DevEx Principles: Minimize switching contexts
My Principles for Developer Experience
Recently someone asked me what my principles are for DevEx. Over the past 15 years shipping products for Heroku, GitHub, and now Vercel, I've learned a lot about what developers need to succeed. Still, I've never documented the principles I use daily to build developer tools, so I’ve decided to write it all down.
Minimize switching contexts: Interruptions matter even when it’s your tools that are doing it.
Remember, you are a chef cooking for chefs: Respect the craft. The bar is higher because you’re building products for people who build products.
Automate anything that can be automated: Automation is king. Any task that can be run in the background should.
Optimize for TTC (time to code): Just as artists need to see paint on canvas in order to keep creating, developers need to see code running in order to test, get feedback, and ship.
Be dependable: Be mindful of breaking changes. People’s services depend on your services.
Don’t bury the lede: Show me what is possible and why it matters. Don’t hide pricing, don’t use convoluted marketing language, and don’t hide the documentation.
I’ll talk about each principle in detail over the next five posts. Minimizing switching contexts is the first and perhaps the most important, and I consider all of them when designing and building any new developer-focused product.
Minimize switching contexts
The key to building excellent tools for developers is understanding how often they have to switch contexts and how detrimental that can be to developer productivity and happiness. Developers interface with four main tools—an IDE, a console, a DVCS (distributed version control system), and documentation. When they need to use tools, build systems, a library or framework, or external documentation outside these four primary interfaces, their flow can be easily broken. I’ve seen many developer tools come to market that seem to rush to creating a website, whereas a plugin is much more appropriate.
The great thing is many of these developer interfaces are open to third-party plugins and extensions. For example, VSCode has thousands of extensions offering vast amounts of customization. The hugely popular GitHub Copilot exists entirely within a third-party IDE. Vercel CD runs within the DVCS. There is quite a bit of flexibility on building rich featured products within existing developer tools. Don’t feel like you need to create a web interface to do that.
The more powerful you can make existing tools, the more effective you'll make the developer. Intrinsically, developers know that minimizing context switching is the key to productivity. While there’s an opportunity to do more research on the effects of switching contexts, this study shows that “it takes an average of 23 minutes to fully mentally return to a task after an interruption.” That’s a lot of mental energy, and productivity lost throughout the day to constant context switches and interruptions.
Why does it matter?
It all comes down to respecting your developer's time. Don't make them jump through hoops to use your product, “even minor context shifts are productivity poison.” 1Developers know their tools best and are likelier to stay in the flow when using them efficiently. We all are skeptical of the n+1 tool. In fact, "interruptions are more disruptive than we think — and affect more than just our work. With minimal or no interruptions, developers had an 82% chance of having a good day, but when developers were interrupted the majority of the day, their chances of having a good day dropped to just 7%." 2
Solve this by bridging the gap between what you provide and the environment where developers already work. For example, when we were building Vercel Comments, we decided to integrate notifications into Slack as well as GitHub and GitLab because these tools are what developers are already using to collaborate. This allowed us to minimize context switching and interruptions.
What happens next?
In the future, we won't be talking about one or two significant products that reduce context switching. Instead, the magic will be in the features that are thoughtfully automated or are powered by AI and weave intelligence throughout the workflow that will help developers stay in the flow the most. Our tools will get even more powerful. When you’re building a new website, you’ll soon be able to ask your favorite LLM to style it like Apple utilizing your favorite CSS framework and have AI create the database schema and test data. From your editor, AI will handle writing the code, opening a PR, and even do a first pass review. Developers will be able to change the entire look and feel of their app without ever switching apps.
AI is starting to democratize developer tools. We are moving development more and more towards AI as an abstraction layer to coding. Writing functions, interfacing with build systems, setting up architectures, will all feel magical, especially to people who are new to software development. It’s an exciting time to build developer tools. There are no shortages of problems to solve. By following good dx we can get there faster.
Stay tuned for more!
Automate anything that can be automated
Optimize for TTC (time to code)
Be dependable
Don’t bury the lede
https://www.nytimes.com/interactive/2023/01/23/magazine/cal-newport-interview.html
https://github.blog/2021-05-25-octoverse-spotlight-good-day-project/
All images generated with Midjourney.