What makes a Bad Programmer?

I've been spending quite a bit of time with the First Year students this week. They're presently grappling with the "Space Cheese Mining" coursework which is a silly board game loosely based on Snakes and Ladders but with a few twists. And some cheese. 

Anyhoo, I was telling one student that I didn't allow First Years to tell me they were bad programmers. "That's my job" I said. The point I was going for is that one of the problems people have when learning to program is that they lack confidence in the code that they write. Sometimes they worry that they might not have found the "best" solution.

It turns out that some things are just hard to deal with, and require fiddly bits of code no matter how you approach them. So your code ends up looking a mess, and that's just the way it is. Snag is, when you are learning to program you don't necessarily get this, and you might worry that your program looks messy because you can't actually write code. So I always say that I'll be the judge of bad and good code, 'cos I've been writing programs for some time. 

We talked it through a while and then the student asked a really tough question "So, what makes a bad programmer then?" Ugh. Wasn't expecting that one. I didn't really have a ready answer. I muttered about bad coding style, not testing code, etc etc and that was that. 

Having thought about it some more though, I reckon I was wrong. I now think  a bad programmer is someone you don't want to work with.  They might write code that nobody can understand. They might refuse to test their solutions. They might refuse to believe that there is a problem with something they have written. They might not buy their round in the pub. They might get into fights with the customer. And they might enjoy telling you about bugs in your code rather too much.

Technical ability will get you so far in this business, but if you aren't good to work with this is going to hold you back in the long run.