routine, practice, and software engineering

Routine is healthy. Animals and children need it. It's good for adults too. It can be taken too far but by and large, a routine can be a good thing.

Practice is laudable. It makes you better at your craft. It's just what you do when you want to be good at something.

Software, oh software.  Programming a computer is great because you write a thing once, and then THE COMPUTER DOES IT FOR YOU. You're done. You can check out. And the story of being a software engineer is the story of understanding problems, solving them in code once, and then letting the computer solve them from that point forward. If you never revisit your code, it might be because you did it right.

There's a disconnect here. As a programmer I'm attracted to the idea that I can solve a new problem every day, and accrue a mountain of functionality on which to perch, a labyrinth of routines and subroutines from which I need never venture. But if I ever succeeded, my very success would drive me mad from boredom. As a human animal I need the routine of solving problems. I need the practice to hone my skill. But my very success sabotages my own mental health. At large scale, it is a delicious psychological vignette.

dry

I like my martinis like I like my humor, like I like my application code:

DRY.

http://c2.com/cgi/wiki?DontRepeatYourself

but not too dry.

I read the gang of four design patterns book a while ago and I've been thinking about it a bit. Aside from the patterns, which are whatever, the actual premise of the book is really interesting, which is that these patterns come up again and again and again in software development.

That's difficult to reconcile with the DRY principle, or at least it admits defeat. It says, you will write this many times, so at least write it the same way each time, ok?

This is a little bit what I was trying to get at in the previous post; code reuse is a ruse. It almost never happens in the real world, at least not the way we want it to. As a programmer, I am chasing this fantasy that I will write a thing once, and then it will be Written, and I may Reuse it for the rest of my life.

But the fact is, code is actually easier to write than it is to read. So, six months from now when I've forgotten al the details of what I just wrote, I will happier to write it again than to try to understand what I wrote previously. Sad but true.

Taking that conclusion and applying it back to the DRY principle is interesting. It suggests limits on how seriously we should take the principle. I am actually a huge believer in DRY as a heuristic for class and module design. At a code level it makes a ton of sense. But over time, and over large teams, it breaks down. It may be worth repeating yourself, in order to avoid the hassle of creating a dependency. It may be worth repeating yourself, in order to create a new local version of the same knowledge. As broken as that sounds.

The result of making this compromise consciously is something in between code and data. "Script" is the closest word for it. I've been thinking a lot about the continuum of art-design-code-system-hardware, and it's interesting to me how different people gravitate to different points on the scale.

The people who live over on the right have a bad attitude, in my opinion, towards anyone to the left of them. I get to say that because I could be one of them, if I wanted to. So I tell myself.

programmer psychoses, better code

We deal in the abstract; it's in the job description. Think about the word "code" for a while.

Runaway abstraction is an occupational hazard. You can find lists of software design principles, and coding principles, laws, rules, etc., that are all aimed at giving programmers heuristics for writing "better code." As an occupational programmer, it is really really easy to start to believe in these heuristics.

But hey, sometimes a scripting language is the right tool for the job.
Sometimes there is no clear line between code and data.
Sometimes a hack is the right answer.
Sometimes an abstraction layer is a mistake, and sometimes it's a critical improvement.

In doing code reviews, especially for external teams / contractors, I'm in a curious position where I may choose to impose my heuristics on other people's code.

Each defect I log is a minor crisis of conscience, where I pass judgement, create work, and reject another professional's opinion. So I must weigh that cost against my belief that I am driving them to "better code."

The decisions are necessary and I make them quickly, most of the time. It's an interesting journey.