Top Ten Things Developers Hate
| March 24, 2020 | in
Developers are creators at heart. They like to create. A big part of the appeal of software development is the quick outputs from your work. You write code one day, and the next day it can be in a customer’s hands. How many other jobs have that quick of turnaround on effort?
But many things can reduce a developer’s day-to-day enjoyment. Many of these are in the list below. The list is somewhat an attempt at humor but also calling out some real pain points that developers experience.
Just because developers don’t typically enjoy an activity doesn’t mean it isn’t useful. Estimation is maybe one of the best activities you can do to force critical thought about a problem. Developers often will dislike meetings to some degree, and I think this is often because a developer’s schedule can quickly become one hour in a meeting, one hour of work, another hour in a meeting, and one hour of work. These constant interruptions can be extremely frustrating, and it impacts their effectiveness. Creating high-quality code requires focus and deep thought. Cutting into that deep thought impedes forward progress.
#10 — Realizing They Broke the Build
Developers want to make forward progress, but sometimes you must go back and fix things. Measure twice and cut once.
#9 — Setting up Builds
Builds and environment work feels like you are doing work before you can get to the “real” work. But these steps are essential for a solid delivered product.
#8 — Realizing Data was Changed Because of a DB Trigger
If you have ever run into this issue, you know exactly what I am talking about. You also think it maybe deserves to be higher on the list.
#7 — Writing Code Only to Realize That It Will Never See the Light of Day
No one likes to build something only for it never to be used. Part of the joy of software is creating things that benefit others. So it can be very frustrating for developers when they find out their code will never be used.
#6 — Rewriting Code
Developers like making forward progress. Coming back and rewriting things becomes a burden on the development staff.
#5 — Poorly-Defined Requirements
It can be challenging to have a deadline and not know what you are supposed to do.
#4 — Fighting with certificates
Every battle with certificates is just that, a battle. The win takes a while to get to and usually isn’t super satisfying. I think the root problem here is developers don’t do enough of it to be good at it.
#3 — Meetings
Developers are not the basement-dwelling isolationists portrayed in media. Developers are pretty much ordinary people, and I don’t think most people enjoy meetings. But I feel this often has to do with meetings that don’t have a clear purpose. If you can have clear goals for the meeting, I think everyone is better off.
#2 — Estimation
Few things are more dreaded by engineers than the “how long will it take?” question. But the irony is that this question is often where good critical thought starts. It is better to embrace this question and welcome it as a must-have step in good critical thinking.
#1 — Meetings About Estimation
No explanation necessary.