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 crazyjj (2598719) * on Thursday January 10, 2013 @02:50PM (#42548925)

    After all, he's fresh from a CS program where they taught him everything.

    • by Anonymous Coward on Thursday January 10, 2013 @02:59PM (#42549089)

      Code Monkey get up get coffee / Code Monkey go to job / Code monkey have boring meeting, with boring manager Rob / Rob say Code Monkey very diligent / But his output stink / His code not functional or elegant / What do Code Monkey think? / Code Monkey think maybe manager ought to write god damn login page himself....

    • by cod3r_ (2031620) on Thursday January 10, 2013 @03: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.
      • Re: (Score:3, Insightful)

        by Jiro (131519)

        The boss is interested in the long term effects of having code that doesn't suck, such as lower maintenance time. If the boss wouldn't care when directly told this, that just shows he has bad management skills.

        In other words, you're basically saying "take advantage of the boss's bad management skills to get the employee fired for doing something that would actually benefit the company".

        • by Anrego (830717) * on Thursday January 10, 2013 @03:12PM (#42549281)

          As programmers its an easy trap to fall into thinking that better code always translates into those dollars and cents management seems so hung up on. Sometimes it does, sometimes it doesn't. Yes, some bad managers are too short term focused, but being able to do the math and figure out if the cost of cleaning up some code is going to be justified in the long run is part of a managers role.

          Telling management you want to re-write everything is a programmers perogative. Accepting it when the manager comes back and says "what we have now works, our customers arn't complaining, the thing is end of life in 2 years, and even if this made future maintenance free it wouldn't be worth it" is a reality.

          • by Anrego (830717) * on Thursday January 10, 2013 @03:28PM (#42549569)

            Forgot to add, this guy put it way better than me a while ago (yes, I bookmark slashdot comments that are particularily helpful.. it comes in useful surprisingly often):

            http://ask.slashdot.org/comments.pl?sid=1932550&cid=34743614 [slashdot.org]

          • Technical Debt (Score:5, Interesting)

            by Anonymous Coward on Thursday January 10, 2013 @03:52PM (#42549971)

            We always see bad code as technical debt and treat it as debt. When we have cycles we pay it off, when we don't we get some more.

            Having been doing this for 12+ years, I have come to realise I have never liked anyone's code and figured out its more of a style or personality than bad or good. Yes there is bad code, but there is no good code per say. Or put another way, if done right its good and you and I still may not like it.

            Its just the nature of the beast, its kind of like driving a car, all other drivers seem bad.

            • Re: (Score:3, Informative)

              by Anonymous Coward

              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 a

            • Re:Technical Debt (Score:5, Insightful)

              by MozeeToby (1163751) on Thursday January 10, 2013 @06:13PM (#42551727)

              Sometimes I don't even like my own code if I'm coming back to it a year later. It's just the nature of the game. What looks 'good' and 'right' to you changes based on what you know about coding, what problems you've encountered, what you know about the project, what you know about the budget, etc, etc.

          • by Nemesisghost (1720424) on Thursday January 10, 2013 @04:01PM (#42550127)

            This is what a lot of idealistic programmers who are just out of school fail to realize. We should be able to remember that all the code we wrote in college had to be perfect, without any flaws. At the same time, most of these programs were fairly small(

            Another problem arises when you have an older developer who is forced to learn new tech where the best practices are drastically different from those he/she is familiar with. For example, if all you've ever done is procedural code(which is what most of my college classes did), and you are tossed into a situation where most of your coding is layered event driven the best practices between the two are so different that you are bound to make mistakes. What I've then see happen in situations like this is that a new developer comes along & sees where there are places that the best practices aren't being followed 100% of the time, and therefore assumes all the code must be crap. Instead, what should happen is the new developer should look at why something was done the way it was & work with the responsible party(not necessarily the original developer) and see if there's a good reason to "fix" the bad code.

            Currently I work with a great set of managers. They understand the cost of any project and are very good at prioritizing "fixes". They know that some of the early development doesn't work with the things we are now trying to do, and are will to let us go back & fix things. But they also know that we don't have the resources to fix everything, even things that might reduce the errors & crashes. I have a fellow developer that not fixing everything drives him crazy, and that was one of his first lessons. Nothing's perfect, nothing will be, and our job is do the best we can & worry about the problems only when we are told to.

          • by AlphaWolf_HK (692722) on Thursday January 10, 2013 @05:57PM (#42551563)

            There's also the matter of rewriting things introducing new bugs and getting the "so what good did it do to rewrite it when the new code doesn't work?" element. Worse is when the new bug is difficult to reproduce or troubleshoot.

            Sometimes it is just best to let sleeping dogs lie, and do something better with the next product.

        • So where are all these bosses with "good management skills"? I haven't seen it since the early 90's. The long term effects of code that doesn't suck do not seem relevant to any manager's career goals, apparently.

        • by n7ytd (230708) on Thursday January 10, 2013 @04:50PM (#42550765)

          The boss is interested in the long term effects of having code that doesn't suck, such as lower maintenance time. If the boss wouldn't care when directly told this, that just shows he has bad management skills.

          Rewriting is very often the last thing to do with working code. IChucking out working code and reproducing it usually involves relearning all of the reasons those last guys did it that horrible way.

        • by Junta (36770)
          The rub being that in many of these circumstances, it's one developer's word against anothers in terms of what's more 'maintainable'. In one corner you have a software developer who is a veteran for your company, in another a likely recent college grad still brimming with less-than-practical ideals intact still yet.

          If you have a long term codebase that has been managed by people that have come and gone, no rewrite or refactoring should be embarked upon lightly. If the codebase isn't subjecting the busines
      • 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.

        This is the reason most software is terrible.

  • Old problem (Score:5, Insightful)

    by Anonymous Coward on Thursday January 10, 2013 @02:51PM (#42548949)

    This is an ancient problem, with 10 years experience I'm amazed you haven't run into this constantly throughout your entire career. New guys (even old guys) perceive everything they didn't write as shit.

    How you deal with it is dependent on a lot of things.

    First: is he right? Maybe your code does suck. Hell maybe you suck! At minimum. code that has been around for a while, has been written by multiple people over a long period of time, been adjusted and re-worked to meet changing requirements, and been done under a deadline usually does suck at least a little. Admitting this is hard.

    New guys want to re-write everything and don't understand the value of code maturity... most of the time a re-write isn't practical, and even the shittiest code usually attains remarkable stability by virtue of having all the bugs pounded out through years of use. Reminding him that this isn't a university project and a certain level of ugliness should be expected might help.

    If you don't think he's right, learn how to properly describe why you do things the way you did, and conversely expect him to explain why they are wrong. This is the biggest thing to learn when doing code reviews, and applies here. If you can't objectively describe what is wrong using with references to either standard or internal best practices or conventions, arguing code ugliness just becomes subjective. If you want to defend your code, learn how to describe how it doesn't suck.

    Having some company guidelines will really help, because it gives you something to point at in defending a decision. Ultimately what one guy considers good code may be considered bad by another. You are always going to have cases where someone thinks your code is too abstract, or not abstract enough, or sacrifices too much performance for maintainability, or too much maintainability for performance. At least with standards, the new devs will rail against the standards rather than personally attack you, and a standards document is a lot easier to defend (and yet still allows good changes without too much politics of hurt feelings).

    • Mod this up! (Score:5, Insightful)

      by ganjadude (952775) on Thursday January 10, 2013 @02:54PM (#42549003) Homepage
      Might as well close the forum down, this is gonna be the best answer concerning this issue. if only I had mod points
    • Re:Old problem (Score:5, Insightful)

      by N0Man74 (1620447) on Thursday January 10, 2013 @03:19PM (#42549425)

      Good answer.

      Your keyword "deadline" didn't really get the emphasis it deserved. I know that I've been guilty of writing some pretty shitty code (and fully realizing it) because I simply did not have the luxury of the time to "do it right".

      Sometimes this is because I made a bad assumption early on. Sometimes there was a surprise change in the specs that didn't mesh well with the design. At times, it is because I'm working in unfamiliar territory and still learning about some aspect of the project. Sometimes it is because I am working with existing bad code someone else wrote (possibly because of one or more of the same previously given reasons), and I have to do my best to work within an existing bad implementation.

      In the real world, sometimes you have to make the choice of doing things right, or actually getting them done.

      • Re: (Score:3, Insightful)

        by Zero__Kelvin (151819)
        You sir, and people like you, are the reason why the software industry is comprised of mostly incompetents these days. If there isn't time to do it right, there isn't time to do it at all, and it was your job to make that clear to management. The industry is flooded with people who don't have time to do it right, but do it anyway, and wind up with Garbage. This is the reason why the Linux Kernel is far superior to Windows. In Linux kernel development, there is always time to do it right, because Linus k
        • Re:Old problem (Score:5, Insightful)

          by Catskul (323619) on Thursday January 10, 2013 @11:12PM (#42554301) Homepage

          While a virtual disregard for a deadline is a big part of the reason that Linux kernel is as good as it is, that does not mean that quality first is the only way to go, and even the Linux kernel has plenty warts that were compromises. A kernel requires a level of perfection that very few other types of software require. There is a vast range between that and, for example, a convenience shell script.

          It's mature developers who both, know how to create high quality software, and also recognize the value of trading perfection for many other goals at the right time who are the most valuable. And Linus Torvalds is one of them. RMS probably is not.

          I, and I'm sure many other highly skilled developers, find your assertion, that anyone who compromises quality as incompetent, insulting but more importantly, wrong.

          • Re:Old problem (Score:4, Insightful)

            by Zero__Kelvin (151819) on Friday January 11, 2013 @08:25AM (#42556427) Homepage

            "I, and I'm sure many other highly skilled developers, find your assertion, that anyone who compromises quality as incompetent, insulting but more importantly, wrong."

            Most likely you don't understand the term quality. Might I recommend that you read Zen and the Art of Motorcycle Maintanence, or re-read it if you have already done so? Any developer who sacrifices quality is incompetent by definition; that holds doubly true for those who know they are doing it and do so anyway. .

      • Re:Old problem (Score:4, Insightful)

        by DragonWriter (970822) on Thursday January 10, 2013 @07:04PM (#42552357)

        In the real world, sometimes you have to make the choice of doing things right, or actually getting them done.

        In my experience, in the real world, the invocation of this phrase is usually used as justification for doing things in a manner that is so bad that what is actually done doesn't actually qualify in any meaningful way as doing the thing that was supposed to be done at all, although it often has enough of the superficial appearance of doing so that the people involved might reasonably hope that they will be out of the radius of accountability when it is realized that what was supposed to be done wasn't done.

        So when I hear it, I mentally translate it into "in the real world, sometimes you have the choice between admitting that things can't be done as requested with the resources alotted and pretending that they can and hoping not to be held accountable when the failure is revealed."

    • Re:Old problem (Score:5, Insightful)

      by LordNimon (85072) on Thursday January 10, 2013 @03:26PM (#42549529)

      New guys want to re-write everything and don't understand the value of code maturity

      I've been working in this industry for 20 years, and I've never experienced this. Instead, the "new guy" is intimidated by me because I'm constantly explaining things to him, and he quickly realizes that he doesn't know anything.

      • Re: (Score:3, Insightful)

        by Anonymous Coward
        The fact that you explain things means you understand what you're doing. A lot of people who can't explain things don't really know what they're doing so they get defensive anytime anyone questions them.
    • Re:Old problem (Score:5, Interesting)

      by gatesstillborg (2633899) on Thursday January 10, 2013 @03:29PM (#42549577)
      I disagree with this "perceiving everything they didn't write as shit" stance.

      I came into a new position, my first serious one (when I was in my forties, second career field, after a couple years of good community college studies). I have experienced in depth 3-6 (3 thorough exposure, 3 partial/peripheral exposure) different, substantial code bases. Two of them where horrendous ("devil spawn"), one was not exactly a work of art, but manageable, managing considerable (reporting and logging) complexity, and the other 3 were solid to the point of being elegant, and naturally readable. And mind you, this was my first serious in depth exposure, across a variety of development platforms, including both proprietary and open source.

      "Man is the measure of all things." -Protagoras
    • by fermion (181285)
      This is good. I was in a situation with some legacy code a while back. It was crap because of the changes that had been made over time. This was when I had about 15 years of code experience, about 5 of it in a formal team situation. I sat down for a few weeks, tore out old stuff, reworked the stuff that was left, and came up with a new product. What I forgot to mention was that it fixed many complex and long standing bugs.

      So this the first thing I would add. It the problem with code that it is not p

    • by jhol13 (1087781)

      Shittiest code does not attain stability because "all the bugs" have been removed. More often it attains stability because it cannot be changed, the odd undocumented bug-like "feature" can be the expected behaviour by some client which you really cannot change ('cause you'd end up in an avalanche).

      Then what I have noticed is that new code is usually bad: when you implement something, integrate and test you'll usually notice how to do it better. But then it might be too late to rewrite it.

      Old coding practice

    • by japhmi (225606)

      First: is he right? Maybe your code does suck.

      I'm thinking of a case I've been in. The code didn't necessary suck, but it was almost completely uncommented. Maybe Mr. "I have 10 years of experience!" should go back and comment his code so the new guys can understand what's going on.

  • Very simply (Score:5, Insightful)

    by houbou (1097327) on Thursday January 10, 2013 @02:52PM (#42548957) Journal
    Critique is only as good as the suggestions for improvement. So, that's your answer. I feel that if someone has issues with my code, then show me better and prove me it is better. In the end, clarity, code reuse, design patterns, performance, all of these things come to play.
  • Is he right? (Score:5, Insightful)

    by AdamStarks (2634757) on Thursday January 10, 2013 @02:53PM (#42548985)

    Take a step back and seriously consider his criticism, as if he were one of your 10+ year coworkers. Whether or not he's right informs the right reaction.

    • by Anonymous Coward on Thursday January 10, 2013 @02:58PM (#42549075)

      Maybe, but we know that he posts to Slashdot as well. [slashdot.org]

    • by flatt (513465) on Thursday January 10, 2013 @03:03PM (#42549149) Homepage Journal

      Whether he is right or not is immaterial. Now is the time to assert your dominance. Sucker punch him and urinate on him while he's down to put him back in check.

      • by Anonymous Coward on Thursday January 10, 2013 @03:32PM (#42549631)

        This works and it's a good fundamental method, but it's not extremely efficient.

        I typically like to hire them in a groups. Initially, lay quiet and see who is the more uppity of the bunch. Let him have his moment in front of the new kids and really start to build an alpha status for himself.

        Shortly there after you really want to just casually stroll up to the fresh example and just stab him in the kidneys a few times. This will deal with the problem candidate and build your reputation as someone who gets things done. In fact, it is unlikely anyone will question your authority for some time.

      • by rahvin112 (446269) on Thursday January 10, 2013 @03:36PM (#42549695)

        We are primates, the proper response is to throw poop at him.

        • by Jeng (926980)

          You just made me consider something I have never thought about before.

          Do wild monkeys throw poo?

          I would think that the ones in zoos throw poo because they can't actually get close enough to rub it in your face and then bite your face off.

    • By definition your code sucks, because it's legacy code and you wrote it.

      So what? Does it work? Does anyone want to fuck with it? Is he willing to risk his job to change the code and break everything?

      New developers want to rewrite everything, and don't understand that new projects don't happen often - and when they do, they don't get to work on them unless they have skills. That doesn't mean they need to kiss ass, but it does mean that they have to write code that works.

      Maybe there -is- a better way to writ

    • Re:Is he right? (Score:4, Insightful)

      by AK Marc (707885) on Thursday January 10, 2013 @03:31PM (#42549623)
      I've never seen anyone right on this issue (the ones that are actually right quit and go someplace else, solving the issue, after all, would you want to work somewhere where all your coworkers were wrong all the time? I worked there once, and I quit and got a much better job elsewhere). It always boils down to "I would have solved this differently, so your way is wrong.

      It's a geek problem. There's often more than one right answer. You can't always get a single correct answer for every question. And that confuses and frustrates people new to some areas where it's true.
    • Re:Is he right? (Score:5, Informative)

      by dubbreak (623656) on Thursday January 10, 2013 @03: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 Darinbob (1142669)

        Then ask what the junior programmer's job really is. Is his job to critique all the other code, or is his job to get a particular set of bugs fixed and features implemented?

        One of the harder things to learn is how to give up idealism and replace with pragmatism. Ie, you have deadlines which means you get the code done even if it's not perfect; you code the feature that the customer wants even if you think the customer is wrong; you eventually start fighting the boss and do what you're told; etc.

  • Fire him (Score:4, Funny)

    by Anonymous Coward on Thursday January 10, 2013 @02:53PM (#42548987)

    Firing him might be the best lesson he ever learns...

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

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

  • by Qubit (100461) on Thursday January 10, 2013 @02:56PM (#42549033) Homepage Journal

    < insert witty song about geeky stuff here >

  • 4 o' clock (Score:4, Funny)

    by Anonymous Coward on Thursday January 10, 2013 @02:59PM (#42549101)

    outside, at the gate.

  • bad code offsets (Score:3, Interesting)

    by themusicgod1 (241799) <themusicgod1@NOspAm.zworg.com> on Thursday January 10, 2013 @03:00PM (#42549103) Homepage Journal
    And ask him what you can do to improve yourself? Do so in a way that gives him work to do in correcting you. But either way...offer to buy bad code offsets [codeoffsets.com]

    You can always learn, and the world can always stand to benefit from more people offsetting their Bad Code.
  • by jeffmeden (135043) on Thursday January 10, 2013 @03:01PM (#42549119) Homepage Journal

    And a follow up question: do you have any internship openings?

    Seriously, if he was hired as an intern I take it he has little/no real experience, and may not have even finished his formal education. He thinks your code is bad because it doesn't look like the code of whatever professor he most admired in school, or it violates some rule of some particular coding sect that he subscribes to. Tell him to write his objections down in a safe place, and come back to them after a year of working "for Real" and you will gladly sit down and listen to what he has to say then.

    • by ByOhTek (1181381) on Thursday January 10, 2013 @03:08PM (#42549211) Journal

      It's also possible the younger coder learned a trick developed since the older coder got his skills fairly solidified, and the older coder never saw, or came up with in his own experiences.

      Just because the new guy is disagreeing and less experienced, doesn't make him wrong. Yes, 9 times out of 10, the new, less experienced guy will be wrong, but that 1 time out of 10, makes it worth giving the other 9 times a fair hearing as well.

      • by dubbreak (623656)

        Just because the new guy is disagreeing and less experienced, doesn't make him wrong. Yes, 9 times out of 10, the new, less experienced guy will be wrong, but that 1 time out of 10, makes it worth giving the other 9 times a fair hearing as well.

        I honestly don't think "experience" has anything to do with it. How long you've sat in front of a computer monitor doesn't directly translate to your understanding of software development. I've worked with a few guys with 15+ years experience. One created more work than he produced over 6 months (we were cleaning up shit from him a year after he was canned), another whom I bitched about in the last question really had no fucking clue how to structure code. He'd write stuff that "worked", but basically misus

  • by ByOhTek (1181381) on Thursday January 10, 2013 @03:01PM (#42549131) Journal

    I would be as blunt, harsh and straightforward back to him, as he is was me, were I in your shoes. I might add a few nails to the coffin of the argument.

    Him: "Your code sucks."
    Me: "Back it up. What suck why."
    Him: *explanation*
    Me: "Well, I can understand you not realizing X, Y, and Z, being new and ignorant, but give it a few years."

    Him: "Why'd do you do [pattern X, Y, Z]? Isn't it better to do [pattern A, B, C]?"
    Me: "In certain circumstances, sure, but in [insert current circumstances and logic for X, Y, Z], this methodology works better."

    Put him in his place if he needs it, otherwise, just educate. Also, listen - just because he's less experienced than you doesn't mean he hasn't picked up something useful. I know a lot of people who think they don't have anything to learn from the new guy, when the new guy had a few tricks up his sleeve. I've been one of those people who's learned from the new guy he didn't suspect. I've also been the new guy with unsuspected tricks.

    • Re: (Score:3, Informative)

      by ByOhTek (1181381)

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

      • I definitely try not to make typos when having a verbal conversation. You're right-- it does help.

      • by neurovish (315867)

        I think the "what suck why" phrasing goes an extra step into emphasizing the dismissive attitude. His objections are so far beneath you that he does not even deserve the time it takes to create a properly formatted sentence with all of those useless articles.

    • by caywen (942955)

      Templated examples. I like it, we should do more template meta posting.

  • by SternisheFan (2529412) on Thursday January 10, 2013 @03:02PM (#42549143)
    I thought if you were supposed to call in sick if you had a bad code. :-)

    *ducks*

    • Re: (Score:3, Funny)

      by Anonymous Coward

      I thought if you were supposed to call in sick if you had a bad code. :-)

      *ducks*

      I got debug bad.

  • by VoidEngineer (633446) on Thursday January 10, 2013 @03:03PM (#42549151)
    Recently went through this myself. Despite having used a kanban board, used version control, commented code, written unit tests, etc, some junior devs thought the code sucked. My takeaway was that there were still too many barriers to entry. Too many passwords, not enough installation instructions, etc.

    Somewhere in the process of learning to write production ready code, it occurred to me that it was necessary to work the process backwards. Begin a project by setting up your hosting or distribution environment before starting to code. Write unit tests before starting to code. And so forth.

    Getting other people to contribute to your project requires the same kind of thinking. Set up a project page before you start to code. Write a vision statement before you start to code. Write installation instructions, coding style guidelines, and operations support instructions before you start to code. That way, as you proceed in the project, you have clearly build up the documentation that other people are going to need to join your project. These things shouldn't be started after the fact.

    If you can't point a new dev to a website and say 'download the source and instructions' here, it's probably too complicated and will meet resistance.
  • A good opportunity (Score:5, Interesting)

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

    From your description, the guy isn't mean spirited. He's likely never had to deal with multiple revision code bases before.

    On the other hand, if this is code that has been through multiple revisions and re-purposes, admit to yourself -- it probably is bad. I'm the lead engineer and dir. engineering at a company I've been at for 10+ years, and I'll be the first to tell you that the code-base I am most proud of (30-50k lines of embedded/DSP code, mostly mine) is TERRIBLE! I wouldn't wish that code-base on my worst enemy. But its also been bread and butter for the company for the last decade and is stretched to its limit.

    We've had at least two hotshots come onto the project in that time who have been terrified seeing that code-base and declaimed it as schizophrenic at best, and they are right. It is bad code, poor coding practices, and everything else bread out of necessity to keep the project(s) going and alive.

    Your mission -- accept that whatever reasons are out there for the code being the way that it is, it probably is poorly structured and could use a rewrite. SO - this is a good chance for him to learn that not every bit of code that should be rewritten can be. Its called business reasons and experience. Whatever the reasons, you probably, as a company, don't have the time or resources to rewrite from scratch (we surely don't!), but a fresh out of school developer probably has not experienced these -non-engineering- reasons for bad code, and certainly was not there for the blood, sweat, and tears that went into them. He won't know about those all nighters that "saved the company" that you and the rest of the team probably went through en-route to this codebase.

  • Don't be a dick (Score:4, Insightful)

    by uepuejq (1095319) on Thursday January 10, 2013 @03:07PM (#42549195) Homepage
    Ask him how he would do it, and be genuinely interested in his response. Maybe he just wants to beat his chest a little, and maybe he'll even say something useful.
  • by dbc (135354) on Thursday January 10, 2013 @03:07PM (#42549201)

    I'm sure if he re-reads your internal design specifications, coding standards, and comments in the code he will understand your design.

  • by PolygamousRanchKid (1290638) on Thursday January 10, 2013 @03:09PM (#42549227)

    . . . are really just not satisfied with themselves.

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

    • by gstoddart (321705) on Thursday January 10, 2013 @03: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.

  • by scorp1us (235526) on Thursday January 10, 2013 @03:13PM (#42549293) Journal

    Well I am back at the place where I was 10 years ago. I thought the code was great then, I think it is shit now.

    But what I've learned in the intervening time, and having been a software development manager myself, is that code is optimized on a few axis:
    - Brevity (get er done!)
    - Clarity (I'll be able to read this again in 5 years and understand it)
    - Structure (Object models)
    - Formatting
    - Efficiency

    All of them factor into a meta category, which I call "Maintainability", where you want high clarity and structure. Maintainability is by far the most important aspect to an organization. Your n00b developer won't have your company's maintainability desire in mind. Efficiency is the dead last because increased computing power is cheaper than the development time to make it efficient, save some scenarios.

    So my recommendation is to have him rate his code on those axis and your code on those axis. Hopefully he'll learn there's more than one way to code. It is very likely he's just out of school and his head is filled with registers and asymptotic running times. Those are important, but not as important as shipping maintainable code on time.

    • by PRMan (959735) on Thursday January 10, 2013 @03:42PM (#42549787)

      I've said this at several workplaces:

      What the Business values:
      1. Correctness
      2. Reliability
      3. Maintainability
      4. Speed
      5. Coolness

      What the Developer values:
      1. Coolness
      2. Speed
      3. Correctness
      4. Maintainability
      5. Reliability

      Don't believe me? Look at practically ANY open source project. Most are unreliable and impossible to contribute to. They are often incorrect, but they are usually fast and the programmer always thinks what he's doing is mega-cool.

      Developers need to adjust their mindset to be valuable to the business, but sadly most business code looks more like the second list than the first.

  • by gweihir (88907) on Thursday January 10, 2013 @03:24PM (#42549489)

    The only way to deal with this professionally, is to look at his complaints in detail and either refute them or acknowledge them. Code quality is an area that cannot tolerate any power games. Have him actually explain in detail why he things some piece of code is bad and then explain to him why it is not, or why there are external circumstances that require it to have the form it has. Make that perhaps a repeated session, until one of you learns something about their coding skills. Go into this open and with a pure technical PoV. If he should happen to be right, then he is right. If not, you have to be able to explain why. That will also deal with the most common source of this behavior: The younger person feels under-appreciated and not respected.

    If that approach goes nowhere because he cannot admit limits in his skills or is unwilling to learn, escalate to management. But make very sure the problem is not on your side before you escalate. Typically, escalation will not be needed, but some junior engineers are so convinced of their own superiority, that they cannot see anything else and cannot learn. I had that twice. In one case it resulted in the termination of the lady in question. That one was so set in her ways, she was not even willing to implement an interface designed by somebody else, but could not explain why it was bad. (It was not. She was just not able to implement anything not of her own design.) Zero team-working skills and zero ability to learn. It happens and it is not your job as a developer to resolve it.

  • Define "bad" (Score:5, Insightful)

    by SirGarlon (845873) on Thursday January 10, 2013 @03:24PM (#42549495)

    As an engineer, I've adopted the maxim that there is no good and bad, only fitness for a particular purpose. I prefer a discussion of trade-offs to statements of principle.

    I tend to ask "what requirements does this code fail to meet?" And very often, the reviewer has invented his own new requirement! Depending on your process, your response might be anything from "good point, let's add a test case for that" to "you should submit a Requirements Change Form for that. Make sure to get all the required signatures."

    And if the criticism is for something immeasurable like "readability" or "maintainability" you can let your critic make the case to the boss why fixing this code is worth the cost.

  • by tomzyk (158497) on Thursday January 10, 2013 @03:29PM (#42549571) Journal

    stare him directly in the eyes and, in an outrageous French accent, curtly state "MIND YOUR OWN BUSINESS!"

  • by AlienSexist (686923) on Thursday January 10, 2013 @03:30PM (#42549617)
    "You dare insult my code!? I'll kill you where you stand!"
    • by H0p313ss (811249)

      An oldie but a goodie:
      http://gradha.sdf-eu.org/textos/klingon_programmer.en.html [sdf-eu.org]

      Top 20 things likely to be overheard if you had a Klingon Programmer:

      • Defensive programming? Never! Klingon programs are always on the offense. Yes, offensive programming is what we do best.
      • Specifications are for the weak and timid!
      • This machine is GAGH! I need dual Pentium processors if I am to do battle with this code!
      • You cannot really appreciate Dilbert unless you've read it in the original Klingon.
      • Indentation?! - I will show you how to indent when I indent your skull!
      • What is this talk of 'release'? Klingons do not make software 'releases'. Our software 'escapes' leaving a bloody trail of designers and quality assurance people in its wake.
      • Klingon function calls do not have 'parameters' - they have 'arguments' -- and they ALWAYS WIN THEM.
      • Debugging? Klingons do not debug. Our software does not coddle the weak. Bugs are good for building character in the user.
      • I have challenged the entire ISO-9000 quality assurance team to a Bat-Leth contest on the holodeck. They will not concern us again.
      • A TRUE Klingon Warrior does not comment his code!
      • By filing this bug report you have challenged the honor of my family. Prepare to die!
      • You question the worthiness of my code? I should kill you where you stand!
      • Our users will know fear and cower before our software! Ship it! Ship it and let them flee like the dogs they are!
      • Our competitors are without honor!
      • Python? That is for children. A Klingon Warrior uses only machine code, keyed in on the front panel switches in raw binary.
      • Klingon programs don't do accountancy. For that, you need a Ferengi.
      • Klingon multitasking systems do not support "time-sharing". When a Klingon program wants to run, it challenges the scheduler in hand-to-hand combat and owns the machine.
      • Perhaps it IS a good day to die! I say we ship it!
      • My program has just dumped Stova Core!
      • Behold, the keyboard of Kalis! The greatest Klingon code warrior that ever lived!
  • by SirGarlon (845873) on Thursday January 10, 2013 @03:48PM (#42549893)

    The first problem is that you regard the code as "yours" rather than "the project's" or "the company's." Engineering discussions should not be personal, and getting emotionally attached to the code is unlikely to help you evaluate it objectively.

  • Years ago (Score:4, Funny)

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

    Years ago I worked with a senior guy who was very good but very critical of everyone else's code, often for poor reasons. One day I showed him some code and asked his opinion. He starts ripping on it and asks me why I did it that way. I reply "You tell me, this is your stuff from a couple years ago.".

    • by neminem (561346)

      Oh, to have some mod points right now... You'll have to accept this virtual "+1 Funny" instead.

  • by TimTucker (982832) on Thursday January 10, 2013 @04:25PM (#42550509) Homepage

    Quite a while back I came across the following two rules for development:

    1. The code written by the guy who came before is junk.
    2. Eventually you will be "the guy who came before".

    Rule #1 tends to work because it's rare to be unable to find some way to improve code when you come back to it again with more experience or a fresh perspective.

    Rule #2 helps keep you humble.

  • Your code IS bad (Score:4, Insightful)

    by wcrowe (94389) on Thursday January 10, 2013 @04:50PM (#42550761)

    Your code IS bad. I know this because it doesn't look like my code.

  • by Arancaytar (966377) <arancaytar.ilyaran@gmail.com> on Thursday January 10, 2013 @05:09PM (#42550965) Homepage

    That this and the linked story are really about the same two coders.

  • by spatley (191233) <spatley@yahoo.com> on Thursday January 10, 2013 @05:22PM (#42551119) Homepage
    just show him this http://xkcd.com/844/ [xkcd.com]
  • by AmazingRuss (555076) on Thursday January 10, 2013 @06:43PM (#42552113)

    Fasten your teeth in his trachea, and pull your head back backward sharply until the trachea comes free from the body.

  • by jmactacular (1755734) on Thursday January 10, 2013 @07:52PM (#42552749)

    My top 3 practical criteria to judge whether code is "good" or not.

    1) Performance. How fast does the application actually run.

    2) Complexity. How many layers and levels and do you have to trace down into to debug something.

    3) Flexibility. Can it be modified easily as new change requests come in.

"Trust me. I know what I'm doing." -- Sledge Hammer

Working...