Slashdot Mirror
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?"
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.
What political party do you join when you don't like Bible-thumpers *or* hippies?
Fire him
When the foot seeks the place of the head, the line is crossed. Know your place. Keep your place. Be a shoe.
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....
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
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.
-Woof woof woof!
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.
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
Leave him an anonymous poem:
Roses are red,
Violets are blue;
The C obfuscation contest produces bad code,
And so do you.
Teach him proper indentation.
When did /. become Dr. Phil for nerds?
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. :-)
Why don't you ask the man to his face??
* Seriously...
APK
P.S.=> His answer MAY surprise you, or, you may surprise him...
... apk
conduct code reviews here is a good tool http://www.atlassian.com/software/crucible/overview , although it is not necessary to use a tool.
And hire a new one who hasn't been stuck in their misguided ways for decades.
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."
I should use this sig to advertise my book ISBN-13 : 978-1501515132.
He'll sleep all day and stop coding. Problem solved. http://dilbert.com/strips/comic/2003-06-19/?CmtOrder=Rating&CmtDir=DESC
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).
Ascalante: Your bride is over 3,000 years old.
Kull: She told me she was 19!
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.
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)
Build it, and they will come^Hplain.
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.
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".
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?"
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.
If your current coworker is smarts he must read book, if told him that you read 'Refactoring: Improving the Design of Existing Code' and could lend it to him if he is interested. If he is not into book, he is not so smart. Maybe clever but not smart
Do it at his exit interview.
Find other job with good programmers, if not when you want, when you can.
Dude, your code sucks!
Get the hint? He's talking about you, or maybe me.
Book by Rick Maurer "Why Don't You Want What I Want" - I found this book immensely helpfull. Check it out on amazon
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.
Why don't you convince him to start using deodorant, shave his neckbeard, and start dating a supermodel?
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.
It's easy. You do what a professor of mine did.
"Dude... Your code is horrible. Yes it works but nobody know how the fsck it works. Here's a book on writing effective comments and coding conventions (sorry can't remember the name of the book)."
Now I know your not in a school environment but as his boss you need to explain to him that the code has to be readable by others. This is his first verbal warning. Give him a book on writing readable code and comments. Give him a couple of months to clean up his current code. If nothing happens then give him his first written warning. If nothing happens then the second written warning. Finally if he's still hasn't quit and still hasn't cleaned up his act give him his walking papers. Where I am you just need to give 1 verbal and two written warnings and show how you tried to help get the employee on track then you can fire them and not have to pay severance.
Pair Programming might help by showing him other approaches. Just be sure to man the keyboard more often than not.
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!
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.
Pretty good is actually pretty bad.
Seems like the original poster seems like their stuff is better than someone else's. Hubris?
Here are some options; let us know which one you picked.
a) Grow some and speak to him
b) Tell your manager
c) You're in a box. Do you think your code is super-excellent-miraculous?
d) Why do you care? Does it hinder you? If so, tell b)
e) Offer some suggestions and re-write some of his code.
f) Get ready to find another job
g) Suck it up, buttercup.
h) Accept your differences. Learn to enjoy your differences.
i) Sleep with his wife/partner just to get revenge.
j) Work from home constantly.
Post his code to the DailyWTF then send him the URL
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?
Try not. Do or do not, there is no try.
-- Dr. Spock, stardate 2822-3.
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.
it wastes your time and annoys the pig.
Request that management set up a system of code reviews. If they're not willing to do it, then leave, since there's nothing that will stem the tide of crappy code. Nothing improves the quality of code, finds bugs faster, and for less effort than code reviews. Have it be policy that code can't be checked in until it passes review, and propose hard and fast criteria, such as comments, meaningful variable names, compact class hierarchies, small functions, etc. Find everything bad with this guy's code and come up with a clear policy that will prevent it from getting checked in. Tell management in the language that they want to hear, which is that bad code is "job protection". Don't single this guy out. Once his code fails review (by someone other than you), it'll be him screaming to management and being a crybaby, except that he's not trying to improve the product, he's trying to give excuses for being lazy. Any manager who isn't phoning it in will see right through his excuses. Once again, though, if management isn't willing to institute this common sense policy, then you should find another job, because they're not willing to put quality controls in place, and don't care about the quality of their product.
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.
Damn_registrars has no butt-hole. Damn_registrars has no use for a butt-hole.
Find the book on programming you think would help him. But don't make it too obvious. Get in the habit of sharing interesting reading material such as magazine articles. Then casually lend him the book, posed as just another interesting topic.
Ask him to explain the code.
That will not be easy for him and should show him why coding standards are important.
There are quite a few "In my opinion's" missing from the question. Ah well, to be young and know it all... I remember those days.
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.
Time to offend someone
With his lack of skills, he'll either be out the door or in management before too long.
The world's burning. Moped Jesus spotted on I50. Details at 11.
Do a code in his style, and ask him to maintain it, specially doing changes where that way of programming show why its wrong.
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.
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.
This space for sale
Make him maintain the code. That's how I learned to write code that's easier to work with.
I went to eat some animal crackers and the box said, "Do not eat if seal is broken." I opened the box and sure enough..
Didn't Linus set an example just a few days back?
Good programmers are constantly learning and improving their techniques.
If you've encountered a long time programmer with code that bad, nothing you can say or do will help.
You should try to teach your dog to speak fluent French; it will be easier.
I do suggest that you ask your boss to implement a "everybody maintains their own shit" rule.
That way your co-worker will be the only one to suffer from his code.
It's their job, and if they won't back you up you'd be stupid to take this on yourself.
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.
Be seeing you...
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.
whats it to you?
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".
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:
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
John McAfee 'It was like that time I hired that Bangkok prostitute; to do my taxes, while I fucked my accountant'
Assuming he reads Slashdot, I think you've already figured this out.
Kwisatz Haderach
Sell the spice to CHOAM
This Mahdi took Shaddam's Throne
And send him the link.
I eat only the real part of complex carbohydrates.
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.
Ask him how the hell you could possibly test such code. Answer, you can't. Testable code is broken down into functions which do one thing, are often referentially transparent, have small scope and try not to mutate outer scope/state when possible.
I have had the same issue with other programmers for my entire career, they write huge huge functions with levels and levels of conditionals/switches, terrible names, impossible to test and mind-boggling to maintain. You can often refactor their code somewhat when it is your turn to work on it, but sometimes short of redoing it (which is a terrible idea which will get you in trouble and seen as wasting time unfortunately), you actually cannot really do anything about it.
Chances are the person who wrote it still has his job because he always gets shit done, regardless of how unmaintainable it is, and . This is because he probably has a really good memory for working with what he wrote and is unable to see that besides himself, no one can understand it but him.
I have noticed that as my memory gets worse, my code becomes more and more organized. It is impossible to do anything about this, other than suggest code reviews for all. Its highly common you will find programmers like this everywhere in industry even though it is maddening.
Simply rewrite his code in the way that you believe it should be written. Do it in your spare time if necessary. Then let him, and everyone else, see the difference.
It's called unit testing. learn it, love it, live it. (http://en.wikipedia.org/wiki/Unit_testing)
Find a company that doesn't keep people around who write bad code. Not only will that company produce inferior products, but the fact that they keep people like that around is indicative of dysfunction. Jump ship, cut your losses, get a better job at a better company. Unless of course he's really open to constructive criticism, in which case you should probably just tell him. What comes to mind though, is that old saying, "you can't teach an old dog new tricks".
make him document it!
lol, I'm not sure why but this made me laugh :)
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??"
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.
This is simply an opinion. Everyones idea of "Bad Code" differs from person to person. Personally, I grew up with 68K assembly and BASIC. So I LOVE GOTO functions and jump commands. I also love numbered lines and fitting entire programs into one source code file with NO external dll's, or other garbage. So to ME, what you are describing sounds decent and YOU might be the bad programmer. What I have learned over the years is there are 2 types of programmers, the serial type, or in-order (like me), that likes line-by-line code and doesn't care for "structured" garbage. Then there are the parallel type of programmers that like to have their programs code broken up into lots and lots of little loops, and subroutines, no GOTO commands, and well, in my opinion, crappy coding that can't be followed line-by-line.
Just a perspective you might want to consider first before saying someones code sucks.
I suspect that the code in question has not a single unit test. Ask the developer to help you write unit tests for the existing code. Then, redesign the code until the tests are simple. (10 lines or less for each test case).
Bad code usually means poor design. Poor design is weeded out with simple test cases.
TDD along with SOLID design principles will deliver you success...
http://en.wikipedia.org/wiki/Test-driven_development
http://en.wikipedia.org/wiki/SOLID_(object-oriented_design)
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.
"Your code makes my eyes bleed."
Programmers don't magically get better by telling them what they are doing wrong. It takes a long time and continuous effort to become the kind of developer who writes good code. If this developer's code is as bad as you say, this person is YEARS AND YEARS away from writing decent code.
Just fire the guy. He will not be writing decent code any time in the near future.
There's guys you can hire from the back of that magazine which can take care of problems like this.
In this case you'd be doing him a favor I can't imagine anyone like that should be forced to remain alive until the day they discover to their horror what an utter waste of skin they are. Put that dawg down!
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.
This space for sale
Easy!
Why is this not something your team handles by itself?
Is it ok to give praise on your team? Is it ok for your teammates to criticize your code?
If the answer to any of the last two questions is "no", talk to your manager about how you are incurring technical debt because your team culture is dysfunctional. If you are the manager, fix it. I have no idea how - it depends on the personalities of the developers on your team.
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.
Life takes interesting turns, but the most interest is when you're off the beaten path.
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.
BZZZT! Answer was not in the form of a HOSTS file update.
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*
Good leaders run toward problems, bad leaders hide from them.
Leading out with an icebreaker joke always works well for me... here is an example:
You: "Knock knock"
!Coder: "Who's there."
You: "You really can't code."
I am still working on improving my delivery.
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.
I haven't thought of anything clever to put here, but then again most of you haven't either.
Praise him to management and get him promoted to either architect or manager.
Yeah. My boss was that bad.
For those who seek perfection there can be no rest on this side of the grave.
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).
10 PRINT "Your code sucks."
20 GOTO 10
Have gnu, will travel.
...the book Code Complete
I was the Systems Admin for a start up and I had to load programmers code on my servers. I also had to clean up the mess thanks to no documentation and little surprises they didn't mention.
Many a time I've seen what a disaster their programs were and told them an untrained baby orangutang could do a better job then they did. As the old saying goes,
"There is nothing more dangerous than a programmer with Root access and a screwdriver."
It doesn't matter if he writes "bad" code or not. All that matters is does it get the job done. If it bothers you then YOU REWRITE the code, period. But don't tell anybody because you won't get paid for that. There are coders better and worse than you so who are you to tell your code is God's creation? Probably your boss cares even less.
And I stopped caring 10 years ago. You might as well...
What if this bad programmer is your CTO? Do you just bite the bullet and quit?
My CTO has written an entire framework of horrid code that would dry out the tear ducts of any decent programmer. But since he's the CTO I'm forced to work on his creation from hell. He's clearly unqualified to be a CTO and it's come to my attention he only got the job due to cronyism.
What should I do?
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.
...sounds like they need all the help they can get right now, with the security wins announced recently!
Code reviews work well too; however, unless you are going by some set of standards then it's merely opinion. Also, if you have standards then you can automate the verification of those standards, and if you can automate then you don't need to confront. Just remember to get everyone's buy-in to the standard.
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. .... . 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.
Work with, not against, his personality. He thinks he's the smartest guy around. So go with that. He's your new mentor. A few times a week, ask him about YOUR code. Say something like:
Can you look at this function I'm writing, please? Linus Torvalds says that "Functions should be short and sweet, and do just one thing, and they should have more than 5-7 local variables." The Microsoft guidelines say
Ask him if you should make the thingRetriever a separate object from the stuffDisplay in your code. He'll likely eat it right up and never realize that he's actually getting a two minute lecture on a different aspect of code quality each day. If he starts out the day thinking about these things, he'll soon notice when he's writing garbage and his ego won't let him keep putting out garbage for long once he's aware of it.
If, after a month, you see zero improvement in his new code, then ask polite, direct questions about his code as needed. "I'm working on Foo(), what is the "bob" variable?" "Hey John, what does is this function called tp() supposed to do?" (My predecessor actually used "bob" as the name of at least one variable in each project.) Those questions make it explicitly clear that his code is unreadable, so do this only after you've kissed his butt in step #1 for best results.
Unless you are the one paying this guy it ain't your problem dude.
I think slashdot has a post about you.
Your pizza just the way you ought to have it.
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.
If not, then he must be his brother....
I take no responsibility for what I say. Even though I'm never wrong
If you offend him, he'll tell you to GOTO hell.
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.
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.
"There is more worth loving than we have strength to love." - Brian Jay Stanley
you just can't.
Seriously. Give up. His code WORKS, right? If he's been coding for as long as you say, then he comes from an era where THAT was the only measure of success... not readability, portability, code maintenance, and certainly not proper OOP. He was forged in the fires of being a programmer before the concept of "software engineering" existed.
Be glad he codes in a language you can read.... my guess is that was the result of a lot of persuasion from brave coworkers before you.
My feed reader truncated the title of this post to "Ask Slashdot: How Can I Explain To a Cow..."
Needless to say, I am disappointed.
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.
s/more error-prone/less error-prone
None at all. But tell James I said hello, would you?
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".
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.
I am officially gone from
Patch or hack the compiler to detect his coding style and generate plausible sounding error messages.
Preferably a clueless intern or some greenhorn just out of college. Have him look the guy's code in his presence and say something like "GOD! Who wrote this crappy code? What a god-awful unmaintainable mess! I hope they're not still working here!"
You may laugh (or not) but this can be very humbling and motivating. I had an intern do this to me on my first programming job. He said, "Who wrote XYZutil? It's buggy as hell, crashes all the time... what a piece of junk," etc. etc.
Me: "Uh... I wrote it."
You suck at coding bro. Every consider a job in the fast food or hospitality industries?
* Carthago Delenda Est *
Shoot the bastard, for there is no other way. Been there, haven't had the guts to do it yet.
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.
I am not a crackpot.
And louder.
Sometimes, people think code is bad only because it does not suit their specific stylistic preferences. Sometimes, code that works perfectly is also impossible to for anyone else to maintain, which will be detrimental to the business when it tries to scale up or when the lead developer finally leaves.
It is not always clear, for any specific code quality dispute, whether the code is actually unmaintainable, or whether someone just doesn't like the style. Whenever the dispute happens, both positions will be asserted.
Regardless, it is in the company's best interest to ensure that the existing code can be affordably maintained by whatever talent will be available when the current code authors are gone. To that end, management should be requireing code reviews and style guides. If they are instead completely trusting their one favorite programmer, they get what they deserve.
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.
To wit: He MAY find out the guy is avoiding say, function call overheads (yes, there are those, just like instancing objects has memory overheads for example)... not much of a justification on his part (vs. his what sounds like inlined monolithic does it all single procedure 1950's-1960's type style), but it IS a possible.
My guess? This guy the article submitter speaks of has 1 truly GIGANTIC thing going for him @ this place - he knows the business data schema, and all the little "tricks" on where to go for what KIND of data... every shop, has a guy like that (usually, imo & experience? It's a DBA, or Business Analyst).
Personally - IF this "oldster" is that kind of guy? He ought to be 'vertically promoted' to a business analyst position... but, that's just me, & IF he is as I suspect him to be, per the above guess on my part.
I don't write code like the article submitter writes about (i.e.-> 1 big dropdown inlined monolithic type is the impression I am getting).
I am a "fan" of procedural style code MOSTLY here... not a "huge fan" of overusing OOP, because I've found, especially on LARGER (purely relative term) projects that creating TRULY reusable objects usually somehow ALWAYS gets project-specific code in them, negating reuse!
So - Perhaps that's what he meant by OOP overuse? I don't know - he wasn't specific on that note!
I am really actually a fan of a "mixture" of OOP, & procedural coding (by that, I mean, e.g. -> Single 'main driver' that calls subordinate procedures &/or functions from the same unit, or separate 'generic' unit (for say file I/O stuff)) & using prebuilt objects that have already been created that do the job for tasks (such as controls in IDE's, or classes that have been written for data access for example, that a company already has).
* And, there ya go!
APK
P.S.=> I've sat down during code reviews (good shops do these imo), & stated things like that to other devs, & they in turn, did the same to some of my work/style too... you always end up learning "upsides" &/or "downsides" + when, or when not, to apply them - albeit, over time thru experience...
... apk
Give me his email address.
He is creating job security for himself since only he can maintain his code... You, who write perfect code, can be replaced.
Might be too late to teach the old dog new tricks.
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?
Most of the most Inept and Incompetent coders I have had the misfortune to deal with reside in Tel Aviv.
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.
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.
Are you working with Ray Ozzie now?
Post all of his code here for um, review. Yeah.
...yourself, when you look at the code you wrote ten years ago. It is the most atrocious stuff, b/c of all the stuff you learned since you wrote it.
Did you ever try asking this old-timer-lack-of-style programmer to code review your code?
By criticizing his code, you are in effect, attacking him. It is his art. Good or not, he's been doing this for years and he likely has a lot of pride in his craft.
But when you have him code review something that you wrote, he's going to pick apart your approach. In the process he's going to ask questions about your style, your reasoning, your corner-case handling, your standards. Great, let him ask questions. In doing so, he is implicitly absorbing new perspectives to the art of coding. There is an additional benefit here. As much as you may think you are the bee's knees to programming, there may be something you'll end up learning in this process as well.
Change will be slow, but the next time he codes he may think twice about what he names his functions or whether or not its a good idea to copy/paste the body of that function. That's progress. Rinse, wash, repeat as neccessary.
Lead by example.
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.
Peter predicted that you would "deliberately forget" creation 2000 years ago...
Lead by Example.
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.
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.
Bad code will probably fail edge cases and take longer than normal to fix. Sick testers on it and measure the quantity of errors and time taken to fix the errors. Have management select a few of the problems, look into them 'trying to understand why there are so many', and ask why obscure variable names, odd factoring relative to other parts of the code, etc. are present in those specific small spots. Then say it is grounds for a wider code review.
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...
HA! I just wasted some of your bandwidth with a frivolous sig!
Proper coding, and proper anything, can only come by setting policies that dictate how code is written. How variable and function names are written, how many processes a single function can have, allowable return values from functions, etc. This would be useful for everybody where you work, both brand new and coding for 30 years. How exactly do you go about determining how long a function can be? Who decides what we should let functions return? How do we even determine what is or is not good code?
Bill Gates, is that you submitting this article? Talking bad about Balmer again, are you?
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.
Official Pi Ambassador -- inquire for details!
Chances are your code sucks just as bad.
if it works, why "fix" it? we live in a world where there is a billion way to do any one thing...
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.
http://en.wikipedia.org/wiki/Duff's_device
Probably not since I'm not sure it still compiles these days/
On this constant 'harassment' & stalking of myself regarding host files - Well, tell you what:
Disprove the things I list that a custom hosts file can do for end users of them on a myriad of levels to good effect for them I enumerate here:
---
APK Hosts File Engine 5.0++:
http://start64.com/index.php?option=com_content&view=article&id=5851:apk-hosts-file-engine-64bit-version&catid=26:64bit-security-software&Itemid=74 ?
---
You do THAT?
Then, you'll have made a SOLID point - for once!
However, I absolutely KNOW you cannot, & it's also quite obvious I've trashed you before on this very challenge as well!
APK
P.S.-> I know you can't & you've probably tried to before & FAILED... thus? It explains your truly cowardly anonymous trolling posts & 'geek angst' @ your failure to do so!
Since IF you did so as your registered 'luser' account here, you KNOW I'd "toss it back in your face" as to the times I've burned YOU, on THIS VERY CHALLENGE, before...
(You know it, I KNOW IT, & anyone else reading would too, based on your reprehensible behavior now & other times you've done this stalking of myself this way on this website forums)...
... apk
I'm a lousy programmer, or I'd do it myself.
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.
When I started working in my current job (lets keep where a secret) I saw many weaknesses in the codebase, and it was hard to understand. Some classes had morphed such that their names were misleading, and big blocks of code were enclosed in if blocks, leftovers from earlier experiments.
But the worst thing was their use of constructors that could fail, throwing an exception that was not caught at all, causing the program to crash. I fixed these bugs when I found them, and the team has moved in the direction of more defensive coding practices, both because of my gentle pestering and my co-workers ability to take constructive criticism. The code is constantly improving, and we are now putting more effort into cleaning up old code. We might even start doing unit tests soon (and now I am still keeping my employer secret).
Try to be concrete, start small, and, most importantly, be constructive. If it does not work, step back, at least for a couple of years, when you have more experience.
Things like Scrum can quickly lead to formation of new team structures, and even encourage people to leave...
Whats wrong with:
float variable1;
int variable2;
etc etc...
I think you're just jealous of his awesome memory.
Second the above, but six months or a year (or a project or two) later when even he has forgotten how it works.
Depending on how much you love your job you could just refuse to maintain it or insist on refactoring if you must maintain it - again as mentioned above that approach could go either way with management.
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.
First thing you do is piss in his coffee.
Second thing you do is piss on his computer.
Third thing you do is tell him you did both (make sure he's tasted the coffee first.)
Fourth thing you do is tell him to fix his code or you do it again....
Gently bop his snout with a rolled up newspaper and then rub his face in it.
Bad programmer! Bad! No coffee for you!
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.
Ask him to read the following slashdot post: http://ask.slashdot.org/story/13/01/03/1859210/ask-slashdot-how-can-i-explain-to-a-coworker-that-he-writes-bad-code
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.
Ray Seyfarth, ray.seyfarth@gmail.com, http://rayseyfarth.blogspot.com
Let him fix and maintain his own code. I'm surprise that no one in your company has forward him bugs from the customer.
Also doesn't your company has coding standard? if no, why not?
Is there any peer review - check in review? if no, why not?
Maybe there is something wrong with your company engineering process.
Maybe he'll see this article and get the hint.
If it weren't for deadlines, nothing would be late.
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.
Start off subtle: "Dave, what do you think of these examples the intern coded as an alternative to what you wrote?"
Less subtle: "Dave I have seen you code and can only conclude that your parents were siblings who were the result of a failed 4H project."
Straight to the point: "Dave, you mainly code in VB don't you?"
I'm in the same predictament. The guy I work with has wonderful math skills and is good at designing electronics, but has made a disaster out of some parts of our customer facing PC software. I find such displeasure in sorting through the rubble of his code that I set up the project such that all the files he typically worked on were in their own static library, and I named the library "kidsroom.lib" (ie, that one room in a perfectly kept house where the kids play with their toys and is usually a disaster zone).
I once wrote a one line C program (ie; a printf statement) of less than 200 characters that replicated the function of a five page ADA program we had been writing in an ADA class I was taking just to PO the instructor. :D
9/11 Eyewitnesses to Explosive WTC Demolition 1 of 2
Let him have his monolithic lasagna code.
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.
tell him Microsoft is hiring right now...
The field is still evolving and until we somehow find a way to stabilize how these kinds of things are done, you're always going to have this come up. I'm not just talking about the many versions of different languages and how each subset causes its own problems, but I'm also speaking of how people unaffiliated with the archetypal person who's competent in training has absolutely no business enforcing deadlines but DO.
Long story short, this field is very young. Programming languages have different versions. Programming itself is more of an art than a science and will remain as such until the dust settles and the languages somehow find a stable, static, and standardized nature because even the standards change each day... How can you have "best practices" when they fucking change every day? And when you have teams that are placed on a leash by business types, how can you really expect even the most seasoned people to really use best practices when you have the prior setting deadlines for things they don't even understand!?
This entire post is a joke and only reflects how this supposed "code critic" can't think outside his fucking box... Welcome to the programming field, my friends.
$USER.yourcode == BAD
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.
point him at this article.
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 & 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.
Once You attain enlightenment You'll know what to do.
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.
Thede, is that you?
Take a page out of the Linus Torvalds Book of Programmer's Etiquette. Tell your coworker his code sucks and to stop coding like a moron. Then helpfully suggest several of the excellent resources online that teach acceptable coding conventions for the language he develops in.
If so comment that "it's a good day when you get to delete more code than you write", and proceed to do just that. Write functions, put common code in them. Etc.
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.
Weaselmancer
rediculous.
Perhaps the original poster was not understanding the code or seeing it and the other programmer as "bad" for a very good reason.
For example, I have worked on code in the aerospace business which has some VERY strict rules for safety-critical code (not just the published standards but also corporate standards that each firm has found to help them get previous systems through the government regulatory hurdles). Often "modern" OOP stuff (like C++) is not allowed, but in cases where it IS allowed, only certain features are permitted (for good reasons) This makes the code look a bit crappy and stupid to young "whipper-snapper" coders who are fresh to the business and have not yet been through the full ordeal of the compliance processes. In such environments there are often good reasons why older (in biological years and/or employment years) team members code the way they do and why managers either tolerate it or even embrace it. If the original poster is actually in THIS type of environment then he needs to calm-down and LEARN; he needs to ask lots of questions about why things are being done this way. Only with a complete understanding of the situation (which could take years and require going all the way through the process of getting a new system designed and certified) will he be able to contribute any of his new and obviously superior ideas without getting summarily dismissed. Over time, younger programmers will be able to bring newer techniques (where appropriate) to such fields but they will need to be able to convince both their co-workers and corporate management that the newer stuff is demonstrably SAFER using empirical methods (not just "this is what I learned in college" or "lots of cool coders on the net are doing it this way"). Oh, and the company will need to be able to convince government agencies that the new stuff is safer too .... a long, expensive, and tedious process (which is one reason why it can be so difficult to get corporate managers to buy-in)
"Your code sucks."
Oliver's law of assumed responsibility: If you're seen fixing it, you will be blamed for breaking it.
I always wondered where Mel went to when he "moved on to greener pa$ture$".
Oliver's law of assumed responsibility: If you're seen fixing it, you will be blamed for breaking it.
svn blame
#1 Respect his experience.
#2 Learn his back ground, what was his initial software development environment when he started at the company?
#3 Let him mentor you so to learn what makes him tick and why he approaches from a Functional, or single program point of view.
#4 Then help him update his standard of coding. Do not write his code just make it so he asks you for assistance in understanding the current coding standard.
The above is if you are a collegue and not his manager. Key is if you are a college make it so he sees you as his friend and support for him. Also get his opintion on what you write and accept gracfully the response.
If you are his manager then the following is the method:
1. Have him document the code in UML and in particular Class and Flow Diagrams.
2. Rewrite the code to follow the diagram and modeling.
3. Create functional test agaist the diagrams.
While he does the above have two people assist him in understanding this new method for him. Be forgiving in his transition to the new method. While doing this give him some breathing room but do not reduce his importance, position and especially his work to the project. Key here is if he does not do well in translation of the Diagrams but does well with the Diagramming then he should be moved to the Design Team. If he has issues with both the translation of the Diagrams to code then he may need to take a sabatacal to get back up to speed with the new standard. in addition there maybe some hidden issue which was masked by his prior success. Key is that he was given all the assistane to suceed into the new development model and to advance in the Company.
If all this does not work out then he should at least say in 6 months time that the place gave him the most support. Then a few years he would say to people to go there since you will be given a change to be successful and all the support to succeed.
, his code works, and has been working n times longer than you've been there. one of you is redundant, and it's not him
Talk to this guy
It's not wasting time, I'm educating myself.
It's entirely possible that the old guy has seen young guys come and go with their new fads (seems like there are new buzz words and fads with every new wave of graduates) and as each came to the job he pushed new stuff with insufficient explanation and documentation, stayed for a short time, then left for a better job. The old guy may have concluded that he will be the guy who stays and finishes his career there and will be the one stuck maintaining all the code; in which case, he probably prefers an environment with none of the fads-he-dislikes and full of his his own coding style (which has always worked for him and which he will remember even when he is so old he has begun to forget the names of his kids....)
Sorry, but I've been around a long while and seen lots of these stories and seen times when the young guy was the "bad guy", times when the old guy was the "bad guy" and times when there was just a culture clash or a misunderstanding accompanied with poor communication, but no true "bad guy".
Don't waste your time. I've met a few of these kinds of developers. You can't forget: his goal was never to write good code. His master plan from the beginning was to gradually embed himself as a permanent indispensable company leech with a high-salary that pays him to mostly sit on his arse doing nothing most of the time because they can't find anyone else intellectually capable of working on it. He knows very well that his stuff is really complicated and confusing for others to work on. It makes his job more secure. You know it, he knows it, he knows you know it, and he knows you know he knows it. It doesn't matter what you say out loud in an attempt to get him to act and think otherwise because he's already prepared and memorized an entire arsenal of sound and logical explanations and arguments to combat people like yourself. He knew long beforehand that someone would come along in an attempt to thwarting his efforts. Every time he voices one of them, inside he smirks and says to himself "nice try, noob".
And I always refer to the developer as "he" or "him" (as a male) because I have yet to meet a single female programmer whom has done this kinda thing (and I'm a guy myself, so don't think I'm just being a sexist here).
So instead of wasting your time playing this game that you'll never win, just walk away. He's won this battle before it even began.
I have just been reading re-eriting such a piece of code, which pandered to every bit of nonsense advice about code.
It had a job that needed about 25 lines, was 150 and FULL of bugs. It was excessively general, and mostly wrong.
Good code should be as short as possible, flow down the page and macros/functions should match complexity, a good test is does the function a actually get called at least twice., simple/clear/short good, long/complex BAD.
If you had a business reason to read the code, ie to bug fix it, you should tell him, b ut not be agresive or confrontational.
MFG, omb
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.
but you said you loved my code, you are so canned, just you wait till tomorrow at the office!
Sounds like he's taken a queue from Wally and is programming himself towards a life time of job security. Quite intelligent depending on how you look at it.
Dood! What the FSCK!? Did Udacity teach you to write this unworkable spaghetti code?
You shouldn't care so much about that, because you will not keep working forever in that company or in the same position an roe, is it right?
Second the code works and such probably has been fully tested (means no necessity to create new defects) and for last don't think that you have the best code ever, because everything changes over the time, from languages, patterns, frameworks, IDEs, coding style and even the flow that the code has to go through. Just look at pure web Java and Android Java.
The most important thing is code working, responsible and not consuming unnecessary memory (memory leaks). After years coding you will be able to read any code, even the worst one, so don't waste time and energy doings this, that doesn't paid off.
Off course that good code helps on the initial phases though after some time you get used with it, keep in mind that what any company wants is profits and nobody on top care about code looking good or not. Just have to work fine.
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.
I feel the common slogan 'easy to read/understand' or 'maintainable' is too subjective, and not meaningful. I was once complained by someone as to my code wasn't readable/understandable because of using struct/union and function pointer. And the style that they believed good were like:
1. very deep nested if-else, so that the 'logic' is clear and more similar to human language.
2. source level function inline optimization(by human) - so we can easily see the big picture' and no need to jump across many small functions when reading the code.
3. Prefer global whenever possible. - so everyone can see each other even if they are far distant.
4. Don't use struct/union and function pointers. - [...] (This is too subtle that I can't yet understand the core spirit. )
... to stop the VCR (assuming these even exist anymore) blinking 12:00 involves a small bit of black duct tape - that's the long term solution and covers even power failures. Who the frack cares what time the VCR thinks it is, that's what clocks and watches are for (NOT phones)? Convergence sucks, and old age and treachery almost always beats youth and exuberance :-)
Perhaps you need to go back and rethink WHY goto is considered bad practice, rather than blindly repeating dogmatic mantras. There are situations where gotos are perfectly acceptable.
I used to be 29 as well :-)
. Go ask his investors what they think of his coding ability.
Fuck you, ask his USERS what they think of his coding ability.
Dude, I've used synplicity, and you just gave me a big hint of why it's such a steaming pile. What you've described is a nightmare of spaghetti code. The world is starving for an FPGA tool that doesn't suck.
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
The only title of honor that a tyrant can grant is "Enemy of the State."
You don't have to embarrass anyone. Just fix what you want to fix.
-jcr
The only title of honor that a tyrant can grant is "Enemy of the State."
Big talk - Show us code you've ever done that was reviewed as good in respected publication, trade shows, or commercially sold software.
This is the example of the golden boy rule. The rule goes like this, guy or gal X is so good that they are left alone. So what that the code they produce is unmaintainable by anyone else. It works and sometimes it is the best solution.
So the boss/manager/etc. leave them alone. Only to pay the price down the road, when this person has left, the company has grown, etc. and now others need to maintain/add to the code. Now it becomes an major effort to go in and document/restructure the code so it is maintainable.
The moral of the story is: No matter how good a person codes, if the end result is unreadable (and unmaintainable) then it is no good. I do not care how good you are, there will be bugs in your code. The better it is documented/maintainable the better it si for the next person (there is always a next person) to pick up where you left off.
I don't really know the exact solution to the problem, so I'll tell you a story about a similar situation.
I was brought into an organization where I was on a team of six developers. I was relatively inexperienced, but even at that point, I was constantly making an effort to improve my coding ability. Early on, I was assigned to work on Project X. For the next two years, I was the principle developer on Project X primarily because the other developers refused to touch it. I honestly don't know the reason why, but none of them would have anything to do with Project X and some would actually make remarks about how Project X wasn't important, even though the customer ordered Project X.
I was occasionally given some assignment, oftentimes something that no one else really wanted to do. What I knew for sure was that whenever I worked with code written by the other five developers, it was really bad code. Any bad practice or antipattern you're familiar with, they did it: building huge HTML tables with string concatenation; executing SQL statements inside loops with hundreds of iterations; writing new applications in VBScript many, many years after it became obsolete; using magic strings as delimiters (even inside SQL tables!); building SQL and XML via string concatenation with no escapement what-so-ever; terribly inefficient extra layers of indirection; the list goes on and on and on.
Wanting to provide my best to the company, I would make suggestions to the other five team members about ways I thought the system might be improved. I tried every way I could think of to be cordial, non-threatening, and helpful. I would like to believe that if someone offered an idea about how to make one of my programs better, I would at least listen to the idea with an open mind.
I tried phrasing suggestions and criticisms as questions: "Do you think it might work better if we changed this code here like so...", "I may have written this a different way; why did you write it the way you did?". I would never assert that they were wrong: "I think that there might be a way to make this feature more user-friendly. What do you think?" Every single time, I was rudely dismissed and reprimanded that I was acting out of line to criticize more senior developers (which they were, in terms of years of experience). They would see straight thru any effort to be polite and take every single word personally. There was one guy who was so bad about it that if I asked him, "I'm going to go get some water; would you like some?", he probably would have responded, "It's not your responsibility to look after me. Mind your own business!"
One co-worker was so defensive about his code that he actually set up a separate source control repository to which I did not have access and checked his code into that.
Fortunately for me, those people are no longer a part of my work life; they all resigned on the same day because they did not like a change in management.
The new people constantly criticize the old in their absence. They say that the old team's code (apart from mine) is the worst code they've ever had to deal with. I know that my code is far from perfect, but I keep telling myself that I don't want any such thing ever said about my code.
Having told that story, I think that question you need to examine is what is the attitude of your co-worker who you believe is writing bad code? Is he someone approachable? Might he be more responsive to criticisms phrased as questions or as direct suggestions? Might there be anything in his coding style you can learn from along the way? If you co-worker is approachable in any way about this issue, I suggest that you talk about it like adults. If you co-worker is like mine, then I would suggest from my own experience that you begin searching for a new job, because a well-connected developer cannot be blasted out with dynamite no matter how bad is code is.
Coding is the kind of work where every detail of what someone did and thought while writing is the actual result - code and version control are so transparent that it creates situations like these. Even writers work more oblique than that because they have a lot more options to express what they mean and they are rated by the same oblique standard.
In most jobs there are only some conditions given which makes the result (time needed, product) count more than other factors. Depending on what management or coders are used to live with it has implications on how to handle such situations.
You cant make someone responsible for not thinking exactly like you do or to think in a way that you understand in all cases, because then he would be you. You cant require someone to solve any problem like you would do, because problem solving scales with the individual problem. So all this discussion can be about is if this person shares your mindset or if your employer has restrictions on the mindset of its employees, which are of course not directly enforcable. Asking management "to do something" means asking for enforcement of restrictions that are not enforceable.
Nevertheless there are better and worser solutions and the only difference is usually knowledge and curiosity. Both of which can not be magically transferred to anyone, it takes effort and if youve got a problem then this would be a way to solve it.
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.
Have you fscked your local propeller head today?
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.
Have you fscked your local propeller head today?
Doctor: Right, kick ass. Well, don't want to sound like a dick or nothin', but, ah... it says on your chart that you're fucked up. Ah, you talk like a fag, and your shit's all retarded. What I'd do, is just like... like... you know, like, you know what I mean, like...
Promote him ... but institute a new 'random, anonymized code readability
review board'
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.
One method I used for this exact situation was a type of "paired programming". (and not that "two devs one kb paired programming" crap like it's 1980 when a friend and I shared a single TRS80 color computer writing 6809 assembly). Yeah. That old (older, in fact).
As a manager, I usually paired a senior guy and a junior guy together. As a team, they were responsible for their code. It didn't matter how they did it, but they were JOINTLY responsible for bug free and reasonably efficient code. (as determined by QA and peer review). I found it worked reasonably well. Senior guys tended to be MUCH lower management overhead, had more consistency in estimating effort, and tended to create lower risk code. but junior guys tended to be more edgy/innovative/creative/"modern". They pushed the senior guys and the senior guys helped mature the junior guys. (brilliant code delivered too late is actually CRAP code)
The thing is, ALL code is crap, at some point. I've inherited code in every language, had to maintain it, update it, translate it, migrate it, etc. It's just not worth getting upset about. If the code is really crap (ie: runs poorly) *AND* it really matters, then this will come out during optimisation. If you don't optimise, then it's clearly not important. So if it runs well, get over it.
"I have a coworker who, despite being very smart, and even very knowledgeable about software, writes the most horrible code imaginable."
Just like that. You go up to h/h, and say, "despite being very smart, and even very knowledgeable about software, you write the most horrible code imaginable.
FTFY. YW. LMKHITO.
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."
Knowledge is how to play a game, intelligence is how to win, wisdom is knowing what game to play.
:-)
There's this intelligent design thingie in code too?
Tell me more about it ;-)
OOP is a hog, writing complex functions can actually speed things up in the compiled code, and if he reduces functions to intelligble variables, he might have just reduced the expressions to a simpler form. Others not being able to figure out what abitrary variable or functions do, is not a sign of bad coding. He might have a deeper level of understanding of programming than you. Challenge him; rewrite a piece of his code that executes faster, uses less resources and is smaller, then he'll listen.
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'...
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?
You can say anything to a person when you're quoting somebody else. Make up a story in which you sneak the horrible truth for him.
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.
The coworker is NOT smart.
Only smart programmers can write simple code.
Kim0+
Why don't you go get a social life and stop worrying about what other people are doing afterall someone could easily go through your code and work out there are lots of things wrong with it too!
maybe just cover his desk with this picture:
http://www.quickmeme.com/meme/3sfl4p/
(comment : Your code is bad And you should feel bad)
simply brilliant.
well played, sir.
www.thedailywtf.com - maybe he'll take the hint
Rewrite his code for him in the shorts method possible, then put it on the refrigerator for all to see.
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.
Ask him to attack you with a banana
YOU CAN HAS BAD CODEZ
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!?!
/* that does not sound like the OPs issue tho*/
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.
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
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.
I took the liberty of refactoring your first sentence to make it more readable and eliminated a bug:
""I have a coworker who, despite being very smart, and even very knowledgeable about software, writes the most horrible code imaginable."
refactors to
firstSentence = basicSentence("", "I", "", "have", "a", "", "coworker") + phrase( "who", "despite being very smart and even very knowledgeable about software", " writes the most horrible code imaginable")
The bug was the comma after "smart".
sentence = basicSentence(glueWord1, subject, interjection1, verb, glueWord2, object, interjection2)
depClause = dependentClause(connectingWord1, sentence, puctuation )
indepClause = independentClause(sentence, punctuation1, connectingWord)
phrase(connectingWord, interjection, phrase)
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.
Maybe he's been trying to protect his job? If no one can understand his code and its is used by the company then that makes it harder to fire him or lay him off if the company has to downsize.
People who speak English with heavy accents that are difficult to understand, often have some of the best ideas (e.g. Albert Einstein and Linus Torvalds). It is not about the syntax, it's about having simple and well-designed interfaces (along with efficient implementation) that makes software useful and reusable.
Don't judge the quality of a symphony based upon the font used to publish the sheet music. Everyone's Python code looks beautiful, or it won't run because the interpreter/compiler thinks white space matters - but that does NOT mean all Python programs are beautiful. In fact, a lot of beautiful code is actually butt-ugly software (e.g. a well-commented CORBA IDL file defining a useless service) which might very well be running on top of some "ugly" source code which IS beautiful software (like the Linux kernel src).
... abounds, is obvious to end users, and comprises a hidden cost to businesses in terms of the time lost to user work-arounds rather than productivity and quality.
Before you approach your co-worker, make an honest judgement on how insecure he is. Most of the people I work with are down to earth and we can question each others work without issue. However one day I discovered an oversight to an check-in made by a very insecure coworker. He couldn't understand what I was trying to explain to him (which may have very well been my fault) and the frustration at me questioning his code caused him to explode. He spent 30 seconds calling me every nasty name in the book. Then if that wasn't bad enough, he then began to cry. For 45 minutes I had to listen to a grown man cry.
https://lkml.org/lkml/2012/12/23/75 and follow it with the word "hint". Then run for cover.
You: "Knock knock"
!Coder: "Who's there."
You: Yuri
!Coder: "Yuri who?"
You: "You really can't code."
Where are we going and why are we in a handbasket?
I suggest that you practice with your significant other first. Once you have mastered the art of explaining to the S.O. that you would like to dictate their appropriate weight, extracurricular activity, preferred conduct in the kitchen, and method for brushing and flossing - I think you are ready for your code discussion.
You wouldn't happen to work at Bell Labs in Mad City, would you? Because this sounds a lot like Mike Pomeroy, the embodiment of every sane person's rationale behind rigidly enforced coding standards, complete with Draconian punishments for violation.
All kidding aside, whether or not the man really is bright (and he may not be) if he wanted to change, he would have by now. Take one stab at correction, then explain to the boss that some poor fool is going to have to maintain this incredible pile of fertilizer and the way things are going the company will very likely be forced to hire a contractor to do it - because the direct employees won't.
The time spent in maintenance will increase by a factor of three or four because of the lousy job he's doing now. Hammer away at the cost factor and see if that gets noticed. If not, begin a job search and get out while your sanity is still intact.
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?
-- I fear explanations explanatory of things explained.
That must suck... I have a friend who makes the prettiest food in the world, but it tastes like shit. My grandmother makes the ugliest food in the world (yes really!) but it tastes WONDERFUL! Which one would you rather eat?
I will take slim, rock solid, fast and ugly code from a smelly old geezer before bloated, buggy, slow and pretty code from a freshman any day!
Sounds like good case for https://en.wikipedia.org/wiki/Pair_programming
Casteism
Documentation. Every time you get frustrated dealing with their code, write down somewhere safe a description of the problem and a solution along with the date, time, and project details. Not only does it give you an outlet for your frustration, but it could come in handy at some point.
If ever you get into a situation where it's your job or theirs, you'll be able to provide all your notes to management and there is a 99% chance your coworker will have nothing on you. This is incredibly useful especially if the higher ups have little familiarity with who you or your coworker are. Also, worst case scenario, courts LOVE that stuff.
This doesn't just work with your peers at work, but bosses as well.
Have you ever considered that your code is bad? Do you have code reviews?
"Are you still having problems with people reverting your commits at your new job?"
"No good deed goes unpunished"
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?