CODING TEAM THEORY: How do you deal with another developer’s bad code?

1️⃣ 𝗦𝘂𝗯𝗷𝗲𝗰𝘁𝗶𝘃𝗶𝘁𝘆 𝘀𝘂𝗰𝗸𝘀 ⚠

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 analyze why you think their code sucks.

2️⃣ 𝗜𝗱𝗲𝗻𝘁𝗶𝗳𝘆 𝘁𝗵𝗲 𝗽𝗿𝗼𝗯𝗹𝗲𝗺

There needs to be an objective problem with the code:

👉 It’s consistently buggy

👉 It’s written in an inefficient way

👉 It doesn’t meet the company’s coding standards

3️⃣ 𝐀𝐬𝐤𝐢𝐧𝐠 𝐪𝐮𝐞𝐬𝐭𝐢𝐨𝐧𝐬 ⚠

Once you’ve established that there is an objective problem with the code, it becomes clear that you should discuss it with your colleague.

The best way to do it is by asking questions and showing your colleague the respect you would want if the situation were reversed.

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.

4️⃣ 𝗕𝗲 𝗵𝘂𝗺𝗯𝗹𝗲

Be humble when you ask your questions:

👉 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?

5️⃣ 𝗘𝗱𝘂𝗰𝗮𝘁𝗲

You’re building a supportive work environment⚠.

So, be sure to avoid subjectivity, and give constructive, objective criticism to bad code. 

6️⃣ 𝗜𝗻𝗰𝗼𝗿𝗽𝗼𝗿𝗮𝘁𝗶𝗻𝗴 𝘀𝘁𝗮𝗻𝗱𝗮𝗿𝗱 𝗽𝗿𝗮𝗰𝘁𝗶𝗰𝗲

👉 Incorporate coding standards: a set of guidelines that lay out the styles and best practices that developers of each project need to follow.

👉 Code reviews⚠: Code reviews offer a great opportunity to suggest fixes or changes in a receptive environment.

7️⃣ 𝗡𝗼 𝗺𝗼𝗿𝗲 𝗯𝗮𝗱 𝗰𝗼𝗱𝗲

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. ⚠️