Being a software developer challenges your technical abilities, your ability to solve problems, and your ability to be creative. Additionally, it's well-compensated and allows you to work remotely. These are all reasons why "Software Developer" is often considered as one of the best jobs you can have.
But that doesn't mean being a software developer is free of frustration. On the contrary, there's quite a big list of things that rub us the wrong way and heavily test our patience. Often, these are small things that make our lives significantly harder or that are "just wrong."
This is a list with 5 of the most frustrating developer pet peeves and how you can avoid them. This is by no means a comprehensive list, but we believe that these pet peeves are shared among a large group of developers.
Heisenbugs
It's no mystery that developers don't like bugs. But there's one particular type of bugs that can make a developer's blood boil. Heisenbugs. These are bugs that either disappear or change their behavior when you try to catch them.
Heisenbugs are named after Werner Heisenberg, the physicist who discovered that the act of observing a quantum mechanic system inevitably alters its state. Similarly, the act of discovering a heisenbug seems to inevitably alter its state. Infuriating.
Heisenbugs are pernicious bugs without a clear solution. Sometimes, they happen because you used the value of a non-initialized variable, because you followed an invalid pointer, because cosmic rays are affecting your hardware (no joke), etc.
The only way to get rid of a heisenbug is through very careful, slow debugging. The best way to prevent one is through good coding practices and careful, consistent refactoring of your codebase. Ideally, you should encounter fewer heisenbugs as your codebase grows, not more.
Everything is Top Priority
Working on a project where all features are important is a frustrating experience. Everything needs to be done as fast as possible and nothing can be cut out. You're trying to do it all and your days are whirlpools of chaos.
But it's impossible for everything to be top priority. It's just a sign that you, your team, or your client hasn't prioritized things properly. A good way to solve this problem is by using a priorities matrix like the Eisenhower Matrix. Divide your features into the following categories:
- Important and urgent
- Important, but not urgent
- Not important, but urgent
- Not important and not urgent
Be honest when doing this exercise. Sometimes, there are things you'd really like to do, but they're not important and not urgent. They're just nice. These are at the bottom of the priority list. I'm sorry.
At the top of the priority list should be the important and urgent things. Do these things ASAP. Then, you should schedule dedicated time to do the important, but not urgent things. Finally, see if you can delegate the urgent, but unimportant things. If not, do these after you've done the important and urgent things.
Spaghetti Code
Spaghetti code is unstructured code that is difficult to maintain. This is usually caused by changing project requirements, a lack of programming style rules, and plain old inexperience or lack of ability.
A subset of spaghetti code is poorly indented code. While all developers have their own way of indenting their code, sometimes you come across a codebase that is difficult to read simply because of the way it's indented. This always tickles a developer's rage bone.
Spaghetti code is better prevented than untangled. This requires a plan of action before you start writing code, as well as ruthless diligence, constant unit testing, and software refactoring.
It also helps if you stick to clean code principles such as KISS and DRY. While these principles shouldn't be seen as the be-all and end-all, they certainly help keep a codebase tidy.
Estimates Are Deadlines
Ever given an estimate to your team lead or client, which they then promptly started treating as a hard deadline? Most of us have, and it's not a nice feeling. This is particularly true if you've shared the estimate with multiple people. You'll start treating the estimate as a deadline yourself, simply because you don't want to let the others down.
The problem with an estimate is that you're setting expectations. This feature should be done by Wednesday, because you said so. The more precise the estimate, the more people will treat it as a deadline too. You're seen as the expert, and an expert should be able to estimate things correctly.
You just have to be really careful when giving estimates. Give a time range or, even better, give progress updates instead of an estimate. Think of the "done when it's done" video game companies adopt. They do this to avoid the crushing pressure of a deadline as best they can.
Poorly Written Documentation
How is a developer supposed to know how to use or contribute to code when the documentation is unclear? Poorly written docs slow developers down significantly and few developers like digging through the logic of a codebase to figure out how it works.
You can get around this with practices such as writing your README first. Additionally, make sure your docs give a thorough description of your functions, methods, and components. Documentation should be the final source of truth.
Good documentation can make you stand out too. Take a look at Stripe's docs, for example. Clean, thorough, and easy to understand. Thousands of developers visit their documentation on a daily basis to understand how they can use Stripe's products. It's why developers love Stripe.
This was a list of 5 pet peeves commonly shared between software developers. Are you frustrated with the above-mentioned things too? What other pet peeves do you have? Let me know with a comment below 👇
Top comments (1)
It resonates to me. The thing that it really comes down to is this way of thinking of everything as urgent and necessary. Code gets done as an MVP, except you will never have time to fix that code or put tests on it. The MVP isn't actually an MVP but the whole product, it's the BIG BANG release.
What seems difficult for most people to understand, is to think of a product, breaking it into small subsets of functionality. Thinking in user journeys instead of the "whole solution". This is what makes most sense to me.
I really dislike developing lots of features for weeks while nobody is using it in production. I get no feedback from users, plus there might be things broken and we will only find that out on the release day. This is the kind of thing that blows back directly into developers faces.
With time and experience I have learned that when using this "waterfall" process, that is usually disguised as agile, time is being wasted into features that nobody will ever use.