
Signs You're a Crappy Programmer (and don't know it) - hhm
http://damienkatz.net/2006/05/signs_youre_a_c.html
======
DarrenStuart
I think it should have been "Signs you are a day coder (and don't know it)"

I am amazed how many programmers I have worked with who are not up to date and
just do their job and are not interested in it.

------
at
"You are adamantly opposed to function/methods over 20 lines of code."

There are (at least) 2 problems with long funtions/methods: 1) They typically
lead to more duplicated (and less reusable) code, e.g. repeated blocks of code
between functions that could have been replaced with to-the-point short
functions. A typical sign of where to extract a function is when you see a
long block with a comment above it inside an even longer function, then
replace the block with a function with a name inspired by the comment.

2) The methods becomes harder to test, and possibly even more important, the
test code becomes harder to maintain (and untested code of some complexity
usually doesn't work), e.g. what happens to your existing tests if you add
some new conditions at the top of a long method?

~~~
Tichy
A good argument might be chunking: the (average) human brain can keep only
about six or seven chunks of information in short term memory.

A method with 20 lines of codes is roughly 20 chunks. Move some parts of those
20 lines into other functions, and you have created more effective chunks.
Presumably, the brain has a much easier time understanding things it can
actually keep in memory.

One idea is to create functions instead of comments, that is instead of
writing "compute the rank" followed by some code, create and call a method
computeRank().

------
edw519
10 Real Signs You're a Crappy Programmer:

10\. The exact same code is in multiple places because you didn't bother to
put in into a common function.

9\. You have error codes in functions, but never bother to look at them (a
sure sign that testing was never finished).

8\. You have early exits from loops because you don't know how to properly
code a recursion.

7\. You execute too much code because you don't know the difference between
"if" and "case".

6\. You use 10 lines of code when 1 line would do because you don't know any
better.

5\. You need to run batch jobs from time to time to clean up your data base
because you don't know how to debug well enough to find what's messing it up.

4\. A third grader doesn't know what your variable names mean.

3\. You think "Third Normal Form" is paperwork you need to fill out for one of
your 8 bosses.

2\. No programmer who has to maintain your code would ever want to work with
you.

1\. Any programmer that has to maintain your code would be more than happy to
accept the consequences of first degree murder.

~~~
Goladus
(6) Happens even when you know better.

(10) Good programmers don't repeat themselves, true, and to continually
improve as a programmer it is important to patiently do everything correctly
the first time. However, obsessing over a few bits of code duplication is
often a complete waste of time.

~~~
edw519
"...obsessing over a few bits of code duplication is often a complete waste of
time."

For you, maybe. But what about the guy who applies enhancements 3 years later
and has trouble getting through testing because the exact same code was
somewhere else and difficult to find because of the 67 mods since then.

Minutes "obsessing" today usually saves hours testing tomorrow.

~~~
Goladus
"Minutes "obsessing" today usually saves hours testing tomorrow."

True, but the app has to make it to tomorrow for testing to matter at all.
It's better to be in the championship trying to figure out how to manage a
tired team, than it is to conserve energy during the semifinals and wind up
sitting in the bleachers.

~~~
edw519
Where'd you ever get the idea that there is any trade-off between "quick" and
"right"?

Doing things according to effective established principles saves a little time
today and a lot of time tomorrow.

Quick and dirty usually ends up being neither.

~~~
Goladus
_Where'd you ever get the idea that there is any trade-off between "quick" and
"right"?_

I don't have that idea. There is sometimes, though, a tradeoff between current
needs and future needs; and that tradeoff can not always be predicted. When
that happens, it's logical to give current demands priority.

I can't for example, predict whether a future maintainer of my code would
prefer code written with multiple returns, or code that sets temporary values,
or code that uses a set of nested ifs, or code that assigns function pointers
to a matrix and calls code based on the indices. Each technique has potential
drawbackss in terms of future maintainability, likelihood of errors, and speed
of immediate implementation. Trying to guess what a future coder (other than
myself) will think is just not important in that case.

Effective Principles can only be Established based on a given development
environment, and it's the responsibility of those in charge of the environment
to make sure the established principles are effective and followed by the
developers.

------
edw519
"...and it often simplifies the code to have multiple returns."

Today. And what happens after 10 other programmers modify your slick little
multi-return function? Nobody will ever be able to modify it again because the
entries and exits are lost among the garbage. This is the ongoing debate I've
had for years with "clever programmers". They're missing one critical point:
the guidelines of structured programming are not meant to make your life
easier; they're meant to keep the code alive longer by making life easier for
the poor schmuck who has maintain it (usually me).

Another Sign You're a Crappy Programmer:

You make your own rules in direct violation of effective established
principles because you think you know better.

~~~
BitGeek
The number one sign you're a crappy programmer:

1\. You foist idiocy upon others and refuse to listen when they point it out
as such, because someone told you that the idiocy was "effective established
principles".

Your "effective established principles" seem to be neither effective, nor
established, nor principled.

~~~
edw519
"neither effective, nor established, nor principled"

<http://en.wikipedia.org/wiki/Structured_programming>

Isaac Newton "stood upon the shoulders of giants." Interesting to see that you
know better.

\-----------------------

"...someone told you..."

Actually, I learned what I'm sharing in this thread (and much, much more) from
MANY excellent mentors. I hope you find some, too.

\----------------------

"The number one sign you're a crappy programmer"

I have hundreds of (well paying) clients that would disagree with you.

\----------------------

I "foist" standards only upon those who work for me. You won't ever have to
worry about that.

------
mironathetin
You know that you are a lousy programmer (and also lousy at doing other
things) if you start to make rules although smart people know:

\- rules are for people who cannot think

\- every rule has a context where it fits perfectly, but

\- every rule has many contexts where it doesn't fit at all

Rules only reflect your current knowledge and your current working situation.
This is subject to change.

------
edu
Oh, well I'm not crappy then. Neither I'm a good one though...

------
BitGeek
I expected this list to be written by a crappy programmer who didn't know
it... but it turns out it isn't.

I'll add two items to this list:

1\. You believe anyone who doesn't write unit tests is a crappy programmer.
(I'm done trying to explain this to carppy programmers- not only are they
crappy they think that unit tests make them not crappy, and so they can't
concieve of the reason unit tests are bad (and often they are...) If you want
to write unit tests for yourself, that's fine, but if you've ever told someone
else that they should write unit tests, you're a crappy programmer.

2\. You believe in Scrum. Like global warming, Scrum is a religion... back in
the old days, when programmers had to actually program, we used to use the
"daily status meeting" as an example of the height of absurdity that pointy-
haired-bosses could achieve. Now crappy programmers think that it makes them
less crappy. (No, it doesn't, it actually means your code is crappy...
especially if you think scum is an improvement.)

Really.

I know I am speaking crazy talk-- at least most programmers under 30 seem to
think its crazy talk-- but it isn't.

The reason we have crappy programmers now? I think its cause they are going to
colleges and getting CS degrees. Back in the "old days" when you had to write
code to become a programmer, when you had to learn and you cared about getting
things done well, we had to self teach and the learning curve was higher....
nowadays really crappy programmers train crappy programmers by the ten-score
at universities who's primary goal is separating fools from their money (and I
mean any university other than maybe caltech and MIT this applies to.) and
they just teach really crappy programming practics. Those that can do, you
know.

Speaking of which, you gotta be poor at math to go to univeristy in the first
place-- teach yourself and start working right out of high school, after 4
years you're senior software developer, you're much better than the people who
have been taught bad practices at university, and instead of being up to your
armpits in debt, you'll have a good job and a great income... and four years
later- a8 years into your career and 4 years after your friends got out of
college, they might have paid off their student loans but you'll still be
making twice what they were.

But then, I'm expecting to get pounced on because this is a site full of
university grads. :-) Sorry, this has been my experience, and I've interviewed
a LOT of programmers in my time.

