6 ms·

The argument of specialist vs generalist is futile. They simple fit in distinct parts of the journey and evolution of a software product. Generalists are highl

The argument of specialist vs generalist is futile. They simple fit in distinct parts of the journey and evolution of a software product. Generalists are highly valuable for many types of orgs and projects especially nascent projects. But sometimes you need the precise output of a specialist to achieve something. If my business has a product that is highly dependent of let's say OpenGL, then an OpenGL specialist will generate more specific output that someone who knows a little of OpenGL and a lot of other things. However, there's always the counterargument that generalists can compensate with their holistic view and understanding of problems throughout the whole stack. I understand this and agree with it, but I think there's a point in every innovation where the generalist contribution declines sharply. And I'm saying this as a generalist. If you are a generalist and you feel undervalued, you're likely in the wrong project or too involved in phases of a project where your contribution can't move the needle significantly anymore.

jtxx 6y ago
> you're likely in the wrong project or too involved in phases of a project where your contribution can't move the needle significantly anymore to expand on this, I've found most of my happiness as a generalist in early stage startups. to me, a larger company looking for a generalist with no concrete role is a sign that they don't have their stuff together. obviously there are exceptions to this rule - some companies just prefer generalists - but usually once teams get big enough, people settle into specific roles, even as a generalist.
- alexjplant 6y ago
  > larger company looking for a generalist with no concrete role is a sign that they don't have their stuff together. Or that their culture is such that they have entrenched, stovepiped personnel that don't venture out of their specific knowledge domains and they need somebody to bridge that gap. An analogy that I've used far too often when describing software deployment in traditional orgs is one of the dev team and IT playing tennis with the grenade that is the software. With each volley back and forth they give each other nigh-useless information - the operations team will tell the dev team that it crashed without sending logs and that it's because of random setting X that they pulled out of a hat, then the dev team will tell the ops team that said configuration value is hardcoded but that can't be the problem because it runs perfectly on their dev machine, and so on and so forth. Having somebody to mediate this interaction so that it's actually productive is inherently invaluable to, y'know, getting actual work done. Unfortunately it's not particularly valuable from a business perspective because if your org is operating this way then it means that they place greater value on the performance of "software engineering" than the actual value added by the software produced. So basically what you said.
memling 6y ago
> If you are a generalist and you feel undervalued, you're likely in the wrong project or too involved in phases of a project where your contribution can't move the needle significantly anymore. Generalists could also be the people in the project who get things done: they may have sufficient domain knowledge to implement the recommendations of a specialist. In poorly-managed or understaffed teams, a generalist might feel a bit frustrated because they're a go-to for any Job That Needs Doing Right Now, even if it falls outside of the field of their deepest experience.
JoblessWonder 6y ago
Don't take this the wrong way, but I feel like you are undervaluing short fat engineers. :) The article isn't saying that specialists aren't valuable. In fact is says the opposite: "If you know exactly what you need, and you need it right now, choose depth." It is just saying that perhaps the short fat engineer would be the one who realizes they need an OpenGL specialist on the team in the first place because the graphics are hitting a bottleneck and slowing down everything else. The author is merely pointing out that in the nascent portion of projects their contributions are, at times, under valued.
hinkley 6y ago
Diversity. I've had a conversation with a few bosses where at some point I stopped to say words to the effect of, "It's like you think I expect everyone a the project to be like me. I don't." <looks of surprise> A project with just me would have problems too. But every project needs at least a couple of people who think like me, which we aren't accomplishing. This whole expert thing isn't tenable on a long term project. The expert will get bored and wander off, at which point all the mistakes they avoided will just be explored in their absence. Unless they built up people, documentation and processes to take over the work. My read of Kernighan's Law, back-ported onto my own philosophy, is that most of the time you don't want the most capable person working on a solution. You want the 2nd or 3rd most capable person on it, have them reach consensus with the other two. Maybe 10% of your code should be as clever as you can manage. Most of the rest should be so boring that only the junior people find it interesting. The bottom rungs of an orchard ladder everyone is trying to climb.
- Swizec 6y ago
  The ideal is an expert who sets up the project, builds the guard rails, creates the patterns and basically sets up a framework for everyone to use. Then they teach everyone how to use it and why And from then it’s a mentoring role. The expert spends more time PR-ing and adding to the framework than building end product features. They build stuff that touches every feature. Force multiplier is the game.
  - cat199 6y ago
    agree - in my view, if you're not designing for the 'hit by a bus scenario', you're not an expert, irrespective of technical knowledge
  - hinkley 6y ago
    I’ve seen this crash and burn too often. If you have someone build something, and then explain it, you don’t find out until after if they are capable of explaining it. Just like a product MVP, you have to explain it as you go along. Without it, you start out with a multiplier but end with a divisor.
