Full Speed

I’ve never liked coding in a rush. You just don’t get enough time to put the right parts nicely into the right places, it really hurts the quality of the system. But as it gained in popularity, I often had no choice.

One of the keys to not letting it get totally out of control is to schedule the work dynamically.

When non-technical people interfere, they have a bad tendency to try to serialize the work and then arbitrarily schedule it. They like to dictate what gets done and when. That’s pretty bad, as the most optimal path is not intuitive.

The first point is to start every development cycle by cleaning up the mistakes of the past. If you were diligent in keeping a list as it was going wrong, it can be very constrained work. Essentially you pick a time period, a week or two, and then get as much done in it as you can. To keep the workload smooth, you don’t take a break after a release, you just switch immediately to cleanup mode and keep the pace steady. Steady is good.

Then I always want to tackle the hard or low-level stuff first. Hard stuff because it is tricky to estimate and prone to surprises; low-level stuff because so much is built on top, it needs to get there first.

But that type of work is often a lot of cognitive effort. Due to life and burnout, some days it is just too much cognitive effort. So the trick to rushing is to pace yourself; some days you wake up and want to do easy stuff. Some days you feel you can tackle that hard stuff. You don’t know until the day progresses. You alway keep the option to do both.

I usually keep two lists as I go, an easy and a hard one, so I can have off days where I just focus on mindless stuff. I switch erratically.

So long as I keep those two lists up to date, and the cleanup one as well, it is organized enough to now spin out of control.

This makes it hard to say what I’ll get done and when. It makes it harder to work with others. But it is me at full speed, cranking out as much as I can, as fast as I can, with the best quality achievable under the circumstances. It’s the price of speed.

I always say that we should never code like this, you’re never really going to get anything other than barely acceptable quality this way, but it has become so rare these days to get anything even close to enough time to do things reasonably.

I miss the early days in my career when we actually were allowed to take our time and were actively encouraged to get it right. The stuff we wrote then was way better than the stuff we grind out now. It really shows.