Live data from Hacker News

A trick to reaching flow: Leave your work broken

census.dev

171–180 of 196 posts

Re: A trick to reaching flow: Leave your work broken

#171

I thought the consensus was that "flow" isn't actually all that great. If you're writing code while juggling multiple difficult concepts in your mind at once, your code will be difficult to follow. While in flow, you tend not to take the holistic, bird's eye view and so work harder, not smarter.

I haven’t considered this but it makes perfect sense. If time is critical or if you are understaffed, it becomes required, however. I’ve prided myself on my ability to get so much done in a solid 8 hour flow state in the past, when it was necessary, but now that I have a baby and work at a larger company, perhaps I can take some solace in the concept you shared.

[deleted]

Re: A trick to reaching flow: Leave your work broken

#172

If I need to stop in the middle of something, I’ll often write directly in the source code, at the point where I stopped, exactly what I was working on and what to do next. I don’t comment out these instructions to my future self so when I sit down next, the project won’t even compile.

This works well near the end of the day or before a weekend too where you spend a few minutes dropping in a brain dump of context near the code you're working on so you can pick it up the next day and also avoid having to actively think about forgetting an important detail. This helps you enjoy your time away. A double win.

Re: A trick to reaching flow: Leave your work broken

#173
I don't necessarily do the "broken" part but always leave a note or marker for myself about where I left off (with special syntax highlighting). I write out thoughts and options as I go in my org file notes so it's useful for rehydrating when I come back.

Tangential trick: walk away more often, especially when in the more intense problem solving or architectural phases.

Re: A trick to reaching flow: Leave your work broken

#174

If I need to stop in the middle of something, I’ll often write directly in the source code, at the point where I stopped, exactly what I was working on and what to do next. I don’t comment out these instructions to my future self so when I sit down next, the project won’t even compile.

I write C++, so I use `#error start here, implement the FOO` It works surprisingly well!

Even easier with C-like languages: a bunch of blank lines above and below something like `xxxxxxxxx;` at the point I planned to continue working. Instant compile fail if I try to run and also very obvious on any "git diff".

Re: A trick to reaching flow: Leave your work broken

#176

Earlier quoted context omitted.

The failures I've experienced in 20 years of spending ~8 hours a day with one: - SSD failure within moments of getting started for the day - backlight failure - mouse/keyboard failure - human failure (spilling coffee on the computer) Each time, I was out of commission until I got a replacement or the computer repaired and someone else had to pick up my work. If your computer becomes a brick, it doesn't really matter…

I've had all these plus PSU failure, network adapter failure, OS post-update self-destruction and more. I push code a couple of times a day. If something goes horribly wrong I just pick up another computer, pull the code, and continue working while I wait for a repair/part for the main computer (or for an OS to reinstall). If your computer becomes a brick, just use a different computer.

That assumes you have another computer that isn't a brick. I have 6 other computers within this house, yet only one other one (my wife's) is currently functioning.

Re: A trick to reaching flow: Leave your work broken

#177

Earlier quoted context omitted.

I've had all these plus PSU failure, network adapter failure, OS post-update self-destruction and more. I push code a couple of times a day. If something goes horribly wrong I just pick up another computer, pull the code, and continue working while I wait for a repair/part for the main computer (or for an OS to reinstall). If your computer becomes a brick, just use a different computer.

That assumes you have another computer that isn't a brick. I have 6 other computers within this house, yet only one other one (my wife's) is currently functioning.

Yeah, true, I'm assuming most people here have old machines that still work. It's good to have one, if you don't!

My secondary is a 10-year old laptop which gets regularly used while sitting in bed in the morning, occasionally for actual work. The other backup is an old desktop I donated to my wife a few years ago, containing an unplugged SSD which is exactly as it was when I last used it. Both will still handle most of what I need, just a bit slowly.

Re: A trick to reaching flow: Leave your work broken

#178

Earlier quoted context omitted.

I've had all these plus PSU failure, network adapter failure, OS post-update self-destruction and more. I push code a couple of times a day. If something goes horribly wrong I just pick up another computer, pull the code, and continue working while I wait for a repair/part for the main computer (or for an OS to reinstall). If your computer becomes a brick, just use a different computer.

That assumes you have another computer that isn't a brick. I have 6 other computers within this house, yet only one other one (my wife's) is currently functioning.

Either you have been extremely unlucky, or a good time investment for you would be to fix a few of the non-working ones. That's likely a better use of your time than wondering how to leave notes to your future self.

Re: A trick to reaching flow: Leave your work broken

#179

If I need to stop in the middle of something, I’ll often write directly in the source code, at the point where I stopped, exactly what I was working on and what to do next. I don’t comment out these instructions to my future self so when I sit down next, the project won’t even compile.

[deleted]

Re: A trick to reaching flow: Leave your work broken

#180

Earlier quoted context omitted.

I also write in the code what I was doing so the code doesn’t compile. My only issue is that I don’t trust my computer, for me, if it’s not pushed in Git then it can disappear at any moment. If the work is not too important and I could easily re-create it from scratch the next day then I’ll leave it in my local Git. But if it’s important then I also want to push it.

Why is that a problem? You can create a branch called "in-progress" or something like that and push that to remote.

Draft PR's are nice on these branches to get a quick visual of the diff.

I self-review my draft PR's and catch all kinds of weird formatting, messy or missing comments, and general clunkiness before imposing it on others to review.

Post reply on HN