Pretty Fast

Print out your stuff. Take a step back and squint. Can you still see structure, or is it all a blur? What if you pasted the thing on the wall and stood back ten feet; could you still recognize functional pieces? What if you could spot something wrong? Wouldn’t that be an interesting find?

Good stories have beginnings, middles and ends. There are plot arcs, there is tension, there are scary bits that you want to rush through and fun bits that you want to re-read. Why don’t we do this with programs? Why are most pieces of code train-wrecks of organization, ideas smothered beneath syntax, no damned plot, nothing re-written to an editor’s advice, and tough as nails to revise?

Why aren’t most programs pretty?

– – – –

An ex cow-orker of mine used to design chips (this was back in the 80s when you could still do it by laying out transistors, more or less by hand). He’d cobbled up a content addressable memory cell for a memory translation unit he was working on and wasn’t really happy with the result, so he decided to get help from a more experienced “career” chip hacker.

She was a cheerful middle-aged lady in another building, where the real chip designers were. She took his design, nodded, gave a gentle smile, then started twiddling. An hour passed, during which she did amazing things with his design. The result was half the area, half the power consumption, twice as fast, and stood a chance of working with the company’s fab process.

“How’d you do that?” he asked.

She smiled again and said, “I go for pretty.”

Style matters.

– – – –

If something isn’t clear, why bother? Term papers are double-spaced for a reason. Use whitespace. Organize. Name things well. Think of how much you hate to debug crabbed scribbles and decipher a half dozen names for things, all subtley different. Think of the awful code you’ve dug into, and how it got that way.

If something is inherently hairy, don’t make it worse by leaving it messy.

A lot of code doesn’t start out awful, but it gets that way. I hate the word “refactor,” because it drags in too much of the current XP culture surrounding it [“verbal documentation,” my ass!], but as with any religion there are useful bits. Steal them. Rip out messy pieces. Don’t say X when you really mean Y. Examine. Criticize. Decouple. Measure! Make notes for improvement. Maintenance isn’t about just fixing bugs. If you find yourself adding extra features “just in case,” those are the areas where most of the problems are going to be found. Resist temptation. Be spare, be direct.

When motorcycling, I find that if I keep things smooth I wind up going faster as a side effect. “Going for fast” is a sure way to get herky, scary results. “Going smooth” — planning curves, watching throttle control, shifting and braking — getting all the little things right is my way of having fun; if that speeds things up as well, that’s a fine thing.