Comment by olivierva | Hacker News Reader

Comment by olivierva | Hacker News Reader

I do like it when people set themselves challenges like this. Clear beginning and end, finishing something in combination with iterative learning is very satisfying. A bit like a hackaton or a game jam. But this made me think, because in a way it limits yourself in what you can do with what you previously learned. The more you learn the more complex projects you can create and halfway through you can create something which doesn't fit in a day anymore; complexity pushes build time up exponentially. E.g. it needs some extra tooling for generating procedural content. So what I propose is instead of 'over the course of 30 days I will every single day finish a project', why not follow the Fibonacci sequence: I start with nothing (procrastinating), next a one day project, followed by another single day effort. Stepping up with a 2 day project -> a big 3 day project -> 5 day full blown project -> 8 day epic. And finally: a full 13 days working on a single masterpiece! (33 days in total).

While there is of course value to tackling a more long term project, the following excerpt of Art and Fear comes to mind:

" The ceramics teacher announced on opening day that he was dividing the class into two groups. All those on the left side of the studio, he said, would be graded solely on the quantity of work they produced, all those on the right solely on its quality. His procedure was simple: on the final day of class he would bring in his bathroom scales and weigh the work of the "quantity" group: fifty pound of pots rated an "A", forty pounds a "B", and so on. Those being graded on "quality", however, needed to produce only one pot -- albeit a perfect one -- to get an "A". Well, came grading time and a curious fact emerged: the works of highest quality were all produced by the group being graded for quantity. It seems that while the "quantity" group was busily churning out piles of work - and learning from their mistakes -- the "quality" group had sat theorizing about perfection, and in the end had little more to show for their efforts than grandiose theories and a pile of dead clay. "

With this scheme if you do even 15 projects, you're already into multi-year time frames and your 25th project will take 200 years. Fibonacci numbers grow quickly!

Knowing when to stop is one of the most important things about delivering a project. After trying this method a couple of times I think many will have learned when to draw the line.

I'm trying something like this to get over shipping anxiety. First a project scoped to one day, then a project scoped to a week, and then finally a project scoped to a month. So far I've done the one day project: https://github.com/milesrichardson/docker-nfqueue-scapy

This is a good approach from a learning and skill improvement perspective. Thanks.

I like that except that when learning something it's hard to know in advance how many days it will take. Instead, you could substitute key pieces of functionality for days.

Wow. Interesting approach to learning.

That is a interesting approach. Thanks.

Definitely an interesting approach.

Reply on news.ycombinator.com