
Signs that you are a bad programmer - okal
http://www.yacoset.com/Home/signs-that-you-re-a-bad-programmer
======
mcantor
I wish articles like this would namespace their assertions by telling us what
they mean by "good" or "bad", so we could avoid the perennial echo chamber
debate that goes like this:

    
    
        A: GOOD MEANS SHIPPING AND PLEASING YOUR CUSTOMERS
        B: NO YOU FOOL! GOOD MEANS WRITING CLEAR CODE THAT OTHER HACKERS CAN READ
        C: NO YOU FOOLS! GOOD IS A HAPPY MEDIUM BETWEEN BOTH OF THOSE THINGS
        D: DEBATE IS HARD, LET'S GO SHOPPING!
    

God forbid we agree on what words mean before we talk about them...

~~~
philwelch
"Good" already has a meaning, you can't arbitrarily redefine it. You have to
actually figure out what the most "good" tradeoff is between shipping and
writing maintainable code.

~~~
FuzzyDunlop
"Good" is also arguably subjective and relative to the subject's perceptions
of "bad"(and vice-versa).

So of course that "good" tradeoff to one programmer might be a "bad" one to
another.

~~~
philwelch
That's a "good" point.

~~~
mcantor
I laughed, you bastard.

------
rickmb
The opposite approach is much simpler. There's only one sign that you are a
great programmer:

 _Clients and fellow programmers are still happy with your work two years
after you've delivered it._

(Of course: "still" implies that they we're happy at delivery, which includes
actually shipping working software in a timely fashion.)

~~~
spenrose
"Clients and fellow programmers are still happy with your work two years after
you've delivered it."

Disagree. The first system I wrote kept the client happy for years. It was a
mess, but it was literally millions of dollars better than not having any
system.

If what you mean is something like "focus on doing work of long-term value,
and consider programming skill as such an input", then I'd agree with that.

~~~
philwelch
"and fellow programmers"

Did your client ever hire programmers to maintain and improve the first system
you wrote? Were those programmers happy with your work?

I guess if no one is ever going to maintain your code it doesn't matter as
much. I wouldn't ever be so bold as to predict ahead of time whether that's
going to be the case.

~~~
krobertson
It also assumes those fellow programmers are also good programmers.

Can a mediocre programmer tell the difference between mediocre code and good
code?

To the original point, the happiness of the client and other developers is a
good indicator, but not the only.

~~~
andrewflnr

      Can a mediocre programmer tell the difference between mediocre code and good code?
    

Maybe not directly, but they can probably tell how well they understand the
code and how hard it is to change. Not as well as a good programmer, since
they'll have more trouble with both regardless, but somewhat.

~~~
spenrose
My bad; thanks to philwelch and saraid for flagging the error. The resulting
discussion is interesting, as is 13 upvotes for a post based on a misreading
:-). FWIW, my favorite bit on programmer's understanding each other's work is
Yegge's Done and Gets Things Smart.

------
substack
I suspect that people who don't "get" pointers (#4 in the article) actually
have a much harder time with the pointer declaration and manipulation syntax
in C than actually understanding how pointers work and what they let you do.

For instance, in C the * character is used both to declare a pointer and to
dereference one and they can be stacked to dereference nested structures. Then
& references a variable memory location but is also used in method signatures
to change the semantics of calling a function into pass-by-reference. To
complicate & further, & is often seen alongside const declarations, which are
a whole other thing that people have to keep in their heads.

On top of all of this, * and & have their own operator precedences and
associativities that you have to memorize, which is a whole discussion about
binary versus unary operators and precedence tables. And I didn't even mention
[].

I really don't think that people fail to comprehend pointers because their
mental models need updating nearly as often as they just haven't fully
internalized all the hoops that C makes you jump through to mess with
pointers.

~~~
BrandonM
> _For instance, in C the_ * _character is used both to declare a pointer and
> to dereference one and they can be stacked to dereference nested
> structures._

This problem can be solved by thinking of * as _always_ dereferencing a
pointer. So:

    
    
      int *a; /* "*a" is an int, thus a is a pointer to one */
      int *b, *c; /* *b and *c are both ints */
    

This also has the nice side effect of explaining why good C programmers write
the * next to the variable name and why multiple variables declared on the
same line all require a * next to the variable name.

