Blog

You’re a software developer, engineer or programmer, and hopefully love what you do (most of the time)

There are bound to be days for most developers however, when your gears get ground into fine dust, and the cry of “I hate programming” can be heard echoing round the Dev team room

Don’t feel that you have to suffer your anguish alone

We know that developers often don’t agree with each other but this may be the rare occurrence where we are all united

We’ve created the Top 10 Developer Hates after much research with a variety of Dev teams and these irritations should resonate with most of you whatever level you’re at or language that you code in.

This may be preparing you for a good old moan, but there should be value in enlightening the wider world as to what winds you up, and increasing the likelihood of your clients and co-workers being more considerate in future

1. Mission Creep (the project nemesis)

The software project has been planned and agreed and the core work has been finished. You’re proud of what you’ve achieved and are inwardly celebrating success

You’ve fulfilled your customers every dream and are ready to move on to your next project

Stop right there!

What your customer thought they wanted months ago seems to have suddenly changed. The most important feature is no longer necessary and they’ve got some brilliant new ideas that they’d like you to incorporate. Their ideas mean that you will have to completely reconfigure everything that you’ve done up until this point. To make matters worse – they’re rather vague on the changes that they actually want n ow.

Their unrealistic expectations and overly optimistic deadlines means that your development time has just doubled whilst simultaneously entering the project Twilight Zone

Not every project is like this fortunately, but the majority have an element of additional requirements resulting in further development time, resources, a wave of dread and a lack of closure

2. Interruptions

You’re in the zone – you can picture the perfect solution to a problem you’re working on when – bam! It’s all lost

It’s going to take you 25 mins to get back to where you were (aside from the time speaking to the interrupter) – and that’s if you ever manage to rezone again

A lot of developers wear headphones but to the uninitiated they may think you’re just quietly rocking out rather than shutting out distractions

You can create a curtly worded notice on the Dev team door which explains why you don’t want to be interrupted, but try to gently educate your customers as to why you hate interruptions so much – a bit of understanding may make them think twice before interrupting you and ease your pain

3. Boring boring meetings

Meetings get in the way of coding and make your deadlines even tighter. They’re just as hated as interruptions and could even include a whole gathering of your favourite interrupters in one place

To make matters worse - a high proportion of meetings are often unnecessary and could be dealt with via email at a time that doesn’t interrupt your flow. They can be inefficient, dragging on with new topics being added unneccessarily, often with a lack of agenda, and controlled by those with the loudest voices - meaning that you might not even get a chance to participate

They may even have little to do with your actual work and are likely a key reason as to why many developers want to work remotely and retain focus

4. Bad code

The well-known quote

‘Always code as if the guy who ends up maintaining your code will be a violent psychopath you knows where you live’ John F Woods

. . . . is a good way to proceed

As a developer or programmer you will undoubtedly be working with other people’s code from time to time. The code may vary from that written by programming gods where you can learn from their experience - to lines of drivel written by newbies or lazy programmers where you will have to completely rewrite the offending code

You might just have your own style and want to stick with it. Other people breaking your code can be just as annoying too

Whatever the scenario – if you’ve got to take the time to refactor or maintain that code – you’re not going to be happy

If the code isn’t documented or you can’t understand the original coders thought processes it’s going to take even longer

. . . . please try not to get your sharp knives and the address book ready

5. What documentation?

On the subject of documentation – most developers hate doing it - and hate reading it when it isn’t up to scratch and makes maintenance a Sisyphean task

You can’t have your documentation cake and eat it though. Try to be the better developer who writes to help others and spends time making clear useful instructions. Or better still – work with an end user or someone who will write it for you

Show how valuable you are to the team with well written documentation and it may even help you move up the career ladder quicker when your invaluable assistance is recognised

6. Debugging (working on the coding chain gang)

Another developer top hate is working on little snippets of code rather than something interesting and creatively fulfilling

Or even not writing enough code!

As a software developer or programmer you will inevitably sometimes get work you don’t enjoy.

If it’s that repetitive – look towards automating it. Or find someone who enjoys the tasks you hate, stick your headphones on or try to find some joy in it. Sometimes a bit of brain relief before you gear up for something more challenging can be useful?

You may find yourself constantly debugging – looking for that needle in a haystack and being driven to distraction - compounded by the pressure to solve it asap or spend the whole night trying. It can feel like a pretty low point but don’t give up – ask your team to have a look too – sometimes a new set of eyes can spot something or provide a different solution

7. They have no idea what I actually do

‘something to do with computers’ – My Mum

Your family know you press buttons regularly whilst your managers think you can do anything from mending printers to writing in any language or hacking their Netflix

You and your team may understand the difference between different IT roles and languages but your family, friends and distant co-workers will probably never grasp more than the basics

Accept this now (or be prepared to hand out laminated mini descriptive/pictorial Org charts with yourself coloured in). At the very least it will distract those who want you to fix their printer

8. Know it all bosses

Developers hate too much management and the wrong type of management

A conscientious developer will want to follow the rules of clean code and create high quality software. The overarching decisions however may come from someone who only cares about the end result, and not the maintenance or ongoing performance which can be frustrating

Unfortunately the characters in Dilbert often still ring true and the know it all boss is all too common. IT departments can often be led astray by bosses who think they’re experts, and who may have been once, but are now too removed from the floor to make the right decisions. Management in itself is important for a Dev team because without structure, a common purpose, someone who can manage customer expectations and negotiate on behalf of the team, life as a developer may be an uphill struggle

The wrong boss can be truly damaging and result in the wrong technology choices, a focus on the wrong solutions, unsuitable hires, poor morale, poor task prioritisation, unrealistic expectations and may even blame developers when it all goes wrong – the list goes on . . .

9. New shiny languages

Nearly everyone hates working on antiquated legacy systems that need high maintenance and prevent new technological advances

Equally, the rush to adopt new languages or frameworks to fix old issues can be frustrating too. You may have spent years becoming expert in your technology to suddenly find it side-lined whilst something more fashionable takes it place. Now you’ve got to learn something new or be left behind, and the level of work trying to update your current application can drive you to distraction

It can certainly be a positive to move to a more ground breaking technology rather than using something old and ineffective but annoying for senior developers who have seen endless change for the sake of change over the years

10. QA Breaking your code

You probably hate QA – they’re meant to break things

A good tester is worth their weight in gold - and should be annoying you - and when they prevent you from making awful mistakes you should be grateful

In contrast, a bad tester is a royal pain in the proverbials - creating unnecessary drama whilst even maybe missing the most important issues. A lack of knowledge can create more problems than needed fixing in the first place

Hopefully you still love your job

The job of a developer, software engineer, coder, programmer – whatever we’re calling it this decade - is undeniably a great one

The niggles in this list are common, but hopefully won’t put you off. If you’ve got a great team around you, a boss who knows their stuff and you get to write what you want to write occasionally, then you should be happy most of the time

If your back is consistently up against the wall and you’re not enjoying what you do – go and find a better company or team – there’s loads of great work out there