6 ms·

Specialist .- Being a specialist/senior dev you can get up to 120-160k/year for languages like ruby, rails, go, java, js, .NET, c++, etc. You can give speeches

by atmosx 11y ago

Specialist .- Being a specialist/senior dev you can get up to 120-160k/year for languages like ruby, rails, go, java, js, .NET, c++, etc. You can give speeches, write books, etc. As a 'generalist' you'll be between 60-80k at most, because everyone will hire you as a entry level programmer in their stack since you're not expert.

kabdib 11y ago
On the other hand, a "generalist" with a couple of really deep areas of expertise can be very valuable. I like the T-shape model; able to help out in many areas, able to make significant contributions in a smaller number of areas. (I would add: And with a significant and continuing track record of growth in knowledge).
- tonyarkles 11y ago
  That's how I handle my contracting gigs. I'm not sure if generalist is the right term for what I do; polyglot might be more appropriate. Every project I do, I'm typically brought in to accomplish something specific, which involves learning whatever that thing is down to the level where I can comfortably build and maintain a system. It's varied over the years: Django and Rails for web stuff (just recently Elixir and Phoenix), several different families of microcontrollers, C#, Java, C & C++, DSP work with software radios, OpenGL work (recently doing some intense linear algebra using shaders), etc, etc. I jokingly call myself a full-full-stack engineer: I can design circuit boards and write a web app to talk to them. It's kind of a TTT model. I've got enough experience under my belt (and did both EE and CS in school) that there's a few areas that I'm quite excellent at, and I've written code in enough programming languages that picking up a new one for a project isn't really a big deal anymore. Edit: Another thing that ends up happening when you get to a point like this is that ideas start inter-breeding. You have a client ask you about some mobile app that they've been thinking of, and you realize that there's a pretty straightforward image processing or DSP algorithm to do what they're asking about, as an example.
theseatoms 11y ago
I'm curious if Python specialists typically command the same market power. From what I understand, Python's broad set of available libraries and APIs make it somewhat more suitable for use by generalists.
- greendata 11y ago
  You'll definitely find specialists in python but they'll also be experts in specific frameworks or packages like Django/Pylons/Pyramid etc. I'd say the same thing goes for ruby...if you're a ruby expert it's almost explicit that you'll at least have an intermediate knowledge of rails.
  - pottereric 11y ago
    Agreed. The ruby expert will probably also be proficient in HTML, JavaScript, and CSS. You need a range of skills to be an expert in something.
rch 11y ago
Simply untrue. There are opportunities to join established teams of specialists looking for someone to bring it all together; perhaps to fill the role of someone senior who has moved on. Accomplished generalists are rare enough that one's starting salary should be more than competitive.
bryanlarsen 11y ago
As a contractor or job hopper you're better off as a specialist for the reasons mentioned. As a long term employee, a specialist gets stuck in one place and doesn't advance. A generalist moves around in the company, impressing people and getting raises, and helps with the valuable stuff like integrations and customer facing contacts. The CTO is a generalist, not a specialist.
- vonmoltke 11y ago
  The paradox is that if the specialist chooses correctly, they have a better shot at moving around outside their original company. No matter how my blog posts people write or discussions we have here, the vast majority of companies will still hire a one-trick pony over a generalist as long as that one trick is what they need at the moment. Hiring, like so much else in the corporate world, is far too short-sighted.
pottereric 11y ago
I agree that being a specialist is where the money is. What I was trying to show in the blog post was that the only way become a well-paid specialist is to improve your skills in the surrounding technologies. I doubt there are many developers making tons of money because they know Ruby really well. If there are making good money as a specialist, it is because the know a lot about a framework (probably rails), a communication protocol (HTTP), a design language (CSS), a plugin ecosystem (gems), and an editor. If you want to be a great specialist, you have to know the surrounding technologies as well.
- rch 11y ago
  Knowing a lot about TCP as well would make you even more of a generalist, and also more valuable.
