How Shipping Software Teaches You to Make Tough Choices

Several years ago, I had a job that seemed like heaven. We were a new team building a new product. We were using new technology: C# 2.0 (yes, people were once excited about major releases of C#). We were using new techniques, like scrum and test-driven development. It was greenfield development in every possible sense, except for the one where our desks would actually be situated in a green field.

I lived in this environment for a few years. I learned a lot about software development, technical leadership, and how to build big systems. Ultimately, though, I think I wasted those years. Why?  We never shipped.

Something magical happens when you ship software: your decisions suddenly have consequences. You suddenly must consider trade-offs. Hopefully, people suddenly care. If they don't, you suddenly must correct that.

What's the big deal about decisions and consequences? Any fool with a text editor can write code, but only an amazing few can code and make good choices around trade-offs. That's the most valuable skill a developer can possess: the ability to make hard decisions. (That's actually a great way to make career choices: opt for the place that'll let you make harder decisions.) Like riding a bike or juggling chainsaws, the only way to get good at making hard decisions is by doing it a lot.  Each time you make one of these decisions, gather data and iterate accordingly.

When I was working on that project that never shipped, I felt like I was making hard decisions. We had big meetings and loud arguments about things that seemed important at the time. You can bet your sweet bippy that we came to conclusions on all sorts of things. However, since we never shipped, we never got any data about any of the choices we made around things like architecture, code coverage, implementation decisions, featureset, and user interface. Without that data, we had no way of knowing if we had chosen correctly. Did we get better at making hard decisions?  Without users, how could you tell?

There was an easy solution to the problem I faced at that job: ship the dang thing. That decision wasn't up to me, so I should've done the next best thing: join a different team, one that shipped a ton of code. Even if the codebase is worse and the product is less interesting, find a role where you ship; it's the only way you get better.