Rubies in the Rough

When Passion Goes Wrong

I usually stick to pretty code heavy topics in these articles, but please allow me to take a detour this time. Our industry struggles with a problem that we don't discuss enough and I want to give it some air time.

The fact is, we're pretty lousy at controlling stress.

Let's look at why that is and some of the ways this problem manifests. Remember, the first step is admitting that we have a problem.

We are a Passionate People

I really believe good programmers are passionate about what we do. Our job can be pretty mentally taxing and, if you don't love it, it would be pretty rough to endure that day in and day out.

Because of that, we generally find that the programmers who survive the climb are passionate folks. Really think about that for a minute. I'll give some examples.

Kent Beck is a name I bet most of us know. One of his great successes was actually writing a book of guidelines for how individual lines of code should be structured. He had to care about the individual lines. That's how far he had to go to manage his programming. He's also done a ton for testing, for similar reasons.

I'm also pretty sure we all know that David Heinemeier Hansson put Ruby on the map when he created Rails. If you've ever seen DHH talk, you know he's a passionate guy. He was passionate about improving the standard cycle of Web development at that time. He also held himself to some surprisingly rigid standards, like his need to keep the code as DRY (Don't Repeat Yourself) as possible, that led to some of the key breakthroughs at the heart of Rails.

Of course, passion doesn't always require this laser focus. Take Aaron Patterson. He contributes both to the development of Ruby and Rails, but his passion comes out as a wacky fun side that has little to do with code. He wears goofy costumes, makes hilarious videos set to silly music, takes regular pictures of himself giving out hugs to the entire Internet, and more. That's just how Aaron copes.

Obviously, passion, in some form, is important. We need it. It helps us do the challenging stuff. I'm for us being passionate. We want to keep that.

But what are the costs for us being this way?

Confusing Passion With Stress

There's absolutely a dark side to all of this passion that we have.

Like most things, I believe it starts out innocently with no one really intending any harm. Things just spiral out from these first steps until we are confused about what's important to us.

He's an example of one of those humble beginnings: "Joe Coder loves slinging code, so I'm sure I can ask him to stay late a bit this week. That will allow us to get a few more features into the big release."

When you use someone's passion like this, you flip if from a positive asset to a painful disadvantage. This may work for a while and, if it's infrequent, it may be hard to see the price you are paying. But there's definitely a price and you shouldn't ever want to pay it.

Imagine these two different scenarios. First, let's say there's a big push looming and your lead developer is struggling to keep up. As a manager, you could come to the developer at 4 PM and say, "Not quite finished yet? Any chance you could stay a little late tonight and wrap this feature up?"

For the second scenario, let's assume the same pressing deadline. This time though, the manager comes in right around 5 PM and says, "You still hammering away at this? Go home. Have some fun with your wife and kids. Come back refreshed tomorrow and you can wrap this up then."

The question is, who gets better and faster results?

Many studies have shown the value of things like rest. Telling ourselves we can function at the same levels without it is just wishful thinking.

Even if our limits weren't fact, we wouldn't want to live like that.

Our Best Intentions

Sometimes our passion even manufactures more stress. A lot of us like to help out on open source projects, for example. That's great and noble, but it can become challenging over time.

Things like bug reports and feature requests can be extra stress sent to you on someone else's schedule. That's not comfortable to very many people.

I'm not saying we should give these things up. I love open source and I don't ever want to live without it. I contribute when I can and I encourage all of you to do the same.

We do need to remember to always keep these efforts in the highest respect though. Don't get too heated when it takes someone else time to address your concerns.

Similarly, we have to filter the things people tell us through the lens of reality. I know I have personally said things like, "New programmers need to be eating and sleeping code." I did not mean to imply that they should be programming around the clock. I just meant that their stage of development is better passed through by writing code than reading our books or other similar tasks. Don't let others push you into this stress framework. Especially not me.

Death to Death Marches

I'm interested in this topic because I've seen enough of it to pass judgement now.

On one software project, I literally watched the lead developer's physical health tank as the project managers pushed harder and harder. He began to have bizarre episodes where various systems of his body would fail in a sometimes drastic manner. The doctors struggled to explain these episodes, because there didn't seem to be an underlying cause. Want to know the really sad part? If you overlaid these episodes on the project's release calendar it was an almost perfect match.

Another project I worked on seemed to operate under the assumption that if our hair wasn't on fire, we were doing it wrong. It was an end to end death march. They would give us some assignment and explain the critical timing of getting it in. We would negotiate a reasonable feature set for that time frame, then set to work. Then something else, even more critical, would come up or management would decide our progress showed we weren't going to make it. They probably cancelled around 50% of what we were working on before we could ship it. That's powerfully demoralizing and it threw one of the cheeriest developers I've ever met into a depression.

Hopefully it's more obvious that we've crossed a line at this level. That should make it easier to avoid.

I do vote that we treat this as a hard line in the sand that can't be crossed. You know the saying about counter-offers? "Good companies don't offer them and smart employees don't take them." We need to apply the same no-tolerance policy to death marches.

