7 ms·

Yes, on top of the 40 hours of intensive work including design, coding, learn a new technology with intensive reading, or even tackling business/marketing strat

by dclara 13y ago

Yes, on top of the 40 hours of intensive work including design, coding, learn a new technology with intensive reading, or even tackling business/marketing strategies and tactics, etc., the rest hours are on lighter work related things, such as email, news, phone calls, book-keeping, etc. Regarding how to dividing the time slots, my usual practice is to concentrate on one major task and get it done completely in the shortest time period. For example, while I'm doing patent application, I have to complete it with all the available resources being collected and everything in the real-time memory for 2-3 weeks until it can pass the criteria. If it's a software development or fundraising, it may take 3-4 weeks to finish one round of intensive development and reach a milestone. After that period, I'm pretty much exhausted, and have to switch to something else to concentrate on, just like what you said. Focus and hammer down the nails with a deadline in mind is so important. Bug-fixing is a side job, light but time-consuming to cover every possible exceptional cases, but it also depends on whether it needs a redesign.

einhverfr 13y ago
At the same time, I find that being willing to quit and come back is important to. I usually devote blocks of 4 hours to achievable tasks in that case. However if I run into problems getting things where they need to go, after 2-3 blocks, I may shelve the task and come back later as needed. There are times when quitting is necessary for perspective, and where you can get the same task done quicker by quitting and moving onto something else, and then when you need to, coming back, than you would by pushing for a deadline. Learning to recognize that there are signs of "I don't really understand this problem, so I should come back after I have a chance to digest my failure today" and recognizing when that's a good idea takes some time though.
- dclara 13y ago
  You reminded me in some cases I did, but I don't feel well about that. But I've already spent too much time on one item, if I didn't quit, it would delay the rest of the tasks. Most of the time, I have to do extra hours of work to get it completed. Otherwise, it's hard get chance to revisit again unless it's a critical feature or bug. Another strategy is, just like what you mentioned, once we are stuck at somewhere for more than 4 hours, we have to move to other tasks, give it up temporarily and later on when we come back, maybe things changed or mind changed, it's no longer that hard any more.
  - einhverfr 13y ago
    I have found that if I never get the opportunity, chances are it wasn't important anyway. For a lot of things that seem to be moth-balled, they have an amazing way of coming up later. For example, a month after I gave up on rewriting the financial logic for LedgerSMB, I got a project that required a small subset of rewritten code there. So I went ahead, took the short cuts required for that, wrote an implementation and such in a half a day, from scratch, when my previous attempt took two weeks with nothing to show from it. That lead to starting the rewrite again which will begin again in earnest after 1.4 branches off. Instead of budgetting months, I am now budgetting only days.
    - dclara 13y ago
      Yes, budgeting for days instead of budgeting for months. When we well manage the task list, usually a feature implementation takes 1-3 days, a project may take 3-4 weeks to reach a milestone. So no feature can take more than a week to finish. Priority is the key.

by dclara 13y ago

einhverfr 13y ago

At the same time, I find that being willing to quit and come back is important to. I usually devote blocks of 4 hours to achievable tasks in that case. However if I run into problems getting things where they need to go, after 2-3 blocks, I may shelve the task and come back later as needed. There are times when quitting is necessary for perspective, and where you can get the same task done quicker by quitting and moving onto something else, and then when you need to, coming back, than you would by pushing for a deadline. Learning to recognize that there are signs of "I don't really understand this problem, so I should come back after I have a chance to digest my failure today" and recognizing when that's a good idea takes some time though.

dclara 13y ago
You reminded me in some cases I did, but I don't feel well about that. But I've already spent too much time on one item, if I didn't quit, it would delay the rest of the tasks. Most of the time, I have to do extra hours of work to get it completed. Otherwise, it's hard get chance to revisit again unless it's a critical feature or bug. Another strategy is, just like what you mentioned, once we are stuck at somewhere for more than 4 hours, we have to move to other tasks, give it up temporarily and later on when we come back, maybe things changed or mind changed, it's no longer that hard any more.
- einhverfr 13y ago
  I have found that if I never get the opportunity, chances are it wasn't important anyway. For a lot of things that seem to be moth-balled, they have an amazing way of coming up later. For example, a month after I gave up on rewriting the financial logic for LedgerSMB, I got a project that required a small subset of rewritten code there. So I went ahead, took the short cuts required for that, wrote an implementation and such in a half a day, from scratch, when my previous attempt took two weeks with nothing to show from it. That lead to starting the rewrite again which will begin again in earnest after 1.4 branches off. Instead of budgetting months, I am now budgetting only days.
  - dclara 13y ago
    Yes, budgeting for days instead of budgeting for months. When we well manage the task list, usually a feature implementation takes 1-3 days, a project may take 3-4 weeks to reach a milestone. So no feature can take more than a week to finish. Priority is the key.