Rapid prototyping as burnout antidote
gabrielweinberg.com
gabrielweinberg.com
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.
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 :))
Sure (although a lot are websites that were shut down later on, to focus my resources):
[1] http://www.learnivore.com (ruby,rails,iphone screencasts aggregator)
[2] http://www.toutpourmonipad.com (ipad case finder for the french market)
[3] http://github.com/thbar/opaz-plugdk (an experiment to create VST plugins using JRuby and Java)
[4] http://github.com/thbar/music-labs (more music stuff with ruby)
[5] http://github.com/thbar/petite-lettre (a little ruby gem for inter-process communication based on yaml)
[6] http://github.com/thbar/magic (a DSL to make it easier to implement UI with IronRuby, WPF and Windows Forms)
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.
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 ...
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.
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...
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).
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.
Then iterate.
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.
Thanks!
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.