3 ms·

I think this is backwards from what works for me. For me, the difficulty is always in starting something new. It doesn't matter what time of day it happens, if

I think this is backwards from what works for me. For me, the difficulty is always in starting something new. It doesn't matter what time of day it happens, if I finish something, and I'm proud of it, I have almost zero motivation to get to work on the next thing. I get that you're trying to prevent morning lethargy from coinciding with decision avoidance, but I think I have a better system. Don't end the day just before you finish. End the day just after you start, just at the part where it starts getting good. The next morning, you'll be excited to come in, because you know what to try next. You can ride that high into your morning standup, confidently say "this is what I will do today," and ideally a half hour before quitting time, you'll finish what you're working on, and while you might be tempted to say "done enough, time to go home," you won't do that. Instead, start on the next thing. Spend 30 minutes figuring through it. Figure out an approach, write it in your journal, and then go home. Start implementing again tomorrow, and repeat the process.

philbarr 13y ago
I like the idea, but I find it really difficult to actually stop when I'm "in the zone". I tend to recognise when I am and treasure those moments of hyper-productivity to get lots done. I use the technique in the article and have for a while. I find that the relatively easy task of fixing a compile error will gently lead me back into coding. I expect it's a personal thing, though. As an aside, I like to leave a bunch of TODOs lying around in code for things like documentation, so I can come back and do that boring stuff when I'm feeling brain dead. I never use TODO for something important that needs to be done because chances are it won't! (I don't know why, I think it's just something about the nature of TODO).

philbarr 13y ago

I like the idea, but I find it really difficult to actually stop when I'm "in the zone". I tend to recognise when I am and treasure those moments of hyper-productivity to get lots done. I use the technique in the article and have for a while. I find that the relatively easy task of fixing a compile error will gently lead me back into coding. I expect it's a personal thing, though. As an aside, I like to leave a bunch of TODOs lying around in code for things like documentation, so I can come back and do that boring stuff when I'm feeling brain dead. I never use TODO for something important that needs to be done because chances are it won't! (I don't know why, I think it's just something about the nature of TODO).