Hacker News Reader

Comment by wruza | Hacker News Reader

Not that I like to be interrupted, but if it’s inevitable, here is my method. I’m using it when interruptions are planned, when a task is complex by itself, at refactorings and on bad/lazy days.

Log all your key thoughts, realizations, decisions and taken steps on paper. It shouldn’t be long or long-term clear, only clear to today’s you. Gibberish to a bystander. Text, bullets, arrows, acronyms, verbs, marks, anything that works. Lists, trees, graphs, outlines.

It’s your L2 cache. L1 is fast but short and prone to distraction. If you log everything into L2, then returning to the task becomes much easier, because the whole context is right there.

The downside is you have to spend time drawing. The unintuitive upside is that by writing you may make it clear to yourself what maybe wasn’t clear.

IDE may be good at where you were, but it doesn’t know what you thought.

View on HN

> It's your L2 cache.

Stuff like this is why I love Hacker News. Rather than making up abstract, weird analogies between a thing, and another very abstract thing I find even more difficult to understand, we can make analogies to technical terms which most people here understand [citation needed], and which anyone who doesn't can easily look up.

> Log all your key thoughts, realizations, decisions and taken steps on paper... Text, bullets, arrows, acronyms, verbs, marks, anything that works. Lists, trees, graphs, outlines ... It’s your L2 cache.

This works out nice for using GPT4. If you prepare project information beforehand you can use it in your prompts. I am working on a way to structure my notes to be AI compatible. We can benefit from having to keep prompt materials for GPT, a good reason to have detailed notes in the first place and it's exactly the diff between general knowledge and project knowledge.

I’ve done this but it’s about 7 times slower than keeping stuff in my head.

My mental state isn’t easily capturable on paper since I use visual/spartial memory for programming. Witting it down requires enormous amounts of translation.

Here's my method, tell anyone who interrupts you to "FUCK OFF" because your busy.

This method is bound to get you trapped as a junior engineer who will never be as effective as you could.

Learn some people skills. Software exists for people.

My department head has openly told us to do this. He knows a distracted engineer is a bad engineer. He knows that most meetings don't need all the people in them. He told us to block off parts of the day that we COULD NOT be interrupted, and told us to reject meetings that aren't productive or valuable. He is also encouraging people to shorten meetings. He told us that if a manager expects you to work outside your normal hours, that is a bad manager.

"This will get you trapped as a junior" is just "All managers are terrible and we should never expect more". It's bad-manager apologism.

Once you’ve done that, you’ve already lost. Interruption encountered.

Reply on news.ycombinator.com