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

[Anonymous Coward]

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

[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

[asmkm22]

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.

Re:You don't

[nut]

If the OP has to help maintain this code, and is also held partially responsible for the performance and robustness of the software, (management tends to see development teams as an amorphous software-producing blob) then the guy IS making his job a lot harder.

So;

When you deliver criticism of someone's code, always be as specific as possible. Choose one class, or function, or whatever and offer an alternative solution which is demonstrably better.

The message should not be, "You fscked up," but, "Hey I found a better pattern for this class of problem, don't you agree?"

Try to make the atmosphere of the interaction collegial rather than instructive. Nobody wants to be corrected, particularly by someone more junior, but if you can persuade him that you just have good ideas you might have a better chance.

You can probably find lots of other advice on effectively delivering criticism, I'm sure people write about this stuff. You can google for it, I can't be bothered.

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

[Anonymous Coward]

Totally disagree. In team programming environments, there is a strong chance that a bad programmer's code may become your own. There is no substitute for writing good code to begin with. Bad code, and by bad code I mean unmaintainable code, hurts your company and directly affects the productivity of your team. It can be your place, because you SHOULD have an interest in protecting the interests of the company you work for. The question should be, is it in the company's best interest to risk causing contention to reduce the bad effects of poor code? Depending on the maturity of your company, a bad programmer may be worth less than no programmer at all.

Re:You don't

[sl4shd0rk]

So, STFU and let management deal with him

Exactly. This boils down to one of the basic problems in any profession. How do I work with people who I think are a boat-anchor to the rest of the team/department/office?

Best advice is: do your job. keep your nose out of it, period. If another person's performance affects your lead-time, let the boss know and then document that you did. Never utter another word about it. To anyone. Also, Making it the topic of office party conversation eventually bites you in the ass too.

Many times, the boss knows he's got some anchors dragging, but he's not up to doing anything about it for various reasons. Sometimes political. Sometimes personal. Sometimes he just doesn't want to fix something that "isn't that broken". Either way, unless you're the boss, standing in front of that truck will just get you run over.

Re:You don't

[Feadin]

Unfortunately, this is about right. But always remember the reason: Idiots outnumber us.

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

[fredprado]

Well, he may not be the best coder out there, but if the company doesn't care and if he is not breaking any enforced standard by doing so it is actually a true statement. It is not his problem.

Re:You don't

[Anonymous Coward]

If you cant understand the code maybe you should go read the language specification again :-)

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

[T.E.D.]

Also, are you sure that his code is that terrible?

In general, I agree with this comeback. However, assuming he is right about putting entire programs into one procedure, then either they work at a "Hello World" factory, or yes the guy's code sucks.

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

[Anonymous Coward]

Writing code to get from point A to point B is brain dead simple.

Point A: I have an arbitrary program and its inputs.
Point B: I know whether this program, ran on these inputs, will halt.

Re:You don't

[fat_mike]

You and the OP need to grow a pair.

Re:You don't

[avandesande]

The number one things that helped me improve was hating the way I did things with an equal measure of laziness.

Re:You don't

[Maudib]

Was there any people that was willing to educate itselves on grammar?

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

[tnk1]

Strictly speaking, he certainly could be a masterful coder at generating the desired effect from code. Unfortunately, being bad at standards and communication makes him a shitty employee on a team unless his code can be all black-boxed and has a decent interface that no one ever needs to look inside of it.

Even when you have that, you are putting your code all in one person's hands, and unless you can find a second person (at least) who can understand it, you're starting to play roulette with your ability to support your code as a team. No good manager wants to encourage that situation if they can help it (although bad and mediocre managers are not unheard of).

Of course, the coder doesn't necessarily care about the team. However, if he takes that attitude too often, and in front of the wrong people, he will cease to become the company's problem soon enough. That's why making sure that he is forced to make those comments in front of someone who does his reviews is a good way to at least get a civil response.

Re:You don't

[Anonymous Coward]

"If you're gut reaction to criticism, constructive or otherwise, is to behave like a 12 year old, you are a shitty programmer."

That doesn't make you a shitty programmer. It makes you a shitty person. Or at least a person who is so immature they respond to professional criticism by throwing a tantrum like a 12-year old. Any immature person, progammer or manager or garbage collector, can act this way.

So it's not a flaw as a developer butrather as an adult. This behaivor likely impacts many aspects of life (ask the spouse).

Re:You don't

[fotoflojoe]

About the fastest way for anyone to piss off their co-workers and bosses is to walk around with a "I'm the best [INSERT_PROFESSION] here" attitude all day, whether it's true or not. Don't do it.

That's a life lesson right there.
Wish I had mod points

Re:You don't

[jwkane]

Tough but true.

The best you can do is make sure your own code is clean and clear. Eventually the contrast will be noticed and management should step in to figure out how to overall improve code quality. In theory they will consult with the developers that have demonstrated good practices. It is quite possible, even likely that no one will care.

You do your job. You write your code. If you do well you may end up managing a team. Then you can implement whatever kind of quality control you feel is appropriate.

Re:You don't

[Applekid]

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.

I would add to just try to keep an open mind. One person's OOP abuse is another person's OOP leverage, and in the event some of his are offensive to you but a good idea, you should be graceful about adapting as much as you'd like him to be graceful. I've fought in some of the holy wars, and if you can't afford to lose any territory, don't pick the fight.

With so many ways to skin a cat, the key is compromise.

Re:You don't

[Macgrrl]

Previous sentence broke my brain.

Re:You don't

[Nerdfest]

If his code is hard to understand, maintain, or add features to quickly to without breaking things, then management better damned well deal with him, as what you're describing is not 'good code', whether it works or not. On a complex project, I'll take maintainable but not all features completely working for quite a long time over everything working but unmaintainable. Writing the initial code is the easy part. It's when the first changes need to be made by someone else is when you find out if it was well done or not.

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

[UnknowingFool]

I think the situation can be assessed in that the other programmer does write really good code; good code back in the day when they were no alternatives to do it the way he is doing it. I see this sometimes with older programmers who despite knowing what object oriented means and using some basic functionality of it, still program everything as if it were procedural. It's just a new way of doing things and the other programmer may not fully want to embrace it. It's really up to the other guy to get with the times; after all if a mechanic only knows how to work with carburetor engines, he's only work on older cars forever.

Re:You don't

[Applekid]

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

Would your opinion be different if Anon said "here at Microsoft"? :)

Re:You don't

[Darinbob]

Well I was implying that people with knowledge of the subject area. Another kernel coder should be able to understand kernel code, barring possibly some device details that they don't have data sheets for (though presumably good code would have comments about the tricky stuff).

Re:You don't

[jgrahn]

Unless he's making your own job a lot harder or you're his boss (or project manager), it's not your place.

Ah, another Slashdot cynic of the "you are unimportant, your work is worthless, and you should just grab the money with as little effort as possible" school.

*Of course* it's his place to help his neighbor to improve. Without that we're just animals.

Can he do anything useful in this situation? That's another question, and the OP doesn't give any real clues. I get the impression he may want to vent more than anything else.

Re:You don't

[fatty2by4]

In short: Lighten up, Francis.

Sergeant Hulka, our big toe...

Re:You don't

[AmiMoJo]

Find a better job and say his terrible code was the reason you left to go work at a real code shop with actual standards. Win-win.

Re:You don't

[jgrahn]

If other programmers can not understand it, then it's bad.

Not always. I've often worked with people so dumb/lazy/undereducated that they couldn't understand normal-level code in whatever language and environment we were using. Dumbing it down for their benefit would guarantee that the situation would never improve; average to smart programmers would stay away and so on.

There are techniques which are *too* clever or *too* bleeding-edge, but there are others which have to be understood. For example mild C++ template usage: probably too bleeding edge in 2002, but not optional to understand today if you're doing work in that language.

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 other programmers can not understand it, then it's bad.

True, but what we have here is the opinion of one programmer. I've worked with people who have many years of experience, but it was all mostly the same sort of stuff, and whenever they were confronted with anything that didn't fit with what they were used to, they'd label it "incomprehensible" or "messy", when really, what they meant was "I've not used this language construct/idiom/design pattern before, I want to do it like I've always done it".

Now reading the submission, it doesn't sound like that's the case here, but I'd be wary of jumping to the conclusion that just because one developer has voiced a problem with some code, that the default assumption should be that it's the code at fault.

Re:You don't

[Synerg1y]

To add, if the guy with the bad code is your senior, guess who management is going to believe.

Why I'm leaning towards agreeing with OPs view of doing nothing is because you say he's a smart person... I've worked with senior devs who's hands I've had to hold, but... I wouldn't call them smart, others might, not me. If I can optimize your code, make it smaller, more compact, and/or faster (not just different... & perf. is the major player here) then I'd say I've got room to tell somebody how to code, but it almost sounds like you don't understand his code, and with him being the senior, it becomes really hard to seriously consider your recommendations.

There's even a few things I can think of that make good code look bad:
1. Excessive error checking without a 3rd party library... I've done jquery error checking without the validator plugin and it looks about 100x more convoluted while doing the same thing... I gained performance & my successor isn't going to have to learn the validator plugin, so I have reasons that may not be apparent right away. 2. Abstract variable names... cNum is an example, it would make sense to me in context of the app, say it deals w customers so cNum = customers, maybe not so apparent to somebody not as familiar with the business logic of the application. Not the best of practices, but it can fly, esp. if there's no standard. I can also make the argument that any programmer worth their salt can use a debugger to unravel even the most abstract variable names... newer versions of Visual Studio have a ton of features for this. 3. Boredom... code so much and you start looking for cool new ways to do things like crazy object handling, or lambda expressions :)

I'd recommend just sucking it up... or updating your resume... or trying to learn a few things from your senior.

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

[Americano]

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

Correct. But that doesn't mean you can't approach your boss with a suggestion for improving things. If your goal is simply to bust your co-worker's balls, you're going to look like a smug asshole no matter how nicely you put it. If your goal is truly the betterment of your team's product, then there is a way to approach this that won't make you look like an asshole, and in fact, will make you look like a huge team player who really wants to make things work better.

Consider the difference between this:

"Hey, Boss - I gotta bitch to you about Bob. He writes the shittiest code ever committed to electronic storage in the history of the world - hand to god, that's no exaggeration. This asshole thinks he's clever, and I really want to see him get his shit taken down a couple pegs, because frankly, I don't like old people - they smell funny. What do you say I just ride his ass for the next six months until he snaps and kills us all in a fit of murderous rage?"

And this:
"Hey, Boss. I have a suggestion. We have coding standards, but people don't really follow them very well; I'd like to suggest that we review & update the coding standards, and then implement a regular code review policy to make sure people are following those standards. There's lots of documentation showing that this practice saves time and results in better code, so I think this could be a really big win for us. If we spend a few weeks updating those standards, and then put an ongoing code review in place, we should produce more & better code as a result, which'll mean more bandwidth for new and exciting projects, and more vacation time to party on the yachts management will buy for us with all the bonuses they shower on us! Whaddya say?"

The first is personal, and very clearly targeted at your singular distaste for a single person's work style. This is a bad idea, because it makes you look like an asshole. The second is constructive, and should clearly include yourself in the 'needs improvement too' category - meaning, you're not strutting around talking about how everybody else is shit, but you're perfect - you're acknowledging that nobody's perfect, and everybody could improve, and you're offering a suggestion as to how you can go about improving.

Do the first, and you're an asshole. Do the second, and you're just a straight shooter with upper management written all over you.

Re:You don't

[Nethemas the Great]

Old people don't like young people managing nor even instructing them especially when no respect has been earned.

Re:You don't

[sourcerror]

how this guys boss is ok with checkins like what the poster is describing

You made the brave assumption that they use revision control.

Re:You don't

[Nethemas the Great]

On my team if I see a "goto" statement in OOP code, you get a warning. If I see it again you'll find yourself on the short list for dismissal. Blatant and arrogant refusal to conform to best practices in general yields much the same treatment. Your pride had better be worth your job because most dev houses have little tolerance for people that arrogantly refuse to support the team's ability to evolve and maintain the codebase.

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

[n7ytd]

On my team if I see a "goto" statement in OOP code, you get a warning. If I see it again you'll find yourself on the short list for dismissal. Blatant and arrogant refusal to conform to best practices in general yields much the same treatment. Your pride had better be worth your job because most dev houses have little tolerance for people that arrogantly refuse to support the team's ability to evolve and maintain the codebase.

Why the "in OOP code" disclaimer? The only place I've ever seen goto sanely used in C, for example, is to implement the equivalent of an exception handler that would have been done with a try/catch in C++. But that is not because of the availability of objects in C++, but rather the exception handling.

Re:You don't

[Beorytis]

Probably, unfortunately correct. Also incomplete. After S-ing the FU as suggested, dust off your resume and start looking elsewhere. If The company's existing management and quality procedures haven't detected and addressed this issue, they probably won't ever. You'll be better off at a different job.

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

[Sir_Eptishous]

Nicely.

Re:You don't

[Anonymous Coward]

Sounds like a fairly stupid rule to me should it be enforced thoughtlessly. One of the more colorful pieces of C++ OO code I wrote uses several gotos and non-local jumps using exceptions (go on, puke your guts out). This is not just because I could do it that way, it actually was the most concise and logical way of keeping the expression close to what the code is supposed to do (=readable).

And I strongly discourage our junior programmers from writing comments. (rationale: 1. they otherwise tend to make big ascii-art banners saying 'this here is a function' 2. once you write a comment, it has to be updated along with the code; once someone forgets, the comment will start lying to people 3. the code itself should be readable, only if you do something excessively clever or it is not obvious WHY you are doing this, you are permitted a comment)

