5 ms·

I have to say, I really didn't like the document much. Not because of substance. Some of what he says is true. On style, though, I think the document is trash.

I have to say, I really didn't like the document much. Not because of substance. Some of what he says is true. On style, though, I think the document is trash. Some of what I say is probably even a bit ad hominem. Most of the good programmers I know don't spend time worrying about bad programmers. They just write good code and cleanup bad code when they see it. If someone feels compelled to write up an essay about bad programmers, he probably spends a lot of time dealing with bad programmers. That experience should lead to humility, not arrogance. If you deal with a lot of bad programmers, you might not be as good as you think you are. After all, you work at the same place on the same project as a bunch of bad programmers. They where hired under the same standards as you. To me, the document just seemed like arrogant posturing. An attempt at crafting a "negative identity" (define a group by vilifying the outsider). The best way to "be", and to be recognized as, a good programmer is to write good code. All the other stuff is just horse shit.

axod 17y ago
>> "They where hired under the same standards as you." The problem is though the hiring process for programmers is often completely broken. Measuring good programmers is also broken in many companies, so bad programmers tend to just stay there instead of improving, or being fired. I think being a good programmer isn't too hard if you have the talent, taste, time etc. Being recognized as a good programmer, and rewarded as such is harder.
- timwiseman 17y ago
  Excellent point. Another to add to the list is that you may easily have been hired under a higher standard as the team lead or "working/programming manager". I have been fortunate to never work with a bad programmer, but I have worked with inexperienced programmers that were learning as they went. I was not hired under the same standard or for the same reason they were.
- wynand 17y ago
  I agree with your sentiment, and although I generally agree with the parent, I also disagree with the statement that "[t]hey where hired under the same standards as you". Few companies look for programming talent and I've seen this being hand waved away by statements like: "good programmers don't necessarily make good employees". But on the whole, the article also leaves a sour taste in my mouth due to the superiority complex that cuts through it. Good programmers won't effect much change at companies that have broken hiring practices. Rather move somewhere where your skills will be appreciated.
- joe_the_user 17y ago
  Being recognized as a good programmer when you focus on the "bad programmers" around you is both unfortunate and counter-productive. Being a good team member who improves the process of your team by working to everyone's strengths is ... excellent. Oddly enough, I think that at least some managers are more likely to recognize the latter than the former and often rightfully so.
clawrencewenham 17y ago
> If someone feels compelled to write up an essay about bad programmers, he probably spends a lot of time dealing with bad programmers. I should cancel my appointment with the psychoanalyst :-) Writing is also a catharsis. You write to discover what you think and improve yourself. But perhaps Isaac Asimov spent a lot of time dealing with robots...
jimbokun 17y ago
"The best way to "be", and to be recognized as, a good programmer is to write good code." That is why he included "remedies" for each condition. If you implement all of these remedies, you are very likely to write good code, and thus be a good programmer. The title leads to the structure of the article, which is really about pitfalls to avoid if you want to be a good programmer. And for some, the negative tone might really be necessary. Remember, incompetent people are often unaware of their own incompetence. But if someone has the humility to read an article titled "Signs that you're a bad programmer" and honestly look for things he can identify in himself, he is on the right track. In my opinion, the remedies transform this from an attempt at vilifying outsiders, into a potentially valuable tool for becoming a better programmer.
ratsbane 17y ago
I appreciate your meaning; certainly, there are enough weak essays about bad programmers, but this one has more substance than some I've read. The idea behind any essay about bad programming has merit. I read the points in essay like this through two filters: is it a valid point and am I guilty of it. Most of the points in this essay are valid. The one about pointers isn't so relevant unless you live in C but the others, sure. The bit about knowing your platform well - that made me think about some things I've been working on. The essay made me think and maybe checksum myself just a bit. For that, I like it.
- Zancarius 17y ago
  > The one about pointers isn't so relevant unless you live in C but the others, sure. To be fair to the article's author, he does mention that understanding references is analogous to understanding pointers. They aren't the same thing (his own words) but they're close enough to matter. I confess I originally thought exactly as you did: "What? This only applies to languages like C!" until I read a little more closely. It was a tricky sentence, and I would have appreciated it more if he were to have made the two a little more obvious. It's always easier to judge in retrospect, though. The problem I have is that I agree with you and the original individual who stated that the article seemed arrogant. On the one hand, it made some really good points including MANY that I have been guilty of at some point or another. The biggest beef I have with the article at large is that some of the issues are language-specific. For instance, not using methods/fields "correctly" is a pretty big problem--unless you're using a language that doesn't have properties (hello, PHP). I absolutely love properties, but whenever I've had to maintain or write PHP (yeah, I know), I tend to create public fields and use them as a pseudo-property rather than writing getter/setter methods. One, since it's a scripting language, getter/setters are superfluous for most simple applications and the fact that it's a dynamic language with an extremely stupid typing system sort of mitigates the benefit of writing extra code. I'm also not sure whether there's a performance penalty with accessor and mutator methods (maybe someone can clue me in here) in PHP. So, am I a bad programmer because I don't use standard paradigms for small scripts written in an arguably awful language? Maybe so. Maybe more so since I actually write in that language from time to time! But, the point of this minor tangent is that some of the article's points don't effectively apply in all languages either due to deficiencies or oversights in the language specification. I do appreciate your point about reading the article through two filters. I'd like to add a couple of others: does it matter (in the context of the language you're using) and is the point of contention a mistake that could be made due to scheduling pressure or deadlines? To some extent, I'm sure we could blame a specific degree of bad code on ridiculous deadlines (and I think the author pointed that out, too!).
elai 17y ago
Most of the good programmers dont think about bad programmers, but if your hiring one, it's something you want to think about.

axod 17y ago

>> "They where hired under the same standards as you." The problem is though the hiring process for programmers is often completely broken. Measuring good programmers is also broken in many companies, so bad programmers tend to just stay there instead of improving, or being fired. I think being a good programmer isn't too hard if you have the talent, taste, time etc. Being recognized as a good programmer, and rewarded as such is harder.

timwiseman 17y ago
Excellent point. Another to add to the list is that you may easily have been hired under a higher standard as the team lead or "working/programming manager". I have been fortunate to never work with a bad programmer, but I have worked with inexperienced programmers that were learning as they went. I was not hired under the same standard or for the same reason they were.
wynand 17y ago
I agree with your sentiment, and although I generally agree with the parent, I also disagree with the statement that "[t]hey where hired under the same standards as you". Few companies look for programming talent and I've seen this being hand waved away by statements like: "good programmers don't necessarily make good employees". But on the whole, the article also leaves a sour taste in my mouth due to the superiority complex that cuts through it. Good programmers won't effect much change at companies that have broken hiring practices. Rather move somewhere where your skills will be appreciated.
joe_the_user 17y ago
Being recognized as a good programmer when you focus on the "bad programmers" around you is both unfortunate and counter-productive. Being a good team member who improves the process of your team by working to everyone's strengths is ... excellent. Oddly enough, I think that at least some managers are more likely to recognize the latter than the former and often rightfully so.

clawrencewenham 17y ago

> If someone feels compelled to write up an essay about bad programmers, he probably spends a lot of time dealing with bad programmers. I should cancel my appointment with the psychoanalyst :-) Writing is also a catharsis. You write to discover what you think and improve yourself. But perhaps Isaac Asimov spent a lot of time dealing with robots...

