Live data from Hacker News

A trick to reaching flow: Leave your work broken

census.dev

151–160 of 196 posts

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

#151

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 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.

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

#152
post #6

I've been using this "trick" for many years. An old mentor taught it to me, but he called it "park facing downhill". The idea is to leave the workday with the work in a state where there's an obvious and easy task to start the next day with, like parking your car facing downhill so that gravity will get you rolling before the engine is up to speed.

As an engineering director years ago I had the rule that engineers hours were 10am-6pm, and I'd walk around the office at 6pm and send people home. I'd get complaints that I was making people stop when they were in the middle of something, and I'd just say, you can carry on with it in the morning. It worked extremely well. Engineers just wanted to get on with their work as soon as they arrived in the morning. We'd ha…

I'm currently in a team that works pretty much 0800-1600, people mostly start logging off 15 minutes before four and after four everyone is either at home or packing their stuff. (Or playing a game if they're WFH :D )

There's zero pressure to work overtime and leaving on time is encouraged. If people work late, we encourage them to leave earlier and relax. Not all tasks can be solved with brute force head smashing.

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

#153

Earlier quoted context omitted.

> Maybe they were in the middle of something hard that's difficult to pick up from. Certainly some of them said that, and I had to push for them to leave anyway. I also feel like that when I’m coding myself sometimes. But I think the of times when it’s actually true are vastly outnumbered by the times when it’s just an illusion, and it was obvious from the velocity and energy level that the policy worked.

I think this also creates a culture or at least impression of a culture that your boss cares about your work life balance, which, honestly, in today's world is valuable and can make your org stand out from other places where the norm is to work until you're burnt out.

I don’t do offices, but I worked 2 extra hours last night to finish a train of thought. Today I won’t start until 3 hours after normal time and will play villainous with the kids (when they emerge)

I don’t get paid for presenteeism, I schedule my own hours. If someone was telling gme I couldn’t work after I wake up at 2am with a breakthrough, that’s as bad as someone saying I couldn’t stop work at 2pm because it’s a lovely afternoon and I fancy a bbq.

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

#154

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!

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

#155
post #146

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…

Still if you worked on something whole day you should have commits that someone could pick up. Let’s say that last note of the day does not have to go to repo. But I would expect some commit chain that would be useful produced and pushed.

Personally, I very rarely push commits unless I’m about to open a PR.

A coworker fell off a ladder and broke both his arms. We had to look at his commits to figure out what he had gotten done. It was worthless. Absolute trash. His finished code was always top notch, but his WIP code … trash.

It was easier to ignore it and start from first principles than to try and pick up where he left off.

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

#156

Earlier quoted context omitted.

> Maybe they were in the middle of something hard that's difficult to pick up from. Certainly some of them said that, and I had to push for them to leave anyway. I also feel like that when I’m coding myself sometimes. But I think the of times when it’s actually true are vastly outnumbered by the times when it’s just an illusion, and it was obvious from the velocity and energy level that the policy worked.

> But I think the of times when it’s actually true are vastly outnumbered by the times when it’s just an illusion, and it was obvious from the velocity and energy level that the policy worked. I agree, and relates closely to the YAGNI philosophy ("You Aren't Gonna Need It") [0]. It's easy to think, "I'm so close, it'll be easier just to do it now". But what's so special about now? Are you really that much smarter rig…

> But what's so special about now? Are you really that much smarter right now than you will be tomorrow (or next week, month, year..)? More knowledgable? More prepared?

Obligatory executive dysfunction angle: the special thing about now is that I'm doing the thing. Once I stop, it will take me anything between 2 hours to 2 days to start again.

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

#157
post #6

I've been using this "trick" for many years. An old mentor taught it to me, but he called it "park facing downhill". The idea is to leave the workday with the work in a state where there's an obvious and easy task to start the next day with, like parking your car facing downhill so that gravity will get you rolling before the engine is up to speed.

Park facing downhill is a practice that is far broader than maintaining programming flow overnight, or even broader than programming itself. I use it when working on slide decks for presentations, when writing technical documentation, when finishing up meetings (setting the stage for the next one), when designing architectures. I use it even when managing my todo list itself, where I try to always leave myself obvious next tasks to do, or add all the info I need to get going quickly when entering the todo (or as close to entering it that I can find the time). It sounds like a lot of work but it’s really not because I can be pretty concise writing for an audience of one.

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

#158
This is exactly what I do! I just came back to a repo I haven't worked in for a couple of days, checked out my working branch, ran a `git stash pop`, ran the tests and there's a failing test case waiting for me to fix. Feels good to know exactly where I left off before.

I also often leave a // TODO comment with some rough bullets for next steps. Works for me!

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

#159
post #118

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 is the way. The only way I can stop coding and stay comfortable when it’s getting late, especially if it’s something even mildly interesting, is to do a borderline incoherent mind dump and break the linter/formatter. Just all my thoughts, what I was working on, other places I may need to change code. I usually end up closing the laptop before I describe the why , but the act of writing it all down usually makes…

Yep

Couple of, retrospectively, often almost incoherent sentences to capture top of mind state when I give up because it’s late.

I’ll write this gibberish comment here because I’ll definitely forget what I was doing and if the compile fails I probably won’t miss it!

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

#160
post #44

It's too effective. I end up sitting at my computer to watch a movie, and end up finishing work in the evening. I'm nerd sniping myself, and it's not healthy. Then in the morning the madness continues. I want to make room for other things in my life. I have to Cm+Q everything in the evening.

There are quite a few solutions for this. You can do your work stuff in a VM that you just turn off and it's gone for the rest of the day. You can get a second computer for non-work programming. Or if you don't need that much compute in your free time, get an iPad. It's great for your evening articles, YouTube and Netflix.
Post reply on HN