Qualitative analysis · Lesson 1 of 3

Coding: from text to categories

A code needs a definition and a boundary. Without both it expands until it means nothing.

9 min read · Free — no account needed to read

Coding is labelling segments of material with what they are about, so that a hundred pages become something you can reason across. It is the basic operation and it is done in stages.

Open coding goes through the material labelling closely and generously, staying near what was said. The output is many codes, some overlapping, most of which will not survive — and that is the point: you are reading systematically rather than hunting.

Axial coding looks for relationships among codes: which belong together, which are conditions for others, which are consequences. Categories start to form.

Selective coding organises around the central categories that answer your question, and returns to the material to check that they hold.

A codebook records each code's name, definition, an example, and when *not* to apply it. That last field does most of the work — it is what stops a code quietly expanding to mean everything by the fortieth transcript, and it is what makes a second coder possible.

Deductive coding starts from a framework and applies it; inductive coding builds from the material. Most real projects are both, and the honest version says which parts were which.

The discipline throughout is to code everything relevant, not only what supports the emerging story. Material that resists your categories is the most informative thing you have.

See it happen

By the fifteenth transcript, your code "lack of support" is applied to about half of everything.

The read that arrives on its own

It is clearly the dominant theme in the data — that is your main finding.

The same situation, with this idea

You check the definition and there is not one, so the code has been absorbing anything adjacent: no training, an unresponsive manager, unclear processes, no peer network. Those are four different findings with four different implications. You write definitions with a "do not apply when" line, split the code, and recode from the start — which is slower and is the difference between a finding and an impression.

After this, you can

write what a code does NOT cover, before it grows to cover everything.

The takeaway

A code needs a definition and a boundary. Without both it expands until it means nothing.

Easy to take the wrong way

That more codes mean better analysis. Fifty codes nobody can define is worse than twelve that are sharp and applied consistently.

Try this

Take your most-used code and write its definition, an example, and when not to apply it. See whether it should be two codes.