Hacker News Reader

Comment by dclara | Hacker News Reader

That's really true. Counting for hours regardless of the intensity of workload is meaningless. I also think the OP's meaning behind how the hours is counted is regarding the full capacity of work load during the day, instead of including everything work related.

The intensity of the software development prevents one to work over 8 hours a day, and even not for too long without a break. What I mean is pretty much continuous work, reading news, emails and making calls are not included. This number is usually 5 hours for some standard software companies, which usually have meetings and chatting from time to time during the 8 hours of office work.

Everybody has his own strength during different age range. As startup company, it's really necessary to work 60-80 hours a week including overall work related activities. Just make sure not to burn out yourself.

View on HN

I can do 8 hours of light-weight development easily enough, things like minor bugfixes, minor tweaks, etc. and carry that on for months if needed. But for stuff like coding from scratch, aside from brief bursts, I usually find that 4 hours is a good general guide. Obviously when nearing release, the long stretches of 8-10 hours of coding is going to be much lighter. Most of the tweaks are going to be minor, you hope, and so you can throw the rules out the window for a bit.

If you are working 60-80 hours a week, hopefully you aren't just doing one thing. It's one thing to put in 20 hours a week on software development, 20 hours a week on sales and marketing, 20 hours a week on fundraising, and 20 hours a week on business administration. It is far worse to put in 40 hours a week on software development, IMO.

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.

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.

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.

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.

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.

Reply on news.ycombinator.com