Or maybe I'm just a monster. :-)

Re:You don't

[Lisias]

Feel free to write using proper grammar.

The ones willing to learn the correct ways will follow you. =]

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

[lgw]

There's definitely a place for got in many languages. Just because you were taught some "goto is bad" rule in shcool doesn't mean it doesn't improve maintainability in some cases. The canonical example is exiting from nested loops in a language that doesn't offer a specific way to do that - the convolutions people will go through to avoid a simple, clear goto do not make the code more clear, OCD and ritual aside.

Re:You don't

[omfgnosis]

You shouldn't, and don't need to, write JavaScript that way either.

Re:You don't

[Smauler]

The OP is not necessarily just cynical. Your opinion seems to be you should always try to help, whatever the outcome. In many cases trying to help your neighbour to improve can be harmful, in one way or another. Failure to recognise shortcomings in your own skills, and trying to help someone who knows what they're doing makes the "helpful" person the problem.

I'm not saying this is the situation here, but people always trying to help when they've no idea what is going on is beyond irritating.

Re:You don't

[Zadaz]

Oh god, the last thing you want is someone who writes crap code working by himself. He'll create his or her own little empire of code madness that no one else can maintain.

The answer is simple: If you don't have the power to fire them you bring the problem to the attention of those who do.

We don't have to keep employing people who don't ear their keep.

Re:You don't

[geohump]

No, I've seen code like that and it is HARMFUL to have it in your project.

This person is going to slow down or hurt the project. When do you do something about it? At the very earliest point that you can. If they won't change their coding style, give them a task that doesn't involve coding.

True confession: I've written code like that and included it in a project -

Why - Standard reason, there's never time to do it right. There's only time to do it over.

It starts out when you want to quickly test out some bit of code so you put it inline within another function instead of doing the overhead work of adding another file to a project, compile - repeat.. etc until you end up with a giant monoglob of crap.

Re:You don't

[Anonymous Coward]

"would be caught at any half way decent company" by the idealistic definition I suppose.

For the most part companies don't care about code, they aren't the idealistic decent company. What they care about is shipping product and making $$$s. Ergo most companies don't give a rats ass about code review and this has been my experience thus far.

For these companies having a few guerilla code cleaning masters on deck can be a boon, and the worst thing to do is to try and stop them. I would promote the distribution of knowledge here but if you're talking up the hierarchy it can be a political minefield and definitely careeer-limiting.

Re:You don't

[segfault_0]

In my experience many "old" coders are lazy and focused on retirement -- which is why they aren't interested in the young guy's ideas -- not because the way Dad did it back in '82 is necessarily better.

You know who the leaders are among the older coders and you don't need a flashing neon arrow pointing to them to know they know their shit. They either naturally fall into positions of respect or were forced into architect/manager positions by now.

If you can't work with others, can't learn new tricks, and haven't learned to be open to constructive input -- regardless of its source -- then you probably aren't half the programmer you think you are. This is why we have the "how do i keep employed as an older coder" articles on here every 3-5 months -- because old coders lose their ability to adapt.

Re:You don't

[overmoderated]

That's obviously the attitude they use at Microsoft HQ.

Re:You don't

[segfault_0]

I agree, the primary attribute for a programmer who will have real longevity is the guy who is learning right till the day he retires.

I make it a point to not let the kids get a lick in on me. I learn the new languages, I use the new libraries, and I rub their noses in it that they didn't find it first and bring it to me.

Re:You don't

[plopez]

I was going to suggest management.

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

[I Mean, What]

If other programmers can not understand it, then it's bad.

You're assuming that all programmers are at the same skill level. More than sloppy coding practices, the general act of assuming (anything) is the most annoying thing to me about other programmers. We are not in a profession that provides us the luxury of assumptions. Go be a movie or art critic if that's your bag.

Addressing your comments specifically, as others have pointed out, quite often the assumption that a programmer's code is bad comes from a programmer who is not aware of their colleague's higher skill level. A novice may assume that if code is not easily understood it's automatically bad, when in reality the "offending" programmer might simply be using advanced application development techniques/design patterns. For example, the novice may not be aware that his/her own code is horribly tightly coupled - they might even believe tightly coupled is good! Until they get over their ego and open their mind.

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.

You're apologizing for less skilled programmers' lack of skill. You're suggesting their lack of skill be accommodated. If intelligently designed code is a "burden" to a novice then they are both blessed to be working with a coworker who can teach them by example how to write better code and obligated to overcome their lack. Ignorance is no excuse. We're engineers, we don't tolerate dumbing down.

Re:You don't

[anonymous_wombat]

I once worked with a guy who thought that the function pointer was the best feature of C.

He then explained to me how using function pointers was kind of like OOP.

There isn't any point in arguing with people like that.

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

[bbulkow]

This. I remember one group I managed where two people privately came up to me and said "That guy is a problem and writing problem code". As a good manager I looked a level down, made up my own mind, and managed him out. I got credit for improving the company, rightly so. Don't go on a warpath. Just drop a hint to your manager in a non-confrontational way and leave it alone. They'll take it from there, or they won't.

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

[TempestRose]

Bingo. No matter WHAT you do, you have almost zero chance of success.

Any programmer who, in this day and age, writes code as you describe, is DOING IT ON PURPOSE to extend their "worth" to the company, by being obtuse.

I feel your pain, but unless you are really close friends with this person, or can BECOME very close friends, I think you're SOL.

So actually, now that I just thought of it, you could become close friends with the dinosaur, and THEN, perhaps, guide him/her?
Good luck my friend...

Re:You don't

[mjwalshe]

and quite often these "young" programmers think that OO is the one true paradime that All coders must follow - for a substantial number of problems I would suggest that OO is an extra over head that you probably don't need.

Re:You don't

[Nefarious Wheel]

Previous sentence broke my brain.

Yes, that was tense.

Re:You don't

[mariox19]

Let's just take what the "new guy" says in this instance as reliable, just for the sake of argument. Then, regarding the "last guy," what he's doing wasn't acceptable 10 or even 20 years ago. If someone writes a wall of text on an online forum, we jump all over him. A wall of code is no better.

Re:You don't

[SleeknStealthy]

I agree this is a common problem, but not for the reasons you list. The best software that I have read comes from experienced programmers, who through education and enumerable amounts of experience can construct robust designs that are elegant, powerful and scalable. Every engineer can bring ideas to the table and it is important for a work environment be conducive to criticism, design discussions and most importantly change. My suggestion is to change his code and comment it as much as possible. Sometimes people don't get the point and if you have to live with their mess, do yourself a favor and fix it. I do this everyday, fix other people's code, mumble to myself and then move on.

Re:You don't

[TranquilVoid]

Well you could implement vtables and therefore polymorphism using function pointers but you'd want to have a very well abstracted framework to make sure it didn't swamp coders with complexity overhead.

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

[sg_oneill]

I cant stand C code written by engineers. I had one guy I worked with who was an incredibly smart hacker, working previously for Sun doing CPU design. But he wrote fecking *awful* code that looks like it wanted to be PLC ladder code or something. Giant switch statements , gotos everywhere, almost no use of functions (It was almost all in the main(){} section) , and what functions he did use, he'd pass variables around with static defines, and so on.

And lots of assembly, which I wouldn't criticize if it wasn't for the fact it was usually in totally non time critical sections and for which a few lines of C could easily replace 2 pages of contorted ASM.

The guy just had no feel for abstraction at all, which I guess makes sense if your designing a logic bus for a CPU where you *need* to think in terms of raw implementation, but makes for awful and unreadable code.

Needless to say none of the rest of us on the team could work with his code, but what where we to do? He was clearly a very knowledgable grey beard, and management loved the guy simply because they could brag about a senior coder who "designed chips for Sun" , but he also believed his own advertising copy and thus refused to listen to criticism from us lowly CS grads who just wanted him to write code that we could follow.

Oh and he couldn't read any of our code either. "Too abstract" he'd complain. Fool.

Re:You don't

[Immerman]

And it's possible to write good code in VB. 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 use" language.

Also known via the more general adage: Create something simple enough that even an idiot can use it, and only an idiot will want to.

Re:You don't

[sg_oneill]

This is actually why I love working with Python code. The design of the language means that it actually requires talent to write unreadable code and as long as someone uses sensible symbols (variable/class/function names) and avoids getting too carried away with things like Lambdas and the like, you can almost always read an experts code and a beginners code with about the same difficulty level. Good python can by explained to your boss, the language is designed for that shit, and if respected in that spirit its a fantastic, and honestly if the server takes a bit of a performance hit, the costs are more than offset by significantly reduced labor costs.

I've been coding nearly 20 years, and I've come to decide I value readability over cleverness. If I have to keep a copy of bruce fowlers pattern book beside me, or a pen and paper to decode some hideous logical nest of conditional craziness , I can only conclude the coder needs to simplify his shit because he's wasting my old-ass time working it out.

Now, combining readable AND concise, thats where the real skill is.

Re:You don't

[Anonymous Coward]

People that were willing to learn better ways didn't need my criticizing, they just looked at my code and adopted the ideas they liked.

Re:You don't

[Immerman]

Heh, reminds me of my own college days. I was easily the best coder in any of my classes, by the end of my freshman year both the seniors and professors would come to me when they got stumped by something. My most infuriating professor was the one that would knock a bunch of points off of code that was clearly the cleanest, most efficient implementation in the class just because my comments or design wasn't completely perfect. In retrospect he was also easily my favorite, and probably the primary reason my skills actually improved in college. My thanks to him, and to any professor that slaps around a cocky know-it-all well enough that they can actually start improving even further.

Re:You don't

[nanospook]

It's all good until he leaves the firm. Then you guys are fscked! At minimum when you try to do maintenance or enhancements you will havfe to invest a lot of time and energy. Ok, so he wrote a highly optimized piece of code that works and makes money. That is awesome. Some people are brilliant at this stuff. But nothing stops him from going back after the fact and putting his thoughts in to make it easier to undertand the code. Maybe he can't do anything he is not immediately interested in?

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

[stanlyb]

Nope, here is the analogy: If you need a spaceship built with prehistoric technology, he is your man, but if you wanna anyone else to do it, even with nowadays technologies..... what to say.

Re:You don't

[Immerman]

Indeed. If you can convince your geniuses that there's value in maintainability by non-geniuses so that they don't get into a snit-fit when someone else refactors their work to improve maintainability you'd really have something. Even your geniuses might come to appreciate it when working on code written by someone else, or that they haven't looked at in year or two. It's really a whole different skill set - just as with a literary editor you wouldn't need to be able to create brilliantly yourself, but you would have to be able to grasp the existing work well enough to actually contribute to it with your own modifications, a challenging task in it's own right, and probably better aligned with the sill set of many who call themselves programmers.

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

[Immerman]

I have to disagree - if something is in fact a standard DesignPatternX then anyone reading the code will probably gain far more insight with five minutes on google than an hour of reading more detailed comments. Good coders write good code - it's a skill largely independent from explaining non-trivial concepts in a clear an concise manner to people that haven't encountered them before. That's a valuable skill in it's own right, and it's a fool that struggles to do a half-assed job explaining something when an expert has already done the job for him.

Re:You don't

[celtic_hackr]

Why the "C" disclaimer? There is more than one language used in the world, and I still support some code where gotos are necessary, as well as labels. There was a time not many years ago, where I would have 10, 20 or even 40 gotos in a single program I'd write on a daily basis. And it ran faster than probably anything you've ever written. Much of that code still runs today on a billing system billing 100s of millions of dollars annually. All rock solid and untouched for nearly a decade. It just works. I was the lead on the team that converted the system from a mainframe, and the billing programs that once took literally all weekend to run, now run in less than an hour. Context is everything. Granted this is not the goto used to taunt kids with. It's an almost necessary part of the obscure and aging language.

Re:You don't

[Immerman]

He had a point - OOP just nicely encapsulates the function pointers in a manner that gracefully handles 90% of the use cases of what can otherwise devolve into real nightmare. Just like an if-goto is kind of like a while loop: the loop is far less flexible and powerful, it's popularity comes from the fact that it handles most cases adequately, and is far more resistant to totally buggering up the code. The problem only comes in not appreciating the relative merits - I've seen some ugly instances of spaghetti code and of "naked" function pointers, but I've also seen some hideous code written by purists who refuse use them even when they really are the right tool for the job. The worst being the idealogues who do things like refuse to even use "break/resume" or more than one "return" per function, even when the alternative is hideous snarls of redundant conditional statements. Yes, there are good reason not to get in the habit of using some of the more powerful language features on a regular basis, that doesn't mean they should *never* be used.

Re:You don't

[celtic_hackr]

Igorance is bliss. I have to wonder about the depth of your experience. Having been around long enough to know a number of guys who worked on some of the first computers ever made, and seeing them "retire", and others come along and retire, I call bullshit.

I'm not yet at a retirement age. I could retire. My brother retired at about this age, as did my father. Rather than retire, I started my own company, and I do well enough. Old people don't lose the ability to adapt. That's just FUDspeech. Some people find adapting harder, than others. But not all old people do, and there are plenty of young people who can't adapt either.

You make a lot of unfounded and unbalanced claims, which simply don't hold up to the light of day and the rigors of time. Sometimes great coders lie hiddne in obscurity, bacause they have personality issues that make people shun them, and their skills go unnoticed.

Re:You don't

[Shao Ke]

Yeah, careful, they'll probably make him a manager.

Re:You don't

[Immerman]

