5 ms·

Rapid prototyping as burnout antidote

118 points by bjplink 16y ago

_pius 16y ago
This is very true. The only problem with this approach is that you can end up with a lots of "little fish" projects instead of making headway on your "Moby Dick" one.
- philh 16y ago
  If the goal is to cure burnout, that's only a problem if you feel compelled to continue work on the little fish projects. I find that if I get a new project, it tends to push an old one from my mind, so there's not much more mental clutter than before.
  - _pius 16y ago
    I guess, but I was thinking more of the case where you end up in a cycle of constantly taking new ideas and making minimum viable products out of them without developing them (or your big idea) further. Of course, that's a much better "problem" to have than to be mentally constipated for long periods of time without bringing anything to fruition ...
- fleaflicker 16y ago
  I often split my big projects into smaller deployable pieces (e.g., rather than 1 large feature launch, "silently" deploy backend changes first, then expose in the UI). This approach also helps in debugging: deploy and fix each piece incrementally. The only times I've burned out are when working on a massive update without any visible progress. When I finally deployed, I would be overwhelmed with a huge number of bugs to fix.
- anthonyb 16y ago
  Except that most Moby Dick projects started out as little fish - Twitter and Flickr spring to mind.
  - _pius 16y ago
    Damn good point.
riffer 16y ago
Yes, this really works. Sort of the way some teams seem to keep a set of blog posts on the shelf, ready to go, we have a list of small tangential projects. These are all three-days-to-a-week type things where we are already pretty familiar with 80-90% such that we can move through it quickly, but also get exposure to something new that we've been meaning to pick up. That combination of quick tangible progress plus learning really clears out any negativity.
_chap 16y ago
yes.
thibaut_barrere 16y ago
I noticed a somewhat similar effect which I named "ProcrastinaBoost" (patent pending, obviously). When working on a long/difficult project A, I keep one smaller but equally interesting (ROI-wise) project B on the side, and ensure I procrastinate in a time-boxed fashion on the useful project B only (vs. more classical procrastination). The time-boxing ensure this stays at the hobby level, and regularly project B becomes difficult too to kick you back into project A. It also gives me some times to relax and think about the issues on the other project. To be used with careful time tracking of course :) This removes a bit of the burn-out feeling, while still working on something that moves us along.
- gjm11 16y ago
  Prior art: http://www.structuredprocrastination.com/ http://www.structuredprocrastination.com/ .
  - thibaut_barrere 16y ago
    Amazing, thanks! That's really one of the things I like most about HN (useful, insightful comments).
  - RyanMcGreal 16y ago
    Hah! The only way I can ever do anything is as a way of not doing something else: http://quandyfactory.com/blog/1/ http://quandyfactory.com/blog/1/
- y0ghur7_xxx 16y ago
  The time-boxing ensure this stays at the hobby level, and regularly project B becomes difficult too to kick you back into project A. I too do exactly the same. Most of the time it's some quick rails app[1] or some server side scripts that do something I never did before (like parsing mails, pg stored procedures or some jquery[2]). Do you have some links to your side projects/no-burnout-work? [1]http://diffuse.it/ http://diffuse.it/ (a blog that is actually used by me, my girlfriend and 2 friends :)) [2]http://31337.it/ http://31337.it/
ez77 16y ago
I hope I'm not flagged as a spammer over this, since I tend to make this point every chance I get. Namely, how exactly do you go about rapid prototyping? I figure in all likelihood it's a bit of an art and requires a lot of experience and knowledge. I realize I may not be there yet. Still, are there any highly recommended references? Books are OK, but in particular videos would help the most. Seeing how experienced programmers kick off a project could (I think) shed much light. PeepCode looks serious, but it focuses too much on one particular technology. Thanks, and sorry to keep bugging with this...
- rman666 16y ago
  This is the first time I've seen your question, so it isn't spam to me :-) To me, rapid prototyping is any technique that will allow you to build 'something' that will give you a feel for what working with a deployable version might be like. Such prototypes can be paper-based, built in PowerPoint, built in an easy-to-prototype language (i.e, Lisp), etc. The key is to quickly see what the 'final' version _might_ be like so you can think more clearly, talk about it, demonstrate it, get feedback, etc. Or, am I answering the wrong question? (See, even my answer is a prototype ... it allows me to get feedback).
  - Retric 16y ago
    People also often model what you want to do in the Excel / Access / Mathmatica world first.
