5 ms·

This seems like great advice, and it resonates with me. I've seen people make a big impact by following this path. > It’s ok to spend some of your time on snac

by oilman 6y ago

This seems like great advice, and it resonates with me. I've seen people make a big impact by following this path. > It’s ok to spend some of your time on snacks to keep yourself motivated between bigger accomplishments, but you have to keep yourself honest about how much time you’re spending on high-impact work versus low-impact work. In senior roles, you’re more likely to self-determine your work and if you’re not deliberately tracking your work, it’s easy to catch yourself doing little to no high-impact work. In my own personal experience, that boost of actually accomplishing something right now instead of slowly starting the process of impactfully pushing another rock up a hill is very tempting. Does anyone have any experience or recommendations for effectively tracking your own work and putting yourself in the right headspace to tackle these more long lived impactful tasks? This mental game seems to me to be one of the huge factors that determine outcomes. I tend to have some challenges with attention at the best of times. My interests tend to run hot and cold. I can make a huge impact and move a project significantly forward when I get into it and hyperfocus on it. But other times managing to focus my attention on a tasks that I know would be high impact is mental torture.

wholien 6y ago
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
- jakub_g 6y ago
  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.
dt5702 6y ago
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.
theptip 6y ago
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.
- surfsvammel 6y ago
  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.
methodin 6y ago
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.
nullsense 6y ago
>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.
nicbou 6y ago
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.

by oilman 6y ago

wholien 6y ago

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

jakub_g 6y ago
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.

dt5702 6y ago

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.

theptip 6y ago

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.

surfsvammel 6y ago
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.

methodin 6y ago

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.

nullsense 6y ago

>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.

nicbou 6y ago

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.