jimbokun 17y ago

"The best way to "be", and to be recognized as, a good programmer is to write good code." That is why he included "remedies" for each condition. If you implement all of these remedies, you are very likely to write good code, and thus be a good programmer. The title leads to the structure of the article, which is really about pitfalls to avoid if you want to be a good programmer. And for some, the negative tone might really be necessary. Remember, incompetent people are often unaware of their own incompetence. But if someone has the humility to read an article titled "Signs that you're a bad programmer" and honestly look for things he can identify in himself, he is on the right track. In my opinion, the remedies transform this from an attempt at vilifying outsiders, into a potentially valuable tool for becoming a better programmer.

ratsbane 17y ago

I appreciate your meaning; certainly, there are enough weak essays about bad programmers, but this one has more substance than some I've read. The idea behind any essay about bad programming has merit. I read the points in essay like this through two filters: is it a valid point and am I guilty of it. Most of the points in this essay are valid. The one about pointers isn't so relevant unless you live in C but the others, sure. The bit about knowing your platform well - that made me think about some things I've been working on. The essay made me think and maybe checksum myself just a bit. For that, I like it.

Zancarius 17y ago
> The one about pointers isn't so relevant unless you live in C but the others, sure. To be fair to the article's author, he does mention that understanding references is analogous to understanding pointers. They aren't the same thing (his own words) but they're close enough to matter. I confess I originally thought exactly as you did: "What? This only applies to languages like C!" until I read a little more closely. It was a tricky sentence, and I would have appreciated it more if he were to have made the two a little more obvious. It's always easier to judge in retrospect, though. The problem I have is that I agree with you and the original individual who stated that the article seemed arrogant. On the one hand, it made some really good points including MANY that I have been guilty of at some point or another. The biggest beef I have with the article at large is that some of the issues are language-specific. For instance, not using methods/fields "correctly" is a pretty big problem--unless you're using a language that doesn't have properties (hello, PHP). I absolutely love properties, but whenever I've had to maintain or write PHP (yeah, I know), I tend to create public fields and use them as a pseudo-property rather than writing getter/setter methods. One, since it's a scripting language, getter/setters are superfluous for most simple applications and the fact that it's a dynamic language with an extremely stupid typing system sort of mitigates the benefit of writing extra code. I'm also not sure whether there's a performance penalty with accessor and mutator methods (maybe someone can clue me in here) in PHP. So, am I a bad programmer because I don't use standard paradigms for small scripts written in an arguably awful language? Maybe so. Maybe more so since I actually write in that language from time to time! But, the point of this minor tangent is that some of the article's points don't effectively apply in all languages either due to deficiencies or oversights in the language specification. I do appreciate your point about reading the article through two filters. I'd like to add a couple of others: does it matter (in the context of the language you're using) and is the point of contention a mistake that could be made due to scheduling pressure or deadlines? To some extent, I'm sure we could blame a specific degree of bad code on ridiculous deadlines (and I think the author pointed that out, too!).

elai 17y ago

Most of the good programmers dont think about bad programmers, but if your hiring one, it's something you want to think about.