When a conversation is being held about a particular topic, there is often an exchange between the participant and the interviewer while on the same topic area, such that you will want to code more than one paragraph or speaking turn. When you do so, include the interviewer’s intervening text as well as the participant’s text, for methodological and practical reasons:
It is helpful to know how the interviewer was prompting or responding to what the participant was saying. And
Every time the coded passage is broken by a non-coded interviewer’s turn, then the
parts will be displayed as separate retrievals and will consequently break up the text when the node is being reviewed.5
Where the passage you are coding is not interrupted by the interviewer you might not need to include the question – unless it is needed to understand the participant’s response (e.g., when interviewing someone who can’t say more than ‘yeah’ or ‘nah’).
� Any time you are reviewing text for a node, you can return to the original source to see what prompted the coded passage.
Coding with analysis in view
Coding can be applied to a word, phrase, sentence, paragraph, long passage, or a whole document. The length of the passage to be coded is totally dependent on context and analytic purpose. You need to include a sufficient length of pas- sage for the coded segment to ‘make sense’ when you retrieve it, but at the same time, avoid coding long, drawn-out, vaguely relevant passages that are going to clutter your reading when you review the text at the node.
basic understanding of how the
90 qualitative data analysis with nvivo
reporting and query functions of the software work (see Chapter 11 for an over- view of these). This is rather a ‘big ask’ at this stage, so here are guidelines to help with those areas most likely to create problems:
Very precise coding of multiple small segments within the same broad passage at the
same node will result in multiple retrievals rather than the single one that would result
from coding the whole passage at the node. Not only does this make the retrievals hard to read, but it slows processing, because retrieving 200 passages is much more demanding on your computer processor than retrieving 50, even if there is less actual text retrieved.
Sometimes, rather than coding all of a meaningful passage for all relevant nodes (slicing the data), researchers code each tiny component of the text at separate nodes (fracturing the data), and so connections between nodes become less clearly defined. Rather than being able to use AND (intersection) queries to find associations, the researcher has to rely on NEAR (proximity) queries. For NEAR queries, it is much more difficult to specify exactly what text should be retrieved, and it is more difficult to interpret the results as there is less guarantee the asso- ciation is meaningful.
If you find you want to add further coding immediately following the passage you just coded, select the text to ensure the passages overlap so the two are counted together as one when NVivo gives counts of coded passages for that node (unless, of course, you really do want it to be counted as two). Also, it will then show in Detail View for the node as a single retrieval.
If you want to find whether experiences or emotions (or whatever) are related to particular contexts (e.g., where or when things are happening, or who is present), then be sure to code the passage with a node or nodes to identify that, as well as for whatever is happening there, even if the context is not specifically mentioned
in that part of the passage (as long as it is clearly relevant). For example, coding
the context as well as a strategy on the same passage will allow you to use a matrix coding query to discover patterns of association between strategies and contexts.
Similarly, if you want to examine something like the ways people responded to issues, events, decisions, behaviours or other stimuli, ensure passages are coded for both the situation being described and their response to that. For example, if you are asking about the strategies counsellors adopt to deal with adolescent behavioural problems, then the description of a particular strategy, if used for a particular problem, is best coded for both problem and strategy, even if the text referring to the problem is in an earlier part of the passage. Doing so will ensure that strategies can be associated with the problems that prompted them (again, using a matrix coding query).
Flexibility and stability
Codes are organizing principles that are not set in stone. They are our own creations, in that we identify and select them ourselves. They are tools to think with. They can be expanded, changed, or scrapped altogether as our ideas develop through repeated interactions with the data. (Coffey & Atkinson, 1996: 32)
Expect your ideas about what is relevant or important to code to develop and possibly change. It is very easy to become beguiled by a thread of thinking you later realize is not important or relevant to the current project. At the same time, to set the parameters of what might be relevant early in the project and limit change thereafter is deadening. Beware ‘shoving’ data into a node – think about whether they actually fit. Check what’s already coded there, and if you’re not sure, create a new node; it can always be dropped or merged later if further data for it aren’t forthcoming.
Your task is to balance flexibility in coding with purposefulness and consist- ency. Developing and keeping a sense of direction in what you are doing is also important, if you are ever going to finish!
� Use the description field in the node properties dialogue to record what a node is about, including perhaps a record of how the concept was developed. Alternatively, if the history is significant, record its development in a linked memo.
Coding also involves balancing between completeness and clutter, between coding the text exhaustively and coding just enough to ensure that each idea canvassed is adequately represented for analysis purposes. This balance will change as the project develops, with coding becoming more strategic. Unless there’s a particular reason for picking up every possible mention of something, code only those texts which clearly illustrate what the node is about. Ask before coding: ‘Why am I doing this?’ Not everything in your data will be equally relevant (though it is hard to know what is or is not at the beginning).
You might also expect to engage in periodic rereading of earlier material, when the salience of particular texts becomes more obvious. In any case, it remains likely that you will create codes which you later drop, and you will occasionally miss relevant passages, but that should not be a major concern. Firstly, important ideas will be repeated throughout the data; secondly, it is likely you will pick up on missed instances of something as you review other nodes, or later as you are querying your data.
� Your coding system will stabilize after your first half-dozen or so sources, but it should nevertheless remain open and flexible, and coding should be interspersed with other activities (memo-writing, querying, modelling) in order to keep your thinking focused and fresh.
Managing the coding process
When coding was referred to as a ‘head-wrecking’ activity on the
to identify three ways in which coding could wreck your head. These were:
through the miserable feelings (frustration, confusion, self-doubt) which can be gener- ated during coding;
because of the possibility of it going on interminably – there is always something else to be found – a sense that coding needs to continue until the task is completed, even if it appears that saturation has been reached; and
because it might impact negatively on analysis – that researchers would focus too much on coding to the exclusion of imaginative, reflective thinking. The problem here was seen as coding rather than computing, however. Marshall quotes the initiator of the discussion as responding to suggestions of computers creating ‘coding fetishism’ with:
… I am a poor veteran of both methods and they both WRECK MY HEAD … When I used paper and scissors I was constantly chasing scraps of paper – now I am a zombie in front of a confuser. (Marshall, 2002: 62)
From the responses given on the list, she then distilled a number of ‘ground rules’ for managing qualitative coding (2002: 69):
Expect that your emotions will be involved, and that some of the emotions will be unpleasant.
Respect this emotional involvement. Give yourself room to be reflexive, and plan your processes so that you can periodically step back and view your methods. Ask yourself how you will know when it is time to stop coding.
Give yourself time and time out so that your imagination and unconscious can be involved in coding. … Include the time for ‘the scholarly walk’ in your calculations of expense and progress rates in the planning stage.
Set routines for coding that will minimise alienation and confusion. These routines should usually involve moving between putting chunks of data in conceptual boxes and thinking about what this means.
Consider seriously the issue of limiting time spent coding.
Lyn Richards often commented that: ‘If you’ve been coding for more than two hours without stopping to write a memo, you’ve lost the plot.’ She rec- ommended regularly stepping out of coding, not only to write memos, but also to monitor and review the nodes you have been making. Be free about making new nodes (rather than sweat over each one as you create it), but also periodically do a check to ensure the categories you are making are relevant, and occasionally review one or two in depth for a useful change of perspective on your data.
When do you stop?
If coding is becoming routine, with no new categories being developed and no new ideas being generated, it could be time to stop, or at least to review your sampling strategy. Of course, if your project is one in which it is essential to code all texts in order to thoroughly test hunches/hypotheses or because
coding basics 93
counting the frequency of occurrence of nodes (e.g., issues raised for a strati- fied sample) is part of the research strategy, you might need to persist until the task is completed. You will need to have worked with enough texts, suffi- ciently thoroughly, to be able to generate convincing answers to your ques- tions or to develop your explanatory theory. If you have additional data you want to just scan through, then scan or listen carefully to those to check if any include comments or images which extend or contradict the model or theory or explanation you have generated from the transcripts you have already ana- lysed. Alternatively, if you have additional data transcribed, then import them into a separate folder for uncoded documents, and use word frequency or text search queries to identify text that contains especially relevant terms from within those sources (see Automating coding in Chapter 5).
Checking reliability
Sometimes, researchers (especially students) are expected to have a second person code some of their data as a check on the ‘reliability’ of their coding, or to code some data a second time, as a check on consistency. These kinds of checks are sometimes seen as an indicator of the trustworthiness of the coding process, and as contributing to the validity of the conclusions drawn from the codes.
While we support the need to check for reasonable consistency across coders in team research, driven by their need to work towards a common goal (see Chapter 12), we question the value of doing so in a project with a solo investi- gator. Each person approaching the data will do so with their own goals and perspective, and so each will see and code differently. Coding is designed to support analysis – it is not an end in itself. What becomes important, then, is that the coder records the way he or she is thinking about the data, keeps track of decisions made, and builds a case supported by the data for the conclusions reached. The alternative is to train someone, like a machine, to apply the same codes to the same data – but all this proves is you can train someone, not that your codes are ‘valid’ or useful. What can be of value is to have someone else review your data and some of your coding for the purpose of having a discus- sion about what you are finding there, especially if you are new to the task of qualitative coding. As noted earlier, discussing a passage of text or other source in a group can open your mind to new possibilities and enrich your interpreta- tion of your sources.
Moving
on
up quite a list of nodes. In the next chapter, we start by thinking about how these might
94 qualitative data analysis with nvivo
be organized to better reflect the structure of your data, and to make your coding system and the coding process more manageable.
In the meantime, you might consider using the nodes you created in coding a source to visualize what you have learned from that source, as demonstrated in Chapter 10. If you haven’t already, you might also find it helpful to write a brief case vignette (in the linked memo) or make a summary of what you learned from the source or case about the main issues of interest in your study.