marcinzm 6y ago
>I think there's a point in every innovation where the generalist contribution declines sharply. That why as another post commented they move into management or product at larger organizations. They get to move the needle and apply their generalist knowledge even to mature projects.
yumraj 6y ago
As a generalist, I agree with bulk of what you're saying but at least my personal experience seems to echo the fact that generalists in general are undervalued since when someone asks a person "what can you do for me", a specialist always has a better and sharper answer than a generalist - and that makes all the difference. Personally I'll take a generalist any day since specialists suffer from the "if you only have a hammer everything looks like a nail" syndrome. Having said that, my 1 career advice to anyone would be, become a specialist in 1-single thing, and then become a generalist in everything else. I'm not that, but I feel that that I would have been best served if I had been that.
- paulryanrogers 6y ago
  Sounds like the 'T' shaped skill set.
  - yumraj 6y ago
    Sorry, not sure what you mean by ‘T’ shaped skill set. Could you elaborate..
    - harimau777 6y ago
      It is used to describe a skillset which has a little experience in a wide number of areas (the top of the T) and deep experience in a single area (the stick of the T).
      - yumraj 6y ago
        Thanks, yes, than that is what I was referring to, I just didn't know that there was actually a term for it.
        Impossible 6y ago
        The article discusses T shaped engineers. It's pretty good, I suggest reading it!
haskellandchill 6y ago
> you're likely in the wrong project The point is there are less project slots for generalists to be in right now.
devonbleak 6y ago
You're going to pay more for a specialist but in shorter bursts whereas you're going to need generalists in longer stretches. Generalists are where your tribal knowledge and lessons learned are going to live. Generalists are also more likely to move into management because of the perspective they bring and adaptability inherent in being a generalist.
- Toenex 6y ago
  I think the management point is a good one. A valuable generalist role is working at the interface between management and the specialists in the team. As an engineer I was much more of a generalist which lead me into product management.
lxe 6y ago
> If you are a generalist and you feel undervalued, you're likely in the wrong project or too involved in phases of a project where your contribution can't move the needle significantly anymore. My general take is that generalists would excel in small scrappy disorganized organic teams, while "specificists" would do well in teams with high level of organization and management structure. Unfortunately, large organizations tend to push out generalists, as structure increases, and their value in the eyes of management decreases. I think a large organization should have both kinds of teams. This kind of alludes to Clayton Christensen's Innovator's Dilemma -- "well managed" big orgs should be internally disrupted by small-scale "startup" style teams, and those scrappy organic type of teams need generalists.

jtxx 6y ago

> you're likely in the wrong project or too involved in phases of a project where your contribution can't move the needle significantly anymore to expand on this, I've found most of my happiness as a generalist in early stage startups. to me, a larger company looking for a generalist with no concrete role is a sign that they don't have their stuff together. obviously there are exceptions to this rule - some companies just prefer generalists - but usually once teams get big enough, people settle into specific roles, even as a generalist.

alexjplant 6y ago
> larger company looking for a generalist with no concrete role is a sign that they don't have their stuff together. Or that their culture is such that they have entrenched, stovepiped personnel that don't venture out of their specific knowledge domains and they need somebody to bridge that gap. An analogy that I've used far too often when describing software deployment in traditional orgs is one of the dev team and IT playing tennis with the grenade that is the software. With each volley back and forth they give each other nigh-useless information - the operations team will tell the dev team that it crashed without sending logs and that it's because of random setting X that they pulled out of a hat, then the dev team will tell the ops team that said configuration value is hardcoded but that can't be the problem because it runs perfectly on their dev machine, and so on and so forth. Having somebody to mediate this interaction so that it's actually productive is inherently invaluable to, y'know, getting actual work done. Unfortunately it's not particularly valuable from a business perspective because if your org is operating this way then it means that they place greater value on the performance of "software engineering" than the actual value added by the software produced. So basically what you said.

memling 6y ago

> If you are a generalist and you feel undervalued, you're likely in the wrong project or too involved in phases of a project where your contribution can't move the needle significantly anymore. Generalists could also be the people in the project who get things done: they may have sufficient domain knowledge to implement the recommendations of a specialist. In poorly-managed or understaffed teams, a generalist might feel a bit frustrated because they're a go-to for any Job That Needs Doing Right Now, even if it falls outside of the field of their deepest experience.

JoblessWonder 6y ago