And if his code actually is brilliant he may have a point. A few brilliant programmers to break new ground and an army of code monkeys to convert their work into something that dots all the i's for future maintainability may actually be an extremely viable approach. It works well for literary authors and their editors. The problem is that many self-proclaimed geniuses have a hissy fit when anyone else touches "their" code, and many code-monkeys don't actually understand brilliant code well enough to modify it productively (a problem that also occurs in the literary world). A little mutual respect and communication can go a long way towards solving the problem though. Geniuses need to recognize that they do tend to make a mess of things from the perspective of smaller minds, and that understanding and simplifying their work is a non-trivial undertaking that means they may have to answer "stupid" questions on a semi-regular basis. And the "monkeys" need to realize that not everything can be forced into the neat little boxes of "approved coding standards" without increasing the complexity dramatically - that doesn't mean the code in question is "ugly", just that making it readily comprehensible is where they have to do their own heavy lifting.

Re:You don't

[PiSkyHi]

Writing well documented, structured, KISS designed software and tools will ensure you remain expendable to management.

Re:You don't

[smellotron]

He then explained to me how using function pointers was kind of like OOP.

He's right. See fopencookie, which provides a way to abstract an arbitrary stream as a FILE*.

Re:You don't

[funwithBSD]

I work in a highly matrixed environment. If one of my Project Managers, Distinguished Engineers, Director, or even a VP tried that stunt, they would find out what CC is for as I ask what task they want me to drop from the list of priorities... and I would include all the people at risk.

Let them fight.

And it is a case of the Peter Principle. But here is the thing: if he hangs onto the code control, you go limp and make him drive you on every task, suck him into micromanaging you. Eventually he takes a medical leave and finds a new job.

He is no longer a producer, he is supposed to make you produce. If he fails at that, then his job is on the line.

Ask for confirmation and approval for every little change via email.
He won't be able to keep up, and if he starts rubberstamping everything, the mistakes will get credited to him, as you "got his signoff" before it went in.

Just make sure you follow everything he says and don't get any smart ideas and take the initiative.

When you get dragged into HR or a bad review, you have to be clean and ready to point out you did everything he asked exactly as he asked for it.

Re:You don't

[starfishsystems]

Dude, you've just perfectly described my work! And with a compelling metaphor at that. May I borrow it? (With credit to you, if you'd like.)

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.

Re:You don't

[ranulf]

My suggestion is to change his code and comment it as much as possible. Sometimes people don't get the point and if you have to live with their mess, do yourself a favor and fix it. I do this everyday, fix other people's code, mumble to myself and then move on.

DO NOT DO THIS. Seriously, whether you like their coding style or not, there's better things you can be doing - for example your own work. But reformatting someone else's code (or even worse, restructuring it) can make it impossible for them if they're still working on the code and need to merge their code back in to what you've turned it in to, or for them to fix bugs in that code later on.

There's also the very strong likelihood that you won't actually understand all the subtleties of the code and you'll break something in the process. I remember a junior programmer doing this at a previous company who refactored and reformatted the code of a colleague who was about 20 years older, so basically the same situation. The younger guy's check-in comment: "Refactored code to look nicer". The older guy's next check-in comment: "Refactored code back to working" (he reverted the entire changeset back to his version).

So, the upshot is that at best you're just going to make the other's guy's life harder, at worst you're going to break the code in the process.

Personally, my golden rule is to change the minimum possible with each check-in, unless the task is specifically to refactor or rewrite a big chunk of code. If that means temporarily abandoning your preferred code style to work in a style that's consistent with the code area you're working in, then do so. Of course, that's what coding standards are for - to try to ensure the style is uniform is the same across a project, but that's often not possible across language boundaries or on projects that have merged.

Re:You don't

[tlambert]

If other programmers can not understand it, then it's bad.

I have discovered there is a very low bar for who is permitted to call themselves a programmer these days.

People have suggested code review as a means of dealing with the issue, and that's true - if you are equally willing to learn from the person you are reviewing, and not simple there as a means if criticizing their readability.

There are a lot of non-obvious techniques for various languages which lead to better code and fewer bugs, and since the early 1990's when accreditation standards changed from "C programming" to "Database programming using C (which you are expected to learn on your own)", these techniques are rarely taght to new programmers, since computer languages are not taught directly, only indirectly.

This is the moral equivalent of a carpentry class with a section on "Making board flat using a joiner", with you being expected to learn how to operate the joiner, appropriate safety precautions, etc., all on your own.

Frankly, this person you are complaining about may simply have a better grasp of their tools than you do.

Re:You don't

[Bogtha]

I'm not sure you got what I was saying. I agree with that. What I was saying was that some developers will incorrectly perceive simple and clear code as incomprehensible and unclear, simply because it uses language constructs that they aren't familiar with and they don't like stepping out of their comfort zone to learn new things.

Let me give an example: A co-worker had many years of experience with C, yet it was all pretty basic stuff. We hired her to work on iOS projects. She could cope with everything that looked like C, and the basic Objective-C message-passing syntax, but as soon as anybody on the team used blocks, she complained that it was incomprehensible. It didn't matter how clear the code was, it didn't matter if converting it to her style made it much more complex and difficult to read, it didn't matter if the alternative had already been deprecated by Apple, if it used blocks, she called it bad code. The problem was with her, not with the code.

Now if you say something like "One developer complained that it was unclear, therefore the code is bad" in that kind of situation, you tie yourself in knots rewriting good code into bad and the entire team is beholden to the foibles of each individual developer.

Re:You don't

[ggendel]

I worked with an absolutely brilliant man that came out of the FORTRAN era. Two character variable names, large functions, no comments, etc. He carried this style through our transition to PL/I and then C. No one could understand his code until they understood his system, which was pretty strict. The second character identified the purpose of the variable, X was a loop counter, and so on. I supported his code after he left the company and once I got the hang of it it was actually easy to figure out where to find what you wanted.

Personally, I would never have adopted his system, but it did work for him and he banged out code quickly with minimal bugs.

Re:You don't

[segfault_0]

You sound like you pattern all aging software engineers after yourself and the guys who "worked on the first computers" -- since you're concerned about unfounded and unbalanced claims, you might want to review that one.

My comment is patterned on 16 years of experience and working directly or indirectly with engineers at dozens of companies.

Good engineers either move into architect roles (referring to planning, architecture, directing, and reviewing) or into more direct management roles (like running companies, departments, marketing and prop writing and the like).

I can tell you unequivocally that if you see an older coder who has been in the business a long time doing the same tasks as the entry and lower-mid level engineers, grunt coding so to speak, it is highly probable that they are lazy, lower-end coders and/or have personality issues that keep them in those roles. If that somehow rings a bell with you that hurts your feelings I apologize -- obviously I dont know your case.

Re:You don't

[dontfearthereaper]

