Grammatically speaking, "coding data" implies that something is done to the data; applied to the data. Data are being coded; they become en-coded. However, qualitative researchers also use the term "coding data" when they describe processes in which they generate codes with, or from data. I think this is confusing. The term "coding data" characterizes one end on a continuum of coding practices: coding as sorting. When we describe how we build or reconstruct systems of meaning by analyzing data it may make more sense to say that we're "data-ing codes".
Imagine you're making a papier-mache statue. When working with papier-mache, you're attaching paper to paper. You're bringing pieces of paper in relation to each other to build up shapes. You're not sorting pieces of paper into pre-existing shapes. In this metaphor, 'data-ing the code' implies that data build up, stick to some sort of initial wire frame. They don't stick magically, but because of analytic processes. Methods are the guidelines for these processes.
Know how you're wired
Let's stick with the metaphor of the wire frame. Think of the wire frame as the knowledge and assumptions that you bring to the table as a person. Your task as a qualitative analyst is not to pretend that there is no wireframe. Ian Dey put this perfectly: "[A]n open mind is not an empty head" (Dey 1993:229 in Bong 2002:15). To have an open mind, you first must be aware of your wire frame: "[T]he articulation of early presumptions does not inhibit or distort her [cs: the analyst's] clear vision; rather it is likely to make her lens more lucid, less encumbered by the shadows of bias. Making anticipatory schema explicit [...] allows for greater openness of mind." (Lawrence-Lightfoot & Hoffmann Davis 1997: 186).
Before you start working with your papier-mache, take a picture of your wire frame. Later on, compare the picture you've taken with the shape that has built up through your work. Ask yourself: To what extent is this new shape influenced by my initial wire frame (i.e. my anticipatory schema)? To what extent is it influenced by the way I've brought different pieces of paper in relation to each other?
Keeping the wires flexible
While you're data-ing a code, you are keeping your wire frame as malleable as possible. You want to analyze in ways that allow data to modify it, and bend it into new directions. You want experiences that people shared with you to grow over your wires, even break them and mend them in unexpected places. This is where discovery happens. Maybe some wires arch, maybe in some places your papier-mache accumulates to create new bulges that extend out from the original frame.
As you start your analysis, your code is a hollow, translucent place holder, and its only substance is your pre-existing knowledge. By 'data-ing' it, by constructively assembling data on and around it, the code takes shape. Your next step during analysis is to see what kinds of larger shapes your code-shapes form, and how you can cut and re-assemble several shapes you've created.
To some degree, the wire frame will always shape your outcomes. But the more you work with data, the more layers of analysis you plaster on, the more you re-assemble parts of the shapes that emerge -- the more your final product(s) will be shaped by the process itself, rather than your initial wire frame. The deeper your analytic engagement, the thicker and more intricate the emerging layers and shapes will be. If your process of analysis is brief and shallow, your wire frame will be more dominant. There might even be some wires sticking out here and there. Ouch!
So...which one's better then? Coding or Data-ing?
Typically, you'll do both when you code. Even when you work with a stable top-down coding scheme, you will stumble over new codes or new themes that build up or emerge because of your process of applying codes to data. That's because you're actually thinking about the data that you sort into codes. Sorting is in itself a potentially generative process, because you need to decide (and document, and justify!) why a piece of data fits, and why not.
On the other hand: Even when you build codes ground-up from data, you will at some point assign data to codes as they stabilize. You're building a container out of papier-mache. You don't know the shape of the container yet, and what kinds of things could actually fit into it. But at some point the container has shaped up, and you can put things into it, rather than layering things onto it to construct it.
It's pointless to try to do one, and to pretend to not do the other: "Data analysis is at once conceptual and organisational, interpretive as well as mechanical." (Bong 2002:31). That's why it is so tricky - you're always working on a spectrum, like the one above. Each analytic practice is a mix. You'll probably use several coding techniques simultaneously, and they may be located on different, complementary regions on this spectrum. Your analytic practices may move alongside the continuum as you proceed through your study. The point is to know where you are on the spectrum, and to know the consequences of your practices' different locations on the spectrum as you do your research. Qualitative methods are guides that can help us pinpoint the locations on the spectrum. They help us realize when and how we move along on the spectrum - and when this could get us into trouble.
Literature & Credits
Bong, Sharon A. (2002). Debunking Myths in Qualitative Data Analysis. In: Forum Qualitative Sozialforschung / Forum: Qualitative Social Research [Online Journal], 3(2). [Last Access: 2/27/2016].
Coffey, Amanda & Atkinson, Paul (1996). Making Sense of Qualitative Data: Complementary Research Strategies. Thousand Oaks: SAGE.
Dey, Ian (1993). Qualitative Data Analysis: A User-Friendly Guide For Social Scientists. London & New York: Routledge.
Lawrence-Lightfoot, Sara & Hoffmann Davis, Jessica (1997). The Art and Science of Portraiture. San Francisco: Jossey-Bass.
Saldaña, Johnny (2013). The coding manual for qualitative researchers. 2nd ed. Los Angeles: SAGE.