Yeah I know this sounds like humanistic BS to some of you, but try get out of your bits and bytes filled and limited world. Great products including APIs are not created with just technology. It’s like ying and yang, you need the hard tech and soft humanistic side as well applied to the process. On top of that you need the off business thinking as well. Nevertheless, ethnography is part of any great API product and developer experience. This is why I added it to 360 DX model in post 38 as one of the slides between human behaviour and engineering.
Obvious to some
To me this is kind of obvious, but that is mostly related to my background. I’m no developer. I can write some pretty damn ugly code and gets things to compile, but that’s it. I’m perhaps sort of wannabe generalist developer. Instead I’ve used nearly 20 years of my life to understand what kind people developers are, what they value and how they behave.
I have been on my never-ending ethnographic journey among the developer community at least since 2001. I might even say that this is my version of Stanley Kubric's "2001: A Space Odyssey".
I started by doing research about Linux and Open source communities and participated Ubuntu Finland community actively observing their behaviour. At that point I did my Master’s Thesis about hackers. Then I went on to hackerspaces around 2009 and established one community in Tampere (which is still very much alive an kicking with 350+ members). At that point I had already turned my head towards PhD and started doing ethnographic research among the hackerspaces. Eventully I went on to 3D printing community and profiled the ecosystem around low-cost 3D -printers (topic of my PhD thesis). Around 2013-2014 I turned my focus to API economy. Now I’m more on the platform economy. Considering my past, it’s no wonder or surprise that developer experience intrigues me. I have always been keen on developer and hacker scene.
Now lets have a look at why I consider ethnography so important in developer experience development.
What is ethnography?
For some, ethnography has become a synonym for qualitative research, so that any qualitative approach may be called ethnographic in whole or part, as long as it involves observation in non laboratory settings.
Originally developed in anthropology to describe the “ways of living” of a social group (Heath), ethnography is the study of people’s behavior in naturally occurring, ongoing settings, with a focus on the cultural interpretation of behavior (Firth & Hymes).
The ethnographer’s goal is to provide a description and an interpretive-explanatory account of what people do in a setting (such as a office, dark basement, code events), the outcome of their interactions, and the way they understand what they are doing. A lot of ethnographic research has been conducted to find out and describe the well-known concept of flow state related to productivity of developers.
Applied to DX development
People working with DX and developer relations probably use the ethnographic-ish approach sometimes without knowing it. They observe, discuss and analyse developers. That is how you learn about some people.
Ethnography focuses on people’s behavior in groups and on cultural patterns in that behavior. In DX it includes how developers interact with the world and people around them. What kind of patterns can be found. For example open source prone attitude is one. Another one is continuous learning.
Developers have their own culture, which of course divides to subcultures and groups as well.
As an example some are backend oriented, some frontend. Popular API driven solutions have distinct groups around it. If you happen to be responsible for that product’s DX, you should constantly analyse their behaviour and patterns to identify what 80% of them needs, what kind of workflows they have, is your audience early birds or night owls. You need to get under their skin, you need to live with them.
The early ethnography prone researchers lived with the people they studied. That is hardly possible for you but you should be in contact with them, observe their behaviour and analyse it, chat about other stuff than just your product. Analyse their professional history if possible (Github profile analysis, LinkedIn profile analysis). Aim is to become one with the customers. Eventually the developers are not just numbers in your DX dashboard, but you can “see” John and Jane from the data. They are no longer stereotypical developers to you.
The idea is to understand your target developer group so well that you can imagine their daily professional life. You can anticipate their needs to some extend.
You learn the vocabulary and hidden meanings of acronyms and sayings. A lot of the communication with developers requires understanding of their culture and history of it. That is not achieved by looking at google analytics and customer paths.
Ethnography is holistic; that is, any aspect of a culture or a behavior has to be described and explained in relation to the whole system of which it is a part. This is what I love about ethnography. It’s not about atomistic observations, but about systemic changes and patterns. We are talking about people, humans, and we are all affected by the surrounding environment and our past. People behave differently in differnt situations and group dynamics is intriguing area of psychology which helps us to understand why one developer is productive with certain kind of other people and practices.
As method, ethnography includes the techniques of observation, participant-observation (observing while interacting with those under study), informal and formal interviewing of the participants observed in situations, audio- or videotaping of interactions for close analysis, collection of relevant or available documents and other materials from the setting.
Ethnographic data collection begins with a theoretical framework directing the researcher’s attention to certain aspects of situations and certain kinds of research questions. In real life when you are building image of the developer base, you don’t just randomly collect data. You have questions for which you need answers. That’s it, there is no “scientific” add-on. Good science is practical. Theoretical framework is constructed from previous knowledge and then the holes are found. Based on what is missing and what we want to find out, we formulate questions. Sometimes there is no framework and in those cases observations are analysed and theories are born out of that. Nevertheless, you have always questions which needs answers.
Use ready-made results
Doing your own “research” is good way to go deeper into the developer community which is your target group. They are influenced by bigger trends and values which often come from larger group of developers. To get insights on that you can try to run huge surveys. That will most likely fail since getting hundreds or thousands of respondents to your survey is not simple. I would advise you to read results from studies conducted by others. Of course you need to evaluate the methodology and not to take everything as granted. A lot of shit is pushed nowwdays as valid scientific research. You can and should use non-academic resources as well, but be vary of skews and hidden agendas in those.
Use what ever means you can think of the build image of the customer. Make it data driven. Using scientific approach does not equal boring or useless philosophical discussions. Science used right is fun, really helpful and practical. Science is about transparency, replicability and systemic analysis. You probably use the same methods and patterns without knowing it. Your first rounds with methodology might be kind of book example, but when you get familiar with the methodology you can and should be creative.
Now that the reasoning to add ethnography to DX development has been discussed, I could go into more pragrmatic examples in the future.
Some more to read from 100 Days DX
- #100 - The biggest open resource on Developer eXperience so far
- #99 - Hackers - the top 1% of engineers
- #98 - Invalid Open API spec files ruins the developer experience
- #97 - Lightweight API evaluation framework
- #96 - Embracing open source community driven tools development
- #95 - Exploring the multilevel nature of API Design Guides
While you are here...
Check out Platform of Trust in which I've worked to enable best possible developer experience!