High Pressure Delivery

When it came to becoming a software engineer, I fell in love with how intellectually stimulating and downright demanding it is on the brain. However, most of the time, the job is devoid of excitement. Sure there are those crazy bugs that come up a few times a year, but the day to day goes by at your resting heart rate. It's far from boring, but it's not exciting.

During college, and for a number of years after, I worked in food service. Back then, I often complained about how lacking these jobs are in creativity, leaving me intellectually starving at the end of my shift. However, I loved the speed of the experience. The intensity under which a team of servers, serving entirely different customers, would all flow together as one during an epic battle sequence between the diner and a warm meal. There was cursing, broken glassware, thrown chopped meat, cut fingers, oil stains and heavy drinking all coming together to form a work experience unlike any other.

At software development agencies, this type of pressure tends to return a few times a year under tight deadlines. The we can't delay one more week moments are real. At product companies, there are deadlines, but most are soft deadlines or best guesses. Agencies, tend to be under stricter scrutiny. The business to business relationship is far less forgiving than the human to human relationship between manager and employee. There is also the financial incentive to ship quicker, to get a client's project to value faster. In short, agencies that grow call their shots and make them.

This was a major driver behind me founding Cause of a Kind. I thrive in the pressure and intensity of a hard deadline and a problem to solve. It feels like all the pathways clear in my head and I can see the fastest path between nothing and something. As the CTO of Cause of a Kind, I don't get a ton of time in the weeds anymore, but last week I got the opportunity to feel the pressure again and it gave me a new perspective on the benefits of a hard deadline.

We had a web application set to launch in four weeks. The application had grown to have a meandering feature set, a braided stream of changes in direction and pivots that took place over the course of the last six months. The actual application that was needed was far less complex and with the latest round of feature changes the original code base was far from where we needed to be.

The shuddered thought to re-write it entered my brain, as it does most engineers when working with a legacy code base. As Joel Spolsky says, "software is easier to write than it is to read." I typically ignore these types of thoughts, re-writes are almost always a bad idea, but this software was untested on users. There was no pain or wisdom that comes from a large legacy codebase that's been with users for years.

Was it possible to re-write it in a week? I decided to spend one day testing the re-write. Depending upon how I felt after that day, I would decide if the re-write was possible in the time remaining.

The following day I stared off into the void, I was at the point of no return, if I continued now, I'd have to finish the re-written application, no matter the cost. I took the leap and continued building. I told my co-founder that I wouldn't be able to make any meetings this week, I had to go heads down and finish, but not to worry I wouldn't miss the deadline. I was committed.

This was also a unique deadline for us, we were traveling to visit the client to deliver the software in person. Showing up with something that was broken, incomplete, or with any bugs would be a horrific embarrassment. My leg bounced up and down like a sewing machine from the moment I sat down until I got up for lunch each day. I shut off slack, I shut off email, I shut off twitter, I shut off every possible distraction that kept me from my goal of delivery.

I was nervous for sure, and in these scenarios it's all to easy to get focused on failure. The what if I don't deliver. It's that voice that wants you to cut corners, to skip the tests, to skip the planning, to duplicate code with reckless abandon, to skip refactors and abstractions. Every minute you aren't writing production code feels like a minute wasted, but this is even more foolish when under deadline pressure. As the code base grows, you need to be able to increase speed with confidence. You can't do this if you have to manually run through every path in the UI with each new change. You need to be able to sprint to the finish line, to increase speed the way an Olympic runner thrusts themselves toward the finish line with ever increasing strides.

At last the day had come for our trip, and I still wasn't quite done. I coded on the plane (only possible because my tests run without a network connection wink), and with two hours left until our demo I stopped in Starbucks around the corner to put on the finishing touches. I could see the finish line now and those best practices were paying their dividends now as each feature came together like a game of chess you're destined to win.

I ran the build, I ran the deploy, everything was live and we were ready to go. My co-founder again looked at me and said, "what if there's a bug?"

"There won't be," I responded.

We arrived at the demo, pulled out a tablet as the business opened and we used the application in real time, with real users for the first time, bug free. But they didn't merely use it, they were in love with it! Seeing the joy on a client's face as they use an application that is going to alleviate months of painfully manual interactions is another glorious moment we don't get to experience often as engineers.

On the flight home I felt euphoric, that same feeling after a crazy New Years Eve service, when the last customer walks out the door and you've polished the last glass. You didn't just survive, you thrived. I could even hear the last song on the dining room playlist from all those years ago ringing in my ears, I've been looking so long at these pictures of you..., and the smell my shift beer coming off the tap, refreshment well earned.

I've often been told that our goal is to alleviate pressure on engineers. To leave them in quiet work spaces to toil calmly. However, I'm not finding that to be my way to reach flow state. Flow state happens for me when pressure forces me to clear my plate, to focus all my energy on a single purpose, a mission, a goal. The nervous energy of a tight deadline distills my thinking to only the essentials, from which I discover my best work. Now the question is, how do we find that optimal amount of pressure and train ourselves to thrive in it?