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.
That could backfire. Maybe they were in the middle of something hard that's difficult to pick up from. To use the metaphor, perhaps you would be forcing them to park uphill.
> 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.
Also shows an understanding of the importance of off-hour processing with any high thought work. Shower time, commuting, cooking dinner, sleeping. All things that give your mind time to coast over the things you may have struggled with in the day. It’s always easier later.
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.
I pick the kids up from daycare at 4:30. Every few days its 4:25, I’m in the middle of something and I’ll spend 60 seconds writing out simple English sentences or bullet-points of what I need to accomplish when I get back to my desk. This context switch allows me to disengage. Sometimes I’m tempted to try “one more thing” a “Hail Mary” but it almost always backfires into a future wrong-approach distraction.
I'm the same way. I have a hard stop every day at 4:45pm to pick up my kids. I have an alarm on my phone that goes off at 4:40pm and I spend the next few minutes taking notes if/when I need to. I might also try to package my current state into a commit if/when it makes sense but I don't tend to stress about it.
> 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 right now than you will be tomorrow (or next week, month, year..)? More knowledgable? More prepared? Possibly... but it's more likely to be the opposite: in the future, you'll understand the problem better, you'll have more data to choose the best path forward, you'll realize there's another way to do it, or you'll simply have bigger fish to fry.
> 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.
I would work for such a guy. That tell me a lot about management caring about talent than any bs marketing pitch they give during interviews. Give me cold hard facts.
I learned this one the hard way, and have found it again and again since: often when it's the end of the day and I'm stuck in the middle of something that seems really hard, the best thing I can do is walk away, and the next morning, it suddenly seems very easy. I call this state "being in the hole." It's a kind of can't-see-the-forest-for-the-trees thing. Always so satisfying to smash a thing in five minutes that I'd wasted an hour on the evening before.
Could, but likely won't: if the things you have to do regularly spill beyond the boundary of time set to do them, you're not deciding how to approach the things you have to do correctly.
Enforcing a constraint for the 90% scenario makes more sense than designing around the 10%.
Or they are on a hard nut to crack and better should sleep over it. I know unsolved bugs can make you sleepless sometimes but sleeping over them often does the right kind of "backtracking" in your mind that leads to the "branch" with the solution the next morning.
In almost every case that I find myself working on something "hard" stepping away, losing focus, and then thinking periodically about the problem leads to higher levels of clarity.
William Carlos Williams would do the same thing with his writing. He wrote for exactly one hour every morning, and he would leave mid-sentence many times. He said it made it much easier to get started immediately the next day.
Or it could be that you had a brilliant idea for the rest of the sentence, but the strict rule prevents you from writing it down, and next day you can't remember it and chase it all day and still be unsatisfied in the end. Either because of lost time or because you couldn't remember/recreate it, or even both.
I suppose it just goes both ways. Try not to finish sth so that you don't have the somewhat hard task to start with sth new next day. But at the same time don't stop in the middle of sth that's difficult to pick up from. A strict timing rule does only help if you are statistically more often at a point where it's easy to pick up again. I doubt that you are though, so I'd try a more concious approach than a clock.
> A strict timing rule does only help if you are statistically more often at a point where it's easy to pick up again. I doubt that you are though, so I'd try a more concious approach than a clock.
Although I disagree with you when it comes to corporate policy, I basically agree with you at a deeper level.
I think that being able to be completely asynchronous about how and when you work, while also being unafraid and deeply reflective about your process would be more of an ideal.
However this isn’t realistic in a corporate situation, and in such a setting most people are more likely to be suffering from meaningless workaholism induced by relentless corporate pressure than they are to be operating at the highest levels of self-actualization.
One should try to create a study to investigate the effects better.
As alternative to "6pm you guys all go home, period.", there is likely a difference between "6pm you all go home, but if you really must finish sth, I'll wait until 6:30pm to pull the plug" and "go home whenever you want" (which may end up being 8pm or 10pm and in a game theoretic setting may lead to later and later time).
> A strict timing rule does only help if you are statistically more often at a point where it's easy to pick up again. I doubt that you are though
You really think so? You think you spend the vast majority of your time at work doing things that are so complex they're hard to pick back up 12 hours later?
That's not how I read the comment. Between the "easy to pick up from here" (downhill parking) and "hard to pick up from here" (uphill parking) there is the most likely most common "indifferent" (parking flat). The main theme of this article is to try to always park downhill. So, an interruption that is anything than parking downhill is to be avoided. The claim is that you spend the vast majority of your time at work not facing downhill. Intuitively, that makes sense.
I'd have quit over that. If the work is interesting and going well I'm not stopping because someone likes to exercise control over my schedule, I'll build something else instead.
I do get what you’re saying on the one hand, I feel the same way, but - is your employer compensating you for working past 6pm, in this imaginary scenario? I started out doing a lot of hourly work earlier in my career, and sure, if I was on a roll I could jam for hours, and I was gettin paid accordingly.
Lately, in salaried positions, I’ve basically had to break myself of that habit - that’s my free time I’m cutting into when I stay late. In emergency situations, I’m happy to stick around later if possible, with the understanding that there’s bonus compensation or at least comp time queued up for me - but if I’m just feeling engaged when 6pm rolls around? Im out, I’ve got dinner to cook and videogames to play.
Work will wait for tomorrow, part of what I’m getting paid for in standard work week is developing on a schedule, you know?
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.
maybe worked extremely well for the company, but not for the worker. I would rather solve the issue before going home (thus having a clear mind at ease) than carry the burden of the looming unresolved issue till the next day.
Not if you don't get there until 10 is isn't. But enforcing a late start is a lot harder than enforcing an early finish. What are you going to do, refuse to let people in if they show up early? Besides, sometimes you can't help it. When I was taking BART to work, I had to get to the station before the parking filled up.
It’s still late in absolute terms. Not everything can just shift around to an abnormally late work schedule.
This sort of schedule gives you virtually no free time with kids. Get home, eat, put kids to bed, wake up early because school doesn’t start at 10am, send them to school, wait a bit, leave for work.
We are lucky that things are more flexible now. I don’t blame the manager. It was a different time. But it’s a schedule that doesn’t work well for a lot of people.
I seriously think that the specific range of hours was not at all the point of the example. Would you disagree?
If you're going to nit-pick, my kid starts school at 9am, so I can't start work before 9am. What about remote workers and the example of walking around the office?
I'm pretty sure the example was specifically to note that cutting off their work hours was a successful tactic with respect to leaving them with something to start in the morning, vs letting them finish what they're working on and then have to figure out what/how to get started on in the morning.
Literally the point of the article there, leaving your work unfinished or broken, as it were, so you can just jump in knowing the next thing you were already going to do last night, but forced yourself not to or were forced to not finish.
I’m not not picking, I’m disagreeing with the idea that the relative end time is all that matters. I specifically did not blame the manager in my comment.
It’s really not clear what you’re saying other than that 6pm would be too late for you personally.
As I’ve explained - I picked that time as the latest people were allowed to work in the office. Before I adopted this, people were randomly staying much later.
It’s true that the team was made up of mostly young, unmarried men. I think only one senior person had children. I don’t recall what his needs were, but I wasn’t a hard-ass about not leaving early if people were productive.
And certainly if the team in general hadn’t liked the hours, I’d have negotiated. We moved from 9am to 10am for that reason.
Your problem should not be how early or how late the schedule is - your problem should be that it’s arbitrary across all workers, regardless of circumstance.
We all would prefer to work a particular schedule - we all deserve to be able to negotiate our hours based on necessary overlap with our coworkers preferences.
“I wake up early so all of you have to wake up early” and “I work late so all of you have to work late” are both not nice.
Are you younger than 25? Because working 100 hour weeks used to be common in startups. Look up stories from the early days of google and Facebook. People lived in the office. It was by choice. No one forces you to do it and plenty of other companies to work for if you wanted balance.
Much older than 25 here. I still do insane hours when I'm starting my own business. But I have never, and would never, work that sort of schedule for someone else's startup (nor would I expect employees of my own startups to do so). If I'm going to kill myself like that, it's going to be to build my dreams, not someone else's.
I'm over 50. I work from home now, but when I did have to go into the office, I'd typically show up just before 10:30 standup and head out by 4. And I'd take an hour or two to workout in the one of the fitness facilities on campus in between. My bosses have always been happy with my work and output.
With an hour for lunch, that’s only 2.5-3.5 hours of work a day. Even less factoring in the stand-up.
What role were you able to be successful at while only putting in 2.5hrs of work a day?
Posted as an edit, since YC is doing its inexplicable rate-limiting on replies to this thread:
> Work != presence. In a role in which you don't have to sit in front of a computer, 3h presence could mean 8+ hours of work. … I typically start working when I step into the shower in the morning. … I think that all counts as work hours.
I work from home, but I do not count my showers as working hours. That’s patently ludicrous, and frankly, 2.5-3.5 hours of “presence” a day is unbelievable. Someone putting in so few hours is shirking their work, period.
My work is in software verification, so it’s not as if I don’t need time to think, but I also put in the actual hours required every day to appreciably kick the can forward.
I’d be livid to be stuck working with (and waiting on) someone who considered their shower and commute as working hours.
Work != presence. In a role in which you don't have to sit in front of a computer, 3h presence could mean 8+ hours of work.
I typically start working when I step into the shower in the morning. (I have a typical coder job.) Thinking about what to work on today, remembering the problem I left off yesterday (having parked downhill), etc. It's a great distraction-free environment. Some of the best ideas come there. No slack, no email. No CI pipeline that screams at me. Sometimes I keep thinking after the shower before turning on the laptop. Just sitting on the sofa. By the time I log in, I may have already worked for an hour. Or perhaps two, if I started thinking about work right after waking up. On office days, I typically think work during the commute. There mostly, but often even on my way home. I think that all counts as work hours.
Seconded. My daily walk to Starbucks is my time to meditate on my coding issue of the day, free from distractions of emails, office visitors, and meetings. Many coders I’ve met say a change of scenery can help you solve a problem you were stuck on.
Also a chance to say hi to the local crows who appear to recognize me nowadays and don’t fly away when I walk by :)
I work from home, but I do not count my showers as working hours. That’s patently ludicrous, and frankly, 2.5-3.5 hours of “presence” a day is unbelievable. Someone putting in so few hours is shirking their work, period.
My work is in software verification, so it’s not as if I don’t need time to think, but I also put in the actual hours required every day to appreciably kick the can forward.
I’d be livid to be stuck working with (and waiting on) someone who considered their shower and commute as working hours.
The whole concept of salaried roles is that you're being paid to achieve enough to keep your employer happy. If my boss feels like he's getting his money's worth based on my output, it really shouldn't be anybody's business whether I'm achieving that in 3 hours or 12 hours. In fact, if I can produce a satisfactory work output in 3 hours versus somebody else's 8, then I'm not shirking at all, I'm simply better at my job.
And as a knowledge worker, I'm being paid to solve problems, and have and structure the knowledge to solve problems in the future. If I'm solving problems for work in the shower, or on my way to lunch, or while making coffee in the morning, I'm literally being paid to do my job. As a software developer not responsible for operations, literally nothing in my job can't wait 30 minutes. Even if I was at my computer, actively coding, it would probably take around that long for me to get to an appropriate stopping point to respond to a message.
Some people at a previous job used vscode, passed their day clicking at stuff with their mouse, navigating directories via a native file explorer, using GUIs to commit their changes, using windows with no knowledge related to virtual desktop management, automating nothing etc... That wasn't no problem at all : they did their job and at the end of the day they wrote code.
But then, with the right tools you could have done what they did in half the time, minimizing all the unnecessary micro-movements with some keybindings and some editor plugins or some really good text editor.
Now, if paired with this mechanical mastery you have a good ability to pack related problems/functionalities to implement and are efficient at solving them/implementing them; then you can add some multiplier to the mechanical speed explained in the previous paragraph.
That's some weird way to think about this, but let's say the ideal instance of the project requires X lines of code; if you work faster, then you reach a higher level of expertise on the project codebase and by this excess of expertise you gain speed relatively to others which in turn makes you more expert and so on.
Except, working "fullspeed" is more tiring than working "normally" and you usually don't want to have a tornado in your team that write 50+ -major changes- commits a day and that cannot cooperate with others because they cannot follow up and are "too slow" to even review those changes.
You decide to fire "slow" workers, but then the tornado must work 9+ hours a day to keep up with your expectations and finally burn-out leaving a work that every other member of the team fails to understand, due to too much litterature to read written by some sort of alien.
So I'm fine with programming 2 to 4 hours a day, since, as an alien-tornado, I prefer my code to be read, reviewed, and understood by my peers.
What I am saying is that this conception of work is absurd. The truth is you are hired to build stuff, not for being at an office during X time.
I like fishes, that's cute.
Working 2.5 hours per day is enough for me some days to meet expectations.
If the person you work for is happy about your output, then should you care ?
If you’re okay working to such low expectations, and do not fear being replaced by automation, then that’s your prerogative.
I would not feel secure in the stability of such an easy job, nor proud of my accomplishments. I also expect that we work in very different stratums in both skill and renumeration.
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.
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.
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.
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".
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
I’m not who you’re replying to, but I hope my input will be helpful.
I just use Jetbrains IDEs on projects with the IdeaVim plugin (integrates so well with the IDE, it’s pretty much my only must-have plugin for any software, beyond uBlock Origin), and Vim for external files (scripts, etc., or when I want to use a specific plug-in for editing).
By default IntelliJ (PyCharm, GoLand. any Jetbrains IDE…) has a pretty large undo history, and that can be extended to however long you like. The real killer, however, is the extended local history for the file, which is arbitrarily (or at least seems to be) long. Combine that with the wonderful built-in git history (which can be a separate pane/window!), and you’ll never worry about changes you’ve made being lost, or overwriting other history, no matter how overzealous you were with said changes.
I find IDEA’s built-in tools so useful I barely ever even think of using git stash or git shelve anymore (or directly calling ~30% of git commands for that matter), and those are commands for which I still have 20+ aliases for in my .bashrc.
Intellij's local history saved my ass a couple of times.
Its git features are also quite comfortable. Very nice diff, I like very much the "Show history for Selection", live git annotate (with GitToolbox plugin). I don't often do rebase, but when I do the interactive rebase is also very helpful.
Closing my laptop and leaving it on a charger. Wish I had a better answer. I use VSCode and it does restore undo history on relaunch for the most part, but I can’t remember if I configured it for that, and I definitely don’t trust or rely on it. I know it definitely doesn’t work if I accidentally invoke “reload”.
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.
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 what you thought you wanted to do next.
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.
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.
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.
If your philosophy is to do a PR at least every few days then the negative impact of this was likely negligible, especially comparing to have a fellow dev being out with having broken arms for a few months.
If you do PRs every few weeks then that could be a bigger issue. But then this should be a lesson to just not do that. Merge small steps often. It has tons of advantages.
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.
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.
"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.
one thing that helped me with open loops is to have what David Allen of GTD calls a "Trusted System"
It's a system you trust to record those ideas bumping around in your head. That lets you get them OUT of your head until you start working again, and relax.
"The best way is always to stop when you are going good and when you know what will happen next. If you do that every day when you are writing a novel you will never be stuck. That is the most valuable thing I can tell you so try to remember it." - Ernest Hemingway, advice to a young writer in 1935 article in Esquire
I wanna live in that world vs kids and coworkers yell fire and their urgent request isn't actually urgent but now I'm outta the zone. Seems like you're describing an idealism.
Ideally, sure I'd fend off these attention suitors and get to them once I hit a stopping point. Love my job and my kids but this triggered me a lil bit. Somewhere along the line I feel like I just became battle hardened into actually accomplishing things regardless. Just a lot of picking up the pieces of context and ideally I left myself notes (e.g park facing downhill, a good mantra)
On the other hand it can be helpful, in my experience, to stop right in the middle of a very hard problem, where you are still searching for a good solution. Come the next morning I often know at least a possible solution, without having worked on it consciously.
It’s crazy the degree to which the subconscious mind chews on problems it’s been given. I never even dream about the problem in question but pretty consistently sleeping on friction points like that will clear them in short order the next morning. It’s almost kind of spooky, like there’s a second person in my head burning the midnight oil.
I wonder how much of it is also about getting out of a local maxima... you are pursuing a specific solution, and are exploring the end of a long chain of choices you made on how to approach it... and starting over again the next day clears out all those choices, letting you maybe discover a better solution that was on a different branch of the decision tree.
The risk with this is that you keep procrastinating away before getting going again. It's the anticipated pain of frustration that prevents you from starting. Not so much if your idle time generated a solution to the problem. But if it didn't, then you are in trouble.
This is an underrated comment. Not only this, but there are some micromanaged environments that make this impossible and you're immediately hit in the face with a meeting first thing in the morning that destroys any energy you might have had to continue after being asked several ways if it's "done yet".
I've been 60 minutes of focused work away from wrapping up this current ticket for the past two days. Too exhausted to get going in the morning before meetings and interruptions kill my productivity for the day. Usually I start work two hours before the workday actually starts because context switching and meetings drain me, and deep work won't get done otherwise. The curse of ADHD.
I already know I don't have ADHD, so I can tell you it might not be your ADHD. It's not that you're ruminating about what they asked, but that they all keep asking you because they use you as their syncing mechanism and must repeat yourself to several people. Effectively just as bad for productivity.
Morning meetings are a deliberate tactic. Middle management needs answers for their next meeting which is also right after yours in the morning.
The people who get to have meetings at the very end of the day are at the top of the hierarchy, and guess what? They got their work done!
If there was ever a real example of inequality that should be fixed (fuck all that DEI shit) this would be it. Work from home actually massively reduced this meeting train crap at my workplace, but they just found other ways to annoy people. It's still an improvement though.
Yeah, you have to give it a solid effort for this to work. On day two if it's not solved yet, you have to give another solid effort before resting.
I'm not sure if in this scenario it's an option to solve the problem on the first go. Usually when I hit this scenario, I am simply unable to do it in the first place, but the next day is easy.
Right. Or you try to break it down into subproblems which may be easier to solve. And those are then candidates for the downhill parking on-ramp for next day.
In uni there were a few times where I'd spend 12 hours solving assignment problems. At EOD I still had maybe half unsolved, although I'd tried to solve them all. Next morning in the 30 minutes I had before class, I quickly solve all the problems before handing it in.
Oh, another time for algorithms assignment, I am up until 5am or so. Still had 2/5 problems left unsolved (but again I had tried to solve them). I go for coffee at the student center, oops it's not 24/7. I take a light nap in the student center waiting for the coffee place to open up. Full on REM dream problem solving occurs. A couple hours later I awake knowing full well how to solve the 2 remaining problems. I grab my coffee and leave to write up the solutions.
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.
I think "failing test in a feature branch with a draft PR and a powered off machine" counts as "left broken". I won't even boot into the work OS if I'm not working.
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.
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.
When the Hemingway rule doesn't work, maybe because you've finished something and don't know what to do, that's when you can turn to the Twain rule: eat the frog first. Start with the hardest task.
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
“The best way is always to stop when you are going good and when you know what will happen next. If you do that every day you will never be stuck. Always stop while you are going good and don’t think about it or worry about it until you start to write the next day.”
> 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.
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.
But be critical; I'm currently trying to discourage my colleagues from over-engineering fairly simple things (static / simple list items in a React app). Refactoring is fine, as long as it's not refactoring for shifting code's sake.
I remember reading this quite a while ago. My elaboration of this technique is to write the last sentence in my head, but only put the first part down on (paper) the end of the file. If I'm lucky, when I come back to it, I can read the first part of the last sentence, and memory will tell me how the sentence ends, I can just keep going.
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.
Hah, for me, these moments are some of the most stressful moments of coding! I am about to find out a very important piece of information: whether I'm done or not.
It's an intense feeling of anticipation like how you feel while hearing, "We, the jury, find the defendant...". I would like to avoid stringing that out over a longer period than necessary.
Compiling is the riskiest time for me, as that's when I'm most likely to get distracted by something else. Sometimes during a 10 minute rebuild I just force myself to stare at it.
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.
Ditto; I remember reading somewhere to try and finish the day on an accomplishment, so that you've got a pleasant taste in your mouth about the project.
Given how long ago it was, though, maybe the article was about personal projects instead of work.
This is the way. I can't believe people are actually endorsing leaving things broken as a positive way to end the day. It's a hard disagree from me on that idea.
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?
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.
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.
I was decently productive while a "flow" practitioner but I am definitely more productive than that after abandoning it as a concept. It's much easier to pick up where I left off because code is structured that way.
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.
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.
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…
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.
I didn't know about flow being a term in biking, TIL thanks. However, my opinion on vaguely related splash images before blog posts being indicative of superficial content where SEO is sought after more than sharing original or useful info is unchanged. This is solely based on my own experience reading various blogs, hence my initial question regarding what is at the heart of this trend if not simply SEO.
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?
It makes me feel more at peace about disconnecting, in a certain way. Since focus is elusive, when I step away from work, I may worry that I'm throwing away an opportunity that I may not get again. If I believe I have a way to recover focus when I start again, I feel more comfortable about letting go.
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.
When I'm in a flow and get interrupted I write "I AM HERE", so the next time I try to run the software (which can be hours to weeks later) I get an error on that row and hopefully remember what I was working on.
The way I do it is I try to stand up as soon as my pomodoro timer is done. I do finish the sentence / line of code or write a comment how to continue, and then I get up and take a break.
There is actually a similar technique for writing: leave your writing halfway, where it’s obvious how to continue. That way when you come back, you’ll continue writing.
If nothing else I leave a test with a description and an `assert false` statement to fail it. Preferable is a test that actually fails for the right reason.
