When would someone be considered a bad programmer? [closed]

Question

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

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

Answer 1

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.

Answer 2

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

Answer 3

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.

Answer 4

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.

Answer 5

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

Answer 6

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

Answer 7

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

Answer 8

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

Answer 9

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

Answer 10

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.

Answer 11

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

Answer 12

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

Answer 13

Unable to adapt themselves to upcoming technologies

Answer 14

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.

Answer 15

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

Answer 16

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.

Answer 17

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.

Answer 18

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.

Answer 19

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.

Answer 20

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.

Answer 21

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

Answer 22

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!

Answer 23

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.

Answer 24

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

Answer 25

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

Answer 26

!(smart and gets things done)

Answer 27

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.

Answer 28

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.

Answer 29

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

Answer 30

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.