> Leave work slightly unfinished for easier flow the next day<p>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.<p>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 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?<p>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.<p>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.
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.
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.<p>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.<p>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.<p>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
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.<p>"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
Was trying to remember where I'd heard this earlier in the year. Someone back then I think called it "park facing downhill". Resonated.<p><i>An On-Ramp to Flow - One Weird Trick: Leave Your Work Broken</i><p><a href="https://news.ycombinator.com/item?id=35456059">https://news.ycombinator.com/item?id=35456059</a>
> I said no to low-impact tasks.<p>This oversimplification is terrible advice.<p>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.
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.<p>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.<p>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.<p>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.<p>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.<p>If I have to be really prepared for the next day, I just keep it ready the night before.<p>1. <a href="https://julian.digital/2021/12/20/the-power-of-defaults/" rel="nofollow noreferrer">https://julian.digital/2021/12/20/the-power-of-defaults/</a><p>2. <a href="https://www.nngroup.com/articles/the-power-of-defaults/" rel="nofollow noreferrer">https://www.nngroup.com/articles/the-power-of-defaults/</a>
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.
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"<p>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.<p>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've done this, in a way, for years!<p>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.<p>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...<p>> 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]<p>[1] <a href="https://www.writingforums.com/threads/hemingways-curious-trick-stop-while-youre-going-good.139596/" rel="nofollow noreferrer">https://www.writingforums.com/threads/hemingways-curious-tri...</a>
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.
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.<p>If I can, I avoid this situation.
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.<p>If you do the above you don’t need any tricks. You just follow your curiosity, excitement, and obsession.<p>If you’re not excited by the end goals then you will never be able to bandaid that over with productivity tricks.
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.<p>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.<p>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.<p>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.
I actually write everything I was working on down on a sticky note and stick it to my track pad. Then I write down everything outstanding.<p>After a stiff cup of coffee and closing out communications and 1min tasks, super easy to jump back in.
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.
I heard this advocated by TDD (Test Driven Development) practitioners.<p>Normal cycle is<p>1. Write test that will fail or not compile
2. Run it
3. Write code to make it pass
4. Refactor
5. Go to 1<p>When you are ready to go home, go after #2.
No thanks. I have plenty of work ahead of me, I'd much rather close up shop having removed it from my back.<p>Now, if it’s later in the evening, well then it’s tomorrow’s work.