Once upon a time, I met an engineer, let’s call him Joe.
We met during my onsite interview day at a famous Berlin startup hub. Joe was friendly, and as I was soon about to find out, an excellent programmer.
He would lead our backend development side and offer his expertise on various low-level and high-level decisions regarding architecture, design patterns, etc.
The environment we were working in was execution-focused and delivery-oriented. We didn’t need to find the ultimate solution; we needed to ship on time.
A few weeks later, I began noticing Joe struggling. Our tech lead was asking him to finish something within a specific deadline, and he was struggling to conclude his work within the time he had.
He would stare at the screen for a long time, sighing and thinking, unable to decide what would be the optimal approach to structuring his code.
When I tried to get an answer from Joe on a specific topic, he would analyze points of view and try to approach it from several angles… but he couldn’t manage to clearly articulate his answer.
Joe could accurately talk about all the programming patterns presented in the Gang of Four book. From a fundamentals point of view, he had more knowledge than I did.
But I would deliver at three times the rate he did.
Our paths diverged, and I saw him stumble from job to job, surviving only a few months in each position he held.
Joe was a classic example of an “academic.” He was aware of the context in which he was operating, but he couldn’t adapt his working style. What mattered to Joe was the “ultimate optimal solution,” not the “high” of delivery and shipping.
Was Joe the ideal team member for some kind of team? Definitely. But I tend to believe these teams are the minority out there: research, academia, teams that have an infinite amount of time to solve a particular problem (so, research!).
Software engineering for product companies is the art of combining technical skills and problem-solving with the ultimate goal of delivering value-adding products that improve people’s lives one way or another, with the exception of some very particular industries.
In most cases, shipping a “good enough” solution on time is better than delivering the “perfect” solution late or not at all.
Could Joe have been coached to become a better delivery-focused engineer? Possibly. But I believe that the core of his personality and working style would have made it very difficult for him to adapt to such a mindset.
Maybe Joe would be a useful addition to a team of highly technical engineers working on a complex problem that requires deep thinking and analysis. But for most product development teams, Joe would be a liability.