askafriend 11y ago
I bet you most early-mid stage startups prefer generalists.
lliamander 11y ago
A number of years ago, my team hired an experienced individual who was quite invaluable to our team despite the fact that their experience was in a different problem domain and a different technology stack. The reason they were still useful was because they had a good understanding of what we might call "systems management software". That is, if you need to write software to manage a set of heterogeneous systems distributed across a networked environment, this person had a lot to offer. (Unfortunately management did not recognize this person's value to the rest of the team until they had already accepted a better job at another company, but that is a different story.) It seems that there are three different ways one can "specialize": problem domain (e.g. business accounting), solution domain (e.g. "systems management software", "data science"), or tool-set (e.g. J2EE). Each form of specialization has its trade-offs, but it strikes me that tool-set specialization is particularly likely to get one stuck working on frustratingly complex legacy systems. My attitude about specialization vs. generalization (that I think resonates with the OP) is not whether we should specialize, but when. To my mind, specialization is a necessity, and it does increase one's income, but it also incurs the risk that the specialization will become obsolete before you are ready to retire. When you look at risk-adjusted lifetime earnings[1], it seems to me that the most reasonable strategy is to delay specialization as long as possible. [1]Warning: statement made without real numbers.
- pottereric 11y ago
  As someone that specialized in Palm OS programming for a few years, I concur that there is a risk in picking the wrong specialty. But I did learn a lot in my days as a Palm OS dev. I earned the right to design and implement some really interesting solutions. I got to solve hard problems. I wouldn't have had those chances if I hadn't proven myself to be very good at what I was doing. On the other hand, my vast knowledge of the API of an obsolete OS isn't helping me much these days. I actually keep a copy of one of my Palm OS books as a reminder to never get to tied to one technology.
  - lliamander 11y ago
    That's a good point. I might phrase it thusly: in order to build up expertise within a solution space (such as doing cool mobile device applications) you end up having to stick with a particular platform/tool-set long enough so that your knowledge of the platform isn't a barrier to solving complex problems. It sounds to me like you more or less ended up doing the correct thing.

by atmosx 11y ago

kabdib 11y ago

On the other hand, a "generalist" with a couple of really deep areas of expertise can be very valuable. I like the T-shape model; able to help out in many areas, able to make significant contributions in a smaller number of areas. (I would add: And with a significant and continuing track record of growth in knowledge).

tonyarkles 11y ago
That's how I handle my contracting gigs. I'm not sure if generalist is the right term for what I do; polyglot might be more appropriate. Every project I do, I'm typically brought in to accomplish something specific, which involves learning whatever that thing is down to the level where I can comfortably build and maintain a system. It's varied over the years: Django and Rails for web stuff (just recently Elixir and Phoenix), several different families of microcontrollers, C#, Java, C & C++, DSP work with software radios, OpenGL work (recently doing some intense linear algebra using shaders), etc, etc. I jokingly call myself a full-full-stack engineer: I can design circuit boards and write a web app to talk to them. It's kind of a TTT model. I've got enough experience under my belt (and did both EE and CS in school) that there's a few areas that I'm quite excellent at, and I've written code in enough programming languages that picking up a new one for a project isn't really a big deal anymore. Edit: Another thing that ends up happening when you get to a point like this is that ideas start inter-breeding. You have a client ask you about some mobile app that they've been thinking of, and you realize that there's a pretty straightforward image processing or DSP algorithm to do what they're asking about, as an example.

theseatoms 11y ago

I'm curious if Python specialists typically command the same market power. From what I understand, Python's broad set of available libraries and APIs make it somewhat more suitable for use by generalists.

greendata 11y ago
You'll definitely find specialists in python but they'll also be experts in specific frameworks or packages like Django/Pylons/Pyramid etc. I'd say the same thing goes for ruby...if you're a ruby expert it's almost explicit that you'll at least have an intermediate knowledge of rails.
- pottereric 11y ago
  Agreed. The ruby expert will probably also be proficient in HTML, JavaScript, and CSS. You need a range of skills to be an expert in something.

rch 11y ago

Simply untrue. There are opportunities to join established teams of specialists looking for someone to bring it all together; perhaps to fill the role of someone senior who has moved on. Accomplished generalists are rare enough that one's starting salary should be more than competitive.

bryanlarsen 11y ago

As a contractor or job hopper you're better off as a specialist for the reasons mentioned. As a long term employee, a specialist gets stuck in one place and doesn't advance. A generalist moves around in the company, impressing people and getting raises, and helps with the valuable stuff like integrations and customer facing contacts. The CTO is a generalist, not a specialist.

vonmoltke 11y ago
The paradox is that if the specialist chooses correctly, they have a better shot at moving around outside their original company. No matter how my blog posts people write or discussions we have here, the vast majority of companies will still hire a one-trick pony over a generalist as long as that one trick is what they need at the moment. Hiring, like so much else in the corporate world, is far too short-sighted.

pottereric 11y ago

I agree that being a specialist is where the money is. What I was trying to show in the blog post was that the only way become a well-paid specialist is to improve your skills in the surrounding technologies. I doubt there are many developers making tons of money because they know Ruby really well. If there are making good money as a specialist, it is because the know a lot about a framework (probably rails), a communication protocol (HTTP), a design language (CSS), a plugin ecosystem (gems), and an editor. If you want to be a great specialist, you have to know the surrounding technologies as well.

rch 11y ago
Knowing a lot about TCP as well would make you even more of a generalist, and also more valuable.

askafriend 11y ago

I bet you most early-mid stage startups prefer generalists.

lliamander 11y ago

A number of years ago, my team hired an experienced individual who was quite invaluable to our team despite the fact that their experience was in a different problem domain and a different technology stack. The reason they were still useful was because they had a good understanding of what we might call "systems management software". That is, if you need to write software to manage a set of heterogeneous systems distributed across a networked environment, this person had a lot to offer. (Unfortunately management did not recognize this person's value to the rest of the team until they had already accepted a better job at another company, but that is a different story.) It seems that there are three different ways one can "specialize": problem domain (e.g. business accounting), solution domain (e.g. "systems management software", "data science"), or tool-set (e.g. J2EE). Each form of specialization has its trade-offs, but it strikes me that tool-set specialization is particularly likely to get one stuck working on frustratingly complex legacy systems. My attitude about specialization vs. generalization (that I think resonates with the OP) is not whether we should specialize, but when. To my mind, specialization is a necessity, and it does increase one's income, but it also incurs the risk that the specialization will become obsolete before you are ready to retire. When you look at risk-adjusted lifetime earnings[1], it seems to me that the most reasonable strategy is to delay specialization as long as possible. [1]Warning: statement made without real numbers.

pottereric 11y ago
As someone that specialized in Palm OS programming for a few years, I concur that there is a risk in picking the wrong specialty. But I did learn a lot in my days as a Palm OS dev. I earned the right to design and implement some really interesting solutions. I got to solve hard problems. I wouldn't have had those chances if I hadn't proven myself to be very good at what I was doing. On the other hand, my vast knowledge of the API of an obsolete OS isn't helping me much these days. I actually keep a copy of one of my Palm OS books as a reminder to never get to tied to one technology.
- lliamander 11y ago
  That's a good point. I might phrase it thusly: in order to build up expertise within a solution space (such as doing cool mobile device applications) you end up having to stick with a particular platform/tool-set long enough so that your knowledge of the platform isn't a barrier to solving complex problems. It sounds to me like you more or less ended up doing the correct thing.