As I reflect on the projects I’ve worked on, I’ve come to realize that the two biggest correlating factors for how much I enjoy working on a project are how well I understand the users and how quickly I can receive their feedback. The best example of this was when I was working on a market analysis tool used internally by traders at Morgan Stanley. I would speak to traders directly to understand their workflows, get feature requests, and collect feedback on the features I shipped. The near instant feedback made the work feel like it was delivering real value. Plus, while I’m nowhere near a professional trader, I have experience trading stocks and looking at large amounts of data, which made it easier for me to put myself in their shoes when I had to make any design decisions. Incorporating this realization into my thoughts on what kind of projects I wanted to work on in the future, building tools for developers (DevEx) became a standout choice.
What is Good DevEx
To me, the ideal developer experience gets rid of anything besides the developer’s core responsibilities. Any competent developer can set up a preview instance of the feature they’re merging or reviewing, but why would you want them to spend any time doing that? When deploying to Vercel, it will automatically create a preview deployment. The developer doesn’t have to think about it at all; they simply make a PR and move on to their next task. Developers get passionate about tabs vs spaces and other such nonsense. If these debates are fun for you, go ahead, but at work, developers shouldn’t be thinking about basic formatting or code style. Setting up a formatter like Ruff or Prettier (and enforcing it by blocking non-compliant merges) allows developers to focus on the code and not meaningless formatting decisions. It also removes the extra mental bandwidth of having to sift through formatting noise when reviewing PRs. One of the most frustrating experiences when trying to ship quickly is having your PR blocked by an unrelated test failure. Eradicating flaky tests would be the ideal, but from my experience working with massive code bases, at a certain scale, they become inevitable. Having the developers investigate and resolve the issue themselves is a massive waste of time, especially if the failure is in a part of the code base that they have no experience in. At Morgan Stanley, we had a dedicated team we would call to deal with this so that we didn’t have to decide between delaying our features or getting into the habit of ignoring failing tests.
My Experience Leading DevEx
Unfortunately, dedicating time to developer experience improvements can be a hard sell on small teams. Clients most likely don’t understand or care about it, and product managers, while more understanding, have higher-priority tasks they want completed. This leaves developers to advocate for themselves, but understandably, most are uncomfortable with or incapable of this, which results in them putting up with a subpar experience, thus slowing them down and accelerating burnout.
While I never saw myself taking on this advocacy role, my never-ending desire to improve my workflow has led me into it at my current company. I started by suggesting some improvements to senior members of my team, but soon found out that was not going to be enough. Everyone is busy and has their priorities, which is understandable, so I tried a new approach. I was getting sick of formatting noise in PRs and inconsistent style in the code base caused by different team members using different formatters, so I created a PR to add a GitHub Action enforcing Ruff formatting and linting. To adhere to my philosophy of “good DevEx is one you don’t need to think about,” I also added a pre-push hook so that developers did not need to worry about manually running Ruff if they didn’t have it configured to run on save. I ran the PR by the team members who work on the codebase the most, and they were all happy with the changes, so I got it merged. It’s been a few months since then, and now our codebase is stylistically consistent and PRs are easier to review because you don’t have to deal with formatting noise.
Implementing my ideas is great, but I wanted to know what issues my team has been running into. We use Jira, so I created an epic for DevEx and added stories for each of the improvements I had jotted down in my notes. I asked the team to add any ideas or issues they ran into, as well as to leave comments on any of the stories that they agreed or disagreed with. The feedback has allowed me to reflect on my ideas as well as gather new ones. Now, anytime we have a few cycles available or an issue becomes large enough to prioritize, we can work on it instead of collectively putting up with a subpar DevEx. These are just the first steps I’ve taken, but anecdotally, they’ve been working well.
Going forward
So far, I’ve been focused on optimizing our usage of existing developer tooling like Docker, GitHub, and Sentry. Which, for an organization the size of which I’m currently at, is realistically all that needs to be done. But in the future, I would love to work on improving challenging workflows that require custom solutions like building out CLI tools, editor plugins, or contributing to open source tooling.
Developer experience is easy to overlook. Developers are not exactly known for their ways with words, which are almost certainly required if you want to get any meaningful amount of sprint time dedicated to working on something the client sees no direct benefit from. However, ignoring it will lead to a slowdown in developer productivity, and the annoyance of using subpar tooling will lead developers to burnout faster. By having strong advocates for developers and dedicating time to improve their tooling, you free developers to do what you hired them for: shipping features.