> _Then & references a variable memory location but is also used in method
> signatures to change the semantics of calling a function into pass-by-
> reference. To complicate & further, & is often seen alongside const
> declarations, which are a whole other thing that people have to keep in
> their heads._

Now it sounds like you're talking about C++ moreso than C. In C, & is pretty
much always the "address-of" operator (except in contexts where it's clearly
logical- or bitwise-AND).

From your post, it seems that the problem is more one of poor teaching, poor
explanations (metaphors), or poorly-designed extensions (C++) as opposed to
shortcomings of C.

~~~
loup-vaillant
I second the remarks about poor teaching (though C type syntax does sucks
hard). The main problem probably comes from the fact that _ordinary variables_
are themselves an indirection of sorts, and programming courses do not make
that clear (we tend to confuse the variable and the value it holds). Excerpt
from my article on assignment[1]:

[The pervasive use of the assignment statement] influenced many programming
languages and programming courses. This resulted in a confusion akin to the
classic confusion of the map and the territory.

Compare these two programs:

    
    
      (* Ocaml *)        │    # most imperative languages
      let x = ref 1      │    int x = 1
      and y = ref 42     │    int y = 42
      in x := !y;        │    x := y
         print_int !x    │    print(x)
    

In Ocaml, the assignment statement is discouraged. We can only use it on
"references" (variables). By using the "ref" keyword, the Ocaml program makes
explicit that x is a variable, which holds an integer. Likewise, the "!"
operator explicitly access the value of a variable. The indirection is
explicit.

Imperative languages don't discourage the use of the assignment statement. For
the sake of brevity, they don't explicitly distinguish values and variables.
Disambiguation is made from context: at the left hand side of assignment
statements, "x" refer to the variable itself. Elsewhere, it refers to its
value. The indirection is implicit.

Having this indirection implicit leads to many language abuses. Here, we might
say "x is equal to 1, then changed to be equal to y". Taking this sentence
literally would be making three mistakes:

(1) x is a variable. It can't be equal to 1, which is a value (an integer,
here). A variable is not the value it contains.

(2) x and y are not equal, and will never be. They are distinct variables.
They can hold the same value, though.

(3) x itself doesn't change. Ever. The value it holds is just replaced by
another.

The gap between language abuse and actual misconception is small. Experts can
easily tell a variable from a value, but non-specialists often don't. That's
probably why C pointers are so hard. They introduce an extra level of
indirection. An int* in C is roughly equivalent to an int ref ref in Ocaml
(plus pointer arithmetic). If variables themselves aren't understood, no
wonder pointers look like pure magic.

[1]: <http://www.loup-vaillant.fr/articles/assignment>

~~~
BrandonM
Thanks for the informative reply and the excellent blog post!

------
edw519
I found the "Alternative careers" hilarious.

My version:

    
    
      Your code sucks.
      Alternative careers: "Do you want fries with that?"
    

OP's version:

    
    
      1. Inability to determine the order of program execution
      Alternative careers: Electrician, Plumber, Architect, Civil engineer
      
      2. Insufficient ability to think abstractly
      Alternative careers: Contract negotiator, Method actor
      
      3. Collyer Brothers syndrome
      Alternative careers: Antique dealer, Bag lady
      
      4. Dysfunctional sense of causality
      Alternative careers: Playing the slot machines in Vegas
      
      5. Indifference to outcomes
      Alternative careers: Debt collection, Telemarketing
    

So the real test of a good programmer is one who can write a routine that
crawls the source code of a bad programmer and tells them what they should
really be doing.

~~~
Sniffnoy
I have to wonder if someone who can't determine order of execution should be
an electrician or plumber either -- those aren't static systems!

~~~
JonnieCache
I guess the point is that there's no "privileged" position in these systems
which changes with time, like the point of execution in programming.

What is the proper name for the bit of code that's currently being executed?
I've suddenly realised that its a concept you think about constantly when
coding, but its so much a part of the scenery so to speak that you never
consciously consider it.

~~~
Androsynth
At the hardware level it's called the program counter, which is a register
containing the address of the current operation the processor is running.
After the operation is finished, it increments itself and moves to the next
step in the program.

Edit: just realized I didn't really answer the question, I believe what your
actually talking about is a statement.

I usually jump at the chance to talk about stuff from my old EE days :)

~~~
Zaak
The program counter isn't the only element of that "what the program is doing
now" state though. The context in which the current instruction is being
executed makes a world of difference.

