1. 14

  2. 7

    This reminds me a bit of a technique Joe Armstrong mentioned, maybe in an in-person conversation at a conference or maybe more publically, I forget. He said that he will throw away code that takes him more than one day to write, and either start over the next day or do something more important. His justification was that if it takes longer, the approach is probably shit. At the time, I thought it was a pretty extreme approach, and just made a mental note of it and moved on.

    After spending the last year+ making a reasonably well tested database, I’ve caught myself having taken on this approach myself, arriving at it after an endless series of devastatingly complicated bugs that have deeply humbled me. It was quite a surprise when I realized it was exactly what Joe had mentioned, that I didn’t really believe was an effective strategy at the time.

    Why do this? For me, it keeps the complexity manageable. If I can’t keep the whole thing in my head when I’m creating it in one shot, there’s very little chance I’ll be able to debug an issue in it in under one or two days. I will create far more bugs when I can’t wield the model of it easily in my mind.

    How long do you want to spend debugging an issue in a system? Combine this approach with bwk’s “debugging is twice as hard as writing a program in the first place” rule of thumb and throw the whole thing away when you get to 1/2 of your desired debugging budget!

    1. 6

      Small joys of full ownership over your product, indeed.

      This way of writing hardly applies to a large codebase with hundreds of people working on it every day without clear ownership boundaries.

      1. 3

        To some extent I already do this: when I start work in the morning I browse the commit logs for yesterday’s work to remind myself what I’ve changed and what needs to change, and read files with unstaged changes. Other coping strategies include leaving myself failing tests at the end of the afternoon, and (in C-ish languages) #error messages indicating incomplete work.

        I don’t, however, fully re-read the project I’m changing, and that could significantly change how I work as the holistic view of the system sinks in over time.

        1. 2

          Gibson in that same interview talks about his schedule:

          …As I move through the book it becomes more demanding. At the beginning, I have a five-day workweek, and each day is roughly ten to five, with a break for lunch and a nap. At the very end, it’s a seven-day week, and it could be a twelve-hour day.

          Toward the end of a book, the state of composition feels like a complex, chemically altered state that will go away if I don’t continue to give it what it needs. What it needs is simply to write all the time. Downtime other than simply sleeping becomes problematic. I’m always glad to see the back of that.