I have an anecdote that might be useful:

A few years ago I was coding at a small startup. Everybody was pretty solid. Then they brought on a new engineer who was very comfortable with a certain framework...but ONLY that framework. One day, in a product planning meeting, we were discussing a new feature we wanted to build. It fell in the new person's domain, so we asked them to give a rough estimate of how much time it would take. Their response?

"It can't be done in this framework. There's no existing module or extension for that".

We all sat back in silence. Eventually someone said what we were all thinking: "We hired you to write code, not install plugins and extensions. Do you actually know how to write any code?"

The new hire left the company soon after. To me, the glaring problem here wasn't that they had aligned their process with a certain framework... it was that they had then closed their mind to other options. They only thought within the framework, and so had nothing creative to actually contribute to the team.

I don't mind slow programmers, or programmers who know when a problem is too difficult for them, or programmers who ask too many questions and need constant confirmation and hand-holding. They are a bit annoying, granted, but harmless, and can be a somewhat valuable addition to your team if you give them the right tasks. Often these guys can do grunt work at reasonable quality.

The worst ones are those that know just enough to be dangerous, and who think they know everything. Instead of asking, they make assumptions, and produce code that almost works. Meaning, it will pass most of the obvious test cases, but breaks as soon as it hits production.

Example: One guy had to add a meta tag to a web page, with the page's publish date in ISO format. Instead of using the source data, which had the date as a DateTime object, he parsed the date from the formatted page output. This worked for US pages, and European pages where the day of the month was <= 12 (because of the different order of day and month), but broke as soon as the displayed string was impossible to parse. Ugh. Any half-decent programmer would wonder, "there must a better way to do this?"

- Gets in the way

- Doesn't admit to being wrong

- Full of it

- Blindly follows/enforces patterns, standards, and best practices

- Constantly tries to draw attention to themselves

- Political

- Code is sloppy, poorly thought out, bug-ridden, and often doesn't work

- Obsessed with time, documentation, meetings, best practices, patterns, testing, and everything else that doesn't matter (not with finishing in a timely manner, writing documentation if necessary, etc, but with constantly using these things as an excuse to get in the way, to excuse their sloppy work, and as a means to insult the ability of other developers and to claim themselves to therefore be the ones that know what they are doing).

Sounds more like a bad employee.

Note: I will say everything below with the context that you are talking about programmer working for businesses.

Good and Bad are very relative words. To apply these to a programmer, let us analyze.

I would say start with this question: What is the Goal of a programmer ? Is it to write great code OR is it to help a business succeed by creating things of value OR both OR something else ?

If the goal is to just write great code, then do they need to write great code along with others ? Or are they ok to write great code just by themselves ? If the answer is that they need to be able to write great code with others in collaboration, then you have your first point covered which is "personality" or I would say "Attitude". If you cannot work well with others, you are bad programmer.

Now, if the goal is to create value and help a business succeed, then does it matter if the code you write is technically the greatest ? Perhaps not; other than the fact it personally is very fulfilling. Gotta love that feeling when that thing compiles!! But the real question to ask is: can I get the patch the system quickly if the code fails or the system crashes ? If yes, then you are a good programmer.

If the business team comes to you for advice on doing something technically that could help them increase revenue but may not be the best technical solution at this time, you are a good programmer if you can make that happen. You are a bad programmer if you tell them you don't want to do it.

That takes to the other point about "passion". I would say that Passion may be an overused word but it should be more about "Do I like doing what I do even though I am not crazily obsessed with it" ? If yes, then you are a good programmer. Why ? Because if you enjoy what you do, you will do it better (most likely)

The last point "Tech Debt". It is again relative. Tech debt for what ? If my company is not making any money and I need to put food on the table, does tech debt matter ? Or does it matter that I need to get paying clients first and worry about the tech issues later. That is a good programmer who can manage this tech debt depending on the situation of the company. Oh but they don't have any documentation in the code, I hate it. Ok then fix it keeping the business goals in mind. If you have the time to do it and still create positive outcome for the business, then that is a good programmer.

Everyone else is a bad programmer.

Someone who writes bad code. I don't like the expression "bad programmer" I prefer to say someone who is programming badly. Because that makes it clear that it is the action that is bad and the badness isn't inherent in the character.

If your next question is "How do you know if someone writes bad code?" then it is fairly simple for an experienced programmer to see if a piece of code is bad, good or somewhere in between.

For lots of amusing true stories of bad programers and the havoc they cause, see http://thedailywtf.com

"Founded in 2004 by Alex Papadimoulis, The Daily WTF is your how-not-to guide for developing software. We recount tales of disastrous development, from project management gone spectacularly bad to inexplicable coding choices."

Anyone who thinks or acts like they're the most important asset to the organisation.

Applies generally in all walks of life, in most situations. I've seen it in programming, and I've seen the mess that's left when people ignore that problem for too long.

The only bad programmers I know are those who over promise and under delivers.

If a programmer week after week on project after project says he will do x, y and z and next week he did G then it ruins the team because nobody knows what to believe and what to count on.

Verde Technologies was an aerial photograph firm that used the Streamed Image Transformation Editor (SITE) to process digital framegrabs on Sun 3/160 workstations. Each cost about $40,000.00.

We required about 90 seconds for each step of our calibration process. There were several steps per image, we shot many images each day and promised our clients 24-hour turnaround.

So Scott Lydiard, the company president spent $5,000.00 on a Floating Point Accellerator card, as Sun promised that it doubled the speed of numeric code. It was a full-size VME bus card with a 68881 in the middle. I'm not real clear why it needed that much circuitry as Macs just had a single socket where you could pop in a 68881, much like the 8087 socket on DOS PCs.

So one night I install our new card. To my dismay the calibration time was reducing only to 85 seconds.

Not wanting to lose my job I discovered just that night what a profiler was. It turned out that SITE used getc() to read each pixel of an image, and putc() to write it. This because the "streamed" part was meant for building UNIX pipelines. You know simple tools that only do one thing.

I patched the code to read all the pixels in one read() system call.

"Hey Mike. Our new FPA is AWESOME! Only five seconds to calibrate an image."

"You made a wise purchase, Scott."

Then a few minutes later...

"Mike, could you explain why calibration now takes ten seconds on the workstation that doesn't have an FPA?"

"That's because it really does double the speed of numerical code."

SITE was written by a computer science graduate student. It is for this and many similar reasons that I don't regard a CS degree as being of much use to computer programmers. Mine is in Physics; among other things, Physicists figure out the way things work.

getc should in fact be reading all pixels in a single read() under the hood, and just pulling characters from a buffer. ISO C stdio streams are fully buffered, when not connected to interactive devices. Moreover, getc is often a macro which inlines the code of pulling a character out of the stream's buffer and updating a pointer, triggering the refill as needed. In my experience, using getc is usually not too terrible compared to writing buffering code to do the same thing. (I certainly wouldn't say someone was a bad programmer or academic for writing the code around getc. On the other hand, if they assigned the return value of getc to a char typed variable, I'd have a different opinion! :)

We once had a developer that kept clobbering changes of our main git branch. We had meeting after meeting where our manager taught us the correct way to do things, yet it kept happening..for almost 3 months.

I blame management as much as the developer for not getting things figured out asap, but I did get paid for those 3 months for essentially fixing the same bugs over and over.