Is it Really the End of the World?

It's worth noting that we're not just talking about work schedules here either. This passion gone wrong infects many aspects of our industry. One area I see it a lot is thinking that any problem is the end of the world.

It's almost always not the end. Really.

Let's talk about Amazon.com. They're huge. Now their architecture is constructed to make full outages extremely unlikely, but let's say their luck goes sour and they really do go all the way down. Maybe they are down for a day. Users cannot make orders. For a whole day.

Does this matter? Would it hurt them?

I seriously doubt it. In fact, I suspect their orders would be artificially high the moment the came back up as the outage urges some users to get their needs seen to when they can. That's what happens anytime the Apple store is offline for 30 seconds, right?

Furthermore, Amazon.com is going to spin it great. That's what they do. They're going to apologize, go to great lengths to tell us what went wrong, and assure us that they've greatly reduced the danger of it happening again. They've done exactly that in the past. It gets them positive press.

If Amazon.com tanking isn't the end of the world, it's just not likely much else is either. Sure, there are some mission critical systems, but those are just super rare exceptions.

One day, while I was at lunch with my wife and a friend, one of my clients called in a dead panic. He was sorry to disturb me, but this was a true emergency. He explained the problem in painful detail and I calmly reassured him that I would handle it.

I'm so glad this call happened when it did, because I got to see how truly absurd we are through the eyes of another. You could tell by the look on my friend's face, who only heard the gentle reassuring side of my conversation, that she expected me to leap into immediate action. I seriously doubt she would have been surprised if I had stolen a nearby laptop, fought my way to a power plug, and started frantically coding. I'm pretty sure she thought lives were on the line.

When I calmly put the phone down, apologized for the interruption, and went back to eating and chatting, the friend had to ask me if I needed to go. I told her not to worry, everything was fine.

Was it really fine?

Yep. I had done some quick and dirty estimation while on the call. The problem was in the order system of a moderate traffic site. That's the worst it can get right? I mean credit cards were involved. The fact is, assuming the worst possible scenario, I figured there could be 20 messed up orders by the time I made it back from lunch. The client has also told me they had stopped filling orders until this was sorted out. So the worst case scenario was that we might need to revert some charges and send some apology emails. Maybe 20 of them. That was the quick and dirty assessment that kept me from panicking.

The reality was even better. There was an issue with the order system. It was an extreme edge case that only one user had managed to trigger with some pretty odd behavior. That's the order the client found. No other orders had been affected. Oh and that type of order required approval, so it hadn't gone far enough in the process to even be charged yet. The safeguards we had in place were doing their job perfectly. Count of abused credit cards: 0.

I'm very glad I didn't ruin my lunch over that.

There are so few problems in the world that cannot wait until Monday morning. Assume yours isn't one of them. It's a superior position to play from.

Show me the Money

Speaking of credit cards and money… well, let's talk about that too. I had a conversation last week that went something like this:

Startup employee: "Our lead developer quit this week."

Me: "Sorry to hear that. They weren't happy with the job?"

Startup employee: "They just ran out of runway. Their wife lost their job, so they couldn't hold out any longer."

This type of thinking is so alien to me that it took me a while to realize what was even being said. That programmer was apparently working for little or no money, and promises of future equity, in order to help get this idea off the ground. Circumstances changed and he couldn't keep doing that.

Of course, I've known multiple people who do this. They are odd to converse with, if you ask me.

Me: "You're not getting paid for this?"

Typical answers: "We're changing the world;" "they've created an amazing culture to work in;" etc.

Uh, no. All definitions of "an amazing culture to work in" begin with, "Here, let me pay you for your work." I promise. Oh and those people who end up changing the world are usually paid for doing so. Sometimes a lot.

If you are about to object with Steve Jobs, Twitter, Facebook, or some other amazing startup case, just stop. Put the keyboard down. Yes, there are some stories of businesses happening like that, but you don't want to actually aim to be like them. The odds are horrible. Go to a casino and bet everything you have on one lucky turn of the wheel. The odds are better. If you are going to "start up" a business, why would you aim for the bad odds? You want to learn the rules and play the game right like everyone else does, gradually building something that works.

Get paid for what you do, please.

An Amazing Culture to Work In

The startup folks have nailed one thing: we can build the culture we want to work in. We have the power to make it whatever we want. Managers can shape the environment by how they run things and programmers need to start politely but firmly rejecting unacceptable conditions.

Here are some modest suggestions for what I would like to see:

• Get paid for your work
• Quit working around 5 PM
• Take lunch breaks
• Don't work weekends
• No death marches, ever
• Remember that our current problems are not the end of the world and behave accordingly

Don't get me wrong though. I'm keeping the passion. Very few people love to program like I do and I'm not giving that up. I've got more than my fair share of the "Go Big or Go Home" attitude. When it's time to code, bring your A Game and give it your all.

I'm just recommending that we remember to properly delineate and respect when those times really are.