Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

How would you consider that a programmer is bad at what he or she is doing?

If possible... How should he/she improve?


locked by World Engineer Jun 26 '13 at 14:00

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.

closed as not constructive by ChrisF Feb 21 '12 at 23:39

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.

Because said person does not accept answers on a programming-related webpage. Kidding :-) – Daniel Sep 20 '10 at 23:55
@EvanKroske: No, that's not right.... Community Wiki exists to allow collaborate editing of posts. See also: Our Meta - Tag: community-wiki – Tom Wijsman Oct 7 '10 at 10:21
In a lot of questions, it's impossible to accept a single answer. See also: Our Meta - Search: accept – Tom Wijsman Oct 7 '10 at 10:24
Not every question gets an answer that actually addresses the problem. – Loren Pechtel Oct 17 '10 at 19:14

34 Answers 34

up vote 134 down vote accepted

When they fail to learn from their mistakes and from peer reviews.

We are all green at some point; however, if you're not getting better or attempting to get better then you're a bad programmer.

Agreed - you've got to have a feedback loop, always learning from your mistakes. – Marcel Lamothe Sep 15 '10 at 12:36
@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. – Chris Sep 15 '10 at 13:23
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. – RegDwight Sep 15 '10 at 21:16
Everyone's a moron at least once a week. – MIA Sep 16 '10 at 1:39
@RegDwight: and your point was ... ? – SamB Sep 16 '10 at 19:57

A programmer who doesn't know what he doesn't know and isn't interested at all to find out.

If I could upvote this 100x, I would. A little humility and a hunger to learn makes up for a lot in the long run. – William Pietri Sep 15 '10 at 18:11
+1 for Ngu and William too. This is the most typical criteria of a bad "programmer". – fabrik Sep 16 '10 at 12:23
What happens when you know that you don't know a LOT and as hard as you try, you'll never know most of it? – Steve Evers Oct 13 '10 at 19:47
@snOrfus, you locate a mentor to teach you... – user1249 Oct 17 '10 at 14:32

A big warning sign is if they are a "cargo cult" programmer - meaning they do things but don't know why they do those things (it's just "magic"). Great post by Eric Lippert here.

From the article:

programmers who understand what the code does, but not how it does it.
*and has been coding in that technology for a while – Joe Philllips Sep 15 '10 at 16:00
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. – missingfaktor Sep 15 '10 at 17:56
@Missing Faktor - and hence, it wouldn't be that inaccurate to say that most programmers who do that, aren't great programmers :) – seanmonstar Sep 15 '10 at 19:12
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. – Jonik Sep 16 '10 at 14:11
@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. – SamB Sep 21 '10 at 18:42

A big tip-off for me is when they ask you or the other programmers development questions that clearly show they have made absolutely zero effort to figure it out on their own.

A corollary is when they ask the same programming question multiple times indicating they aren't internalizing the information.

Ah yes, I worked with him. Past tense, fortunately. – Mike Woodhouse Oct 17 '10 at 19:55
Some aren't even able to form decent questions, asking you to "just fix it" – deltreme Oct 18 '10 at 13:43

When it takes them a long time to solve the FizzBuzz problem.

I think there could be some beginners with potential to be good programmers -- who have trouble with it. – JD Isaacks Sep 15 '10 at 13:35
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 DiTrolio Sep 15 '10 at 13:54
I would argue that it shouldn't take anyone who successfully finished an entry level programming course a lot of time to solve this. – EpsilonVector Sep 15 '10 at 14:36
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 Kanchi Sep 15 '10 at 16:19
Stackoverflow question on FizzBuzz is well worth a look. Check out the python solution that doesn't use division or modulus.… – Gordon Sep 17 '10 at 19:12

Programmers who refuse to learn new technologies/languages, and insist on sticking to what they already know.

Addendum: (adding what dash said below in the comments)

An extension of this is people who know a subset of the functionality of some technology but show no desire to learn anything more about it. Programming language, editor, other tools...

...and for no good reasons, I should add. – missingfaktor Sep 15 '10 at 17:44

When a team member is the negative producing developer.

|# Lines Written| - |# Lines of bugs introduced| - |# Lines of rework required| < 0

Meaning the rest of your team has to do more work because of the bad developer. NNPP

I agree - these people can be extremely damaging to their team. – Marcel Lamothe Sep 15 '10 at 12:35
Huh...I've removed 500 lines of redundant code yesterday, and didn't introduce bugs. LOC Metrics Considered Harmful? – Piskvor Sep 15 '10 at 13:06
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. – danivovich Sep 15 '10 at 17:52
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. – MIA Sep 16 '10 at 1:46
LOC metrics are a great way of measuring how many places bugs have to hide in. – SamB Sep 16 '10 at 20:35

