Things Developers Hate About Being Developers

Being a developer comes with many benefits. Often, there's the opportunity for continued on-the-job learning, a high salary, and the ability to work remotely, which means developers can live wherever the cost of living gives them the biggest bang for the buck. But programming isn't all fun and games.

Like any other career, development has its downsides. Here are the things that developers hate most about being developers.

1. Too Much Screen Time

Programming, by nature, requires quite a lot of screen time. This is the one thing that Guardian Software Systems developer Erica Gilhuber hates about being a developer:

"Even with taking frequent breaks and a bunch of other eyestrain-prevention techniques, my eyes are begging me to just stare at the clouds by the end of the day."
— Erica Gilhuber

So, how can you overcome too much screen time? Blue-light glasses can be a great help, Gilhuber said. Also, "the Windows night-light setting is awesome. Set it more intensely than you think; it won't look orange after a couple days." She also uses dark mode everywhere she can — OS settings, themes, browser extensions, etc. 

2. Clients Who Don't Understand Tech But Think They Do

Devin Ceartas, owner of NacreData, dislikes working with clients who don't understand tech. It's one thing to have family members requesting help troubleshooting printers on holidays, but in the workplace, non-tech-savvy clients can make your job difficult.

Even worse, he said, are "clients who think they understand tech and don't," especially clients who are sure they know exactly how something should be implemented because they read one thing somewhere or watched a video. "As an independent developer, my future work is largely dependent on having satisfied customers and their recommendations or references. But 'satisfied' isn't just doing what you ask me to do, competently and affordably."

Non-technical clients likely won't understand the difficulties developers face when transforming ideas into reality, he said. For example, the new feature on your website or app fits into an existing ecosystem, and "in the end, you'll judge me by the impact my work has on the totality." Then, there's the fact that the experience the client's users have may vary considerably because they work with different devices and use tech in different ways.

The latest development tools, such as frameworks, may entice clients but not necessarily the developers themselves. Ceartas said, "Yes, that new JavaScript library you read about makes the interface really pop," but the one you're already using can do almost the same thing without slowing your site down with another large code download.

Or yes, that four-tier cascading dropdown menu would allow you to access every page of your site from the home page and works great on your high-resolution laptop, but have you tried using it on the phone?

Programmers need to find ways of working with clients and managers who fail to comprehend the technical aspects of a project. "Sometimes the client and I never see eye to eye, and I just do it their way or ditch the project," Ceartas said. But often, it can be worked out by pulling out only what it is about the tech they've stumbled across that they like.

This can be something like: "I think I hear you saying that you really like the responsiveness of this example code you found. That's a wonderful example to have. I'd love to use that concept while also optimizing the page load time so the overall user experience improves.'"

Time and Money Problems

SoftwareMill Scala software engineer Bartłomiej Żyliński said it's challenging to work with businesses that "do not know what they want, but it has to be ready yesterday." Often, there's a disconnect between what a client wants and what's possible based on budget, time, and resources.

What seems like an easy job on paper might be too costly or time-intensive to actually implement. Still, good communication can ease the pains of clients who don't fully grasp the technological side of business projects.

3. Context Switching That Breaks Your Momentum

Developers must juggle different tasks. In programming, context switching means storing and restoring the state of a thread or process so its execution can be resumed later. As Over-C CTO James Sugrue said, "Context switching — it wears you out sometimes."

Context switching is necessary when stuff breaks "at inopportune moments, like weekends or when you're trying to relax, [or] when you're minding your own business and you start worrying about some bug," Sugrue said. Simple but effective strategies, such as maintaining a balanced calendar, can reduce the impact of context switching.

4. Depending on Technology and Teams for Success

While technology can make a developer's life easier, it can also present hurdles. Dave Fecak, founder of both Resume Raiders and the Philadelphia-area Java Users' Group, laments that, as a developer, he's not in full control. There are dependencies on things he didn't build, including tools, APIs, open-source products, other people who have access to your code, etc.

"No matter how well you do, there's a chance somebody else can screw it up," Fecak said. The technology and processes that allow development are a gift and a curse. Regardless of your programming prowess, you need to depend on many outside factors that ultimately impact projects.

5. Implementing Someone Else's Designs

Programmers may seem like magicians to non-developers, but they're not clairvoyant. Vedcraft founder Ankur Kumar explained that what he hates about programming is implementing "designs thought of by someone else." There can be a disconnect between the idea on paper and what's possible in the real world.

This is further complicated when working with clients who don't understand or respect the technical limitations that developers face. Similarly, working with someone else's code, and especially legacy code, can be a huge pain point for devs.

6. Old Coding Practices That Become the Newest Thing

Although programming has risen quite a bit in popularity, it's by no means new. Mad Botter founder Michael Dominick is bothered by how some ancient coding concepts resurface as new ideas.

"In general, I love software development, but the one thing that has begun to irk me over the years is venerable old ideas being presented as brand new."
— Michael Dominick

In particular, this has been a trend with functional programming, something that has been around since the 1970s "but was recently rediscovered by developers of my generation and younger," Dominick said. It's great to see these older technologies being embraced by new developers, he said, but "there's also a lot of value in understanding the fundamentals of where these methodologies and technologies came from within their historical context."

7. Doing Someone Else's Job

It's not uncommon that the work you're doing after signing your contract differs somewhat from the job description. But doing someone else's job is another story.

"I hate doing my manager's job," Abstract software engineer Pam Selle said. She's seen managers push all organizing work onto individual contributors rather than providing direction about what an individual contributor needs to do.

"If managers manage, it lets me work as an engineer, which is why I have the job I have."
— Pam Selle

Generally, a manager is in a managerial position for that reason: to manage. However, many individual contributors are forced to manage or even perform their manager's job for them.

It's often said that employees don't leave companies; they leave managers. Having to do your manager's job in addition to your own may eventually lead to burnout.

Selle said there are solutions to this problem. "As much as large corporations get flack for, say, having a 'Jira of Jiras,' managers working out how to keep a flow of work coming down the pipe for engineers really allows engineers to focus on the engineering and do better work because of it."

Can You Live With the Downsides?

With promises of high-paying salaries and because almost every company is a software company, whether by design or not, programming continues to be an enticing career. But like any other job, development isn't without its downsides.

Whether it's clients who don't understand technology, the frustrations of implementing someone else's (sometimes sloppy) designs, too much screen time, or dealing with poor management, something will likely come up that will make coding seem like less than a dream job. However, if you're willing to put up with some annoyances and find solutions to mitigate problems, it can be a satisfying career choice.