~~~
jpendry
And the ability to save all of that into a variable so that you can pass it
around to other parts of your program means that your programming language
supports Continuations.

------
skrebbel
What a condescending piece of junk. It serves absolutely no other purpose than
to make programmers who _do_ grok everything mentioned feel good about
themselves.

Worse yet, programmers who could _actually_ benefit from an article like this
(i.e. programmers who shouldn't be programmers) won't understand it. E.g.
"(Functional) Creating multiple versions of the same algorithm to handle
different types or operators, rather than passing high-level functions to a
generic implementation" - a bad programmer won't understand what is meant
here, so he will simply skip over it and not get the hint.

Finally, I find the notion that you can't be a good programmer if you've never
really used Lisp laughable.

~~~
loup-vaillant
The actual quote about lisp is: _"5. Lisp is opaque to you"_. I don't think
the criterion isn't whether you used Lisp or not. He probably meant: "could
you understand Lisp if you tried? If you can't, then that is a red flag".

------
barce
I paused for a bit when I read, "A programmer can't acquire this kind of
knowledge without slowing down." It seems that many businesses that rely on
programmers are unwilling to give them the time to be better.

I have seen coders with CS degrees from top-tier schools believe that they
couldn't code anymore when placed in environments that do not mentor them,
that treat them as horses to be run until their backs break.

If you feel this way, take a part-time job and focus on becoming a better
coder. If you are a business that does this... no wonder you waste money on
recruiters.

~~~
nhangen
I'm in this position now. I'm not a great developer, and I love learning new
tricks, but because I'm billed hourly, am constantly interrupted, and get
brought in to useless meetings, I'm left with zero time to learn.

~~~
bmj
The other problem with this is that you never have the opportunity to improve
the business, either. Often, management wants the rank and file to improve
processes ("because they know them best") but it's hard to find the time for
that when you're already working full time (and more) on your deliverables.

~~~
nhangen
No doubt. In fact, this is exactly what happened to me today. I'm supposed to
have great ideas, but when trying to implement them, told that I need to focus
on paying the bills. I don't know how people manage this long-term.

~~~
wnight
By jumping ship and landing at a less-dysfunctional workplace.

If their business plan doesn't include time for improvements of the processes
it's a failure. Leave now. Don't try to make up for their mistakes. They won't
see it (positively), let alone reward you for it.

Do good for your old co-workers by recruiting the good ones into the more-
functional company.

~~~
AppSec
Depends on what process you are talking about. If you are trying to improve a
process which will hurt the time to deliver of a major project costing a
company money, then is it really right to call the company a failure?

Every company/division/organization has priorities and while there maybe
inefficiencies in their processes, they maybe a minor cost in relation to the
other priorities. (I can't believe I actually just played devils
advocate/defended this).

~~~
wnight
No, I stand by it. If a company doesn't include time for process improvement
they have failed. Maybe they haven't tanked yet but the first bend in the road
will finish them.

This doesn't mean they have to stop and fix every non-problem, but if there's
no time budgeted to fix what comes up the first real problem will ruin
everything.

------
clawrencewenham
I wrote this years ago to get it out of my system, and after Infogami went to
the big web host in the sky I ported it and my other nonsense to Google Sites.
The slightly updated version of the same article is now here:

[http://www.yacoset.com/Home/signs-that-you-re-a-bad-
programm...](http://www.yacoset.com/Home/signs-that-you-re-a-bad-programmer)

~~~
mcantor
Just FYI, I love your articles. I routinely forget who wrote them and where to
find them again, then fail to find the link in my bookmarks, so I spend a half
hour Googling phrases I vaguely remember being included in the essays ("how to
deliver without everything getting fucked up", nope. "how to write code
without shit exploding", nope. "how to..."). I think they reside in some kind
of cognitive null zone in my brain. So, thanks for linking them again!

------
joe_the_user
The problems described by the article are certainly real problems I've seen
and seem like an indications of someone who indeed hasn't taken the time to
deeply understand the programming process. But the term "bad programmer" and
the general attitude of the article seems deeply mean-spirited,

I would rather work with an actual "bad programmer" than with the kind of
person who'd spend their time thinking up "alternative careers" for these
people.

~~~
jakejake
In my experience just about everybody fancies themselves a great programmer
and considers anybody who doesn't know (insert semi-random list of skills) to
be a shitty programmer.

I kinda think it's like the Roth test for obscenity. I can't really explain
what makes a shitty programmer, but "I know it when I see it."

~~~
gorbachev
I don't know about that.

Most people I've worked with over the years have understood their limitations
and would never consider themselves great, with the possible exception of half
a dozen or so folks, who truly are great.

There have, of course, been exceptions, too.

~~~
jakejake
My opinion is probably tainted by my own working experiences. I've run into
various mediocre IT pros who have been at it for a while and possibly are
trying to appear smart for purposes of job security.

I've only had the pleasure of working with a handful of what I considered
truly great programmers. I don't think a single one of them considered
themselves to be "great" even though I thought they were.

------
mcknz
"You're not reading this article."

But seriously, it probably never occurs to bad programmers that they should be
finding articles like this.

Perhaps a better title/approach would be "A Bad Programmer Taxonomy, And How
You Can Help."

------
eru
Sounds quite arrogant to me. And didn't get the biggest problem: Not finishing
stuff.

~~~
veb
I must admit I'm bad at this. However, in my defense it comes down to: bad
management.

I'm forever being told to work on the next MOST IMPORTANT THING EVER only to
be told after a few days that I need to work ON THE NEXT MOST IMPORTANT THING
and that the MOST IMPORTANT THING EVER that I was working on is no longer
important at all.

le sigh

~~~
FuzzyDunlop
"Hey, FuzzyDulop, we're a day before deadline but I've been thinking, we could
do _SUPER BRILLIANT IDEA THAT CHANGES EVERYTHING_ and it'd be amazing! What do
you think?"

...

"You can forget about your deadline if you want that in, boss."

* skip forward a week *

"Hey, FuzzyDunlop, we're a day before deadline but..."

~~~
crag
And then getting chewed out for missing the original deadline. Usually from
the boss who just drop the SUPER BRILLIANT IDEA THAT CHANGES EVERYTHING in
your lab.

~~~
FuzzyDunlop
We get the sort of unsure, passive aggressive criticism, full of ifs and
maybes. The sort that actually makes you feel worse because the boss appears
to be personally disappointed.

Get chewed out proper and at least you know it's just because jobs have to be
done.

------
ducktype
> "Bulldozer code" that gives the appearance of refactoring by breaking out
> chunks into subroutines, but that are impossible to reuse in another context
> (very high cohesion)

I feel like this might give people the wrong idea. Surely some amount of
cohesion is desirable. Also, I'm not quite sure how one "gives the appearance
of refactoring" without actually refactoring. Whether it's useful or not may
enter into it, but I would usually consider the breaking out of chunks into
subroutines refactoring.

~~~
kenjackson
Not only that, the purpose of refactoring isn't simply for reuse, but also for
readability. If you break out chuncks that aren't reusable, but enhance the
readability of the code then you've likely improved the code.

Given the choice between reusability and readability I'd say that readability
should usually win (although it is a false choice).

~~~
pseudonym
I would contend that if you're having code readability issues, it'd be better
to fix it by sprucing up your whitespace and comments, instead of saying
"Well, let's chunk it into more functions" and have method(), which returns
method1(), which returns method2(), which returns method3()...

Chunking for the sake of itself doesn't seem like a viable strategy to me.

~~~
glenjamin
When you add a new-line or two into a section of code, you're usually saying:

"These two blocks of code do something different"

Thats what is normally called a method. If it's only for one class then by all
means make it private and name it well, so the caller remains readable.

------
larsberg
Interestingly, his enumerated set in the "Bad Programmer" list is almost
exactly what I was grilling for when I asked people to implement stupid
algorithms on a whiteboard and then step through them, debug them, etc.

I somewhat disagree with:

> 6\. Cannot fathom the Church-Turing Thesis

Truly understanding the Church-Turing thesis probably requires more
computability theory than the two-week overview even top CS students and
otherwise great programmers get in their ABET-required Discrete Math course.
It would be great for more people to have an understanding of what a
computable function is and isn't, because it would make it easier to explain
why we don't have more fancy-pants type systems around,\footnote{Inference is
undecidable for most interesting ones.} but it certainly isn't a requirement
for great or even good programmers.

~~~
eru
> Truly understanding the Church-Turing thesis probably requires more
> computability theory than the two-week overview even top CS students and
> otherwise great programmers get in their ABET-required Discrete Math course.

Mathematicians may have more luck in their training. But that depends on your
chosen speciality.

------
jwingy
A lot of these make sense, but I would caution against being discouraged if
you show any of these symptoms. Like another front page article that says IQ
is not static, I think this also definitely applies to programming ability.

I hope this isn't used by some to push the mantra that 'not everybody can
code'.

~~~
re_todd
Yeah, I think the title should have been "Signs that you are a mediocre
programmer", which would have been less discouraging. I'm sure most good
programmers have started out making many of these mistakes. At least it has a
"Remedies" section, so it's not a total downer.

~~~
dcrankshaw
I completely agree. Several of the mistakes listed, particularly thinking in
sets, were things I had issues with until that "aha" moment when the paradigm
shift in my thinking about the problem occurred.

On the other hand, I doubt the author was trying to discourage bad
programmers, but rather bring common deficiencies or mistakes up to help
programmers avoid them. To me, many of these are signs that you are a new or
inexperienced programmer, not a bad one (although if you've been a programmer
for a decade and are still making them, you may have something to worry
about).

------
jedberg
My first thought was, "wow, infogami is still up?" I guess I left it in a good
state. :)

~~~
william42
Looking at the homepage, it says that the most popular pages were converted
into static form, and now they're trying to sell the domain.

~~~
jedberg
Yeah, we did that a long time ago. I'm just surprised it is still running! I
don't think I even told the other reddit guys about infogami or where it runs
or anything.

~~~
clawrencewenham
I guess I can't log-in and add a link to its new home, eh?

~~~
jedberg
Nope, it's static only. But if you ask the reddit guys real nice, they might
be willing to edit the file manually for you.

------
xarien
To me, everything in that article can be addressed with a little experience.

My one indicator that someone is going to be a bad programmer actually has
little to do with technical skill sets, but rather personality. As my sanity
check, I make sure to examine the open-mindedness (willingness to research and
use unfamiliar tools) of programmers. More often than not, you find
programmers who are very comfortable in given languages, environments, tools
etc, but once you take away their comfort blanket, they keep reaching back for
it.

An extreme example would be a scenario such that a programmer who knows C very
well decides to do a decent amount of parsing in C instead of researching
better languages for the job such as python or perl.

------
pookiesbutt
"You seriously consider malice to be a reason why the compiler rejects your
program"

Of course it's malice.

~~~
VladRussian
the compiler in many simple cases could have tried to repair the program, like
attempting to insert(remove) missing(extra) ';' or '}' for example. While it
may be not a malice, it is definitely an absence of a good will.

Note: i did work on a real product which had parser inside that had such style
of repair implemented, and such approach is also quickly mentioned in the
dragon book as well

~~~
gridspy
It's possible that such automatic repair would create a bug. Much safer to
have a human check and ensure that the ; goes in the right place.

A better point is that the error messages from many compilers can be very
obscure. This was particularly true 10-15 years ago.

~~~
philwelch
Yeah, if a compiler only compiles the code you actually wrote, it's still your
fault. If a compiler tries to infer what you meant and compiles that instead,
then it might genuinely be the compiler's fault when something breaks. Plus,
the original code should still be fixed instead of relying on the compiler to
compile the same broken code the same "right" way each time. We spent the last
20 years trying to convince web developers of that idea.

Clang does something like this. If it notices a simple enough syntax error
that it can correct, it still generates the error message but it makes the
correction internally and continues the compilation far enough to generate
useful error messages about the rest of the code. But it doesn't output
anything or change the code.

------
ericdykstra
I don't need an article to tell me I'm a bad programmer.

------
bitops
The OP may be being ironic/sarcastic to a certain degree but I'm always wary
of these types of articles.

"You are a bad programmer". How would it make you feel to hear that? Probably
not open to further suggestions on how to improve.

While I agree that as programmers we should always strive to be getting
better, these types of put-downs and belitting don't foster a culture of
communication and trust.

Personally, I'm most receptive to hearing that I could improve when it's
coming from someone I trust and respect. If a random person or poster on the
Internet sent me this article and rubbed it in my face, I'd probably write
them off as a major a-hole. And, I might miss out on a great opportunity to
learn.

It reminds me of this post: <http://news.ycombinator.com/item?id=2322696> \- I
read it and at the time thought it was great. But, sadly, not much has changed
and this post is sad evidence of that fact.

~~~
chernevik
I saw at least a half-dozen habits that have cost me I-don't-want-to-think-
how-much time. And at least a half dozen I'm still doing. I was dimly aware of
them as repeated frustrations, but identifying them makes it a lot easier to
target them for deletion.

I'm going to mark this thing up, add "haven't crossed any of these off in the
past year", and postpone my judgment until next fall.

------
njharman
Why is "Performing atomic operations on the elements of a collection within a
for or foreach loop" a symptom of mediocre programmer "inability to think in
sets"?

How should one do that if your "thinking is sets"?

~~~
amalcon
That particular symptom is built under the assumption that your language
supports map/filter/reduce or some equivalent functionality. These are
generally preferred when available because there are fewer places to make
mistakes.

------
bauchidgw
my ruleset is much more liberal

signs that you are a good coder: you enjoy coding, you enjoy a good piece of
code

signs that you are a bad coder: you don't enjoy coding, you can not appreciate
beautiful code

if you enjoy coding it jut doesnt matter if anyone else thinks that your code
sucks. you will get better. if you hate your job (programming) then you code
stinks and will get worse.

in my careere i went from good to great to bad to i dont code anymore to good

~~~
absconditus
How long have you worked as a professional software developer? Have you ever
worked at a large company? There are plenty of people with a decade of
experience who enjoy writing code who are just bad at it. Some of these people
work on software that is much more important than Facebook.

------
onan_barbarian
I suspect that #1 sign is that you go trolling for self-assurance in articles
like this, or worse, by writing smug, random articles like this.

The best possible signs either way will be in your career so far.

------
Okvivi
A sign that I found missing from the list: you are totally devoted to a
particular programming language and believe it's a silver bullet. All good
programmers that I know understand that languages are just tools and all have
tradeoffs of some sort.

~~~
watmough
I'm pretty sure I saw the "everything is a nail" type listed, which might well
cover the folks that think Technology A is the be-all and end-all.

------
jgn
I'm a student in the third year of my CS degree and I constantly worry about
not being a good programmer. There's things on that list I need to work on.

------
jroseattle
I'm presently repairing a project that violates nearly every one of these
principles. Literally, it's like they had a checklist made from this post and
went down it to ensure they did everything wrong.

------
chris_dcosta
I think this stuff comes from someone who has a colleague with these
"symptoms", and is either frustrated because they can't educate them into
better techniques, or is a subordinate with no power.

In any case it's pretty unforgiving.

I have had a colleague who fits the bill here, but actually I just let them
get on with their work and I got on with mine. Sure, it was hard when he
delivered something that was excruciatingly poorly conceived and executed and
I had the task of taking it to the the next stage. But you know this isn't a
life and death business, he was a really nice guy, and I wasn't going to rock
the boat. The next project, I was working with someone else and everyone was
happy.

Contrast that with making an issue of it, and you might find yourself being
labelled as a trouble maker, even if you did have the best intentions for the
development.

If you run the show however, don't stand for it, because it's your business,
and it calls for the best at all times.

------
dustinupdyke
Is it odd that any tense of the word "ship" does not appear in this article?

~~~
saraid216
Believe it or not, sometimes we code for purposes other than selling stuff.

~~~
zbuc
But you still have something to ship, even if it's just to your buddies on
github.

~~~
kd0amg
What you give to someone else may not be code -- it might just be the code's
output.

~~~
recoiledsnake
That is still called shipping.

------
krobertson
Hilarious, but some of the alternative careers I don't agree with.
Particularly the first example of order of execution.

If you can't grasp that and decide to be an architect, I wouldn't want to
drive on your bridge, work in your building, or live in your home. Same for
the options!

~~~
clawrencewenham
You may be able to grasp the instantaneous distribution of forces in a
building or charges in a circuit without needing to know the order that they
deploy. While a computer itself is an example of a circuit where the order of
execution matters, a radio is not.

Order-of-execution is not perceived the same way as cause-and-effect, even
though they're both the same thing. It's a damn weird thing that I've seen
people do. A little bit like how artists can comprehend how the position of an
arm has an effect on the way bones, fat and muscle are distributed over the
rest of the body, but can't understand why they got smacked with an overdraft
fee when their _average_ daily balance would have covered it easily.

------
sliverstorm
How do I know that list is a little off? Using it as a metric, I am mediocre-
to-good, when I know for a fact I haven't yet reached mediocre.

For example, I grokk pointers, but I use them so infrequently I make foolish
errors and have to stop and block everything out.

~~~
sophacles
In my experience you have nothing to fear: such thinking and self
understanding makes you a better programmer than many I have worked with. The
worst usually think they are way better than they are, and the better ones
usually know where they can improve.

I have worked with people who do some or most of these, and let me tell you,
the experience is not pleasant -- frequently turning into "Oh you changed that
code, I can't maintain it anymore, object are too tricky" (when refactoring
bulldozer functions and dicts of lists of dicts of tuples (some of which
contained dicts) into a few classes in python) or "My code was working, why
would you change that? I can't be responsible for looking at it anymore!"
(When the spec changed and we needed to check for extra error conditions.)

