▲ 572 points
back
190 comments
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 have a 5 minute literal stand-up that really did only last 5 minutes because people were so impatient to get on with what they had put down the night before.
The policy had to stop when a new VP was hired who valued presenteeism and the appearance of hard work over focus and energy.
Similarly, I find it effective to simply writing down what the next step is, and what’s interesting/challenging about it in a couple sentences. It seems to directly solve the problem that this “trick” is indirectly solving, which is reducing the load of knowing how to get started next time.
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.
(author here) "park facing downhill" is an excellent TL;DR - I'm definitely stealing this!
> park facing downhill
I like that expression, but this could also mean leaving things not broken, but in a ready state for the next phase.
Personally I don't like logging off with things broken. I like logging off with things in a good state so I can jump in next time knowing everything up to this point is good.
Excellent advice, just like the article as well.
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 that come back before I’ve finished reading the first few words the next time I revisit it. I’ve found this remarkably effective to the point I often just do a mind dump the moment I feel tired at all, and end up in a better place than if I kept pushing.
I write C++, so I use `#error start here, implement the FOO`
It works surprisingly well!
I don’t usually leave notes, I just leave the last thing I looked at in whatever arbitrary failure state it was in, unsaved, with whatever undo history I stopped at. If the errors aren’t immediately obvious, a couple cmd-Zs is usually all it takes to jog my memory and at least start retracing my steps
"Go Home Red" is a slogan I've heard tossed around the length of my career, meaning "leave a unit test failing overnight." It's trivial if you're practicing TDD, since most of your time is spent coding against a failing test. A failing test really expands your short-term memory, ameliorating interruptions like meetings, Slack messages, and having a life.
Regarding open loops "living rent-free in my head," preoccupation with work outside work can certainly be a health hazard, but I have never found `git push` to reduce those ruminations. If engaging hobbies and loving community don't do it for you, maybe some mindfulness meditation might help "let it pass."
That being said, I am not super disturbed if even my dreams are infiltrated by the dayjob on occasion; I don't bill hourly.
Never stop until you know what you are going to pick up with next.
https://www.fastcompany.com/3021905/hemingways-secret-to-mai...
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.
This trick is also known as the Hemmingway rule.
It is a way to fight anxiety by starting with something your brain is convinced it can get done easily. And then get the ball rolling thanks to the increased self-confidence.
The opposite is finishing your day on something painfully difficult and not solved.
Instead of “// TODO” I just add “TODO” or “asdf”, suffixed with a short description of the next thing I’d like to tackle. That gives a compiler error so I can find the relevant line very quickly next time I work on that project.
“Stop in the middle of a sentence, leaving a rough edge for you to start from the nest day – that way, you can write three or five words without being “creative” and before you know it, you’re writing.”
— Cory Doctorow
> Exiting after hitting a “neat” stopping point - unless the task is done, leaving the system / code too clean makes it hard to know what to work on next. While it’s really tempting to try to stick the landing on an internal milestone, it can often be more productive on net to stop just short of a neat milestone as an onramp to your next coding session.
I have heard novelists talk about similar strategies: end your writing day knowing what the next thing you need to write is, but not actually writing it. So, the next day, you can sit down and get going immediately, and use that momentum to launch you into that day's work.
I think I do the opposite. I most often reach a flow state when there's something wrong, and I'm trying resolve it. It's repairing the broken state that absorbs me. When I get to that resolution, the challenge is having enough self-awareness to stop: I look up, and afternoon turned into night, my shoulders are cramped, my neck hurts, but hey why not keep this going?
Even after resolving the problem, the overall state of the application is still "broken", i.e. incomplete, so I always have something to bring me back.
The thing for me, as a former-professional programmer, current hobbyist, is that it's easier to reach a flow state if you care about what you're working on, and get wrapped up in it. If you're working on some corner of an application you don't care about except for the paycheck, you probably have a harder time getting motivated. So, what works for me may not work for everybody.
Another hack I had read about and found out it works for me is to write down any distracting thoughts while trying to focus.
Many times, when I try to focus on a particular task, I get ideas and questions about tangible or completely irrelevant (we need to buy bananas) topics. My primitive brain would drive me to first complete these irrelevant tasks first to get some dopamine reward.
Now I always have in front of me a small piece of paper, and when some distracting thought like that hits me, I just write it down, and I reassure my brain I will get back to it once done with the main task I am trying to focus on. It is nice to have these written down because I can completely empty my brain of them.
I know it is stupid, but it works for me :)
You’ll never be able to exist outside of work if you follow this advice. There is a mental burden to leaving things broken; if you really care, you’ll spend your cycles thinking about what is next and how to solve it. From experience, I don’t recommend it.
Similar to this "leave things broken", I like to start the day with some lightweight refactoring. This allows me to pay down technical debt while I warm up my brain to the code.
Hemmingway would leave off writing for the day in the middle of a sentence for the same reason.
This is one of the only weird tricks that actually works. I don't remember where I originally got the idea, but as soon as I saw someone point out that it works, it seemed so obvious. I've been doing this for years.
When I get into a slump, it's usually because I finally finished something, and then woke up the next morning not knowing what to do.
A side effect of this technique is that the "obvious next step" to fix the broken code left over lives rent-free in my mind until I can come back to it.
For some people, leaving things in a broken state when the solution is known is an itch begging to be scratched.
My old colleague Mike Rowe said it this way: "Always leave it compiling" meaning, make a change and don't test it, just start the build and walk away. So when you returned you had something to dig into (didn't build, or did and needs trying).
Also, you had a good feeling that maybe what you just tried will fix the problem or whatever. So you don't go home frustrated and depressed.
Ohhh, this makes sense. I must try that. Up until now I was doing the exact opposite - trying to finish the task or at least drive it toward some clean state. Mainly to not block others if I am close to completion.
My trick is to get outside my comfort zone when coding, but only just enough that's it's tolerable and not overwhelming. Most of the time, even as a seasoned coder, I should feel inadequate, yet still up to the task at hand. That's what flow is for me: pushing myself, but not too far that I end up falling off the proverbial cliff.
This is what I do with writing most of the time. There is a tool[1] I've used on occasion that (in a certain mode) forces you to write non-stop without being able to look at what you've already written, for a certain amount of time. Whenever I need to knock out a rough draft for something and am feeling a bit stuck, I reach for this.
“ Before stepping away, leave the code in a state where it is Obviously Broken, but Easy to Fix. ”. So purposely introduce a break that you can fix would work just as well?
Leaving a failing test clearly pointing at what to do next has been very effective for me.
I usually add a line with a plain "todo" to break the build and afterwards a three-line comment describing what is supposed to change. At the end of the change I remove the todo-line and move the three-line comment to the now-better location as documentation for why that code there is the way it is.
When I don't have such comments, its usually back to the collection of design documents thinking through the next feature.
Leaving a test broken that is going to be straightforward to fix does help me pick up the pieces again the next day. A next steps text file helps too.
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.
This resonates with me.
For about 18 months I commuted to work through public transport and I had to adhere to bus/metro timings or risk reaching home couple of hours late and earn the wrath of family. This meant two things 1) I drastically cut down on non-productive tasks while at office and 2) I often had to get up from desk with solved but half-finished work. So when I reached work the next day I didn't have to think what to do, I had an extremely well scoped work to start the day. It's as if a chef walking into kitchen finds all the cutting/dicing done and recipe laid out in front, he just needs to start cooking.
The net result being it was perhaps the most productive period of my career and it coincided with the hyper growth phase of the startup I was working for.
I like leaving some easy finishing touches at the end of the day, so next morning starts with a quick win and morale boost. Or even leaving in the evening with no idea how to solve the issue, usually solution comes itself until next morning.
Nice trick.
For me it's little different. I usually divide the work into small chunks and tackle one by one. I may work on task 1 and 2 and leave task 3 untouched for next session. This has worked for me pretty well to get started the next session.
I can follow OP's argument, but it doesn't work precisely that way for me. I like to start in the morning with a clean build. Then I can set off to make major changes, knowing that everything that goes wrong, what I just did had something to do with it. The work will inspire new ideas (which I jot down to not forget, but stay on track) and I work till I get back to a clean build again. I want the complex flow-state in my head to be related to what I'm working on in as short a time-span as possible. New ideas can wait for a new day.
> leaving the system / code too clean makes it hard to know what to work on next
I've heard about the idea in this post often in other contexts (e.g. writers stopping in the middle of a sentence), but I've always been the type of guy who likes everything to be clean when I stop for the day. But that does indeed make it very hard to know where to start the next day (or even worse, two weeks later when coming back from vacation). Sometimes it takes me days to get back into the work and it doesn't feel good.
I will definitely try this out.
In academic or research work this can be tricky because sometimes you put something down and can’t come back to it for a week/month. At that point, this trick is more of a hindrance than anything…
No idea if it’s true but I’ve read that Michelangelo was using the same technic while sculpting.
At the end of the day, make a big ugly dent somewhere in the stone, that makes him want to fix first thing the next morning
Maybe off topic, but it's weird to see a post about flow and distraction start with a completely unrelated splash image as many posts do these days.
Are there studies linking this with better recall/comprehension or is it SEO related/purely aesthetic/trendy? It makes the posts signal 'I care about this' a bit more than your old school livejournal text only content, but I suspect in the vast majority of the cases it correlates with superficial and weak content.
Yep, I use this in writing. Leave that juicy scene until tomorrow, so I jump out of bed instead of slithering to the coffee machine while building a list of excuses in my head.
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.
I usually just type a couple english words in the source file so that it won't compile when I pick back up and immediately draw my attention to where I was last typing.
It's basically the simplest possible system, and I find not only does it mean I can get started right off when I come back to it, I also have no hesitation to start something I won't be able to finish before getting up.
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!
This is good general advice, but there are situations where it doesn't always work. Sometimes I've come back the next day, finished the thing I was working on within 1 hour and then I get stuck for the rest of the day trying but failing to be productive. Maybe it would have been better to finish the day before and taken the next day off?
This makes sense. But does anyone else have problems with disconnecting when I know what needs to be done.
This is a variation of the Zeigarnik Effect for anyone interested in the why behind it.
I realized this trick a while ago. As an engineer I will sometimes leave stuff disassembled on my desk to end the day if I was working on it, so the next obvious step in the morning is to re-assemble it and keep testing.