Welcome to DevX Digest - the place to hear all about Developer Experience, brought to you by Pauline Narvas (@paulienuh) and Mike Nikles (@mikenikles) from Gitpod. You’re reading another newsletter from us 🎉! In this edition, we deep dive into the psychology behind developer experience. The key question we will be answering today is whether developer experience is not easy because we don’t want it to be?
Have you noticed the language used when describing improved developer experience? Tooling is easier, faster and simpler. Despite these promises, Stripe released a developer coefficient report in 2018, revealing that developers waste a lot of time due to tooling that doesn’t deliver on its efficiency promises. A waste of time costs money. The question then becomes - why haven’t things gotten easier?
“The best moments in our lives usually occur if a person’s body or mind is stretched to its limits in a voluntary effort to accomplish something difficult and worthwhile.” - Psychologist Mihaly Csikszentimihalyi.
In other words, the effort put in to accomplish something challenging is a rewarding experience. It feels good being able to do something hard that not everyone can do. Is this why developer experience hasn’t improved? Because we as developers like the challenge?
Think back to the last time you were bored. For example, you have spent so much time doing manual work that could be automated. Automating this task may take a lot longer and is perhaps more difficult to do… But at the end of it, your brain feels accomplished and as a result, you feel better about the task. You successfully completed the challenge that you set yourself! It was not too easy (boredom) and not too hard. When something is too hard, resistance and anxiety block your brain from ever entering flow. It’s a balance!
Ellen Chisa suggests that perhaps developer experience has been optimising for the wrong thing this whole time? Instead of making things easy, faster, simpler; we should be optimising for the flow we described above. Let’s delve into this some more using the example of onboarding.
If onboarding is too hard, you can often hit that wall of frustration and spiralling anxiety that comes with it. So how do we solve this? Leveraging the feeling of familiarity is so important. 🎯
- Anchoring familiar onboarding e.g. from the comfort of a CLI tool!
- Connecting the tool to an existing skill
- Connecting to an existing workflow e.g. adding to the toolchain
On the other hand, when something is too easy, people can switch off completely. Brains, eh?
There needs to be enough effort that people feel like they’ve done something meaningful. None of us wants the experience of developing software to just be like copy and paste. The feeling of making some real progress by doing should be embedded into the developer experience as it is what brings people back into the flow. 🧠
How do you solve this? Developers need to be made to feel like something is believably hard.
Now you don’t want to overwhelm people by providing them with every single bit of information at once.
This will give you the opposite effect: too much to comprehend and anxiety rises. But if you give too little, folks may feel like they know it all already leading to boredom. The best way to solve this is by sending information over a period of time, this is where progressive disclosure comes in.
In software, this is done quite well with error messages and documentation. Good error messages can reduce anxiety as users are informed about what is going on and feel empowered to solve it, resulting in flow. Good documentation can also support learning and lead to the feeling of growth.
Developers come from all walks of life, from vast backgrounds and experiences, making awareness of these differences important.
For instance, let’s take learning styles. Ellen highlighted that developers learn in different ways which contribute to their onboarding experience. Some developers…
- Read the documentation 📖
- Start with a blank canvas and learn by building 💻
- Completely take apart an application and reverse it to fit their own needs 🛠
In a similar sentiment, there’s a saying: the more you know, the more you don’t know.
Ellen experienced this herself when showing darklang to developers with functional programming experience, folks with limited programming experience and those that had internalised imperative models. Interestingly, it was the latter group that struggled the most with onboarding because they had a lot of unlearning to do.
Do your efforts in developer experience account for this diversity?
Another important part of developer experience is customisation. Ideally, developers will grow with a tool over a couple of years. Giving developers the power to customise their experience will cultivate positive feelings as they improve their expertise in it. This will ultimately lead to users paying it forward, sharing and re-investing in your tool in the long-term, which is great!
There’s a reason why people enjoy sharing their CLI tools, colour schemes, remote office set-ups and optimising these things to their needs.
We may need to rethink how we look at developer experience. Instead of promises of tools making our lives easier, better, more efficient, it may be worth honing our focus towards designing balanced experiences that cater for everyone’s learning styles, improving progressive disclosure and giving more power to the developers to make the experience their own.
As Ellen ends her DevX Conf talk beautifully:
“we don’t want magic, we want to be magicians.” 🪄
Another thing about Gitpodders is that we’re all driven by community feedback, and this newsletter is no exception! Please send us your thoughts, feedback and help us drive this conversation. We may even feature some of your takes and comments in future newsletters!
Come and hang out with us over on our Discord channel.
More about DevX Digest
Sign up for our newsletter or follow @devxcommunity on Twitter to stay updated.