19 Things That Software Developers Hate To See/Hear

Daily struggles of being a Software Developer

Daniel Anderson
Oct 19 · 5 min read
19 things that software developers hate to hear/see
19 things that software developers hate to hear/see
Photo by Toshi on Unsplash

1. Useless error messages

2. Badly named things

Examples:

var d = 2;
var myInt = 12;
var message = "An error";

3. “We’ll write tests later”

Then often what happens is when making a minor change this can cause this part of the software to break and they get asked: “why does this software break all the time?

4. When a job requires more experience than when the tech was created

5. “How long this is going to take?”

Not only do developers hate it when they have to try to give an estimate without all the details but when the business takes their estimate as an actual time that is 100% correct and hold them to it.

6. A non-technical person says “it’s just a small change”

This can be even worst when it sounds like such a small simple change but its part of the system which is integral which can be hard to explain to a non-technical person why it may take much longer then they think.

7. “We’ll add error checking and proper error messages later.”

This can lead to people asking why are there errors coming from that part of the code or what does that error message mean, can we make it more meaningful.

8. “Just one more thing”

9. Everything is a top priority

10. “It works on my machine”

This often happens when you release local code to a server!

11. Merge conflicts

Every developer will come across these! The longer you wait to get the latest version of the code from the parent branch, the worst they get as well.

12. Whitespace in the code

Linting can really help cut this issue out.

13. “We’ll clean that update later”

In the long run this often doesn't get rewritten and the developers have to deal with this hard to follow code, which in the end takes much longer to add any extra features to that part of the system.

14. Broken builds

A lot of companies will send broke build updates to group chats with the developers name on it so every other developer can see that their build failed!

15. Everyone in the world thinking they are an expert on UI design.

This usually effects the time to deliver the feature due to everyone having different opinions on the UI design causing requirements to change after the code has been started.

16. Inconsistent code

Inconsistent code can turn any application into chaos.

17. “It needs to work in Internet Explorer”

The amount of times developers come across it working perfectly in Chrome and then forgetting to test it in IE right until the end and releasing there going to have to change large parts of their code.

18. “Should I assign that bug to you?”

The worst type of bugs are bugs that are disguised as requirements!

19. Not being able to replicate a bug

Developers can start to believe they’re made up.

Conclusion

Every job has good and bad points. Being developer can come with some frustrating things especially as most developers just want to be left alone to code and get one with the job.

Hope you’ve enjoyed reading!

JavaScript In Plain English

New JavaScript + Web Development articles every day.

Medium is an open platform where 170 million readers come to find insightful and dynamic thinking. Here, expert and undiscovered voices alike dive into the heart of any topic and bring new ideas to the surface. Learn more

Follow the writers, publications, and topics that matter to you, and you’ll see them on your homepage and in your inbox. Explore

If you have a story to tell, knowledge to share, or a perspective to offer — welcome home. It’s easy and free to post your thinking on any topic. Write on Medium

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store