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?"
After all, he's fresh from a CS program where they taught him everything.
What political party do you join when you don't like Bible-thumpers *or* hippies?
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).
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.
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.
Firing him might be the best lesson he ever learns...
You Are Not Your Code: http://sstephenson.us/posts/you-are-not-your-code
Ask Slashdot: How Can I Explain To a Coworker That He Writes Bad Code?
Might as well close the forum down, this is gonna be the best answer concerning this issue. if only I had mod points
have you seen my sig? there are many others like it but none that are the same
< insert witty song about geeky stuff here >
coding is life
outside, at the gate.
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
You can always learn, and the world can always stand to benefit from more people offsetting their Bad Code.
GENERATION 26: The first time you see this, copy it into your sig on any forum and add 1 to the generation.
And then reality strikes when management says "NO" to these suggestions.
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.
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.
Self proclaimed typo king, and inventor of the bear destroying coffee table (patent not pending).
*ducks*
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.
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.
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.
I'm sure if he re-reads your internal design specifications, coding standards, and comments in the code he will understand your design.
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.
Self proclaimed typo king, and inventor of the bear destroying coffee table (patent not pending).
. . . 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 . . .
Schroedinger's Brexit: The UK is both in and out of the EU at the same time!
Sounds like he wants to be a big boy. Put him in your shoes with an incredibly challenging and time-sensitive project (real or fake). Then start changing the project requirements every week/day at random. In my experience this is how shitty code gets made (other obvious way is person is inexperienced).. If his code works and looks great and is bug free, maybe you'll learn something, if not, maybe he will..
yep.
What next? "I am some code. How do I tell my new maintainers they suck?"
Signature v3.0, now with 42% less memory usage.
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.
Slashdot's rate-of-post filter: Preventing you from posting too many great ideas at once.
Yeap. If you have 50,000 lines of code, and it isn't clear how to enter it and begin to understand it, then the code sucks. It might be good in other ways, but in at least one crucial way it's bad.
"First they came for the slanderers and i said nothing."
This questioner says he's been at the company 10 years and the new kid is hassling him. That prior question says the guy he's hassling has been at the company longer than the hassler has been alive. If they've hired a 9 year old as a coder then they deserve all the atttitude they get.
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 write it now. It'd be worth it to ask. Maybe he's right? Most likely he's has no context - it's written that way because it was written that way. Maybe he can rewrite it in his spare time and show everyone.
NOTE: if he was able to read your code and said it sucks and should be refactored or something, that means the code doesn't suck as much as he said it does - because he could read and understand it. That means that it's maintainable. So that's a plus on your side.
There is no excuse for anyone looking at your source code to not understand it.
That's a ridiculous statement and standard. Lack of experience or knowledge of the problem domain is often a reason why people won't understand code. Now the code might genuinely be poorly-written, but just because newbie hot shot doesn't understand it doesn't mean it's bad.
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.
Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
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.
[Sir Garlon] is the marvellest knight that is now living, for he destroyeth many good knights, for he goeth invisible.
stare him directly in the eyes and, in an outrageous French accent, curtly state "MIND YOUR OWN BUSINESS!"
Karma: NaN
Management won't say "no". They'll say, "That sounds good. Do it, but don't change the date for our next release." And everyone will hate the new guy forever.
cogito ergo dubito
"You dare insult my code!? I'll kill you where you stand!"
How to react to the coworker who complains to you that a coworker thinks that his coding is bad.
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.
[Sir Garlon] is the marvellest knight that is now living, for he destroyeth many good knights, for he goeth invisible.
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.
That's easy.
Perform a Core Dump.
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 misused every concept in computer science. No one could follow his code and there was no clean way to cut it out. I also know plenty of CSc and S.Eng. student that never learned how to code in school. I mean, yeah, they passed assignments that required coding but never really got a grasp on writing software.
On the flipside I've worked with people straight out of school that were as good as experts with plenty of years behind them. The big thing I've seen is there tends to be two groups: people who understand software development and those that don't. People who don't understand can write working code and even create big projects.. but they are hell to maintain and even hell for that person to write. For people that understand, it's a lot more fluid. We all start at the ignorant stage and some get beyond it quicker than others, some never make it out.
I honestly didn't learn to code (as in really code) until late in my degree, but I buckled down and got over the learning curve.. then it all became a lot easier and way more fun. More practice and the fog cleared even more. I think I still have quite a ways to go (as I'm able to recognize those that are much clearer than I), but that's ok as long as I'm dedicated to moving forward and can recognize others are more cognizant and clear and lean on them when I can. Some areas I might be better than others and if they are good they lean on me for that. It feels great to work in an environment like that. Life is hell when you're trying to fix some clueless code.
One other observation I've had is that people that understand tend to code throughout their career. Those that don't quickly move onto non-coding positions (analyst, management etc) and drop coding as quickly as possible.
"If you are going through hell, keep going." - Winston Churchill
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.".
He's an arrogant douche. Get rid of him. Any new kid who has the balls to call existing code terrible to your face is going to be nothing but far more trouble down the line. He already knows everything, and nothing you can say is going to get through to him. It's just not.
Get rid of him if possible, stick him in a little box otherwise. Don't let him work on the good stuff and hopefully he'll leave on his own because he's "awesome". Your bigger fear should be that he won't ever leave...
We have a few of those types in my office, and sadly we don't get rid of them because they have value just being present. It's depressing watching them bounce from project to project because they can't do anything right, and yet think they are god's gift to programming and that we're all just idiots.
Don't take the time to explain jack shit to him. It's been tried here, and they didn't change. People may say I'm too harsh and that everyone deserves a chance. My response is that they don't. People that act like dicks to others like that don't deserve another chance. Their next chance is at another job.
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.
The answer is really simple:
Step 1) Hire a second, unpaid, intern
Step 2) Give all the current responsibilities the 1st intern has to the 2nd intern
Step 3) Have the 1st intern do nothing but beautify your existing code, with the understanding that he can't change how any of it is written.
Your code IS bad. I know this because it doesn't look like my code.
Proverbs 21:19
"How can I stop my employees from fighting over who's the best coder?
I don't care about code one way or another. I own a bakery, all I care about is selling bread. I just hired this CS college dropout because he was my cousin's nephew and I owed him a favor, and the kid turned out to be a good employee. Even suggested we bought a computer for keeping our budget electronically, and that worked out well. So, as I was satisfied with this somewhat bright kid, when I had to replace our janitor, I hired a second CS dropout. The problem is they started disagreeing right away about the most irrelevant things you can imagine and now they bicker all the time, have heated, uncivlized arguments about who is the better coder, what sort of software license works best, their choice of cellphone and whatnot. It's really disturbing the workflow around here. Nothing works properly anymore. For example, I never know whether my computer will have LibreOffice or MS Office installed, which means that at any given day I can open only about half my files properly. My customers are also placing complaints and I'm fed up with the food fights they cause. Can someone tell me how to make them stop or, at least, how to properly discern compatible nerds in the future?"
This is the reason most software is terrible.
That this and the linked story are really about the same two coders.
just show him this http://xkcd.com/844/
Fasten your teeth in his trachea, and pull your head back backward sharply until the trachea comes free from the body.
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.
And did you exchange a walk on part in the war for a lead role in a cage? - Pink Floyd.
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.
And they may have been right - the really bad drivers bring the average down a lot more than the really good drivers bring it up.
Now if you were talking above *median*, then sure, at least 30% of them were wrong
--- Most topics have many sides worth arguing, allow me to take one opposite you.
If you want to be pedantic, please use correct terminology. First, the median is an average, the arithmetic mean another, the mode another, the geometric mean yet another. You probably equate average with arithmetic mean, but that's not strictly true. Second, the central limit theorem proves that for any random variable that has finite (stable) variance the mean and the median are equal. Not sure if 'driver ability' has finite variance, but if it is anything like IQ, length or weight, then yes, the (arithmetic) mean divides the top 50% from the bottom 50%.