#20 - Keep Knowledge in Plain Text
Plain text is made up of printable characters in a form that can be read and understood directly by people,
e.g: Fieldl9=467abe is meaningless, DrawingType=UMLActivityDrawing is better.
#21 - Use the Power of Command Shells
Every woodworker needs a good, solid, reliable workbench, somewhere to hold work pieces at a convenient height while he or she works them. The workbench becomes the center of the wood shop, the craftsman returning to it time and time again as a piece takes shape. For a programmer manipulating files of text, that workbench is the command shell.
#22 - Use a Single Editor Well
We think it is better to know one editor very well, and use it for all editing tasks: code, documentation, memos, system administration, and so on
#23 - Always Use Source Code Control
#24 - Fix the Problem, Not the Blame
Embrace the fact that debugging is just problem solving, and attack it as such. It doesn't really matter whether the bug is your fault or someone else's. It is still your problem.
#25 - Don't Panic
If your first reaction on witnessing a bug or seeing a bug report is "that's impossible," you are plainly wrong. Don't waste a single neuron on the train of thought that begins "but that can't happen" because quite clearly it can, and has.
#26 - "select" Isn't Broken
We worked on a project where a senior engineer was convinced that the select system call was broken on Solaris. No amount of persuasion or logic could change his mind (the fact that every other networking application on the box worked fine was irrelevant). He spent weeks writing work-arounds, which, for some odd reason, didn't seem to fix the problem.
When finally forced to sit down and read the documentation on select, he discovered the problem and corrected it in a matter of minutes. We now use the phrase "select is broken" as a gentle reminder whenever one of us starts blaming the system for a fault that is likely to be our own.
#27 - Don't Assume It—Prove It
Don't gloss over a routine or piece of code involved in the bug
because you "know" it works. Prove it. Prove it in this context, with this data, with these boundary conditions.
When you come across a surprise bug, beyond merely fixing it, you need to determine why this failure wasn't caught earlier. Consider whether you need to amend the unit or other tests so that they would have caught it.
#28 - Learn a Text Manipulation Language
There is a growing number of good text manipulation languages. Unix developers often like to use the power of their command shells, augmented with tools such as awk and sed. People who prefer a more structured tool like the object-oriented nature of Python. Some people use Tcl as their tool of choice. We happen to prefer Perl for hacking out short scripts.
#29 - Write Code That Writes Code
In the same way a woodworker invests the time in a jig, a programmer can build a code generator. Once built, it can be used throughout the life of the project at virtually no cost.
There are two main types of code generators: Passive code generators are run once to produce a result, Active code generators are used each time their results are required
Top comments (0)