A positive developer experience keeps retention high, boosts productivity, and minimizes rework. It’s a lofty goal and there’s a wide range of ambiguous guidance; for some, it means buying top of the line MacBooks for all the developers, remote work, cool company hoodies and t-shirts or worst of all: free pizza when everyone has to come in on a Saturday to debug a failed release.
Fact is most developers want to feel as if their work has a positive impact on the company and they’re fairly compensated and recognized for their efforts.
Happy developers produce higher quality work and are less likely to quit. This fosters consistency and improves the overall velocity of the entire development organization, which, in turn, reduces the likelihood of missed deadlines and supports the strategic goals of the business as a whole.
I’ve laid out some specific considerations for improving the individual developer experience that have nothing to do with pay, perks or work from home.
-
Listen to their feedback - By far the most important. 1:1 in-context sentiment is better than any tips you may read on the internet.
-
Set a clear roadmap - Everyone must know what comes next, both the big picture and their own daily tasks.
-
Include a definition of done for each item of work - Avoid creating a “breadcrumb trail” of tasks for developers to follow; when undertaking a new project or feature, the finish line, at least for the current iteration, should be easy to see.
-
Minimize context switching - Start by reducing the number of unnecessary meetings and consolidating the tools required to deliver the product. Then go beyond that: the sudden, unexpected, yet high priority tasks. If there is constant firefighting, something needs to be fixed upstream; if it’s frequent cases of “we’ve never had this feature before, but we need it tonight”, then the roadmap is useless.
-
Automate repetitive tasks and eliminate recurring challenges - Unit tests, security scans, license checks and dependency validation are crucial to ensuring high quality and secure software; because they should be a part of every release, the devs shouldn’t be burdened with manually performing this work. A universal continuous integration strategy eliminates the likelihood of gaps or skips when consistency is the goal.
-
Validate quickly It should be clear whether a change complies with the release policy and is suitable for deployment soon after it’s been submitted for approval. The tools in the stack should facilitate this, and present a Ready/Not Ready status that’s obvious to the developer and can be acted upon to minimize rework.