Let's start with the inverse.
How NOT to Talk About Bad Engineering
- “Who WROTE this garbage code?! What the heck were they thinking?”
- “Using PHP would be a mistake, this should definitely be done in Python.”
- “This is terrible - none of these tables have any indexes or foreign key constraints.”
All of these statements may be absolutely true, but none of them are a productive way of talking about bad engineering. Using aggressive, critical, or negative language will make other developers and stakeholders feel defensive and uncomfortable.
Ask Questions
Try to understand the context of the implementation.
- “Could you give me some background on what you were trying to achieve with this function?”
- “Out of curiosity, why were you thinking of implementing this using PHP?”
- “I noticed that some of these tables don’t have foreign key contraints. Was that intentional?”
Acknowledge Ideas and Suggest Alternatives
Never call an idea bad (even when it is). It’s our job to propose and advocate for good ideas.
- “It seems like this was written under a tight timeline. Can we prioritize refactoring it during the next sprint?”
- “PHP is definitely an option. Have you considered Python? It might be a great fit for this project.”
- “You’re right that vertical scaling is one option, but I think we can save some money by adding a few indexes!”
Offer Help!
Proactively offer to be part of the solution instead of complaining about the problems.
- “Would it be helpful if I refactored some of this code?”
- “Would you like me to create a proof of concept using Python?”
- “I’d be happy to create a migration that applies indexes and foreign key constraints.”
