

Confessions of a terrible programmer - albertcardona
http://blog.kickin-the-darkness.com/2007/09/confessions-of-terrible-programmer.html

======
menloparkbum
_Humility is certainly something to strive for, however I disagree that you
should envision yourself as a "terrible" programmer._

One thing I've learned the hard way is that self-deprecation only works in
British comedy. In the USA most people don't get it and it not only damages
your career but your dating and social life, too.

~~~
yason
This is an interesting and apparently culture-dependent difference. Can you
elaborate a bit on this, please?

How it works, and why is it like that? What's the mentality behind people's
minds there? Does it hold for everyone, just geeks or everyone but geeks?

What do you have to say in order to look good? How truthful -- I mostly agree
with the article -- can you stay while still keeping other people thinking
you're good?

~~~
danohuiginn
Think of it as analogous to bling. If you wear lots of gold, drive a sports
car, etc, you're showing you've got enough cash to blow it on non-essentials.
If you're self-deprecating, you show that you have enough status to waste it
by downplaying your achievements.

~~~
yason
Sorry, I should have been more explicit; I meant the other way around.

The self-deprecating dynamics I get, the U.S. version I don't -- probably just
because of that :-) I would still appreciate thoughts on why and how?

------
hunterjrj
I enjoyed this article. Humility is certainly something to strive for, however
I disagree that you should envision yourself as a "terrible" programmer. Just
approach each problem as a student, not an expert.

I doubt Wayne Gretzky skated down the ice thinking "I'm a terrible hockey
player", but I do know that he was a student of the game and as a result, one
of the hardest working players both on and off the ice - with the results to
prove it.

~~~
albertcardona
Not just humility: the author goes on to explain all his practices to defend
himself from himself. These attracted my attention, for no programmer I know
enjoys them:

3) Be a testing masochist, i.e., I ruthlessly try to break my own code.

4) Have other programmers inspect my code.

The author goes on to explain how he approached fixing a broken program: to
stop catching errors and letting it crash. Which meant getting stack traces
and fixing them on the spot. Combined with his aggressive use of assertions,
no wonder he fixed it.

~~~
andreyf
_These attracted my attention, for no programmer I know enjoys them..._

Really?

Maybe I have competitive split personalties, but testing my code is a lot of
times more fun than writing it. And at least for junior developers, getting
feedback from those with more experience is probably the most valuable part of
a job.

It kind of blows my mind to hear that some programmers commit code they
haven't thoroughly tested, or avoid showing their code to other people...

------
anuraggoel
To me, the author is like someone who will never really learn to swim well
because he can't let go of swimming aids. Dependence on crutches like compile
time checking and programming assertions might let you fake it, but there are
more productive ways (and languages) to write working code.

1\. Compile time checking can't catch most non-trivial bugs. Even if you swear
by it, given the advances in Java IDEs, I would have to be quite lazy (or
careless) to write Java code that doesn't compile.

2\. Programming assertions - really? That's what unit testing is for. I like
his point about being a testing masochist, but it doesn't sound like he's
going about it the right way.

3\. Having other programmers inspect your code can be helpful, but to me it's
a luxury that you often can't afford.

 _"If I could bring this kind of a system to fruition, meeting all its
requirements and budget and schedule constraints, just by conscientiously
applying a slew of techniques for uncovering my programming failings before
they got into the final product, then I knew that I would be able to fake it
for the rest of my career."_

The author claims his techniques have allowed him to create a good end-
product, but at what cost? I could 'fake it' for the rest of my career, or I
could invest more effort in learning how to write better code faster in the
first place.

~~~
ellyagg
That's what unit testing is for? True, and do you understand the trade-offs?
Unit testing is far more time consuming than assertions. Moreover, you're
forced to write artificially short routines, routines of a length that
research has shown to have a higher defect ratio. For myself, I've not yet
been convinced that the costs/benefits of unit testing surpass the
costs/benefits of assertions, at least when you're a small team working on end
user software.

~~~
rimantas
"Moreover, you're forced to write artificially short routines, routines of a
length that research has shown to have a higher defect ratio" [citation
needed] So far I've only seen advice to write shorter routines.

~~~
ramchip
Indeed, I don't see how smaller, more manageable pieces would be more likely
to be defective.

~~~
jibiki
Somebody posted a study which showed, IIRC, that ~150 lines was the optimum
length for subroutines. I really should bookmark these things...

EDIT: Hooray for searchyc:

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

~~~
scott_s
If you upmodded it, it's bookmarked under the "saved" section of your profile.

------
jrockway
_If I can’t use Ada, well, then Java is the next best choice, since it’s got a
lot of the same built-in bug detection capabilities._

Seriously? Java has less runtime checking than Perl, and its compile-time type
checking prevents only the most trivial errors. If you want to talk about bad
type systems, look no further than Java. (Of course, the same could be said
about C++ and C too. There is even less of a type system there.)

~~~
likpok
The same could be said about C++. C is a weakly typed language and was
designed to be so, so it's type system cannot really be said to be 'bad'.

