Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Ask Slashdot: How Can I Explain To a Coworker That He Writes Bad Code?

timothy posted about 2 years ago | from the roofies-in-his-mountain-dew dept.

Programming 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?"

Sorry! There are no comments related to the filter you selected.

You don't (5, Insightful)

crazyjj (2598719) | about 2 years ago | (#42466433)

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.

Re:You don't (4, Funny)

broggyr (924379) | about 2 years ago | (#42466477)

Lighten up, Francis.

Nobody puts Baby in a corner....

Re:You don't (5, Insightful)

Anonymous Coward | about 2 years ago | (#42466519)

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.

Re:You don't (5, Insightful)

coma_bug (830669) | about 2 years ago | (#42466549)

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

Re:You don't (5, Insightful)

idontgno (624372) | about 2 years ago | (#42466901)

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 [] is the best answer. Especially the part about wisdom.

Re:You don't (2)

BitZtream (692029) | about 2 years ago | (#42466947)

Or not. More than once, the reponse I've seen was the icy equivalent of "Your understanding is not my problem."

Which makes him 'not the best coder here' by all intelligent meanings.

Re:You don't (0, Offtopic)

Glendale2x (210533) | about 2 years ago | (#42466551)

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.

If I could I'd mod this straight to the top.

Re:You don't (4, Interesting)

AwesomeMcgee (2437070) | about 2 years ago | (#42466555)

I basically agree here though I still fail to keep my mouth shut. One trick I've learned to not make this problematic is A) hold myself to the same standard; which means publically defame my own work so nobody thinks I'm giving them guff because I know better, and B) hold *all* people equally to that standard, and when they meet it give high praise, do whats in your power to help them (I have actively requested the people be brought into projects they wanted to be on, or generally backed them with my reputation wherever possible when they meet those standards). Result: People know I'm opinionated and in a couple offices this was problematic no lie, in others this was beneficial because managers and other engineers would actively seek me out for my opinions and advice on technical issues, plus engineers liked working with me because they knew if they put the effort in and did well people would hear about it. Basically I'm a loud mouth and that can be good and bad, but if you don't have your mouth indeterminably and unfilteredly attached to your brain, go with what the poster above me suggests. Some of us just aren't so capable.

Re:You don't (3, Informative)

Anonymous Coward | about 2 years ago | (#42466619)

That's a really cynical view. You must work at a really crummy place if that's how concern for long-term code quality is treated.

Where I work, this kind of behavior (helping others with their code quality, even those more senior than you) would be more likely to get you recognized/promoted.

Re:You don't (5, Insightful)

lorenlal (164133) | about 2 years ago | (#42466655)

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.

Re:You don't (3, Informative)

Lisias (447563) | about 2 years ago | (#42466659)

Parent is pretty right. Been there, done that.

I *WAS* my job to try to introduce better practices, but since I was given no authority (i.e.: I can not fire anyone), I just got burnt.

People that was willing to learn better ways didn't need my criticizing, they just looked at my code and adopted the ideas they liked. Eventually almost all of that ideas come to production (and the few that didn't, oh hell, it appears that being a freaking paranoid doesn't necessary makes your code always better, uh? =P)

People that was not willing to learn nothing new just ignored me and, even worst, started to undermine me on the company. Things escalate to a level that I decided that the money wasn't paying the headache.

So, *DON'T DO IT* unless you have the power to lay off bad coders.

Re:You don't (0)

Anonymous Coward | about 2 years ago | (#42466673)

I agree with your general idea that it's pointless to bother, but I heavily disagree with the idea that it's not your "place" to offer criticism of co-workers. Are you just a serf, or a person? A serf feels he has to have a "place", and wouldn't dare do anything outside of that place. A person does what they think is right without regard to their "place".

From the OPs description, it sounds rather pointless to even bother trying. But that's the reason not to bother, not because you live in some kind of indentured servitude where only your betters are capable of offering and advice to co-workers, improving the workplace, or making your job easier (obviously the bad coder makes everyones life more difficult).

Re:You don't (1)

Anonymous Coward | about 2 years ago | (#42466679)

While I agree that most approaches will only lead to failure, bad coders CONSISTENTLY make other engineers' jobs harder. Once the code is written it has to be maintained, and extended. Bad code, particularly someone else's bad code is really aggravating to maintain, and chances are good the job will often fall on the OP.

To answer the OP's question. I've had success by ensuring an environment of code reviews on all checkins. Then getting the bad coder to review your code. Step him through it and show him all the clever things you did, and why you are proud of them, without becoming snobbish. The trick (which often isn't easy) is to get the coder excited about improving and learning new things. Once you manage that, offer him books like Clean Code and Head First Design Patterns Show your enthusiasm and be genuine about it.

Re:You don't (4, Informative)

icebike (68054) | about 2 years ago | (#42466689)

I disagree.

Give the guy a book on the subject, explain in detail the difficulty in maintaining or interacting with his code.
Do it in a helpful and non confrontational way in a private setting.

I'm sure he can be convinced that making everyone else's job harder isn't beneficial to the company.

Maybe something like
Hey Bob, I wonder if we could break this monolithic program into four parts for easier maintenance....
Can we break this function out to a stand alone routine, because I call this function it loads in this ton of code that I don't need, and puts the database at risk...
Bob, I can't follow this code, what would you say to this re-write I sketched out...

Old dogs can be taught new tricks, but don't dismiss the possibility that the young pup doesn't quite know everything he thinks he does.

I've often seen kid programmers using some high level function without a clue about the mountain of code it drags into the
application, or use a language "feature" that generates a ton of code that is slow and imprecise, when discrete operations would
be much faster in execution and more accurate even at the expense of more source lines.

People working on the same project have to act as a team. Approached properly, the old geezer might actually appreciate it.

Re:You don't (3, Insightful)

corbettw (214229) | about 2 years ago | (#42466877)

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.

Re:You don't (4, Insightful)

White Flame (1074973) | about 2 years ago | (#42466929)

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:You don't (1)

asmkm22 (1902712) | about 2 years ago | (#42466957)

Exactly. It's generally not a great idea to criticize people at the same "level" as you, only below. If the code is truly awful, and goes against the established code standards for your company (you have some right?), then bring it up to a manager and let them deal with it. Otherwise, you'll just cause a lot more problems than you'll solve, personally and professionally.

short answer (2, Insightful)

alphatel (1450715) | about 2 years ago | (#42466451)

Fire him

Ok ok (5, Funny)

Anonymous Coward | about 2 years ago | (#42466505)

I GET IT!!! My code sucks. You have made this clear. You don't have to start posting on forums you know I read. Sheesh....

Re:Ok ok (1)

mark-t (151149) | about 2 years ago | (#42466841)

I was going to post something similar... now you have me wondering if it was about me at all.

He knows something you don't. (5, Insightful)

VortexCortex (1117377) | about 2 years ago | (#42466507)

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

Does the guy really qualify as seasoned? (3, Funny)

Sheetrock (152993) | about 2 years ago | (#42466763)

For example, nothing was said about GOTOs being liberally sprinkled throughout the code. If he's working in a non-optimal language that doesn't support GOTO, he should try hacking in the functionality with preprocessor defines. Maybe even hack in a preprocessor if the language designer forgot one, or add another preprocessor if not. With a few stacked preprocessors one can even write his own (better) computer language, and what seasoned programmer doesn't aspire to have one or two of those under his belt?

You write code for humans... (2, Insightful)

Tei (520358) | about 2 years ago | (#42466517)

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 write code for humans... (0)

Anonymous Coward | about 2 years ago | (#42466769)

you just restated the op concerns and get modded up : WTF mods !!!

Re:You write code for humans... (5, Insightful)

gstoddart (321705) | about 2 years ago | (#42466849)

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.

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.

Not easy (4, Insightful)

jfdavis668 (1414919) | about 2 years ago | (#42466531)

People are very proud of their work, and do not take criticism well. One way is to ask for his advice on your work. In reviewing it, he may pick up some of your ideas and implement them. Be tactful.

Re:Not easy (1)

Bob the Super Hamste (1152367) | about 2 years ago | (#42466939)

Sometimes not. I have some code that I wrote that I will never admit to as it really was a dirty java reflection hack to get around an issue in a 3rd party framework that would eat all exceptions and not let you know if something failed. At least I documented why the hell I was doing that in the code and explained what was happening so that the next poor bastard who gets to look at that code won't wonder WTF I was doing.

its a lost cause (1)

alen (225700) | about 2 years ago | (#42466533)

our SQL devs write the longest most headache inducing code and never listen to reason. and they use the most evil invention ever, temporary tables. when there is no reason to

Re:its a lost cause (2)

mwvdlee (775178) | about 2 years ago | (#42466709)

Temporary tables can provide massive performance improvements and lower resource requirements when used correctly. You don't need them often, but in some situations they are a life-saver.

Criticism should be handled delicately... (5, Funny)

Anonymous Coward | about 2 years ago | (#42466535)

Leave him an anonymous poem:

Roses are red,
Violets are blue;
The C obfuscation contest produces bad code,
And so do you.

Re:Criticism should be handled delicately... (1)

AwesomeMcgee (2437070) | about 2 years ago | (#42466953)

That is absolutely hilarious. Would that I knew how to use the moderation system, I would +something.

Start with the basics (0)

Anonymous Coward | about 2 years ago | (#42466539)

Teach him proper indentation.

Which site is this? (1)

Anonymous Coward | about 2 years ago | (#42466557)

When did /. become Dr. Phil for nerds?

But who is it? (1)

Anonymous Coward | about 2 years ago | (#42466581)

You haven't made it clear here if you're talking about Bill Gates or Linus Torvalds. Either way, you're got more moxie than anyone I know. Good luck with your new career outside of information technology. :-)

Instead of asking us? (0)

Anonymous Coward | about 2 years ago | (#42466583)

Why don't you ask the man to his face??

* Seriously...


P.S.=> His answer MAY surprise you, or, you may surprise him...

... apk

Re:Instead of asking us? (1)

Anonymous Coward | about 2 years ago | (#42466757)

What happened to you? You used to talk about REAL problems before...

code reviews (5, Informative)

k0ldsh4d0wz (1608239) | about 2 years ago | (#42466585)

conduct code reviews here is a good tool [] , although it is not necessary to use a tool.

Re:code reviews (0)

Anonymous Coward | about 2 years ago | (#42466811)

This should be moderated higher. This is exactly what code reviews are for, catching bugs, ensuring correct functionality, and ensuring code adheres to standards and is readable and therefore maintainable.

Either that or pair programming, but this may create a prime environment for a shooting spree Amerkin style...

Fire him (1)

viperidaenz (2515578) | about 2 years ago | (#42466587)

And hire a new one who hasn't been stuck in their misguided ways for decades.

Automate! (5, Insightful)

TechyImmigrant (175943) | about 2 years ago | (#42466595)

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

Re:Automate! (4, Insightful)

TheSpoom (715771) | about 2 years ago | (#42466853)

In an environment where such a coder is allowed to flourish, I sincerely doubt they have any form of code review.

Re:Automate! (4, Informative)

ZombieBraintrust (1685608) | about 2 years ago | (#42466873)

I second the automation argument. Have an automation tool flag them as warnings. Then have a policy that code does not go out to build if the number of warning is over a set limit. Start the limit at the current number of warnings. Then lower the number gradually with each release. You can even get plugins for your IDE that display the problems as errors. Its hard to argue with a plugin that places a red x on your function.

Re:Automate! (1)

Megane (129182) | about 2 years ago | (#42466965)

If his code is that bad, he's probably got 500 warnings from the compiler. (assuming this is a language that now is good about giving warnings like C or C++) TRWTF is people who refuse to use -Werror -Wall.

Code reviews (5, Insightful)

Java Pimp (98454) | about 2 years ago | (#42466603)

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

Static code analysis tools (3, Informative)

El_Muerte_TDS (592157) | about 2 years ago | (#42466607)

Run his code through a static analysis tool with default, or best practice, settings, and then have him explain why the detected problems are false positives.
The best way for people to learn that their code sucks is to have a 3rd, impartial, party tell them. Static code analysis tools are the best, because they have no ears.
Telling them directly their code sucks is the worst way.

Force him to maintain his own code. (1)

oneiros27 (46144) | about 2 years ago | (#42466621)

If the code really sucks, it'll either teach him why it's bad code, or it'll bog him down enough that he doesn't have time to write new bad code.

If the code's working ... then you don't have to look at it. (but he still has time to write more)

Provide and solicit feedback. (5, Funny)

Tackhead (54550) | about 2 years ago | (#42466623)

A good manager should provide and solicit feedback.

For example, you tell him his code code not functional or elegant, and then, you ask him what he thinks about that.

And then you write the goddamn login page yourself.

Make it about YOU, not him (4, Insightful)

Karganeth (1017580) | about 2 years ago | (#42466625)

Instead of criticizing him, say "I'm really struggling to read your code, could you do x y z to make it easier for me to understand? Thanks".

Re:Make it about YOU, not him (1)

MozeeToby (1163751) | about 2 years ago | (#42466865)

Well, that would be fine if x y z were 5% of the guy's code. The summary makes it sound much worse than that, and I don't think anyone is going to hear "can you completely change the way you're doing every single line of code to make my life easier?" and be like "yeah sure!"

RTFM (4, Insightful)

HideyoshiJP (1392619) | about 2 years ago | (#42466629)

You'll find way to the explain it to him right next to the section with answers to questions from the wife, such as "does this make me look fat?"

mandatory code reviews (5, Insightful)

alx (7083) | about 2 years ago | (#42466635)

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.

does he reads books (0)

Anonymous Coward | about 2 years ago | (#42466645)

If your current coworker is smarts he must read book, if told him that you read 'Refactoring: Improving the Design of Existing Code' and could lend it to him if he is interested. If he is not into book, he is not so smart. Maybe clever but not smart

If that dog won't learn new tricks, put it down. (0)

Anonymous Coward | about 2 years ago | (#42466651)

Do it at his exit interview.

Change company! (1)

Anonymous Coward | about 2 years ago | (#42466669)

Find other job with good programmers, if not when you want, when you can.

Just say it.... (1)

Mike (1172) | about 2 years ago | (#42466677)

Dude, your code sucks!

Re:Just say it.... (1)

91degrees (207121) | about 2 years ago | (#42466941)

Needs to be more specific than that. "sucks" doesn;t help make it not suck.

"Your function names are so terse as to be unreadable", "This function is way too long" and the like are much more useful.

Post the problem on Slashdot And hope he reads it. (1)

Anonymous Coward | about 2 years ago | (#42466681)

Get the hint? He's talking about you, or maybe me.

"Why don't you want what I want?" (0)

Anonymous Coward | about 2 years ago | (#42466685)

Book by Rick Maurer "Why Don't You Want What I Want" - I found this book immensely helpfull. Check it out on amazon []

How to show him... (1)

Anonymous Coward | about 2 years ago | (#42466699)

Take things one at a time. And learn how he likes to learn.

If he learns through books, loan him a copy of Code Complete.

If he learns by doing, show him that factoring out repeated parts of his code makes his code less buggy and easier to maintain.

If he learns by other people's mistakes, then give him some code of yours 'to review' with one oy his big mistakes. Ask him if there's a better way to do things, and see if he realizes the mistake in others.

And if none of those ideas work, use his code to summon Baalzebub.

While you're at it... (4, Funny)

JeanCroix (99825) | about 2 years ago | (#42466711)

Why don't you convince him to start using deodorant, shave his neckbeard, and start dating a supermodel?

Key question: "Why?" (1)

BenSchuarmer (922752) | about 2 years ago | (#42466717)

You say you ask him whether he can tell that your code is better, but it sounds like he can't.

Maybe you should ask him WHY he coded a function the way he did (maybe he has a good reason). Depending on the answer, explain WHY you think your way is better.

Bad coder (1)

Urban Nightmare (147344) | about 2 years ago | (#42466719)

It's easy. You do what a professor of mine did.

"Dude... Your code is horrible. Yes it works but nobody know how the fsck it works. Here's a book on writing effective comments and coding conventions (sorry can't remember the name of the book)."

Now I know your not in a school environment but as his boss you need to explain to him that the code has to be readable by others. This is his first verbal warning. Give him a book on writing readable code and comments. Give him a couple of months to clean up his current code. If nothing happens then give him his first written warning. If nothing happens then the second written warning. Finally if he's still hasn't quit and still hasn't cleaned up his act give him his walking papers. Where I am you just need to give 1 verbal and two written warnings and show how you tried to help get the employee on track then you can fire them and not have to pay severance.

Pair Programming (1)

Anonymous Coward | about 2 years ago | (#42466721)

Pair Programming might help by showing him other approaches. Just be sure to man the keyboard more often than not.

My suggestion. (4, Funny)

DoofusOfDeath (636671) | about 2 years ago | (#42466733)

To worker: "You write bad code."

See, by choosing the right language for the problem, the solution was very simple. And I did it with just four keywords plus one terminator!

Ask slashdot: (-1)

Anonymous Coward | about 2 years ago | (#42466737)

My coworker thinks he's some sort of hot shit and wants to agile his scrum (or whatever this week's buzzword is) on rock-solid production code. I've been coding since before he was baby batter in his mother's cunt. This isn't some ruby on fails website, this is mission critical software. How can I tell him to fuck off?

The best approach is persuasion: high school style (1, Funny)

dingen (958134) | about 2 years ago | (#42466739)

Simply get a group of tough guys together, wait for him after work, drag him into an alley and make him understand. Works every time.

Re:The best approach is persuasion: high school st (1)

Nyder (754090) | about 2 years ago | (#42466885)

Simply get a group of tough guys together, wait for him after work, drag him into an alley and make him understand. Works every time.

I was thinking mafia style. Take part of the fingers till he gets the picture. It might make a few fingers shorter, but sooner or later he'll figure it out or quit.

Original Poster Arrogant? (0)

Anonymous Coward | about 2 years ago | (#42466745)

Seems like the original poster seems like their stuff is better than someone else's. Hubris?

Options, lots of them (0)

Anonymous Coward | about 2 years ago | (#42466749)

Here are some options; let us know which one you picked.

a) Grow some and speak to him
b) Tell your manager
c) You're in a box. Do you think your code is super-excellent-miraculous?
d) Why do you care? Does it hinder you? If so, tell b)
e) Offer some suggestions and re-write some of his code.
f) Get ready to find another job
g) Suck it up, buttercup.
h) Accept your differences. Learn to enjoy your differences.
i) Sleep with his wife/partner just to get revenge.
j) Work from home constantly.

DailyWTF (3, Insightful)

Anonymous Coward | about 2 years ago | (#42466761)

Post his code to the DailyWTF then send him the URL

Old code (5, Insightful)

holophrastic (221104) | about 2 years ago | (#42466765)

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.

Never teach a pig to sing... (1)

swm (171547) | about 2 years ago | (#42466771)

it wastes your time and annoys the pig.

Code Reviews (0)

Anonymous Coward | about 2 years ago | (#42466775)

Request that management set up a system of code reviews. If they're not willing to do it, then leave, since there's nothing that will stem the tide of crappy code. Nothing improves the quality of code, finds bugs faster, and for less effort than code reviews. Have it be policy that code can't be checked in until it passes review, and propose hard and fast criteria, such as comments, meaningful variable names, compact class hierarchies, small functions, etc. Find everything bad with this guy's code and come up with a clear policy that will prevent it from getting checked in. Tell management in the language that they want to hear, which is that bad code is "job protection". Don't single this guy out. Once his code fails review (by someone other than you), it'll be him screaming to management and being a crybaby, except that he's not trying to improve the product, he's trying to give excuses for being lazy. Any manager who isn't phoning it in will see right through his excuses. Once again, though, if management isn't willing to institute this common sense policy, then you should find another job, because they're not willing to put quality controls in place, and don't care about the quality of their product.

Wait for him to retire (1)

damn_registrars (1103043) | about 2 years ago | (#42466789)

You said he's older than you, so if you're planning to stay with your current employer, just wait for the bad coder to retire. You won't be able to help him, it isn't worth trying really. You might well cause yourself a fair bit of harm by even trying to resolve the problem.

Give them a book (0)

Anonymous Coward | about 2 years ago | (#42466795)

Find the book on programming you think would help him. But don't make it too obvious. Get in the habit of sharing interesting reading material such as magazine articles. Then casually lend him the book, posed as just another interesting topic.

Get him to explain it to you (1)

Blasphemy (78348) | about 2 years ago | (#42466801)

Ask him to explain the code.

That will not be easy for him and should show him why coding standards are important.

Re:Get him to explain it to you (1)

Blasphemy (78348) | about 2 years ago | (#42466881)

Worst thing that could happen is that he thinks you're stupid. But, even if he does, he should try to write code that you understand.

It's always a good idea to get people in the mindset that their work will need to be maintained by someone else, because they won't be there after they are promoted. So they aren't writing for themselves, but for the next guy, who obviously won't be as brilliant as they are.

Missing IMO's (0)

Anonymous Coward | about 2 years ago | (#42466835)

There are quite a few "In my opinion's" missing from the question. Ah well, to be young and know it all... I remember those days.

Make him fix a bug in his old code (4, Insightful)

Bob the Super Hamste (1152367) | about 2 years ago | (#42466839)

Seriously that is how I started writing good code. If it was code he hasn't looked at in years it works best as then he has to suffer through his own problems and wondering what the hell is going oin. I learned this very early on when I was still in school and was trying to create my own game on the side that I would work on periodically. After dealing with some of my own early garbage code (piss poor names, no documentation, shit structure) I learned real quick to make my own life easier and write better code. I know I write better code now than I did then and am always trying to be better.

Relax (2)

MightyMartian (840721) | about 2 years ago | (#42466845)

With his lack of skills, he'll either be out the door or in management before too long.

Make him taste his own medicine (1)

gmuslera (3436) | about 2 years ago | (#42466847)

Do a code in his style, and ask him to maintain it, specially doing changes where that way of programming show why its wrong.

Pair programming (1)

Sonyc148 (877067) | about 2 years ago | (#42466859)

Sit next to him, and code together. Don't forget to let him have the keyboard. Even if he makes mistakes, it gives him the opportunity to practice (and you have a chance to refactor his code when it's your turn to have the keyboard). If he's really smart, there is a chance he's willing to learn. Don't give up on him.

Add code reviews and coding standards... (2)

GaspodeTheWonderDog (40464) | about 2 years ago | (#42466867)

Coding Standards and Code Reviews. Then you'll have some more process in place that he won't care about. From previous experience they'll probably all get waived in favor of the almighty deadline anyways!

Yeah yeah... I know the horrors of maintaining somebody else's junk code... but what coder hasn't left behind them a trail of woe and destruction? Also, have you ever considered that it might be you? It sounds like more of a potential ego problem than a who is doing it write. Sure the code may suck to maintain, but if the guy is hitting deadlines and the sky isn't falling (until the maintenance crew touches it)... well who's to say who is write or wrong? Unless you get management to sign off on a specific plan, or can explain why OO is better than monolithic scripts... you're not going to have any way to show this or that.

At any rate... rewriting something that works (even poorly) is a massive undertaking... and you'll be fighting a losing battle of playing catch up. Unless you really like coding a lot, and overtime even more you should really consider if it really is worth the fight for you. I worked at a place that I convinced management to convert from procedural code to object code, and even with full backing everything went to hell over two years... and guess what the old system was still functional while the development team went of to write code for new features of the system because they wanted to solve interesting problems and not port code over that solved current problems we needed.

What you really should be focussing on is how do you put yourself into a position to write 'beautiful' code so that everybody else has to be stuck maintaining your code.

Make Him Maintain It? (1)

TheNinjaroach (878876) | about 2 years ago | (#42466871)

Make him maintain the code. That's how I learned to write code that's easier to work with.

Look at Linus (5, Funny)

rastos1 (601318) | about 2 years ago | (#42466875)

Didn't Linus set an example just a few days back?

You can lead a horse to water... (0)

Anonymous Coward | about 2 years ago | (#42466879)

How can I make him see the light, realize the truth, and be able to tell good code from bad?

... but you can't make him drink.

Good programmers are constantly learning and improving their techniques.
If you've encountered a long time programmer with code that bad, nothing you can say or do will help.
You should try to teach your dog to speak fluent French; it will be easier.

I do suggest that you ask your boss to implement a "everybody maintains their own shit" rule.
That way your co-worker will be the only one to suffer from his code.

involve management (0)

Anonymous Coward | about 2 years ago | (#42466883)

It's their job, and if they won't back you up you'd be stupid to take this on yourself.

Coding is thinking (3, Insightful)

erroneus (253617) | about 2 years ago | (#42466887)

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.

If the code works... (2)

Shinare (2807735) | about 2 years ago | (#42466895)

whats it to you?

One way (2)

ryanrk (867641) | about 2 years ago | (#42466899)

Get all of the developers in a room and have them stand in a line. Then ask all the developers who develop good code to step back one step, then proceed to tell the suspect "not so fast".

Are you sure it's his? (1)

HornWumpus (783565) | about 2 years ago | (#42466909)

He might have inherited that mess and it might be so brittle that the correct way to maintain it is with minimum changes while replacing.

Of course management usually nixes the replacing part and you wind up just doing the minimum changes part.

If he is making new messes you need him assigned to maintaining an old mess.

Also one part of your post bothers me:

basic language features ignored, when they could make everything shorter and more readable

Shorter can be less readable. For example C++ Template abuse. I once maintained a program written by a dude that was learning C++. He used every language feature as a learning exercise. Function overloading for no reason. etc

Easy steps (1)

jollyreaper (513215) | about 2 years ago | (#42466917)

Assuming he reads Slashdot, I think you've already figured this out.

Submit the best examples to TheDailyWTF (4, Funny)

Megahard (1053072) | about 2 years ago | (#42466927)

And send him the link.

manager's issue (1)

subnomine (849148) | about 2 years ago | (#42466931)

Describe the issues to your supervisor in terms of extra time and difficulty to maintain, and/or poor performance and production bugs/issues. If the code works well enough and nobody has to maintain it, then management wont care. It becomes a simple matter of how much you care about the "sanctity of code." Back to the question... Rewrite a portion of the code to show how much better it can be.

Testing (0)

Anonymous Coward | about 2 years ago | (#42466933)

Ask him how the hell you could possibly test such code. Answer, you can't. Testable code is broken down into functions which do one thing, are often referentially transparent, have small scope and try not to mutate outer scope/state when possible.

I have had the same issue with other programmers for my entire career, they write huge huge functions with levels and levels of conditionals/switches, terrible names, impossible to test and mind-boggling to maintain. You can often refactor their code somewhat when it is your turn to work on it, but sometimes short of redoing it (which is a terrible idea which will get you in trouble and seen as wasting time unfortunately), you actually cannot really do anything about it.

Chances are the person who wrote it still has his job because he always gets shit done, regardless of how unmaintainable it is, and . This is because he probably has a really good memory for working with what he wrote and is unable to see that besides himself, no one can understand it but him.

I have noticed that as my memory gets worse, my code becomes more and more organized. It is impossible to do anything about this, other than suggest code reviews for all. Its highly common you will find programmers like this everywhere in industry even though it is maddening.

Do it better (0)

Anonymous Coward | about 2 years ago | (#42466945)

Simply rewrite his code in the way that you believe it should be written. Do it in your spare time if necessary. Then let him, and everyone else, see the difference.

There's a fix for crap like that.... (0)

Anonymous Coward | about 2 years ago | (#42466949)

It's called unit testing. learn it, love it, live it. (

jump ship (0)

Anonymous Coward | about 2 years ago | (#42466963)

Find a company that doesn't keep people around who write bad code. Not only will that company produce inferior products, but the fact that they keep people like that around is indicative of dysfunction. Jump ship, cut your losses, get a better job at a better company. Unless of course he's really open to constructive criticism, in which case you should probably just tell him. What comes to mind though, is that old saying, "you can't teach an old dog new tricks".

Easy.... (1)

fatmal (920123) | about 2 years ago | (#42466979)

make him document it!
Load More Comments
Slashdot Login

Need an Account?

Forgot your password?