- astrofinch 16y ago
  I'm not sure there are any secrets to it. 1. Should I include this feature in the first release? -- If there's a significant chance that the feature will make the difference between your product having users and not having users, add it. Otherwise don't. 2. I realized I definitely should have implemented Feature X differently. Should I reimplement it before release? -- No, unless Feature X is core to your product and this reimplementation might make the difference between users/no users, or unless Feature X's implementation will have a significant impact on your application's architecture, and you still have a fair amount of coding to do prior to first release. Obviously these are just heuristics. For example, if including a feature would be as simple as changing a configuration directive, you can include it in the first release even if there's not a significant change it would make the difference between no users/users. The way to think about it is that as a programmer, you've got kind of a potential possibility curve--when you're at your best, you can write clean performant code slowly, or featureful dirty nonperformant code quickly, etc. And when you're rapid prototyping, you're optimizing to write nonfeatureful nonperformant moderately clean code quickly.
milesf 16y ago
There's no such thing as burnout. It's really heartache in disguise.
- midnightmonster 16y ago
  Universal negative is hard to prove, but this has a ring of at least partial truth.
- chmike 16y ago
  I'm not sure I understood what you mean. What I know is that burnout, as it is commonly described, is perfectly real.
ww520 16y ago
It absolutely works for me. It's called "strategic procrastination." It let me channel my creative energy to a different use when working in a long and difficult project. Retaining control over creative freedom is very important for motivation and avoiding burnout. The nice thing about being your own boss is that you can change the schedule anytime you want. :)
jakevoytko 16y ago
This isn't startup specific! I work on projects with long development cycles, and rapid prototyping outside of work is very therapeutic. You can amplify the healing power with the right tools: in my case, Python and Git. There's nothing more satisfying than creating something in a few days, or extending an existing project to do more. Be sure to let someone know you did something! Thankfully my girlfriend listens to me babble about my minor wins, even when they sound ridiculous or incomprehensible.

118 points by bjplink 16y ago

_pius 16y ago

This is very true. The only problem with this approach is that you can end up with a lots of "little fish" projects instead of making headway on your "Moby Dick" one.

philh 16y ago
If the goal is to cure burnout, that's only a problem if you feel compelled to continue work on the little fish projects. I find that if I get a new project, it tends to push an old one from my mind, so there's not much more mental clutter than before.
- _pius 16y ago
  I guess, but I was thinking more of the case where you end up in a cycle of constantly taking new ideas and making minimum viable products out of them without developing them (or your big idea) further. Of course, that's a much better "problem" to have than to be mentally constipated for long periods of time without bringing anything to fruition ...
fleaflicker 16y ago
I often split my big projects into smaller deployable pieces (e.g., rather than 1 large feature launch, "silently" deploy backend changes first, then expose in the UI). This approach also helps in debugging: deploy and fix each piece incrementally. The only times I've burned out are when working on a massive update without any visible progress. When I finally deployed, I would be overwhelmed with a huge number of bugs to fix.
anthonyb 16y ago
Except that most Moby Dick projects started out as little fish - Twitter and Flickr spring to mind.
- _pius 16y ago
  Damn good point.

riffer 16y ago

Yes, this really works. Sort of the way some teams seem to keep a set of blog posts on the shelf, ready to go, we have a list of small tangential projects. These are all three-days-to-a-week type things where we are already pretty familiar with 80-90% such that we can move through it quickly, but also get exposure to something new that we've been meaning to pick up. That combination of quick tangible progress plus learning really clears out any negativity.

_chap 16y ago

yes.

thibaut_barrere 16y ago

I noticed a somewhat similar effect which I named "ProcrastinaBoost" (patent pending, obviously). When working on a long/difficult project A, I keep one smaller but equally interesting (ROI-wise) project B on the side, and ensure I procrastinate in a time-boxed fashion on the useful project B only (vs. more classical procrastination). The time-boxing ensure this stays at the hobby level, and regularly project B becomes difficult too to kick you back into project A. It also gives me some times to relax and think about the issues on the other project. To be used with careful time tracking of course :) This removes a bit of the burn-out feeling, while still working on something that moves us along.

