This question exists because it has historical significance, but it is not considered a good, on-topic question for this site, so please do not use it as evidence that you can ask similar questions here. This question and its answers are frozen and cannot be changed. More info: help center.

As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
If this question can be reworded to fit the rules in the help center, please edit the question.

3

Because said person does not accept answers on a programming-related webpage. Kidding :-)
–
DanielSep 20 '10 at 23:55

@PSU well said. Just like any craft, programmers are tradesmen and are not perfect, always learning but if you fail to learn from mistakes you are not improving at your craft.
–
ChrisSep 15 '10 at 13:23

2

That's a very broad definition; it is not limited to programmers. It applies to scientists, cooks, sportsmen, translators, janitors, photographers, and really any profession.
–
RegDwightSep 15 '10 at 21:16

*and has been coding in that technology for a while
–
Joe PhilllipsSep 15 '10 at 16:00

5

This would apply to almost all the programmers who have ever done some web development with frameworks like Java/Spring or Ruby on Rails. Those frameworks are full of black magic that normal programmers usually do not bother to understand.
–
missingfaktorSep 15 '10 at 17:56

3

@Missing Faktor - and hence, it wouldn't be that inaccurate to say that most programmers who do that, aren't great programmers :)
–
seanmonstarSep 15 '10 at 19:12

14

Then again, it's unrealistic to assume that programmers should fully understand the inner workings of the framework, virtual machine or whatever they're building code on. (Or, indeed, details of all the layers of abstraction below, until bare metal is reached.) You can be a perfectly good, productive programmer even if you know just the most relevant parts.
–
JonikSep 16 '10 at 14:11

4

@Missing Faktor: they might not understand the internals of the libraries and frameworks that they use precisely, but they should at least know what each thing in their code is for: "to snark the frobber", "because the documentation says that this is needed to preserve the integrity of the space-time continuum", etc.
–
SamBSep 21 '10 at 18:42

I think there could be some beginners with potential to be good programmers -- who have trouble with it.
–
JD IsaacksSep 15 '10 at 13:35

2

Beginners are fine if you are looking for junior programmer who you intend to mold and shape into a good one. But that problem is so trivial, it shouldn't take anyone with experience any time at all to write.
–
Matt DiTrolioSep 15 '10 at 13:54

8

I would argue that it shouldn't take anyone who successfully finished an entry level programming course a lot of time to solve this.
–
EpsilonVectorSep 15 '10 at 14:36

4

If a beginner can't solve FizzBuzz, s/he shouldn't be applying for programming jobs. If you claim to be able to program (eg. by applying for a programming job), you should be able to solve FizzBuzz.
–
Chinmay KanchiSep 15 '10 at 16:19

Most metrics are awful, and LOC metrics are usually more the useless. The point here is that a bad programmer is someone who creates more work for the team than hes/she completes.
–
danivovichSep 15 '10 at 17:52

5

LOC metrics aren't useless. They are HARMFUL. Besides, LOC counting is very difficult in most modern languages. But, the metric isn't the point here. It's just saying |Work to create| - |Work that was wrong| - |work to fix|... i.e. if it took you 10 hours of which time you spent 6 hours working on something that ultimately had to be fixed and took 6 more hours to do that, then you're -2 hours. Time is really what you're trying to get at anyway.
–
MIASep 16 '10 at 1:46

1

LOC metrics are a great way of measuring how many places bugs have to hide in.
–
SamBSep 16 '10 at 20:35

Personally I think that any programmer who can look at their own code that they wrote a while ago and not find something wrong with it is not a good one. "A while" can scale with experience... I'd say between a few weeks up to a year or so.

When I was a team leader in a smallish shop, there were several folks who I had to have reassigned (neither I or my direct supervisor had termination capability without a ton of Red Tape and a pile of documentation.) or to have no contract renewal at the end of the current engagement. Some of the types enumerated also worked for other team leaders, and they pretty much took the same view.
Things which took folks into the "Bad Programmer" category in my book:

Untrainable or Ossified in the past
When the 'programmer' doesn't seem to be able to absorb the new system, new tool or whatever is being deployed, no matter how the training/education is done. Has to repeat said training on a frequent basis.
When the 'programmer' only knows the technology or coding paradigm that they used 10 or 15 years ago. It was good enough then, so why should they change?

