The fabled grand slam project

When I was in college and for the first too-many years of my career, I imagined that professional programming worked a little like this:

• Your boss tells you to write a service or feature that does X
• You work really hard and make something that does X well
• Your work makes the world better and you’re rewarded for it

This was stupid. This is not at all how software engineering works.

“Obviously useful”, grand slam projects like this are rare enough that most of them have already been finished. If your boss was so sure that this project was one of them, it probably would have been done long ago.

Software engineering, unlike food service, law, nursing, or dry cleaning is not a service industry. In each of these industries, the utility your work provides to the world has some rough correlation to the effort you expend. A great nurse or lawyer will certainly have a much higher coefficient for how much utility they create per unit of their time. However, the two are usually still correlated and there’s a cap as to how much utility they can provide with their time.

Contrastingly, software is a product-driven business: you can work really hard on a product, but if no one uses it, then - pardon the French - you’ve wasted a shit load of your time.

To exacerbate this, software has a high upfront cost to write but often has almost no marginal cost to add a customer. This means that, unless you’re careful, there will be huge sunk costs by the time you realize something isn’t useful.

The obvious upside to this model is that if you can actually write software that’s useful, it can provide a terrific amount of utility to the world.

My advice to my younger self: you may be handed projects, but the project specifications will be wrong in 50 ways that no one knows yet. This is not your boss’s fault: the hard part of software isn’t writing the code, it’s figuring out what the software should do in the first place. Knowing how to write the code is just table stakes for the real job.

As soon as you acquire those basic engineering skills, start focusing on understanding how to validate your product ideas, work closely with customers to refine them, and get buy in from others to work on them. This is a completely different and frankly much more valuable and difficult skillset than software engineering. Find and study the experts in the field like Paul Graham, YC Startup School, Eric Ries, and Peter Thiel. The whole field is as much black magic as it is engineering, but there are still very real principles to be learned.

Past a certain point, these skills are as useful at a large company as they are at a startup. You can receive a few promotions at a large company just by doing the right engineer-y things that look right, but at some point you’ll be expected to create something that matters and no one really cares how hard you worked on it if it doesn’t provide utility.