I stumbled upon this blog post about how most of the time spent developing code is actually spent rewriting rather than actually writing, which actually fits the aphorism about how most of writing in general is rewriting. But the thing that he discusses is that this is a function of the fact that most developers can’t immediately grok what code is supposed to do just by reading it, and a lot of them end up trying to rewrite what has already been written, which, in my estimation, is a glorious waste of time.

In my mind, this is simply another example that most developers can’t properly comment on and document code to save their life, although perhaps it is also a sign that the particular high-level language they’re working in is not human readable. (C and C++ comes to mind, although I come from a background of learning to code in BASIC, Logo, Lisp, and Pascal and, God help us all, assembly, and the only thing that I know how to do these days is write Perl scripts, although I sometimes delve into the atrocity known as JavaScript, so take that as you will.) Whether or not this is applicable to real-life development these days, I grew up believing that if you can’t read your code, you’re simply not doing it right. Supposedly, well-written code is self documenting, and all you should have to do is read the procedure/method/variable name, and figure out quite easily what it’s supposed to mean and/or do. If you actually have to rewrite the code, that means that the guy who came before you really fucked things up, or that you are completely illiterate when it comes to this particular high-level language.

Of course, this may all be bullshit, because I don’t code for a living.

What I do do, however, is practice medicine, and I find that there is a lot of similarities here. Because most people who have medical illness tend to have more than one doctor, you’re forced to dig through old notes and lab tests that you didn’t order and you have to try to figure out just what the hell some other guy was thinking without necessarily being able to talk to him or her. And, let me tell you, the human body and human pathology is far less documented than computer architectures and high-level languages, and, frankly, we don’t run into this problem of having to reinvent the wheel each time. Sure, there are some that rewriting is done, in the sense that sometimes the plan has to be modified, but most of the time this is because new, unexpected data comes in, or because the patient just doesn’t want to do what you told them to do. (Imagine coders trying to deal with non-compliant adherent computers.) But even the most inexperienced physicians (such as myself) can rifle through some chicken scratches, glean what medications someone is on, and maybe even talk to the patient themself to figure out just what the heck is going on without having to start entirely from scratch.

Sure, the notion that reading about something is not the same as doing something is valid, but sometimes you have to make do with the reading (because in the beginning, all I ever really knew about heart failure was what I had read,) and you don’t have time with the doing (because recreating all the experiments since Galen figured out the cardiovascular system would be just a tad time-consuming), so ultimately, whatever is practical tends to win over whatever may be theoretically correct/proper, and practically speaking, you don’t have time to grok code by rewriting it all.

But I grant that the connection between writing code and treating patients is tenuous at best.

But again, a brief note: it always seems that whenever I get a new blog engine working, I find myself typing about all sorts of crazy minutiae. Eventually I will settle down some and not blog. I promise.