Thread by @drvicclarke

1/10 For those of you learning about or having a go at #thematicanalysis for the first time, & particularly the TA approach developed by me & @ginnybraun (which is quite diff from others), I want to share some thoughts on coding in our approach, & tips for learning to code well.

2/10 One thing to avoid when you're reading data is starting to think about themes straight away & use coding to identify themes in the data. Our approach involves building themes from codes, so themes happen later in the process. Make a note of your ideas & put them aside.

3/10 You want to avoid reading the data through the lens of these initial impressions - sometimes our initial thoughts are 'gold', but often they are quite superficial or obvious, & a thorough familiarisation & coding process can lead to more complex, nuanced & richer insights.

4/10 For your 1st go at TA work in hard copy if you can - it's important to develop a robust TA sensibility & clear sense of good practice, otherwise software programmes can shape our coding process in ways that aren't always helpful - it's all to easy to generate loads of codes.

5/10 Because themes are built from codes, & the coded data, coding labels need to clearly evoke what is analytically relevant. This highlights that coding in our approach isn't just about data reduction & summary, it's also about interpretation & analysis.

6/10 For these reasons, one word coding labels are unlikely to do the job! They are too coarse - we often see people using labels like 'gender', 'benefits'... what about gender? what about benefits? What is analytically relevant here beyond that broad label?

7/10 Try the 'take away the data' test - without the data next 2 yr codes, do the codes clearly evoke what is analytically relevant for u? If not, the labels will need some refining. People are understandably anxious about the semantic/latent distinction, so let's consider that..

8/10 This distinction is there to help you reflect on how u are coding - at the surface level of meaning or looking beneath the surface to the underlying assumptions & meanings. Reflexivity is key to good coding practice in TA - try to reflect on what assumptions yr making.

9/10 This is really tricky & it can help to share yr thoughts with someone else. What I am overlooking/not seeing? How R my assumptions constraining & limiting how I'm engaging w/ the data? The S/L distinction will help you to reflect on the level at which yr engaging with data.

10/10 But u don't have to have both S & L codes, or try to force the latter. Most analyses have a mix of both - L codes R not inherently better 'cos they seem cleverer! Coding always needs to fit to yr purpose! So try not to sweat the S/L distinction & use it for reflection.