Basically what I'm suggesting here, is bad programmer is less a function of
skill at any particular moment, but of attitude and approach. Skills that
don't change, continued lack of understanding, and laziness, are all symptoms
of a bad programmer, who won't improve. I'd rather work with a neophyte who
wants to improve over a veteran who is static any day.

~~~
chris_dcosta
" I'd rather work with a neophyte who wants to improve over a veteran who is
static any day."

So true.

------
yaix
> eg: the "Delete Database" button is next to "Save", just as big, has no
> confirmation step and no undo

That was common practice all over the Web for over a decade, it only stopped
recently (on most sites). [Submit] [Reset] Argh!

------
scubaguy
If you are reading this article, you are not a bad programmer; you are a
programmer learning to master your craft.

~~~
thret
I'm starting to think that the majority of errors listed here are simply
phases of the learning process we all go through.

------
buckwild
I'll admit, when I was a C programmer, I was victim to "Dysfunctional sense of
causality."

I remember taking a C class in my undergrad, nailing the code to perfection,
and getting an F because I had written the code in under different
architecture and compiled with a different compiler (not specified in the
prompt by any means). It ran well on my computer (and I proved it), but since
it wouldn't run on my professors computer or TAs computer, I still received an
F.

So yes, I still maintain strong malice towards C :-)

