Both have their value. Personally I prefer broad over deep, but that's me. You need to figure out what works best for you.
Deep has the advantage that when specialists are in demand, you're really in demand. It's good to have someone on the team who knows absolutely everything about the thing you do. The downside is that when technology or your career moves on, you know nothing. You're stuck doing that one thing, and may have a harder time getting into something else.
And broadness has a specialization of its own. Knowing multiple things is particularly valuable if you know how to connect those things. If you can develop front-end with an eye on what's easier for the back-end, if you can design the graphics that you will need, rather than having to wait for someone else to get around to it. Knowing different unconnected things is less valuable, but even there you may find unexpected connections. But for the deep technical stuff, you may find that you'll have to ask a real expert.
No generic answer to this but one way to think about it is over the long term would you value more depth (expert in something) or breadth (freedom to explore everything)?
If you value depth, specialize. In an industry (e.g security, healthcare, finance, etc.) or field (AI, distributed systems, scaling, etc.) You'll get intellectual satisfaction, emotional satisfaction if you intrinsically care about the space (e.g healthcare), and financial upside since people value specialization.
If you value breadth and wandering, generalize. You'll still get intellectual satisfaction from knowing a variety of things, emotional satisfaction from working on things you care w/o any industry constraints, and financial upside since generalists are valuable to startups and even though their failure rate is high, being in the right company at the right time could give you the same financial upside you'd get from say being at a large company in a specialized field.
I personally chose to speciailize because I value depth and find diving deep into a field more meaningful. I know many generalists with the same amount of experience who are doing equally well and I would hire them and value them in the same way if I built a company again.
I have pondered about this depth vs breadth approach for some time. My path has made me a generalist who learns and does whatever I think is necessary in a given situation. This is great because I can do anything. But I envy the domain experts who do one (or a related few) things VERY well.
Perhaps it depends much on the mind of the person; I don't think I could just focus on one thing forever. But while the new shiny tech guys may seem to have more opportunities, I believe the domain experts may get paid more and have more of their career time spent as "recognized leaders".
It's probably good that people are all different, and both types (and all in between) exist.
You can focus on breadth or depth depending on what kind of programmer (generalist or specialist) you want to be. Matt Klein (of Envoy) had a good thread about that on Twitter [1].
He focuses on depth whereas I tend to focus on breadth. Of course I have areas and technologies I know better because I have worked in / with them (computer vision, filesystem / DB replication algorithms, Lua, etc) but I try to expand my areas of knowledge so I can understand whole systems rather than become an expert at a specific thing. For instance, right now, I'm doing mostly Web front-end stuff, which is the part of the Web stack I know the least.
Going broad rather than deep cuts both ways. Sure, you have more employment opportunities, but the value of your individual contributions has a ceiling. That means after a relatively short period of time, you plateau career wise. Like is a generalist with 15 years of experience really that much more valuable than one with 7 years? Not really. So if you want to progress beyond a generic senior engineer, then you need to specialize in something.
Substituting breadth for depth is likely only useful in less technical roles. Specialize in different areas so you have depth in many. There's a thing called 'T'-shaped skills and you can acquire multiple areas of depth and be 'TT'-shaped, etc.
I think you need the right company which values general and broad knowledge. There might not be so many positions which specifically look for such a person and so having some expert knowledge might come in handy from time to time when your general input is not what the team currently needs.
In my experience having some deep knowledge on a topic makes you a bit better situated on the market if you don't have a strong network, but having broad knowledge allows you to have impact on a greater scale and you might value that more.
I consider myself a generalist, and if I had to choose, it would be backend. It's more low level and fun, and honestly, I'm not a great designer. The point of being a generalist is that you can adapt to more places.
There is plenty of value for people who can do both. Or at least most of one and a good amount of the other.
I have become a generalist at a company that definitely has distinct frontend and backend teams. I started as backend dev but started doing frontend work too. I have found myself in great demand due to my unique role at the company.
Since I know a lot about the entire tech stack, I can act as a routing agent for product managers and other non-developers. They ask me questions, and I can give them a pretty good answer. If they need something done, I can refer them to the specialist who wrote the code that needs changed.
When I am coding small tasks, I can write both sides of an API much faster than it would take two devs to negotiate the requirements. Communication is a time sink. Rather than writing emails or tasks requests, I can just write code and be done. There is a threshold though where it is better to split the work. There is only so much I can hold in my head at once. But even then, I find I am better at communicating because I know how both sides work.
Does the project have a nasty bug that needs tracking down? The generalist can lead an investigation the whole stack, asking specialists when needed. Last week I solved what our CTO referred to as "the ninja bug" that had plagued another team for months. The root problem was on the frontend (ios client), and I pushed an instant fix by updating our server code to compensate.
Lastly, some companies have skunkworks projects with very small teams. Being able to own both sides of a task means fewer people required to do it. I have become the goto guy for whipping up prototypes. I typically work directly with our CEO to create a proof of concept as fast and cheap as possible. When things look promising, we bring on more specialized devs and I lead the project.
You may not want to be exactly 50/50, but definitely be aware of how the other side lives. And dont be afraid to ask for a role change to broaden your skill set!
Depends on the needs of the team too. In most of my roles, having good breadth has been more important to keep an eye on the big picture and to be able to contribute in various areas and tell when the Jr's are doing something unwise.
I think everyone of us should try and specialize in at least one thing. That does not imply that you do your best to know nothing about relevant fields. For example if you are a web developer who works on Ruby on Rails and makes awesome web apps but don't like working on the front-end, i.e HTML/CSS/JS then that is OK as long as you have some basic knowledge about those technologies and respect those who do work in that area.
Back to the specialization, I really think you should have at least one area in your chosen field where you have deep knowledge. How deep? On the above example - maybe you know internals of Rails + Rack very well. If you are on the front-end may be you should have a thorough understanding of how browsers work, how HTML/CSS is parsed and rendered etc. I don't really have a good explanation as to why this is important but I've noticed that the really good web developers or designers tend to have at least one specialization or deep interest within their fields.
Generalists are typically better in smaller companies. As companies grow they move towards specialists.
This is typically because of workload. In the early days of a project the work oscillates between front and back end. As projects grow you will have enough frontend work to support dedicated front end engineers and similarly for backend.
I think both are important but it’s not necessary for any one person to excel at both. Some will naturally be better at depth and others at breadth. As long as you acknowledge both types of contributions I think it will work out well.
I don't know if I'm a generalist or more someone who's simply curious and not intimidated to get stuck into stuff I have zero knowledge of.
I seem to have acquired a fairly diverse set of technical skills compared to most devs which has it's advantages, but at the same time I know at times it can make it hard to explain to employers what I do and how I can be useful to them. Sometimes this leads to me being underutilised, and in my opinion under appreciated. It can also make interviews difficult because employers like you to talk about relevant experience where my experience is all over the place.
I personally think my skill set is awesome though. I tend to be the perfect candidate for smaller companies where technical specialisation isn't feasible. Need someone to do some some UI/UX design, frontend development, backend development, devops, AI, SEO, QA? I can help. I've worked with almost every major language at some point in my career and while I'm not great at every language, I'm familiar enough that I can get whatever needs doing done.
I do try to keep my frontend development skills current enough that I can call myself a frontend dev when needed. Generally for contracting or when applying for positions in larger companies this is my best route. When I'm in the door sometimes I can branch out a little, but it depends on the company. I do worry I might fall behind at some point due to my lack of focus, but honestly I think people who specialise too much fall into that trap more often. If the technology you specialise in becomes redundant, then so do you. Having a broad set of skills gives you a technical safety net because there is always something else you can fall back on, even if that comes at the cost of fitting less perfectly into any specific role.
So no, I don't regret it and I think it's actually an advantage if you can sell it correctly. Learn as much as you can in my opinion. There are definitely companies out there which really want great generalists who can just get stuff done.
I consider myself to be a generalist that specializes in front-end web development.
If you are trying to decide between hiring a generalist or specialist, it just comes down to your resources and the current structure of your team.
If you are a startup with little to no funding... generalist.
If you are a stable company looking to improve your UI or starting to incorporate new tech (like native mobile dev) into your products....specialist.
An Ideal team for me, given ample resources, would be a bunch of specialists supported by 1 - 2 generalist.
A specialist will always try and solve problems with the tech that they know. This often leads to maintenance problems due to a blurring of separation of concerns. A specialist will also out perform a generalist when they are given the correct problems to solve.
A generalist will know which specialist is the correct one to solve the problem, and can even do some light to medium lifting if a deadline calls for it.
Both being an expert in a particular area and having broad knowledge in different areas can be valuable in tech, depending on the specific context and goals.
Being an expert in a particular area means having a deep understanding and mastery of a specific technology, tool, or domain. On the other hand, having broad knowledge across different areas of tech can be valuable in roles that require a generalist skill set, such as product management or entrepreneurship.
If you haven't been aware of, for example, Blockchain technology, you can start expanding your knowledge with this blog: https://www.ratherlabs.com/blog
I highly recommend it for those who want to study something new!
I think we might be talking in different time scales, and maybe different responsibilities. If you're looking to bring on someone to solve an urgent problem this month, you're going to need a specialist in the area. If you're bringing on an early hire to build a team, or another engineer to bolster your team with some specialists, you may want a solid generalist. There might also be some significant difference between organizational structures, if you're joining a team centered around building and supporting a product, or maybe a startup with only one or two products, a generalist might be much more effective. If you're joining a massive organization where there are highly specialized teams dealing with specific problem areas, a specialist makes a lot more sense.
As a sweeping statement, I'm better at solving "a problem" than a specialist. If you define the problem area tightly, they may be the right person for the job, but if the role you're hiring for has uncertainty and flexibility, the front end specialist probably isn't the right person to figure out why your database is slow, your load balancer isn't working, your build and deploy process is stuck, etc.
There are definitely roles that are much more fit to one or the other, but the generalist can handle a lot of things pretty well. All of that being said, we can probably agree that the best setting is having both.
I agree with this, it is good for skillsets to cross pollinate and it makes you better at both.
Another divide is development and design, those that can do that produce amazing products. You see this more in the gaming or interactive space but it makes you less biased and understanding of the problem points, and best parts of both verticals.
Specialization over generalization is why lots of large software sucks today and small companies or startups win, they employ more generalists, design/develop crossovers and full stack product focused t-shaped employees. When teams are huge, specialized and care is removed. The chaos of more communication channels (N(N-1)/2) encourages just staying in your lane rather than viewing the big picture. Small teams with generalists are where the best products are made due to everyone going beyond their lanes/channels and viewing the big picture.
I think generalization is best in startups or small groups including gaming/interactive especially with hyperfocus on a product. Making the product good in all aspects, and caring about them, from design to development, presentation to production, and especially maintenance and iterative growth. Once that is established, teams can grow and specialize, but innovation and creative growth is harder.
As a former IT industry analyst who tended towards being a generalist--and has a somewhat similar role today--there's a tension that I've often discussed with people.
On the one hand, my personal preferences just tend to being more generalist. And I think that can inform opinions and understanding whereas extreme specialists can often have such blinders that they really miss broader context.
On the other hand, go too broad and you know a little bit about a lot of different things. And you really have very little background in any individual area to, for example, push back against BS claims.
Deep has the advantage that when specialists are in demand, you're really in demand. It's good to have someone on the team who knows absolutely everything about the thing you do. The downside is that when technology or your career moves on, you know nothing. You're stuck doing that one thing, and may have a harder time getting into something else.
And broadness has a specialization of its own. Knowing multiple things is particularly valuable if you know how to connect those things. If you can develop front-end with an eye on what's easier for the back-end, if you can design the graphics that you will need, rather than having to wait for someone else to get around to it. Knowing different unconnected things is less valuable, but even there you may find unexpected connections. But for the deep technical stuff, you may find that you'll have to ask a real expert.
reply