gjm11 16y ago
Prior art: http://www.structuredprocrastination.com/ http://www.structuredprocrastination.com/ .
- thibaut_barrere 16y ago
  Amazing, thanks! That's really one of the things I like most about HN (useful, insightful comments).
- RyanMcGreal 16y ago
  Hah! The only way I can ever do anything is as a way of not doing something else: http://quandyfactory.com/blog/1/ http://quandyfactory.com/blog/1/
y0ghur7_xxx 16y ago
The time-boxing ensure this stays at the hobby level, and regularly project B becomes difficult too to kick you back into project A. I too do exactly the same. Most of the time it's some quick rails app[1] or some server side scripts that do something I never did before (like parsing mails, pg stored procedures or some jquery[2]). Do you have some links to your side projects/no-burnout-work? [1]http://diffuse.it/ http://diffuse.it/ (a blog that is actually used by me, my girlfriend and 2 friends :)) [2]http://31337.it/ http://31337.it/

ez77 16y ago

I hope I'm not flagged as a spammer over this, since I tend to make this point every chance I get. Namely, how exactly do you go about rapid prototyping? I figure in all likelihood it's a bit of an art and requires a lot of experience and knowledge. I realize I may not be there yet. Still, are there any highly recommended references? Books are OK, but in particular videos would help the most. Seeing how experienced programmers kick off a project could (I think) shed much light. PeepCode looks serious, but it focuses too much on one particular technology. Thanks, and sorry to keep bugging with this...

rman666 16y ago
This is the first time I've seen your question, so it isn't spam to me :-) To me, rapid prototyping is any technique that will allow you to build 'something' that will give you a feel for what working with a deployable version might be like. Such prototypes can be paper-based, built in PowerPoint, built in an easy-to-prototype language (i.e, Lisp), etc. The key is to quickly see what the 'final' version _might_ be like so you can think more clearly, talk about it, demonstrate it, get feedback, etc. Or, am I answering the wrong question? (See, even my answer is a prototype ... it allows me to get feedback).
- Retric 16y ago
  People also often model what you want to do in the Excel / Access / Mathmatica world first.
astrofinch 16y ago
I'm not sure there are any secrets to it. 1. Should I include this feature in the first release? -- If there's a significant chance that the feature will make the difference between your product having users and not having users, add it. Otherwise don't. 2. I realized I definitely should have implemented Feature X differently. Should I reimplement it before release? -- No, unless Feature X is core to your product and this reimplementation might make the difference between users/no users, or unless Feature X's implementation will have a significant impact on your application's architecture, and you still have a fair amount of coding to do prior to first release. Obviously these are just heuristics. For example, if including a feature would be as simple as changing a configuration directive, you can include it in the first release even if there's not a significant change it would make the difference between no users/users. The way to think about it is that as a programmer, you've got kind of a potential possibility curve--when you're at your best, you can write clean performant code slowly, or featureful dirty nonperformant code quickly, etc. And when you're rapid prototyping, you're optimizing to write nonfeatureful nonperformant moderately clean code quickly.

milesf 16y ago

There's no such thing as burnout. It's really heartache in disguise.

midnightmonster 16y ago
Universal negative is hard to prove, but this has a ring of at least partial truth.
chmike 16y ago
I'm not sure I understood what you mean. What I know is that burnout, as it is commonly described, is perfectly real.

ww520 16y ago

It absolutely works for me. It's called "strategic procrastination." It let me channel my creative energy to a different use when working in a long and difficult project. Retaining control over creative freedom is very important for motivation and avoiding burnout. The nice thing about being your own boss is that you can change the schedule anytime you want. :)

jakevoytko 16y ago

This isn't startup specific! I work on projects with long development cycles, and rapid prototyping outside of work is very therapeutic. You can amplify the healing power with the right tools: in my case, Python and Git. There's nothing more satisfying than creating something in a few days, or extending an existing project to do more. Be sure to let someone know you did something! Thankfully my girlfriend listens to me babble about my minor wins, even when they sound ridiculous or incomprehensible.