Life as a Software Engineer: Learning to Work With Ease

“When I think back to the times I was at ease as a programmer… those were some of the hardest-working times!”

Some years ago I worked in tech support. Back in those days it was pretty wild supporting those native binaries, typically written in C or C++ because they had the habit of crashing hard. You millenials may not be aware that, unlike modern languages that run in VMs, those libraries had full access to raw system memory and could easily bring down the whole server with a dreadful segmentation violation miles away from the root cause, leaving you pretty much without a clue.

Fueled by such complexity, a common sport among us support techs was to focus our criticism on the shortcomings of the code without sparing the developers associated with it. I definitely had times when I’d get frustrated. I mean, really frustrated.

It took me a while to understand that it was precisely those kinds of hard problems that pushed me to learn some pretty hard stuff. I’ve looked at Microsoft C++ runtime’s heap model in great depth and figured out the mechanics of how buffer overruns create security vulnerabilities. I figured out ways to reproduce sneaky multi-threaded race conditions using advanced debugger features and taught myself programming idioms to avoid those problems. There was just no other way to track down pesky production issues. And I got pretty good at it after a while.

Now that I look back at on that time, all I want to do is thank those developers whose sloppiness or temporary lapse of reason (or whatever it was) gave me the opportunity to learn all of this. It was a great experience. There’s still one nit though, one thing I regret when I look back at my early life as a software engineer. I wish I’d enjoyed it more.

There’s still one nit though, the one thing I regret when I look back at my early life as a software engineer. I wish I’d enjoyed it more.

That’s something I wonder today, too — am I still missing something? Is there a rule (preferably an algorithm) for living a better life as a software engineer?

Kent Beck, the creator of eXtreme Programming, TDD, and JUnit, gave a rather unusual talk called Ease at Work, in which he he talked about his life as a software engineer over the years and what he learned along the way. I was really interested to see it because I thought I might find clues for my own personal pursuit of happiness as a programmer, and I wasn’t disappointed.

I got some great takeaways. Read on!

What is working with ease, and what does it have to do with life as a software engineer?

Working with ease is like monads in functional programming: it’s hard to define, multi-faceted, invisible, yet undeniably real. It’s when we have the sense that “…it’s ok for me to be here, who I am, doing what I’m doing,” says Beck. It’s freedom from the worry, pain and agitation when “there’s so much to do that there’s no way I’m gonna get to all of it.” It’s a sense of trust in ourselves and in our co-workers. It’s that basic sense of calm that allows us to fully concentrate on our work and reach our fullest potential.

It strikes me that these things are impossible to achieve without good management. You feel at ease when you have reasonable deadlines, helpful resources, and a strong sense of direction. For that I have to be thankful — Conductor has its act together there.

But ultimately working with ease is about us: programmers. Over the years, we develop habits — ways in which we interact with our peers, how we perceive our work, etc., some of which are more conducive to ease at work than others. For example, Beck urges us to maintain trust: communicate realistic expectations to our managers and peers, be responsible — and we will be ok.

Beck talks of increased anxiety when he wasn’t prompt about communicating schedule slippages and other problems, and the ease he gained when became more open about it. From my personal experience, good developers tend to have this sort of forthcoming attitude. They are able to convey bad news and admit mistakes. It’s a trademark of a mature developer. Good call, Kent!

Good developers tend to have this sort of forthcoming attitude. They are able to convey bad news and admit mistakes. It’s a trademark of a mature developer.

Working with ease is about joy

We have plenty of fun stuff around here at Conductor: there’s Nerf guns, the Bieber-Buscemi (long story), and beer on tap, to name a few. These things make Conductor the quirky fun place to work that it is. (And it really is awesome.) Yet Beck says there’s something deeper than that — joy. He points out that, unlike fun, which is an ephemeral feeling, joy is a deep emotion — lasting and highly satisfying. Working with joy leads to increased productivity, better self-image, and of course — joy itself!

Finding joy is part of my journey as a programmer (in addition to having fun — d-uh!). And it can happen when you least expect it. Kent Beck says you can have a really serious, conflict-filled, intense discussion with someone and come out of it with a sense of joy even if it wasn’t fun. Seth, our CEO, would attest to that — when you join Conductor, you get a free copy of Fierce Conversations and your new hire package will encourage you to practice having them.

Kent Beck says you can have a really serious, conflict-filled intense discussion with someone and come out of it with a sense of joy even if it wasn’t fun.

