Coding. Yay. Eek. Ugh.
Let’s face it, coding is a biggie. You don’t get far in the qualitative data analysis literature without seeing some mention of it. To be clear, this post does not assume coding is necessary in all qualitative data analysis. Nor does it assume coding amounts to qualitative analysis in the sense that coding is all you need to do. There is always an analytical residue – more interpretive work post-coding; in fact coding is often only a small part of qualitative analysis. Lots of analyses I’ve done haven’t used coding at all.
But coding can be incredibly valuable to us as qualitative data analysts. The problem is, it’s really easy to be busy coding but not to be doing so well. In this post I’m trying to spell out what it might mean to code well, and how you might know if you’re doing so.
Why code in the first place?
If you’re coding without knowing why, and without having made a deliberate choice to do so (rather than feeling you have to), it’s not a good start. Coding potentially serves lots of purposes, including but not limited to:
- Enabling you to retrieve chunks of data, or particular phrases, quotations etc, later when you need raw data in your writing, or if you want to check ideas that come up.
- Helping you ‘be with’ the data in a particular way, getting you up-close to the text.
- Maybe you might notice things in it that you haven’t seen before
- Maybe you might notice things important to the participants (but not originally to you)
- Lifting your ‘being with’ the data up a level to notice distinctions and associations (ie similarities and differences) at a high level of resolution
- Lifting your ‘being with’ the data up a level to notice where concepts or theoretical ideas might be manifest in concrete instances in your data
- Helping you develop codes, categories, or themes, that can become building blocks for subsequent analysis; You might compare or contrast these within or across cases, for example, or employ frequency counts.
What does coding well look like?
Coding is a slippery slope. I slid a long way down it several times, landing with a bump when I realised I’d been busy but uselessly so for several weeks. I forgot to keep these things in mind:
- Good coding relates to how hard you’re thinking (and helps you think harder). If you’re finding coding easy, or you’re not constantly having to make difficult decisions about what to name codes, how to code pieces of data, how big those pieces should be etc, chances are you’re not coding well.
- Good coding means you are seeing new things in the data and these new insights are progressive. Progression might mean enriching your argument (answer to research questions), or sharpening it (fixing in on what is essential, for example). These ‘new things’ could be new codes or categories or themes, but they could also be patterns, distinctions, associations, forms of significance, why things matter etc.
- Good coding settles towards a parsimonious set of codes/categories/themes. The best coding system is not the one with the most codes in it. An analyst who has created 10,000 categories has not done work that is 1,000 times better than the analyst who has created 10 categories. Chances are, the latter has been thinking much harder than the former as she goes. By parsimonious I mean strikes the optimal balance between power of explanation (persuasive, novel argument and insights) and complexity (number of ideas or building blocks in the argument). We can expect diminishing returns: adding five more codes or categories to a system that already has 50 probably doesn’t add as much as value as adding five to a system that only has two or three.
- Good coding opens up as much as it closes off: coding rarely, if ever, provides the answers to your questions. Rather it creates building blocks or thinking tools (and retrieval systems) that allow you to get closer to those answers. So good coding might open up by:
- Making new connections between parts of the data possible
- Making new distinctions between parts of the data possible
- Leading you to frame new questions that might specify how you will arrive at the answer to your big research questions
- Giving you units of data, concepts, ideas (and their inter-relationships) that you put to work in the next analytical stage.
But good coding isn’t purely expansive and generative. It also has to have boundaries and bring focus. So good coding might close off by:
- Helping you decide what data or concepts or categories to focus on, and which to set aside
- Consolidating what used to seem disparate or unconnected into coherent units that you can work with in whatever follows.
And this leads to my final point: good coding is a process that enables you to take further steps in analysis that wouldn’t have been possible without having done the coding. The codes are not the outcome (unless your research findings are going to be simply a matter of describing themes that come up in interviews, for example, which sounds terribly dull). If you can do the next step without more coding, perhaps it’s time to move on. If you can do it without the coding at all, why are you coding?
I would love to hear your experiences of coding – why do you code? When and how do you choose not to code, or to stop and move on to other analytical processes? How do you know you are coding well? Have you had experiences (like I have) when you’ve spent ages coding only to realise it hasn’t got you where you wanted to be?