Forgot your password?
typodupeerror
Programming Software

Ask Slashdot: How To React To Coworker Who Says My Code Is Bad? 507

Posted by timothy
from the very-strong-lye-solution-coffee dept.
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?"
This discussion has been archived. No new comments can be posted.

Ask Slashdot: How To React To Coworker Who Says My Code Is Bad?

Comments Filter:
  • by Anonymous Coward on Thursday January 10, 2013 @01:53PM (#42548991)

    You Are Not Your Code: http://sstephenson.us/posts/you-are-not-your-code

  • by cod3r_ (2031620) on Thursday January 10, 2013 @02:01PM (#42549127)
    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.
  • by ByOhTek (1181381) on Thursday January 10, 2013 @02:18PM (#42549407) Journal

    You should also try to avoid my typos and grammatical errors. Those will not help your case.

  • by gstoddart (321705) on Thursday January 10, 2013 @02:28PM (#42549559) Homepage

    Give him a copy of "The Psychology of Computer Programming", and tell him to read the bit about egoless programming . . .

    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)

    by dubbreak (623656) on Thursday January 10, 2013 @02:44PM (#42549817)
    Absolutely. Experience (as in year doing software) doesn't mean shit. I had a co-op student under me (who I hired when I started my own company) that could code circles around everyone at the company. He understood software, something some developers just never get. I'm not a bad developer by any means (people jump into my code, understand, modify etc no problem), but he'd usually come up with something more elegant and cleaner. It was give and take as I'd come up with some good suggestions for improvement or ways to solve a problems he hadn't considered (which was partially due to experience, partially due to having a different perspective).

    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).
  • by benjfowler (239527) on Thursday January 10, 2013 @03:59PM (#42550873)

    Best Slashdot comment ever.

  • Re:Mod this up! (Score:5, Informative)

    by del_diablo (1747634) on Thursday January 10, 2013 @04:10PM (#42550973)

    No. You only say that until you are almost permanently awarded with mod points.

  • Re:Technical Debt (Score:3, Informative)

    by Anonymous Coward on Thursday January 10, 2013 @04:25PM (#42551147)

    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.

It was kinda like stuffing the wrong card in a computer, when you're stickin' those artificial stimulants in your arm. -- Dion, noted computer scientist

Working...