What Sets Developers Apart at Different Career Stages?
Putting my engineering manager hat on
In this substack I haven't yet written about anything related to my job and industry; however, when inspiration strikes you just don’t say no. In this essay, I delve into the multidimensional landscape that dictates these decisions, using my expertise in software engineering as a lens. While my focus is industry-specific, the concepts I explore have wide-ranging implications for expertise across different fields. Intrigued? Let's dive in.
If you're in tech management, you've likely wrestled with how to best slot candidates into roles—regular, senior, or staff engineer (if your org doesn't use that title—think a senior engineer on steroids) —and whether the added experience is worth the added expense. The industry teems with both young prodigies and seasoned disappointments. So, experience alone can't be your guiding star; for a cautionary tale, consider how promotions work in Japan's Keiretsu system.
The Paradox of Skills, Aging, and Priorities
Here's something to mull over: reaching job proficiency in software development can happen faster than you'd assume. Couple that with the tech world's incessant change, forcing you to reskill every few years, and it raises questions about the value of long-term experience.
The cognitive angle complicates things further. For example, my 25-year-old self could code much more efficiently than I can now at 38. But it's not just about cognitive decline. As life progresses, new responsibilities pile up—maybe you've got kids, a mortgage, or aging parents. These aren't distractions; they're shifts in what matters most, making the marathon coding sessions and work-centric life of my younger years less viable.
Given all these factors, one could assume that seniority is overrated in software development. But as any experienced manager will tell you, this is definitely not the case.
The Illusion of Consensus
On the surface, you might think technical debates are straightforward duels between good ideas and bad ones. You'd expect great engineers to side with the good ideas, making companies that hire top talent hotbeds for excellent decision-making. My time at Google, known for its rigorous hiring process, offered a reality check. Although Google's system isn't flawless, it's effective enough to ensure that the overall quality of engineers is very high. Given that, you'd think there would be broad agreement on best practices, perhaps only quibbling over the sequence of implementation.
However, that was far from my experience. Conversations at Google were fierce, sometimes verging on religious wars. Engineers typically fell into one of two camps: progressives, eager to adopt new technologies, and conservatives, who favored established, time-tested solutions. As a young engineer, I was decidedly in the progressive camp, often feeling like my senior colleagues were dedicated to shooting down my innovative ideas. Yet, as years passed, I found myself adopting a more conservative stance. As much as my younger self would hate that – this was a sign of me actually making progress.
Two Axes, Not One
In the realm of software development, ideas can be plotted along two axes: their actual merit (good or bad) and their perceived merit (seem good or seem bad). While it's easy to gravitate toward ideas that are good and seem good, and equally simple to avoid ones that are bad and seem bad, it's the other quadrants that pose challenges and opportunities.
Regular and even senior developers often find it straightforward to deal with ideas that fall in the 'good and seem good' or 'bad and seem bad' quadrants; these are the no-brainers that reasonable people can quickly agree upon. However, true expertise manifests in navigating the murkier waters of ideas that seem good but are bad, and those that seem bad but are good.
A senior engineer has often been burned enough by the alluring but flawed 'seem good, are bad' ideas to approach them with caution. Learning to differentiate between glitter and gold in this quadrant is not a matter of intelligence but one of experience and, often, painful lessons.
Staff engineers take this discernment a step further. They not only have the experience to separate the wheat from the chaff but also the persuasive skills to champion ideas in the 'seem bad, are good' quadrant. These are the risky propositions that might appear counterintuitive but are actually brilliant. It takes both technical insight and the ability to communicate persuasively to drive such ideas to fruition.
It's precisely because of this nuanced understanding of ideas that more senior engineers may find themselves at odds with the rest of the team. While junior developers may be eager to jump on the latest technology trend, a senior or staff engineer might see the hidden pitfalls, or conversely, champion an unconventional approach that the team initially resists. These disagreements aren't a sign of discord; rather, they signify the presence of hard-earned wisdom that only comes with years of navigating the complex landscape of ideas. It's these moments of divergence that often lead to the most innovative solutions when reconciled effectively.
In Summary
The distinctions between regular, senior, and staff engineers go well beyond years on the job or coding ability. Navigating the complex landscape of ideas—categorized not just by their actual merit but also by how they are perceived—is a critical skill that sets experienced engineers apart. Senior engineers have honed their ability to discern truly valuable ideas from those that merely seem promising, often through hard-learned lessons. Staff engineers extend this skill by not just recognizing but effectively advocating for ideas that may seem risky but hold untapped value. Even in high-caliber environments like Google, ideological divides are prominent, underscoring that the complexities of technical debates are far from black and white.
Are you reading this? Do you find this interesting? I have no idea, unless you reply to this email or write a comment. I am mostly OK with sending these emails into the void, but I wouldn’t mind feedback. Also, if you know someone who may be interested, please forward this to them!
I’m stealing the 2x2 matrix :D