Hacker News Reader

Comment by Atrine | Hacker News Reader

> Leave work slightly unfinished for easier flow the next day

Years ago a sr. eng on my team would find root causes to bugs late in the afternoon and then just go home. When asked why, they said that they knew exactly what they were going to do first thing in the morning and that it got them straight into the flow state for the rest of the day.

I like this example better because understanding a root cause and not having it fixed is more concrete than "slightly unfinished" which is too vague for me to measure.

View on HN

I have done something like that at times. I find the bug in the afternoon. Now I have the satisfaction of having found it and don't want to risk the frustration of it not actually being the actual bug I found. So I saved it for the next day, to milk the satisfaction again, but also to be more fresh at it to fix it right and test it, or to better be able to deal with it not being the actual bug! Though my boss at some point was puzzled "why don't you just fix it now?"

Also taking notes to bridge the time gap, physically or even just in the mind, can help improve understanding. Could be described as rubber-ducking with a future self.

I've tried so hard to take notes about what I do, but I'm really bad at it.

> Though my boss at some point was puzzled "why don't you just fix it now?"

Unfortunately this also leaves your boss's job slightly unfinished, ready to jump start the manageering in your cube the next morning :)

>Years ago a sr. eng on my team would find root causes to bugs late in the afternoon and then just go home. When asked why, they said that they knew exactly what they were going to do first thing in the morning and that it got them straight into the flow state for the rest of the day.

This works, but also needs some notes with a "dump" (on the previous afternoon) of all relevant points. For some subtle bugs and complex codebases it's easy to forget some key point, even though you found what the main issue to fix is. So if you already know some subtle points/edge cases in the afternoon, write them down.

It’s a lot of fun leaving notes. When I’m working in the office and the next day is a WFH day I ssh in to my home computer and write my notes in a text file in the home directory. It feels like I am reaching through the computer to my desk at home.

I like this, too. “Slightly unfinished, but fully understood” is a great place to pick up. A “slightly unfinished understanding” of the problem or task at hand is a great way to nuke one’s mental model and end up stuck trying to recreate it in the morning.

But how do you really know if the problem is fully understood? I often think I’ve understood a problem multiple times, and only reach a true understanding through repeated testing and fixes.

Sure sure, but a complete but incorrect understanding of the system is, to me, still better than an incomplete one. If I have a complete system in my head, I can use that to jumpstart my thinking the next day and then get to a correct understanding. But an incomplete understanding is even more confusing the next day because of all the loose ends.

A complete but incorrect understanding is just an incomplete understanding with some extra confusion.

Sure, but the goal at the end of the day isn't to understand it fully, it's to have something that you can swap out and swap back in the next day.

Often, I find a good rest gives me greater understanding of a difficult problem or complex bug. Sometimes you get lost in the weeds. I also work much faster in the mornings, which helps.

Definitely. I’ve even had those magical moments where you wake up and realize you solved the problem in a dream. I think my preference is to have the major points of confusion cleared up so that they don’t become more confusing when I lose my mental model overnight.

This is the huge part. You found the bug, so your anxious mind is calmed, but you did NOT write the first fix that came to mind, so you have time to mull it over.

Often you realize sometime in the night that the first fix would have had other subtle issues.

And you’re less likely to throw a quick fix on in the morning.

A professor I worked with liked to stop work in the middle of typing something. “As if I fell asleep or passed out while working on it”, he said. And the next morning, kickstart the flow state by doing the very simple task of typing the rest of the unfinished word. Followed by the less simple but still straightforward task of finishing the sentence/line of code. And so on.

What if you're not working on a bug? If you're proficient, you should be able to measure the amount of work left in something so that it's "easily finish-able in the morning."

I did something like this yesterday. The only problem is that I spent all night dreaming of SQL statements to implement the solution. YMMV if you have trouble turning your brain off it seems.

Follow it further for a valuable interview question. Identify those who go rogue after hours, and select against.

Well, you can't always have something that specific to fall back.

In fact, it is better not to have bugs every day =)

Reply on news.ycombinator.com