Restoring the Spark
How often have you left work exhausted. Gone home and said (or at least thought) “I don’t want to think about that project for the rest of the night. I want to think about anything else BUT that project”? Once in your career? Once a year? Month? Week? Every night? I have had my share of those projects. You go home completely drained from your day. Sometimes you even look back at your day and ask yourself “What did I even do today?” Unsure that you actually accomplished anything at all.
On those occasions, when I wake up, I often hear a version of the Toy’s R Us song. The original is:
I don’t wanna grow up I’m a Toys R Us kid,
they’ve got a million toys at Toy’s R Us that I can play with.
I don’t wanna grow up I’m a Toys r Us kid,
they got the best for so much less, you’ll really flip your lid.
From bikes to trains to video games, it’s the biggest toy store there is, (Gee Whiz)
I don’t wanna grow up cuz’ maybe if I did?
I wouldn’t be a Toys R Us kid.
(More games, more toys, Oh Boy!)
I wanna be a Toys r us kid!
My version is simply “I don’t wanna get up cuz’ maybe if I did? I’d have to write code again.”
But here’s the thing, I enjoy writing code. There are times that I might be disgruntled or even miserable, but I can’t imagine doing anything else for my career. When I’m home I often will write little apps, not to land a new job, or help work out at all, but because it’s fun. I try to teach myself new techniques and new languages, again because it’s fun. If you’re reading this, chances are you are probably a lot like me.
Over my career, I’ve thought about what causes those points in time where I head home grouchy. I don’t want to think about work. I want to do anything BUT go into work in the morning. Here are some of the things I thought caused or contributed to my general grumpiness:
- Project isn’t challenging
- Rude coworkers
- Not being valued by my company
- Management doesn’t understand development
- Too many meetings
- Can’t figure out that stupid bug
I’m sure that each of those can contribute to low job satisfaction. But lately I’ve noticed something else. Each of those things listed above are framed in a negative light. In order to increase job satisfaction, I’d have to eliminate negative things, a lot of which I can’t control. In fact of the 6 items above, only 1 of them is anything that I can really control, figuring out the “stupid bug” is something that I can work towards. None of the rest have much that I can actually do anything with.
So let’s re-frame the list above. Instead of focusing on the list of things that can suck about a job, let’s look at what makes a job fun. As I said above, I can’t imagine doing any other profession besides software engineer. So in order to have increased job satisfaction, I need to focus on writing more code.
That’s exactly what I realized on my current project. Without going in to details, there is not much that is technically challenging. It’s also not in a brand-new, untapped or difficult domain. But I’m enjoying it immensely. The main difference that I’m noticing is that I’m doing TDD on this project. And something specific I’m trying is to leave each night with a broken test.
Why does this work? When I do TDD I’m writing new code every minute or so. More than that, I see progress every day. Every time I write a test and watch it go from red to green I see another “notch” of something I accomplished. I can still leave work at the end of the day not completing a feature, but I know that I’m 12 tests in to the feature. Or I know that the data access for the feature is done. Not only done, but also tested.
And the leaving work with a broken test? That makes me not want to leave. It makes me think about logging in at home and working more. It makes me want to get to work in the morning and write more code. Why? I think it’s the fact that I’ve left unfinished business. It doesn’t gnaw at me. It doesn’t drive me crazy. But it reminds me that there’s still work to be done. Not only that, but by leaving a broken test at night, I know exactly where to start in the morning. It takes less time to ramp up. I open up my IDE, see the failing test and set about writing the code to make it pass.
There’s two things at play here. First, I’m focusing on the things that I can control. That in and of itself helps increase satisfaction. Secondly, I’m doing it in a way that highlights progress. I don’t have to leave work asking “What did I do today?” Instead, I know what I did. I have tests that show what I did.
Those two things can help bring the spark back in a stale development relationship.