Summary
- Focused on the Metagame of software engineering
- The software development industry, as a System, is designed to foster technologists; people more focused on the tool than on the problem the tool solves.
- Technologist are:
- Startups use new technology because of their immaturity rather than despite it. Playing with new
- “The only guaranteed benefit they can offer their engineers is the freedom to invent their own challenges, and learn through iterative failure.”
Notes
I learned two lessons from this time in my life. The first was personal: I am, at heart, a technologist. I like to generalize, to abstract. While I believe it’s crucial to understand the context around your software, I’m happiest when that context is other people’s software.
The second lesson was broader, and less obvious: our industry is designed to foster people like me.
This was surprising because it seems so clearly against our own interest. In almost every case, companies fail because they build the wrong thing. Unless your customers are themselves engineers, I’m the wrong person to help with that. You want someone comfortable at the periphery of your system, who wants to learn about the competitive landscape, who wants to talk to customers. You want a product engineer.
But consider our standard interview questions: data structures, recursion, and computational complexity. It always feels a little strange when I see someone arguing that these don’t reflect “real” day-to-day software tasks; I write recursive functions all the time. But that’s a consequence of the abstraction; what might be a simple nested lookup on any specific datatype becomes recursion when you try to generalize over a set of possible datatypes.
Likewise, I’ve seen it argued that the difference between, say, O(log N) and O(N) isn’t important, because in practice N tends to be small enough. That may be true for some domains, maybe even most of them, but if you’re building a general-purpose tool you have to focus on the pathological cases.
[…]
But if we want to hire product engineers, what questions should we ask instead? It’s impractical, given the sprawling scope of our industry, to only consider candidates with prior experience in our exact product space. Likewise, it’s unrealistic to expect that we’d have expertise in a candidate’s prior product spaces. We lack a common vocabulary, a common understanding of the nuances that separate good design choices from middling ones.
And so we continue to search for our keys under the streetlamp; they could be anywhere, but this is where the light is. If we’re lucky, the technologists we hire will also have all the other skills necessary to make humane, useful software.
This means that even if you’re not a technologist, you have to learn how to pretend. [Be what they expect you to be]
[…]
As many have pointed out, this is not a rational strategy for building a company. It is, however, a phenomenal way to train new technologists. Chesterton notwithstanding, the fastest way to learn why a fence exists is to tear it down and see what happens.
Seen from this perspective, it doesn’t seem so irrational; most startups fail before reaching a scale that has any existential technical risks. The only guaranteed benefit they can offer their engineers is the freedom to invent their own challenges, and learn through iterative failure. If the startup fails, there’s no harm done. If the startup gets traction, the engineers can apply their newfound wisdom.
This means startups don’t adopt new technologies despite their immaturity, they adopt them because of that immaturity. This drives a constant churn of novelty and obsolescence, which amplifies the importance of a technologist’s skillset, which drives startups to adopt new technologies.
[…]
By introducing abstraction into every problem we solve, we distance ourselves from how our work is ultimately used. We tell ourselves we’re in the business of building sharp knives; if we made them safer, they’d be useless for everything except spreading butter. We float above the the effects of what we’ve created, treating them as inexorable consequences of progress.