In April of '89 I left my family and friends to move from Michigan to Massachusetts for a programming job. The new job paid twice as much as my first programming job had, which means three times as much as I was making since that company laid me off, so it seemed like a pretty big step in my then-new career. I hit the road in a used Ford Escort that I'd just bought for $900, and which barely survived the 800-mile trip. Stupid piece of junk.
Since then I've worked at a bunch of companies. Red Hat is the only one of those that I joined when it was already large. Of the ten startups (including the one in Michigan) none went to an IPO. One was the subject of a moderately successful acquisition (Conley by EMC). Four more were moderately successful for a while in some niche, and one of those is still going. The rest were either acquired at fire-sale prices or just sank without a trace (but only one while I was still on board). In other words, I did better than average. As much as we all like to dream about billion-dollar exits, the grim reality is that most startups fail suddenly and completely, leaving employees in the lurch.
It's a good thing there are plenty of other reasons to work at startups. You get to learn a lot that way, both technically and otherwise, in a short time. You'll almost certainly be given more responsibility and more freedom than you would at a larger company. You're more likely to work on cutting-edge technology (though not every large company is as far behind as some would have you believe). Startups provide a lot of opportunity in a very energizing environment.
Unfortunately, anything that's energizing in the short term is likely to become tiring in the long term, and that's what I'm here to write about today. While I'm not at a startup any more, that's how I got to where I am today. It's how I got to where I am in terms of being hired at Red Hat to start one project and then become an architect on another. It's also how I got to be kind of burned out, not just on my current job but on programming in general. 24 years is a long time - six bachelor's degrees, two of them entirely at specific companies. To explain how that feels, I'll start with a quote from The Hobbit.
Now it is a strange thing, but things that are good to have and days that are good to spend are soon told about, and not much to listen to; while things that are uncomfortable, palpitating, and even gruesome, may make a good tale, and take a good deal of telling anyway.
The funny thing about working on any project is that you forget all the good parts. Everything that was initially cool about what it did - and how - becomes so familiar that it's forgotten or taken for granted. Meanwhile, every architectural or design flaw you ever noticed still seems to be there. Bugs get fixed, but every troublesome module or interface is still troublesome. Every critical feature that was missing years ago is still missing, after being put off over and over again while other people's stupid ideas always jump to the head of the queue. After a while, you see nothing good and everything bad. It's an unfortunate quirk of human nature.
I must emphasize that this phenomenon isn't because of the code. It's a change in a person's relationship to code. I've worked on enough projects to know it's not just one, and I've talked to enough other developers to know it's not just me. Familiarity truly does breed contempt when it comes to code, and outsiders could be forgiven for thinking that "this code sucks" is the official motto of our profession. For what it's worth, I've also changed jobs enough times to know that's not necessarily the solution. Remember, I've done that ten times already. The grass isn't really greener, and the same problems tend to reappear everywhere. Eventually, disenchantment with one particular project becomes disenchantment with programming in general, or at least to programming within a particular domain. That's when the feeling of being trapped really sets in.
This steady deterioration doesn't just apply to code, either. Similar processes occur with respect to the social and organizational aspects of programming as well. I have a lot more to say about burnout in general (I even have a long post half written about it) but I'll leave that for another day. Today's post is about how I'm trying to fix it. Basically, I have three things I need to do.
Reduce my pace. When I was young, I thought I could sprint forever, but this is a marathon and nobody can sprint at that distance. Nobody. Also, the hills get larger.
Catch up on my personal life. Re-start my exercise program, de-clutter and fix stuff around the house, have lunch with friends, play with my daughter. All the stuff I've been too busy, or too tired, or too grumpy to do enough of.
Get some perspective. I need to re-familiarize myself with what else is out there in the computing world, not just as a matter of education and keeping up but also to remember what's good and cool about the project I'm on.
After the break, I'm not coming back full time. Like a recuperating patient, I'm not just going to dive right back in trying to do everything I did before. I'm going to take things a bit slower, at least for a while. Then again, it could be permanent. We'll see. The important thing is that I get to try, and I can't say that without acknowledging the role my bosses at Red Hat have played. They haven't just grudgingly or passively allowed me to do this. They have encouraged me, offered valuable suggestions, and agreed to terms far more favorable than I could have hoped for. Kudos to them, and to the company.
I don't know how many people can consider the sort of actions I'm taking, but I will say this: beware of burnout. It will creep up on you, no matter how immune you think you are when you're still early in your career. You can't ignore it. You can take positive steps to avoid it, or you can fall prey to it. Don't be one of those people who lose their family or their sanity first.