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.
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/ (a blog that is actually used by me, my girlfriend and 2 friends :))
I have one side-project ongoing (that I will mention here later on) and another one for after.
I have learned a lot on each of these projects - bits that have most of the time been reused shortly after on customer projects (sphinx, mongodb, jruby...).
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.
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.
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.
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.
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 ...
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.
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.
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).
If you are working in a slow to develop language like Java or C++, it often helps to use Python, Ruby, or the like to get a quick proof of concept that finds the gotchas and lets users poke holes in the implementation. The total implementation time, including reimplementing in the production language, may actually be less.
I have found that as I've gained more experience, my ability to rapid-prototype has gone down - it's extremely hard to break out of the habit of doing things the 'right way' and go back to doing them 'the fast way'. (On the other hand, my prototypes actually work).
Get to know some basic building blocks in one language really well (e.g. simple CRUD patterns in PHP), then design and build everything around those. It'll be messy, but rapid prototyping is often not the place for elegant architecture.
Experience is invaluable when you're prototyping something that requires a lot of knowledge (e.g. APIs), but for most web apps, most things you would want to prototype can done very quickly with limited knowledge.
If you're stuck on getting started, just grab some example code (App Engine has plenty) that does something close to what you want, then hack away at it until it gets closer, then let error messages and satisfaction drive you the rest of the way.
Thank you all for your replies. I'll try to be more specific. I feel I need some technical guidance in how to get a moderately interactive site up and running. Google App Engine seems interesting, and what I have in mind is to build a simple database backend with some forms, just for practice, and especially motivation. I know some python, some html, less js, little css... but as I have a day job and a family I feel I will never deploy anything (even if it's just a hobby) if I try to learn each area well enough.
This is the kind of project kickoff that I mean: actual code for some "dumb", simple project. I'm guilty of course of spending too much time on single, specific topics that are not really necessary at this stage. (Say, how to make the forms look good, how to validate them with js, etc., even though the whole project is not there yet.)
Will get there someday! At least to a hobby-worthy level.
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.
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. :)
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.