10 very annoying things about being a developer
Development · Feb 17, 2022
Being a developer is awesome. But if the job were perfect, everyone would do it.
Most developers I know love the challenge of both writing code and making sure they write it properly. Like a sculptor who chisels stone (the code!) into a beautifully crafted statue (the perfect app or API), you could say a developer is a modern-day artist who uses technology as a toolbox and the customer as a muse.
It’s not all roses, though. Like any other job out there, there are inevitable frustrations that await you as a developer no matter what workplace you find yourself in.
“What grinds your gears?”
Out of curiosity, I recently conducted a very informal survey with some of the developers in my personal network to get a sense of what annoys them most about their day-to-day work. In no particular order, here are some of the responses I received:
“Not knowing where to start when I join a new project or team.”
“No documentation about how something was built or why it works this way.”
“Inefficient frameworks that require a lot of complex code or boilerplate.”
“Dependencies change without notice.”
“Having to maintain someone else's mysterious code after they leave.”
“Things that should be automated aren’t.”
“Comments in the code don't make any sense/aren't up-to-date.”
“Other teams create their components or processes in silos.”
“The review/CI test/build process is slow.”
“There's just too much to learn and not enough time.”
Maybe some (or all – or none) of these pain points are familiar to you, or maybe you have some of your own frustrations to deal with. Whatever the case, it’s hard to deny that these types of setbacks increase blood pressure, decrease productivity, and generally hinder the overall developer experience.
Eliminating single points of failure
After thinking about the responses from my developer network, I realized that a good chunk of the gripes could be summed up using three overarching themes: findability and ownership, knowledge sharing, and process efficiency. I’ll also go out on a limb to suggest that if a workplace is experiencing weakness in even just one of these three areas, a host of issues will inevitably crop up – just like a single point of failure that threatens to obstruct a smooth experience for all developers.
Findability and ownership
How easily can developers find the software, services, information, or resources they’re looking for so they can do their job? Are they able to quickly identify the owners of APIs, repositories, or applications if they need to ask questions or suggest updates? If developers are left to just "figure it out", something isn’t quite right.
Centralized systems that provide visibility into what’s happening across the organization can dramatically improve findability and clarify ownership when it comes to the elements developers depend on to accomplish their daily work. For example, TELUS Digital has invested in building internal tools (like a software catalogue and tech radar) that help team members take the guesswork out of determining what’s what within our broad technology landscape.
The benefits are fairly self-evident when an organization puts a centralized system in place to tap into the collective knowledge and know-how of its technical community (we don’t store the code in team members’ heads, so why would we keep the information about the code locked up there?). Surprisingly, many organizations lack the means for employees to share their invaluable technical knowledge broadly across teams.
Here’s a common scenario. Imagine you’ve been asked to take over the codebase of an existing product. Would you rather:
desperately scour code comments, documents on various shared drives, and emails in your inbox for clues about how things work, OR
visit an easily searchable site where all product information is in one place?
Option 2 is your probable choice if you want to reduce developer frustration, not to mention the chance of hiccups for the product’s end users. That’s one of the reasons why more and more software-centric organizations (including TELUS Digital) are embracing well-designed developer portals as their one-stop shop for internal technical knowledge. A developer portal is even more effective when its governance model allows for and encourages content contributions from across an organization’s development community.
Poorly thought out processes (or a complete lack of them) can cause real friction for developers. Take the CI/CD pipeline as an example: if problems with my code are randomly discovered long after I’ve submitted it, and it gets sent back to me to fix while I’m tackling a completely different project, how annoyed do you think I’ll be? Not only will the code be difficult to troubleshoot because it’s not fresh in my mind, but I’ll be forced to pause the progress I’m making on my current initiative. This type of “context switching” has a high price that many organizations pay in the form of lost productivity.
Developers directly benefit when an organization invests in building new processes whenever it makes sense, automating them whenever possible, and making continuous process refinements based on measurable results. Since we’re talking about CI/CD pipelines, a great example of a process automated at TELUS Digital to make developers’ lives a bit easier is deployment risk assessment: our non-blocking Risk Engine tool provides team members with automated recommendations based on the amount of risk detected in each deployment.
Finding the golden path
Many things could – and often do – go wrong for an organization making the long journey towards reaching an optimal developer experience.
But is there a secret to success?
Maybe it’s not as complicated as we think. Developers are happiest when they’re able to access the tools, knowledge, and processes they need, at the time they need them, in a way they expect. Follow this golden path, and I bet that list of developer annoyances would shrink – fast!