~~~
jrockway
Yes, good point. But a lot of people cite C as "the" strongly and statically
typed language, and that's just wrong. ("But omg, you have to say 'int i'
instead of 'var i'. Clearly this is strong typing!")

~~~
noamsml
C has no types, as a quick (int*)&var will show.

~~~
wingo
Unfortunately, this is not true in the case of type punning. C used to be the
language you used when you wanted to access bits. Now with C99 you cannot *
(int16* )((int32* )x).

NB, all compilers make exceptions for unions, but the type punning rule
stands, and at work we've actually seen code like the above (for a dynamic
typing system) compile to NULL instead of the appropriate reference with GCC.
Grrrrrrr.

------
visitor4rmindia
This attitude just wouldn't work for me - if I didn't feel like a great
programmer and I didn't enjoy coding/designing/testing/releasing so much I
would change my job.

Relying on tools and techniques may help me coast through my career - but
where's the fun in that? Tools and techniques are all well and good, but they
can't become the crutch you lean on.

And please, please - do try more languages than just Java/C/C++/Ada.

I program in C/C++ with a team of very talented developers. None of us are
humble, all of us believe we can be the best and we have a lot of fun. Plus
our product is great!

~~~
thorax
Well, I view it as a little different than _feeling_ like a bad programmer.
Basically-- you get to a point when you realize "The most important trick to
being an amazing developer is always sincerely doubting, checking, and double-
checking that fact." I feel sorry for developers who believe they're amazing
without that-- they won't truly be good until that feeling dulls somewhat and
they start verifying their code by habit as if they were newbie developers.

In my case, I view it more like how Socrates does: "One thing only I know, and
that is that I know nothing."

Design and implement as brilliantly as one can, but then use all the tools
available to protect oneself from the possible dumbass mistakes that humans
inevitably make.

~~~
visitor4rmindia
It's more fundamental than that - if you don't feel like a great programmer
then the techniques described (static checking, unit testing, code reviews)
become what you _depend_ upon rather than just tools of your job.

For instance, code reviews are __great __\- but maybe you can't use them in
your one-person startup. That shouldn't stop you from _still writing great
code_! It may be harder - yes, but you have to have the confidence that you
can do it.

I mean consider the author's dependence on static checking. There are a lot of
wonderful dynamic languages available (and a lot of great programmers in those
languages too!). The author - because of his philosophy of being a "terrible
programmer" is simply going to miss out on whole genres of languages and
techniques.

IMHO great programmers have confidence in themselves - just as in any other
field. Tools and techniques are really secondary.

EDIT: Grammar.

------
gne1963
Ok I admit that when I used BASIC back in 1979, I put GOTOs in my code.

~~~
blasdel
So what?

GOTO isn't evil, it just has no meaningful context without a comment or
convention. All the classic 'structured programming' control structures are
nothing but simple conjugations of conditional GOTOs -- what they provide is
idiomatic context.

~~~
parenthesis
E.g.:

    
    
      clisp> (macroexpand '(dotimes (i n) blah blah blah))
    
      (BLOCK NIL
        (LET ((I 0) (#:COUNT-2814 N))
          (TAGBODY
            #:LOOP-2815
            (IF (>= I #:COUNT-2814)
                (GO #:END-2816))
            BLAH BLAH BLAH
            (PSETQ I (1+ I))
            (GO #:LOOP-2815)
            #:END-2816
            (RETURN-FROM NIL (PROGN NIL)))))
    

(goto in Common Lisp is (go ...) )

------
yason
There's the thing between how good you think you are and how good you are when
compared to others.

To be honest if you're any smart you will, no matter what, eventually realise
that you're actually pretty bad. There's so much you don't know yet and lots
and lots of things that bug you because you know you could have done better!
This will keep you on toes which in turn makes you better than others.
Conversely, it'll be quite a shock to a smart person to realise that others
really aren't that smart, far from it.

This phenomenon has actually been studied: after doing some tests good
students tend to think they did bad and assume that everyone else is at least
on the same level, while bad students tend to think that they're actually
pretty good and then assume that most other people must have done it worse.

------
airlabam
As long as we're talking about programming and (teehee) ego-dissolution:
"There are two major products that come out of Berkeley: LSD and UNIX. We
don't believe this to be a coincidence." - Jeremy S. Anderson

~~~
miked
I enjoy the line and, living next door to Bezerkley, I take the point, but LSD
was invented in Switzerland (by Albert Hofmann) and Unix came out of New
Jersey.

------
awt
I didn't understand object oriented programming until I understood the limits
of my brain.

~~~
pistoriusp
I only started understanding it when I realised that it wasn't that important.

I think many young programmers are mystified by OOP because they feel as if
it's a magic bullet that's supposed to solve all of their problems. When you
start out trying to understand OOP you can't figure out how it's going to
solve those problems...

IMHO OOP has its place, I use it daily, but it's hardly ever my first approach
when trying to solve a problem.