Don't take this the wrong way, but I feel like you are undervaluing short fat engineers. :) The article isn't saying that specialists aren't valuable. In fact is says the opposite: "If you know exactly what you need, and you need it right now, choose depth." It is just saying that perhaps the short fat engineer would be the one who realizes they need an OpenGL specialist on the team in the first place because the graphics are hitting a bottleneck and slowing down everything else. The author is merely pointing out that in the nascent portion of projects their contributions are, at times, under valued.

hinkley 6y ago

Diversity. I've had a conversation with a few bosses where at some point I stopped to say words to the effect of, "It's like you think I expect everyone a the project to be like me. I don't." <looks of surprise> A project with just me would have problems too. But every project needs at least a couple of people who think like me, which we aren't accomplishing. This whole expert thing isn't tenable on a long term project. The expert will get bored and wander off, at which point all the mistakes they avoided will just be explored in their absence. Unless they built up people, documentation and processes to take over the work. My read of Kernighan's Law, back-ported onto my own philosophy, is that most of the time you don't want the most capable person working on a solution. You want the 2nd or 3rd most capable person on it, have them reach consensus with the other two. Maybe 10% of your code should be as clever as you can manage. Most of the rest should be so boring that only the junior people find it interesting. The bottom rungs of an orchard ladder everyone is trying to climb.

Swizec 6y ago
The ideal is an expert who sets up the project, builds the guard rails, creates the patterns and basically sets up a framework for everyone to use. Then they teach everyone how to use it and why And from then it’s a mentoring role. The expert spends more time PR-ing and adding to the framework than building end product features. They build stuff that touches every feature. Force multiplier is the game.
- cat199 6y ago
  agree - in my view, if you're not designing for the 'hit by a bus scenario', you're not an expert, irrespective of technical knowledge
- hinkley 6y ago
  I’ve seen this crash and burn too often. If you have someone build something, and then explain it, you don’t find out until after if they are capable of explaining it. Just like a product MVP, you have to explain it as you go along. Without it, you start out with a multiplier but end with a divisor.

marcinzm 6y ago

>I think there's a point in every innovation where the generalist contribution declines sharply. That why as another post commented they move into management or product at larger organizations. They get to move the needle and apply their generalist knowledge even to mature projects.

yumraj 6y ago

As a generalist, I agree with bulk of what you're saying but at least my personal experience seems to echo the fact that generalists in general are undervalued since when someone asks a person "what can you do for me", a specialist always has a better and sharper answer than a generalist - and that makes all the difference. Personally I'll take a generalist any day since specialists suffer from the "if you only have a hammer everything looks like a nail" syndrome. Having said that, my 1 career advice to anyone would be, become a specialist in 1-single thing, and then become a generalist in everything else. I'm not that, but I feel that that I would have been best served if I had been that.

paulryanrogers 6y ago
Sounds like the 'T' shaped skill set.
- yumraj 6y ago
  Sorry, not sure what you mean by ‘T’ shaped skill set. Could you elaborate..
  - harimau777 6y ago
    It is used to describe a skillset which has a little experience in a wide number of areas (the top of the T) and deep experience in a single area (the stick of the T).
    - yumraj 6y ago
      Thanks, yes, than that is what I was referring to, I just didn't know that there was actually a term for it.
      - Impossible 6y ago
        The article discusses T shaped engineers. It's pretty good, I suggest reading it!

haskellandchill 6y ago

> you're likely in the wrong project The point is there are less project slots for generalists to be in right now.

devonbleak 6y ago

You're going to pay more for a specialist but in shorter bursts whereas you're going to need generalists in longer stretches. Generalists are where your tribal knowledge and lessons learned are going to live. Generalists are also more likely to move into management because of the perspective they bring and adaptability inherent in being a generalist.

Toenex 6y ago
I think the management point is a good one. A valuable generalist role is working at the interface between management and the specialists in the team. As an engineer I was much more of a generalist which lead me into product management.

lxe 6y ago

> If you are a generalist and you feel undervalued, you're likely in the wrong project or too involved in phases of a project where your contribution can't move the needle significantly anymore. My general take is that generalists would excel in small scrappy disorganized organic teams, while "specificists" would do well in teams with high level of organization and management structure. Unfortunately, large organizations tend to push out generalists, as structure increases, and their value in the eyes of management decreases. I think a large organization should have both kinds of teams. This kind of alludes to Clayton Christensen's Innovator's Dilemma -- "well managed" big orgs should be internally disrupted by small-scale "startup" style teams, and those scrappy organic type of teams need generalists.