A great way to find joy is to work in a place where you can be yourself. I used to work for a company that openly disliked agile methodologies, much to my chagrin. My manager at the time made a point of not allowing engineers to talk to prospective users, in an effort to remove “distractions.” All I was allowed to do was implement the feature according to the spec, he said. No talking to anyone outside engineering. It made me pretty unhappy.

So we weren’t going to get any official support for user feedback, but we found ways around it. My small team made friends with a couple of pre-sales folks and a professional services guy. We had frequent discussions and impromptu demos. Lots of great ideas came up. Waste was nipped in the bud, Lean style. Working alongside that small set of future users, we built something that we knew they would find useful. The product we ended up creating looked nothing like the initial spec (thankfully!). Still, it was a bittersweet victory knowing how much of our efforts went by unacknowledged.

Eventually I had to look elsewhere, and so I arrived at Conductor. It was quite a change. The first thing I did was take a company-sponsored TDD course (from one of Kent Beck’s former colleagues, no less). Did I mention testing was discouraged at my former job? Yeah — according to some math, the same amount of typing can give you more features if you write fewer tests. Let me repeat that: I’ve seen management actively discourage developers from writing tests!

But here I was at Conductor, where, after the refreshing nod to XP, I discovered that this is the kind of place where you’re not only allowed but encouraged to jump on a customer call and get familiar with your users. It’s a place where we frequently iterate and demo our work. We get regular feedback as a matter of course. It’s been energizing, refreshing, invigorating. Now that’s a joyful turn of events. The choice of workplace can make a big difference.

It’s been energizing, refreshing, invigorating. Now that’s a joyful turn of events. The choice of workplace can make a big difference.

Working with ease is about being easygoing

I mentioned earlier I used to get pretty frustrated with developers when I was a support engineer. Can you blame me? While they were sitting comfortably in their chairs writing code, I was spending late nights tracking down and fixing their bugs. They were messing things up and I was the hero who stepped up to clean up the mess. It was dramatic. I saved the world countless times. In my head.

Kent Beck remembers having similar attitudes in his younger days. His advice is to avoid wasting energy on unwarranted heroics. Programming so you can feel like a hero is a whole lot different than programming so you have a program, suggests Beck. Instead of spending energy on such antics, we can do much cooler things: like perform refactoring, write blog posts, and implement nifty new tools. Keep it light and cheerful. “Let’s have coffee,” suggests Beck. Somebody put that phrase on a bumper sticker.

Programming so you can feel like a hero is a whole lot different than programming so you have a program, suggests Beck.

Pick up the proverbial can

“What if you’re in the desert and see a tin can lying on the ground?” — says Beck, calling to mind those instances when we encounter someone else’s work written in a way we don’t approve of. We might say, maybe in frustration, or maybe out of sheer habit, “Who threw this tin can here with no respect for nature… [mumble grumble]…” Again I have this image of my younger self doing that tech support job. I’ve seen lots of proverbial tin cans scattered across source code over the years, and back then I was quite an environmentalist. What I didn’t realize was the negative effect that had on me.

Knowing that we like to make things better, Beck says it’s a perfectly natural expression of who we are to just pick up the can without any of the accompanying “drama.” In our proclivity to criticize others’ work, he contends, lies a tendency to be equally critical of our own selves. Being more forgiving of others, by contrast, will lead us to become more self-forgiving, which in turn unlocks capacity in us to take on more challenging work. Having empathy for the shortcomings of others makes us more open to learning from our own failures, helps us become better programmers. The next time you come across a tin can in the code, “Pick it up,” says Beck. No biggie. Just like that.

In our proclivity to criticize others’ work, he contends, lies a tendency to be equally critical of our own selves. Being more forgiving of others, by contrast, will lead us to become more self-forgiving, which in turn unlocks capacity in us to take on more challenging work.

On to more ease at work.

It’s been quite some time since I realized just how beneficial my experience as a support engineer was for my career, so a lot of what Kent Beck presented in Ease at Work was already familiar to me. I still found the talk very inspiring.

First and foremost, it’s an affirmation that another programmer (my longtime role model, no less) has been through similar experiences in his life as a software engineer and come to similar conclusions. Second, it’s great to take a break from our busy, high-pressure work involving mostly machines and their emotionless languages, and pause for a second to explore the humanity that’s present even in our mostly introverted and coy aspect as geeks. After reading all those tech books by Kent Beck, I’m happy to also relate to him in that he’s human and has human feelings.