Ask Slashdot: How To React To Coworker Who Says My Code Is Bad? 507
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 (Score:5, Informative)
You Are Not Your Code: http://sstephenson.us/posts/you-are-not-your-code
Re:Tell him to write goddamn login page himself? (Score:5, Informative)
Re:It depends on how he goes about it. (Score:3, Informative)
You should also try to avoid my typos and grammatical errors. Those will not help your case.
Re:Those who are not satisfied with others . . . (Score:5, Informative)
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.
Re:Is he right? (Score:5, Informative)
First step is to understand that young or old, lot's of experience or little, a person can have valuable contributions. For a good team you have to put ego aside. Sounds like there is ego on both sides of the equation in this particular issue. Listen carefully to what he thinks is wrong and he should listen back about the design decisions etc.
My experience tends to make me think that there are serious issues with the codebase. Depending on language, 50K lines isn't much and could be rewritten by a couple smart people in a matter of months. Obviously the product works, but how long are bug fix turnarounds? How extensible is it? How quickly can you add new features? Do new features ever break other parts of the code (i.e. coupling issues)? You can be proud of what you achieved, but also be honest. I've written some code myself I wasn't proud of (I'm sure we all have). A good developer isn't the same coder as they were 6 months ago, because it's a continual learning process.
If this jr has valid input, good ideas for restructuring (once you look at your code honestly, "Yeah, there was a better way to solve the issue..") then why not let him lead the dev for the next gen product? If you are honest about the code and he's just an egotistical little shit not willing to discuss things like an adult (some back and forth and actually listen to you and others).. get rid of him. Seriously. It's not going to help your team at all and he's going to cause problems anywhere he goes. If he's right and you're all wrong, then he's better off elsewhere anyhow (though if he's bullheaded and egotistical I doubt that's the case).
Comment removed (Score:4, Informative)
Re:Mod this up! (Score:5, Informative)
No. You only say that until you are almost permanently awarded with mod points.
Re:Technical Debt (Score:3, Informative)
Bingo, it's bad code in the eyes of the beholder if the code currently fulfills the user case(s). what is good code: What is good code? Readable? Efficient? Academically written? following standard? ingenious? a hack? All depends on the use case... remember those things?
If you're coding for a career, coding is about filling a use case, to make money. It's not a mental exercise--which is left to college students. That's why I see CS prima donnas and Business AppDevs fight so much on code.
If it does the job and fills the use case, it's good code regardless, if you're speaking british, english or latin.
I always found writing good code is easy, reading [someone else's] code is where the money's (and respect's) at.