Programmers Hate😡 These Questions!

Photo by Camylla Battani on Unsplash

Programmers (software engineers, developers, and coders) are fantastic. They drive growth and even create the main product for huge and successful companies.

However, they can be prevented from achieving their jobs by some bozos coming up and asking questions they shouldn’t, breaking concentration and flow. It’s annoying and shouldn’t happen.

“So, what things have I heard and wanted to shout ’Let me get on with this’ to the questioner? 

Take a look at my top picks below and bask in the excitement of knowing The Secret Developer’s favorite annoyances.”

Are we still on track?

If we are creating something new, something genuinely new then past performance is not a good indicator for the future.

Deadlines create stress for programmers who have no real control over when something might be delivered.

“If I’ve delivered everything in the past, why don’t you believe I will deliver now?

In my current position, I’m asked pretty much daily whether we are still on track. Nothing seems to change in the intervening time so I’m unclear why I need to give a daily update. I’m thinking of saying ‘it’s in the ticket’ but even for me that seems to be a little obnoxious.”

We need to make this deadline. Cut corners if you need to. Can you do that?

This can be followed up with “You can clean up the project later”. It feels inevitable that the later never comes and the tech debt never gets acted on.

“How can it be fair that keeping things maintainable is seen as ‘dev work’ that can be put off indefinitely? The developers on the project feel the pain of this rather than the managers who are making these requests of the developers.

Look I’m not proud that sometimes I bend the rules and just get the work done. This is behavior that gives the whole Agile team more work over time (but especially The Secret Developer) as expectations increase. It’s not a sustainable way of working and ‘breaks’ Agile but I don’t feel as if I have an alternative to this behavior. Suggestions in the comments, please!”

Why are there bugs in the code?

It always seems to be the developer’s fault that there are bugs in the code. How can it be any other way than a problem with the programmers and the product that they produce?

“Yeah. The only code that has no bugs in it is code that is entirely empty. Do you want us to delete the entire project?

That will ensure there are no bugs. 

It does make me laugh that business owners think that the problem is with developers when it could be issues with requirements or that pile of tech debt, we are not able to tackle due to a lack of resources.

This one is about how we are treated as developers and how we are considered by business leaders. It’s about being seen as a cost center rather than a team member who solves problems. It’s a real issue that needs to be fixed.”

Can you help me with creating a user?

Coders often want to help people and are naturally quite a flexible bunch. It seems natural to ask them for help when creating a user in the alpha system for testing. 

“I want to produce working software that delivers wow. Doing so means keeping up to date with technology and understanding what is going on in any particular new feature. 

This might mean being overloaded with work and struggling to keep up with capacity. When members of the team ask you to come up with solutions to what seems to be their issues nobody is helped.

Worse when you break up a programmer’s concentration it can take hours to get back into the groove of coding. A 5-minute distraction can cost an hour.”

Can you fix this?

This is a fair question for software developers. When there is a bug, they should be able to fix it.

“Back to reality. If we have a bug which is not adequately defined (dare I say not refined) the software developers are not sure what problem they are trying to solve. 

Then a business owner wants a commitment to fixing the issue. Not just an estimate but a full commitment. I guess I can do it within 400 years? I wouldn’t want to commit to a different timeline.

Tell me what you want to fix, before asking if I can fix it.

Is that a reasonable request?”

This should be easy!

When a product owner or member of the business tells you that your work should be easy.

“In my opinion telling a developer how they need to approach a problem is an issue.

This can manifest in telling a developer that this is ‘just like something you’ve done before’ which is a charming assertion that I’ve previously been subjected to. Even I’m not brave enough to ask how they might know enough to assert this. 

How does a business owner know what is easy or what is involved in technical work? They might even be a developer who has transitioned to another role but even so are they familiar with the detail? On that basis, this type of ‘question’ (it’s not a question by the way) is practically a detrimental attack on a developer.

I’m not going to thank anyone for such a judgement on my work and knowledge. Why should I?”

Can I get a status update?

Status updates are prevalent in the world of software development. They are a fact in many developers' lives as part of a daily ceremony.

“I think part of this is the fact that we do not trust developers. 

When we take this from basic principles, I believe this means we do not trust developers to get on with things themselves and deliver the end goal of working software. 

It can actually be worse than this. When we repeatedly ask a developer for a work update, we distract them from getting on with their work. Couldn’t we simply get a developer to work and update their tickets along the way? We would be able to progress our development in the fastest possible time. 

Shouldn’t that be our goal?”

If your work is done, why are there still bugs?

If developers are creating software artifacts on time, are they also of sufficient quality? Members of the business might ask why if a feature is ‘done’ there are still bugs in the work.

“I’m all for meeting a level of quality. However, where I work the completion criteria changes during development, which can mean that the QA are checking work against something which was never developed. 

As developers, if we could work without ever creating bugs, we would do that. Even The Secret Developer cannot create perfect bug-free code. If I could do that, I’d be ChatGPT or something [put a reminder to the audience that this is a joke]. 

My work isn’t perfect. If you know someone who has perfect code, please hire them.”

Conclusion

This itself is a ridiculous list of things you might hear at work as a programmer. It is intended to raise a smile and not make anyone’s life worse in any way.

“If you don’t like it, comment to increase the engagement on this article anyway. If you do like it, do the same.

Thanks!”