5 ms·

The kitchen analogy is apt. Woodwork (shop work, joinery) too. I can think of people in my life for whom cooking without also continuously tidying is anathema

The kitchen analogy is apt. Woodwork (shop work, joinery) too. I can think of people in my life for whom cooking without also continuously tidying is anathema. It keeps the deck clear but at a huge efficiency cost. Some people just can’t stand untidiness, yet learning to live with mid-process untidiness — and the associated anxiety — is a big step towards being more productive. It is certainly not easy. When coding, I feel a great anxiety if I am mid solution and have a large amount of the current batch left to complete. It is as if I had taken a gulp of air and dived under the water into a cave. Batching involves being able to commit to living without safety checkpoints, and to be able to get a batch complete in the time allotted. If you don’t, you risk having a large pile of four-fifths completed batches.

frays 6y ago
Fantastic analogy.
madaxe_again 6y ago
I find it’s more like a kitchen where you start sautéing some onions on the hob, and behind you, the inactive dishwasher spontaneously belches water onto the floor, which you have to deal with now. While you’re disconnecting the water supply, your onions are burning, but just as you get back to them, the power goes out, and you have to go investigate. You come back an hour later, and resume cooking, when somebody knocks on the door, wanting to know how many squirrels can fit in a party balloon. You respond, go back to your onions, but the pan has inexplicably broken in two while you had your back turned. You get a new pan, and then you realise you are out of onions, and it’s 2am, and you go to bed, feeling you’ve accomplished nothing. Most context switching isn’t voluntary, and isn’t controllable.
twh270 6y ago
> When coding, I feel a great anxiety if I am mid solution and have a large amount of the current batch left to complete. This doesn't work for all types of coding, but I've found that TDD (test-driven development) helps a _ton_ with eliminating large batches, as well as reducing cognitive load. The trick with TDD though is that it's simple to learn, but hard to master. Another good practice is to reduce the "blast radius" of changes so that you're dealing with one thing at a time. For example, don't introduce a new type (class, interface) as a method parameter while implementing the new type while writing tests for it while changing all of the callers of the method to use the new type. One (small) thing at a time, and prefer to keep everything compiling and working except for that one thing you're working on. As for cooking etc., I differentiate between "tidy" and "clean". Mid-process dirty is common, but I strongly prefer to keep my working area relatively tidy throughout.

frays 6y ago

Fantastic analogy.

madaxe_again 6y ago

I find it’s more like a kitchen where you start sautéing some onions on the hob, and behind you, the inactive dishwasher spontaneously belches water onto the floor, which you have to deal with now. While you’re disconnecting the water supply, your onions are burning, but just as you get back to them, the power goes out, and you have to go investigate. You come back an hour later, and resume cooking, when somebody knocks on the door, wanting to know how many squirrels can fit in a party balloon. You respond, go back to your onions, but the pan has inexplicably broken in two while you had your back turned. You get a new pan, and then you realise you are out of onions, and it’s 2am, and you go to bed, feeling you’ve accomplished nothing. Most context switching isn’t voluntary, and isn’t controllable.

twh270 6y ago

> When coding, I feel a great anxiety if I am mid solution and have a large amount of the current batch left to complete. This doesn't work for all types of coding, but I've found that TDD (test-driven development) helps a _ton_ with eliminating large batches, as well as reducing cognitive load. The trick with TDD though is that it's simple to learn, but hard to master. Another good practice is to reduce the "blast radius" of changes so that you're dealing with one thing at a time. For example, don't introduce a new type (class, interface) as a method parameter while implementing the new type while writing tests for it while changing all of the callers of the method to use the new type. One (small) thing at a time, and prefer to keep everything compiling and working except for that one thing you're working on. As for cooking etc., I differentiate between "tidy" and "clean". Mid-process dirty is common, but I strongly prefer to keep my working area relatively tidy throughout.