4 ms·

Interesting read, though I'm a little wary of the turning generalists into specialists point being taken too far. There are a lot of unwritten assumptions behin

Interesting read, though I'm a little wary of the turning generalists into specialists point being taken too far. There are a lot of unwritten assumptions behind that idea. For example, let's consider a business that does something many of us here are familiar with: making a web app. There's a trend in web development world these days to put every little thing into its own silo. We separate front-end and back-end people. We separate back-end developers from DBAs and operations people. We separate designers and front-end developers. We invent whole new job titles using trendy terms like "user experience", as if making a good UI hasn't always involved doing the same things. The real world does not work like this. In the real world, all of these things are related, and what matters is the overall result. In the real world, there are many different skill sets, but almost no-one is an expert at one thing and has little if any knowledge of the others. And crucially, in the real world someone can often do one part of a job much better if they also have substantial knowledge of some of the related parts. So I think generalist vs. specialist is almost always a false dichotomy once you get beyond the crude "Yes, the CEO probably shouldn't also be the guy spending all day debugging a tricky rendering glitch" level. One "generalist" with skills/knowledge in more than one area can easily be more productive than multiple "specialists" who each know their own area but don't really understand the relationships to adjacent areas, and thus need significant process and management to work effectively at all and still probably incur significant overheads. IME, the principle of keeping a level of generalism scales up just fine as well: those with the broader knowledge and skills often become good candidates for technical leadership roles in growing organisations.

hinkley 10y ago
If you want to stay a generalist at a bigger company, convince the bosses that they need to worry about the Truck Number of each of the competencies in the company, and then participate in improving it. The problem I've always had with being a generalist is defending your existence. If there are constant fires to put out, people will see you fighting them. But if you prefer to prevent fires instead, you have to work all the harder to be seen. It's easier to be recognized if you let or encourage management to label everybody and you carve out a nice niche for yourself. It's easier to make something more complicated so people leave it to you to work on. Managers who know how to run an effective team know and push back against this, the ones that are just trying to look good often don't.
- Silhouette 10y ago
  What you describe is often true in larger companies, but IME not in the kinds of 10-20 person outfits we're talking about here, or even quite a bit bigger. At that level, one experienced "generalist" person who can do a whole job end-to-end can still get the same visible results as a small team of less experienced "specialist" people, and if we're talking about salaried staff then that single more experienced person is probably costing far less to hire than all of the other team put together because good senior people are disproportionately cheap to hire as employees. The overheads of running a team mean it takes a surprisingly large project before it's necessary/advantageous to hire a much larger team of junior people rather than a much smaller number of senior people, assuming you have the choice.
  - dasmoth 10y ago
    Agree with all of this. But there seems to be active distrust of coders working solo, both from managers and from other coders. There's a surprisingly strong perception the "a team" is the safe option.
    - Silhouette 10y ago
      But there seems to be active distrust of coders working solo, both from managers and from other coders. There's a surprisingly strong perception the "a team" is the safe option. It's been my experience that capable developers tend to appreciate other capable developers. It's also been my experience that capable developers appreciate managers who are actually doing a useful job, and vice versa, and that both of those groups are also quite willing to support those who are currently less experienced but are interested and trying to learn and grow. I suspect the kinds of objections you're thinking of most often come from managers or developers whose own positions are threatened as soon as someone competent enters the picture. A capable one-person development group has no need of a micro-manager to take the credit on their behalf, nor of a developer who has just enough knowledge and skill to be dangerous and/or in the way but no inclination to get any better. At some point obviously you need more than one developer for scalability and resilience, but even then you can still do a lot with a few good developers and a useful manager co-ordinating them compared to a large group of mediocre developers and a whole management hierarchy above them.

hinkley 10y ago

If you want to stay a generalist at a bigger company, convince the bosses that they need to worry about the Truck Number of each of the competencies in the company, and then participate in improving it. The problem I've always had with being a generalist is defending your existence. If there are constant fires to put out, people will see you fighting them. But if you prefer to prevent fires instead, you have to work all the harder to be seen. It's easier to be recognized if you let or encourage management to label everybody and you carve out a nice niche for yourself. It's easier to make something more complicated so people leave it to you to work on. Managers who know how to run an effective team know and push back against this, the ones that are just trying to look good often don't.

Silhouette 10y ago
What you describe is often true in larger companies, but IME not in the kinds of 10-20 person outfits we're talking about here, or even quite a bit bigger. At that level, one experienced "generalist" person who can do a whole job end-to-end can still get the same visible results as a small team of less experienced "specialist" people, and if we're talking about salaried staff then that single more experienced person is probably costing far less to hire than all of the other team put together because good senior people are disproportionately cheap to hire as employees. The overheads of running a team mean it takes a surprisingly large project before it's necessary/advantageous to hire a much larger team of junior people rather than a much smaller number of senior people, assuming you have the choice.
- dasmoth 10y ago
  Agree with all of this. But there seems to be active distrust of coders working solo, both from managers and from other coders. There's a surprisingly strong perception the "a team" is the safe option.
  - Silhouette 10y ago
    But there seems to be active distrust of coders working solo, both from managers and from other coders. There's a surprisingly strong perception the "a team" is the safe option. It's been my experience that capable developers tend to appreciate other capable developers. It's also been my experience that capable developers appreciate managers who are actually doing a useful job, and vice versa, and that both of those groups are also quite willing to support those who are currently less experienced but are interested and trying to learn and grow. I suspect the kinds of objections you're thinking of most often come from managers or developers whose own positions are threatened as soon as someone competent enters the picture. A capable one-person development group has no need of a micro-manager to take the credit on their behalf, nor of a developer who has just enough knowledge and skill to be dangerous and/or in the way but no inclination to get any better. At some point obviously you need more than one developer for scalability and resilience, but even then you can still do a lot with a few good developers and a useful manager co-ordinating them compared to a large group of mediocre developers and a whole management hierarchy above them.