------
malkia
Whooops... One of the symptoms is:

"(Functional) Manually caching the results of a deterministic function on
platforms that do it automatically (such as SQL and Haskell)"

Isn't that what memcached is doing?

------
mrt54321
This article is ignorant bullshit. Speaking as someone who's been a
professional programmer for a long time, and for a series of good companies.
What's present may be technically correct ( _may_ ), but most of the important
stuff is absent. And as for alternative careers for people who are too dumb to
progam. Oh please.

------
VBprogrammer
I think one of the biggest errors a bad programmer makes is seeing 'bad' code
everywhere. Sure, some code stinks but just because some code doesn't do
something the way you would have done it doesn't make it bad.

If you do have to complain about some piece of code then do so in concrete
terms:

\- Presense of bugs

\- Lack of error handling

\- Preformance issues (real ones, that cause real problems)

\- Security issues

\- Poor robustness

\- Redundancy

~~~
jroseattle
Your username doesn't aid in your argument against criticism of bad code. Just
sayin.

~~~
VBprogrammer
Actually, that was a username I've used for 13 years. Currently I'm mainly
developing in TCL professionally and Python personally.

~~~
jroseattle
It's in jest. There's something funny about the username "VBProgrammer" in a
discussion about identifying bad developers, from the stereotypical POV.

