Four Essential Tips Before You Start Coding Your Qualitative Data
Before you dive into coding your qualitative data, discover these four crucial tips that will help you navigate the process with confidence and efficiency. Learn from a seasoned research consultant's insights!
File
Qualitative Coding for beginners - 4 things you HAVE TO KNOW but NOBODY will tell you about coding
Added on 08/28/2024
Speakers
add Add new speaker

Speaker 1: So in this video I'll share with you four things that I believe are crucial to know before starting to code your qualitative data. I base these four things, so this advice, on my on my work as a research consultant. So every day I work with with individuals and companies. I analyze lots of data sets and also I have face-to-face consultations, face-to-face tutorials with individual clients. So I hear to their problems, I listen to their problems, I try to help them. So I decided to take this advice and share it with you in this video so that you don't have to pay me for a private tutorial. But if you do decide to pay me for a private tutorial the link is in the description. And if this was not the most cheeky and blatant self-promotion ever I don't know what is. So number one on my list and this is something that will be underlying most of most of the advice I give you in this video, coding is a relatively common-sense process, common-sense procedure. If you think about it, coding is something that we actually do quite a lot in daily life, especially if you are a student. So if you think about using for example sticky notes and bookmarks, not to mention PDFs where you actually can make comments, put comments and highlight the text. So all of these things, they are basically what you're doing is coding. So you are making notes, you're selecting a given piece of text and you're writing a short summary or just labeling that text with something. So if you for example make a note, I did it when I was a student, I would make a note saying for example this is a good example of a methodology section or I would make a note saying this is a good justification for why interviews were used. So if I would be working on my methodology I would make this kind of note. So anything that would help me. Obviously not to mention the whole literature, reviewing the literature, making notes about individual notions from the literature that I was interested in. So for example to make notes such as identity, self-esteem, you know some arrows or things pointing to the text. Anyway, any way in which you mark the text, you know you select certain extracts, you give, you make any kind of a note to yourself about this text, what you're doing essentially is coding. Because if you think about it what is coding? This is not the main purpose of this video but if I was to define coding very quickly for you, coding is essentially labeling parts of the text, parts of the data, assigning certain labels, certain names to parts of the text in order to organize it. So you want to organize your text, your data or whatever you're working on for yourself. You want to organize it for yourself, you want to know where everything is and you want to prepare it for further analysis. So basically this will be also the core, the backbone of your thematic analysis because as you do that, as you mark the text with your codes, eventually you'll start seeing patterns, you'll realize there are some codes that were used more often, which means there are certain topics or themes that were discussed more often. So that's what coding is. And like I said, this is what you are doing if you are, for example, marking a book or a PDF file. So this is a common sense thing and I want you to remember this when you, next time you start, you're about to start coding. What I mean in practice is that you should not worry, and this is the main thing that will be underlying the rest of the advice in this video, I don't want you to worry too much about models, guidelines, you know, am I doing this right, am I coding right, how am I supposed to code, is that how an academic would or professional would code it, because there is hardly anything, any notion of correct coding or guidelines to coding. Like I said, this is, you are in charge of it, so coding is correct as long as it makes sense to you, as long as it helps you organize your data and, like I said, label your data, your text with certain names that will help you further analyze this data or this text. And this kind of leads me to the second point, the second piece of advice, and I think this one is also extremely important, it's crucial in fact. So you have flexibility, you have freedom when it comes to naming your codes, when it comes to assigning these names to your codes. Again, this is something that's definitely not obvious and I know based on my students, my clients' feedback. So people often ask me how do I name codes, what's the rule, like what do I use, you know, what is the correct name for a code. Again, there is hardly anything that you can describe as the right way or the correct way. Yes, there are some methodologies where a certain approach to naming the codes is suggested, including grounded theory and their use of gerund forms in the initial round of coding. So basically they say you should use gerund forms, which is the ING ending form, like playing, you know, playing with somebody being stressed about something. That's kind of what grounded theories suggest for the first round of coding, but even there, in grounded theory, if you don't necessarily do this, it's still okay, you don't have to be doing, you don't have to be applying this particular method. And generally, like I said, there are hardly any guidelines or requirements when it comes to how to name the code. So you don't have to worry, you can name them whatever you want, however you want to name them. So whether it is gerund forms, it is, you know, feeling stressed or maybe she felt stressed or the feeling of stress or sense of being stressed or whatever, it literally doesn't make any difference and there is no right or wrong when it comes to how you name these codes. So I prepared, I wrote down, as I was working on a specific data set today, I actually wrote down two codes that I created. So I wanted to share with you these two code names. The first one is gender and perceptions and stereotypes etc. So that's that's literally the name of my code. Gender and perceptions and stereotypes etc. It's far from being a specific thing, it's about gender, it's about stereotypes, it's about etc, so anything else. I just named it because I was working on on this data and I just felt like I think I had a code called gender but then I encountered something in the text that was also about general stereotypes and I thought I'm probably not gonna create another code for stereotypes because I already had this gender code and I thought I'm not sure if gender, either gender or stereotypes, will be important in this data set later. So for now I'll just mix it in all together and I'll just create this general code gender and stereotypes and and whatever etc. So this is just to show you that, you know, it's just for myself, it's a note, it's literally a note for myself, this code. And another one that I wrote down, this is, you're gonna love this one as well, something potentially interesting that I do not understand. That's the name of the code, something potentially interesting that I do not understand. I thought it's funny but this is true. I just realized from the interviewer was talking to the interviewee and there was a whole chunk, a long response from that interviewee, it's a study in healthcare so I'm not that familiar with that topic and I didn't really, I was also quite tired, it was early in the morning and I was looking at this response from this interviewee and I didn't feel or think that it was that interesting or important but what happened then, and it shows you also how subjective a process it is, the whole coding thing, then the interviewer after this response said wow that's interesting and then I said is it? I thought is it interesting and then I read it again but I was so tired I thought okay this is definitely something interesting I'm just probably too tired now to think straight and I just, so I don't want to miss it, I selected this whole bit, I'm using software so I selected this whole bit, this whole chunk of text and I called it something potentially interesting that I don't understand because I will come back to it. It's a note to myself, it's just like putting something in a drawer. Codes are, you know, drawers, you're just putting things in drawers and you're labeling the drawers for later so this one is just I kept it for later. So the whole point, just to summarize again, you have a complete freedom when it comes to naming your codes because codes are just your tools, what I said before, your tools for organizing the data, for making sense of the data, so you have a freedom to name them whatever you want to name them. So they are not themes that will be the final product where you share them, you know, with the world or whatever, with your examiner, they are not themes so they are just something that will eventually become a theme. I have a video actually about codes, how they become themes, so if you want to see that, if you want to watch that video, but basically codes are just your tools at the moment. Later they may become themes, but now they're your tools and they are yours, you are in charge of them, you don't even need to share them. You may share a few examples here or there, but generally they are your tools. Nobody can criticize you for naming a code something potentially interesting that I do not understand. It's your, it's just, you know, it's not their business, I'll put it that way, what you called that code. So the next advice, the next point is, again, it's related. Everything, as I said, is related and the underlying message is that you are in charge of this whole process, you should not worry. So the next one is that the general approach to coding is a very flexible, very vague and flexible notion as well. So what is, you know, the approach to coding? Again, I get asked this question, you know, how do I code? And I understand that for people who are new to this, so if you're new to this, you can be so confused. How do I code? Like, what is the right way? What do I even choose to code? Like, do I code paragraphs, words, sentences? What do I do? Nobody tells me, everybody talks about these codes and labels, but what do I even code? And who decides, how do I decide, you know, what to code and what is important, what is not important? So that's, so I understand, that's the struggle. And again, there is, there are hardly any guidelines, hardly any official approaches or models, you know, for how to code. Again, there is a grounded theory, which is quite characteristic, I suppose, because of their grounded theory's general emphasis on coding. And they are probably the only ones who have a specific, very detailed approach to coding. So they have, you know, these different, different stages of coding and also they are very specific in their very detailed approach to coding. So they say, you know, almost every sentence should be coded separately as a separate thing, as opposed, for example, to whole paragraphs. Again, this is, like I said, it's just one, one approach, but generally, again, there is no right or wrong approach to coding. You can code a word, just a single word, you can code a whole sentence, you can code, you can code a whole paragraph, you can code the same sentence with two or more codes, if you believe that, you know, it's, you want to have these separate codes and this sentence represents different things. So again, you are very flexible when it comes to coding. Generally, if you watch my other videos, you probably know that I do recommend quite detailed approach to coding initially. So I'm not a big fan of coding, for example, you know, whole paragraphs and using very abstract sounding codes, like identity. Not initially, because I do think, and I explain in another video, I'll try, I'll try to find it and link it here as well, I do explain in another video why I believe that detailed line-by-line approach is so good, and it generally helps you control your assumptions, control your bias, and helps you not to miss too many important things. And I believe if you start with a very detailed, very abstract approach, you may simply miss more things in your data. But it's, but it's my preference, see what I mean? It's, there is no, there is no right or wrong. And even when I code, when I use this detailed approach, I mix it with more, with less detailed approach. So again, even now, today or yesterday, I was, I was coding some data and, and there are things sometimes that are, that I am especially, particularly likely to code in a very broad way initially. So I may be coding the whole interview with quite detailed codes, but then I come across this question, for example, do you have any additional comments, or do you have any suggestions for how to improve, you know, whatever it is that we're talking about. It's quite common to put these, these questions at the end of the interview. And it's quite common for me to code them with a very broad code, so I select the whole bit, the whole long response, for example additional comments, and I create this code additional comments. Because initially I have no idea what, what's the meaning, what's the relevance of these comments. But later on, as I'll be working through my codes, I'll perhaps start to develop some kind of a framework, and then I'll come back to these, these additional comments extracts, and then I will break that large code into smaller, you know, smaller specific subcodes. So, so you know, whenever there is, do you have any advice, this kind of question, or additional comments, I will probably come back to it, I will then start breaking it down and listing these actual additional comments as some, some kind of specific codes, or listing the pieces, the kinds of advice given by the participant. But initially I, I tend to code them with one code, like I said, it can cover literally half a page, because it's, all of it is a response to a question, do you have any additional comments. So again, I guess the whole, the whole point, and to summarize this piece of advice, is you are in charge of your approach to coding, there is, so generally there is nothing that would, I know that lots of students feel that this stress, this anxiety of doing something not the right way, it really stops them, and it really limits their, not just motivation and enthusiasm, but their, their creativity, for example, and open-mindedness, because they keep thinking, am I doing this right, is that, you know, I feel like I would do this, but is that what the book would tell me. So, so the whole point again is, you know, there is, it's your approach, the whole point is to, to code your data, to later use it, and to, to analyze it thematically, to develop themes, and, and just use whatever way, you know, will get you there, whatever, whichever way makes you feel comfortable with the process, and, and when you feel that you, you know, it helps you familiarize with the data, that's, that's the right way, there is no right or wrong here. And finally, the last piece of advice, and actually this is something that I've been saying throughout the whole video, I just wanted to really stress this, and highlight this, you are in charge of your coding, and your, and the coding process. So that's, that's the only advice, really, that I want to give you, but obviously that would be weird if I just gave you one piece of advice, but everything that I explained in this video actually relates to this, you are in charge of the whole process. Again, I will repeat, you are in charge, this is your, the codes are your tools, analytic tools, you are free to use them in whatever way you want to apply them, in whatever way you want to name them, whatever you want, so, so you are literally in charge of this thing. So I don't want you to worry about, you know, being evaluated and assessed, and, and anything like that, I just want you to remember the goal of this whole process, the goal, you know, of analyzing your data, I want you to think about, you know, your research questions, and your aims, and your desire to know the answers to your research questions, rather than thinking about what would he do, what would she do, you know, what would the book tell me, or my supervisor tell me, so you are in charge of coding and your coding process. So that's everything that I wanted to share when it comes to coding, feel free to add comments under the video, I'm really interested to hear if you have any, perhaps additional pieces of advice or questions to me, or your own insights based on your experience with coding, and like the video if you learned something new, and if you're new to this channel, consider subscribing.

ai AI Insights
Summary

Generate a brief summary highlighting the main points of the transcript.

Generate
Title

Generate a concise and relevant title for the transcript based on the main themes and content discussed.

Generate
Keywords

Identify and highlight the key words or phrases most relevant to the content of the transcript.

Generate
Enter your query
Sentiments

Analyze the emotional tone of the transcript to determine whether the sentiment is positive, negative, or neutral.

Generate
Quizzes

Create interactive quizzes based on the content of the transcript to test comprehension or engage users.

Generate
{{ secondsToHumanTime(time) }}
Back
Forward
{{ Math.round(speed * 100) / 100 }}x
{{ secondsToHumanTime(duration) }}
close
New speaker
Add speaker
close
Edit speaker
Save changes
close
Share Transcript