Tell me more ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.
up vote 58 down vote favorite
38

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

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

share|improve this question
3  
Because said person does not accept answers on a programming-related webpage. Kidding :-) – Daniel Sep 20 '10 at 23:55
1  
@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
show 2 more comments

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 specific 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, see the FAQ for guidance.

34 Answers

1 2
up vote 135 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.

share|improve this answer
4  
Agreed - you've got to have a feedback loop, always learning from your mistakes. – Marcel Lamothe Sep 15 '10 at 12:36
2  
+1 That's my #1 definition. – deceze Sep 15 '10 at 12:52
1  
@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
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. – RegDwight Sep 15 '10 at 21:16
13  
Everyone's a moron at least once a week. – MIA Sep 16 '10 at 1:39
show 2 more comments
up vote 76 down vote

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.
share|improve this answer
3  
*and has been coding in that technology for a while – Joe Philllips Sep 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. – missingfaktor Sep 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 :) – seanmonstar Sep 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. – Jonik Sep 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. – SamB Sep 21 '10 at 18:42
show 6 more comments
up vote 10 down vote

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.

share|improve this answer
1  
And the programmer is a really bad one when he can't read a code well written :-) – bigown Sep 15 '10 at 22:06
4  
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
show 1 more comment
up vote 18 down vote

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

share|improve this answer
1  
I agree - these people can be extremely damaging to their team. – Marcel Lamothe Sep 15 '10 at 12:35
44  
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
5  
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
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. – MIA Sep 16 '10 at 1:46
1  
LOC metrics are a great way of measuring how many places bugs have to hide in. – SamB Sep 16 '10 at 20:35
show 5 more comments
up vote 10 down vote

Unable to adapt themselves to upcoming technologies

share|improve this answer
up vote 21 down vote

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

share|improve this answer
1  
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
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 DiTrolio Sep 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. – EpsilonVector Sep 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 Kanchi Sep 15 '10 at 16:19
1  
Stackoverflow question on FizzBuzz is well worth a look. Check out the python solution that doesn't use division or modulus. stackoverflow.com/questions/437/… – Gordon Sep 17 '10 at 19:12
up vote 15 down vote

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

share|improve this answer
show 2 more comments
up vote 18 down vote

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

share|improve this answer
up vote 10 down vote

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

share|improve this answer
show 2 more comments
up vote 2 down vote

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.

share|improve this answer
2  
And when he says why it can be done? – bigown Sep 15 '10 at 14:14
1  
So, how about solving a halting problem? Can it be done? – Pavel Shved Sep 15 '10 at 14:45
2  
It's bad to dismiss something as impossible if it's not and vice versa. – Randall Schulz Sep 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 Monego Sep 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 Williams Sep 22 '10 at 20:39
show 6 more comments
up vote 2 down vote

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

share|improve this answer
up vote 46 down vote

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.

share|improve this answer
1  
+1000 it's valid for anything. – nanda Sep 16 '10 at 10:04
1  
Some aren't even able to form decent questions, asking you to "just fix it" – deltreme Oct 18 '10 at 13:43
show 1 more comment
up vote 2 down vote

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

share|improve this answer
up vote 126 down vote

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

share|improve this answer
16  
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  
+1 for Ngu and William too. This is the most typical criteria of a bad "programmer". – fabrik Sep 16 '10 at 12:23
show 2 more comments
up vote 7 down vote

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.
share|improve this answer
8  
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
show 2 more comments
up vote 21 down vote

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...

share|improve this answer
6  
...and for no good reasons, I should add. – missingfaktor Sep 15 '10 at 17:44
5  
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... – dash-tom-bang Sep 16 '10 at 1:47
up vote 15 down vote

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.

share|improve this answer
5  
What if they can't find anything wrong, and that worries them? – SamB Sep 16 '10 at 20:39
1  
Or worse, they can't find anything wrong and try to fix it. – Toon Krijthe Sep 18 '10 at 13:03
up vote 15 down vote

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

share|improve this answer
up vote 14 down vote

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

share|improve this answer
show 1 more comment
up vote 7 down vote

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.

share|improve this answer
up vote 4 down vote

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.

share|improve this answer
up vote 2 down vote

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.

share|improve this answer
up vote 3 down vote

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.

share|improve this answer
up vote 2 down vote

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.

share|improve this answer
up vote 2 down vote

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

share|improve this answer
show 2 more comments
up vote 3 down vote

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

share|improve this answer
up vote 2 down vote

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.

share|improve this answer
up vote 4 down vote

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.

share|improve this answer
up vote 0 down vote

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.

share|improve this answer
1 2

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