Ask Slashdot: How Can I Explain To a Coworker That He Writes Bad Code? 683
An anonymous reader writes "I have a coworker who, despite being very smart, and even very knowledgeable about software, writes the most horrible code imaginable. Entire programs are stuffed into single functions, artificially stretched thanks to relentless repetition; variable and class names so uninformative as to make grown men weep; basic language features ignored, when they could make everything shorter and more readable; and OOP abuse so sick and twisted that it may be considered a war crime. Of course, being a very smart person who has been programming since before I was born makes him fairly impervious to criticism, so even a simple 'Do you see how much better this function is when written this way?' is hopeless. How can I make him see the light, realize the truth, and be able to tell good code from bad?"
Re:You don't (Score:5, Interesting)
How long... (Score:2, Interesting)
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.
Have someone else fix his code bugs (Score:4, Interesting)
I perform lots of testing on my team and the ones that code well can usually find the reported bugs and fix them fairly quickly unless the logic of the code is extremely complex. But, by having another team member debug your code, the sheer amount of vocal bitching at shitty coding standards will begin to give the bad coder a clue. It will probably float up to management which will either push the employee to training, start following standards, or show the bad coder the door.
Re:You don't (Score:5, Interesting)
The solution is to make the person do all maintenance on the code. Give them a feature that's big with too short a deadline (and no one volunteering to help), force them to get all the boring bugs fixed before the new sexy feature, etc. Sometimes I see such programmers essentially get pushed out of one group and into some minor side group where they work by themselves.
Yes it's true that sometimes it's just not your problem. But it does become everyone's problem if you have to work with that person's code and it is slowing down the entire team.
Re:You don't (Score:5, Interesting)
Bingo.
I will not code to Boutique standard #47 that snot nosed brat thinks is great. Follow the standard that we have set here in the office. If I'm senior coder, than that means I set the standard.
I'll use a goto once in a while just to make a newbie convulse on the floor.
Re:short answer (Score:5, Interesting)
Pretty much. I had a similar situation with a business partner who had done well for himself (off and on) in business for 20 years, but when we started trying to work together I realized he had no concept of basic managerial accounting. The idea that you need to record your expenses, and use a simple spreadsheet that uses your costs in order to price services, and that when someone will not pay more than it costs to do a job, you don't do the job.
And he would say things that sounded right-ish, like his wife would "do the books in QuickBooks" but it turns out all she was doing was reconciling the checkbook, and not entering any of the credit card expenses. And when after four months I said, "hey look this isn't making any money" he'd say I needed to "learn to read a P&L sheet!" because the P&L said we were making money. But you can't read a P&L that doesn't have the Ls on it. If you didn't have to record the expenses, and could just record the profits, we wouldn't call it a "P&L," we'd just call it a "P." Or that he "ran the numbers," but to me that means "used a spreadsheet to calculate prices based on costs," but to him it meant "thought about some numbers and wrote one down."
You would think this would be obvious to anyone, even with no business experience. But trying to explain that what he was doing doesn't work was like talking to an angry brick wall, because he'd been doing this for 20 years, and had basically lucked into some success. Thankfully I was able to extricate myself without losing anything, but it was still just incredible that someone could be that wrong, and that belligerently wrong.
He's about broke now. Says it's the economy. Gotta be, right? Things are tough all over.
So, OP, there is that saying about old dogs learning tricks. Expect a world of defensive stupidity, and your best bet is to stay out of the way.
Re:You don't (Score:5, Interesting)
If management wants your opinion of your coworkers, they'll ask for it.
Not necessarily; having managed a few dev teams I actually appreciated it when someone would come to me with issues like this (privately, non-confrontationally, without a lot of arrogance, etc - any of those things would probably just make me ignore you). Management isn't telepathic; they can't see every single problem like magic.
That said, if your manager a) doesn't have at least enough understanding of coding best practice to know why the stuff you're bringing him is bad, b) is an arrogant asshole himself, or c) is one of those types that believes the ladder to success is built from the heads of underlings, then yeah - STFU. And start job-hunting.
Re:You don't (Score:3, Interesting)
Or not. More than once, the reponse I've seen was the icy equivalent of "Your understanding is not my problem."
Under most management, it's worst than that. "Your misunderstanding is my asset." When you have a large chunk of code that only you understand, you become the genius/hero/cowboy to most managers.
Where the management class can't code, and the inability to code is increasingly a prerequisite to a management position, writing code that is maintainable by others is a career liability.
Re:Criticism should be handled delicately... (Score:4, Interesting)
Re:You don't (Score:5, Interesting)
What I am mostly hearing here is that the company lacks things like basic code reviews or any kind standards. I cannot imagine how this guys boss is ok with checkins like what the poster is describing. This sort of thing would be caught at any half way decent company.
Not necessarily. I worked with someone that directly fit this description. I've never seen OOP abused so badly in my life (inheritance and polymorphism that was either the product of a genius obfuscating their code.. or an idiot that knows of such ideas, insists on using them, but has no clue as to the right time and place to use them). He was able to sneak by most code reviews because he was often working solo on products that were borderline legacy. With few bugs apparent at the user level his slow progress was put up with for the mostly "reliable" code. Then once some other people got pulled (such as myself) he got put under a microscope by his manager. This actually resulted in yelling matches. The code was truly horrible. At one point he had read that a function/method shouldn't have more than a few lines code. I found a method 9 calls deep, each method adding another argument that resulted in a call to a native API that could have been done at the top level (well excepting side effects along the way that did god knows what). We also coined the term "lilypadding" for some of his solutions. It was obvious he's jump directly into a problem without any real vision of the end goal or result. He'd eventually get to the end, but only after making many many jumps, often in the wrong direction (open file, read all of file, find line you need, read part of the file based on that line again despite having just read the entire file, do select * on a table in a loop while filtering in code, etc). It almost seemed he came upon a working solution by happenstance. I think part of it was the false ideal: if you aren't coding you aren't working. A 5 day solution for him would be 2 days planning and 1 coding for anyone else.
In the end his code was not maintainable or extensible. He refused to listen to the suggestions of his manager and change his code, insisting it was golden and the correct way to program (despite being provided plenty of evidence to the contrary). The guy would even get pompous when you request he fix his own check-ins (he would often leave his hacked up "testing" library in references, though his special proprietary library was not in the codebase, resulting in a project that would not build).
How'd management fix the issue in the end? They got rid of him. He got decent severance, and help seeking a new position. Part of me feels for the guy (and his family that relied on his wage), but part of me also wonders who's problem he is now.
How was it solved? They got rid of him.
Could he have been trained to be better? Maybe, but he didn't act willing to change and wasn't a good fit to the team or company attitude-wise. He'd do things like hang up on a customer because "it was his lunch time" even after being reprimanded for doing that previously. He claimed in "his culture" that's how they do things. When a bug is escalated directly to the responsible programmer from a customer, you put your lunch off for 15 minutes, you don't say, "Oh it's lunch.. bye." And we're not talking a slave driving culture, he was free to take his lunch whenever and any overtime would be balanced by time off. It was simply a matter of treating the customer well in a sensitive situation which he couldn't wrap his thick skull around.
If a company isn't willing to take care of time wasting employees, that don't fit the company culture.. I'd leave. It's not your problem to take care. It's your job to make sure the issues are clear to management, and it's fair for them to request you help guide him/her to being more productive in the company, but it's not your job nor place to try to fix it.
Re:You don't (Score:5, Interesting)
So IMHO not really your "fault" that you can't pick up the kernel design in an afternoon by skimming the code, it's the coder's job to clearly explain the implementation, not the design.To paraphrase an old friend of mine, "Source code is like shit, you can't smell your own". Even if the code was written by Shakespeare, browsing code is still the hard way to pick up the design of a non-trivial application, but if your not surrounded by co-workers who wrote it then it's often the only way available.
Trivia: I used to teach C to second year engineering and CS students in the early 90's. The engineers were the worst for writing the entire thing in main() because they already had leaned bad habits from elsewhere. Each year most of them would fail the first assignment and then complain about the harshness of the assessment, one they knew I was serious about my style sheet most of them would do much better on the second and subsequent assignments. I wonder how many of them now understand why their code's comments and style were worth a full 50% of their mark.
Re:You don't (Score:4, Interesting)
Re:You don't (Score:5, Interesting)
Great story. I've never had trouble understanding code I wrote. That's probably because I have one of the world's worst memories, so I always write code with lots of clues to help me decipher what's going on. Also, I got lucky when a programmer from industry taught a structured programming course. He was all about coding best practices. I learned the KISS rule from him, and have avoided clever obtuse code, when a straight forward solution will do. The analog designers I work with might disagree... I'm forcing us to use Python and classes, and you'd think I was murdering kittens from all the complaining. The reaction when I made us all use git... *shudder*
As for the poster's question, feel free to make some noise about his code, and see if it has any impact. Older coders like me rarely change much, but you might get him to adhere to a few team-wide coding guidelines, at least if he's not an analog designer. In a perfect world, you could help him find a better job, one where his coding issues would not be such a liability, and where whatever his real strengths are can come into play.
The best programmer, by far, I ever worked with is Ken McElvain, founder of Synplicity. If you need a problem solved quickly, and better than what all your competitors can do, he's your man. However, his code when I joined the company had some of the issues the poster mentioned, and that made me laugh. He's a very fast typist, but his typing speed is his limiting factor in coding, so he used 1 and 2 letter variables mostly. Writing code inline is faster to type than factoring out a bunch of small functions. Comments just slow him down. The first day working for him, I opened one of his most ingenious pieces of code (responsible for better 2-level logic optimization than what Synopsis had at the time), and tried to understand the 2,000 line file, which is tiny given the job it does. It's core is a brilliant 1,000 line function, and it took me all day to figure it out. I thought there had to be documentation somewhere, so I grep-ed the whole code base, all 350,000 lines of it, for comments. There was one. It said, "This is a hack." Many programmers, including me, will hold that his code is difficult to understand against him in the "best programmer" contest. He wins anyway. He knew that the most important reader of his code was himself, and that being as productive as possible early on was key for Synplicity's success. We were profitable, and had over 20 employees when I joined, yet I was the first programmer he hired. As the coding team grew, he started adding comments and using descriptive names. I heard a lot of complaints about working with some of his code, but he owned nearly 50% of Synplicity at the IPO, and everyone involved made money. Go ask his investors what they think of his coding ability. Anyway, if this co-worker is so smart and experienced, I'm not convinced hes a "bad" programmer. Maybe he just needs a job where he's the right guy.
Re:You don't (Score:5, Interesting)
Sounds like the problem can more readily be resolved by two levels of coders. The creators who produce the original lot and make sure it runs and then editors who tidy and pretty it all up and make in more informative. In fact lots of people who are not very successful at creating new code, can be quite good editors. Cleaning up code, resolving the last few bugs, better variable and class names, more comments, breaking up functions etc. They do it for writers in order to speed publication. The same might be considered suitable for coding and with ready access to the original coder to provide explanation over any more convoluted high quality easy to maintain code could be more readily and quickly produced.
Re:You don't (Score:2, Interesting)
This is actually why I love working with Python code. The design of the language means that it actually requires talent to write unreadable code and as long as someone uses sensible symbols (variable/class/function names) and avoids getting too carried away with things like Lambdas and the like, you can almost always read an experts code and a beginners code with about the same difficulty level. Good python can by explained to your boss, the language is designed for that shit, and if respected in that spirit its a fantastic, and honestly if the server takes a bit of a performance hit, the costs are more than offset by significantly reduced labor costs.
I've been coding nearly 20 years, and I've come to decide I value readability over cleverness. If I have to keep a copy of bruce fowlers pattern book beside me, or a pen and paper to decode some hideous logical nest of conditional craziness , I can only conclude the coder needs to simplify his shit because he's wasting my old-ass time working it out.
Now, combining readable AND concise, thats where the real skill is.
Re:You don't (Score:3, Interesting)
No it does'nt. But your comment shows your perception based on a complete lack of evidence.
If some fresh-out-of-college kid gave me a book on coding practices, I'd certainly not toss it in a trash-bin. But the kid would certainly be added to my list of arrogant piss-ants to be crushed at every juncture.
While it may be possible this kid isn't exagerating. It's also highly likely the kid hasn't seen all his code. Code which might complie extremely compact. Compilers are very good at optimizations these days. But since the kid gives no reference of this guy's history, we have no clue whether he's an old mainframe coder, or some guy who worked his way from sales to coding.
God is in the details.
I once worked with a guy, that we all thought was the worst coder in our group. When he left and me and one other coder were all that was left of the entire department, I found out the guy had some really brilliant code in some places. He was very slow, but his shitty looking code was all rock solid and bug free. Really bug free, and he had some really complex code that I've learned from. Granted he got most of that stuff from books.
The kid here mentions nothing about code reliability or speed of operation. So, the kid has already shown himself to be less than competent in my book, and having an ego problem. But, hey, maybe I'm drawing conclusions with insufficient facts.
I should add, that I have had to explain my code to others from time to time. I have written "entire programs" in a single function (usually very small and compact and mostly used for testing code, data cleansing, internal tests, etc) . I have written programs in a single line (just to prove it could be done). I have written production programs in single functions, in advanced 4G languages covering hundreds of lines, because that is the way the language is designed to be written and used (MAPPER "runs"). I have used OOP in very ipmproper ways. I personally hate OOP, because of the terrible overhead. Anything you could write in OOP, I could write in procedural form, that is just as reusable, briefer, faster, and easier to understand and maintain. That said, when I'm lazy, I'll just use OOP the way it was meant to be, when appropriate to be used. So the kid just didn't give enough detail to draw any relevant answers, and it likely isn't his place to bring it up.