Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free.

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

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

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

Today, many programmers believe that this complexity is best managed by using only a small set of well-understood techniques in their programs. They have composed strict rules about the form programs should have, and the more zealous among them will denounce those who break these rules as bad programmers


A programmer who just copies and pastes code from other places, and doesn't understand how the code actually works, is known as a bad programmer! I typically see this with javascript.


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!


When starting a Quality Improvement program and somebody's first suggestion for how we could most dramatically improve quality is to "fire Vito", then Vito is a bad programmer.

True Story. Vito was fired. He was beyond bad, venturing far into unethical while bordering on illegal.


I think that the only way a programmer can be bad at programming is if he stops listening to what other people have to say.

Programming is about information. One needs to keep the ears, and eyes wide open.

A programmer can only improve by hitting the books, and working hard. But, you should also focus on learning new things, not learning the same over and over (look for new experiences inside your specific field/industry).

Good luck.


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

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.


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.


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


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


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.


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.


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.


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.


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


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.


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

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


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

!(smart and gets things done)


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


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.

Some aren't even able to form decent questions, asking you to "just fix it" – deltreme Oct 18 '10 at 13:43

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


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

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


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.


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

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