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

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

Comments

You don't

[crazyjj]

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

[broggyr]

Lighten up, Francis.

Nobody puts Baby in a corner....

Re:You don't

[Anonymous Coward]

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

[coma_bug]

"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

[AwesomeMcgee]

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

[Anonymous Coward]

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

[lorenlal]

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

[Lisias]

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

[icebike]

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

[corbettw]

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

[idontgno]

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

[White Flame]

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

[BitZtream]

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

[Darinbob]

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

[BitZtream]

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

[Austerity Empowers]

if his attitude is like some of my coworkers, he's no doubt asking his management why the junior engineers aren't rewriting his code to make it efficient while he tackles the big problems more suitable to his seniority.

Re:You don't

[Darinbob]

The solution is to make the person do all maintenance on the code. Give them a feature that's big with too short a deadline (and no one volunteering to help), force them to get all the boring bugs fixed before the new sexy feature, etc. Sometimes I see such programmers essentially get pushed out of one group and into some minor side group where they work by themselves.

Yes it's true that sometimes it's just not your problem. But it does become everyone's problem if you have to work with that person's code and it is slowing down the entire team.

Re:You don't

[funwithBSD]

Help him get promoted to "Software Architect" and get him out of the coding business.

Re:You don't

[q-the-impaler]

I can tell you are humble just by reading your Nick.

Re:You don't

[Synerg1y]

And like the OP said, it doesn't matter if it's good or bad as long as it works.

That's like saying I'm going to sell you this used car and the alternator is going to go out as soon as you get home... and oh, we don't offer a warranty sorry. Inheriting crappy code sucks hard dude. Code reviewers are just people, in some cases Visual Studio might do a better job.

Re:You don't

[Rob the Bold]

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

[Lumpy]

Bingo.

I will not code to Boutique standard #47 that snot nosed brat thinks is great. Follow the standard that we have set here in the office. If I'm senior coder, than that means I set the standard.

I'll use a goto once in a while just to make a newbie convulse on the floor.

Re:You don't

[Darinbob]

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

Re:You don't

[Nefarious Wheel]

Sometimes, subtlety is overrated.

"John, that piece of code smells worse than your uncle's codpiece (which I wish you would stop wearing to work), and in reviewing it I can deduce that your parents were never formally introduced."

Re:You don't

[UnknownSoldier]

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

Re:You don't

[Garridan]

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

[CanHasDIY]

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

[Beetjebrak]

I used to be 29 when working with a colleague who was 64 at the time. He learned programming in ALGOL on Burroughs mainframes. Very tight, very sparse, very unreadable when he did Perl. Perl in fact lets you do this, as does C, but it's not needed anymore. It was downright impossible to get him to rename functions and variables to something descriptive or to use comments. That stuff used to cost back when the bits of RAM were visible with the naked eye. Today the balance tips another way. Doesn't mean the old dogs see any merit in that though and they will wield their seniority when pushed too hard. Personally I can really enjoy tweaking 6502 or 68K assembly by hand, but that's a hobby. At work I deal with business applications that, when slow, usually are just fed more iron because it's cheaper. The inner geek cringes at the thought, but it's the reality of business.

Re:You don't

[Altus]

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

[Mephistophocles]

If management wants your opinion of your coworkers, they'll ask for it.

Not necessarily; having managed a few dev teams I actually appreciated it when someone would come to me with issues like this (privately, non-confrontationally, without a lot of arrogance, etc - any of those things would probably just make me ignore you). Management isn't telepathic; they can't see every single problem like magic.

That said, if your manager a) doesn't have at least enough understanding of coding best practice to know why the stuff you're bringing him is bad, b) is an arrogant asshole himself, or c) is one of those types that believes the ladder to success is built from the heads of underlings, then yeah - STFU. And start job-hunting.

Re:You don't

[buybuydandavis]

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

Under most management, it's worst than that. "Your misunderstanding is my asset." When you have a large chunk of code that only you understand, you become the genius/hero/cowboy to most managers.

Where the management class can't code, and the inability to code is increasingly a prerequisite to a management position, writing code that is maintainable by others is a career liability.

Re:You don't

[Ivan Stepaniuk]

On the contrary! it is your duty and responsibility, as a team member, to check your colleagues work and the code quality. Otherwise you are not only a bad team player, you are also unprofessional as a developer. Just a solo code typist.

Of course, It would be easier to avoid confrontation, do your s*it and home like parent does. Just easier, not right.

