In honor of Valentine's Day this year, I wanted to write about some of the things that developers love. But since developers disagree so often on best technologies and practices, I thought I'd write instead about what developers love...to hate. Because we all know that nothing unites us quite like righteous anger. So I hope you have a good February 14th, because now you are going to feel the hate for these 14 things that affect developers' lives.
1. “Just one more thing”
I know we’re no longer in the age of waterfall where every single thing is planned before coding starts and nothing can change, but the amount of add-ons for software products is getting ridiculous. I’m talking about unclear or last-minute requirements, incomplete or missing user stories, and feature creep.
“The first 90 percent of the code accounts for the first 90 percent of the development time. The remaining 10 percent of the code accounts for the other 90 percent of the development time.”
—Tom Cargill, Bell Labs, from the book Programming Pearls
Tom Cargill's quote is so true for many projects today. Teams finish the core work on a software project, and once people actually start using it, the endless requests come in. “Oooh, now let’s make this feature do this!” “I hate this feature that I fought so hard for in the requirements stage. Why did we build it?”
It’s death by a thousand papercuts. It’s like this story I heard about some soldiers in WWII who didn’t need morphine after being shot because they expected to be shot, whereas soldiers who weren’t expecting to be shot needed lots of morphine and were in a lot more pain. Same principle.
Having too many of these last-minute additions to a project can often lead to feature creep. To prevent this, a team needs to understand an idea most developers truly believe in—the Unix philosophy. It’s pretty simple: Just do one thing really well. Software, or at least the components of a software product, should do the same. One product can’t please everyone.
Image credit: Developer Memes
2. Poor QA
Developers build code; QA breaks code. It’s not hard to see where the conflict originates. Imagine being five years old, you’ve just finished the Mona Lisa of wooden block towers, and here comes your jerk of a younger sibling. They represent the QA tester in this fantasy, who rams into your tower at full speed, destroying the masterpiece you’ve spent the last 20 minutes carefully crafting. Do you understand? That’s the kind of trauma that QA can bring about.
Maybe that’s overdramatic, but there’s no denying that truly bad QA can be extremely annoying and waste significant time. The worst testers will:
Create bug reports for issues that are caused by their own unique environment
Prioritize every bug as a showstopper
Robotically follow scripts and get stuck on non-issues while missing real issues
Focus on minutiae while major issues remain untested
Leave out key information in bug reports
“It’s not a bug—it’s an undocumented feature.”
- Anonymous developer
Frankly, they should know how to code too, but if they don’t, they shouldn’t try to recommend where to fix a problem because they built an application using Basic this one time.
But let’s remember that there are a lot of good testers out there, and they are worth their weight in gold. If a good tester is annoying you, it’s probably a good thing. They force you to become a better developer, and they’ll save your butt when you screw up royally.
Image credit: Dumb and Dumber, New Line Cinema
3. Interruptions
Developers don’t wear headphones because they enjoy music more than other people. They do it to shut out distracting noise and to prevent interruptions. It’s in lieu of having a sign on the back of their head that says, “LEAVE ME ALONE! I’M CODING!”
Interruptions are detrimental for all knowledge workers, but they are especially bad for programmers because of the mental models they need to maintain. This cartoon explains it better than I ever could.
Studies show that it takes about 25 minutes to get focused again after being interrupted. So just remember that the next time you consider interrupting a developer when they’re clearly in The Zone™. You’re wasting about 15 to 30 minutes of their time in addition to the time you spend talking to them.
You may think that you’re interruption feels like this:
Image credit: Lennart Guldbrandsson
But to a developer, it feels like this:
Image credit: The Social Network, Columbia Pictures
Thankfully, there’s hope in some of these approaches to dealing with interruptions while coding.
Image credit: Geek's Humor
4. Bad bosses
Pointy-haired bosses are real. Some of us have worked for them. They’re the bosses who think that because they know a little bit about a lot of things, they are experts in everything (especially UI design). They make assumptions that make no sense and have zero basis in reality. These assumptions can result in arbitrary organizational constraints on language, platform, libraries, and other technology choices. Everyone understands that being a manager is tough, but some don’t follow basic principles that could make everyone a lot happier and more motivated.
Developers hate too much management—where they are caught in nonstop meetings that result in lost time and constant direction changes in the software, which also wastes time. Developers hate micromanagement, where managers are asking for time estimates every hour and trying to find out where every second of your day is spent. Developers also hate not having enough management—a team without structured processes will be in constant pain because no one is in sync and tasks are being forgotten.
The good development managers of the world won’t set unreasonable deadlines; it’s usually the non-technical ones that do that. They will listen to developers and give them the benefit of the doubt, because the manager will acknowledge that they’re not the expert. Most important, managers will give developers a good amount of autonomy without letting the team be completely structureless.
Image credit: quickmeme.com
5. Everything is top priority
Some people forget what the word prioritize means. It means ranking tasks and projects—in no uncertain terms—for your developers. But many of the bad examples of managers, like the ones illustrated in the last section, are too afraid to choose. They assume that if they prioritize one task over another, the lower priority task won’t get done on time (reality check—sure, sometimes it won’t). It’s nothing more than wishful thinking. They’ll say that individuals can just work on multiple things “in parallel,” as if saying this magically gives them the ability to code two things simultaneously.
Often, managers will add new "top-priority" tasks to the developers’ plates and still expect other ongoing tasks to be finished on time. “Why did we forget about this task?” they’ll ask. Few people think about the reality behind adding tasks or routines, which is that something needs to be tabled or removed permanently from your day in order to make room for the new work.
So many developers have to live in a world where everything is top priority. This way, it’s easier for the manager to blame the developers when something isn’t finished on time. The manager can just say that the task that the developers silently decided not to prioritize was "top priority". They should’ve known. The manager was very clear.
Image Credit: Allie Brosh
6. Meetings
By now you've noticed that a lot of these items are not exclusive to software engineers. So if these issues are annoying to the rest of the world, then why aren't they getting fixed? We may never know.
Maybe we should have a meeting about it? When should we have a meeting? Let's schedule a meeting to discuss that? This actually happens. It's not an exaggeration.
Too many meetings or inefficiently run meetings are just as detrimental to productivity as interruptions (probably more so in many cases). You've probably encountered all of these meetings:
- The meeting that could have taken 10 minutes, but took an hour
- The meeting that could have been replaced with an email
- The meeting without a clear objective or agenda
- The meeting where people keep bringing up new topics and extending the length
- The unnecessary motivational meeting
- The red tape meeting that you have to attend but has nothing to do with your work
Meetings and interruptions all throughout the day are common reasons for working late into the night. It's the only time developers can get the isolation and long stretches of focused time needed to finish projects. Sometimes the amount of meetings gets so bad that developers look forward to the weekend, not because they get a break from work, but because they can actually get some work done!
Another side effect of badly run meetings is that it discourages participation. If meetings commonly run over their expected time, many team members will stay silent and not add to the conversation unless they're required to. This is because anything they say can start a whole new tangent of conversation that drags the meeting out for another 15 minutes.
Meetings are one of the most hated things on this list, and the best resource I can give you on fixing the problem of bad meeting practices is this talk by Jason Fried: Why work doesn't happen at work.
Image credit: Someecards, victordidit
7. Other people's bad code
Just like writers, programmers have their own individual styles, and the tendency is to transform any code they see into something that aligns with that. There are strong opinions across the industry about whitespace, method naming, and a host of other things that might seem like minutiae to an outsider.
Developers certainly don't hate everyone's code but their own. Most have to learn by examining and admiring more experienced programmers' code. However, diving into the code of a programmer who didn't do a very good job can be traumatic. Sometimes the programmer wasn't very good, while other times they just got lazy. Either way, it's a nightmare scenario when you have to maintain or refactor that code.
The biggest challenge is the amount of time it takes to wrap your head around someone else's architecture and thought process. It's especially hard when the previous developer didn't create any documentation explaining how everything worked or didn't build any unit or integration tests, which would also give clues about the user flow. Code without comments can also be really hard to understand.
The solution for preventing these scenarios lies with the original programmer. The only way to prevent more of these horrific events is to abide by this mantra:
"Always code as if the guy who ends up maintaining your code will be a violent psychopath who knows where you live. Code for readability."
Image credit: memegenerator.net
8. Documentation
As I mentioned in the last point, documentation is crucial for future generations of developers who will have to maintain your code. But there are two different perspectives:
- Developers hate writing documentation
- Developers hate badly written documentation
It looks like we're at an impasse. Nothing is worse for developers who are trying to learn about some platform, library, framework, or piece of code than confusing, badly organized, or outdated documentation. Unsurprisingly, documentation written with haste (or, lose the "s"—with HATE) will probably turn out bad. So what's the solution?
Teams need to nurture a documentation author. It could be a developer who's better at writing than the rest. Or just someone who doesn't hate writing documentation as much as the other team members. It doesn't always have to be a developer, and it shouldn't be forced on them if it's not necessary.
Either way, someone on the team needs to bite the bullet and get good at writing documentation. It's the only way to start producing good documentation and end the vicious cycle. Plus, it's a great skill that can differentiate some developers and result in a higher salary.
Image credit: imgflip.com
9. Technology churn
Churn is what happens when the bulk of the developers in a specific language ecosystem designate one framework or platform as the best and form a vibrant community around it, and then one or two years later the majority of developers decide that a new framework or platform is the best. They then all migrate to that community, leaving behind other developers who tied their software more firmly to the first technology.
The JavaScript and Node.js ecosystems are prime examples of this technology churn. “Flavor-of-the-week.js” some call it. It can be extremely stressful for developers—even the most engaged ones—to keep up with the churn of tools and APIs, which can require major changes to their applications.
There is often too much credit given to the shiny new thing when it is often just a reinvention of something that already exists and solves a problem very well (sometimes better). It's true that developers shouldn't get bogged in a declining technology for many years, especially since that can bring on its own set of frustrations. But it's ridiculous when the veterans in the development community have to talk about how every few years, a new generation of developers tries to reinvent the wheel. It makes it seem like the development community goes through cycles where it forgets the problems it solved in past generations and sometimes does a worse job when it tries to solve them again.
Image credit: memegenerator.net
10. Stereotypes
This is what most of the world thinks developers do:
Video credit: NCIS, CBS
It just makes me want to cry. Partly because it's so funny, but also because it's so sad.
Being thought of as a wizard by the general population is a blessing and a curse. The curse is that managers think you can code anything, and most of your family just describes your job as "something to do with computers." Or worse, they ask you if you can hack the neighbor's Wi-Fi, and when you say, "It depends," they say, "Either you can hack it or you can't!"
I blame movies and TV shows like the one I just posted above. I don't think I've ever seen a realistic portrayal of a software developer or security engineer in film or on television. And you know there's always going to be that scene in every movie where a scientist or technical character spouts some poorly scripted techno-babble and the main character says, "Speak English, please!" As if every smart person ever has no concept of how to talk to a layperson.
"He was devoted to his job, doing something with computers"
— Daniel Spenser (@DanSpenser) January 4, 2016
- My parents, reading my eulogy.
11. Requests for tech support
This is closely related to the last point, and it's something developers have to deal with from family members and at the office.
Dad: "Hey, you work with computers, right? Come help me fix my iPad!"
Your boss: "Hey, the printer's broken again. Can you fix it?"
It doesn't matter if you've only ever built CSS frameworks, people just assume that anyone who can write code can also fix anything technology-related. Sure, if you can help friends or family you're usually willing to hear them out. But people go too far when they treat you like you're a source for free 24/7 technical support.
Image credit: familygeeks.com
12. Recruiters
The scarcity of developers has made the field of software engineering very lucrative. Jobs are plentiful.
It's nice to be desired in the midst of this tech boom, but the amount of recruiting going on there has gone too far. At this point, I get emails for senior Rails developer positions because I built a simple site back in 2013. They almost never take a deep look into candidates or pay attention to their desires. It's all about speed and quantity.
The worst recruiters have no skills other than the ability to send an email and make a phone call. They would call James Gosling and ask him if he's interested in their senior Java engineer position and be completely serious (and also oblivious). This is why veteran developers who don't need to search for jobs anymore have to put "no recruiters" in all caps on their LinkedIn profile, or delete their profile altogether. It's almost as bad as telemarketing calls before we passed laws to curtail them.
Most recruiters suck and could stand to learn a lot from the rare, excellent recruiters like Dave Fecak, who also gives excellent programming job search advice.
Image credit: quickmeme.com
13. People looking for a technical co-founder
This annoyance happens less frequently than recruiters, but it's still annoying in most cases. Most good developers can find great work environments and high salaries with a number of companies. Most won't leave all that behind even for the most innovative-sounding startups. So when some business major tries to tell you about their great idea for a new app or send you their weak pitch, it's nothing but a nuisance. Developers probably have their own (better) ideas and most likely don't need a business person to make them a reality.
Some of the non-technical people who want to found a company just want to contribute ideas while developers do all the work. People with this mind-set are everywhere: "I'm an ideas man!" There's no way anyone will come close to working with these people. If you're going to start a company, you're going to need to put in as much work—if not more—than the developers. If a person needs to code something for the startup they want to create, they should learn to code.
A post by Tyler Willis has one of the best pieces of advice on this issue: "If the idea is more important to you than the team that implements it, you aren't looking for co-founders."
Image credit: Allison Rhodes
14. Works on my machine
Is it the framework, OS, hardware, gamma rays? This phrase has many facets to hate, but it's usually a cop-out for developers when there is clearly an issue with their software. Developers who say this instead of trying to drill down into the root cause are annoying to the other developers or stakeholders on the team.
Instances of software working on one machine and not another can occur because of bad, state-heavy design, because there's a lack of knowledge about the operating environment, because developers are doing a poor job of version control or continuous integration, or for a bunch of other possible reasons.
Regardless of the cause, saying "It works on my machine" without it being a joke is very annoying to the other developers and stakeholders if you don't plan to follow up on why it only works on your machine (or if you're lying).
Image credit: Jon Galloway
Honorable mention: Link bait articles :)
Don't you just hate all the list articles (a.k.a. listicles) that start with a random number? One developer told me that they refuse to read any article that starts with a number in the title. Personally, I would never write something like that ;)
In general, just about everyone hates being tricked into clicking on an article with an eye-catching headline that has little to no substance. It's annoying when authors keep using the same old gimmicks to try to get developers' attention. All they have to do is write a controversial or short and cryptic headline and they'll likely get thousands of views.
Let's try an example: "React is Garbage"
You know the author is baiting you, but you really like React and you simply can't let this aggression stand. You have to see what flimsy arguments they make against React and promptly refute them in the comments. "[X Technology] Considered Harmful" titles are my favorite.
Please share your hate in the comments. And, oh yeah...Happy Valentine's Day!
Keep learning
Take a deep dive into the state of quality with TechBeacon's Guide. Plus: Download the free World Quality Report 2022-23.
Put performance engineering into practice with these top 10 performance engineering techniques that work.
Find to tools you need with TechBeacon's Buyer's Guide for Selecting Software Test Automation Tools.
Discover best practices for reducing software defects with TechBeacon's Guide.
- Take your testing career to the next level. TechBeacon's Careers Topic Center provides expert advice to prepare you for your next move.