Disclaimer: I started as a VB guy myself. Now I fall in the C# and Python
camps.

------
Void_
> (OOP) Writing lots of "xxxxxManager" classes that contain all of the methods
> for manipulating the fields of objects that have little or no methods of
> their own

How about writing lots of xxxxController classes that manipulate objects that
have little methods of their own.

------
Don_Wallace
This article is mean spirited, too serious and not well written.

Bad programmers I have known generally:

\- Are oblivious and clueless. They just lack cleverness.

\- They lack problem solving abilities and willingness to solve problems.

\- They are usually slow witted.

\- They are very conventional-minded - external approval means a lot to them.

\- They are willing and ready to work too hard at programming for a result.

\- They lack abstract reasoning skills.

And most bad programmers don't like Star Trek or science fiction, but I can't
figure out why other than simple correlation with the mindset of a programmer.

The first set of six "real" causes pretty much encapsulate 99% of the
mediocrity I've witnessed in industry in this field. Bad programmers usually
have two or more of these problems. Even one of them is a serious problem if
you are looking for a great developer.

All other badness, such as "meal ticket" thinking, usually radiates outward
from these things.

I say this because if you lack the quickness and the desire to seek simple and
elegant solutions, the work becomes like drudgery and your work reflects the
other deficiencies that the article described.

