Completing tasks by time-boxing at several fixed intervals

3 pointserlich2y ago3 comments

Especially in computer programming, I find that you really can take as much time as is given. You often can see people spending weeks on something that could be done in under an hour. The scope seems to grow with the amount of time you have, and the difficulty in asking for more time. Sunk costs also factor into requesting more time - if you have already spend a long time on something, its easier to get more time.

*The idea is to perform a task and produce a demo-able deliverable as quickly as you can in 30 mins. Then 1 hour. Then a day. Then a week.*

The idea is to force people to explore the fastest possible solution first.

I think this can help:

- analysis paralysis - you have to pick your library/framework/technology/approach super fast. There is so much choice and this can help force a quick decision and accelerate the learning by doing rather than by reading. - motivation - you feel the rush of a deadline in the first day...instead of the "I wish I had more time" feeling just before the deadline. - "it couldn't be that simple" - sometimes things can be really simple...especially if you step outside of your existing tech stack / process. There might be a library out there that does everything for you...but you embarked on a roll-your-own approach that has taken you months. This forces you to explore the quickest modern solution that you might have disregarded.

I haven't tried it yet, but was interested if anyone has tried something similar.

3 comments

nivertech2y ago

Demo-driven development is a great forcing function and it can work.

Also when you demo something to the management/stakeholders, you communicate progress, and even can get some additional funding/budget/time.

When you demoing for yourself/team, you can get more confidence in yourself and some dopamine.

This can be relevant:

My approach to building large technical projects (mitchellh.com)

https://news.ycombinator.com/item?id=36161397

dingosity2y ago

I've been doing something like this about 33% of the time for the last couple decades. The Agile guys glommed on to time-boxing and called it "sprints" but seemed to think time-boxing is only effective at multi-week scale.

A couple jobs back we experimented with coordinating our time-boxes (gang scheduling) when we were working in the same code base. We would do four 45 minute chunks, then spend 5 minutes emailing / slacking each other and 10 minutes to play beer-pong (actually it was set aside for chatting if we needed to chat.)

The rest of the day was spent sorta however you thought you might need to spend it.

Sometimes we would do it all day long. Some days we wouldn't do it at all. But a lot of us got into the habit of picking a small bit of work, doing it, then seeing where you are in the overall process. It also helped us avoid rabbit-holes. Our dev culture evolved to this place where people waited until the top of the hour to chat with co-workers unless it was an emergency. That was pretty cool 'cause you had a reasonable expectation of getting 45-55 minutes of uninterrupted coding time.

I definitely recommend recruiting co-workers to try it if you're working with other people in the same code base.

erlichOP2y ago

> It also helped us avoid rabbit-holes.

I think this is a big 1. There are so many in modern coding.

j / k navigate · click thread line to collapse