4 ms·

I like the method but for me personally as a young unexperienced person, the problem usually lies in evaluating whether a task is possible in a day. I tend to

I like the method but for me personally as a young unexperienced person, the problem usually lies in evaluating whether a task is possible in a day. I tend to be overly excited and thus think that I can finish something that takes a week in a day. Then when I give myself more time for something I finish it more quickly...

faeyanpiraat 6y ago
Everyone started out like that, so don’t get discouraged. The key is to excercise the estimation muscle. Keep logs about your estimations and how long it actually took. Then think through periodically what caused the big differences. This way in the long run you’ll be able to precisely estimate tasks you’ve sort of already done in the past, and can estimate a reasonable low/high time range to finish tasks which you’ve never done before.
macintux 6y ago
Note the last sentence: > Typically the goals I choose are things that might take one to two hours of focused effort. Very few of us can accurately estimate what will take a day, but an hour is much more manageable.
- msaltz 6y ago
  Author here :) I'd echo this. It's really crucial that you limit your goal for the day to something that you have nearly 100 percent confidence about. So even if you think "I can do this whole thing today!", you should just pick off the first piece of it that's definitely attainable to use as your goal. In addition, on the few occasions where I didn't manage to hit my goal by the end of the day (maybe three times in the last month), I'd take the time to figure out why that was and think of how I could have reframed the goal in a way that would have made it achievable. Usually when I missed a goal it was because it was either not specific enough or it was dependent on something else. For example, I might have had "Push XYZ patch", when it should have been "Make bugfixes to XYZ patch and push if able", since there's always the possibility that the latest fixes introduce an unexpected problem or that the reviewer won't get to the code review that day.
  - macintux 6y ago
    Thanks for the article. I'm looking forward to giving this approach a try at work next week.

faeyanpiraat 6y ago

Everyone started out like that, so don’t get discouraged. The key is to excercise the estimation muscle. Keep logs about your estimations and how long it actually took. Then think through periodically what caused the big differences. This way in the long run you’ll be able to precisely estimate tasks you’ve sort of already done in the past, and can estimate a reasonable low/high time range to finish tasks which you’ve never done before.

macintux 6y ago

Note the last sentence: > Typically the goals I choose are things that might take one to two hours of focused effort. Very few of us can accurately estimate what will take a day, but an hour is much more manageable.

msaltz 6y ago
Author here :) I'd echo this. It's really crucial that you limit your goal for the day to something that you have nearly 100 percent confidence about. So even if you think "I can do this whole thing today!", you should just pick off the first piece of it that's definitely attainable to use as your goal. In addition, on the few occasions where I didn't manage to hit my goal by the end of the day (maybe three times in the last month), I'd take the time to figure out why that was and think of how I could have reframed the goal in a way that would have made it achievable. Usually when I missed a goal it was because it was either not specific enough or it was dependent on something else. For example, I might have had "Push XYZ patch", when it should have been "Make bugfixes to XYZ patch and push if able", since there's always the possibility that the latest fixes introduce an unexpected problem or that the reviewer won't get to the code review that day.
- macintux 6y ago
  Thanks for the article. I'm looking forward to giving this approach a try at work next week.