I was catching up with a longtime colleague and friend at one of my favorite cafes in San Francisco the other day.
I'm always a bit amazed at how some things never change. Much of the conversation was around the same old shit. Non-competes and non-solicitation clauses (he's looking at leaving his current gig)... lawyer perspectives (both sides) on the declarations, etc. "What if we both quit at the exact same time?" How many times has that statement/question been uttered? Anyway, we got to important stuff like code.
He made a statement that I think I'm sure we've all heard a thousand times, but it hit me just right this time and I've been sitting with it for a few days now.
"It's not the code we write, it's the decisions around _which_ code to write."
It was a statement about experienced software development, and increasing the odds of success on a project. It was a statement around stepping back and trying to understand the forrest from the trees before you make one of the biggest financial investments out there; writing code.
The battle is not in getting the code written (great programming is assumed and table stakes). The battle is in ensuring you're writing code that is going to best fit the anticipated usage patterns. If you have good vision into the latter, the former is simply brick-laying.
If I look at software developers (myself included) I've employed over my career, and their pay (equity, cash, reward of having most impact on a project, whatever...), there is a direct correlation between pay and ability to make good decisions around which code to write. There is little correlation between how clean or sexy the code itself is, and pay. There is untold value in making the right decisions about which code to write.
Making the right calls around which code to write can make or break a company or project. You might be able to build something quickly and get it to market, but then if you're successful, you might not be able to get it to scale, your customers might become frustrated and leave before you can resolve the scale challenges.
Of course the inverse is an issue as well. You could spend all your energy getting something to scale early, but then you never capture customers.
Then there's the grand-daddy challenge of them all. In reality, there is no way you can ever anticipate the actual usage patterns of your software. You have no way to predict things like traffic flow and load and usage. You can try (and you should... and indeed try hard), but you'll never get it spot on.
In the end, you have to enter a project knowing you'll never know exactly how the software that gets written is going to operate at scale. You have to enter a project knowing that if you succeed at points along the way, you have to be prepared to tear out versions of the software that got written, in favor of new versions of it that better accommodate the changes in use (e.g. more users, a new feature, whatever). You have to enter a project knowing that if you succeed, change is good, it is right, and it is ok.
Unfortunately of course, writing software costs a lot of money. You have to understand this though, and know that you're going to always be spending money on the evolution of your software. Unless you have a perfectly closed system, your software's needs are going to change, and in turn, it is going to have to change.
After churning on this with my friend and over the past few days, I realized the great software developers I've been lucky enough to work with over time, understand all of this. They know not to bother even thinking about the code they should write, until things like "what's expected load going to look like?" or "let's model cache hit rates first" are explored. They lead with contextual understanding questions and exploration, long before a single line of code ever gets laid down. The actual exercise of writing the code that will make tons of money in production, is almost an afterthought. Of course that will get written and written well, the challenge is in understanding which code to write.
So, next time you're exploring a software challenge and you ask "how do I solve this?" make sure your answer leads with exploratory questions around the challenge itself, and don't bother diving into the "how" until you've done that.
This is one of the biggest challenges in one's software development career. You want to dive right in and start writing code on the solution itself, not explore all the edges around it. However, if you want to be intensely valuable at writing software, you're going to have to find the patience to explore first. Find answers to the questions no-one else around the table has. In those answers are guideposts along the path to successful software.
