Become a fan of Slashdot on Facebook


Forgot your password?
Programming Software

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?"
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:
  • 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).

  • 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.

  • 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
  • by MickyTheIdiot ( 1032226 ) on Thursday January 10, 2013 @02:55PM (#42549023) Homepage Journal

    Give me a freaking break...

  • Re:Very simply (Score:4, Insightful)

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

    It boils down to two questions:

    1) Does it work?
    2) Will I ever touch it again?

    If yes to the first question and no to the second, quality doesn't matter.

  • 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: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.

  • 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.
  • by Jiro ( 131519 ) on Thursday January 10, 2013 @03:06PM (#42549189)

    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".

  • 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 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 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.

  • Re:Very simply (Score:4, Insightful)

    by Ravaldy ( 2621787 ) on Thursday January 10, 2013 @03:15PM (#42549333)

    You can never answer #2 with 100% confidence and if you are a seasoned coder, coding it properly won't be harder than hacking it together.

  • 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.

  • 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.

  • 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: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.
  • 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 marnues ( 906739 ) on Thursday January 10, 2013 @03:58PM (#42550063)
    Given the GP's vitriol, I'm guessing he's one of those self-taught coders who has to deal with someone telling him his code is poor. My experience shows that self-taught coders do write a lot more code, but tend to write it without understanding how it's less maintainable. Us college learners try to write less code that does more, but often end up in the design phase longer than necessary.
  • 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 Synerg1y ( 2169962 ) on Thursday January 10, 2013 @04:38PM (#42550665)
    Anybody who says tell the 1st year intern to rewrite the app cause he doesn't understand better... is pretty much a moron. That's not how you learn, and it's a huge waste of company resources, a lot of coders come out of college over-zealous and thinking they know best... it's the college mentality, you're invincible and on top of the world, doesn't mean you should set them up for failure, esp. w a decade in the biz. What we have is a poor approach and a conflict of interest, OP of ta is probably a dinosaur (10+ years at a company is not the industry trend) who just wants to go home at 5 and not do a single thing not asked of him... which is fine, and a college student who wants to learn anything and everything and probably hasn't been shown much of the humbling QC experience.

    I've had my code criticized before by people who I knew were in a lower league, and all I did was explain it to them proper and I consistently get back "oh, ok" and it's dropped, every once in a great while I may learn a minor thing or two even.
  • Re:Old problem (Score:3, Insightful)

    by Anonymous Coward on Thursday January 10, 2013 @04:47PM (#42550737)
    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.
  • 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 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.

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

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

    Disagree (respectfully), there is such a thing as good code.
    Good code is readable, maintainable, and performs the required function ... (great code is also extensible and/or flexible).
    Bad code is anything else.

    Variations of design, style, elegance or efficiency are the art of coding and being the
    subjective part of the equation determines whether or not a particular person* will like it or not.
    Just because someone doesn't like a particular piece of code or would have implemented it differently doesn't make it bad.

    *yes programmers are people too, no matter how hotly debated that "fact" might be.

  • 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.

  • 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.

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

    by Zero__Kelvin ( 151819 ) on Thursday January 10, 2013 @06:48PM (#42552157) Homepage
    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 knows what a moronic thing it is to do it any other way, and understands what a clusterfuck it would be if they started just hacking things together to get them "out the door."
  • 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."

  • by TapeCutter ( 624760 ) on Thursday January 10, 2013 @07:11PM (#42552427) Journal
    Regardless of where anyone learned to program, I'd ask the kid one question - "You say can't read it, so why should we trust you to rewrite it?" - Then offer him some help to understand it, or sack the arrogant little shit if he's pissing people off with his unwillingness to learn "what is".

    I've been in the game for a long while, I have never seen anyone walk in and comprehend the inner workings of a non-trivial source tree in under 3 months, but I've seen plenty of inexperienced people that think they can. The real problem is that code is much easier to write than it is to read. When a coder rewrites something only one thing is certain, it will be an education for the coder. However that coder is now the SME for that application and other coders will have to try and read his code. An old friend of mine, an excellent coder and all round pragmatist, described this phenomena perfectly with the expression; "Source code is like shit, you can't smell your own".

    Disclaimer: Self-taught coder, BSc CS/OR, 22yrs commercial experience, 28yrs coding experience.
  • 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:Or... (Score:4, Insightful)

    by dintech ( 998802 ) on Friday January 11, 2013 @08:15AM (#42556385)
    One thing you might consider about junior guys is that they often say things like 'this code is crap' not because they really want to change it but because they want you to notice that they're smart. He probably is a bit socially awkward and doesn't get that he's also being offensive. Pretty much he's just trying to prove that he's knowledgeable, knows how to do 'the right thing', is a good coder etc.

    I think the best way to resolve the situation is not to distract him by giving him some greenfield work to do. This give him the scope to prove himself without pissing you off in the process. What you actually think of HIS code is a totally different topic.
  • 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. .

e-credibility: the non-guaranteeable likelihood that the electronic data you're seeing is genuine rather than somebody's made-up crap. - Karl Lehenbauer