I'm assuming this guy knows what he's talking about...... given that, there's a few options here:
- 'Mr. Horrible' is trying to protect his job by making his code such a PITA, that no one else wants to deal with it.(It's a nightmarish task for an elderly individual to find a programming job in the current IT community)
- 'Mr. Horrible' is stuck in or was taught some antiquated/obfuscated/twisted/bass akward coding methodology, either by choice or simple habit, and refuses to change (lots of older people are this way).
- 'Mr. Horrible' fully knows and understands what he is doing, and is doing it solely to piss you young whipper snappers off.
- 'Mr. Horrible' just wants to watch the world burn.

Re:You don't

[coofercat]

Great story.

Whilst the coworker may need a different job, it's also possible the submitter does too. It's possible the company is in "startup mode", and so is (by design) just throwing things together to get code out of the door. Proposing everyone slows down to make it look pretty probably won't be welcome.

I'm not a programmer, but I do dev-ops. Even here it's important to know if you are a startup or a mature outfit - and it has nothing to do with the company around you, but more to do with the project, the department, the culture etc. If you get latitude to retrospectively fix things up, then throwing things in is okay. If not, then you're probably better off doing it "right" because that's the way it'll be forever and a day.

Re:You don't

[JMandingo]

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.

This is me as well with the poor memory. My co-workers thank me for writing such beautiful and easy-to-follow code. I explain to them that it is about my survival, I do it more for me than for them.

Re:You don't

[3.5 stripes]

I think he was making a point about the voting a straight party ticket, similar to the communist country votes, where you could only vote for one person/party. If you're just running down the line voting for one party, you're not doing democracy right.

Re:You don't

[fatphil]

Nowadays, the youngsters seem to think that everything has to be a "pattern".

Everyone I've worked with who's talked about patterns I have found to be fundamentally lacking as a programmer. Design patterns lead to lazy thinking, which lead to flawed, or even braindead, designs.

Most of the DP dipshits have been java programmers. So I've come to associate OO with dipshittedness too (despite having lectured many courses in OOP decades, back before the shit hit the fanbois).

Re:You don't

[mcvos]

I disagree. You do this through code review by linking to your team/company coding standards (you do have those, right?).

I think this is the best answer. If your company has no coding standards and no code review, there's not really any good way of addressing bad code from a senior co-worker. So insist on coding standards and code review. Make sure the senior co-worker is involved, but don't let him do it alone. And then you have a platform to discuss this professionally.

Re:You don't

[mcvos]

(eg. he grew up under communism but voted straight Democrat... WHAT?!)

I'm not entirely sure what you think the relevance of this is, but including such non-sequiturs does undermine your own judgement of his character.

Re:You don't

[SlideRuleGuy]

Been around long enough to know that the "best" code is what your superiors expect you to produce at that particular moment. It may need to be one or more of the following: {fast (in running speed), quick to produce, high quality in terms of having few bugs, easy to understand, easy to extend, compliant with a particular standard or standards (coding, security, etc.)}, and probably a dozen more such factors. You cannot optimize very many of these at the same time.

What really stinks is that if your boss or co-workers are out to get you, software is so subjective that they can always fault you for one of the above factors that you didn't optimize for.

Oh, and you'll never get people to understand the above, to be able to use it in your own defense...

Re:You don't

[coinreturn]

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.

Said by an obvious right-wing conspiracy nut. The Democratic Party is nothing like communism. Shut off your Faux Noise.

Re:You don't

[azav]

Bullshit. He's either a help to the team or a risk to the team.

If he can't improve, there are others waiting to fill his place.

If he creates shit, it is likely that you will be responsible for maintaining it later.

Conduct code reviews - declare standards of "this shall not pass" as acceptable code.

If he keeps sucking, then this is a problem and it's his boss's duty to know about it and do something about it.

Re:You don't

[minstrelmike]

I'm an ancient coder still using Perl (at work) but one of the things I took immediate advantage of was when we were freed to use descriptive variable and function names. Code Complete, the best book ever on coding, says well-named stuff makes code self-documenting.

I remember debugging some C code a long time ago in DOS (8.3 filename limit) and I discovered the compiler had a 5-character limit on distinct variable names. You didn't get an error but the compiler confused all the variables that were not distinct in the first 5 characters!?!

Re:You don't

[n7ytd]

Why the "C" disclaimer? There is more than one language used in the world, and I still support some code where gotos are necessary, as well as labels. There was a time not many years ago, where I would have 10, 20 or even 40 gotos in a single program I'd write on a daily basis. And it ran faster than probably anything you've ever written. Much of that code still runs today on a billing system billing 100s of millions of dollars annually. All rock solid and untouched for nearly a decade. It just works. I was the lead on the team that converted the system from a mainframe, and the billing programs that once took literally all weekend to run, now run in less than an hour. Context is everything. Granted this is not the goto used to taunt kids with. It's an almost necessary part of the obscure and aging language.

That's why I wrote "used in C, for example." As I stated, I sometimes use a goto and label pair in my C code as an escape from inside the logic of a function to a cleanup routine just before the function exits, similar to how a try/catch exception handler is used in C++ or Java. In assembly? Sure. We can hide the machine code under the guise of a higher level language, but underneath it all every branch of any kind is still implemented as the same JMP opcode that the goto would have been. To not understand that is a dangerous mental trap that many programmers fall into.

Re:You don't

[n7ytd]

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.

I'm still not understanding what the ability to use objects in a language has to do with goto. Perhaps you're saying that any language that is sufficiently high-level enough to offer objects also has some other features that obviate the need for goto?

Re:You don't

[Em Adespoton]

Lighten up, Francis.

Nobody puts Baby in a corner....

You'd better back that up with one impressive dance combination....

Re:You don't

[outofluck70]

Just curious if you've spoken about Ken McElvain before on Slashdot, I seem to remember similar comments in a past about a "Ken" maybe it was you. While not a programmer myself, the success of my job depends upon good code. I have good vendors and bad ones. One is particularly good, and I wonder what his code looks like. I know that sounds idiotic, but looking at it wouldn't help me do my job better (can't code). I wonder if he's more like the mad genius, or actually puts in helpful comments. Maybe one day I'll have enough spare time to check it out. Thanks for the insight.

Re:You don't

[Lodragandraoidh]

Your post is related to what I was thinking: if there is no expectation for anyone else to maintain his code, then I don't see the problem from the complainers perspective. Of course, that doesn't help the company if he gets hit by a bus.

The agile manifesto may also be useful to consider:

Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan

That is, while there is value in the items on
the right, we value the items on the left more.

He might be focussing on delivering working software - and less about documentation or process. The management of this company might see his performance as a good thing relative to customer satisfaction...that is until he gets hit by a bus and a zero day vulnerability emerges from the depths of the gaseous mud bog that passes for his code base...

Re:You don't

[fluffynuts]

The problem becomes that of the OP the moment this rock star is no longer available (hit by a proverbial -- or literal -- bus, for example). Then it becomes everyone's problem -- except his.

Re:You don't

[lsatenstein]

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.

===
You are absolutely right. However, you might try a diplomatic approach in that you ask the spagetti man if he could help a support person to follow his code. Do find a support person so you are in the clear. Other than that, keep away.

Re:You don't

[Lisias]

Yep.

Exactly the same thing I did, 20 years ago, when I realized that I was far, but a lot far from being the best coder in the world and thought it could be a good idea take a look on more experienced coders's work and see what (and, mainly, *why*) they were coding that way.

My code is not perfect (far from it), but it's a lot better (and useful) than my ego when I was 25.

Re:You don't

[lgw]

You have a very narrow view of good code, problably because of very narrow experience. Good, maintainable code takes many forms, not just the first form you were taught in school.

Re:You don't

[LulzAndOrder]

For all these reasons, OP should convince somebody else to do this, preferably a rival. If it works, OP benefits, and if it goes down in flames, OP benefits.

Re:You don't

[Sigg3.net]

Good for you Wwgeek. Forgetting things means that you're using the creative parts of your brain; a constructive programmer!

  Now, imagine that the code you are working on is NOT constructive, just plain statements in the wild. You need good practices unless you want the code to die with you.

Re:You don't

[DarwinSurvivor]

* nmp3bot dances :D-<
* nmp3bot dances :D|-<
* nmp3bot dances :D/-<

Re:You don't

[DarwinSurvivor]

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 break and bug 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 bad editors. Oversimplifying up code, inserting the last few bugs, mixing up variable and class names, redundant comments, breaking ___ 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.

FTFY.

If you can't program, you probably shouldn't touch the code of those who can.

Re:You don't

[Immerman]

Go for it, I actually paraphrased from someone on another branch. Always happy to provide a perspective to make life flow a little easier.

Re:You don't

[metaforest]

Was there any people that was willing to educate itselves on grammar?

I don't think english is the GP's native language, and it is likely that he was using a translation tool.

Not everyone who posts here is qualified to post in English. It is called the "world Wide Web" for a reason!

Get over it.

Re:You don't

[philip.paradis]

You shouldn't, and don't need to, write JavaScript

FTFY.

Re:You don't

[starfishsystems]

Yes, precisely. "Anyone" is professional shorthand for "any qualified person."

See? You learn something every day. Of course definitions vary as to what constitutes a qualified person, and so it may seem that the point I was making is based on an arbitrary measure, but not so.

Consider a normal curve which models expertise across a population of developers. The concavity of a normal curve inverts one standard deviation to either side of the mean. Obviously it's harder to find candidates as you move above mean expertise, but what's significant is that beyond one standard deviation, your efforts begin delivering less than linear gain. And it becomes worse the further you go. If you really must go out three sigmas for someone who is sufficiently qualified to do the work, you're trying to correctly pick one or two resumes out of a thousand.

Can you settle for two sigmas? Then, for that fractional concession, your chances improve better than tenfold of being able to find the person you need with the resources you can afford. The optimal point is not arbitrary, because the function is not linear.

Re:You don't

[omfgnosis]

You shouldn't, and don't need to, write Python.

Re:You don't

[euroq]

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

This is bullshit. You didn't describe a "best programmer" you described a business. One comment saying "this is a hack" for a 2,000 line file which you couldn't understand implies this was written by a bad coder. Or, at the very least (I'm giving you a lot here), it implies it wasn't good code, just working functionality.

Re:You don't

[euroq]

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.

I love what you're saying. I think you should write variables names and function names so long they stretch 120 columns (I'm slightly exaggerating). I love clear documentation. I love well designed software.

Nonetheless, I'm a programmer who has worked in the gamut of coworker programmer skills. Large companies and startups alike. And I know that there is a FUCKING HUGE part to programmer skills. A huge part to coworker's intellectual capability. No amazingly self-documenting code will fix that.

Re:You don't

[euroq]

Bad code can easily meet coding standards. Most code reviews I've been through would nit pick the punctuation between the change request number and the date stamp on the update comment, while completely ignoring the glaring code bug.

Totally hear you there, brah. My first code review took some C code that went from working perfectly to failing in many ways. But the main takeaway was that I should write for loops like "for (int i = 0; i

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

Well, this is what everyone's up in arms about. It matters that it works, yes. But it does matter if it's good or bad, because time is a dimension that continues past the present.

Re:You don't

[euroq]

I'm not trying to troll you, I'm being serious :)

1. The original C++ was written in C with macros dealing with function pointers.
2. Using function pointers is kind of like OOP. :) It really is! They are exactly interfaces (Java interfaces, can't remember their term in C++ I think pure virtual classes).
3.

There isn't any point in arguing with people like that.

But it sounds like an interesting conversation if you're willing to listen with an open mind.

Re:You don't

[euroq]

I think you've gotten a lot of answers to your comment, idontgno, so my response may just end up in /dev/null. But I want to say, after all the discussion on this slashdot forum about coding, your response about the Serenety Prayer is the most apt to so many situations in my personal coding career. I've been through small and large companies, dumb-ass coworkers and co-workers who were smarter than me, and tons of code reviews where people get pissed, and tons of just straight up "coding bullshit". Lots of arguments about what is a "better coder" and the newest fad in coding paradigms. The best wisdom I could say isn't technical, but what you provided:

God, grant me the serenity to accept the things I cannot change,
The courage to change the things I can,
And the wisdom to know the difference.

I feel like I am a more mature person for knowing this.

Re:You don't

[euroq]

You misunderstood. He said the democratic party does not relate to a communist party.

Re:You don't

[euroq]

Regardless of the awful things that happened in the past, these in no way relate to the subject at hand. 18th century "yanks" no longer exist in America. And I think Americans are very aware of Reagan and two bushes. Basically, America is much more than the limited portrayal that you've commented on. P.s. I'm no right winger

Re:You don't

[hawk]

> but I've also seen some hideous code written by
>purists who refuse use them even when they really
>are the right tool for the job. ...
>that doesn't mean they should *never* be used.

yes, yes, yes!

Years ago on my dissertation, I realized that I was writing a *lot* of code to avoid a GOTO. There were alternate sets of pre-processing, depending upon history reaching that point, and it came down to a GOTO or duplicate blocks of code (or a gratuitous function call and its overhead, iirc).

Then again, I think that's the only time I've used GOTO since the early 80s . . .

Re:You don't

[hawk]

five characters of caseless ascii (6 bit) are what fits into 32 bits . . .

hawk

Re:You don't

[hawk]

That the companies approach clearly doesn't work? :)

hawk

Re:You don't

[Immerman]

Yeah, there's not a lot of benefit for GOTOs in most situations, certainly not compared to the headaches they can introduce, but every now and then... Still, I've found that 99% of the places I'm tempted to use one a few minutes thought shows that either a switch statement or "gratuitous" function call is a cleaner solution. After all, unless you're in a tight inner loop or a really inefficient language the overhead of a function call is negligible, typically no worse than executing a few integer additions, and as long as there's no loops in the function you can even inline that away. (I never really understood that restriction. Sure, in 90% of the cases where you are looping inlining is pointless, but why prohibit it while still allowing three-page non-looping functions? I've written *lots* of loops in my life that only execute once or twice except in corner cases)

I still don't understand the rational of folks that refuse to use breaks and such - those can save a lot of code in a lot of situations, making logic far more legible. But oh no, the code path of a function isn't 100% controlled by its block headers. The HORROR.

Then again maybe I'm just an oddball - I also tend to use FOR loops for things that have nothing whatsoever to do with counting - seems to me a whole lot of "while loop with priming read" type scenarios fit perfectly into a for loop. To my mind anything where your loop ends with "...and then get ready for the next iteration" is a prime candidate for neatly grouping all your repetition-related logic all in one place.

Re:You don't

[Lisias]

No matter how big a shark you are. Given enough mobster over you, you will be the one being eaten.

Been there, done that! That bites are still hurting! :-)

Re:You don't

[unitron]

... I can deduce that your parents were never formally introduced."

...which is surprising, seeing as how they were not only brother and sister, but each other's uncle and aunt, respectively.

Re:You don't

[unitron]

It's amazing how many programmers for whom English is not a second language still cannot code it correctly.

Re:You don't

[hawk]

The processor cache was coming into play, too, iirc.

It was a recursive function in heavy Fortran number-bashing, the states were quasi-Markov (for lack of a better term), and could need types of pre-processing before the main body.

I forget the exact sequence, but there were two or three things that may or may not need to be done, and there were a couple of different things that *could* need to be done, after which the remaining processing was the same.

Not having used a GOTO in 25 years, it didn't occur to me until I engaged in contortions. I finally realized that jumping from one of those possibles to the code after the other would cleanly solve the issue.

hawk

Re:You don't

[celtic_hackr]

You ignore the group of people who actually enjoy coding, over the other tasks you mention. I've known excellent and poor coders, coders who've moved up the corporate ladder and coders that were utter failures. Certificate boys and lazy old-timers and lazy young slackers.

As for me, I've been doiing this for over 20 years. I still write a ton of code. I also own the company and am the majority stockholder.

I prefer to do coding over management tasks, but manage to squeeze some of that in too. I set the designs, along with others.

Perhaps you've just been unfortunate in your choices of companies. It's big world, full of many variations. I try not to make generalizations on entire categories of people. I've worked in maybe a dozen fields on multiple continents over more than 4 decades, with thousands and thousands of people. The IT field is no different than any other field, people come in every flavor imaginable, and some you'd never imagine. I've run five successful and profitable companies and done pretty much every task involved. I hold multiple degrees in various technical fields. To tell a little more about my case. You won't hurt my feelings. I'm comfortable with what I am and what I do, and don't need anyone patting me on the back. I make my own way and always have.

Re:You don't

[segfault_0]

The number of people we can use to man a program is finite.

If our companies are anything more than trivial in size, which can't be micro-manged, we will need some of our technical staffs to step up and lead.

If you experienced guys wont step up, you don't just get to double your staff so you can keep them. If they arent leading/architecting, then why are they any better than the young kid out of school who tries hard and did his homework? They arent. They are filling the same role for twice (or 3 times) the price.

This attitude of yours may work for a place with say 20 or less employees, but once you really start growing its untenable.

Re:You don't

[mcmonkey]

If you can't program, you probably shouldn't touch the code of those who can.

Nonsense. Programming ability is not a binary function--either you're a god or illiterate.

Pairing experienced programmers with acolytes is an excellent idea, to the benfit of both parties.

Re:You don't

[DarwinSurvivor]

There's a big difference between pairing them up and telling the newby "Here, go pretty up this senior developer's code."

Re:You don't

[pete6677]

JavaScript is easy to hate because its a piece of garbage. It can't make up its mind whether or not it wants to be a real programming language (will it support data types or not?) . If it weren't the only client side scripting language available, it would be abandoned like Flash.

Re:You don't

[pete6677]

While unmaintainable code is a bad thing, the reality of it is there are no real warranties in the software world. Every product or service has terms that state something along the lines of "we are not liable for anything" and you aren't even entitled to so much as a refund of the purchase price, although many companies will refund money if the customer is super pissed and they want to keep the customer.

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

Re:Ok ok

[mark-t]

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

Re:Ok ok

[wierd_w]

Similarly here, but I inline a fucking bible full of humorous and self-disparaging comments with the code, and criticise it myself, because I already KNOW that the functions are ugly, unelegent, and not in line with best standards and practices.

Then again, I am essentially the only one in my dept that can even *write* these macro functions anyway. :D (scripts to extend functionality of CAD software, using its publicly exposed APIs.)

I was just being a little bit thoughtful for the next slob that has to maintain the damned things.