His code is the team code and therefore your code as well. Code reviews are to critique code, not to criticize team mates, however, if you cannot even make a remark like 'Do WE see how much better...' you have a bigger problem than just bad code, you have a rotten team, and if you STFU, you are only making it worse.

For the sake of your project, your company (and then your job), you must do all you can to shed light on these team issues. Talk with other team mates, learn how to organize a team retrospective, ask for help on this matter. Care.

And specially, don't count on managers to solve these issues by themselves, they can help, but they are not your babysitters.

Re:You don't

[Canazza]

The way the OP is going on about it, I imagine him writing C# code in the style of Javascript...

Re:You don't

[jeffmeden]

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.

Says the man so proud of his employer that he is posting anon...

Re:You don't

[tnk1]

And like the OP said, it doesn't matter if it's good or bad as long as it works.

As a one-off that no one is ever going to add to, fix, or need to reference, you would probably be right.

The problem is that code usually needs to follow certain standards so it can be taken up by someone else when the original coder leaves. It frequently needs new features, and is certainly not without bugs. Further, sometimes simply working does not im

I will agree with the person who said that it is not *your* problem, unless it directly makes your life harder. However, if it does have a real effect on your work, then your manager should be someone you should be able to go to with this and explain the issue. As a manager, he should know that following standards is best for the company, and caring about the company's future, as well as the rest of his team's ability to work, is his problem.

Don't start a potential fight with a colleague, go to the manager. If you have a rapport with the coder, you can try and work with them gently first, but if you even suspect that it will cause drama, that is what they pay managers for. You're not tattling on your colleague if they are not using the expected standards which are there to make your lives collectively easier and your company more able to function.

Of course, this implies your company/group has coding standards to begin with. Some places I have worked at have almost none at all. If you don't, proposing some might be a good way to cause the bad coder to at least defend their way of doing things when you propose the new standards. Or, if you like, propose to the manager some industry standard coding scheme and get him to sign off on it and impose it. Then you don't even have to be the bad guy.

Re:You don't

[Bengie]

Require proper Unit Tests. That will force someone to reduce the amount of code-paths in a method.

Re:You don't

[Anonymous Coward]

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 don't

[Tmann72]

The very fact that this question was formed from the position of a co-worked makes it a safe assumption that they are using the same language and skills for the job. When you are on a team like this situations like you suggested don't happen often.

Re:You don't

[dubbreak]

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.

Not necessarily. I worked with someone that directly fit this description. I've never seen OOP abused so badly in my life (inheritance and polymorphism that was either the product of a genius obfuscating their code.. or an idiot that knows of such ideas, insists on using them, but has no clue as to the right time and place to use them). He was able to sneak by most code reviews because he was often working solo on products that were borderline legacy. With few bugs apparent at the user level his slow progress was put up with for the mostly "reliable" code. Then once some other people got pulled (such as myself) he got put under a microscope by his manager. This actually resulted in yelling matches. The code was truly horrible. At one point he had read that a function/method shouldn't have more than a few lines code. I found a method 9 calls deep, each method adding another argument that resulted in a call to a native API that could have been done at the top level (well excepting side effects along the way that did god knows what). We also coined the term "lilypadding" for some of his solutions. It was obvious he's jump directly into a problem without any real vision of the end goal or result. He'd eventually get to the end, but only after making many many jumps, often in the wrong direction (open file, read all of file, find line you need, read part of the file based on that line again despite having just read the entire file, do select * on a table in a loop while filtering in code, etc). It almost seemed he came upon a working solution by happenstance. I think part of it was the false ideal: if you aren't coding you aren't working. A 5 day solution for him would be 2 days planning and 1 coding for anyone else.

In the end his code was not maintainable or extensible. He refused to listen to the suggestions of his manager and change his code, insisting it was golden and the correct way to program (despite being provided plenty of evidence to the contrary). The guy would even get pompous when you request he fix his own check-ins (he would often leave his hacked up "testing" library in references, though his special proprietary library was not in the codebase, resulting in a project that would not build).

How'd management fix the issue in the end? They got rid of him. He got decent severance, and help seeking a new position. Part of me feels for the guy (and his family that relied on his wage), but part of me also wonders who's problem he is now.

How was it solved? They got rid of him.

Could he have been trained to be better? Maybe, but he didn't act willing to change and wasn't a good fit to the team or company attitude-wise. He'd do things like hang up on a customer because "it was his lunch time" even after being reprimanded for doing that previously. He claimed in "his culture" that's how they do things. When a bug is escalated directly to the responsible programmer from a customer, you put your lunch off for 15 minutes, you don't say, "Oh it's lunch.. bye." And we're not talking a slave driving culture, he was free to take his lunch whenever and any overtime would be balanced by time off. It was simply a matter of treating the customer well in a sensitive situation which he couldn't wrap his thick skull around.

