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.
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.
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.
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.
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 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)
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.
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.
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.
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.
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.
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 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 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 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.
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.
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?
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.
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.
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.
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 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.
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.
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.
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.
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.
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.
“ 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?
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?
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.
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.
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.
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.
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.
> 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.
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.
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.
195 comments
[ 3.0 ms ] story [ 260 ms ] threadhttps://www.fastcompany.com/3021905/hemingways-secret-to-mai...
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.
Sleep really helps.
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.
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.
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)
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
You’re not a 10x “alien tornado”, you’re just a fish in a very, very, very tiny pond.
If I only dedicate 2.5 hours every day to my work, I’m not meeting that obligation.
If I start accounting for my showers and commute as working hours, I’m being dishonest with both myself and my employer.
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.
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.
I really like the parking downhill analogy.
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).
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?
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 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.
0: https://wiki.c2.com/?YouArentGonnaNeedIt
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 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.
Enforcing a constraint for the 90% scenario makes more sense than designing around the 10%.
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.
Honestly, forcing people to any particular rhythm is a pretty bad idea unless things go out of hand.
Sometimes I'm in the mood to continue on the problem, and sometimes I'm too tired and would rather leave by 4pm. Why shouldn't I be able to decide?
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 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.
For some people, leaving things in a broken state when the solution is known is an itch begging to be scratched.
When I don't have such comments, its usually back to the collection of design documents thinking through the next feature.
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.
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.
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.
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.
The author is entirely right about a trick to recover context.
But I'm not sure he's ever experienced flow.
May work great for some people. May be terrible for others.
The internet is a wonderful place for the open exchange of ideas, if you just treat them as such.
I definitely read it somewhere.