An engineer pulls me over to look over his code. He can’t figure out why a method is executing twice, and I immediately blurt out, “Hm.. why are you checking your errors this way with if (err == nil) {} ?”He didn’t ask for my opinion on his code style. He was looking for someone to help debug his code. He needed to address the functionality of his code.

Let’s reverse the situation. Assume I call on you for help, and you come over and question my use of scope braces in C. I’m immediately on the defensive since I need to justify my style. And even if I tell you that has nothing to do with the problem, you probably wouldn’t believe me and we’d just spiral into an argument over style.

Doesn’t matter who wins the argument over pretty code indentation. We haven’t even addressed the actual issue I’m trying to solve in the first place.

When I switched to engineering management, I’ve stopped making any comments about anyone’s code style when called upon for assistance. Style guides for coding should be established beforehand and then sorted out at a different time like a code review.

Take a collaborative approach when you sit down with the engineer and work out the logical flow. Don’t be combative by harping on style.