5 things I hate about being a developer

This article was originally published on .cult by Patrick Zawadzki. .cult is a Berlin-based community platform for developers. We write about all things career-related, make original documentaries and share heaps of other untold developer stories from around the world.

Software development as a career has exploded over the last couple of years. And with the popularity of boot camps and lateral movements, it’s a great time to get involved.

Yet behind all the fluff and pizazz of software engineering, there’s a side that’s not so glamorous. And if you’re like me, you probably want to know the dirty truth before committing time, energy, and money.

With any job, there are good days and bad days. I like to say that if you enjoy your job at least 70% of the time you’ve got a great gig. Personally, I love development; I couldn’t be happier, but that shouldn’t stop me from addressing the other 30%… those bad days, those recurring problems, those fist-through-the-wall moments.

There can be lots of problems with any job over time, but with development, there are a few recurring ones that always seem to appear at some point in my career. So let’s just talk about the top five worst things about being a developer (in no particular order).

1. Debugging problems in a codebase you don’t have direct control over

Bugs aren’t something people want to find. It’s great when you do, but a bug ultimately means that somewhere along the line, a step was skipped or a process was misunderstood. In the context of those types of bugs, they are the best subset of all bugs because at least we can control them. We can find them in the codebase and fix them. But what about bugs imported from a library or bugs imported from a third-party vendor?

Debugging issues you can’t easily access is arguably one of the more challenging and frustrating parts of being a developer. Maybe it’s a library you imported, but the library has been minified or compiled making it unreadable to the human eye. Thankfully this library is open-source…right? Not always, and that’s the worst of the worst in this category. Now you need to spend additional time isolating the problem, in an external system, in a reproducible way so you can send this problem to the owners of said library, in hopes they can fix it on the schedule you need it fixed.

These are challenges faced by many teams on a daily basis and ultimately aren’t avoidable. You can mitigate these types of concerns by opting for open-source or homegrown solutions when making the choice for your codebase. But if there are no options, you’re cornered and have to bite the bullet.

2. Maintaining an old project, without any contextual knowledge

Imagine this, you are a trained and experienced survivalist deciding to join a TV show kind of like Alone with some twists. You’ve done this type of thing for thousands of hours, you’re an expert at what you do, and have a proven track record of success. Here’s the twist, this season, you get randomly picked up and dropped into an area completely unknown to you.

To be a successful survivor you need to know where you’re going, what it’s like there, and maybe even some methods for success. You need to know why you’re going to bring certain items, how they could be of use, and maybe even talk to some fellow survivalist buddies who have been in an environment like this before. What worked, what didn’t work, and maybe some tricks of the trade that are unique about this environment. But nope, this season of “Alone+” is going to test your skills to the max.

Being a software developer dropped into a new project, without any context or without anyone who you can ask questions to is pretty similar to this. The thing about software is that there is a multitude of ways to approach a single problem and sometimes the path of decisions someone took to choose their approach was systematic and deeply debated.

Being on a project without any context or people you can ask questions to means that you may encounter odd things and struggle to understand why they’re there. Was it a developer being lazy? Was it a workaround or hack they needed to do to make a deadline? Was it due to some exterior constraint that forces the code to be designed this way? It’s impossible to tell, it’s simply lost in the void. The twist to all of this is that you still need to learn how to succeed in this environment since your own success as a developer depends on it.

These types of projects can, unfortunately, push a lot of developers to their wit’s end and cause some people to hate their jobs. These projects are slow to start and seem like trying to blindly navigate a minefield. This is why well-written code and code with up-to-date documentation is so important.

If you’re reading this you’re probably a developer or looking to become one. Try to be the one that makes note of these oddities in your codebase so the next person who interacts with it will have an easier time piecing things together, whether or not you’re there to answer questions.

3. When people who DON’T understand software development make the decisions

A typical makeup of a team in the software world is software developers, a project manager, and some type of product owner. Maybe the project manager and product owner are the same people, but ultimately there is someone writing the code and someone with a vision for what they want the product to be. In most scenarios, the person with the vision is the person who takes stakeholder meetings, establishes timelines, and ultimately “sells” the product to others.

The relationship between this type of individual and the developer is pretty crucial to a project’s success and sometimes the developer’s joy on a team. All too often developers are seen as “code monkeys” on projects and requirements are simply pushed down to them without much back and forth discussion, and sometimes with unrealistic deadlines. This leads to rushed products, unmet expectations, and ultimately a failing product because it doesn’t do what the business had in mind and constantly breaks.

As a programmer, finding a team that has a balanced and working relationship between project managers/product owners is important to not only the success of a product, but the joy of the programmer in their role.

4. Not having enough uninterrupted time in your day

There are a lot of great tasks that encompass the role of the developer, and most developers tend to cherish these parts of their day-to-day jobs. The ability to quickly create a vision and turn it into reality within minutes is one of the more addicting parts of being a programmer.

Another really amazing part can only be described as “the flow”. It’s the sense of almost complete immersion that one experiences when getting deep into their work and thought process. It’s a really common part of getting into a place of deep productivity and progress and a part of programming that many developers need to be effective.

In the modern work world, however, it’s easy to be constantly added to meetings or asynchronously messaged with questions/concerns throughout the day. The fickle thing about “the flow” is that it can be challenging to enter, but easy to be pulled out of.

Additionally, software development is a highly individualistic type of job, in the sense that you’re an individual contributor who’s given tasks and problems and expected to complete them. With constant asynchronous communication and meetings back to back, it can be challenging to find enough time to get into the flow and stay in the flow long enough to complete the tasks at hand. The key here being an “uninterrupted” period of your day, because even context switching to fit in small tasks throughout the day is overly draining.

Finding a gap of uninterrupted time, maybe 3-4 hours ideally where you can get completely into your zone and focus on your work is incredibly important. Days jam-packed with meetings or, even worse, meetings sparse 30-45 minutes apart are detrimental to the productivity and effectiveness of many developers worldwide.

5. Imposter syndrome

For many programmers worldwide, it’s unfortunate to say that sooner or later they will experience some level of imposter syndrome during their careers. Maybe it’s starting a new project, joining a new team, or just a sudden mix of bad emotions in a day that makes self-doubt creep into your decisions and affect what choices you make throughout the day.

According to Merriam Webster, imposter syndrome is defined as:

… a psychological condition that is characterized by persistent doubt concerning one’s abilities or accomplishments accompanied by the fear of being exposed as a fraud despite evidence of one’s ongoing success.

It’s quite a counterproductive and contradictive scenario that many struggle to shake. Some people experience it often and some never. Some people experience it more frequently than they’d hope. Either way, the great thing about the software community is that many have experienced it to some degree at some point in their career and many people are willing to help.

Summary

Software engineering is a great field with many benefits for many people and it’s an interesting field to be in with seemingly endless opportunities. However, every field and career has its pros and cons. Most of the time people only talk about the pros of a career but rarely the cons, let’s be honest, sometimes the cons can outweigh the pros. And the cons for some people may not even be cons for others.

Regardless of your situation, I hope that seeing some of the negative sides from a software developer can help provide perspective to anyone thinking about joining the field and anyone who is just entering the field. This isn’t meant to scare anyone—more of a little light shining into the dark corners that aren’t often shared. After all, being aware of issues and things that may affect you is oftentimes better than not being aware.