The spike in demand for new applications and software is unprecedented, and expectations for quick turnaround times are even more intense. These two factors together only increase the volume of poorly written code. Most developers have encountered bad code, and depending on their area of expertise, are forced to deal with it frequently, accepting bad code as the norm. It’s hard to enjoy fixing poorly written software and applications, but the question is how should you go about correcting code written by one of your colleagues?
No one writes perfect code. Surely, we all make mistakes from time to time because coding is tedious work. The difficulty arises when you have to broach this subject when the code comes from one of your associates or higher-ups. Most software engineers think their code is superior and that everyone else should go back to school, but we all know that every developer has room for improvement.
The truth is, a vast amount of code produced isn’t meticulously documented and may not look the best, but it gets the job done. However, bad code starts to become a serious issue when it’s difficult to understand, and the conventions deployed therein mark a significant departure from industry standards. Having a conversation about poor coding practices with one of your trusted associates is difficult. As you know, many engineers can easily be put on the defensive when it comes to processing any criticism about their work. So, what’s the best way to address badly written code with one of your teammates?
Coding and subjective interpretation
As in any written language, the art of determining the value of another person’s code is highly subjective. So, when the time comes to evaluate the effectiveness of another developer’s work, it’s important to consider whether your objection to their methods is warranted. This requires a moment of pause in which you ask yourself whether or not the code is bad or just stylistically different. When your colleagues’ code departs from your normal expectations, remember that your interpretation of their work is fundamentally subjective unless you can identify objective faults.
Grappling with someone else’s quirky code is a challenge for most developers. Given the array of training options and educational platforms available, you shouldn’t really expect code to present exactly the same way at every outing. On the one hand, you have developers with advanced degrees who went through elite university programs like M.I.T., while on the other, you probably work alongside full-stack engineers who are virtually self-taught. Both can be highly effective in their roles, just as both can produce badly written code.
It’s not uncommon for software engineers to quibble with the aesthetics of other developers’ code, but if it’s not inherently flawed or consistently buggy, you should ask yourself whether or not giving your associate negative feedback is worth the trouble. It could throw you in a poor light, showing you as someone with a pension to waste your coworkers’ time.
Identify the core problems with the code
As mentioned, there’s no one way to write code, and multiple effective methodologies exist. However, many developers are still under the impression that there’s only one way to go about it, which is usually their own approach. So, before charging your teammate with incompetence, be sure you can offer ample support as to why their code is less than stellar in your eyes. Come equipped with evidence beyond the typical vagaries and your subjective impressions about the code’s beautification. Here are three concrete questions you should ask yourself before approaching your colleague:
- Is the code written efficiently?
- How buggy is the code throughout?
- Does the code match company-established standards?
If the code is unintelligible and riddled with mistakes, you should find reasonable grounds to have a conversation about your teammate’s efforts.
It’s all in the approach
To have a productive conversation with an associate about the quality of their code, you should start by asking questions instead of leveraging allegations. This is the best strategy for keeping conflict levels low. In some situations, it may be impossible to raise the topic without offending the subject of your critique, but this is inherent to any dependable quality control initiative.
Nevertheless, by asking questions, you’re showing your coworker that you’re approaching the conversation with an open mind which will foster mutual air of respect. When you dive right into criticisms of your associate’s code, you’ll defeat the process, and your colleague will be less likely to self-evaluate. If you remain humble and focus on educating, you can expect a positive outcome.
Let One Blink Technology relieve your issues with bad code
Constantly fixing bad code is a messy business, not to mention resource-intensive. If you run a small company and find yourself overwhelmed with fixing bad code or have applications that crash at the most inopportune moment, consider partnering with One Blink Technology.
We’re a leading software consultancy that specializes in developing clean and robust web applications in popular frameworks like Laravel, WordPress, React, and Vue. For more on how we can provide your business with advanced software development support, complete our request for contact form online now to schedule your next meeting.
