How to address your coworker’s bad code
-
-
If your shop uses code reviews, then it is not necessary to single out a developer and tell them how bad they are. You have a controlled environment where you can make suggestions and point out issues that must be resolved.
-
wear a bulletproof fire suit
Decrease the belief in God, and you increase the numbers of those who wish to play at being God by being “society’s supervisors,” who deny the existence of divine standards, but are very serious about imposing their own standards on society.-Neal A. Maxwell You must accept 1 of 2 basic premises: Either we are alone in the universe or we are not alone. Either way, the implications are staggering!-Wernher von Braun
-
I prefer to address coworkers that write bad code with "Hey, sh*t for brains!" [edit]Oh geez, now that I actually read the article, I have to wonder, why all this politically correct warm fuzzy garbage? What ever happened to "we made a huge mistake hiring you. You're FIRED!" But no, we have to waste our time coddling incompetence. And I don't mean you should apply this to junior devs - you know what you're getting into -- this should be applied to those people who lie when they knowingly (or not) call themselves a "senior" developer.[/edit] Marc
Imperative to Functional Programming Succinctly Contributors Wanted for Higher Order Programming Project!
-
Coding errors are fairly straight forward to address. If you have comprehensive coding standards and regular code reviews, then these sorts of awkward situations can be avoided altogether. What is more difficult are design flaws in someone else's code. It is easier to improve your coding skills than to improve your design skills.
"There are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies, and the other way is to make it so complicated that there are no obvious deficiencies. The first method is far more difficult." - C.A.R. Hoare Home | LinkedIn | Google+ | Twitter
-
Coding errors are fairly straight forward to address. If you have comprehensive coding standards and regular code reviews, then these sorts of awkward situations can be avoided altogether. What is more difficult are design flaws in someone else's code. It is easier to improve your coding skills than to improve your design skills.
"There are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies, and the other way is to make it so complicated that there are no obvious deficiencies. The first method is far more difficult." - C.A.R. Hoare Home | LinkedIn | Google+ | Twitter
Dominic Burford wrote:
coding standards
So much this. Without a documented coding standard it becomes a clash of egos. "This is the way I would do it because (long-winded reasons trying to convince others).". With a documented coding standard it becomes "This is a violation of rule #32. Fix it."