(I don't need the lecture about how bad my code is; I already *KNOW* how bad it is! Sometimes I wonder how it even compiles at all!)

Re:Ok ok

[Lodragandraoidh]

From my own experience programming since I was 16 (30+ years myself!), as I became more experienced over time I became more and more aware of my shortcomings (the more you learn, the less you know). I've tried to make a point to continue learning and improving - and today in my old(er) age I would be more likely to appreciate constructive criticism than when I was younger (and sure I knew it all).

The guy might surprise the kid - so I would advise him to have a friendly/constructive discussion about it.

(and stop posting about me on /. please!)

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.

[tokul]

Who else can maintain that cluster fsck?

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.

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.

Re:He knows something you don't.

[Mr. Underbridge]

Exactly. If this isn't your style guide, you're doing it wrong.

Re:He knows something you don't.

[tokul]

So how does writing bad code make him irreplaceable? He writes code that nobody understands.

Nobody except him. OP never said that this coder can't read own code.

Re:He knows something you don't.

[Endophage]

It's not naivety, it's common sense. I do my work properly so that when the people I have worked with leave and get jobs elsewhere and their new boss asks if they know anyone good, the say "You need to hire that guy!" That's exactly how I ended up in my current job, and the one before.

Re:He knows something you don't.

[Endophage]

I hope your employer doesn't collapse when you get hit by a bus because you were the only person that understood some critical system and you failed to build it in such a way that somebody else could easily understand it. I'm not even asking for comments, just clean and clear code.

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

[avandesande]

That reminds me of one guy I worked with that relied heavily on his debugger for everything- since he used the debugger for everything he never had to develop decent naming for methods or object models that made sense. Maintaining or modifying his code was a nightmare!

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

Re:You write code for humans...

[Steauengeglase]

Math major?

Re:You write code for humans...

[benjfowler]

Easy ways to approach this with managers:

Use the technical debt idiom, and how accumulated debt needs to be paid back with interest before the burden of poor productivity strangles your team.

Also:

A feature is an asset.
A line of code is a liability.

Re:You write code for humans...

[Fastolfe]

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 depends entirely on where you work. If your organization prioritizes short-term product deadlines over long-term maintainability costs, that's a business decision that programmers aren't really in a great position to influence. Not every business is run that way. If you're really a good programmer, and value these types of things, you might consider seeking these places out.

I work at a major software company. We are engineering-focused and engineering-driven. We have a fairly rigid style guide and our source code repository enforces code reviews by people that have proven themselves capable of writing readable, maintainable code. Alarm bells go off when you add code that isn't unit tested, and reviewers can and do ask that you step up and write tests before submitting. All of this conspires to make you a better coder. After a few painful projects, you're pumping out readable AND testable code just as quickly as you were before you joined.

While the OP discusses what appears to be a social problem, there are technical solutions that get most of the way toward solving this problem.

Re:You write code for humans...

[rev0lt]

Try getting a Director/VP/C-suite to understand why unmaintainable, shitty code sucks and hurts the business. Believe me, I've tried.

Me too. It works. Explain the cost of a business-made decision regarding deadlines in terms of maintenance down the line. How (in some cases) they'll need to re-implement it from scratch because its not a good foundation for a product (not flexible enough, not scalable, not maintainable, etc). If it is an online product, describe how defects caused by poor architectural design can lead to downtime/bad user experience/voiding of marketing efforts. Describe the problems specifically (pick 3 or 4 major blockers/issues your team agree with) and describe them to the management. Do not be condescending, and be prepared to give deadlines - like "we need 2 more weeks to iron out the kinks". Do not use expressions like "this is all pure shit and needs to be reimplemented from the ground up". Ask how much does it cost to lose a customer, how does it cost every hour of downtime because of easily fixed architectural problems. Explain that a flexible design usually shrinks the time to add production-level features. If the guy before you is a moron, explain to him how he is going to be crucified when the product crashes and burn, and remind him you'll send him an email with CC to his boss (if it exists) stating just that.

I've been on the management side for several years (but not currently), and what I can tell you is that most good programmers should learn that there is code that is "good enough". Proposing rewritings of critical/big chunks of an application is generally a bad idea, but sometimes is necessary. If you don't take in to account business requirements (like "what we have is good enough, we dont mind to hire extra programmers to maintain the mess), management will never take you seriously.

Re:You write code for humans...

[Gorobei]

If you ever get bored at Google, I've love to hire you. New York weather isn't as nice, though.

Re:You write code for humans...

[gstoddart]

Masters degree, practically the same thing. ;-)

Re:You write code for humans...

[Kjella]

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.

Technical debt is like real debt, easy to acquire and a bitch to pay off. Which is why most managers don't do that, they just pay interest (extra development time and bugs) and take up more debt. Yes, eventually it might grind to a halt but that might take years and your manager isn't planning to stay around that long, at the very least he's looking for a promotion so it'll be his underling's failure to meet the deadlines. Or they've just been so convinced by marketing that the window is right now and they must just ship and get the product out there and hit it big before a competitor steals all the buzz and customers. I think they at some level understand but they aren't measured by it, whether you ship on time or not is clear. The state of the code base is just a fuzzy feeling. A manager can't use that to justify missing the deadline, it just sounds like a pathetic excuse for failure.

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

[Bob the Super Hamste]

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.

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

[Darinbob]

I had a boss who was absolutely terrible at C. But he readily admitted it. He was a long term IBM mainframe programmer who spent most of the time in assembler (the type with lots and lots of macro capabilities so that it's as easy as a higher level languages). He told me he had learned C from a "Learning C in 21 Days" book.

He was also a cut-and-paste programmer. Meaning he would cut a useful loop from one part of the code and past it somewhere else. Which in some cases is fine. However he never re-indented that pasted code! Indentation levels were absolutely arbitrary. He rarely put in some functions to reduce the cut-and-paste. He thought I was just wasting my time by rewriting some stuff (but later relented when he realized I could fix bugs that came in much faster).

He actually had code like this (but even worse, this is just a sample):
      while (strncmp(&str1[i], &str2[j], 1) == 0) ...
I suspect he assumed that this was like an assembler macro instead of a function call...

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

Re:Not easy

[thesandtiger]

Not quite.

Unprofessional people who have entirely too much ego investment in their work will find it difficult to take constructive criticism and feedback.

Professionals who are actually committed to being the best they can be (rather than trying to pretend they're the best) will welcome constructive criticism because it may actually help them get better. Nobody is perfect, nobody knows everything, so there's always something to learn.

I don't mean to say that people should just blindly accept any criticism unthinkingly, but rather that they should be capable of listening and integrating any improvements into their process.

My question to the OP:
You don't get very specific in the summary and I can't quite tell if the guy actually shuts you down or if you're just backing down because you are intimidated.

If you're getting shut down, my suggestion would be to look at getting other team members involved (or management if necessary) and present it as the code being written works but it is not maintainable and it is written in a style that doesn't conform to standards and thus forces everyone else to waste productive time just sussing out what it does. If your team and management are unwilling to get involved, then you can figure out if you want to work there enough to deal with this particular issue and go from there.

If it's just that you're intimidated, then I would say get over it and approach them in a professional manner - there have been numerous good suggestion about diplomatic ways to handle this in the responses so far.

Re:Not easy

[Fastolfe]

I have gone so far as to fix unreadable code so as to make it clearer what was happening, add documentation, etc., and send the code review to the original author. This communicates the problem to the author while simultaneously solving it, and often times, communication is enough for the original author to prioritize readability in the future. I know if someone sent me some code reviews to fix crap I'd written, I'd probably scan through the rest of what they're working on and try to fix it up preemptively.

Re:Not easy

[n7ytd]

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.

The danger of inviting his comments on your code is that he may take it upon himself to teach you the One True Way to code like him. Expect lots of unhelpful advice and a grudge to develop as you do not adopt his ideas.

The correct answer has already been stated above: implement good coding standards and reviews. Getting these done in a way that developers accept without hurt feelings is a fine art. Use the situation as a way to improve the competency of the team, not as a way to single out one poor developer. After getting a working standard in place, then you have a yardstick to measure code quality beyond your own opinion.

If the coworker's coding practices are affecting your work, but is in line with the company's coding standards, either the standards need improving or the problem is you. If you have some sort of OCD that causes you pain to look at his code, then my advice is to stop looking at his code.

Re:Not easy

[rev0lt]

It's not easy to allocate memory for new objects and the more you do it the more memory fragmentation becomes an issue.

Its dead easy to allocate memory for new objects in nearly every OOP language I worked with. You're mistaking operating system calls with memory allocation calls - most languages implement their own heap management routines, not only because usually the OS will only give you 4Kb (or 4Mb) blocks, but also because it is way easier to use your own memory heap manager tuned to the specific requirements of your language.

Please don't do that, instead put everything in a single static method, which will only be called once and suffer no performance penalties.

Or just ditch OOP altogether. If you can solve a given problem easily using only/mostly static methods, you probably have no gain in using OO constructs.

Re:Not easy

[Bob the Super Hamste]

Yes I am proud of the effort and creativity used to fix the problem but it is some really ugly shitty code that I wouldn't want anyone to see, and hopefully they won't.

Re:Not easy

[euroq]

while (strncmp(&str1[i], &str2[j], 1) == 0) ...
I suspect he assumed that this was like an assembler macro instead of a function call...

That seems like perfectly cromulent code to me.

its a lost cause

[alen]

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

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

Re:its a lost cause

[Panaflex]

In SQL there are often no choices in the matter if you want decent working code. I avoid temp tables like the plague they are, but sometimes the evil is necessary.

Re:its a lost cause

[ggpauly]

The basic problem here is the concept of "SQL Devs".

SQL code must be co-developed with the code layer that interacts with it. Projects must not be divided at the SQL / other language layer surface. If multiple coders are needed, other ways to segment the project must be created. No-one should code only SQL.

The reason for this is that there is a close interaction between the calling code and the database data. The exact nature of this interaction depends on the problem at hand, the capabilities of the language(s) used to interact with SQL/data, and the preferences, idiosyncrasies, and skills of the coder. Security also depends on an integrated understanding while designing software.

I don't understand your abhorrence of temp tables (" ... the most evil invention ever ... "). They make some things possible and other things easier or clearer. Some coders prefer to use them more often than others.

If you're a manager my heart aches for the suffering of your employees.

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.

Re:its a lost cause

[Anonymous Coward]

Whereas, I know C# developers who write the most unmaintainable dynamic, nested, and unnecessarily recursive subqueries, never once using temp tables or table variables, who never understand why the SQL DBAs despise them when they come for help to "just do the performance tuning" and then baffle even further when said DBAs balk at supporting Entity Framework, because the C# Devs think it will provide better performance and scalability [facepalm.jpg].

Re:its a lost cause

[Jonner]

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

If you think temporary tables are the most evil invention ever, you may need to learn some more SQL yourself.

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

[AwesomeMcgee]

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

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.

Which site is this?

[Anonymous Coward]

When did /. become Dr. Phil for nerds?

Re:Which site is this?

[BitZtream]

Seconds after CmdrTaco left :(

Re:Which site is this?

[idontgno]

I dunno.... when did "Ask Slashdot" start?

Re:Which site is this?

[CanHasDIY]

When did /. become Dr. Phil for nerds?

Hey, it beats the "Teach me how to hack my ex's Facebook" type questions...

But who is it?

[Anonymous Coward]

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

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

[benjfowler]

Code reviews are also a great way to spread knowledge throughout the team; to get people more familiar with different corners of the codebase, and to get people thinking harder about their code. I see code reviews not just as a(n imperfect QA tool), but as a learning 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.

Fire him

[viperidaenz]

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

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.

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.

Re:Automate!

[Megane]

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.

Re:Automate!

[gknoy]

Shoot, I accidentally modded you overrated. Sorry about that, posting to undo the mistake.

Re:Automate!

[gmack]

Good luck with that. A few years back I turned on a bunch of warnings and added annotations to make GCC warn on misuse of format strings only to have the second programmer on the project turn them all off again on the portions of the code he was maintaining because he thought they generated too much noise. The resulting failure when the new servers were 64 bit rather than the 32 bit machine he was developing on was the only thing that convinced him to clean up any of it.

Re:Automate!

[benjfowler]

Impossible on massive corporate codebases, with low standards to begin with.

Implementing something like this would be asking your developers to clean the Augean Stables.

Re:Automate!

[Sulphur]

Impossible on massive corporate codebases, with low standards to begin with.

Implementing something like this would be asking your developers to clean the Augean Stables.

Divert a river through it; anything less will be overwhelmed by the problem.

The proper functioning of a chain of command is a thread running through a lot of this :

The boss needs to be personally aware of the problems, and not be informed by the chain. (thereby avoiding intrigues)

He needs to issue orders by the chain, and not break the chain. (leaving structure and order in place)

Re:Automate!

[Anonymous Coward]

I would love having my code reviewed.

Switch the office coffee pot to decaf.

[Andy Prough]

He'll sleep all day and stop coding. Problem solved. http://dilbert.com/strips/comic/2003-06-19/?CmtOrder=Rating&CmtDir=DESC

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.

Force him to maintain his own code.

[oneiros27]

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.

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

Re:Provide and solicit feedback.

[suutar]

Amen. Here, have some coffee cake.

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

[MozeeToby]

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

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.

Re:Make it about YOU, not him

[jdavidb]

You just caused me to suddenly realize what somebody was trying to tell me about a school project twelve years ago!

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

[Darinbob]

Often those fail. The team gets tired of being criticized and so they end up doing them less and less. Or the code reviews always tend to end up being about nitpicking about irrelevant stuff. After you skip a few of them because of tight deadlines it becomes easier to skip the next ones, and the cycle slowly stops turning.

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.

Change company!

[Anonymous Coward]

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

Just say it....

[Mike]

Dude, your code sucks!

Re:Just say it....

[91degrees]

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.

[Anonymous Coward]

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

How to show him...

[Anonymous Coward]

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

[JeanCroix]

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

Key question: "Why?"

[BenSchuarmer]

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

[Urban Nightmare]

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.

Re:Bad coder

[Anonymous Coward]

as his boss you need to explain to him that the code has to be readable by others.

You imagined the part about being his boss. He describes himself as a coworker. That's not the same thing (as any cow could tell you).

Pair Programming

[Anonymous Coward]

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

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!

Re:My suggestion.

[Tooke]

Or even better: "Your code sucks." It could be shortened down even more to "You suck," but then the meaning starts to change a bit.

The best approach is persuasion: high school style

[dingen]

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:Instead of asking us?

[Anonymous Coward]

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

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?

Re:Does the guy really qualify as seasoned?

[shutdown -p now]

If he's working in a non-optimal language that doesn't support GOTO, he should try hacking in the functionality with preprocessor defines.

In Java, you can make do with gratuitous use of throw/catch. In anything functional, you can spin flow control with higher-order functions much more creatively than you could with gotos, anyway.

The real trick to job security, though, is writing in Common Lisp. Just don't forget to use reader macros a lot.

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.

Re:Old code

[holophrastic]

Yes, different is bad. But it can be solved in either of two directions. You don't need to change the code. You can change the developers.

So you define what good code is -- in my world, that's code that you can read two years later within 10 minutes -- and then you make everyone use that style.

It's not about the syntax, or the conventions. It's about the end-result.

Re:Old code

[Anonymous Coward]

Great! Drag everyone down to the lowest common denominator.

I'll bet it didn't even occur to you that just maybe the "different" way the senior programmer is doing things really is better? That just maybe the rest of the team should be learning from his experience?

Re:Old code

[dudeman2]

Doesn't matter if he can understand his two-year-old code if no one else can. If he quits or gets hit by a bus, what then? I agree with above posters that this is something for his superiors to handle, not you. If it's affecting your work, point it out to them, and if they can't see the problem, perhaps it's time to look for a new job.

Re:Old code

[holophrastic]

if no one else can, the solution might be to teach the others. don't make someone stop writing code that works just because others aren't good enough to read it. either hire better readers or teach them. otherwise you're angling to have the most easily-read code, as opposed to the most something-else code. and since the client doesn't pay based on code legibility (that's not true for all projects, but for most), you should be optimizing your code for its functionality, or its flexibility, or its size or something that matters to the client.

Re:Old code

[Anonymous Coward]

Watch out with that strategy, he might have a long memory.
I can easily understand and explain code I wrote several years ago and not touches since, of which I know it is horribly written, since I had no training or experience whatsoever when I wrote it.

Re:Old code

[holophrastic]

I used to say the same thing, but since I program something different every day, I can't remember 300 projects any better than I can confuse them.

But either way, you're not asking him to use it. You're asking him to walk you through it. If one line of code yields twenty-seven sentences of explanation, or if ten lines of code yields three words of explanation, then it'll be obvious to everyone.

Remember, it's not about right or wrong. It's about whether or not everyone's happy with the explanation. If they are, then they only need to learn to read it. If they aren't, then it really doesn't matter anymore.

Never teach a pig to sing...

[swm]

it wastes your time and annoys the pig.

Wait for him to retire

[damn_registrars]

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.

Get him to explain it to you

[Blasphemy]

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

[Blasphemy]

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.

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.

Make him taste his own medicine

[gmuslera]

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

[Sonyc148]

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

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

Make Him Maintain It?

[TheNinjaroach]

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

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.

Re:Look at Linus

[johnsnails]

hahah, did a search of the thread to see if someone else mentioned this... you beat me to it...

I better add something useful

http://developers.slashdot.org/story/12/12/29/018234/linus-chews-up-kernel-maintainer-for-introducing-userspace-bug

Re:The best approach is persuasion: high school st

[Nyder]

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.

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?

One way

[ryanrk]

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?

[HornWumpus]

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

[jollyreaper]

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

Re:Easy steps

[Thud457]

Nah. It must be you he's talking about. Because it certainly couldn't be me.

Submit the best examples to TheDailyWTF

[Megahard]

And send him the link.

Re:Submit the best examples to TheDailyWTF

[omnichad]

And since they anonymize the code, he won't know its his own at first. And he'll see hundreds of comments of why it's wrong and maybe even agree with them before he figures it out.

At the very least, he'll get the point that you don't respect such code, and it's much less personal than attacking his own code directly.

manager's issue

[subnomine]

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.

Easy....

[fatmal]

make him document it!

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

Honesty

[TimMD909]

Have you tried telling him that his code is as painful to go through as running naked backwards through a corn field? Honesty is always the best policy.

Re:Honesty

[larry bagina]

Next up on ask slashdot: How can I explain to a coworker that running naked backwards through a corn field is painful?

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:How long...

[John Bresnahan]

This!

I had the exact same experience early in my career. The senior programmer just smiled and let me work it out for myself.

Re:How long...

[presidenteloco]

That!

Get to the point

[fingeo]

"Your code makes my eyes bleed."

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.

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.

I imagine APK looks like Giorgio Tsoukalos...

[Anonymous Coward]

BZZZT! Answer was not in the form of a HOSTS file update.

Write a post

[jameshofo]

And send it to Slashdot for him to read, then again, your the one that's having problems reading his code so maybe your stuck in a mode of trying to get everything perfect! *har*

This is what you do

[TheSkepticalOptimist]

Take code he wrote 6 months ago and ask him to explain what it does. If he can't do so in under 10 minutes it should be obvious his code is poorly written and not maintainable. Or, just list all the bugs associated with his code base he has had to fix over the last 6 months.

It seems its a recurring theme that every software firm has a smart ass that assumes he knows everything but writes code that even a junior code monkey fresh out of diapers wouldn't write.

Let me guess, this same guy is advocating coding style that matches his style rather then adopting more widely utilized coding standards.

Re:Why is this on slashdot?

[TheSkepticalOptimist]

This is what Slashdot is. if you don't like it, go elsewhere. I'm tired of people going on about why something is on Slashdot, obviously the 100's of comments suggest this is the kind of content people want to read and write about on Slashdot.

Also don't be that guy that defends a bad developer by using your own poor coding habits as an example.

I think this guy has my former job

[ZeroSerenity]

Yeah. My boss was that bad.

Sounds like a management problem...

[Vesuvias]

That type of coding is a result of management encouraging speed and something that "just works" over maintainability. It could be argued that he "could" be faster and have less bugs if coded more conventionally but not without extra education on his part (violating the speed objective).

The only argument you can likely make (unless his code just doesn't work) is the maintainability one. If management doesn't go for it then they actively don't care about maintainability as much and as offensive as that might be to you as an engineer it is their choice to go down that route.

Overtime your style will win out if it truly is the superior choice for their needs. The parts that you coded versus his should be easier to refactor, debug and have less general issues overall. If this is not the case then your assumption that your style of code is better than his may be wrong (at least in terms of the company's needs).

Simple

[PPH]

10 PRINT "Your code sucks."
20 GOTO 10

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.

Re:Easy solution that works - psychological judo

[phantomfive]

That is an excellent idea, thanks.

Re:Start with the basics

[Lumpy]

Or better yet use reverse indentation.

You paying him?

[mbrod]

Unless you are the one paying this guy it ain't your problem dude.

Re:You paying him?

[breakpoint8088]

Oh, no-- you have it completely backwards! His _manager_, after all, isn't likely to have to _maintain_ that code-- his co-workers are. Likewise, they have to deal with the security problems that invariably fall out of code nobody else can understand due to a lack of proper documentation and descriptive coding practices. So it most definitely is _his problem_. However, if we put the two of you together, you can start to see the correct solution, which is that he should be telling his manager to _fire the guy_.

Wilmer?

[MSBob]

I think slashdot has a post about you.

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.

Is his name Don?

[wizkid]

If not, then he must be his brother....

Maybe there is a reason behind his coding style?

[vovick]

If your coworker is actually really smart and experienced, maybe he has a good reason to do things his way and you're just not seeing it? Maybe he could explain that reason behind his naming convention and avoiding certain features and it would make more sense? I had a couple of interesting talks on similar topics with older programmers in our team (I'm a newbie) where they actually convinced me on most points why their style and policy to avoid certiain "fancy" language features and practices was more error-prone and readable after a while of working on the project.

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.

Brain wiring, code design, and elven mages

[eagee]

It depends upon the person of course, however if he's not able to learn from the feedback you're giving him it's possible that his brain might not be wired that way. In my experience (as a lead developer and lead architect) I've found developers usually sit somewhere on the spectrum between implementationists (nuts and bolts programmers) and designers (big picture programmers); and every now and then you get someone who is just so far to one end or the other it's hard for them to see, for instance, why code needs to be elegant when it's already working (or vice versa why sometimes the performance cost of a perfect design doesn't pan out).

If you think this might be the case, it doesn't mean he needs to be fired or kicked off the team though. You just have to focus on using his abilities where he's strongest (e.g. low level code, or when you need to *get the job done now, future consequences be damned*). There will be times when something that seems obvious just isn't going to make sense to someone else, and in those instances I find it's best to think of the each team member the way I might when playing an rpg; while a dwarven warrior won't have the finesse of an elven mage, sometimes it's just the kind of character you need. :-)

Re:Maybe there is a reason behind his coding style

[vovick]

s/more error-prone/less error-prone

Standards

[Sedated2000]

The only way to handle sensitive issues like this is to have standards in place to begin with. Configuration Management including coding standards and honest peer reviews. If the developer didn't follow standards, he fails his peer review. It doesn't even have to be personal. Not "Your code is horrible, fix it.", it's "We need code written this way to comply, please fix". It gives you a leg to stand on rather than dramatic phrases like "Your code is like a war crime".

A serious proposal

[dkleinsc]

Instead of criticizing the code he writes, do a training exercise where a group goes through bad code that someone not (currently) working at the company wrote, and have people who write good code point out the flaws. The idea is that this way, you've taken his ego out of the equation, but still showing him the difference between good and bad code.

The passive-agressive method

[jessehager]

Patch or hack the compiler to detect his coding style and generate plausible sounding error messages.

Easy

[kurt555gs]

You suck at coding bro. Every consider a job in the fast food or hospitality industries?

Go Philosophical, nothing else will work

[Rob the Bold]

There's really nothing you can do about this that has a good chance of a positive outcome, since no one likes criticism and managers don't really like to find out about yet one more problem they've got to deal with. Because in this case you're criticizing their management practices for allowing this to go on.

I've seen some suggestions here of books to read or to give to coworker to read. I, too, will make a reading suggestion, but a very short one:

"To a Louse"

After this, you can wonder just what annoying trait you might have that annoys your coworker, and take some comfort in that. Or something.

Talk slower...

[colnago]

And louder.

Too many new tricks for an old dog

[DCheesi]

If he's been around that long, chances are that he started his career writing assembly or something nearly as low-level. That's why he writes everything in one big function --even procedural programming is a "new" paradigm that he's only half-comfortable with. Expecting him to fully utilize OOP language features and best practices is just unrealistic.

It's kind of like natural languages; even after years of speaking a new language, some folks never achieve true fluency because they can never get away from thinking in their native tongue. This guy is like that; he'll probably never be able to do more than write assembly-style programs in a procedural or OO language wrapper.

The best thing to do with old dogs like this is to give them their own little niche where they write their ancient code in peace, without bothering anyone else (or being bothered). Maybe something low-level (as in close to the computing hardware), or an older product line or obscure technology area where his ancient knowledge might be of some use. And preferably something self-contained where no one else will have to interact directly with his source code on a regular basis.

Re:Too many new tricks for an old dog

[DutchUncle]

I was a teaching assistant for IBM 360 assembler in 1978. We had been taught, and I taught others, better practices than that. In fact, one of the professors had a complete block-structured language implemented in assembler macros.

Simple tools don't force poor design or ugly work. The finest sculptures were done with hammer and chisel.

Easy

[Charliemopps]

Give me his email address.

Maybe you missed the point

[pubwvj]

He is creating job security for himself since only he can maintain his code... You, who write perfect code, can be replaced.

How old is your co-worker?

[JTsyo]

Might be too late to teach the old dog new tricks.

Re:How old is your co-worker?

[DutchUncle]

Where I am, I *am* the old dog. The difference is, I learned software design, while most of my colleagues are hardware guys who have to slap some code together to get the hardware to work. I teach them. And I introduced Subversion and configuration management and better tools (some open-source). Some people get it, others don't. Age isn't the determinant.

Only three kinds of code:

[Simonetta]

There's only three kinds of code:

    Code that works:
    Code that's documented:
    Code that was written quickly and cost-effectively:

    Chose two:
 
    Pay for one:

    If the three items above are not part of the problem, then maybe the issue isn't the code. Maybe it's the user interface that is associated with the code.
      I cringe whenever I click an item and a screen comes up that requires me to move the move pointer to a completely different part of the screen and click again in order to continue. Insane!
    Ever notice that a so-called professional user-interface developer will know everything about the code and the computer part of the interface but know absolutely nothing about anatomy or the human body aspect of the user-interface? Are retards still writing mouse code that doesn't allow the mouse wheel to scroll the mouse cursor to all the clickable options in the message text box?

I See Bad Programmers Everywhere

[makoto149]

And they don't know they're bad programmers. It is a story as old as time itself. I can imagine two flint knappers sitting around talking:

Thag: "Grog, I have to tell you something about Dag."

Grog: "What is it?"

Thag: "He is a terrible flint knapper. The absolute worst. His flints are all crooked, half the time they're broken, he's just awful!"

Grog: "Have you told him this?"

Thag: "Of course, but he is impervious to criticism!"

Grog: "It is part of the human condition. By the way, you're not so great at this yourself. Just saying."

Thag: "You mean the ones who are the most vocal about others' lousy work are often guilty themselves?"

Grog: "Yep. 'He who smelt it dealt it'."

Thag: "Screw you. I'm going to talk to a zillion people about this who have never actually seen my work. I'll bet they are more sympathetic."

Of course, you could always wait until he retires.

constantly correct his code

[Dishwasha]

I know it's kind of a waste of time, but most programmers recognize portions of code they have worked on and will notice when the code has changed. If you consistently refactor his code in to something significantly more readable with fewer lines, it is likely he will notice the change and see your patterns and follow suit. If he doesn't follow suit, he will probably complain to management and then you can properly defend yourself when he's the one instigating the conversation.

The Daily WTF

[PRMan]

I had a semi-junior developer from India that was overall a good coder but did some really bad things at times. As his team lead, I tried the direct approach but he just argued to my face that he was right and had been doing it that way all along and that it was no big deal.

Instead of continuing to argue with him, I just showed him The Daily WTF and laughed with him about how stupid some of these coders were. I told him that I read it every day to laugh at bad coders, as a form of therapy. After about a year, his coding had improved dramatically.

When In Doubt.

[LifesABeach]

Lead by Example.

Dude, your code sucks!

[Quince alPillan]

Just tell him straight out that his code is impossible to read. Follow it by explaining why its hard to understand and ask him to make it human readable and understandable. Give examples, preferably from an authoritative source such as a textbook, of ways that he can change his code.

If he can't (I don't know how to write it any other way!) or won't (I can read it just fine!) then fire him, with justification that his code is impossible to maintain and he's causing the company to lose money in the time it takes to maintain his code.

Either way, your company is going to be in the lurch when the guy leaves and the only documentation left is his shitty legacy code. Better to cut him loose now and replace his bad code with good code.

Bad code... Or whiney coworker?

[sdsucks]

I always wonder when these types of questions come along... Who is really the bad coder? The "Coworker", or the person that thinks the coworker is a bad coder? Face it, most "bad coders" think they are good... and there are actually few "good coders" in most groups.

More importantly: most programmers actually want to write good code, but at the end of the day it's really about cost effectiveness. In some cases this might mean you whip up the crappiest POS code you can to get the job done, and in other cases it's all about quality and maintainability. I wish more programmers understood this.

Regardless, if you are not management - either STFU or bring it up with someone who is a manager.

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

Re:if (coder.suck) { return false; }

[jgrahn]

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.

Huh? Quite literally: what's not to like? I can't think of one more reasonable thing to ask for except maybe performance. I assume "simple" includes "simple to interface with", i.e. clean, documented interfaces.

Re:if (coder.suck) { return false; }

[uslurper]

OH CRAP! He's talking about me!

Re:if (coder.suck) { return false; }

[mooingyak]

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.

Huh? Quite literally: what's not to like?
I can't think of one more reasonable thing to ask for except maybe performance. I assume "simple" includes "simple to interface with", i.e. clean, documented interfaces.

It can often be as simple as brace placement, indentation style, variable naming conventions. Also, languages often have more than one completely valid way of doing something, but the one you prefer may not be the one someone else prefers.

Obviously these things are trivial compared to gaping logical errors, copy & paste code, and a lack of modularity. But it can still be jarring to deal with code that's done in a different style than you like.

A possible solution --- no comments :-)

[troll]

At one shop we had code walk-throughs. They specifically not termed "code-walkons,"
Several programmers --- no managers --- would schedule a conference to review and comment on code.
These walk-throughs were a good idea --- the coder wasn't attacked by one person; others were (probably) more tactful than yours truly.
I learned a lot of respect for my co-workers, not to mention new ways of doing things.

Re:A possible solution --- no comments :-)

[troll]

Further information: the (invited, as I remember) attendees were given the code for review a few days before the walk-through.

Glass houses, stone throwing, etc.

[pclminion]

Chances are your code sucks just as bad.

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.

It will take a long time

[ewrong]

But... It can be done.

Start with a general discussion about how you might standardise code so that it's easier to switch between areas as a team. Little things like naming conventions and code formatting. If you can't get buy in to that then abandon ship.

Otherwise, introduce tools to start enforcing those rules. Hey let him decide what most of them are.

After this hopefully you have broken the barrier of being able to speak about each others code and you've planted a seed in his head that a bit of formalisation isn't a bad thing.

Rince & repeat upping it a notch each time.

It depends...

[Dcnjoe60]

How can I explain to a coworker that he writes bad code?

It depends. Are you his/her supervisor? Did the coworker ask for your opinion or advice? If you cannot answer "Yes" to at least one of those questions, then you really should examine your own motivation as to why you feel you must explain to the coworker anything at all. Now, on the other hand, if the coworker's coding is impacting your work, then your recourse is to discuss it with your supervisor. Taking the matter into your own hands, particularly without approval from your supervisor will most likely get you branded as a trouble maker and have negative repercussions for you, while doing nothing to improve the coworker's code.

Programmers with poor programming skills usually get additional training. Programmers labelled as having a poor attitude usually get replaced.

Treat him like a bad puppy

[Kyn]

Gently bop his snout with a rolled up newspaper and then rub his face in it.

Bad programmer! Bad! No coffee for you!

was Re:You don't, but actually...

[breakpoint8088]

Man, you sure don't see this kind of attitude in a small company. You can only get away with it in an environment large enough for people to hide. Like aerospace! Or academia. I can assure you that this is exactly the kind of thing managers dread: employees intimidating each other out of peer review. As a rule, MANAGERS DON'T REVIEW CODE. Mangers review PROGRESS. If progress sucks, they will try and figure out what's wrong. But if they're not reviewing code, and the employees are tight-lipped about each other, than one or more of the following happens:

0) The company ignores the problem, then goes broke because unmaintainable code means permanent fire-fighting. This is what usually happens.

1) Resources get added. If this isn't actually needed, but is being used to "code around" problem people, this is going to cause serious initial slowdown while they get trained. Which your good programmers don't have time for. So guess who gets stuck training the new guy. And guess what that means.

2) Code reviews! Oh, the humanity. Watch tempers flare as the shit finally flies through the air, after years of stifling deeply-held opinions instead of discussing them with your peers! Someone will either quit or get fired, so code quality will improve. Morale, however, will go straight in the toilet.