If a company isn't willing to take care of time wasting employees, that don't fit the company culture.. I'd leave. It's not your problem to take care. It's your job to make sure the issues are clear to management, and it's fair for them to request you help guide him/her to being more productive in the company, but it's not your job nor place to try to fix it.

Re:You don't

[Anonymous Coward]

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

[TapeCutter]

Ever been in the situation where a co-worker asks you what a bit of code does, you skim it for a few minutes and brush him off with "not sure", then he replies; "but you wrote it"? If you write enough code (especially maintenance code), it will happen to you eventually.

So IMHO not really your "fault" that you can't pick up the kernel design in an afternoon by skimming the code, it's the coder's job to clearly explain the implementation, not the design.To paraphrase an old friend of mine, "Source code is like shit, you can't smell your own". Even if the code was written by Shakespeare, browsing code is still the hard way to pick up the design of a non-trivial application, but if your not surrounded by co-workers who wrote it then it's often the only way available.

Trivia: I used to teach C to second year engineering and CS students in the early 90's. The engineers were the worst for writing the entire thing in main() because they already had leaned bad habits from elsewhere. Each year most of them would fail the first assignment and then complain about the harshness of the assessment, one they knew I was serious about my style sheet most of them would do much better on the second and subsequent assignments. I wonder how many of them now understand why their code's comments and style were worth a full 50% of their mark.

Re:You don't

[Bogtha]

If I'm senior coder, than that means I set the standard.

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

[dcollins]

"If I'm senior coder, than that means I set the standard."

Your standard for if/then statements must be delightful.

Re:You don't

[CAIMLAS]

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.

Re:You don't

[Sir_Sri]

This is a fairly common problem anyway. People tend to get stuck in their ways, the new guy comes in and knows all of the new stuff in the language, the new theories of software engineering etc. The last guy, what he learned 10 years ago or 20 years ago was good enough, and hasn't bothered to keep up.

Really it's not the job of another lower level person to level specific criticism. Your best bet is to talk either training sessions with bosses (everyone gets refresher courses), or just do it with new tech and show the person how it can be done.

Re:You don't

[shadowofwind]

I cannot imagine how this guys boss is ok with checkins like what the poster is describing..

If you write code that nobody else can deal with, you gain more leverage in a project, and so does your manager by extension. True it hurts the product, but it doesn't hurt your team relative to other teams if there is more than one. In theory there should be a manager higher up who cares, but in practice his time is more effectively spent in PowerPoint competitions with other managers, not enforcing coding standards. From what I've seen, this is a prevalent pattern at most companies, not just at a few dysfunctional outliers.

Re:You don't

[dubbreak]

On a side note, I really wanted to vent about that guy because I had a nightmare about him last night (which I confided to someone who used to work with him as well). We had a good laugh about it.

In the dream I was sitting at a table with some other devs making a sarcastic rant about some anti-pattern, "Here's a really good system design.. < insert some silly anti-pattern or short sighted design >"

The guy across from me proudly states, "I just designed a system like that an am using it now!" Then goes into detail about his entirely stupid short-sighted design**.

I look across the table and just then notice it's HIM. The lilypadding complicator I thought I had left behind.. "Noooooooooooo!"

**Being a dream it didn't really make sense, but I remember something about a POS system for a bowling alley.

Re:You don't

[Nethemas the Great]

There is no excuse in oop languages. Goto type a.k.a. jmp opcodes are an esssntial part of assembly. In other non-structured programming languages they are likewise essential to flow control.

Re:You don't

[Nefarious Wheel]

Yes, comment style, yesss -- the number of times I've seen "increment j by one" instead of "where J = initial position in string" and wanted to beat the writer with a hockey stick...

Re:You don't

[Nefarious Wheel]

Simplicity and clarity is the mark of an expert.

Re:You don't

[bbulkow]

