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.
A trick to reaching flow: Leave your work broken
151–160 of 196 posts
Re: A trick to reaching flow: Leave your work broken
#152I'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…
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
#153Earlier 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 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
#154If 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.
It works surprisingly well!
Re: A trick to reaching flow: Leave your work broken
#155Earlier 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.
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
#156Earlier 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…
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
#157I'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.
Re: A trick to reaching flow: Leave your work broken
#158I 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
#159If 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…
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
#160It'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.