3) Coding standards. This is your best bet, in my opinion. You go into a room _without_ anybody's code, and all gradually develop some standards and best practices. This should take about a week and it is damn well worth it. It takes all the ego out, because everyone reaches the standards by collaboration. It also means that when people "complain" about code, they have specific things to cite, and specific reasons the complain about them. This is the best way to avoid peer-to-peer fights, because everything dilutes in the team. And if you have one person who is constantly fighting the _entire team_? Well, you had better re-evaluate whether you want that person _on_ your team. This solution should result in a _short_ written document, and should not be an excuse for out-and-out nitpicking. (HINT: Use a stopwatch to see how much time people try to spend arguing about brace and bracket placement, and kill the issue quickly with a vote.)

4) Peer-programming gets added. This is popular lately, and man, this is one place managers really better earn their pay. Careful balancing of the mix of peer programming and solo time, and careful pair selection, is required to slowly teach better habits. I recommend doing this AFTER the coding standards document, so that it "guidance" doesn't seem arbitrary or egotistical.

Tale from the past

[seyfarth]

I had a good friend who did a lot of useful programming. He was full of creative ideas which made up for his lack of programming style. I recall one piece of Fortran code which used the "3 pronged if" which bracnched to 1 of 3 lines based on an integer being negative, 0 or positive like:
      if (n) 1,2,3
  1 i = i -5
      goto 10
  2 do something for 0
      goto to 20
  3 do something else

