Notes On Programming

By Lars Magne Ingebrigtsen

  1. Programming is easy. Yet it takes so many people so much time to make something that works.
  2. 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 artists.
  3. 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.
  4. 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.
  5. 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 there.
  6. 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.
  7. 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 examined consciously.
  8. 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.
  9. The editor is the primary tool for programmers. People who don't choose an appropriate primary tool are worthless as professionals.
  10. 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 hobbyists.
  11. 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 produced efficiently.
  12. 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.
  13. 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 impulse.
  14. 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 it.
  15. The first rule of programming is: Be lazy. Never optimize. The second rule of programming is: Test. Profile. Optimize. Test.

2002-01-28 01:04:52