DevEx Principles: Chef cooking for chefs
My Principles for Developer Experience
Over the past 15 years shipping products for Heroku, GitHub, and Vercel, I've learned a lot about what developers need to succeed. I’m finally documenting the principles I use to build developer tools. This is the second article in the series.
My principles for Developer Experience
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: Don’t hide pricing, don’t use convoluted marketing language, don’t hide the documentation. If your tool is faster - how much faster is it?
You are a chef cooking for chefs
“Cooking is a craft, I like to think, and a good cook is a craftsman—not an artist. There’s nothing wrong with that: the great cathedrals of Europe were built by craftsmen—though not designed by them. Practicing your craft in expert fashion is noble, honorable, and satisfying.”
- Anthony Bourdain
Developers are masters of building applications, so when you’re building tools and experiences for them, you’re cooking in their kitchen. You can marvel at the delight you bring to the experience because no one can appreciate your hard work more than another developer. Developers can spot inconsistencies, antipatterns, and hurdles a mile away, so you must pay close attention to these details. At the same time, they know the challenges, understand the concerns, appreciate the details, and can provide crucial feedback to make your product even better.
Why does it matter?
Dark patterns won’t fly.
Since we’re all chefs here, I’m going to be more candid about how I speak on this topic, so buckle up. I want you to repeat this mantra: dark patterns won’t fly with developers. Every developer tool I've used and worked on struggles with this issue. If you’re utilizing anti-patterns, or worse, dark patterns, they will underperform and sow distrust between you and your customers. Recently, I was trying to opt out of an email from a database service, and buried at the bottom of the message was an unsubscribe link in 9px #333 font. I clicked on the link, and they made me retype my email address in a textbox with a grayed-out button to unsubscribe. While this may prevent most users from successfully opting out, this will just annoy another developer. In this example, we know there was a decision along the way to make the process more challenging. Do they not respect my time? Developers using your product have probably been forced to implement similar tricks, and they know exactly how they work. If you use these patterns, you’ll find out exactly what developers think of your product because they’ll stop using it. Be very skeptical about applying any growth hack strategies to a developer product without considering how it impacts the user experience.
A word for the weary, you will fight this at every level of your organization, but it’s worth the fight. Here’s the thing, you can implement experiences designed to grow your user base and drive more adoption without utilizing these tactics. Look to your usage data to find out where your opportunities are. Chances are that developers want to use your product more, so find those parts of the product where upgrades are intuitive and natural.
Performance is vital.
Last weekend I spent an afternoon refactoring my personal website to reduce the load time by 200ms. I was excited that I could shave that much time off. To put that in perspective, 200ms is roughly half the time it takes to blink your eyes, and as a developer, it matters. There is a famous Steve Jobs quote where he explains the importance of increasing boot time, "well, let's say you can shave 10 seconds off of the boot time. Multiply that by five million users, and that's 50 million seconds every single day. Over a year, that's probably dozens of lifetimes. So if you make it boot ten seconds faster, you've saved a dozen lives. That's really worth it, don't you think?"
Because of how software is developed, those seconds matter. Each piece of code depends on hundreds of thousands of other pieces of code. When you do thousands of renders or compilations, time can easily be a huge barrier to productivity. If you’re developing for the web, I cannot stress this enough, spend time with your telemetry and get to know where you can optimize. Check-in with your application’s web vitals regularly, or look at your Real Experience Score after each deployment if you’re using Vercel.
Feedback from a developer is (more) amazing.
Don’t get discouraged if you’ve made it this far and feel like developers are difficult to build for. There are huge advantages to making developer products that you can find simply by listening to their feedback. Developers will help find and triage complicated problems, and they have a higher degree of specificity while knowing how to shine a spotlight on what’s not working. They will even spend time writing GitHub issues about the bugs they find and include steps to fix them or even open a pull request.
Famously at GitHub, we received an open letter via a repository called Dear GitHub. This letter was authored by a group of open source maintainers, and it contained some of the most insightful feedback I have ever seen in my career. When this kind of feedback happens, you don’t need to be delicate with it, but you do have to respond. And it was abundant, as it usually is with developers who are not shy about articulating each problem. GitHub responded by shipping. We launched a project called Papercuts, led by my team under Luke Hefson. Since the feedback was generous and abundant, we had to find a way to focus it. We wrote a heuristic to help us quickly identify what we could ship with our resources. The heuristic considered technical feasibility, design scope, and impact to the community. The team shipped hundreds of small to medium fixes to improve GitHub products, greatly improving the problem - all because we listened to the gentle nudges of an enthusiastic developer community.
Openness is the building block of great software
In 1993 John Carmack and John Romero created Doom. In 1994 mods started to take off, which allowed players to customize their experience. Pretty soon, Doom had the largest mod-making community, which changed how games were built. People started trading mods, and they were able to add hundreds of new, creative levels to the game. They built tools to improve how to install and launch new mods. Mods made the game more fun and approachable, and Doom’s creators learned a lot about how people wanted to play. They made the characters more empathetic, sensitive to their surroundings, and human just by opening it up and allowing everyone to build with the game’s data.
It’s easy to be very defensive around your product. What if your customers take their data elsewhere, or bypass paid features? I’m here to urge you to do the opposite. Developers love to build their own solutions. There is no way your product will be able to cover every use case, language, or format that developers need. By creating a tool that is open by design, you enable the community to take what you’ve built and extend and enhance it in ways that you could only dream. Like the small team at ID Software realized in 1994, opening access for developers and providing building blocks to create their own experiences will only make your product better. I will always put my trust in developers to build amazing things.
Build for the love of the craft.
To be a craftsperson, you have intimate knowledge and respect for what it takes to build things. Developers will notice the little things, the things that take time to get just right. This can be anything from minimizing the footprint of your js includes to delicately crafted error messages or even the pixel-perfect rendering of an icon. You do these things not just because you want them to be done right but because you know that it may also catch the eye of another craftsperson.
Have you ever clicked view source and found an ASCII art image buried deep in the code or come across a 404 page graced with style and sass? When you use a thoughtfully designed CLI where the developer has spent time coordinating colors and designing useful prompts, you know the tool will feel good to use. It's a nod to fellow developers and a celebration of our work. It says, “hey, this product is for you, and you’re going to have fun using it.”
These details are what make our community so great. They separate the tool that you have to use from the one that you want to use. That’s how you’ll win more developers' hearts and minds.
What happens next?
Being open and collaborative is the only way we win going forward. With new AI-powered tooling, expect to see a new type of chef enter the kitchen. Let's call them sous-chefs. We’ll need to build a new suite of tools and processes to accommodate this group. The way that we’re interacting with code is already changing, thanks to GitHub Co-pilot. Expect this to continue. Developer tools must embrace this change and adapt to a new understanding of developers using their software. This goes beyond just re-thinking our documentation but providing interfaces that are flexible to new types of inputs. Just look at how much easier RegEx is with natural language parsing. It’s not just about making things easier but also being more kind to varying skill sets. Frankly, how many developers even really have a full grasp of RegEx syntax anyways ;)?
Sure, the definition of developer may be changing, but what if we welcome this change? Open source is the largest team sport. We get better if we all do this together.
Stay tuned for more!
Automate anything that can be automated
Optimize for TTC (time to code)
Be dependable
Don’t bury the lede
All images generated with Midjourney.