When they produce things which belng on The Daily WTF on a regular basis.


When they know there are better ways of doing things but still refuse to do them even when time permits.

But there could be expert disagreements about what's "better". – DarenW Oct 9 '10 at 0:19
@DarenW - I wouldn't say someone is a bad programmer because they took a side on a controversial topic, but when they have a definitive choice in their own mind. – JeffO Oct 9 '10 at 13:12

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.

What if they can't find anything wrong, and that worries them? – SamB Sep 16 '10 at 20:39
Or worse, they can't find anything wrong and try to fix it. – Toon Krijthe Sep 18 '10 at 13:03

Those who ignore warnings on their codes and cares only on errors.


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:

  1. 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?
  2. 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.
  3. 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
  4. 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.
  5. 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.
  6. 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?)}
  7. 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.
  8. 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.

These are just some of the bad characters I have had to work with....

/s/ BezantSoft

RE "Those who think they are indispensable usually are" kind of reminds me of – DaveDev Sep 26 '10 at 0:40

Unable to adapt themselves to upcoming technologies


Apart from the obvious lack of knowledge/ability, a programmer is a bad one, if their code is harder to read and/or maintain than it should be.

And the programmer is a really bad one when he can't read a code well written :-) – bigown Sep 15 '10 at 22:06
Wouldn't this be almost everyone? I mean, isn't code nearly always harder to read and/or maintain than it should be? – SamB Sep 16 '10 at 20:38
Nope. Code is always easier to write than read. But I've had to maintain some very well written code that reduced this pain as much as possible. – Chinmay Kanchi Sep 17 '10 at 10:22

When nobody else can read his code. It doesn't matter how bright you are; no programmer is an island.

Well, if he's writing in Unlambda, nobody should be able to read it. – SamB Sep 21 '10 at 18:45
Also, when a programmer takes very little time to do something initially and then a lot of time to do some customization on that. I have often seen this happens because the programmer mostly copy pastes code (that's why fast in the beginning), but then takes lot of time because it is difficult (even for good programmers) to alter it from there because of the absence of the intent to write customizable code in the beginning. – Sandeepan Nath Jan 1 '11 at 9:34

Someone who does not pay attention to the details and is always in "it works, so I'm leaving it alone. All those exceptions in the logs don't matter" mode.


There are two categories for programmers for me - solo and team.

Bad solo programmers are

  • Those who took too long to get the simple task done.
  • Those who can't research by themselves for what they are doing.
  • Those who will forget what has been coded today within few days and can't maintain his own code base very well.
  • Those who can't adapt to the requirement changes.

Bad team programmers are those who falls into bad solo programmers category, including

  • Those who can't coordinate with other team members.
  • Those who don't welcome criticism.
  • Those who don't know how to be useful to others, and how to benefit from other team members.
  • Those who can't write readable code.
  • Those who don't comment for the sake of readability to the others.
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. – James Sep 15 '10 at 16:57
@James Please excuse my English ;). I mean that if a programmer come back to look at his/her code few days later and have no clues at all, that's a bad sign. I also don't remember how and what exactly I have done few days ago, but I'm sure I don't have to scratch my head when looking at my own code and say 'what was I thinking?' – tia Sep 15 '10 at 18:50
@James: Exactly, he should document his code so that it doesn't matter that he forgot how half of it works – SamB Sep 21 '10 at 21:33

Not willing to admit they don't know the answer and/or unwilling to look things up.

If you don't know it, don't give up - figure it out and get it done.


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.


Being repreategly shown the right way to do it, and repeatedly just doing it the easy way.


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!


Someone who says "It can't be done".

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.

And when he says why it can be done? – bigown Sep 15 '10 at 14:14
So, how about solving a halting problem? Can it be done? – Pavel Shved Sep 15 '10 at 14:45
It's bad to dismiss something as impossible if it's not and vice versa. – Randall Schulz Sep 15 '10 at 14:58
@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 Monego Sep 15 '10 at 18:58
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 Williams Sep 22 '10 at 20:39

If he only knows the syntax of a language but don't know the basic concepts of algorithms.


When they do a lot of pontificating but produce very little.


!(smart and gets things done)

== stupid or not able to get anything done ;-). – Toon Krijthe Sep 18 '10 at 13:05

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.


An embedded programmer that doesn't understand interrupts very well or multitasking. Also programmers that need to work with bit fields but don't grasp logical operations on them and shifting.


An immediate recognition signal is someone saying: "I don't understand why it doesn't work. I did everything right."

Followed closely by "I don't understand why that works, it's not right." – Randall Schulz Sep 21 '10 at 0:45
Yeah, it's the computer that's stupid :) – Dan Williams Sep 22 '10 at 20:41

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.


Not the answer you're looking for? Browse other questions tagged or ask your own question.