We recently decided to stop diving in too deep on tasks right away. Instead, we’re going for four hour chunks upfront. We start work on a task and then, after the first four hours, come up for air.
Why? When you’ve done nothing, you don’t have a realistic view of what it’s going to take. But when you’ve spent days or weeks on something, you can get too invested. It becomes hard to change, admit you’re wrong, or that what you’ve been doing isn’t actually worth more effort.
Four hours lets you get your toes wet. Then you ask questions. Is this worth continuing? Are you on the right track? Is there a way to judo this? Should you bring in another set of eyes?
If it’s all good, then keep on going. But a lot of times this forced break can reveal hidden solutions and/or lead you in a different direction.
It’s easy to get excited about solving the problem at hand, even if the solution is complex. But then you can wind up spending way too long on a problem that’s just not worth it. Sometimes you’re better off restating the problem or even tabling it and moving on to something more important. The four-hour upfront technique prevents you from going too far in the wrong direction.
Tim
on 21 Jun 07I’m assuming you are talking about taking four hour design breaks – since you can visually see what you have at the end of that time.
Whereas for programming, it’s really difficult to see what you have until it’s done.
DHH
on 21 Jun 07We’re actually talking about programming here. While design tasks can definitely suffer from unexpected complexity, it’s more or less the norm with programming tasks. Thus, it’s way more important to reflect on the latter after you’ve had enough of a taste to get an idea of whether this is a good direction or not.
ML
on 21 Jun 07Design and programming. “Go until you’re done” can lead you down the rabbit hole. Instead, do enough to guage how far away from finishing you are (if four hours isn’t enough, then go until you’ve got some sort of basic idea) and then ask if there’s a better way.
Neeraj Kumar
on 21 Jun 07You are so damn right. The night before I working on a complex set of tabs sitting next to my wife while she was watching TV. After couple of hours hours (yes bollywood movies are really longgggg) she had finished the movie and I was no closer to getting it done.
I conveyed my frustration to her and the solution she proposed was not only simpler but more intuitive too.
I guess I should take break after every 3 hours.
Ian Lotinsky
on 21 Jun 07Yesterday I wrestled with ASP.NET Repeaters for a few hours trying to accomplish something trivial. I could have continued down the path I was forging for a couple more hours in frustration but decided to take a fifteen-minute breather.
When I came back to my computer I realized that the direction I was headed in just wasn’t working and designed and coded an alternate solution within half an hour.
(Agile Web Development with Rails arrived in the mail yesterday. I’m looking forward to working with a framework that doesn’t break the Web.)
Brian Anderson
on 21 Jun 07Excellent article coming at the perfect time. I am in the rabbit hole as we speak. Thanks for the reminder!
Andy Kant
on 21 Jun 07This is a great practice especially for breaking up development and testing periods. For programming milestones, I usually try to drop it for the rest of the day and come back the next day for review/testing. It helps to clear your head, and more often than not, you’ll catch alot more than if you do it consecutively.
y0mbo
on 21 Jun 07So what do you do after the four hours? Start another task? Have a meeting? It would seem to me that you need a similar but different think to do so your mind can determine if the rabbit hole is good or not.
ML
on 21 Jun 07So what do you do after the four hours?
There’s usually plenty of other things that need attention. Or go for a walk. Or time it so it’s the end of the day. Then you can review tomorrow w/ fresh eyes.
Mrad
on 21 Jun 07Good call, but obviously there have to be exceptions to this rule. If I’m crankin’ on something and feeling really good about it, I’m not gonna break that momentum. It’s just way too hard to get it back.
JF
on 21 Jun 07Good call, but obviously there have to be exceptions to this rule.
No. No exceptions ever. Of course there are exceptions. Does that need to be said about anything anymore? Everything has exceptions. We assume reasonable people understand this.
Chris S
on 21 Jun 07Yeah I haven’t paid attention to the time, but that’s about right…after 3-5 hours the frustration level forces me to take a break. I actually go for a walk, get some coffee, and say to myself, “I don’t have any idea where to go next with this.”
Invariably, when I get back to the desk, I keep TextMate closed and scribble some pseudo code. I almost always end up seeing that I was actually trying to build an elephant and shove it down the rabbit hole, when there was really a much smaller and simpler rabbit sitting there the whole time…but my elephant was in the way :-)
Keith
on 21 Jun 07I’ll go ahead and plug a few of my favorite design ideas that fit really well into the “4 hour chunks” idea laid out here:
Jakob Nielsen’s Paper Prototyping http://www.useit.com/alertbox/20030414.html
A List Apart’s Paper Prototyping http://alistapart.com/articles/paperprototyping
Plus, if you are working on something solo, or in a small team, paper prototyping gives you an immediate artifact to demonstrate to fresh eyes.
I suspect almost everyone has seen these, but in the framework of working on issues like this in 4 hour chunks, this makes life A LOT easier.
It’s almost too easy to let any single task get too far before you have a chance to reflect on what you’re trying to accomplish and then make a decision on how far divergent your current line of thinking has become with what you actually NEED.
Paul Howson
on 21 Jun 07In my experience, the conscious mind can only go so far in solving a problem. There is a point of diminishing return—often after a few hours hammering away at a problem. The temptation is to keep pushing harder, but this often ends up in feeling angry and frustrated.
I’ve learned that it is better to take a break—go for a walk, do some physical work, etc. Then, hey presto, the unconscious/subconscious mind kicks in and the answers you need percolate up to the conscious mind. The magic ingredient here is allowing time and space for the mind to produce the answer.
If you have a quieting practice (“meditation”) as part of your daily routine, this can be very helpful in resting the mind and allowing this subtle mechanism to operate. So many times the simple and elegant solution I’m seeking just appears while I’m sitting quietly, withdrawing from the outer busyness.
I think this ties in with Jason Fried’s statements about not working too hard on problems—less really can be more.
Garth
on 22 Jun 07I’ve been working this way for years. Walking away from a problem or even a proposed solution encourages other avenues of thinking and gets your lateral juices flowing!
Michael
on 22 Jun 07@JF You are a hard ass. The guy is just trying to contribute. You are trying to do one of two things, be funny or be a jerk. If it’s the former try to make that more clear. If it’s the latter get off of your high horse. You make great stuff and I enjoy your posts but not everyone thinks the same way you do. If they want to try to make things a little more clear does that mean they are not reasonable people?
RJ
on 22 Jun 07Joking aside, I think this is a really great practice. It’s desperately hard to fix a coding problem once you’re more than 5-6 hours in to it. We have issues with this sometimes that take a slightly different look – the project management team start the programmers on developing before the UI design is finalized. If the developers spend more than a few days coding without the final comps, and the interface is at all complicated, it usually requires big changes in the code that waste a lot of time. Stopping every so often to re-evaluate is extremely important.
Maggie
on 22 Jun 07What Michael said.
Peculiar Paolo
on 26 Jun 07I read somewhere that P&G implements / encourages a similar “protocol”. I remember CEO Laffley calling it “the Corporate Athlete program”. The idea is to work in “bursts” and consciously taking breaks in between.
Joske
on 26 Jun 07When I start on a new programming task, I start at 2pm. This allows me to start programming through the afternoon. When I stop to go home, it gives me plenty of time through the evening and night to recapitulate about the job.
This discussion is closed.