What lies behind the red flag question: “I’ve done all my coding – now what?” In my last blogpost I considered the first likely culprit: starting to code before thinking through its purpose. But thinking about the purpose isn’t enough. A second issue is the need to think about coding as an on-going process – not as a single event that gets “done” before moving on to the next event. Coding is the opportunity to repeatedly connect with our data.
Moments of contact
There are many different “moments of contact” with the data in a qualitative or mixed-methods analysis. Some have nothing to do with coding, like the very first, when data is collected. Or immediately after, when you automatically find yourself reflecting on what was seen or heard. Or when transcribing, an undervalued moment of contact with its unavoidable decisions about what and how to represent what is heard into words on a page. There are others, but none of these examples involve codes.
Coding as moments of contact with the data
But many moments of contact do involve codes. These are so many different moments of contact that it is impossible to think of coding as a single moment that gets “done” before moving on to the next task. Thinking of coding as a single moment inevitably weakens the analysis and leads to the tell-tale question that suggests an analysis isn’t focused: “Coding’s done. What’s next?”
The more iterative the research – the more times that data needs revisiting from different perspectives – the more moments of contact there are. But every qualitative project has a degree of iteration, so the principle holds for virtually every project: coding is a process involving moments of contact that occur throughout the project.
Here are some examples that represent key moment of contact with data:
Familiarizing yourself with data collected by others. You become familiar with data you collect and transcribe yourself during those moments of contact. But you don’t already have an overview when working with secondary data, so data familiarisation becomes an important moment of contact that informs coding.
Exploring data for potential concepts. Working inductively means exploring a sample of data in detail before coding across the dataset. This helps prevent helter-skelter coding without a plan of focus.
Looking for pre-determined concepts. Working deductively means looking at data in detail for concepts derived from your theoretical framework. You'll then see the context in which the concepts are expressed.
Retrieving and reviewing coded data. Coming back to the coded data to retrieve relevant data segments has many purposes. For example: reflection on what’s going on in the data in relation to our research questions; assessing whether they adequately represent the current working definition of the code; checking for their degree of equivalence; and so on.
Rationalising a coding scheme. Retrieving and reviewing coded data almost inevitably leads to refining the coding scheme – deciding which codes to re-name, merge, split, move, delete, etc.
Interrogating connections. One reason we code is to later explore the connections between the concepts that are represented by codes: to explore patterns, relationships, or anomalies; test theories or hypotheses when working deductively; and validate interpretations when working inductively.
Coding as a process
Coding doesn't involve going through each data file and sequentially coding each segment in turn to all the possibly relevant codes – and then we’re done. Coding is a process that is alternated throughout a project with other processes. Whatever the coding approach – and there are many – we flip back and forth between and within data files, repeatedly retrieve, re-read, compare and re-think coded data segments, then un-code, re-code, and re-name accordingly, thus refining the coding scheme and rethinking the concepts that the codes represent. It’s an iterative process of repeated contact with segments of data.
The role of CAQDAS packages
There’s a range of opinions about the impact of CAQDAS packages on the process of coding. I disagree with suggestions that CAQDAS always favours coding or homogenises methods to code-based approaches to analysis. Yes, these programs have sophisticated coding tools – because many methodologies involve coding. But the programs also provide ways to support different approaches to qualitative data conceptualisation. And the coding features in CAQDAS programs can also be used for other useful purposes than those required by code-based approaches. The key point is that however you harness the coding features of a CAQDAS program, it is a process that occurs throughout the life of a project.