in reply to How do you avoid "Code Burnout"?
There were unmistakeable non-code challenges. A combination of distributed team and personality issues, financial pressures of the "dot-bomb" and our largest benefactor losing millions in the week of September 11, finally pushed us under.
But the real burnout came from the team/technology challenges. I implemented several tightly-integrated concepts which made perfect sense to me, and was understood by my business partner, but which few of the rest of the team even tried to grok. It was opaque to them, no matter how I pitched the concept, the structure, the roadmap, code reviews, or offered examples. Nobody wanted to build on what I started, but kept trying to rebuild or reimplement things they were already familiar with instead. Nothing synergized. We were all stuck on our own concepts, myself included.
Every time I look at the code, I wistfully imagine the rest of the structure that was supposed to use it. It's exactly like looking at the unfinished arcology project called Arcosanti. I fantasize about somehow getting over the next hurdle of implementation privately, of a phoenix rebirth in code. Or hire a skunkworks crew of interns or offshore coders to haul the heavy parts. Then I look at my current lifestyle, a "day job" and a family, and realize it's just never going to happen. My years of invention just lie virtually dormant on a hard drive, in a dusty directory I visit a few times a month.
So in reply, I don't want to start from scratch, I want to use what I've built. I empathize with that sense of depression. Not sure what to say about how to get out of it, other than any other get-out-of-depression advice. Some comedian said in a mock mystic's voice, "I sit, and I think about myself, and I get depressed." I have found that's really the crux: if you stop sitting, or if you stop thinking about yourself, you can pull out of most average funks.
Taking a walk outdoors and exploring the problem-space may help you find different insights. Scribble diagrams on a pad of paper. Avoid the keyboard until you really have something you want to implement. Refactoring is useful, but only if you have a new user waiting impatiently to use and abuse the new interface.
[ e d @ h a l l e y . c c ]