> Leave work slightly unfinished for easier flow the next day
Years ago a sr. eng on my team would find root causes to bugs late in the afternoon and then just go home. When asked why, they said that they knew exactly what they were going to do first thing in the morning and that it got them straight into the flow state for the rest of the day.
I like this example better because understanding a root cause and not having it fixed is more concrete than "slightly unfinished" which is too vague for me to measure.
I have done something like that at times. I find the bug in the afternoon. Now I have the satisfaction of having found it and don't want to risk the frustration of it not actually being the actual bug I found. So I saved it for the next day, to milk the satisfaction again, but also to be more fresh at it to fix it right and test it, or to better be able to deal with it not being the actual bug!
Though my boss at some point was puzzled "why don't you just fix it now?"
Also taking notes to bridge the time gap, physically or even just in the mind, can help improve understanding. Could be described as rubber-ducking with a future self.
>Years ago a sr. eng on my team would find root causes to bugs late in the afternoon and then just go home. When asked why, they said that they knew exactly what they were going to do first thing in the morning and that it got them straight into the flow state for the rest of the day.
This works, but also needs some notes with a "dump" (on the previous afternoon) of all relevant points. For some subtle bugs and complex codebases it's easy to forget some key point, even though you found what the main issue to fix is. So if you already know some subtle points/edge cases in the afternoon, write them down.
It’s a lot of fun leaving notes. When I’m working in the office and the next day is a WFH day I ssh in to my home computer and write my notes in a text file in the home directory. It feels like I am reaching through the computer to my desk at home.
I like this, too. “Slightly unfinished, but fully understood” is a great place to pick up. A “slightly unfinished understanding” of the problem or task at hand is a great way to nuke one’s mental model and end up stuck trying to recreate it in the morning.
But how do you really know if the problem is fully understood? I often think I’ve understood a problem multiple times, and only reach a true understanding through repeated testing and fixes.
Sure sure, but a complete but incorrect understanding of the system is, to me, still better than an incomplete one. If I have a complete system in my head, I can use that to jumpstart my thinking the next day and then get to a correct understanding. But an incomplete understanding is even more confusing the next day because of all the loose ends.
Often, I find a good rest gives me greater understanding of a difficult problem or complex bug. Sometimes you get lost in the weeds. I also work much faster in the mornings, which helps.
This is the huge part. You found the bug, so your anxious mind is calmed, but you did NOT write the first fix that came to mind, so you have time to mull it over.
Often you realize sometime in the night that the first fix would have had other subtle issues.
And you’re less likely to throw a quick fix on in the morning.
Definitely. I’ve even had those magical moments where you wake up and realize you solved the problem in a dream. I think my preference is to have the major points of confusion cleared up so that they don’t become more confusing when I lose my mental model overnight.
A professor I worked with liked to stop work in the middle of typing something. “As if I fell asleep or passed out while working on it”, he said. And the next morning, kickstart the flow state by doing the very simple task of typing the rest of the unfinished word. Followed by the less simple but still straightforward task of finishing the sentence/line of code. And so on.
What if you're not working on a bug? If you're proficient, you should be able to measure the amount of work left in something so that it's "easily finish-able in the morning."
I did something like this yesterday. The only problem is that I spent all night dreaming of SQL statements to implement the solution. YMMV if you have trouble turning your brain off it seems.
I don't like this tip at all. I get the sentiment, getting started is the HARDEST part of the day for me. But if I can finish something now, why wait until tomorrow?
It's a golden rule sort of thing. I'm imagining the HR person saying, "It will only take a few minutes to fix this for you, so I'm going to wait until tomorrow". Examples are endless.
There are better ways to get myself going in the morning, than to leave myself softballs from the previous day. Learning to make myself a realistic and attainable plan for the day works better for me.
I like the closure so I can take my mind off the task and onto home life. Leaving stuff hanging just means I'll be performing the task mentally all night.
I think it’s different if someone is waiting on the immediate output of your work.
But in your example, if the HR person needs to process 1000 documents this month and mine is one of them, I’d much prefer they use this process to help them actually get through all that, rather than struggle to start every day and get less done over the course of the month.
> I think it’s different if someone is waiting on the immediate output of your work.
I partially agree, something needs to be on fire or a complete showstopper for that to happen. My only other reason would be helping out a colleague who's trapped in a gravity well of fail and needs a bit of help and support.
I’ve had good luck as well with the practice of leaving myself a “head start” to pick up in the morning. It seems like it wouldn’t help that much, but in practice it makes the task of getting back into the programming zone much easier. Seems like just one of those ways to trick our brains into working a little better.
It's not about not finishing as much as it is about letting something in unfinished state.
You can finish what you are doing right now, and start something else to get a clear view of the next step. Or take something you want to fix, and put a breakpoint it it and plenty of print, to make it sure nothing works and the day after you know where to start.
Interesting. I am the polar opposite of this. New things invigorate me, and I can often slam through a project to 90% but it takes me days or sometimes weeks to motivate myself to do the last 10%.
Once I can convince myself and start just doing it, I can usually get that done quick too, but there's a mental barrier of high difficulty to overcome first, and I'm compelled to be doing something new instead.
> getting started is the HARDEST part of the day for me.
For you, yes. But remember not everyone is a night owl, nor is everyone an early bird. I start work at 930am, we have our stand up, then I warm up with 30-45 mins of coffee, reading some techy stuff etc, and then I'm ready to roll.
> why wait until tomorrow?
Because it's the end of the "working day"() and my mind isn't at its peak performance.
> I'm imagining the HR person saying, "It will only take a few minutes to fix this for you, so I'm going to wait until tomorrow". Examples are endless.
A whole heap of things aren't that time critical at the end of the working day. If I've had a problem with my salary or some revision to my contract it can wait until the morning.
But if you want to go ahead and knock yourself out with another 2-4 hours of work on top of your working day (and contractually obligated hours) then beware of burnout. Pace yourself.
depending on when you start your working day, which doesn't need to be 9am. Personally I used to start at 10am because of flexitime and work on until maybe 7pm or until there's at natural cut off
Yes, completely agree. A colleague left a PR hanging one day. A customer wrote the next day saying the missing functionality that would have been fulfilled by that PR wasted an hour of their time last night.
The part about finding a "sticking point" is really important - if you know what's next, you can pick up the context rather easily and get going. If you end the day feeling confused or not sure how to approach the next problem, it's going to be rough coming back to it.
On the other hand, leaving the day feeling confused and sleeping on the problem is often times more helpful than pushing through when you're not getting anywhere in the moment. It gives time for those "aha" moments when you're not actively problem solving.
Write it out then, quickly, before you stop. On paper, that is, with a pen/pencil. Write in pseudo-code if it helps get it on paper faster. Stick that to your monitor or under your keyboard, it'll be there the next morning. If you got it right, typing it in will be easy. If, the next day, you see things differently, you will be past the first draft.
After many years of learning this lesson over and over again, that much my subconscious works on problems, I've finally learned to trust myself to step away when I feel like I'm grinding.
This is a great suggestion, it can help get rid of that sense of "I need to write this code now" but still produce a meaningful diff in the relevant places you'll need to change without all the mental overhead of determining the logic right there & then
I interpret "emptying your brain" to mean "writing things down so you don't have to remember them tomorrow". This probably helps you remember, but without the stress of worrying about forgetting.
If i did that i would think the rest of the day at what i have to do next. I have days when I am completely absorbed by a problem so my family, kids, healthy habbits fall into the background noise as i think about it. A lot of times i can't properly sleep, or i have exhausting dreams trying to work out my next steps. It might work for people that can shut off ther brains on command, unfortunately i'm not one of those people.
A mentor of mine taught me a variant of this that I use to this day. Always have a simple task waiting for you in the morning. One that you can accomplish in under an hour.
He phrased it as "park facing downhill" -- so you can roll-start your engine with ease in the mornings.
It really depends. This is just one of the tools that might or might not for you. I think it's more important to know your goal and yourself. In this case, you want to increase your productivity. As long as you can reach your goal, it's good enough.
Personally it doesn't work well for me because I need clean separations from work and be in the prolonged work mode would cause burnout. I have no problem to get started in the next morning with my own routine. It's more important for me to put things down and rest everyday.
On a meta level, experiment with what might work for you and iterate on your own work flow - it's exactly like TDD programming but for yourself
I am with you on this one. I, for my part, cannot stop unless I finish some logical subset of the work. Leaving the work incomplete or with bugs would make me sleep worse, and I would spend lots of time the next day trying to understand what I was trying to achieve. Even more so in hobby projects, where I might come back in a couple of days or weeks.
What I do, though, is leaving a TODO where I think I need to continue the next time. Works wonders for me.
In the end, I think it is about leaving some kind of an "anchor", but the exact kind depends on your personality I guess.
This was something Hemingway did. He'd stop writing mid-sentence when he knew where things were going, so he could pick up and continue on the next day.
"Learned never to empty the well of my writing, but always to stop when there was still something there in the deep part of the well, and let it refill at night from the springs that fed it. I always worked until I had something done, and I always stopped when I knew what was going to happen next. That way I could be sure of going on the next day." — Ernest Hemingway
I've seen many people refuse "low impact" work that's just flat out required for things to operate. Talking about keeping systems stable, working on tickets while they are on-call, and generally doing things that make work easily transferrable to others. These people that "refuse low impact work" end up being terrible teammates a lot of the time.
That's why they call it "on-call", you only work if you get the call. If you're on-call and being expected to work on unrelated tickets then you're now adding many hours/days to your working week, and somewhere near and just over the horizon is burnout town.
> people that "refuse low impact work" end up being terrible teammates a lot of the time.
yes, but there's a high chance they'll climb the corporate ladder way faster, while not caring about being great teammates because this is not a requirement for advancement. Actually, dumping this on someone else's lap [0] should be on the list of things to do if you want to move up from loser to sociopath [1].
I agree and practice Points No. 2, 3, and 4, but the main title of the post and Point No. 1 isn’t, at least in my opinion, a good one.
If I leave something “unfinished” intentionally when I could have finished it, I would likely not sleep right, eat with ease, talk to other people, so on and so forth.
However, I agree that if time is a constraint and the task is “lengthy,” I suggest keeping it to a stage of completion at a stage and then picking up the next day/time.
Many smart people want to keep something ready for tomorrow because they tend to be lost when there are no instructions on what is next. My suggestion would be to have a “Default,” which can be a simple set of instructions in plain text, something along the lines of, “If I’m stuck and have no clue what I have to do — then here are the defaults - do this, then this or that.” These can be bigger-picture goals or the “waypoints” for your daily/weekly tasks that you have to do.
I have been practicing the idea of the “Defaults” for a pretty long time but I got a lot more clarity and definitions from “The Power of Defaults.”[1][2] These are the things I keep on the top of my mind and return to when I’m stuck, confused, or doubtful.
If I have to be really prepared for the next day, I just keep it ready the night before.
this is great productivity hack, but personally i'd rather sacrifice the productivity and finish the workday (or even just go for lunch) feeling like i've finished something.
It feels like a reward mechanism for a different type of person.
Long-term, I can't comprehend how this could possibly increase productivity unless it makes you more satisfied / happy and, coincidentally, more productive.
For some it might work, for others - definitely not.
You are missing the point. Finish what you doing, but then start the next item, and leave it unfinished. Whatever you do, leave something unfinished for you to finish tomorrow.
A variant I've been using for a while is leaving a failing test. When I get started again I can focus on getting that test to pass. In the process I build the bigger context.
Actual title is "4 simple software engineering habits that transformed my productivity"
Using keyboard shortcuts is one of the four. I've been using keyboard shortcuts since I was a child! I can scarcely imagine programming without them. It would be like removing half my fingers or something in terms of detrimental effects.
Could somebody even get to a high level in software engineering skills without them? I'm curious. How would you interact with the terminal? Could you completely avoid it?
I get by with what's probably about a mid-tier-power-user level of keyboard shortcut knowledge. 50ish? Counting some Mac special-character chord (like em-dash)?
I can't really think faster than I can mouse, anyway. I forget any shortcut I don't use more-or-less daily.
My biggest problem in the morning is just getting going. I work better late in the afternoon and into the evening. So often, I've left a final compile or commit undone so I can just "quickly" do it in the morning out of necessity or, at times, sheer anxiety.
When I get this done in the morning, then I'm in the game so to speak.
I wonder how often this nugget of wisdom is rediscovered and passed on, in every field – I remember learning it as a kid from an autobiography of Roald Dahl, who in turn learned it from Hemingway...
> I never come back to a blank page; I always finish about halfway through. Hemingway taught me the finest trick : “When you are going good, stop writing.” You don’t go on writing and writing until you come to the end of it, because when you do, then you say, well, where am I going to go next? You make yourself stop and you walk away. And you can’t wait to get back because you know what you want to say next.
> [1]
I usually just write one sentence in english right in the code where I had been typing. The next day, the compiler points me directly to it and I can pick up where I left off fairly easily. It makes it easier to stop at any time, easier to leave-it-at-work, and easier to start the next day.
A long time ago I started leaving a trivial compile error (I was doing C++ at the time) in the code when I left for the day as a little bookmark, so the next day I'd just kick off a compile and see right where I was working.
Same here. I leave a to-do comment but without the comment delimiter. Won't compile, and it describes why. Feels a little like I'm living in the movie Memento, but it works.
Doesn’t work for me. There are chances that I will be trying multiple ways to finish it in my head while attempting to fall asleep. Causing insomnia some days and therefore very tired the next day.
I do something similar, where I paint myself an arrow for the next session. I don’t stop at the hardest part (which feels like procrastination), but after completing it and making my commit, I will often leave my working tree dirty with a TODO comment describing what is the next step, potentially along with some other comments that just say “modify here” at the relevant places. This way, when I run “git status” next session, I see exactly what I thought I needed to do next and where exactly I thought it needed to be done.
Productivity should always be to fulfill a terminal goal that ideally should excite and benefit you. If you are being productive just for the sake of it, or to get an employer off your back, you’re doing something wrong. I made this mistake in my early 20s.
If you do the above you don’t need any tricks. You just follow your curiosity, excitement, and obsession.
If you’re not excited by the end goals then you will never be able to bandaid that over with productivity tricks.
I disagree pretty strongly with this. Who gets excited about data entry, invoices, warehouses and shipments, documentation, sanitation, etc.?
Games designed purely for excitement hold my attention for a month or two before I need a break. After about 8 years of playing more Factorio than anything else I am at 1800 hours. How on earth can anybody maintain excitement on a single thing for 2000 hours a year, every year? Don't get me wrong, I'm excited by things my company does, but my day job involves a lot of boring necessities. I strongly suspect this is true of most jobs.
I obsessively chase my curiosity and excitement in my spare time, and I have a pile of unfinished projects to show for it.
I love the sentiment, I just feel it's not reality for most.
I was obviously being obtuse. But I honestly feel like the attitude that work has to be exciting or meaningful for you to be productive is a bourgeoisie luxury. I get paid well by my employer and therefore I feel a responsibility to be productive for them to an appropriate level.
EDIT: in fact, I feel like I made _that_ mistake in my 20s and 30s - looking to work for too much of the meaning and fulfillment in my life.
This is how Hemingway wrote. He’d stop at a point where he knew what he wanted to write next so the following day he could pick right up where he left off.
I do something similar I suppose: I deliberately add an error (if one doesn't exist) into the code I'm working on. Usually the method I last worked on.
So when I start in the morning, or especially after the weekend, I hit F5 and it shows me the exact line where it broke... and that's where I start from.
It's mega simple but it works for me as I do my utmost to forget about work when I'm not there.
I think the point is you take the problem home with you and let your subconscious work on it evening and night and then next day you are in a better position to do the right thing about it.
However note that nobody pays for you to work on it, or have your sub-conscious work on it on your own time. But if you really want to do a good job then that's the way to do it.
Do you leave yourself enough breadcrumbs that you can pick things back up in the morning? What's causing you sleepless nights? I find it helps me sleep better as I know I've dumped the context out of my brain and don't need to put effort into retaining it until I can get back to the task at hand.
Not who you replied to but I'm in the same boat re: sleepless nights.
It's not quite literally that bad but it's distracting for sure.
I just can't seem to leave enough breadcrumbs to stop ruminating about the problem after work.
Of course working from home doesn't help the situation. But sometimes it feels like I have to leave so many breadcrumbs and capture so much context that I might as well just do the work...
If I do have a problem then I write down every thought so it's out of my head for sleep. Nothing worse for me than trying to solve the problem mentally when trying to sleep.
I do this. I leave my code in a state where it wont compile. So the next day just hitting build will highlight where i left off - which makes it easy to get started, which makes it easier to move to the next thing.
Cool trick is to type a comment for future you as a plain text right in the source code. This way IDE will yell at you and the code will not compile. It will be clear next morning where to start.
Years ago a sr. eng on my team would find root causes to bugs late in the afternoon and then just go home. When asked why, they said that they knew exactly what they were going to do first thing in the morning and that it got them straight into the flow state for the rest of the day.
I like this example better because understanding a root cause and not having it fixed is more concrete than "slightly unfinished" which is too vague for me to measure.