Bad Programmer

The BadProgrammer is the one who leaves a trail of destruction in his/her wake. Yes, this programmer has figured out how to make a three-hundred-line method called "get_stuff()" that has all sorts of nested try blocks, handles exceptions (all of them) by dropping them on the floor, and generally writes hard-to-understand BadCode.

Whoever wrote the comment "Call this function after you do foo, bar, or baz" is a BadProgrammer.

You've been called in to make "one minor change". This, of course, is unrealistic. You haven't read the entire program (it's 400 pages long) so you don't call this function after you did bar. It's not like there's a way to make this part of some API or calling convention; you would have the moral obligation to make everything use said API which is a monumental task.

Anyway, add your experiences.


Bad programmer! No pizza for you!


Quotes
BadProgrammers will be BadProgrammers in any language. I have a friend who will take your beautiful PythonLanguage and make it his bitch. This is not a boast on my part - I'm actually rather disturbed. My point is that writing code in PythonLanguage will not magically make my friend write beautiful code. -- JohnBeppu

I once knew someone who could write PDP-8 assembly language in any language. -- AndrewKoenig


We've all met (sometimes only through their code) bad programmers who did things like:


A rather good programmer I know had once (while working on some parser, late at night) written the following piece of code:
  for i=1 to 3
     switch on i
      case 1: ... break;
      case 2: ... break;
      case 3: ... break;
     end switch
  end for
Generally, this programmer makes quite good code; it's just that sometimes he loses something, and this is what happens. I'm sure he would have caught it in the morning, if he'd seen it again. -- AvivEyal


What bugs me about this is that these people got jobs billing themselves as C++ programmers. And didn't get fired for massive incompetence. I can't imagine any other industry when people without even the most rudimentary, basic knowledge of their trade are allowed to practice and make disasters day after day after day. [Politicians, maybe?] -- AlainPicard

Then your imagination is not as creative as reality. Quite a great number of people working in pretty much any field are pretty poor at it.

No, no, no ... there are no incompetent doctors, lawyers, judges, auto mechanics, waitresses, CEO's, or Wiki posters.

You appear to be massively incompetent, Alain, on several levels. Here's a clue: inability to imagine P != not P.

You must be being sarcastic...worked as a cook in college...there are many incompetent waitresses...

People naturally think that more experience means you are better at your job. This is not necessarily true in any job; in programming, the correlation is almost non-existent. PeopleWare empirically showed the weakness of this correlation.

No it didn't.

This should not be confused with the idea that experienced programmers are never better at their job. Experienced programmers can avoid traps that most rookies do. They are battle-scarred; they have found AntiPatterns and dealt with them on their own; they have stories to share. The 'DotBomb cemetery' is full of bright but naive young programmers.

You get experience when you are honest enough to interpret your failures. Too many programmers don't bother thinking about the reasons for a bug. "Bugs are just bad luck." Until the next bug correction in the production code, they just bury the facts under excuses. Reflection on our own work requires that we assess our limits, and it hurts.

There were 400 bugs reported.

It was good code.

Good code? How?

I got paid for it.

"in programming, the correlation is almost non-existent" -- Only an incompetent moron would believe this.


I wonder HowToImproveProgrammingSkills?
There is the occasional "bad because it's easier" programmer. See BadGolfer.

One of the best coders I ever knew was a notably BadProgrammer. We've all SeenThisPattern: he can write code faster than he can design it, so when he needs a the same operation done in fourteen different places, rather than write one function to handle all fourteen cases, he writes fourteen slightly different functions scattered about the code. Multiply this by the number of times he's done this and by the number of changes that have to be applied to each similar function, and you have a maintenance nightmare that can bring a project to its knees.

Mind you, this was in MicrosoftAccess, which sort of encourages this nonsense by its heavy reliance on CodeBehindTheForm. - JayOsako


EngineersShouldTestTheirOwnCode. An engineer who relies upon QA, other engineers, or customers to test their code is a BadProgrammer.

EngineersShouldHaveSomeoneElseTestTheirCode. An engineer who relies upon his own mistake-making brain to spot all of his mistakes, and considers it fully-tested if he doesn't happen to see any, is a BadProgrammer. Hence, PairProgramming, ContinuousIntegration, and CustomerTests...
Hey, It doesn't matter if I'm writing code or rewriting code. I get paid exactly the same!
Bugs are just bad luck. Until the next bug correction in the production code, they would just bury the facts under a lot of excuses.

Why would they bother burying facts under excuses if facts just result from bad luck? Which ultimately is bad: programmer, code, luck?

- Yes! I've found the bug: the report showed the same figures in 2001 and 2000 because the query object wasn't refreshed by a close, then open.

- Ah. Now, maybe we should think about how we could have prevented this bug.

- Impossible, testing wouldn't prevent this, because you must ask for the report for 2000, then for the report for 2001. This kind of request never happens.

- You are telling me that this bug couldn't have been trapped because the test case is just too rare to be worth the pain of executing it.

- Exactly.

- But the users just found it, and they were not testing anything, just using the feature.

- Yes, but if they use the report once in a session, then it works. Such a repeated request for a report, year 2000, then 2001 with absolutely correct result is not a critical to them.

- You seem to forget how they discovered the failure: they had to produce year reports because their dept is under an accounting audit.

- well, yeah...

- ...so how could we try to prevent the failure?

- Hmm, just by checking that every query object should be closed and re-opened before we use the results. Oh wait! We could put some code here: "if query.active then query.close;" and next, the "query.open".

- Don't you think that the problem happened just because this query object is a global?

- Uh?

- Your report() routine use many local variables but one global query object...

Then the discussion slips in generality and voilĂ : one hour spent in stupid arguments about "theory and practice", "here we're different" and so on.

I don't think there are bad programmers. Then you're an idiot. There's bad code (peta-tons of), which programmers are both frustrated with and ashamed of and try to cover with defensive behaviour: arrogance, irrelevance, confidence, and so on.


The worst programmer I ever knew was a good programmer. More likely you're stupid and incompetent to judge. I mean, his code was good. What made him the worst programmer I ever knew was stubbornness. He wrote the wrong thing, and never, ever turned back. He had a particular task that was daunting, so he met it with a dauntingly complex solution. One aspect of this solution was a new BASIC-like programming language (compiled to C via lex and yacc) that knew how to undo all of its commands at any time. It could receive an interrupt from the user that caused it to reverse execution back through commands, up and down the call stack, undoing everything along the way, until it reached a "stop back tracking" command. He spent months alone on it and the fact that it worked as well as it did is a tribute to his brilliance.

Unfortunately an exec saw it in an incomplete state and fell in love with it. Next thing he knew he had two weeks to deliver it. He tried his best to fix it up, but as soon as people started using it the bug reports started piling up. It had lots and lots of weird, non-deterministic bugs. They threw more people at it (that's when I came in), but in the end it drove him insane.

He stopped coming to work, stopped answering his phone. No one heard from him for weeks. I spoke with him months later and he said he just quit being a programmer. I spent a month trying to fix/figure out what the code was doing. I looked everywhere I could think of for information about languages designed to reverse execution direction. (All I found was a mailing list devoted to hypothetical CPUs with an unused mirror CPU that does the opposite of what the used CPU does, all so they can use transistors that are like electron see-saws instead of electron cliff divers, which would result in virtually no power consumption or heat, but conjures the spooky image of an evil negaverse lurking in the CPU running MicrosoftWord's evil twin... - Wouldn't that be Word's good twin? - anyway, back to my story.)

You must not have looked all that hard - see http://mindprod.com/article.html. Also, your friend sounds not so much like a good or bad programmer as a mentally disturbed programmer.

In the end I gave up and talked to my boss, who was a great programmer. I told him it looked like a year to make it bug free, with a chance that it was mathematically impossible. We argued until we came up with a stunningly simple solution to the daunting task: five C++ classes that knew how to serialize their history on a common stack. We took about a week to write and test it. It was a big hit with the customers because C++ experience looks much better on a resume than JBMRL (Joe Blow's Magical Reversible Language). Whether something looks good on a resume is the determinant of good or bad programming

I'm grateful for the lessons this episode taught me: Always argue, and when you hit a dead end, turn around.

How about the lesson that your views on what is impossible and how long it will take to achieve something aren't reliable?

See ReversibleLogic.

I once found the variable 'alanIsABastard' in code written by another. Unfortunately, I was quite clearly the Alan in question.

Why is that unfortunate?


Or just name all variables x, y, and z, or name them all after characters from LordOfTheRings.

I once had the pleasure of working with a guy who named all of his variables and functions after French towns. It wasn't a pretty sight. Slightly less bad, but still bad bad bad, and much too common: I worked with a programmer who abbreviated most variables to at most 4 characters. He chose them with purpose, but there's only so much you can do with 4 characters. So if he had a pointer, he'd call it p. If a function was working on a data byte, he'd call it d or b. A pointer to data might be pd or pb. It was common to see expressions like ta = ps->ld.t1 - q.t. When I had to call one of his functions, the API's of which were rarely documented, I'd stare at the 10 lines of it for about an hour. When I finally figured it out, I realized how graceful the logic was. He had a way of using simple, straightforward algorithms in powerful ways, the ways they were designed to be used. His code was like a great work of literature, written in ProtoSumerian?.

In a code review, I suggested to a colleague that his seven hundred line method should be broken up into smaller, easier-to-follow methods. He dutifully broke it up... into a chain of functions that called one another, passing a massive list of the function's local state as parameters to the next chunk of code, with sequential naming. doProcess -> doProcess2 -> doProcess3 -> doProcess4 -> doProcess5 -> (...). Even better, he didn't even return the values up the stack; all the results went into a global variable. This was in Python.


See BadCode, BadCodingStandards, WarningSignsOfBadProgramming, GruntProgrammer, BadGolfer, GoodProgrammer, GrandMasterProgrammer

EditText of this page (last edited November 19, 2014) or FindPage with title or text search