Anyway he had a section of about 15 lines with 10 labels and about 8 to 10 of these if's. Most of them had 3 different labels for the places to branch to. He said that he hated to waste a branch on an if.

He took a Pascal class and the teacher told him all the code for a program could be on one line since the input was free-format. So he wrote 1 line Pascal programs.

Needless to say he was proud of his code. In this case I think his value was obvious and the best strategy was to leave him to his ways. I tried to show him a few style issues like indenting code and using the better forms of if. Unfortunately there was no while loop in Fortran at that time, so some goto's were definitely required to implement loops which didn't use simple counting for control. Today's languages generally offer nice structures, but if my friend were still alive he would probably still be using Fortran 77 and 3 pronged ifs.

Introduce him to Slashdot?

[ClickOnThis]

Maybe he'll see this article and get the hint.

I think everyone's missed the point.

[quietwalker]

Too many people seem to be focusing on this as a technical or engineering problem that can be fixed by education, rationalization, discipline, design, or process. The info I see above seems pretty well thought out and rational, each person focusing on one facet of the symtom, and trying to leverage a fix.

I'm not surprised - that's what I come to slashdot for.

However, this is fundamentally a communications issue with potential business ramifications.

You want it changed for the better, you need to put a price on it, and show it to management. It's that simple. I'm assuming it's in man hours spent on bugs, and lost sales due to poor quality code engendering bugs, bring-up time for new employees, migration/maintenance costs for tools, etc. Not speculation either, actual literal costs. The next best thing is to find a manager who understands the actual costs, who agrees with you, who can then put a price on it and show it to management.

The outcome may be firing, it may be company mandated coding styles, it may be enforced design process, it may even be the adoption of a new development framework or third party release management system. However, if you can't put a dollar value on it, there's no business reason in the end.

As a side note: I just left a company which had this type of problem, and were at the point where 80-90% of the dev staff were involved in bug fixing only. Management's opinion was still that refactors or other mechanisms to reduce bugs and produce well thought out designs were still more expensive than delays in releases due to lack of manpower for new features. So even when it seems apparent from a technical problem standpoint, the finances favored the mess.

He's obviously getting paid per lines of code

[Culture20]

Let him have his monolithic lasagna code.

My personal method.

[Kaenneth]

Whenever I write a piece of code that pleases me by my cleverness in crafting it, I rewrite it dumbed down.

Boring code is maintainable code.

re: Ask Slashdot: How Can I Explain To a Coworker

[GrimShady]

tell him Microsoft is hiring right now...

Fire him!

[slashmydots]

I am SO SICK of older IT workers who fail to properly keep up with whatever they do and then this is the result. The IT manager at my old company (a hospital btw) couldn't actually name most of the parts in a modern desktop. He was in his 50's. Programmers are even worse. They're too lazy to learn new languages so they just don't and sort of cruise by with a half-assed attempt at making something sort of work. The best part is, they get paid the most! I now own my own computer repair business and if someone walks in and I know nothing about Windows 8, they walk right back out. You keep up or you go work in a different field. That's IT, deal with it. I'd push very hard for him to get fired.

seriously

[lkcl]

point him at this article.

Tell him...

[TsuruchiBrian]

