Chapter 11: Going Deep vs. Going Broad
Everyone says you should be T-shaped. Nobody tells you what to do when you’re shaped like a lowercase L and leaning hard to the left.
At some point in every developer’s career, they face the depth-breadth question. Should I go deeper in what I know, or should I expand into new territory? Should I become the person who knows everything about Kubernetes, or the person who can do a little bit of everything? Should I specialize or generalize?
The standard answer — the one you’ll hear at every conference and read in every career advice blog — is “be T-shaped.” Go deep in one thing (the vertical bar of the T) and maintain broad familiarity across many things (the horizontal bar). It’s tidy advice. It makes a nice diagram. And it’s not exactly wrong.
But it’s also not enough. Because the T-shape metaphor glosses over the real questions: how deep is deep enough? How broad is broad enough? When should you stop deepening and start broadening? When should you stop broadening and start deepening? And what do you do when going deep starts to feel like hiding?
The Comfort of Depth
Let’s start with why depth is so appealing, beyond its obvious practical value.
When you go deep into a technology, something happens psychologically: you become safe. You accumulate expertise that’s difficult to replicate, which makes you valuable, which makes you secure. You become the person everyone goes to for that one thing, and being that person feels good. It feels important. It feels like you’ve earned your place.
Depth also provides clarity. When you’re a specialist, you know what to study, what to read, which conferences to attend, what your next learning goal should be. The path is clear because the path is narrow. There’s comfort in that narrowness. In a field that’s overwhelmingly vast, choosing a lane is an act of self-preservation.
And depth is genuinely valuable. The world needs deep experts. Someone has to understand the internals of the database engine. Someone has to know the security implications of every HTTP header. Someone has to understand the garbage collector well enough to tune it for production workloads. Depth isn’t a trap — it’s a real and necessary thing.
But it becomes a trap when depth is motivated not by genuine interest or professional need, but by fear. Fear of being a beginner again. Fear of losing the status that comes with expertise. Fear of discovering that you’re not actually as good at learning as you thought you were. When depth becomes a bunker rather than a foundation, you’ve got a problem.
The Anxiety of Breadth
Breadth has its own psychological signature, and it’s not always comfortable.
The developer who goes broad is, by definition, a beginner in many things simultaneously. They’re the person in the meeting who says “I’ve worked with it a bit” instead of “I’m an expert in it.” They’re the person whose knowledge is wide but shallow in any given area, which can feel — especially in a culture that worships expertise — like a confession of mediocrity.
Broad developers also face the “jack of all trades, master of none” stigma. It’s one of the oldest put-downs in professional life, and it stings because there’s a kernel of truth in it. If you spread yourself across ten technologies, you probably won’t be the world’s leading expert in any of them. And in a job market that often filters by keyword match and depth of experience, breadth can look like lack of commitment.
But breadth has advantages that are easy to underestimate. Broad developers see connections that specialists miss. They recognize when a problem in one domain has already been solved in another. They can communicate across team boundaries because they speak enough of each team’s language to translate. They’re often the people who unstick projects, not because they have the deepest knowledge, but because they have the widest view.
The anxiety of breadth is that you never feel like an expert in anything. The power of breadth is that you can see the whole board while specialists are focused on their quadrant.
The T-Shape and Its Discontents
The T-shape model tries to have it both ways: deep enough to be an expert, broad enough to be versatile. And as a concept, it’s sound. But as practical advice, it’s incomplete.
The first problem is that the T-shape model doesn’t tell you how to sequence things. Do you go deep first and then broaden? Or do you go broad first and then deepen? The answer matters, because the two paths produce very different developers with very different career trajectories.
If you go deep first, you build a strong foundation of expertise that gives you credibility and job security. But you also risk getting so comfortable in your depth that broadening feels threatening. You become the expert who can’t (or won’t) work outside their domain.
If you go broad first, you develop versatility and a wide perspective. But you risk never developing the depth that commands respect and compensation. You become the generalist who’s useful everywhere and essential nowhere.
The second problem with the T-shape model is that it assumes a stable landscape. Your deep expertise in technology X is valuable as long as technology X is relevant. But technologies shift, and deep expertise in a declining technology is a depreciating asset. The T-shape needs to be maintained, and maintaining it sometimes means choosing a new vertical bar — which brings you right back to the beginner’s dilemma.
The Real Shape
The honest truth is that most developers aren’t T-shaped. They’re more like a mountain range — a series of peaks and valleys, with some areas of genuine depth and some areas of genuine ignorance, shaped by the random topography of their careers.
Maybe you’re deep in React and PostgreSQL but have never touched mobile development. Maybe you know a ton about DevOps but your frontend skills stopped at jQuery. Maybe you’re an expert in one very specific thing — the thing your company needed when they hired you — and everything else is a plateau of moderate familiarity.
That’s normal. That’s what a career shaped by actual work looks like. The T-shape is an aspiration, not a description, and the gap between the aspiration and the reality is where a lot of unnecessary anxiety lives.
What matters is not whether your skill profile matches a letter of the alphabet. What matters is whether you’re making intentional choices about where to invest your learning time, rather than letting inertia make those choices for you.
Making the Choice
So here’s a framework for thinking about depth vs. breadth that’s more useful than “be T-shaped.”
Go deep when the depth is compounding. Some areas of depth build on themselves — each new thing you learn makes the previous things more useful. Database internals are like this: the deeper you go, the more every query you write benefits from the knowledge. Security is like this: each vulnerability you understand makes you better at spotting all the others. If you’re in a domain where depth compounds, going deeper is almost always a good investment.
Go broad when you’re stuck. If you’ve been in one stack for years and you feel like you’re stagnating — same problems, same solutions, same patterns — breadth is the cure. Not because your current stack is bad, but because a new perspective will make you see your current work differently. Sometimes the best way to get better at Python is to spend a month writing Go.
Go deep when you have a specific need. If your job requires you to be an expert in Kubernetes, become an expert in Kubernetes. Depth driven by real-world need is the most efficient kind of learning because you get to apply what you learn immediately. Theory and practice reinforce each other.
Go broad when the landscape is shifting. If you sense that your area of deep expertise is declining in relevance — not gone, but fading — that’s the time to start broadening before it’s urgent. Broadening from a position of strength is much more comfortable than broadening from a position of desperation.
Go deep when you’re enjoying it. Genuine curiosity about a topic is one of the best predictors of sustained learning. If you’re fascinated by compiler design, go deep in compiler design. The joy will carry you through the hard parts, and joy-driven depth produces better expertise than obligation-driven depth.
Go broad when you’re avoiding it. If you notice that you’re going deeper and deeper into one area specifically to avoid learning other things — if depth has become a hiding place — that’s a signal. The discomfort you’re avoiding by not broadening is probably the discomfort of growth, and growth is worth the price.
The Permission to Change Shape
Maybe the most important thing is this: your shape can change. You’re not committing to a permanent configuration when you decide to go deep or go broad. You can spend two years going deep, then a year going broad, then deep again in a different area. You can oscillate. You can experiment. You can follow your curiosity and see where it leads.
The developers with the best long-term careers aren’t the ones who found the perfect balance between depth and breadth and maintained it forever. They’re the ones who kept making honest assessments of where they were, what they needed, and what the world was asking for — and then adjusted.
There’s no correct shape. There’s only the shape that serves you now, and the willingness to reshape when now changes.