Cowboy coder
The person who codes first, without a plan. The 'programmer' who makes untested changes to the production code and/or data "because we gotta get it fixed now" and then is surprised when the "fix" fails.
The Cowboy is also most definitely not a team player. Doesn't need no stinkin' team.

The weather-vane
This 'programmer' is enamored with the "technology du jour" and sees every new framework, language, methodology or whatever is new and hot as the

The "Big Brain"
This 'programmer' is so sure of his talent and capabilities that things are done which don't make a lot of project sense. e.g. Rewriting a standard library "because it is inefficient for our system" or introducing tools and techniques not suitable for the problem at hand. e.g. Introducing Lisp or Forth in a mainframe environment.

LOC a. Sandbagger
This 'programmer' uses obfuscation and mis-direction to increase the a. LOC: Lines of Code that get paid for. I have seen code in this situation that was was page after page, screen after screen of duplicate structure and logic, with only the paragraph or control variable names changed to pump up the line count.

Indispensable Expert
The 'programmer' who has the domain knowledge to solve the problems at hand, but since they "know" everything about it. As a matter of fact, if they were to be hit by a bus, then the whole organization would come crashing down. {Observation: Those who think they are indispensable usually are. (Anyone got the source on this aphorism?)}

The Pasta Chef
This 'programmer' specializes in spaghetti code, spiced with identifiers that are just too hard to follow without a syntactically implemented IDE. e.g. IndexI1O0, Index1I0O, etc.

Summer Intern - Specifically subtype Walking Disaster
My old shop used to hire a number of late high school or college age interns. One time a department needed a small database to track some equipment usage, (now this was waay back, and it was using dBase III). The guy coded along all summer, but was not done when college started in the fall. He got a one week extension then a second week. At the end of the second week, I got sent out to take his project over and bring it back in to Systems Development to be finished. He showed me the stuff he had done, and then the unfinished part. What worked had nice eye candy, but the application was incomplete. When I opened the new box of formatted floppies to get copies, he said, "just a second, let me delete my test files..." and before I could say anything, he'd deleted a bunch of files.
Being the suspicious sort, and finding that his application was almost nothing but eye candy when I got back to my shop, I went back to the department and pulled out Norton and undeleted the files he'd deleted, trying to find some additional logic, even if incomplete.
I found, not bad logic, but bad behavior. The printer attached to the PC he was using was a daisy wheel printer. The character set normally mounted was a swiss variant. The output of the deleted programs put out a name, address, DOB, some letter codes and some type of id number. The format and layout bothered me. All the birth dates for multiple people were barely legal drinking age. Most of the addresses were not there, when I looked them up in our criss-cross directory. When I showed the printouts to his supervisor, he looked at me and said "Driver's licenses, don't you think?" I said I did so. He said that was why he'd found the transparency stock all cut up in the trash next to the Xerox. Our bad boy had made overlays to adjust his and and his friends ages on their drivers licenses. We reported it to the authorities. He was not paid for his last two weeks.

I don't remember exactly how I implemented things that I programmed last week. Is this uncommon? I was under the impression that working with finite human memory was just one of challenges of programming. Hence, the importance of structuring and documenting code so that I don't need to remember details.
–
JamesSep 15 '10 at 16:57

A big warning sign in my experience is when they don't comment their hacks....

You know what I mean: when you're forced to do something very hacky because there is simply no better way to do it.

Good programmers will hate having to do it and put in inline comments saying how much they hate putting in that kind of hack, but there is no choice. Bad programmers will just put in the hack and not comment it.

Quiet obviously when a programmer writes A LOT of code. Very large functions, maybe copy/paste lines or code blocks, using way more ifs then necessary, etc. This could be because the programmer doesnt know a standard function to do what he wants but much of the time it isnt.

I am moving my answer to here from a closed duplicate topic that asked Can you recognise if you are a bad programmer? The other topic was being closed as I was composing my response. My answer more directly addresses the question as it was phrased by the other asker and will read better if you understand that.

