Matthew Jordan
| Programming, Running, and ThingsMy first job out of college was as a systems engineer, doing software implementations for large public safety projects. It was a great first job. I mean that sincerely: it was a lot of fun. I travelled all over the country, some places illustrious (what, you mean I have to spend one week a month in Laguna Beach for a year?); some not (why hello there Central Texas. 100 degrees + 100% humidity? Sure!). I learned a lot from the experience. I think everyone who aspires to be a software engineer benefits from seeing their software used. As an implementation monkey, I often yearned to drag the software engineers responsible for the buggy piece of shit I was attempting to deploy out of their comfy air conditioned offices to my not as comfy (yet still air conditioned) server room to show them just how often their buggy piece of shit crashed. I later got lucky enough to write my own buggy pieces of shit, at which point, my dreams of berating those who were - quite frankly - far better than me - diminished by a large measure.
Nothing tempers enthusiasm like experience.
I worked a lot. A lot. A compatriot of mine and I once decided to see how many 100+ hours weeks we could work in a row before collapsing in something like dementia. I think I hit 3 (I’m pretty sure he hit 4; I was the weak one). I wrote a lot of really bad software during this time as well, mostly in hotel rooms and on planes. I’d like to believe that sleeplessness had nothing to do with this, but I’m probably whitewashing history. One piece of software I am both equally proud of and embarrassed of was written predominately on two plane trips between Orange County and Atlanta (one of which was a red-eye); it coordinated dispatches between all the fire departments in Orange County. Hilarity ensued when I accidentally cleared every single fire engine in the entire county off their calls.
Oh, I’m sorry, were you going to that structure fire? Not any more!
Whoops. (As an aside, there’s some incredibly professional people working in your dispatch centre. Thankfully, they are used to morons like me writing buggy software that their county chooses to buy based on who has the lowest bid. If you meet a dispatcher, thank them. They’re nice people. Fire fighters, for the most part, (and I’m making a gender based stereotype here, but I have to go with my experience and the sheer lack of many female fire fighters that I personally met), are frat boys who never grew up. They just find it fun to drive large trucks down interstates at breakneck speeds. Getting to U-Turn the sucker twice in one day is just good fun.)
The value of test driven development was something I learned that day.
These are all anecdotes to say that I worked too much. I knew I had a problem when the stress of my demanding contracts got to the point that I couldn’t sleep at night. I’d wake up every hour, dreading tomorrow’s e-mails from customers angry that I hadn’t provided the software they wanted. Every day was this existential horror of working until 2 AM, sleeping in 30 minute batches with periodic, hallucinatory jolts of “wakefulness”, only to know that by 6 AM, my work would be insufficient to stave off the devouring beast that were “my customers”.
We were spread a little thin. Not surprising, I was getting pretty burned out.
You may think that my overworking was proof that there was something wrong with management. In retrospect… nope, still don’t think so. They actually told me - quite often - to stop working. To go on vacation. To close the damn laptop. For the most part, I ignored them. I just figured, “this is what you do”. I had a problem: I hadn’t yet learned how to say “no”. I liked being “the hero”. Even now, I like a good amount of pressure. There is, of course, a balance, and unfortunately, I hadn’t yet learned that heroes, often as not, get eaten by the dragons they’re attempting to slay.
Naivety is fun.
My vice president at the time was Alice. She’s amazing, and I still have the utmost respect for her. She’s a legend for showing up at the office before everyone else and going home long after everyone else had turned off the lights. She’s a machine; she always knew every customer, what they wanted, what they didn’t really need, who was good at doing what, who to trust, who not to trust. She had the “pulse” of the company, and she knew how to keep the machine moving. Those of us who were lucky to get to know her wanted to be as big of a bad-ass as she was.
I remember hearing some advice she gave someone else some time, who asked - with some incredulity - how she managed to do all that she did while still maintaining healthy relationships and an active personal life. To paraphrase:
Figure out what you need to be sane. Figure out what you need to be happy. When you know what it is, set that aside. And don’t violate it.
It’s no secret that I love Agile development. A lot of people associate a maintainable, predictable velocity with Agile development - which, while not part of the manifesto - kind of goes hand in hand with that whole “valuing of individuals” statement. Having a predictable development velocity means you do not do high burns on anything approximating a regular basis. 50 hour weeks is not cool. 100+ hour weeks are so far out of bounds the stadium that would be our analogy of “yeah, this is acceptable” is probably in another galaxy. Doing work that exceeds your normal average limit means that there is something wrong. If you can’t maintain a particular velocity, then you can’t predict what you can and cannot do.
As human workers, we’ve gravitated towards 40 hour weeks. I suspect (but am too lazy to look up) that there is a large body of research that says that 8 hours is the most we can expect out of someone in any given day, and giving someone 2 days out of a week as a break is a good idea. I’m sure that works for most people. Others can do more; others can do less. (Personally, I think most people would benefit from a 4 day/9 hour schedule, but that’s just me. I’d take a 10% hit on salary if it meant a 3 day weekend; then again, I’m pretty blessed to have a wife that works and no kids. Your mileage may vary.) Myself, I tend to lean towards the “more” side of that scale, but that’s just a personal preference.
The point is: find a work/life balance. Find what works for you. If 40 hours a week is the magic point, then do that. And don’t exceed it.
If it’s more: that’s fine too. For me, I find myself at about 10 hours a day with a smattering here and there on the weekend. Again: I’m lucky; I have an understanding wife and a dog. People with kids have other priorities, and that’s understandable.
The past month, I’d say I was in a “high burn” situation. I worked a lot, especially on the weekends. I’m not sure I was hitting that magic 100 hour week, but I was certainly close (ew). At the same time, I do recognize that I pay for these situations. After these high burns, I’m tired, I’m cranky, and I’m pretty sure I care a lot less about whatever software I was writing. That’s not good: I like to care about what I’m doing. Work is important to me - what I do, what I build, is part of my identity. I find that my life is better that way; devaluing that is no bueno.
At the same time, sometimes, you look at the schedule, look at your list of desired features, close your eyes, hit the afterburners, and pray.
All of this is a long way of saying that I’ve had Alice’s advice in the back of my head this week, chiding me for violating that piece of sanity that I carve out for myself. I’ve already carved it back into my life, which is a good thing. I think there’s a limited number of times you can do high burn situations, and the period of time that you can devote to such a burn decreases as you get older. Witness the start-ups founded by today’s young “hot” entrepreneurs. It’s not surprising that by the time they’re 35, they aren’t doing what they did when they were 25. And that’s not a bad thing.
They probably carved out their piece of happiness as well. At least, I hope they have.
Otherwise, what the hell is the point of all this?