A couple strategies that I've employed, that have helped me:

1. Do a start-of-week plan, and end-of-week review. Pick a few milestones that are achievable this week. Hold yourself accountable and check in with yourself to see if you completed them. If you didn't, review why not. Did you snack too much? Did you get pulled into lower-priority meetings? Did you work on some other urgent stuff that is actually OK to drop your tasks for? Keep any insights at the top of your "weekly plans" doc so you can remind yourself of them and try to avoid making the same errors repeatedly. Breaking your long-term goals into milestones also gives you some "snack-like" satisfaction before you get to the finish line and earn the big payoff.

2. Every day, pick a task that you're going to do "hell or high water". Try to get that done before you snack. Typically this is (a piece of) one of your weekly tasks. If your calendar is prone to getting filled up with meetings, block off some "maker time" on your calendar to get this task done. I find it helpful to preemptively schedule timeslots for my project work at the beginning of the week even when my calendar is likely to remain open; it keeps me honest.

3. Timebox your snacking. If you feel like you need a break from longer-range tasks, you want to get an energy boost, etc., set a timebox, say "1 hours refactoring these tests", and try to return to your hell-or-high-water task after that timebox. I find it easy to go down the rabbit hole when I start snacking, especially if I get deep into the flow state. Flow is good! But it can lead you astray from your longer-term goals if you're flowing on something that's not your #1 priority.

As for the mechanics of tracking your work, I have used a personal Trello, todo.txt doc, Roam, GDoc, pen & paper -- this is immensely personal but just having a single place where you can go back and remind yourself what you were supposed to be working on is really helpful.

This is great advice. I do something similar and it’s been working. The only thing I dont fully agree with is the tracking of work. I’ve found that tracking work has very little value to me, so I just don’t spend time on it.

The only time when tracking work has been really useful was when the Icelandic banks went bust during the crash of 2008. Having a log of work-done helped a little in trying to get paid after my client went down. But, in other cases, I’ve found that the result of the work is the log of work done.

I didn't use to track my work and I noticed that at yearly review time it's been pretty difficult to remind what I actually did for last year. I'd go through merged PRs in the main projects, but it's only a tip of the iceberg.

Some time ago we moved daily standup to Slack, and since then I have a pretty good history of what I did each day. I created a wiki page where every 1-3 months I try to summarize all the stuff I did in the quarter (code shipped, dashboards created, docs written & non code work done, like helping X ship Y -- with screenshots, links etc.) and then it gives me a bit of confidence boost during the perf review time.

Cannot upvote this enough. These are excellent ideas for managing work, constantly making forwards progress, and showing to yourself, and the world, that you are having an impact.

I would add that always double check on regular basis that at least one of the things you are working on is a priority for your manager. Use your 1:1 meetings to confirm this and make sure you are aligned, and where you arent, that there is an over-riding company-acceptable reason. The bigger the company, the more this matters.

> 3. Timebox your snacking.

I find the Pomodoro timer technique (25-minute timeboxes) helpful maintaining short-term focus (and for breaking my focus, giving me a chance to review whether I am snacking or need to move to a different task for my next 25-minute timebox).

A web-based Pomodoro timer I keep in a pinned tab: https://tomato-timer.com/

Checklists are useful for breaking a task down and providing incremental steps to progress through.

During my PhD I would write down what specific task I was working on in a work journal every half hour or so and it would help me refine the specific problem/question I was working on. At the end of the day I would have made a steady progression through a relatively abstract problem which might not have been apparent at the beginning.

I take the same approach with working on the various projects now as a software engineer. I find the act of documenting my progress/thoughts as I go extremely calming. There’s a balance to be struck here - I only take this approach when developing something new and I have to record all the things which didn’t work.

Definitely agree on snacking being very seductive - it makes you feel useful and doing stuff, but when you zoom out, it's usually very inconsequential

The mental game is very important. Definitely hard to work on the things that actually matter - they are usually difficult, new, more intricate to setup, etc. What I've found to work is to "just start on it" - starting is the hardest part. Telling yourself you'll do 15 minutes of it or something, so you will actually start. Usually, when the 15 minutes are up, I won't be stopping. The inertia goes from "not going it" to "doing it" and it's hard to change ha

Trick that often works for me: create a ticket in JIRA, explain well what has to be done, how, document gotchas etc.; assign to yourself; if it's a code ticket, create a local branch with ticket number.

I usually procrastinate when it's not clear what exactly has to be done and how, and writing it down somewhere helps immensely.

In my personal life, I adopted a "broad front" approach to long term projects.

By broad front, I mean that I'm inching a lot of things forward, instead of focusing all of my attention on a single breakthrough.

If my motivation is low, I'll do small things that will be helpful when my motivation returns. This includes planning, buying supplies, cleaning up the workspace (physical or digital) or implementing quality of life improvements. For example, I might not be ready to extract a bolt that broke in a motorcycle engine ([expletive]), but I can disassemble the engine, buy tools, or figure out how it's done.

Sometimes, this gets me right back into it. Sometimes it just makes it easier for another day. To keep with the analogy, I call it stabilizing the front.

If you do this, it's critical that you leave yourself an easy reintroduction to the project. This might be a 95% finished commit, or a really good readme. You shouldn't dread getting back into it because of the project's state.

I've found focusing on the hardest problems first when enthusiasm is high nets the best results as the difficulty over time of remaining tasks coincides with waning enthusiasm and fatigue. Focusing on small tasks first and delaying large problems has the opposite effect - unless there's not enough context to complete the larger tasks without completing smaller parts first.

>This mental game seems to me to be one of the huge factors that determine outcomes.

I realized this was true for my personal projects this year, but never realized it's also exactly the same as work.