In fact, I've found that PhDs in CS are useless, Masters in MS are good for
grunt work, if you watch them close but generally shouldnt' be hired, and
people with jsut a BS degree can usually be retrained if you can get them
focused... if they get a job at a big corp right out of school, though, they
are lost forever. (Most of them anyway.)

All the really brilliant programmers I've known didn't go to college. (BTW, I
did, so I know first hand it was a waste of time.)

Anyway.....here's a bonus "how to know you're a crappy programmer":

You're a crappy programmer if you think while (foo) { stuff }

is wrong because the curly brace goes on the same line as the while. Generally
,the sloppy programmers who think they are really productive but produce
nothing but shite are adamant about that... the ones who think about what they
are writing and are useful, put the brace on the next line.

Really should use that as an interview question.

~~~
DanielBMarkham
I think it's about time somebody stood up for the "curly braces stand alone"
school.

I mean, we can debate silly stuff all day, like LISP versus C, Firefox vs. IE,
Mac vs. PC, web 1.0 vs web 2.0, etc. But these "braces on the same line" guys
are just completely out of their minds. :) <\-- Smiley face means humor was
used in this comment.

~~~
Tichy
I've seen whole projects fail over that discussion.

Maybe it really should be used as an interview question. There is no point in
mixing same-liners and new-liners together.

Only remedy might be to use a programming language without curly braces.

~~~
DanielBMarkham
I have to admit it's a pet peeve for me -- even more than choice of languages,
oddly enough. When scanning code, I just like the ability to see my control
blocks clearly. Simply because you can do something like this

    
    
     if (a==b) { doStuff(); } else doOtherStuff();
    
    

Doesn't mean you should.

I would consider this a little bit of a hangup on my part, though, as it seems
other programmers go the other way. An interesting topic for a book is all the
weird things programmers get hung up about. Variable naming comes to mind, as
does error handling strategies. And when we get hung up, usually we're not too
shy about explaining why everybody else is wrong!

~~~
Tichy
I would not put everything on the same line, but I admit to putting the
opening bracket on the same line. In fact, I consider the other variant
extremely ugly. Just consider

    
    
      if(...)
      {
        ...
      }
      else
      {
      ... 
      }
    

vs

    
    
      if(...) {
        ...
      } else {
        ...
      }
    

I can't for the life of me understand why someone would want to move the
bracket to the new line ;-) It's just empty (wasted) space without any
meaning. I can see the control blocks with the tighter version just fine,
plus, it's the Sun Coding Convention for Java. But it's really a fruitless
discussion...

~~~
jamongkad
I on the other hand find this quite elegant

(...) ? $doThis : $doThat;

------
edw519
My follow-up thread:

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

