The danger of having system programmers around, illustrated
December 11, 2010
My little issue the other day with DTrace makes a nice illustration of a variant of programmer laziness. As I sort of alluded to in the entry, although DTrace's function tracing limitation is documented, I didn't actually find it by reading the documentation. Instead I found it the hard and indirect way, by being a system programmer.
When I ran into a kernel function that DTrace couldn't trace, I wound up:
Only after all the dust settled did I read the documentation and lo and behind, there it was documented for me (twice).
(This is far from the first time that I've done stuff like this. For example, I've read through Linux kernel source in order to work out when and where a specific errno result was generated. More than once.)
Now, if you are the right sort of system programmer, all of this makes perfect sense. The problem with documentation, as any sysadmin will frequently tell you, is that it is often incomplete, unreliable, or in fact outright wrong. When you are a system programmer (or have that mindset), the easy way to answer questions is not to waste time reading the fine manual, it is to proceed straight to authoritative things like reading kernel source and disassembling code. If you can see how the system actually works, you don't have to trust the manual, and you only have to be burned a couple of times by bad or incomplete documentation before this seems like a good idea.
Which is exactly the danger of having system programmers around: we're perfectly capable of going very overboard before we do basic things like checking documentation, because we think of things like disassembling code and reading kernel source as the fast way to do things. Sometimes we're right, but sometimes we're very wrong.
(It's like people with hammers, where you know that sooner or later every solution is going to involve nails, or at least hitting things.)
Written on 11 December 2010.
* * *