Qualitative Coding

What a code actually is, the types worth knowing, building a codebook that holds, and staying consistent across a long dataset.

The short answer

Coding is labelling segments of qualitative data so they can be gathered, compared and built into something analytic. A code is a label, not a finding: the analytic work happens afterwards, when codes are compared, grouped and raised into concepts. Most coding problems in doctoral work come from two things — codes defined too loosely to apply consistently, and coding that never moves beyond describing what was said.

What a code is, and what it is not

A code attaches a short label to a segment of data, marking it as an instance of something. That is all it does. It is a filing decision with analytic intent, and treating it as more than that is where confusion starts.

Three things follow.

Codes are not themes. A code says what a segment is about; a theme makes a claim about what it means. Grouping codes under headings produces categories, not themes, and the step from one to the other is separate analytic work.

Codes are not findings. A list of forty codes is not a result. Nobody should ever see your full code list in a findings chapter, though it belongs in an appendix.

Codes are working tools and will change. Codes get merged, split, renamed and abandoned throughout. Expecting to define them correctly at the start is what makes people over-plan the codebook and then feel they have failed when it moves.

Types of code worth knowing

Saldaña’s manual is the standard reference here and catalogues a large number of coding methods. A handful cover most doctoral work, and knowing their names lets you describe your own practice precisely rather than saying “the data were coded”.

TypeWhat it labelsUseful when
DescriptiveThe topic of the segment, in a word or short phraseFirst pass over varied material; inventorying a large dataset
In vivoThe participant’s own words, kept as the codeParticipants’ own language matters; avoiding premature translation into your terms
ProcessAction, usually as a gerund — “managing uncertainty”The question is about how something unfolds; central in grounded theory
EmotionFeelings recalled or displayedExperience and its affective content are part of the question
ValuesValues, attitudes and beliefs expressedStudying culture, motivation or conflicting commitments
VersusOppositions and conflicts in the dataContested settings; competing accounts of the same events

Most doctoral projects use two or three of these together, often descriptive coding to get oriented and then something more analytic. Say which you used, and where.

One further distinction cuts across all of them. Semantic coding stays with what was explicitly said; latent coding labels what appears to underlie it. Latent coding is more interpretive and needs more justification, and mixing the two without noticing produces a code list where some labels are descriptions and others are arguments.

First and second cycle

Coding runs in at least two passes, and conflating them is why some analyses stall.

First cycle works on the data. You move through transcripts labelling segments, coding generously, staying close to the material. The aim is coverage: getting everything relevant marked, without worrying yet about how it fits together.

Second cycle works on the codes. You are no longer reading transcripts primarily; you are comparing, merging codes that turned out to be the same thing, splitting ones doing two jobs, discarding those that never earned their place, and grouping the rest into categories. This is where the dataset starts becoming an analysis.

People who feel stuck after coding have usually completed the first cycle and are waiting for meaning to appear from it. It will not. The second cycle is a different activity and has to be started deliberately.

Expect a substantial reduction between the two. A first cycle producing well over a hundred codes is normal; a second cycle that does not collapse that considerably usually means merging is being avoided.

A codebook that actually works

Whether or not your approach requires a formal codebook, keeping one makes coding consistent and makes the chapter writeable. Approaches vary: coding-reliability work fixes it early, while reflexive approaches let it evolve throughout. Either way it should exist.

For each code, record:

  • Name — short and stable.
  • Definition — one or two sentences on what it captures.
  • When to apply it — the inclusion rule.
  • When not to — the exclusion rule, and the line most often left out. It is where your future self, three months on, disagrees with your past self.
  • An example — a real extract from your data.
  • Date and note on changes — when it was added, merged or redefined, and why.

That last item is doing double duty: it keeps you consistent, and it is the audit trail your methodology chapter will need as evidence of dependability. Reconstructing it at the end is close to impossible.

Staying consistent over months

Doctoral coding happens over a long period, often with gaps. Consistency is the practical problem nobody warns you about, and it is visible in a finished thesis when early transcripts are coded differently from late ones.

What helps:

  • Recode earlier material when a code changes. Tedious, and the alternative is a dataset coded under two different schemes.
  • Code in reasonably long sessions. Twenty minutes here and there produces drift; you re-enter the dataset without having re-entered your own thinking.
  • Re-read your definitions when returning after a break. Especially the exclusion rules.
  • Check yourself against yourself. Recode a transcript you coded weeks ago and compare. Where you disagree with your past self, the definition was too loose. This is worth doing whether or not your approach uses reliability statistics.
  • Keep memos alongside the codes. A note on why a code was created preserves the reasoning that the label alone will not.

Knowing when coding is finished

Coding can be extended indefinitely, and it is a comfortable place to hide when the interpretive work ahead feels harder. Two signals that it is time to stop.

New material is producing no new codes. Everything is being absorbed by existing labels. In approaches using theoretical sampling this connects to saturation; in others it simply means coverage is adequate.

You can describe what the dataset is about without consulting it. If you can sketch the shape of your findings from memory, the coding has done its job and the second cycle is where the remaining value is.

Coding is not the analysis. It is what makes the analysis possible, and a thesis whose findings chapter reports the code list has stopped one step short of the work.

Questions researchers ask

What is coding in qualitative research?

Attaching short labels to segments of data so they can be gathered, compared and built into an analysis. A code marks a segment as an instance of something; it is a filing decision with analytic intent rather than a finding in itself. The interpretive work happens afterwards, when codes are compared, merged and raised into concepts or themes.

What is the difference between open, axial and selective coding?

They are the coding stages in grounded theory as set out by Strauss and Corbin. Open coding breaks data into concepts and categories; axial coding works out how those categories relate; selective coding identifies a core category and integrates everything around it. They belong to that methodology specifically, so using the terms for a study that did not sample theoretically or analyse alongside collection is a mislabel examiners recognise.

How many codes should I have?

First-cycle coding commonly produces well over a hundred, and that is fine — it is coverage, not analysis. What matters is what happens next: a second cycle that does not substantially reduce that number usually means merging is being avoided. There is no target figure, and a thesis is not judged on the size of its code list.

What is the difference between a code and a theme?

A code labels what a segment is about; a theme makes a claim about what it means and is organised around a central idea. “Workload” is a code. “Staff absorb unmanageable workload privately because admitting it reads as incompetence” is a theme. Grouping codes under a heading produces a category, not a theme — the move between them is separate analytic work, and it is where most qualitative chapters stop too early.

Should I code inductively or deductively?

Most doctoral work does both, and describing that honestly is stronger than claiming a purity examiners will doubt — you bring a question, a literature and a discipline to the data, so pure induction is largely a fiction. What matters is being specific about which codes came from the data, which came from theory, and what you did when the data would not fit the framework.

How do I keep my coding consistent over several months?

Write exclusion rules as well as inclusion rules in your codebook, since that is where you will later disagree with yourself. Recode earlier material whenever a code changes, work in reasonably long sessions rather than short scattered ones, and re-read your definitions after any break. Recoding a transcript you coded weeks earlier and comparing the two is a useful check regardless of whether your approach uses reliability statistics.

Related guides

Stuck between coding and findings?

The stall after first-cycle coding is the most common point at which qualitative theses lose months. Describe your dataset and where the analysis has reached, and a PhD in your field will work through the next step with you.

Discuss your analysis