Developer Pain Points
All happy families are alike; each unhappy family is unhappy in its own way. Leo Tolstoy, "Anna Karenina"
Corollary: "All happy developers are alike; each unhappy developer is unhappy in her own way."
Hot take, but my rendering is this: there is a known happy path for most developers in broad strokes. Then, developing upon a given Developer Journey or Developer Persona, there are details.
But the broad strokes appear more robust.
It's in the unhappy paths and their idiosyncracies that make the space challenging.
It's also what creates opportunities to unseat legacy giants who have lost their way by taking their eyes off of developers and their needs.
Here are some pains to start the conversation, in no particular order.
I include some spicier takes, things I haven't heard from candidates or developers directly but have indirectly and through revealed behavior.
Fears of Slimmer Job Prospects
Yes, in the age where Twitter is dominated by the 1% developer who has to fend off the waves of recruiters attacking them over LinkedIn, there are developers, particularly those early in their career (and potentially those later, although this I don't know as well) who want to make sure they aren't made irrelevant.
To me, it's easy to overlook them, particularly in specific communities.
But people want to become developers and are willing to make these changes in their educational or career arc; but there's an underlying concern of getting sidelined by the hot new tech or being pegged in a dying segment.
Cognitive Overload
This won't come from a developer survey or an in-person interview, but various patterns do emerge based on complaints. This can come in the form of context switching, latency from doing one thing for another thing, bad documentation, poor or inconsistent patterns in naming conventions, illegible mental models.
Understanding the "what" and "how" a system or interface works takes time; and when the domain model is fuzzy and unclear, this creates pain.
Syntactic Convolution
This bucket can capture a wide range of things, but it means that the syntax of writing the necessary code is unnecessarily convoluted for the developer.
This varies by environment and developer; but often the smell test can be found in whether doing so increases the Cognitive Overload.
This typically applies to the developer writing the code (which is why frameworks or platforms will compare the difference in lines of code of the old way vs the new way)
Adjacent Work
The journey for many developers to ship from localhost (gtfol) often takes them to places outside of just writing code in their local IDE.
This is partly why the "shift left" movement has so much momentum: lots of pain in the adjacent areas in the life-cycle.
Illegible Telemetry
Bugs happen, but when a tool makes it hard to troubleshoot, the pains can be enormous.
The scope of this can range from error messages in the console which don't make sense, to production logs that...don't make sense.
Refactoring Tech Debt
Reviewing existing code, whether one's own or someone else's, with the goal of not only understanding it, but reducing tech debt, feels painful.
It doesn't move the needle in terms of completing new features.
Sometimes it doesn't even reduce existing known bugs.
Testing
The testing process itself is often a pain because it feels like "adjacent work" -- work that isn't core to the business at hand.
Testing, however, is actually core to the business, but it's not particularly fun.
Yet it's often part of the developers workflow.
Third-party Integrations
Learning about other products, their API, their documentation, and then adding the infrastructure to integrate to those services, again, can feel painful because it seems outside of the core.
But for an increasing number of software products, the ability to integrate to these other solutions is core to their growth and functionality.
Writing Repetitive Boilerplate
Getting started with something that involves alot of pre-existing or redundant code rather than just working on the core introduces boredom (a pain) but also a need for high-levels of attention because sloppy boilerplate can break.
What are some common themes?
Now that we've listed some common, specific pains, what can we see?
First, in nearly every case, for every problem type there are solutions dedicated to addressing those problems.
This makes the developer-facing product space challenging -- because developers experience the problem often solve their own problems. This can mean there are multiple solutions in the market if the problem is common enough; and some of those start off as free open-source solutions.
This competitive nature as well as the now often high business return can often make such products need a product manager.
The second is that anything that takes developers out of "the zone" can be a pain.
This is a bit of a "fuzzy" category, which is where I think a product manager's judgement and sense of the product fits in. Many of the pains fall into this category, and it largely makes sense: the primary job to be done for a developer is to have the greatest impact in the least amount of time.
They aren't measured on lines of code or time spent. In fact, a developer would largely prefer to complete something that could otherwise take 10 months and do it in 10 minutes and then chill out.
The third, again, sort of broad but still a consideration, is "boring."
They often want something that intrigues them, like problems that interest them; you may often find that jobs with old technology and uninteresting problems have difficulty attracting quality developers.
Documentation and Content Solutions
A bad developer experience can't be completely addressed outside of the product.
In the end, the exponential and recurring growth must be based on core features of the product.
That being said, taking an audit of product concerns still need a solution that is documentation and content first.
This isn't a bandaid.
It is a way to create the ideal specification for what the product should be.
So if you want to solve developer pains, improve your products, and accelerate the time-to-value of your own engineering efforts, the product-led developer docs approach helps shape this.
Read more here: Product-Led Developer Content