19 Things That Software Developers Hate To See/Hear
Daily struggles of being a Software Developer
1. Useless error messages
Whatever programming language or technology you’re using as a developer you will always come across them generic useless error messages. These type of errors are very time consuming when it comes to debugging as often it leaves developers with no starting point.
2. Badly named things
Names which do not reflect what a function, class or variable is for. This can make the code hard to follow very quickly and can become misleading.
var d = 2;
var myInt = 12;
var message = "An error";
3. “We’ll write tests later”
When a project comes in and is needed in a hurry the tests can sometimes take a hit. Developers may get told to write tests latter but more times then not them test never get written.
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
This is becoming a running joke, especially in the frontend/web development world. We’ve all seen recruiters with job adverts saying something along the lines of: “5 years experience needed of xxx” when the technology they’re referring to was only created 3 years ago.
5. “How long this is going to take?”
This question is usually a problem when you don't have the full details or some cases extremely little detail.
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”
When a non-technical person says we just need to add this or change this: “It shouldn't take too long”. Developers can find this frustrating as before you know it you're having to add new / change new tests and change half the code.
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.”
Similar to the: “We’ll write tests latter” heading. In a rush to get a project/feature complete error checking/ messages can often get forget about or ignored.
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”
“Can we just add that or change that?” The never-ending project/feature which over time can cause the code to get messy due to non of these changes being designed or planned correctly and rushed through. This can also kill the developers motivation with the constant changes!
9. Everything is a top priority
When all the work is a top priority, it kind of starts meaning nothing. Every developer has gone through this. It ends up taking longer due to all the context switching to try and get everything done quickly.
10. “It works on my machine”
This a right of passage for every developer. This can be frustrating and sometimes makes it hard to figure out whats wrong, if there's an issue.
This often happens when you release local code to a server!
11. Merge conflicts
Them tricky merge conflicts which can take up a lot of time and sometimes can break a developers build.
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
Some developers hate this a lot more than overs but that pointless whitespace in the code really get some developers going. You’ll often see developers highlight every whitespace issue in desk reviews.
Linting can really help cut this issue out.
13. “We’ll clean that update later”
Similar to the ‘we’ll write tests later’ heading. Where the code quality takes a hit and the business just take the approach of just getting it to work. This can frustrate a lot of developers as they take pride in their code.
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 developer hates nothing more when they see there build is broken. This can be even worst when it’s highlighted to every other developer that you pushed/checked in a broken build.
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 can be frustrating for developers as this usually causes confusing requirements or an inconsistent 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
The more senior you get the more you find out how important having a consistent codebase is!
Inconsistent code can turn any application into chaos.
17. “It needs to work in Internet Explorer”
If you’re a web/frontend developer you should have had a few painful encounters with Internet Explorer. Every developer hates to hear in the requirements something like “must work in IE 8”.
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?”
Probably one of the most obvious ones on this list that developers don't like this but no developer likes to see bugs logged against their code as it can hit their pride and ego for some developers. Even though this is part and parcel of being a developer.
The worst type of bugs are bugs that are disguised as requirements!
19. Not being able to replicate a bug
There’s nothing worst and time-consuming than trying to replicate a bug. Often this is caused by different environments or different settings.
Developers can start to believe they’re made up.
I’m sure there's a lot more on the list that developers hate to hear/see.
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!