A specific example: if you care too much what non programmers think (including
your managers) and if you are a bit of a toady, you will not take the time to
learn what is going on in-depth, and you will look for quick solutions. So
it's important to strategically ignore your bosses from time to time and if
you are trying to be politically popular, software development isn't a good
place for this.

Another example: if you "want" to work very, very hard, you will not seek ways
to simplify the code. You will instead cope with growing complexity and
spaghetti.

I question the article writer's programmer instincts because he did not figure
out a much more efficient and concise way of expressing the same things. Above
all else, a real programmer figures out how to say it just once - not
repeatedly cast in different ways.

------
fatalerrorx3
Where does the "gets shit done" programmer fit into all of this though? I'll
admit that some of my code is confusing and not always "clean" but it does
what it's supposed to do, and I'm able to get more "shit done" when I focus on
the end goal vision rather than the cleanliness of my code... which in a
prototyping phase of product development is really rather meaningless anyway,
since you don't even know yet if there's a market for your product/service
offering

------
LeafStorm
> "Yo-Yo code" that converts a value into a different representation, then
> converts it back to where it started (eg: converting a decimal into a string
> and then back into a decimal, or padding a string and then trimming it)

The other day I was at a hack night and some guys were working on something
written in Node. They were having all kinds of problems with an object, so
they serialized it to JSON and loaded it back, and somehow it magically
started working.

