By Lars Magne Ingebrigtsen
- Programming is easy. Yet it takes so many people so much
time to make something that works.
- Programming is a craft. A programmer makes something that
has a use. Programming is seldom an art form. Art is
something that has no practical use. Programmers are not
- Quite a lot of programmers approach what they are doing as a
mixture of an art form and a hobby. They reject any tools
that distance them from what they are doing.
- If I do something myself from scratch, it gives me a
feeling of satisfaction. ĢI baked this cakeģ, or ĢI built this
complex Lego figureģ. If I used a cake mixture, it wouldn't
feel as satisfying. The cake wouldn't really be my doing. If I
bought the Lego figure pre-assembled -- what would be the point?
Creating something on my own fulfills a need. Creating
something on my own is important. It isn't important whether
the dinner I made isn't as good as the one I can buy in a great
restaurant. Making the dinner is the point.
- Using this hobbyist (or amateurish) methodology when creating
software is fine. It might not be as good as what you can buy
from a vendor, but it's fun and satisfying. Creating a
program from scratch is much more satisfying that using a GUI
builder and just plugging in a few lines of code here and
- If you see someone programming in C under VI, you see
someone enjoying their hobby. They are not working. If they
were working, they would use tools appropriate to the task
they were hired to do. C under VI is never the right tool.
- Hobbyist programmers will claim that they need control over
their code. Why they need to enter each space and brace
character manually is often left unanswered. Their need is not
- People who hire programmers want to use the software these
programmers produce. They did not hire people to have them
sit and twiddle their thumbs; or the C/VI equivalent: Start
VI; do a slight change; exit VI; compile; make note of where the
compilation failed; start VI; jump to that place in the code;
no, wait, that was the wrong place; exit VI; compile; start VI;
jump to the right place in the code; make another slight
change. People who program in this manner are hobbyists: They
haven't taken a professional approach to their jobs. They
haven't learned which tools are appropriate. They are like
cleaning personnel who clean floors with tooth brushes.
- The editor is the primary tool for programmers. People who
don't choose an appropriate primary tool are worthless as
- People who aren't programmers might well choose
inappropriate tools for what they do: For novelty reasons; for
fun; for any reason. It's not their job. They can be
- The edit/compile/test cycle is in itself
counter-productive. Using a rapid development environment like
Common Lisp makes testing an integrated part of the editing.
This gives you the result you should be after: Correct code
- Watching a master VI user can be impressive. The speed at
which some of these people can use that tool can be dizzying.
It's impressive in much the same way that it's impressive
watching a drummer do a really fast drum solo. Perhaps the
drum solo wasn't really appropriate, and perhaps the drummer
didn't keep the beat, but it's impressive nonetheless.
- People should work with the tools they are most comfortable
with. Standardizing one one tool for all people, for all
tasks, is counter-productive. Different tasks require
different tools. However, some tools are clearly
inappropriate for some tasks. Hobbyist programmers will
insist on using the tools they feel fit best with their
- Hobbyist programmers have a tendency to immediately optimize
the code they are writing. Instead of writing obviously
correct code, they will write obscure, unmaintainable code
that is very efficient, using some criteria or other. It will
either consist of very few characters, or it will take very
short time to execute. Sometimes both at the same time.
Professional programmers will write obviously correct code, in
a manner that is clear and maintainable. If it later turns
out that this code is inefficient, they will then optimize
- The first rule of programming is: Be lazy. Never optimize.
The second rule of programming is: Test. Profile. Optimize.