51–60 of 105 posts
After a stiff cup of coffee and closing out communications and 1min tasks, super easy to jump back in.
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 leav…
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 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 leav…
The end-of-day-just-one-more fix is likely to be lower-quality than the fresh-start-after-a-good-night’s-sleep fix.
> 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 hav…
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.
> 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 hav…
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.
> I said no to low-impact tasks. This oversimplification is terrible advice. 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…
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.
I normally write uncommitted comments of what I need to work on next, e.g. a to-do for the next day
Now, if it’s later in the evening, well then it’s tomorrow’s work.