One of my favorite things to do:
Stop working right in the middle of something and leave the unfinished work for the next day. On the next day, you know exactly where to pick up and can start right away.
This week I managed to pull it off twice.
On Monday afternoon, we were hacking on performance improvements when someone interrupted us. At that point, all that was left to do was to fix compiler errors. Yet after the call, I didn’t fix them. I did something else instead. Tuesday morning, I unlock my screen, see the compiler errors, and start typing. Right back in it.
On Wednesday, I was trying to figure out where to make my code changes. Someone helped me out and told me about a mechanism in the codebase I didn’t know. With that, I knew exactly which code to write. But I only had about twenty minutes left in the day. I went and did something else, leaving the code untyped. Thursday morning I unlock the screen, the cursor still where it should be, and start typing.
I’ve shared this little trick before but I’m not sure where I got it from. I think it was Zach Holman. I don’t know whether it was in a talk or a tweet in which he shared it, but a search led me to his AMA repository in which he comments:
The best advice I have for that is to always leave your code unfinished the day before. That way I always know I can come back to a small problem that may only require three minutes to fix a test, or write a new method, or whatever the case is. Once I've been doing code for five or ten minutes, I tend to quickly become sucked into the problem and it's much easier to jump into the harder code at that point. Same rationale for stretching before doing exercise, basically.
Maybe I got it from this very comment — 9 years ago.
In the years since, I’ve come across the same trick in another context: writing — prose, not code. Hemingway, apparently, had the same habit. In a piece of writing published in Esquire in 1935 he had two characters say the following:
Mice: How much should you write in a day?
Y.C.: The best way is always to stop when you are going good and when you know what will happen next. If you do that every day when you are writing a novel you will never be stuck. That is the most valuable thing I can tell you so try to remember it.
Mice: All right
Here’s the crucial bit: “stop when you are going good and when you know what will happen next.”
Stopping in the middle of something when you’re confused about what to do — no good. You’ll start the next day sighing big sighs.
It only works when you know know what to do next, when you know “what will happen next” — that’s what you leave for tomorrow.
Joy & Curiosity
Last week I’ve linked to an article about Peter Miller’s book Shopkeeping. This week I can report that I read the book in one evening and it’s wonderful, wonderful, wonderful.
Cormac McCarthy on the Kekulé Problem. What a writer. I’ve read three of his novels and assumed (hoped) that McCarthy’s style — biblical language, barely punctuated — is so much his, that it’s foolish to try to measure up against him. Then you read this and think, god damn.
This long piece on Palmer Luckey was very good. I barely knew anything about Luckey going in. Going out I’m fascinated by quite a few things — Luckey, Anduril, the US defense industry.
Came across this blog post by a VS Code developer on “some snippets and links that I often refer to or refer others to”. I found it interesting for two reasons. One: some of the debug tooling described in there seems like it can save a lot of time. Two: you rarely see stuff like this — the things that are passed on from coworker to coworker — documented in a form like this.
I’ve enjoyed this blog post on "Consistently Making Wrong Decisions Whilst Writing Recreational C” a lot. What stuck with me was this line: “the best part about this is watching the output of make” — there is something about orderly and neat make output.
Patrick shared this with me a couple weeks back: Do the Real Thing. It resonates so much with me that I’m considering getting the whole thing tattooed (not really but you get it.)
Now this is what technical writing should be. There’s a first person, there’s a story, there’s technical details, it’s neatly formatted. Fantastic.
"May your writing week be better than Kafka's."