Sigh! Part of me didn't want to add to this already busy topic, but the other part of me won! Why did it win; why am I bothering to add yet more words to this particular multilogue? Well, because, to some degree, I may have a slightly different take on this than the many previous commentators.

Binary works great in computers: it's '1' or '0', "on" or "off." We can abstract and encode a lot of information using those famous two states. But, it doesn't tend to work so well for human matters: "good" or "bad," "sane" or "insane," "good" or "evil," "smart" or "stupid," "fat" or "thin," "alive" or "dead?" These kinds of polarized evaluations have always left the caring human being part of me terribly unsatisfied. By whatever measurement schemes I choose to apply, I usually find that the answers to such stark contrasts actually lie somewhere along a continuum between one such pole and the other, not at either end.

I have fought with this tendency towards polarization for quite some time, now, and my personal solution is that I find it far more useful to apply three words to any such evaluation: "to what degree!"

So, my answer to your question is to suggest that you rephrase it and to ask yourself this: "To what degree am I a bad programmer?" Or, even better, to ask it in the other direction: "To what degree am I a good programmer?" If you pursue truth, you will probably locate yourself somewhere along a continuum between being a "bad" programmer and a "good" one. Then, once you manage to locate approximately where you are along this path, you can probably identify a point somewhat closer to the "good" end—a point where you would like to find yourself in the near future.

If you do not set that point too far away, you can probably get your hind end in gear and start moving it in that direction. If you manage to iterate this rather simple heuristic algorithm several times, you may soon find yourself too busy programming to need to ask this question again! Oh, and you'll probably make faster progress if you start pounding code on a keyboard as quickly and often as you can; and, if you take a little break now and then, read some high quality code written by your peers! In these days of dynamic Open Source development, you have no shortage of free and exquisite code to learn from!

So, I strongly recommend to you that you try my three little words, "to what degree," and see how far in a good direction they can take you!

In my opinion it's all about problem solving, the tool should be far less relevant than actually getting work done. If I've got to solve it using MS-Access or assembly language, it's a matter of time and money, not a matter of "It can't be done"

A warning sign is too much focus on the academic and "proper" way of doing things, and not enough focus on getting work done.

So, how about solving a halting problem? Can it be done?
–
Pavel ShvedSep 15 '10 at 14:45

2

It's bad to dismiss something as impossible if it's not and vice versa.
–
Randall SchulzSep 15 '10 at 14:58

2

@Randall Schulz: As far as I can tell from craigslist, a rock star programmer is someone who handles all tiers of development (database, user experience, deployment, sysadmin and user support) at an ad agency for significantly less than the normal wage for one of those things. They call them rock stars because after 60 hours a week of this, their diet is similar to someone who tours in an econoline van and has to pawn their guitars for food.
–
Dan MonegoSep 15 '10 at 18:58

1

Yeah, I made a sweeping generalization :), but.. it was to make a point. "My professional opinion is that it shouldn't be done" is better. Even better "What about solving the same problem in a different way". My point is a good programmer should be solution focused. "It can't be done", without offering options is very frustrating to the client.
–
Dan WilliamsSep 22 '10 at 20:39

Those who don't know principles such as SOLID, DRY, OOP and so on. It's important to have good understanding of programming principles and foundations rather than knowing specific technologies. Those with solid foundation will be able to learn new topics easily and will produce better code.

One thing that distinguishes a bad programmer from a newbie programmers is stubborn insistence on implementing their favorite system in whatever language and API they are working in.

I once inherited a system where the prior developer re-implemented (in Java) a large set of the Ashton Tate DBase III+ api layered on top of custom dbf access library. None of the Java collections framework was used.

This was so he could write a Java/swing app that looked and acted like a DBase III+ (or possibly clipper) app.

The Apps he wrote in this system had lite-bar menus and would open a full window form with a row of buttons on the bottom when you navigated the lite-bar to the option. It was like a little time machine back to the 1980s.

The man was clearly a skilled developer. He knew enough that he was able to write that whole system himself in the time frame of that project. He was also able to re-use it on a few other internal systems.

But he was an awful programmer in that his code misused the features of the systems he worked on. He was more willing to spend 3 months on a custom lib of dubious benefit than learn Java/Swing/SQL.