------
chegra
It's easier to fix the technology than to fix the users. I don't think in my
wildest dreams I could walk away from a program I created and say the user of
said program is bad. I would find a way of fixing it. Programs should serve
users, not the other way around. Likewise, Programming Languages should serve
Programmers. Clearly, we aren't properly being serviced if programming makes
us constantly look bad.

------
bbrizzi
Signs you're a bad writer:

\- Your blog post only consisting of lists

\- Using only -ing verb forms in your lists

\- Not having an introduction in your article

\- Not having a conclusion either

\- Having only short 2-line paragraphs

\- Lack of any style

------
itsnotvalid
The best part is at the very bottom... if you think it's TL;DR, you could have
missed a lot of points.

------
juanfatas
I think the bad programmer won't see this post as they don't check Hacker News
on a daily basis... :P

------
rwmj
I wonder who wrote this article originally? Google finds about 9 identical
copies:

[https://encrypted.google.com/search?q=%22deficiency+a+progra...](https://encrypted.google.com/search?q=%22deficiency+a+programmer+can+practice+by+using+the+IDE%22)

~~~
bostonvaulter2
Hacker News user clawrencewenham

<http://news.ycombinator.com/item?id=3132533>

------
clu3
Signs that you are a mediocre programmer

Adding columns to tables for tangential data (eg: putting a "# cars owned"
column on your address-book table)

I thought this is actually good for performance in different cases? Why is
this considered mediocre?

------
buff-a
Another sign: not reading this article because you couldn't possibly be a bad
programmer and therefor this article can't have anything to offer.

------
madrox
There are no bad programmers. Just bad programs.

------
its_so_on
There is one surefire sign you're a bad programmer: faced with a problem, your
reaction is "pshaw, I see how I can solve this..."

Whereas a good programmer has the reaction, "uh-oh. I see how I can solve
this..." And knows that this is just half the battle, and what he's getting
himself into.

~~~
skizm
Oy, I used to do this all the time... till I stared sitting down to solve some
of those problems. That was about the time I started saying "uh-oh". I (think)
I have moved on from this phase fortunately.

------
kno
oh my! I love when you recommend specific career base on specific issues. You
made my day! I can't stop laughing. "Bag Lady" seriously looool

~~~
warmfuzzykitten
I agree with joe_the_user. I found the article snide and condescending. I
suggest alternative careers for the author:

\- Leader of a high school clique \- Movie reviewer who concentrates on who's
"in" \- Coiner of demeaning nicknames

I wouldn't want to work with this person.

~~~
crag
I agree too. I found it arrogant and very condescending.

But his alternative career section is humorous.

