Ask Slashdot: How Can I Explain To a Coworker That He Writes Bad Code? 683
An anonymous reader writes "I have a coworker who, despite being very smart, and even very knowledgeable about software, writes the most horrible code imaginable. Entire programs are stuffed into single functions, artificially stretched thanks to relentless repetition; variable and class names so uninformative as to make grown men weep; basic language features ignored, when they could make everything shorter and more readable; and OOP abuse so sick and twisted that it may be considered a war crime. Of course, being a very smart person who has been programming since before I was born makes him fairly impervious to criticism, so even a simple 'Do you see how much better this function is when written this way?' is hopeless. How can I make him see the light, realize the truth, and be able to tell good code from bad?"
You don't (Score:5, Insightful)
Unless he's making your own job a lot harder or you're his boss (or project manager), it's not your place. Your "help" will likely only piss him off more and more and cause problems in the office. Not only will it in *no way* benefit you, but it will very likely *hurt* you and your career--since your manager will come to view you as a source of headaches, your co-worker(s) will view you as a pretentious little prick, and (contrary to popular belief) the guy who helps produce better overall product is almost never rewarded for it anyway. About the fastest way for anyone to piss off their co-workers and bosses is to walk around with a "I'm the best coder here" attitude all day, whether it's true or not. Don't do it.
So, STFU and let management deal with him (or not). That's what they're paid for, not you. Don't offer *any* unsolicited criticism, and even if solicited, offer only a few minor criticisms at a time.
In short: Lighten up, Francis.
short answer (Score:3, Insightful)
He knows something you don't. (Score:5, Insightful)
There's a reason why he's a seasoned programmer and still has a job. Think about it. Who else can maintain that cluster fsck? No one, that's who.
If Bad Code did not exist it would be necessary for Good Coders to create it.
TL;DR: job security
You write code for humans... (Score:3, Insightful)
Since programmers must maintain code, read it, understand it, and write more than work with the existing code, the top priority of code is to be well written, and easy to understand for humans. You maybe can help him take ideas how to make his code better for other programmers.
Re:You don't (Score:5, Insightful)
I disagree. You do this through code review by linking to your team/company coding standards (you do have those, right?).
Also, are you sure that his code is that terrible? It's always possible you just don't understand his way of thinking. Maybe ask him why he wrote something a certain way and go from there.
Not easy (Score:5, Insightful)
Re:You don't (Score:5, Insightful)
"I'm the best coder here"
no, but "you're the best coder here but it would help if you wrote code the rest of us can understand" might work.
Automate! (Score:5, Insightful)
Require that code be run through code analysis and compliance tools that look for the basic things, like function naming, function decomposition, pointer use and other pitfalls.
Then when code reviews come around, you have data instead of arguments and suggestion. "You've got 500 warnings from the code compliance tool. Clean them up before bringing the code to code review."
Code reviews (Score:5, Insightful)
That's what code reviews are for. They aren't to berate someone for writing bad code but identifying as a team areas for improvement (of the code, not the developer).
If you notice a lot of repetition, suggest refactoring common code into a function. Suggest renaming poorly named constructs. Code reviews should be a team effort with backing and consensus of the team with a focus on code quality and not any one developer's ability (or lack thereof).
Make it about YOU, not him (Score:5, Insightful)
RTFM (Score:5, Insightful)
mandatory code reviews (Score:5, Insightful)
Make code reviews mandatory for everyone. If he can't deal with that, he knows where the door is. On my team we use git, and contributors are not allowed to push their own code to the main branch. They must submit a pull request which gets reviewed and pulled by another member of the team.
Re:You don't (Score:5, Insightful)
I completely agree with this. Hyperbole aside, if the coding practices in your organization allow for this, you should discuss them (and not the practices of others) with your management. If the coding practices discourage (or even forbid) this behavior, and your coworker continues to violate them... That's not your problem.
Iff his code does affect what you are working on in a negative way AND it violates coding practices that your organization is enforcing, you could bring it up to immediate superiors.
DailyWTF (Score:3, Insightful)
Post his code to the DailyWTF then send him the URL
Old code (Score:5, Insightful)
You double-down. You take two-year old code that he's writted, and you ask him to walk you through it today. If he can, at reasonable speed with reasonable prep, you lose and you'd better start learning to read his code which conclusively isn't bad it's just different.
Make him fix a bug in his old code (Score:5, Insightful)
Re:You write code for humans... (Score:5, Insightful)
That's nice in theory, but in practice, the "top priority" of code is to meet the deadline and get shipped. Everything after that is secondary.
I've worked in a few places which had some star coder who cranked out endless volumes of shitty, un-maintainable code. And as long as they kept churning out new features and the like, it was fine.
But god forbid that code should need to be maintained or updated -- the original author has moved onto other shiny things, can't remember whatever bit of genius led to the creation, and is often no help in debugging.
This is the kind of thing which is a long-term liability, but overlooked by people with short-term focus.
You can't fix him or his code. You can either cover your ass, or move on somewhere else. And somewhere else is just as likely to have someone of the same ilk.
If management can't/won't rein him in, he'll keep doing it. If he's really been coding longer than you've been alive, you stand no chance -- because either his code is brilliant and you just don't get it, or it's really crap but nobody cares because he can ship a new version on time.
It goes the other way too, I've known coders who were so focused on building something elegant, theoretically good, and built on the latest best practices their code was unusable. Those guys will never actually deliver anything which works, but they'll be able to give you a lengthy discourse on why this code convention is vastly superior to the one you've been using for the last 10 years. And, sometimes, those guys are also horrible at maintaining their code since they can't figure out how it does something any more.
And, since as a group developers tend to be high-strung, self-centered individuals who think they know everything (no slight intended, I used to be the same way) -- there's a reason why it's been compared to herding cats. It takes work to steer coders around, and it sounds like nobody is taking ownership of that where you work.
Re:Automate! (Score:5, Insightful)
In an environment where such a coder is allowed to flourish, I sincerely doubt they have any form of code review.
Re:You don't (Score:4, Insightful)
Did you miss the part where the submitter said his coworker has been programming longer than he's been alive? If some little snot-nosed brat gave me a book on how to be a better programmer, I'd toss it in the trash and use my years at the company to make his life very unpleasant until he finally quit.
crazyjj hit the nail on the head: STFU and GBTW.
Coding is thinking (Score:4, Insightful)
To me, writing code is about expressing and organizing thought processes. Actually, so is the spoken and written language. To improve one's ability to think, improving the use of all language, written, spoken or even programming will invariably improve the process of analyzing and understanding things which fit within those frameworks.
But also, the way people speak, write and code also reflects their current thought processes. A person may or may not be open to such new ideas. Telling a person who speaks "ebonics" about this notion will not likely result in their improved use of English and will not likely result in thought or behavioral improvements. (I know, I have tried... I once attempted to correct someone saying "aks" instead of "ask" and they just hated me for it.) It would also be true of improving coding styles. A person who would be open to such improvements would already be aware of his weaknesses and address them through observation of other peoples' code examples. They wouldn't have to be told. And even if they did, they wouldn't require more than a slight nudge.
Some people want to improve themselves and others believe they are good enough or are simply already the best. There is no hope for the others.
Re:You don't (Score:5, Insightful)
Or not. More than once, the reponse I've seen was the icy equivalent of "Your understanding is not my problem."
Seriously. If there's no violation of actual standards, browbeating someone about coding style is both futile and counterproductive. Even if it's horrible coding style. Without the firm ground of enforceable standards, it's just an unwinnable piss-fest.
As glurgy and trite as it comes across, sometimes the Serenity Prayer [wikipedia.org] is the best answer. Especially the part about wisdom.
Re:You don't (Score:5, Insightful)
The conclusion is to bring it up with your boss (or the team lead) and let them deal with it, deferring to their authority. Show how it's affecting productivity.
Shutting up is a dumb option. Odds are, those with authority over the problem worker are unaware of the issue. If they are aware of it, then by talking to them at least everybody knows where everybody else stands, which defuses a lot of tensions.
Re:Make it about YOU, not him (Score:4, Insightful)
Re:You don't (Score:5, Insightful)
If other programmers can not understand it, then it's bad. Even very intelligently designed code can be awful if no one else can understand it. If you're working in a team then you absolutely must make sure your code is not a burden to your coworkers. Sometimes it's just a matter of putting in comments to explain what you're doing.
Re:You don't (Score:5, Insightful)
And that shows that you're a shitty programmer.
If you're gut reaction to criticism, constructive or otherwise, is to behave like a 12 year old, you are a shitty programmer.
I can say this because my biggest flaw as a developer is responding poorly to critical input from others. I've at least over the years got to the point where my initial reaction may be shitty but I do sit back later and analyze the input to look for truth in it that I may not realize.
I've learned more from CS graduates who have been out of school for less than a year than old foggies like myself. Not because they are über programmers, but because they had a perspective that I could not consider myself, even if their perspective was one of ignorance it almost always helps me be a better developer when I learn how to adapt to their complaints.
This is a process that never ends imho. Writing code to get from point A to point B is brain dead simple. The path you take to get there is what matters.
Re:Not easy (Score:4, Insightful)
Re:You don't (Score:5, Insightful)
The conclusion is to bring it up with your boss (or the team lead) and let them deal with it, deferring to their authority. Show how it's affecting productivity.
Shutting up is a dumb option. Odds are, those with authority over the problem worker are unaware of the issue. If they are aware of it, then by talking to them at least everybody knows where everybody else stands, which defuses a lot of tensions.
When you find a big kettle of shit, it's best not to stir it. If management wants your opinion of your coworkers, they'll ask for it. Otherwise you're the smart-ass who's always making someone's life difficult by bringing up problems that now they've got to deal with.
I'm cynical, of course, but consider this: If management doesn't know who's doing a good job and who's dragging down the team, the problem isn't with unmaintainable-code-guy, the problem is management. Lay low till "unmaintainable" quits or is fired, or a new boss comes in and does "360-degree" reviews or some other comprehensive performance evaluations, or you get transferred, promoted or demoted, or you find a better job and quit, or retire, or die.
Re:You don't (Score:5, Insightful)
It also depends upon if the code is very bad, or just slightly bad. I do see some younger programmers who have a high standard of idealism that collides badly with the real world. A lot of times people work under tight deadlines and they have to cut corners or churn stuff out faster than is good. Sometimes some code does not need to be high quality as well.
It would be highly annoying to have someone fresh out of school blathering on about agile or naming conventions while everyone else is under a high amount of stress. On the other hand, sometimes some veteran programmers really abysmal at what they do, probably having spent most of their career programming alone and then ending up in a very different environment.
In one of my first jobs I was fixing up all sorts of bugs from a programmer who had left. I pointed to some really awful code to someone else who had been there for ages who told me "Dave really loved Pascal. It's a shame that he didn't actually know Pascal."
Easy solution that works - psychological judo (Score:5, Insightful)
Work with, not against, his personality. He thinks he's the smartest guy around. So go with that. He's your new mentor. A few times a week, ask him about YOUR code. Say something like:
Can you look at this function I'm writing, please? Linus Torvalds says that "Functions should be short and sweet, and do just one thing, and they should have more than 5-7 local variables." The Microsoft guidelines say
Ask him if you should make the thingRetriever a separate object from the stuffDisplay in your code. He'll likely eat it right up and never realize that he's actually getting a two minute lecture on a different aspect of code quality each day. If he starts out the day thinking about these things, he'll soon notice when he's writing garbage and his ego won't let him keep putting out garbage for long once he's aware of it.
If, after a month, you see zero improvement in his new code, then ask polite, direct questions about his code as needed. "I'm working on Foo(), what is the "bob" variable?" "Hey John, what does is this function called tp() supposed to do?" (My predecessor actually used "bob" as the name of at least one variable in each project.) Those questions make it explicitly clear that his code is unreadable, so do this only after you've kissed his butt in step #1 for best results.
You paying him? (Score:2, Insightful)
Re:You don't (Score:4, Insightful)
I partially disagree. Part of the problem of why we have so much shitty software is the "It compiles! Ship it!" mentality where no-one gives a damn about writing good, small, beautiful code - which is what happens when you let Finance run the ship. (Conversely letting the Engineers run the company and you will never ship!) This problem is alluding to the holy trinity: Engineering, Finance, Marketing.
Now getting this back on topic: The smart programmer knows when and were to pick his battles. i.e. You could win the battle but still lose the war (i.e. job)
There are a few options the OP has:
* Ignore it
* Embrace it
* Involve management. i.e. "The rest of the team is having a hard time interfacing with Bill's code due to it not being compliant with our coding standards"
* Be very, very, respectful when commenting on criticism so as not to offend / sound like going on a witch hunt. i.e. "Could you help me understand why you wrote your code this way? What advantages/disadvantages does your way have?"
Reading Comprehension, D- (Score:5, Insightful)
Fire him.
Did you miss the descriptive word "coworker" in the parent post ---
or the even more telling phrase "a very smart person who has been programming since before I was born?
This is the new kid on the block.
He is not the boss.
Re:You don't (Score:5, Insightful)
If other programmers can not understand it, then it's bad.
I can't understand most of the kernel source. My C skills are rusty, and I know nothing of kernel design. That means it's my fault, not the kernel hackers'. Is it possible that the submitter isn't seeing the whole picture, and failing to take his own ignorance into account?
Re:You don't (Score:5, Insightful)
And that shows that you're a shitty programmer.
If you're gut reaction to criticism, constructive or otherwise, is to behave like a 12 year old, you are a shitty programmer.
While that's likely true, it does not change the fact that the shitty programmer in this situation is in a position to make the other guy's life a living hell, were he so inclined.
Sometimes you just gotta roll with the punches while searching for an exit.
Re:You don't (Score:5, Insightful)
I'm going to assume that the poster is not an idiot and that this guy really is writing horrible code as described.
What I am mostly hearing here is that the company lacks things like basic code reviews or any kind standards. I cannot imagine how this guys boss is ok with checkins like what the poster is describing. This sort of thing would be caught at any half way decent company.
Sure, this guy sounds bad but it has to be symptomatic of the company having serious issues. Its probably time to find a better job while you still have this one and perhaps at the exit interview you can clue some people into some of these problems.
Or just suck it up and deal, but this likely wont be the last problem.
Re:You don't (Score:5, Insightful)
Re:You don't (Score:2, Insightful)
If that guy worked for me, I would fire him. I don't care how smart he is. I have 15 other programmers who are now less effective because they have to fix this prima donna's shit all the time. Find a good software engineer who is a team player, bring him or her on board, and once they are up to speed, shit can this guy.
Re:You write code for humans... (Score:4, Insightful)
That's nice in theory, but in practice, the "top priority" of code is to meet the deadline and get shipped. Everything after that is secondary.
This. This is exactly why 99% of code written under corporate auspices sucks major ass. Try getting a Director/VP/C-suite to understand why unmaintainable, shitty code sucks and hurts the business. Believe me, I've tried. Maybe 1 in 100 understands. The rest have the same response: "we met the ship date, it works. So what? And by the way, since you can't understand that, you're not an asset to the business. So don't bring me this crap again."
I don't know the answer to that particular debacle, myself - such that I usually just shut up about it and tell the devs working for me that, "yes, you can write shitty code. It will get you a pat on the back from management and a slap in the face by the guys you have to work with every day. Your choice."
Re:You don't (Score:2, Insightful)
Or not. More than once, the reponse I've seen was the icy equivalent of "Your understanding is not my problem."
At one of my first engineering jobs, my boss made it very clear that the things we were building were not the product. The _engineering_work_ necessary to make the build possible was the product. If a new build five years down the road by a different crew was not possible, then you didn't have a product, you just had a very expensive toy. The boxes we built did a job, but we were paid for the documentation we delivered along with it (as well as the documentation we kept in-house). The situation is the same here. Your employer (and depending on the work, your customer, and even their end customers) are no paying you for programs to forestall problems. They're paying you for the knowledge work to solve -- truly solve -- problems.
This, of course, is the ethical aspect, and ignores the more important practical aspect that other people will eventually have to pick up his slack. He'll go on vacation. He'll get sick. He'll die. (If all three happen in the same week, you should also make a note not to go to that resort.) When he says "your understanding is not my problem," he may as well be saying, "why should I care what happens to this company when I'm sick/fired/hit by a bus?" From one perspective, he has a point, but it's the perspective of a terrible employee who you need to get rid of ASAP.
If he doesn't want to talk like a human, accept it and say, "fine, CodeBot 9000: you do shitty work. You steal time from the rest of us. Get your act together, or leave."
Re:You don't (Score:4, Insightful)
Older doesn't necessarily mean more senior developer. I've had to fire somebody who has been programming a couple of decades longer than I have because they weren't up to scratch. I was the one writing the standard too. Call me a snot-nosed brat if you like, but that doesn't change the fact he couldn't get the job done.
There are developers who have 20 years experience, and there are developers that have 1 year of experience that they've repeated 20 times. The two are not equivalent, and just because they've been doing it a long time, it doesn't necessarily mean they are any good at it.
Re:You don't (Score:3, Insightful)
I replaced a guy in a small company who was viewed as a coding genius. I heard the following things numerous times:
* "Luk was a genius."
* "Luk wrote awesome code."
* "Luk wrote genius level code it's no wonder you can't understand it"
* "Maybe we should see if Luk will explain it for us"
* "Well, Luk did it in x time, get better"
Luk was a genius in his own right. He had a very deep understanding of a very small subset of things and anything on the periphery were completely ignored. Not a big picture thinker. (eg. he grew up under communism but voted straight Democrat... WHAT?!) He was also a crafty, deceptive bastard who cut corners where his superiors wouldn't understand what he was doing to make himself look better.
Bringing any of these things to light didn't help matters. Management had a preconceived idea of how things were. The point I'm trying to make is that it doesn't matter what the reality is, what management thinks is paramount and the only reality you need to concern yourself with. If management thinks he's a good coder, that's all he's got to worry about - you're obviously wrong.
That's true (Score:5, Insightful)
As a guy in his mid forties this is very true. The first time you go to a doctor that's younger than you, or get pulled over by a cop that's younger than you and have to call him "sir", you feel it.
The thing is you have to recognize it and fight that impulse. Everyone over 21 is an adult. Remember that. Mozart began composing at the age of five. Einstein came up with some of his best work while he was a patent clerk. Not every good idea comes from someone your own age and station.
And it's especially important in the software industry. Younger guys have an advantage us beginning-to-fossilize programmers don't have. They're *flexible*. They can and will use the newest technology and do things we can't. If you don't listen to the younger folks in this field, you will eventually look like your parents did when they couldn't stop the VCR from blinking 12:00. That's how you'll look.
If a kid gave me a book on being a better programmer I'd read the fucking thing. Ego be damned.
Re:You don't (Score:5, Insightful)
Simplicity and clarity is the mark of an expert.
Re:You don't (Score:4, Insightful)
eg. he grew up under communism but voted straight Democrat... WHAT?!
Maybe you should ask yourself this very question. For example, ponder whether, perhaps, your understanding of what communism is, and how it relates to the platform of the Democratic Party, is deeply flawed.
Re:You don't (Score:5, Insightful)
If you need a problem solved quickly, and better than what all your competitors can do, he's your man.
You have provided one criteria (quickly) but you still haven't defined what "better" is.
Here's an analogy. If you need to perform an amputation, or other rapid operation to keep someone alive (like on a battlefield), is the doctor who can perform that amputation the fastest "the best"? What about if their operation to keep the person alive causes problems with follow-on surgeries or other body functionality? Are they still "the best"?
What drives me insane is that people forget that the vast majority of source code ends up being a living thing. Features are added (or removed), bugs are fixed and it is used in ways not envisioned in the original development. That means someone has to go in and make changes. If it isn't easily understood then (a) it takes longer to make those changes, (b) it is more likely new bugs are introduced and (c) it may be used in a manner that is unexpected (large-scale instead of small scale, and the code is inefficient). What this means in the long run is your code is more expensive to modify and maintain, and it probably won't be as good. How is that a win for the customers, the company, the new developer who has to make changes and our profession in general?
We need to stop glorifying the "gods" of programming, but the average guy who just gets shit done on a regular basis. More analogies: A fighter pilot gets the glory, but the poor guy changing the fluids is just as important - and works on a dozen planes. Same with a quarterback - if an offensive lineman doesn't keep up their end of the work, the entire offense will crumble. It's supposed to be about being a team, and accepting that you have to provide support for the average guy - it is extremely unlikely you will always have a team that is 100% superstar material, so don't act like you do.
Re:You don't (Score:5, Insightful)
The people I'm working with now, well, I'm still making up my mind. They really are geniuses, by which I mean that they're exceedingly smart, blindingly fast, and exceptionally careful in their work. It's hard to fault them, though it's not easy to understand them. And, apart from feeling totally outclassed, mostly I'm in heaven.
There's just one missing piece, and you touch on it in your comment. The best possible code is the most maintainable code. If it takes a genius to maintain it, then you need a reliable supply of geniuses. These, by definition, are in short supply. If the code is unpleasant as well as difficult to maintain, you will have difficulty motivating and retaining those geniuses. All of this serves only to magnify business risk. You would be far better off with genius code that anyone could maintain. But that takes real talent.
Re:You don't (Score:4, Insightful)
Code editors... what a fine idea. Most people seem to agree that "code gods" are both a blessing and a curse to the industry. Couple them with an acolyte or two to do the tedious job of making the code maintainable and the gods could shine again. An excellent way as well to make low- or mid-level coders far more valuable. Once you learn to understand and document brilliant code you'll be in a far better place to write good code yourself. I shudder to think of all the "programmers" I've met who couldn't trace their way out of a paper bag.
Re:You don't (Score:5, Insightful)
I don't even understand why you describe JavaScript as "easy to use". Easy to start using, perhaps. It's probably the same reason PHP is so widely used. Of course wide use means lots of terrible code, most programmers aren't particularly excellent at programming.
JavaScript is highly misunderstood by many programmers, and widely used by people we should properly call non-programmers. Not because of its "ease of use" but because of its wide availability and its position as the front-end web language. Additionally because of widely available, widely used libraries like jQuery that make it simple to do a few things that are simple for non-programmers to reason with. That's not a failing of the language, it's a failing of happenstance.
I've seen some incredible code written in JavaScript. I dare say I've even written some good JS myself. I'm not an idiot, and I quite like the language. There are things I might like to change, but they're few compared to the parts of the language I like. I like it so much, in fact, that I've chosen NodeJS for the biggest project I've ever worked on. It's the best tool for the job, in this case.
But you know... people love to hate JS. I don't want to convince you not to, I really don't care. I don't particularly like being called an idiot as a matter of guilt by association, just as I'm sure you wouldn't like it if I said:
And I am not saying that, except as a tongue-in-cheek reminder that we all live in a glass house and we might be wise not to throw stones.