
The Humble Developer - terpua
http://www.forbes.com/technology/2008/12/08/cio-software-developers-tech-cio-cx_dw_1209developers.html?feed=rss_technology
======
swombat
_But back to laziness. A great programmer is lazy because he or she prefers
thinking through a solution to solve a problem rather than hacking through it,
which is way too much effort. Dick Vile, a developer I met at FAME Software, a
company founded by Larry Rafsky, put it this way: "What do I use to do my
programming? A pencil." Thinking things through, coming up with a great design
and then doing the coding is the way a real smart, lazy programmer does
things._

The article is interesting on the whole, but this point falls flat on its
face, in my humble opinion. Some up-front thinking is always required, but
aiming to have the whole thing thought through before you start coding is
terribly wasteful - if only because you will always get (sometimes quite
important) parts of it wrong because non-trivial systems are too complicated
to hold in your head in their entirety while creating a new design.

Also, he's only got one third of the picture with laziness. As Larry Wall
said, the *three greatest qualities of a programmer are laziness, impatience,
and hubris ( [http://cranked.me/2008/07/laziness-impatience-hubris-
three-g...](http://cranked.me/2008/07/laziness-impatience-hubris-three-
great.html) ).

Humility is in direct contradiction with one of them and in indirect
contradiction with another. I personally feel that those are still more
important qualities than humility when it comes to being a great programmer -
which, I hasten to add, is very different from being a great designer... that
requires far more humility.

~~~
krakensden
I think more importantly [with regards to humility] that while it's important
to talk with your users, you still need to be hubristic. His reason for being
humble is this:

There is a huge payoff for being humble about your ability to understand
software requirements. In Agile methodologies, the goal is to get users a
working program as quickly as possible so they can try it and tell you what
they really want

But you still need to be a bit of an arrogant dictator and remember that just
because users tell you what they really want, doesn't mean they really want
that. Which doesn't really map to hubris I guess, but it certainly isn't
humility. GNOME 2's `draining the swamp' effort comes to mind.

------
creativeembassy
This completely contradicts what I was taught about being a lazy programmer.

Laziness, to me, means that you only type the code that you need to
(essentially the DRY principal, Don't Repeat Yourself.) Beginner programmers
are 'eager', they want to continually pound the keyboard until the program
does what they want it to do. Lazy (senior?) programmers carefully decide each
line of code that gets included, because they don't want to have to repeat
themselves or throw out code that wasted their time.

Maybe someone can clarify my thoughts better. But being lazy does not mean
waiting to code until you have the entire idea in your head. Programmers who
do that typically miss the mark of what their users want.

~~~
raju
Again, mostly yes. Another way I look at a "lazy programmer" is in the way of
how a developer works. If a "lazy" developer has to do the same thing 3 times,
then they will figure out a way to automate it.

A "lazy" developer also tries to find the best tools for every job, and
figures out how to best leverage those tools for maximum productivity and
least effort. Whether it be the right language for a task at hand, to using
macros and powerful editors (to perform "surgery" on text [I quote Yegge
here]) to learning keyboard shortcuts for their IDE of choice so to minimize
hand movements etc.

This also applies itself to not violating DRY, to thinking about higher level
of abstractions so as to reuse code better, writing modular functions that are
easily accessible and do not violate the Principle of Least Surprise.

I know I am missing a lot here, but in conclusion, I agree with you about the
article.

------
biohacker42
That article couldn't make up its mind.

First it endorses XP and Agile's frequent user interaction and iterative
development over big upfront design. And then it criticizes XP and Agile for
not doing enough design.

In summary, extremism is bad, so be moderate and smart.

------
gruseom
I know I should respond to the content of this article, but:

    
    
      Dick Vile, a developer I met at FAME Software
    

_Dick Vile_? That has to be a punk rock singer.

Edit: Ok, a comment on content. Perhaps I'm expecting too much from _Forbes_
\- who had any idea they publish columns on software? - but really, an article
called "The Humble Developer" that goes on about the 1970s and doesn't mention
Dijkstra... just really.

[http://www.cs.utexas.edu/~EWD/transcriptions/EWD03xx/EWD340....](http://www.cs.utexas.edu/~EWD/transcriptions/EWD03xx/EWD340.html)

------
mironathetin
To me this sounds very much like the waterfall model: read requirements,
think, write, done.

This has a long, long beard.

------
awt
I did not know Eric Von Hippel's work was a source of some of the agile
methodologies. That is interesting, as the guys in Portland (Dave Thomas et.
al) seem to be the biggest influences in design right now. Nice to hear from
the originator.