Let me tell you a story. On the founding week of a company, where 80 programmers were hired (some of the best I've ever met, it was a strange situation), I was told to write a filesystem in 3 days. In order to succeed at this, I didn't do full POSIX, figured out why we were doing a filesystem, what the special twists were, and built the thing. The code had to be extremely reliable (multimonth uptime delivered in days of coding, so the code has to be "provable" and "inspectable". I did this thing. Three times in the next 4 years different people walked into my office and said, effectively, "I found this POS in the bottom layer of our product and it's creating all these problems". I said "is the interface and layering right?" "Yes", they always said. I would say "I wrote it in three days and it's exactly hit the design goal I was aiming for. The code's never crashed, never lost data, has a great interface, and it's slow as dead dog meat. If the requirements have changed, rewrite the code. Spend a whole week on it this time. But don't say I wrote POS code - it was code exactly to spec." Every time, the person wandered out of my office, and the project manager said "we've put off changing that module", and no one ever touched the code. Apparently it was a POS, and it was a simple well defined module, but when push came to shove they wouldn't do anything better. I have other stories like this, an expert programmer will often do something a beginner won't - like cut a corner and write known-ugly code to win business, ship a product, keep a company alive, and are more than capable of writing beautiful code, too.

Re:You don't

[WaywardGeek]

Great story. I've never had trouble understanding code I wrote. That's probably because I have one of the world's worst memories, so I always write code with lots of clues to help me decipher what's going on. Also, I got lucky when a programmer from industry taught a structured programming course. He was all about coding best practices. I learned the KISS rule from him, and have avoided clever obtuse code, when a straight forward solution will do. The analog designers I work with might disagree... I'm forcing us to use Python and classes, and you'd think I was murdering kittens from all the complaining. The reaction when I made us all use git... *shudder*

As for the poster's question, feel free to make some noise about his code, and see if it has any impact. Older coders like me rarely change much, but you might get him to adhere to a few team-wide coding guidelines, at least if he's not an analog designer. In a perfect world, you could help him find a better job, one where his coding issues would not be such a liability, and where whatever his real strengths are can come into play.

The best programmer, by far, I ever worked with is Ken McElvain, founder of Synplicity. If you need a problem solved quickly, and better than what all your competitors can do, he's your man. However, his code when I joined the company had some of the issues the poster mentioned, and that made me laugh. He's a very fast typist, but his typing speed is his limiting factor in coding, so he used 1 and 2 letter variables mostly. Writing code inline is faster to type than factoring out a bunch of small functions. Comments just slow him down. The first day working for him, I opened one of his most ingenious pieces of code (responsible for better 2-level logic optimization than what Synopsis had at the time), and tried to understand the 2,000 line file, which is tiny given the job it does. It's core is a brilliant 1,000 line function, and it took me all day to figure it out. I thought there had to be documentation somewhere, so I grep-ed the whole code base, all 350,000 lines of it, for comments. There was one. It said, "This is a hack." Many programmers, including me, will hold that his code is difficult to understand against him in the "best programmer" contest. He wins anyway. He knew that the most important reader of his code was himself, and that being as productive as possible early on was key for Synplicity's success. We were profitable, and had over 20 employees when I joined, yet I was the first programmer he hired. As the coding team grew, he started adding comments and using descriptive names. I heard a lot of complaints about working with some of his code, but he owned nearly 50% of Synplicity at the IPO, and everyone involved made money. Go ask his investors what they think of his coding ability. Anyway, if this co-worker is so smart and experienced, I'm not convinced hes a "bad" programmer. Maybe he just needs a job where he's the right guy.

Re:You don't

[Darinbob]

It's not just about skill. If the original programmer failed to comment the code so that others can maintain it, then that is bad code! Comments are not an optional programming language feature that can be safely ignored. Now of course there are some pieces of code that deal with very esoteric issues that not everyone will be able to understand, but they should still be documented since the programmer could end up leaving the company. Eventually someone else will take over maintenance of the code.

This is about understanding the code. Maybe the novice may not know why something is modular instead of being tightly coupled but the novice will still be able to understand the code. The novice doesn't have to know what a design pattern is or what it's named or even know what they are but the code should be understandable. Personally, I think if someone puts in a comment like "This is standard FactoryModulatorWidget pattern" they need to do better commenting anyway (quite a lot of great programmers do not know the details of the design pattern cult).

If the code is intelligently designed and intelligently written then the novice will be able to understand it if they understand the basics of the programming language and the subject field and are familiar with other parts of the system. This is especially true with modern programming languages allowing longer variable names written on a big screen with a nice keyboard and lots of disk space (older stuff like 70's Unix can be excused on this basis).

Apologize or not to other programmers not being able to understand it, but they will absolutely hate the programmer who's in the hospital if their code can't be understood. Managers should consider this sort of stuff to be risk management. This is not about dumbing down.

Re:You don't

[shutdown -p now]

You should grep your code for "do...break...while(false)" and see how many of those you'll find. On all teams that had people like you that think goto is inherently evil and should be banished everywhere, that was the ultimate result - they wrote plenty of gotos, and it passed the code reviews etc just fine so long as the word itself was never spoken.

Re:You don't

[shutdown -p now]

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

[Bender0x7D1]

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

[rtb61]

Sounds like the problem can more readily be resolved by two levels of coders. The creators who produce the original lot and make sure it runs and then editors who tidy and pretty it all up and make in more informative. In fact lots of people who are not very successful at creating new code, can be quite good editors. Cleaning up code, resolving the last few bugs, better variable and class names, more comments, breaking up functions etc. They do it for writers in order to speed publication. The same might be considered suitable for coding and with ready access to the original coder to provide explanation over any more convoluted high quality easy to maintain code could be more readily and quickly produced.

Re:You don't

[starfishsystems]

Late in my career, I find myself surrounded by genius developers. That's rare. Mostly the better developers I have met are fast and smart, but somewhat conceited and not particularly careful. I run across someone with real talent maybe once every five years, if I'm lucky. And by talent I mean that they write consistently beautiful, correct, modular, extensible, exemplary code. Okay, maybe once every ten years would be more accurate.

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

[Immerman]

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

[celtic_hackr]

No it does'nt. But your comment shows your perception based on a complete lack of evidence.

If some fresh-out-of-college kid gave me a book on coding practices, I'd certainly not toss it in a trash-bin. But the kid would certainly be added to my list of arrogant piss-ants to be crushed at every juncture.

While it may be possible this kid isn't exagerating. It's also highly likely the kid hasn't seen all his code. Code which might complie extremely compact. Compilers are very good at optimizations these days. But since the kid gives no reference of this guy's history, we have no clue whether he's an old mainframe coder, or some guy who worked his way from sales to coding.

God is in the details.

I once worked with a guy, that we all thought was the worst coder in our group. When he left and me and one other coder were all that was left of the entire department, I found out the guy had some really brilliant code in some places. He was very slow, but his shitty looking code was all rock solid and bug free. Really bug free, and he had some really complex code that I've learned from. Granted he got most of that stuff from books.

The kid here mentions nothing about code reliability or speed of operation. So, the kid has already shown himself to be less than competent in my book, and having an ego problem. But, hey, maybe I'm drawing conclusions with insufficient facts.

I should add, that I have had to explain my code to others from time to time. I have written "entire programs" in a single function (usually very small and compact and mostly used for testing code, data cleansing, internal tests, etc) . I have written programs in a single line (just to prove it could be done). I have written production programs in single functions, in advanced 4G languages covering hundreds of lines, because that is the way the language is designed to be written and used (MAPPER "runs"). I have used OOP in very ipmproper ways. I personally hate OOP, because of the terrible overhead. Anything you could write in OOP, I could write in procedural form, that is just as reusable, briefer, faster, and easier to understand and maintain. That said, when I'm lazy, I'll just use OOP the way it was meant to be, when appropriate to be used. So the kid just didn't give enough detail to draw any relevant answers, and it likely isn't his place to bring it up.

Re:You don't

[Immerman]

I always liked the adage "distrust your darlings". There is a time and place for clever code, but if you find yourself writing it with any regularity that's probably a bad sign.

Re:You don't

[omfgnosis]

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:

It's possible to write insightful comments on the Internet. Nobody does though, it's just too easy to write crap that works well enough for now. It seems to be the great failing of any "easy to publish" network. Create something simple enough that even an idiot can post their facile opinions on it, and only an idiot will want to.

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.

short answer

[alphatel]

Fire him

Re:short answer

[meta-monkey]

Pretty much. I had a similar situation with a business partner who had done well for himself (off and on) in business for 20 years, but when we started trying to work together I realized he had no concept of basic managerial accounting. The idea that you need to record your expenses, and use a simple spreadsheet that uses your costs in order to price services, and that when someone will not pay more than it costs to do a job, you don't do the job.

And he would say things that sounded right-ish, like his wife would "do the books in QuickBooks" but it turns out all she was doing was reconciling the checkbook, and not entering any of the credit card expenses. And when after four months I said, "hey look this isn't making any money" he'd say I needed to "learn to read a P&L sheet!" because the P&L said we were making money. But you can't read a P&L that doesn't have the Ls on it. If you didn't have to record the expenses, and could just record the profits, we wouldn't call it a "P&L," we'd just call it a "P." Or that he "ran the numbers," but to me that means "used a spreadsheet to calculate prices based on costs," but to him it meant "thought about some numbers and wrote one down."

You would think this would be obvious to anyone, even with no business experience. But trying to explain that what he was doing doesn't work was like talking to an angry brick wall, because he'd been doing this for 20 years, and had basically lucked into some success. Thankfully I was able to extricate myself without losing anything, but it was still just incredible that someone could be that wrong, and that belligerently wrong.

He's about broke now. Says it's the economy. Gotta be, right? Things are tough all over.

So, OP, there is that saying about old dogs learning tricks. Expect a world of defensive stupidity, and your best bet is to stay out of the way.

Ok ok

[Anonymous Coward]

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

He knows something you don't.

[VortexCortex]

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

Re:He knows something you don't.

[omnichad]

No company can afford to have a single point of failure

Please note: ideals do not match reality.

Re:He knows something you don't.

[jotaeleemeese]

I can't believe they are still people so naive.

Do your work properly because is morally correct to do so just don't expect job security in exchange.

Re:He knows something you don't.

[gnasher719]

So guy is working hard to make sure that he is irreplaceable. It could give him more years on paycheck, but eventually business will put business continuity on higher priority.

So how does writing bad code make him irreplaceable? He writes code that nobody understands. That means he doesn't understand it himself either. So one day the company will hire someone who is actually clever enough to maintain that awful code a lot quicker than he can.

You write code for humans...

[Tei]

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

[gstoddart]

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.

Re:You write code for humans...

[Mephistophocles]

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

Not easy

[jfdavis668]

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

[j00r0m4nc3r]

People are very proud of their work, and do not take criticism well.

Ammendment: insecure people do not take criticism well. I find the best play in this situation is to appeal to their ego and do a little misdirection like, "Man your code is really good, but I'm finding it a bit hard to follow, like in this example..." The trick is to insinuate that the flaw is with you, and he would be your hero if he could write functional code AND make it easier for the peons to work with. Everyone likes feeling the hero, even if they're really the ass...

Re:Not easy

[avandesande]

You won't be teaching the guy anything. If he has been coding more than a couple years and isn't sick of making the same mistakes over and over there is no hope for this person.

Re:Not easy

[tool462]

In general I've found asking "why" to be an effective way of pointing out flaws in others' work.

Bad idea: "Hey, dingleberry, stop using global loop variables in all your functions! F#$&!"
Good idea: "Hey, friend/coworker/secret lover, I've run into a weird bug and wondered if you could explain to me how this works..."

First, it immediately defuses the accusatory tone that puts people on the defensive. Anybody who gets their dander up will no longer listen to reason.
Second, while this example was a pretty extreme case of brain-deadedness, there can be situations where something that looks ridiculously stupid was done that way for a reason. You could learn something. And if you expect somebody else to drop their pretensions about their code, you'd better be willing to do it yourself.
Third, if you work through the reasons that code was a problem with them, they're more likely to recognize the underlying cause of the problem and will be less prone to making the same error in the future.

It works surprisingly well, even with the interminably stubborn assholes out there. And any time you do end up pinning a mistake on someone, you need to give them a graceful out if you want them to own up to it and have a good working relationship in the future.

Re:Not easy

[luder]

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.

Or maybe he will say something like this:

"Why do you create so many objects and methods! Object instantiation and method calls are costly. It's not easy to allocate memory for new objects and the more you do it the more memory fragmentation becomes an issue. Method calls can disrupt the processor pipeline and prevent the best use of the cache. All this can really slow down our application and increase its memory footprint. Please don't do that, instead put everything in a single static method, which will only be called once and suffer no performance penalties. Hey, since I'm ahead of schedule, I'll be glad to give you a hand on improving your code. All of that overhead will be history in no time :wink:."

Criticism should be handled delicately...

[Anonymous Coward]

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

[SuiteSisterMary]

Actually, that might not be a bad idea. Submit some non-critical or non-copyright code to such a contest, and hand him the award/accolade.

code reviews

[k0ldsh4d0wz]

conduct code reviews here is a good tool http://www.atlassian.com/software/crucible/overview , although it is not necessary to use a tool.

Re:code reviews

[tazan]

If he's the only one complaining then he's probably the only one on the team who knows what code is supposed to look like. Getting standards written and having code reviews could very well make things worse. You'll have to write your code like him.

I missed a meeting one time and the team decided to write some standards. I came back and found some great new standards. e.g. Always declare all variables at the top of the method. Every function must have a try catch. All variables are set to nothing at the end of the method. etc. etc.

Automate!

[TechyImmigrant]

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!

[TheSpoom]

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

Re:Automate!

[ZombieBraintrust]

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.

Code reviews

[Java Pimp]

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

[El_Muerte_TDS]

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.

Provide and solicit feedback.

[Tackhead]

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

[Karganeth]

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

[cervesaebraciator]

This is exactly how to approach people who think much of themselves and are causing problems thereby. I would add, if you've not yet built the rapport with him necessary to ask him actually to make changes, one step can come before this: ask him for advice on a project. When people give advice, they feel important and good about themselves (see, e.g. everyone who's posting comments here). Sometimes they can associate that good feeling with the one to whom they gave advice. This might open them up for suggestions later on. The important thing is to be patient and play the long game if you want to win.

RTFM

[HideyoshiJP]

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

[alx]

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:mandatory code reviews

[Fastolfe]

Set clear rules about what things should block code reviews, and what things should not. My employer has a fairly rigid style guide, and I like it that way. Many of the things we ask people to fix in our code reviews would probably be things most programmers would consider "irrelevant stuff", but they do improve readability (thus maintainability).

You can prevent code reviews from being skipped by building your system to require them. If you feel you need an exception process to submit things without review, make that process ring alarm bells and require an after-the-fact review (possibly with a manager sign-off). There are technical solutions to these problems.

Alternatively, consider pair programming (so that the other member of the pair does the code reviews), or pseudo-pair programming, where you work independently but you're still focused on (prioritize) each other's code reviews when they arrive.

Re:its a lost cause

[mwvdlee]

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.

While you're at it...

[JeanCroix]

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

My suggestion.

[DoofusOfDeath]

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!

DailyWTF

[Anonymous Coward]

Post his code to the DailyWTF then send him the URL

Does the guy really qualify as seasoned?

[Sheetrock]

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?

Old code

[holophrastic]

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

[Bob the Super Hamste]

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

[MightyMartian]

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

Add code reviews and coding standards...

[GaspodeTheWonderDog]

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.

Look at Linus

[rastos1]

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

Re:Look at Linus

[TheSpoom]

Linus's example works when you're the Big Boss. My guess is that OP is (unfortunately) not.

Yelling at peers is a good way to get fired yourself.

Coding is thinking

[erroneus]

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

[Shinare]

whats it to you?

Submit the best examples to TheDailyWTF

[Megahard]

And send him the link.

TheDailyWTF

[RHIC]

Why not post a representative sample to TheDailyWTF, and when it shows up, call him over with: "hey, come take a look at this shitty code someone posted, how could anyone write something this awfu... wait, isn't this yours??"

How long...

[Anonymous Coward]

How long have you been working on the code? I was convinced my boss's code was total garbage for a year until I started reimplementing it 'my' way to find that alternatives were worse, now I mirror his style closely and am producing the results I need much faster than I could otherwise.

Re:code reviews and scoring

[GaspodeTheWonderDog]

All submits should start with a score of 100 and should be able to slip into negative infinity.

Your coding standards should be written in such a way that they can be difficult to understand and abused for your own purposes. Always allow for exceptions to any rule, but that they have to be allowed by a select few (only yourself if possible).

You should use things like poor comments to beat people over the head to show them how much smarter you are as well as deduct points.

Don't actually give out the coding standards or code review documentation to anybody, make sure that you make a power point presentation that 'dumbs it down' for everybody, this will make them feel better about the doing the reviews but still allow you to nit pick over every little detail.

Remember to ensure that your submits come in from 90-100, so that you can beat everybody else out but still show improvement from time to time.

Finally, you should always wait until the last minute to do any code reviews and enforce standards, this way you can ensure that you really only review the people who you want to chastise with a lower chance of repercussion from others reviewing your own code.

P.S. also ensure that you promote people committing directly to trunk and causing the most amount of breakage possible, that way you can deduct points from their code review because you should have a note that for each code breakage infraction they lose points.

Have someone else fix his code bugs

[realsilly]

I perform lots of testing on my team and the ones that code well can usually find the reported bugs and fix them fairly quickly unless the logic of the code is extremely complex. But, by having another team member debug your code, the sheer amount of vocal bitching at shitty coding standards will begin to give the bad coder a clue. It will probably float up to management which will either push the employee to training, start following standards, or show the bad coder the door.

Re:Which site is this?

[BitZtream]

Seconds after CmdrTaco left :(

Consider this

[asmkm22]

If you can't explain to him why your code is so much better than his, and your argument boils down to something like "it just is" or "it's common sense" or something, then your method may not be nearly as great as you think. Your example of "Do you see how much better this function is when written this way" means nothing if you can't actually elaborate on why it's much better. Is it simply easier for you to read? Is it more efficient? Is it more secure?

A better approach would be to simply ask him why he codes the way he does. Bring up a particularly "bad" example of his work and just ask him about it. Maybe there's actually a reason you hadn't considered before. Or maybe he'll tell you why, and you can constructively offer an alternative method to see what he thinks. It's very possible he's just stuck in his old ways of coding, which is a situation you'll probably find yourself in sooner or later, but it's also possible there's a reason. Simply accusing him of bad coding practices means you'll never know.

Re:Fire him

[BitZtream]

Or just start the hiring process in general. Make one of the requirements that the new programmer must be able to do do 'insert problems with current programmer here' and make sure its known that you feel the current guy has those problems.

Generally that will get some attention.

Buy him a present

[rabenja]

...the book Code Complete

Re:Buy him a present

[benjfowler]

+1.

Excellent read. We just got a new development manager, and his first act in the job, after talking and carefully listening to everyone on the development team, was to expense a copy of Code Complete, and ask everybody to read it. When somebody is this clueful, it builds confidence...

Make him read his own code

[kiick]

Take something he wrote several months ago, that he's not likely to have on the top of his brain. Then ask him to debug, add to, modify or analyze his own code. Or just ask him to give you an explanation of how it works. It might dawn on him that his own code is unreadable and hard to maintain, if you do it right.

I'd also push back on your manager, to make it policy that until this guy gets his code in shape, he is the one who has to maintain it. Bad code is bad even to those who wrote it. Make him work on his own code.

Easy solution that works - psychological judo

[raymorris]

Since I'm arrogant like that guy and sometimes write less than beautiful code, I bet what works on me would work on him. He won't change radically overnight, but you can affect change without drama.
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 .... . D you think I should break this function into two, maybe buildSpreadsheet() and saveSpreadSheet()? Would that be better, it terms of "Functions should be short and sweet, and do just one thing", do you think? Two days later you ask him to look at your variable names and tell you if he can tell what each is for, or if he thinks you should rename any of them to make it more clear. He's helping you to make sure your code is readable and clear.
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.

Reading Comprehension, D-

[westlake]

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.

So what?

[SuperKendall]

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 totally agree. But we already know the guy in question is a shitty programmer. So then it would be PRETTY DAMN STUPID to give a book to someone to prove what we already know, an alienate a powerful person in the company to boot.

If someone is not reading books already on how to be a better coder there is nothing you can give them that will help, and anything you do very likely will make things bad for everyone.

Re:its a lost cause

[gmack]

I disagree, SQL is a skill in it's own right and someone practicing multiple skill sets will rarely be as good as someone who specializes in it. If there is an agreement between the SQL devs and the devs handling whatever other language interacts with it on the needed data and what form it's in, I find it's it's actually better to have them as separate functions.

The downside, as with any other language, is when someone starts trying to show off how clever they are or when you have the "if all you have is a hammer" type of person.

if (coder.suck) { return false; }

[TiggertheMad]

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.

First off, the poster is wrong, his coworker doesn't write the most horrible code ever. Because I work with the guy who does that. He is the worst fucking coder I have ever seen. He learned hobby level coding skills sometime around 1992 in visual basic, and he is still coding the same way. The sad thing is, his boss knows he sucks and won't fire him, so every year the code base gets more and more fucked up.

I have worked with a lot of coders over the years, and there is such thing as stylistic choices when it comes to coding, and this isn't the same thing as writing bad code. I have worked with a few great coders that had style that drove me up the wall. Although I might dislike their style of doing things, I would be the first to say they are top notch coders because their code was elegant, simple, robust, extensible, scalable, etc. This is not the case with bad coders.

I'm going to go with the OP on this one and say that it probably is just a lousy coder, and not a misunderstood savant or something. Odds favor the guy just sucking...

Book Club

[terbeaux]

Organize a weekly book club where you read a chapter from a book like "Code Complete" or "The Pragmatic Programmer" and everyone talks about the chapter together for an hour and relate it to current practices on the team. Get your manager to splash out for pizza and beer or peanut butter and chocolate (or both). This allows everyone to think that they have formulated their own ideas instead of having to deal with the defensiveness that is associated with (even constructive) criticism. You may also find yourself learning things that you thought you should already know.

Everyone on your team will get better including yourself.

That's true

[Weaselmancer]

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.