How do you deal with another developer’s bad code?
Every software developer, at some point or other, will come across bad code. Most of us are guilty of writing it ourselves from time to time. The question is, how do you flag that up when the bad code was written by your teammate or your boss?
Amongst developers, there’s always an element of the ‘everyone else’s code sucks’ mentality. Maybe it just isn’t pretty enough in your opinion, or it could be tweaked there, better documented there. Maybe you struggle to understand it because it’s not what you’re used to. These feelings are fine – normal, even – but what if the problem is more than that?
It can be hard to start a conversation about someone else’s bad code – many developers can get defensive about their work. So how do you approach the topic amicably, without upsetting your colleagues?
Subjectivity sucks
It’s common for developers to hate reading other people’s code. So, before you get any closer to questioning someone else’s work, it’s important to check that your objection to their method is valid. This means that you need to analyse why you think their code sucks.
Because it is so easy to view another developer’s style subjectively, it’s very possible that you think it’s bad code simply because it’s different. It’s normal for developers to struggle with someone else’s code for aesthetic or personal reasons, even if the code itself works fine.
‘If you just want to exert a bit of control and satisfy your aesthetic sensibilities, understand that you’re wasting their time.’ – Barry Rountree
Identify the problem
The issue with code, in general, is that there are multiple ways to write it, and most of them work. There isn’t a right or wrong way to do it. So, before you approach your colleague, evaluate why their code sucks. You’ll need a reason (or a few) that are more than just your opinion. There needs to be an objective problem with the code, for example:
- It’s consistently buggy
- It’s written in an inefficient way
- It doesn’t meet the company’s coding standards
If the code is flawed to the point that it doesn’t work or isn’t understandable, you have a good reason to approach the developer and discuss their work.
Asking questions
Once you’ve established that there is an objective problem with the code, it becomes clear that you should discuss it with your colleague. It can be hard to see a way to broach the topic without causing offence. How do you tell someone their work sucks in a non-sucky way?
The best way to do it is by asking questions and showing your colleague the respect you would want if the situation were reversed. By asking questions instead of immediately criticising their bad code, you prompt them to self-evaluate their coding practices.
Asking questions gives the developer the opportunity to self-identify their errors and teaches them the queries they constantly need to ask themselves while writing their code each day.
By asking questions, you’re also showing that you’re open to their point of view. When your colleague feels respected, they’re less likely to get defensive. Plus, you might find that you were wrong or hasty about your bad code judgement. There could be a reason the code seems rushed (such as running out of time to complete it) or a useful method in the apparent madness that you missed.
Be humble
Be humble when you ask your questions; avoid starting a question with ‘why’ and explain your reasons for asking the questions. Some examples could be:
- I don’t understand this section of code, could you explain it to me?
- I’ve always coded that in this way, what do you think of this method?
- Would it be better to structure the code like this?
In other words, challenge their bad code by asking for their opinion, rather than rejecting it outright.
When asking questions, it’s important to phrase them so that you don’t sound like you are attacking your colleague’s work. Instead, ensure that you are approaching the situation with an open mind, as ready to learn as you are to teach.
Educate
Just as you need to give reasons for asking your questions, you should give reasons as to why an alternative method is better than the one they are using. It’s far easier to adopt a change in practice when you understand why it’s superior.
By giving reasons and opening the discussion, instead of just expecting the developer to follow your word blindly, you’re building a supportive work environment. You’re showing that it’s okay to make mistakes. Everyone does, so build a team dynamic that supports learning and fixing these errors.
So, be sure to avoid subjectivity, and give constructive, objective criticism to bad code. After all, next time it could be you on the receiving end of this conversation.
Incorporating standard practice
There are other ways to encourage every colleague to analyse their code (including you). A few practices can be put in place to ensure that the code you and your colleagues produce meets the standards of the company and brand.
- Incorporate coding standards
Set by the company, coding standards are simply a set of guidelines that lay out the styles and best practices that developers of each project need to follow. They are useful for determining whether there is an actual problem with a developer’s code rather than just personal preferences coming through. Better coding standards mean less bad code.
- Code reviews
Code reviews are a scheduled opportunity for two or more developers to inspect a set programme of code. The aim of a code review is to ensure that the coding standards and best practices are being followed, as well as to fix any errors or vulnerabilities, and detect malware. The overall effect of a code review procedure is the production of better quality software. Code reviews offer a great opportunity to suggest fixes or changes in a receptive environment – the topic is already broached for you.
No more bad code
How do you tell a developer their code sucks? Short answer, you don’t. Long answer, you educate, you learn, and you approach with an open mind.
By asking questions and incorporating code reviews, you take a difficult situation and make it a learning opportunity. You promote a supportive environment with your colleagues, and you might even improve the overall output from your team.
Bad code happens – but you don’t need to become the bad guy to beat it.
