Slashdot Mirror
Ask Slashdot: How To React To Coworker Who Says My Code Is Bad?
A week ago, you read the other side of the same question. Now, an anonymous reader writes "I have been with my company for 10+ years and have seen many development cycles on our projects. We have a developer intern who has not been on the team for very long. On day one he started ripping into my code on how terrible it is. We have a code base of roughly 50,000 lines of code. When he comes to me with a complaint about the code it is simply because he does not have the experience with it to actually understand what the code is doing. He is a smart guy with lots of promise, he is asking good questions, but how do I get him to look past his own self perceived greatness enough to slow down and learn what we are doing and how we have pulled it off?"
You Are Not Your Code: http://sstephenson.us/posts/you-are-not-your-code
Exactly. Don't hold the guy's hand. Tell him to waste all his time rewriting everything and see what the company does with him.. In the end the boss man doesn't give a shit about how clean the code is.. he give a shit about how fast the code was written and if it does everything it's supposed to and more. New guys gota learn the game too or they will have a hard life in the world of software development.
This, a thousand times this -- but remember, it works both ways.
The professor I worked with closely in university was a strong proponent of this. Sit down, go over the code, look at what can be made better and why, and what may need to stay crufty because it's arcane, and if someone doesn't understand something that's an excellent time to explain it. Walk through and review everything, and don't let your vanity get in the way of writing better code.
He called it egoless programming back in the 90's (no idea how old your book is), and I've found it extremely handy -- objectively look at your stuff and see if he's right. If he's wrong, explain it to him. In the end, the better solution should win out (unless someone is being stubborn or the 'better' solution is technically feasible, which does happen).
Get over the whole "I'm a code guru who knows everything", and be prepared to explain, justify, or even accept that you're wrong. In the end, you review your code to make sure it is as good as you can make it (within reason) and your junior guys get up to speed and understand things better. You get better code out of it, your junior guys get up to speed faster, and you might even learn something along the way.
It's still how I work with co-workers, and it helps in a lot of ways -- instead of saying "here's the solution", you start with "here's a solution, what have I missed?"
You won't agree about everything, but you can pick your battles and try to reach quorum -- the cats don't need to be herded when they're on-board in the first place.
I've seen really awful, and really good ideas from junior coders -- part of the process is helping them understand which is which. In a year or so when he's got more real experience, and knows he can have the discussion, both you and he might actually be better coders for it.
Lost at C:>. Found at C.
No. You only say that until you are almost permanently awarded with mod points.