1. You write the most horrible code imaginable. 2. You stuff entire programs into single functions. 3. You artificially stretch function through relentless repetition 4. You make uninformative variable and class names. 5. You ignore basic language features, when they could make everything shorter and more readable 6. You don't use OOP correctly. You need to be smart to write good code. Being smart does not guarantee that you write good code. Writing code since before (insert person) was born does not make someone good at writing code. Some people just can't learn new things, especially some of these old self taught programmers who were considered hackers and geniuses back in the days when computers were simpler and dealing with a few hacks here and there was ok and easily fixed through more hacks here and there. When you graduate from a bicycle to a 747, duck tape is no longer allowed (and probably didn't even belong on the bicycle either).

Everyone thinks that they have a sense of humour

[Stonefish]

Everyone thinks that they have a sense of humour & Everyone thinks that they write good code.
I've worked with enough tossers who believed that a particular style was the best way and that whatever style was being used was crap that I just want to vomit. Go and fix the MS word templates because they offend you sense of style, stay out of my way. I used to get involved in these debates and found that it was better to simply marginalise the idiot until he went away. Now I run a company which makes money and internally you don't get 'pretty'.
The job of coders is to ship code. If he's shipping more code and meeting more deadlines than you he's a better coder.

Really this point of view is bigger than this, it relates to directory structures, word templates, diagrams basically if you care about these things you're a time waster and are worth keeping on because you constantly get distracted by fluff and don't make money.

Read the Tao of Programming

[hugetoon]

Once You attain enlightenment You'll know what to do.

Unit Testing

[Luveno]

Make sure programmers having documented unit tests is a standard at your work. Then watch him write tests for his uber-methods. Either he'll "get it" or he'll think testing is stupid. Having a programmer proclaim "testing is stupid" usually doesn't go over well with the rest of the department.

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.

Re:That's true

[celtic_hackr]

Speak for youself. Being even older than you, and being an experienced programmer, I can say for certain that I'm not willing to say that kids can do things I cannot. They merely have had a different learnig experience and may have learned things I didn't, because they were hacking things that I don't have the time to hack.

Nor would I "read" a book given me by some wiz kid fresh out of school. I would probably look at the book as I do all books, and make a judgemnet call on whether it was worth a read, or to be given to the nearest charity to be recycled.

The advantage the younger kids have is having had time to play with the latest technology, while in school and not needing to spend 8 hours a day working, and many hours after in raising a family. I work about 14-15 hours a day between my company, and family responsibilities. Leaving much less time to play. flexibility isn't the issue, "available time" is. Still I wouldn't discount the opinions of younger coders, and often seek it out. But I have serious doubts about random "kids" offering to teach me how to code better.

Re:That's true

[johnw]

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.

You call policemen "sir"?! Where I come from, the policemen call members of the public "sir". It may be said in a sardonic way, and they don't really sound like they mean it, but at least it's there. You're right about them getting younger though - there was one on the news recently reporting on a twit in a Porsche who'd managed to get it submerged to the point where just the tips of the wiper blades were breaking the surface. (Wipers still running despite the water.) I'd swear he (the policeman) was about 12.

As a man in my mid fifties, I call my doctor "Charlie".

Re:That's true

[freeze128]

If a kid gave me a book on being a better programmer I'd read the fucking thing. Ego be damned.

What if the kid is Justin Bieber?

Re:That's true

[Weaselmancer]

Being even older than you, and being an experienced programmer, I can say for certain that I'm not willing to say that kids can do things I cannot. They merely have had a different learnig experience and may have learned things I didn't, because they were hacking things that I don't have the time to hack.

I believe we are saying the same thing. You just explained the how and the why of it. This is why kids can do things we can't do. Could you and I do them? Sure we could. But we haven't. And they have because they have had the time and the familiarity. You and I could do these things certainly, but it would require a few months to study, a free babysitter and someone to cover our mortgages while we got up to speed.

Nor would I "read" a book given me by some wiz kid fresh out of school. I would probably look at the book as I do all books, and make a judgemnet call on whether it was worth a read, or to be given to the nearest charity to be recycled.

As would I. I wouldn't automatically read anything some kid gave me, of course. But unlike the GP I wouldn't discount it out of hand which was my point. I know a few programmers my age or older that wouldn't even read the cover before it hit the circular file.

Re:That's true

[metaforest]

Many years ago I was 'the kid' on a rather daunting project. I was to verify the correct implementation of an IEEE-754 lib that had been implemented on a new platform. There was also an identical implementation on a previous platform that had been in service for 4 years, and had no reported bugs against it for two years. The previous implementation was in active use, as shown by a steady stream of devs asking for clarification, assistance with bugs (in their code) etc...

So my plan was to validate the new code by putting it operation-to-operation with the old code.
Since the two libraries claimed to conform to the same standard I treated the old implementation as the gold standard and developed as test system in C and assembly on the new platform that communicated with the old system to execute identical operations, and compared the results bit-for-bit, and where reasonable for execution time. Since the project was underfunded and I had other responsibilities I also made it a Montecarlo test system... sure it did a complete suite of unit and bounds tests, but after that it ran in random mode. It ran billions of test cases...

After a few weeks of run-time I noticed an consistent error. The logs were showing that when either operand in a multiply or a divide was a +2.0000... the result was off in the least significant bit of the mantissa. (eg. 2.0 * 1.0 = 2.00...01 or 2.0...0 * 2.00...00 = 4.00....02 ... etc)

Further analysis concluded that new implementation was returning correct results, and the old platform was returning incorrect results.

After consulting the PM I posted a bug against the old code. All hell broke loose. The Gray Beards upstairs came down on my 20 year old ass like The Wrath of God(tm) for daring to challenge their combine 120 years experience in math implementations and the fact the old implementation passed the official IEEE-754 test suite flawlessly, etc.

It got particularly ugly when I pointed out that the new code passed that test suite as well, as it was a hard requirement before I could accept an RC as testable. I had already chased that lead down and had the reports to prove that the implementation I was testing had passed the suite as well.

So it was that I my code was drug out before a committee, and reviewed thoroughly, etc with my PM and manager acting as my 'legal council' before the assembled wrath.

Eventually the issue was uncovered. The Gray Beards had closed the original bug reported as 'won't fix' and then somehow later the record was altered to 'not a bug' So I never saw it for my review when I was looking for open activity against the old code.

While the PM and my direct supervisor protected me from the blow-back... being the messenger was bad for my career at that company. I got shuffled off to less important projects until I left in disgust.

Don't anger the Gray Beards... as the 'new kid'... it will end badly for you, even if you are right.

"Hey. Dude."

[roc97007]

"Your code sucks."

Well well well....

[roc97007]

I always wondered where Mel went to when he "moved on to greener pa$ture$".

stealth

[johnsnails]

svn blame

First thing to do

[FuzzyDaddy]

Talk to this guy

How comfy is your work environment?

[sammy baby]

Depending on your relationship with your coworker, you could try something like this:

"Dude! What the fuck is with this? This whole module reads like it was written by David Foster Wallace after sustaining a concussion!"

Then, having gently broached your general concern, you could offer a few helpful suggestions. "How about actual English names for some of your variables, instead of packing everything into a global array called "Stuff"?"

I'm actually only half kidding here. I'm lucky enough to work with guys with a sense of humor, so when one of us screws something up we expect a certain amount of ball-busting. I really do feel that this is a valuable practice, so long as the critics don't go too far with it and the critiqued can keep a good sense of humor.

Re:you lose

[rubycodez]

indeed, this article is just one of jealousy. the old-timer will be there long after the kid is outsourced, for his wares are running the place

It's really "good" code.

[firewood]

Nowhere did you say the old guys code didn't work, had serious bugs that weren't being fixed, or was noticeably behind the rest of the team according to the project schedules. Until that happens, and as long as the old guy is solving problems with his skill set, management may well consider your "good coding" criteria to be bad for the company, thus making you, not the old guy, the troublemaker for suggesting changing what works. Businessmen have been burned by too many trendy sounding academic fads, such as all the good coding practices recommended here.

Wait till you can out-code him, solve major problems he can't, and get promoted above him (or he dies or retires). Even if his smelly pile of code crashes and burns, if he can tape it back together faster (running) than you can rewrite it (feature complete), he's the hero, and you're the troublemaker.

Re:It's an evolving field...

[tarpitcod]

He needs to learn:

Just because something is different doesn't make it bad or wrong.

For all we know the guy he's complaining about is a demon APL programmer. Or a guy who was partitioning FORTRAN so it ran decently on a super. Or maybe the guys an oldtime LISP dude and all the languages he's coding in makes him lament the loss.

Just fix it.

[jcr]

When I see bad code, I fix it, test it to make sure I didn't break something else, and check in my changes. If the guy who wrote the bad code objects, then he's asserting that he OWNS the code in question, so made damned sure that any bugs in that code are on his plate to fix. If he doesn't fix his bugs, escalate.

-jcr

Bad idea.

[jcr]

You don't have to embarrass anyone. Just fix what you want to fix.

-jcr

I agree..

[nanospook]

I really agree with this. Especially that last statement. It's the manager's job to handle this and fix it. If he can't see the problem or doesn't at least discuss why he would permit it (perhaps business reasons that are valid), then you are in the wrong place. If he goes, yes i know, I want to fix it, but we have to do it my way as the problem employee is actually valuable, then you have to trust in him to do it.

Aspergers or some other form of odd ball brain

[nanospook]

Is it just the coding? Does he neglect to say hi or bye. When you are talking to him about something, does he just go back to work without giving you feedback because he is really busy. Does he skip using an IDE environment because he can just read and compile the code into an app. He's totally happy to do this over and over.

Does his odd ball brain make him superior at some tasks? Can he juggle 15 projects at once? Can he stay nose to the grindstone for 10 hours with a 30 minute lunch? Does he eat the same thing every day for lunch?

I'm describing my co-worker. Same coding issues. Same lack of interest in anything he doesn't write. But he is a valuable member anyways because he keeps things going in the old world while we write a new platform. Originally, he totally pissed me off, but I realized my manager understood my points and my desires to have a better organized team and environment. At the same time he explained he was working against the gun to reach milestones for our mid size firm.

Now i just understand this guy better and focus my attention on the more average personalities on my team that need a good code review or the benefits of my experience and talents.

Re:Aspergers or some other form of odd ball brain

[nanospook]

Oh I know why he is what he is! It's BACTERIA!

Leadership.

[genocism]

If you lead and no one follows then you're just out for a stroll. You're problem is leadership. Sounds like you already discovered that criticism isn't an effective method of exerting influence. Only after you win his heart will he be open to logic. This dude is probably sensitive about the age gap between the two of you. Play off of that by learning COBOL or something. Only when his age difference makes him feel intelligent and respected will he start to come around to appreciate what you know. It'll take weeks, not days, to win someone over and only then should to start talking about modern software design.

Patronize him

[davidwr]

Patronize him, but only if 1) you are his boss AND 2) he's really so good that he's earned it.

Things like "Most of us aren't smart enough to read through this code and understand it quickly. One of the things keeping me from recommending you for promotion is that right now, if the team loses you, we couldn't maintain the code that you've written. For all future projects, I need you to 'dumb down' your code so less experienced programmers can jump in and maintain it if necessary."

what is good/bad code?

[SuperDre]

Good and bad code is all in the eye of the beholder.. what looks like great code to you can look like utter crap to another..
There are so many ways to do code, and also there are so many different views on what's good practice and what not.. Yes stuffing everything in one big function which spans multiple pages normally isn't considered good practice, but splitting every single thing up into separate functions is also not good. Also some people think using lambda expressions is great, others just think it makes it unreadable and you should just put it in a separate function (in the end, a lambda expression is nothing more than a function without a name)..
Just like declarations, some swear by hungarian notation, other actually swear at it (to me it all depends on what programming language you are using).

In most cases just talking to each other and explaining why a specific way might be better is the way to go, maybe the other person than explains why their way which after explaining makes sense to you.. As I said everybody has different views on what constitudes to bad/good code..
If you want to force your way of development on others in a company than you should have a document in place which tells exactly how to do some stuff..
I for one always say, at least comment your code as good as possible, as even having great descriptive variables doesn't mean the code is readable.. and a person once told me: 'well good written code explains itself' I responded with 'well bad written code also explains itself, because the compiler can understand it so it must be good written code'...

This whole topic so badly wrong.

[tp_xyzzy]

Here's reasons why I don't like this topic:
  1) There is no bad code. Every programmer has written the best code they can write. If you have trouble reading it, buy some better glasses.
  2) Complex code is not bad code. The programmer you're trying complain about is smarter than you think. He saw some complex problem in your software architecture and his complex code fixed it. You still can't even see the problem, much less the solution. It works, and any complaining about the details is useless.
  3) Reading someone elses code is always difficult. about 90% of programmers think they write better code than others simply because reading ideas from other programmers is difficult. This accounts large portion of "bad code" out there. You need to find better criteria for labeling someone elses code bad. How about check test cases that fail... Oh wait, where's our test cases?

Code Reviews and Ego

[prk_inc]

In our company, code reviews are mandatory and that restriction is built into checkin triggers (clearcase). No exceptions. When this process was instituted about an year ago, expert programmers wanted to checkin without code reviews. They only wanted to review new-hire or inexperienced programmers' code. However, the new-hires all knew the 'right way' that they are taught in school, though they should be reminded to keep following those good ways (in school you lose points for writing bad code in programming assignments and your grade is at risk). Over the last one year, after the triggers were instituted, the team culture has changed from having lengthy email disputes to something more like teamwork. Every comment is greatly appreciated and good reviewers are rewarded. The only ones people still don't agree upon are indentation and code-formatting related. People still have different opinions about those (we found a different solution for it that everyone agrees with). However, there is almost no dispute in our team about what constitutes good, working, maintainable code. Everyone in the team has learned and would not want to live without mandatory code reviews any more. If the expert programmer disagrees with the comment, fire him. There are thousands of other expert programmers out there that work well with the team and lead by example.

Not smart

[Kim0]

The coworker is NOT smart.
Only smart programmers can write simple code.

Kim0+

What you need

[Brian Kendig]

You (and every other development shop) need:

* A coding standards document. Using one from a large open-source project (such as http://framework.zend.com/manual/1.12/en/coding-standard.coding-style.html or http://www.kernel.org/doc/Documentation/CodingStyle) is a good idea. This ensures that you do not have to spend any time being surprised or misled by how a piece of code is formatted.
* Unit tests. They make sure that your code continues to work the same way as you develop it. They also exert pressure to make sure that your units (individual functions to be tested) remain small and concise (or else the unit tests become a bear to write).
* Code reviews. This ensures that more than one person understands how a piece of code was written. It also means that the reviewee learns from your comments and you learn from his code and you both are better programmers for it.

And, most importantly:

* A manager who believes in all of the above and is willing to support and defend it.

If you have all this, then it ceases being a personal "you vs. him" issue, because you can objectively point out (to him, to your team lead, or to your manager) where he's violating the coding standards, where his unit tests are not adequate, or where he is ignoring his code reviews.

The alternative is what it sounds like you have now: cowboy programmers, quickly cranking out code that satisfies a need right now but will take huge amounts of time and money to maintain and extend in the future.

lily padding

[minstrelmike]

I've never heard the term lily-padding but I've worked with those sorts of folks. They have to be removed at least from the team if not the company, sidelined into solo projects that don't require maintenance (because they never completely work in the first place ;-) A development team needs cohesion, not necessarily conformity. I work with 3 other coders and we debug each others code when needed and over the last 7 years have mixed and matched approaches into something that is a lot more standard than any possible set of standard coding practices written up!?!

It happened organically. If you debug your own code two years later, you should have learned a lot (if you've been coding that time) whether on your own or working in a team. There are folks tho who do have what they call 20 years of the same 1-year experience, never learning anything after the first program. /* that does not sound like the OPs issue tho*/

cost-benefit of coding approach

[minstrelmike]

some code needs to be maintained and some doesn't.
speed of coding vs maintainability vs robustness are always in a tradeoff in a professional programmer's mind.

If this is a simple conversion routine that won't be used again, git her done..If robustness is important, spend some time thinking about the over-all design. If you have snarky developers with some kind of religious affiliation to a language or operating system, don't waste a lot of time arguing (assuming you want to win an argument (you know facts, logic, that jazz). If you just like arguing, then there is no one better to fool with ;-)

backfire

[minstrelmike]

For a loser programmer, suggesting refactoring can backfire. We told one gal (who was finally fired after waaaay too long) to use a library file (in Perl) for the common routines for the reports she was 'writing' (cutting and pasting). The next day, instead of 20 files in our report directory, we had 40, a new .lib for every .pl!?!
We refused to make any more suggestions.

Your management is paid to fix these problems

[emzee]

Been there! Every time you have to fix his garbage code, make sure to let management know. Push them to deal with it. It might be as simple as sending him to a basic course in OOP fundamentals - far too many old-school coders have no formal instruction and just don't "get OO" and insist on writing procedural code in OO languages. Bad OO code is much harder to work with than bad procedural code and management must be made to understand the cost of letting him continue to write bad code. If he still doesn't get it, you could suggest he be moved to architecture or some other team that can use his knowledge and experience while keeping his fingers out of the actual code.

FTFY

[presidenteloco]

You: "Knock knock"
!Coder: "Who's there."
You: Yuri
!Coder: "Yuri who?"
You: "You really can't code."

Just be direct

[IsoQuantic]

How about just telling the fellow directly? Why the hand-wringing over this? I appreciate it when someone tells me where I need room for improvement and any reasoned person should as well, no?

Pair programming

[NewYork]

Sounds like good case for https://en.wikipedia.org/wiki/Pair_programming

You ask nicely ...

[choke]

"Are you still having problems with people reverting your commits at your new job?"

Don't fret

[carys689]

In 99.999% of the cases, every engineer thinks every other engineer's work is a piece of sh*t. So what else is new?