Specialist or generalist: choose the problem before the label
Decide where to deepen your skills and where breadth helps. Compare specialist and generalist work against an actual team problem, not a career stereotype.
Choose depth or breadth according to the work you want to become reliable at. Specialisation helps when a hard part needs sustained expertise; breadth helps when the problem crosses boundaries. Neither label is a complete career strategy.
A slow checkout might need a database expert to fix one difficult query, or someone who can trace the delay across the browser, API, and payment service. The right learning plan depends on where the problem actually is.
“Become a specialist” and “stay a generalist” are both incomplete instructions. They leave out the problem, the surrounding team, and the kind of responsibility you want. A list of technologies does not tell you whether you can solve a difficult problem with any of them.
Compare both approaches on the same problem
Take an illustrative checkout problem. Customers sometimes wait a long time after pressing Pay. One developer knows how to inspect database execution plans in detail. Another can follow a request through the browser, application, and external payment flow. Both approaches are valuable, but they answer different uncertainties.
If the delay is already isolated to a query that behaves badly under realistic data, deeper database expertise may be the next useful investment. If nobody knows where the delay happens, tracing the complete flow may matter first. The broad investigation can discover the need for the specialist; the specialist can explain constraints that change the broader design.
Compare the approaches on the same dimensions. What uncertainty can you reduce? What decisions can you make safely? Where must you ask for help? How will another person check your work? A title such as “full stack” does not answer those questions, and a narrow job title does not prevent someone from understanding the wider system.
Try the decision
One service is slow and its product requirements are unclear. How should the developer choose where to grow?
The label says little about this service or the team’s missing capability.
Next step: Compare the actual performance and product decisions the work demands.
This is an illustrative decision with stated assumptions. It cannot establish your employer’s policy or predict an individual career outcome.
Depth is not the same as narrowness
David Epstein’s Range challenges the assumption that early specialisation is always the best route. The author’s description of the book presents an argument for breadth and exploration. That is a useful challenge to a rigid career plan, not evidence that generalists always outperform specialists in software.
For a developer, depth might mean understanding why a particular solution fails, recognising misleading measurements, and knowing what to investigate next. It is not simply knowing more commands. Breadth might mean noticing that a technically correct change makes a support process harder, then finding the right person to resolve that conflict. It is not collecting introductions to ten frameworks.
One practical approach is to maintain a reliable area of depth while deliberately learning the neighbouring work that most often blocks it. A database-focused developer might learn enough application tracing to recognise when the database is not the bottleneck. A frontend developer might learn enough accessibility testing to detect a problem that visual inspection misses.
This is a proposed way to choose useful learning, not a universal skill shape everyone must follow. Some roles need several deep specialisms; some teams need a person who handles a broad, bounded product area. The useful distinction is between reliable capability and surface familiarity.
Choose a learning bet with visible use
Write a learning goal around an action. Replace “learn cloud” with “explain the deployment path for this small service and diagnose a failed deployment in a safe environment.” Replace “become more strategic” with “compare two approaches using the constraints the team actually has.”
Then identify a task, a reviewer, and a boundary. The checkout investigator might prepare a trace and explain why it implicates one component rather than another. The specialist might reproduce the slow query and show the trade-offs of two fixes. Both can produce evidence of judgement rather than a certificate of attendance.
Keep a short “can do / need help / not yet needed” record. This avoids treating every missing skill as an emergency. Follow the guide to shipping bounded work independently for the delivery responsibility around the technical exercise. When selecting practice, use a repeatable task with feedback, not just more reading.
Check whether the work exists
A learning investment needs somewhere to be used. Ask which problems the organisation repeatedly struggles with, who handles them now, and whether you can participate. An interesting specialism with no access to relevant work may remain a hobby for the time being. That does not make it worthless; it changes what you can expect it to do for your job.
For an external move, inspect actual role descriptions and speak to people doing the work. Distinguish required capabilities from a long wish list. Do not infer demand, pay, or security from a fashionable label. Those are separate questions that require current evidence in the market and location you are considering.
Be especially careful with the idea that breadth automatically leads to leadership. Senior and staff expectations depend on scope and organisational need. Knowing a little about many tools does not by itself demonstrate that you can guide a complex decision.
Revisit the choice when the work changes
After a meaningful period of using the skill, ask what became easier, which decisions still need help, and which adjacent gap now matters most. Continue deepening, broaden into that gap, or choose another direction. You do not need a permanent identity as one type of developer.
The better question is small enough to answer: “For the work I want next, which capability would let me contribute more reliably?” That produces a learning decision. “Am I a specialist or a generalist?” often produces only a label.