
Should Custom Software Developers Be Generalists or Specialists? - pottereric
http://blog.apterainc.com/custom-software/should-custom-software-developers-be-generalists-or-a-specialists
======
beat
My mother says a specialist is someone who knows more and more about less and
less until they know absolutely everything about nothing, and a generalist is
someone who knows less and less about more and more until they know absolutely
nothing about everything.

~~~
icehawk219
Also summed up in the old saying: "A jack of all trades, a master of none."
The world needs both in different places at different times.

~~~
metafunctor
While these sayings are fun, and sort of true, they are kind of not useful.
You should be a jack of various trades, a master of some. Specialization is
for insects :)

~~~
beat
Something I've learned from the Dreyfus Model of Skill Acquisition is that
once you achieve expertise/mastery at a skill, it becomes much easier to learn
other skills at the competent/proficient level. In other words, you learn how
to learn, when what you're learning is hard and requires much effort.

Having achieved expertise/mastery at a couple of different things (software
deployment, guitar playing, other things), I find all sorts of common patterns
between these seemingly unrelated skills, patterns I can then reapply for
other skills. For example, being an improvisational musician has made me
keenly aware of the passage of time, and immutable deadlines - an awareness
that helps me with every other skill that involves the passage of time.

~~~
pottereric
There are many interesting ways that the Dreyfus Model of Skill Acquisition
could be applied to the ideas in the blog post. There should be a few areas
where you are an expert, a handful of things you should know at a proficient
level, many things you should know at a competent level. You should be
expanding the number of things in which you are an advanced beginner.

I also like what you said about your knowledge of music was useful to your
programming skills. Being well-rounded individuals can make us better
specialists.

------
sirgawain33
I've been partial to Heinlein's idea of the "general specialist" lately:

"Computermen sent up to install Mike were on short-term bonus contracts— get
job done fast before irreversible physiologlcal change marooned them four
hundred thousand kilometers from home. But despite two training tours I was
not gung-ho computerman; higher maths are beyond me. Not really electronics
engineer, nor physicist. May not have been best micromachinist in Luna and
certainly wasn’t cybernetics psychologist. But I knew more about all these
than a specialist knows—I’m general specialist. Could relieve a cook and keep
orders coming or field-repair your suit and get you back to airlock still
breathing."

from _The Moon is a Harsh Mistress_

~~~
vcarl
Similarly, another quote from him that always resonated with me:

"A human being should be able to change a diaper, plan an invasion, butcher a
hog, conn a ship, design a building, write a sonnet, balance accounts, build a
wall, set a bone, comfort the dying, take orders, give orders, cooperate, act
alone, solve equations, analyze a new problem, pitch manure, program a
computer, cook a tasty meal, fight efficiently, die gallantly. Specialization
is for insects."

------
jedberg
This essay focuses only on expanding knowledge within programming and
business, but I think to truly be successful, you need to generalize outside
of programming too.

My favorite example that I like to repeat often is that as a Site Reliability
Engineer, more than once my knowledge of sports, entertainment, politics and
current events have been quite relevant to my job.

When we were trying to figure out why people suddenly stopped watching Netflix
in Mexico and Brazil, it was important to know that there was an exhibition
match in Soccer/Football between the two countries, and knowing that that was
culturally important and something that they would be using the TV for instead
of Netflix.

~~~
pottereric
Good point. It helps to be well-rounded in general, not just in technology.

To be fair, if you work for Netflix, entertainment is part of your business
domain. One of the things the article highlights is the importance of knowing
the business domain for your customers/clients.

~~~
jedberg
> To be fair, if you work for Netflix, entertainment is part of your business
> domain.

That's true. But politics isn't really part of that, but came in handy
(knowing when the President was making a big speech or another country was
having an election or debate, for example).

~~~
toyg
_> But politics isn't really part of [entertainment]_

That's a very naive view of politics :) -- if you think I'm just being a
smartass: Reagan, Berlusconi, Trump, Schwarzenegger, Trudeau, Paquiao,
Blair... the list of politicians who were entertainers before getting into
politics is _huge_ and getting longer (and more popular) by the day.

~~~
jedberg
That only became true when politicians started appearing on TV. They even
touch on this in Back to the Future. When the only thing people knew of
politicians was via printed word, and later radio, no one cared what they
looked like.

------
dasil003
In other words, the importance of being T-shaped:
[https://en.wikipedia.org/wiki/T-shaped_skills](https://en.wikipedia.org/wiki/T-shaped_skills)

~~~
pottereric
That is the exact concepts I was going for. I had never heard that terminology
until I read your link. Thanks for the information. I still like the concept
of a topo map because I believe that the skills nearest your specialty or more
important than those that are further away. A T just indicates that you have a
specialty and the your have broad knowledge.

------
atmosx
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_.

~~~
lliamander
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
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
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.

------
p4wnc6
I agree with this advice, and especially the follow up comments about being
well-rounded in general.

But one thing I hate is when a business or a manager tries to politicize this
whole "t-shaped skills" buzzword, by arguing that importance of generalist
skills entitles the business or manager to almost completely disregard
someone's specialization.

If you hired someone as a machine learning expert, and instead you've got them
working on a legacy Ruby on Rails codebase or going down some rabbit hole
about containerization, then it's gone too far. Yet politically, this will be
defended endlessly in the name of "team player" and "business bottom line" HR
code words.

But specialization of labor is hugely important to society. We need people to
be deep experts, and for the trend of getting deeper and deeper into a field
to continue, and well-defined roles within an organization are important for
this. And yes, this does require managers and planners to work very hard to
actually understand the business's needs, so that they can hire a machine
learning engineer when they need one, instead of hiring one, then trying to
repurpose the engineer into a Rails engineer by appealing to "be a team
player" nonsense.

Any way, I think it's just important that as good as generalization, well-
roundedness, and basic curiosity are, developers and knowledge workers
especially have to be really pedantic and adamant that businesses respect
specializations. Don't let the politicization of "be a generalist" get used as
an excuse for your employer to stop respecting your specialization.

This is a major reason why I dislike the trend of "full-stack" development.
It's great when developers really do have full-stack skills. But it's a huge
red flag about a company when they actually want, and encourage, people to
work in an essentially purely generalist capacity. It can often mean the
company is either trying to get by cheaply (i.e. they're happy with relatively
lower quality work from a generalist working in a specific area that is not
the generalist's specialization) instead of seeking higher quality solutions
through the appropriate specialists, or else they are just not doing the hard
work of actually mapping their business needs correctly onto the skills that
different specialists have, meaning that "full-stack" is just a hiring
buzzword to avoid hard work somewhere up the staffing foodchain, and build in
plausible deniability when it doesn't work out (e.g. "But we hired full-stack
people...").

~~~
danieltillett
I think there is a difference between hiring someone as a machine learning
expert with the intent of having them work as a ROR maintainer and hiring the
person and asking them later when an urgent need comes up. If you are a small
company growing rapidly it is impossible to anticipate all future needs in
advance. This means on occasion you get mismatched between skills and needs.

~~~
p4wnc6
If this happens once or twice and gets resolved quickly, then sure it's OK. It
can happen, and even if "team player" is often misused as a politicized HR
code word, most of us developers still do want to be team players in the real
sense, and so helping out is not a problem.

But if the issue lingers over time, either because the small company doesn't
want to foot the bill to hire an appropriate specialist, or because the
company tries to paper over the wrongness of the on-going situation by acting
like this sort of "team player" working-outside-my-speciality-because-someone-
claims-it's-urgent status is just "how start-ups work" or "that's just start-
ups" or "everyone's got to wear many hats" or whatever other bullshit, then
that's a huge red flag.

It means that not only did the company fail to plan for its needs (which
should be some cause for concern, but not catastrophic since start-ups are
hard), but even more, _after_ learning that they didn't plan staffing
correctly, instead of considering the deleterious burnout effects it might
have on a specialist to force them to work way outside their area for
prolonged times, the company just doubles down on it and even tries to build
their company culture around it, as if "just do what you're told, no matter
how hilariously far off it is from what we said you'd be doing" is a
centerpiece of company culture, and indeed that somehow that's "just how it
is" at any start-up.

So, even if there is no intentional deceit or planned bait-and-switch, it's
_still_ a big red flag if this happens a lot and/or doesn't get resolved
quickly.

If you are a specialist, any employer who doesn't care enough about your
specialty to be sensitive to the request to make you work way outside of it is
really bad news for your career, unless you have other reasons for wanting to
work there that, for you personally, supersede however much you value career
progress in your chosen specialty.

At the very least, companies should be apologetic about this when it happens,
and should really work to find a compromise that doesn't cause burnout or
create big gaps of time on an employee's work history during which the
employee is not gaining experience related to their actual career specialty.
If managers can admit the situation is not ideal, and level with you about the
business emergency causing it, that's somewhat better (though still not an
excuse for it to linger on for a long time). But if the business can't be
bothered to admit they are doing something _really_ suboptimal, something
specifically fucking with your career progress and ability to gain experience,
then it's probably time to just move on to another job. The company's not
showing you any loyalty at that point, but they are expecting a pretty extreme
form of loyalty and trust on the engineer's part.

~~~
danieltillett
It is defiantly a problem if a company does not learn and adapt to changing
needs. It is an inefficient use of resources and ultimately will lead to
developer churn if allowed to continue.

Companies do have problem recruiting people to do the work that needs to get
done verses the work developers want to do. Maintaining old code is not
popular and getting good people to do this is hard. This is no excuse for
engaging in bait-and-switch tactics though.

~~~
vonmoltke
I think a lot of companies are shooting themselves in the foot in this
respect. They bias themselves towards people with visible portfolios of
greenfield work, then hire them to do maintenance. Not only does this select
negatively for the type of person who would be good at maintenance, it also
sends the signal that maintenance is a career dead-end.

~~~
danieltillett
Does anyone want to maintain old code as a job?

I agree that there is a major issue between what companies say they want and
what they actually reward people for. Be a team player and work on code
maintenance, but when we promote or recruit we want a “rock star” who has 100
projects on GitHub.

~~~
vonmoltke
> Does anyone want to maintain old code as a job?

I actually think it's really fun. Of course, my attraction to engineering has
always been to figuring out how things work and making them better.
Unfortunately, most maintenance is just ticket-punching. I love the kind of
maintenance that is "find a way to speed up the critical path in X" or "find
the source of the intermittent crash in Y" rather than "change every
occurrence of FONT_COLOR='#239a11' to '#239a33'".

~~~
p4wnc6
I take this even further. I think _all_ maintenance should be framed by the
business as:

> _What ideas do you have about how the solutions to these specific bugs
> /tickets/requests can simultaneously improve the existing system, even in
> ways unrelated to the specifics of the bugs/tickets/requests. How can we
> give business priority to those ideas?_

The difference is that if you challenge someone to not just meet a minimal set
of criteria to "solve" a bug/ticket/request, but to use their wits to go
further and not just solve it, but solve it in a way that creatively improves
things around it too, then they'll be way more engaged. Almost all studies on
this sort of thing have shown that you get higher quality work, people work
_faster_ in this set up, and they generally report feeling satisfied about it.
This was a big part of the book Peopleware, where it talks about how in
software at least, the notion that you have to trade-off speed of
implementation against quality of implementation is a total myth -- just not
borne out of any data measuring task completion time, degree of spec
completeness, and bugs.

To me, things like Agile tend to get politicized in a company and then get
misused, to the point where rote emphasis on minimally clearing tickets ruins
any chance to let people be creative about _how_ they solve maintenance
issues.

And at the end of the day, even if you have great system architects, usually
it is the maintenance developers who have really seen the nitty gritty of the
codebase and have the most intuition about good refactoring design choices.

------
metafunctor
You should be enough of a generalist to understand how your part fits into the
whole. You also need to be enough of a specialist to do your part really,
really well.

Also, get into several specialities as you move along on your career. I'm
almost 40 years old, and can list quite a few specialities in my resume.

------
ykumar6
Think of your career as being a generalist, but learn things like a
specialist.

You want the opportunity to work on a wide array of problems so you build a
repertoire of solutions and insights that can be applied to various problems.

Being a full-stack engineer is a great place to start, but it's limiting
because you never gain enough depth beyond plugging together front-end, back-
end and off-the-shelf components.

Instead, you want to rotate between various roles so you can focus on
different areas. This way you can understand the pitfalls and best practices
of certain systems (like infrastructure, queues, machine learning, angular,
etc).

------
beat
Another specialist/generalist vector I've encountered... at a lot of startups,
they're looking for a "full stack developer" (generalist). Which is fine when
staff is limited. But when you're a big company and you have a product that
costs a thousand dollars a minute when it's offline and the database crashes,
who do you want looking at the database... the girl who's lived and breathed
nothing but Oracle for the past 15 years, or that full stack dude?

------
lnkmails
You'd never to go to a neurologist to get a ACL reconstruction. In other
professions, specialization is seen more respectfully and also pretty vital.
Whenever I interview with startups, I get a feeling they want "generalists"
because they need to get the same amount of work without hiring a lot of
people. I'd personally prefer specialists but are inquisitive enough to jump
on random things and can move the boat without waiting for someone.

~~~
zaidf
Another reason startups prefer generalists is that at the early stage, you
don't know what specialists you may require. As a general rule, the later the
stage of the company, the more specialists you will find. For example, you
will find people at google whose only job is to make icons for a very specific
screen. The same task at a startup may be done by the founder or really anyone
who wants to take a stab at it.

~~~
p4wnc6
One problem with this that many orgs face is that later down the road when
your business has grown, now you need to hire a lot of specialists (usually in
a big hurry), and in fact at that point hiring the new specialists often
matters way, way more than continuing to take care of the generalists who got
you to that point.

On one hand, if you defer to the market, you'll end up being forced to pay
high wages to those later-on specialists, and probably also more equity than
would otherwise be warranted for their time of entry to the firm. Lots of
early-on generalists could get mad that they aren't paid well and that even if
they have more equity, it's not fairly proportioned to how much up-front work
they put in.

On the other hand, if you don't agree with this market problem, then you end
up hiring only specialists who don't know how much they are worth, or else
have other factors that make them cheaper to hire -- generally meaning you
hire crappier later-on specialists to save money and to keep the equity
proportions "fairer" to the early-on generalists. These firms often get a bad
reputation for doing crappy work in the specialist area, and specialists stay
away from it.

I see this _a lot_ with machine learning. A smart machine learning specialist
is not going to join a Bay Area start-up for $150k and 0.1% equity as employee
number 40. If you waited until employee 40 to start investing in highly
specialized machine learning talent, and it's something your business needs,
then you're either going to have to raise the wage super high (much higher
than the early-on employees who may resent this), or you're going to have to
offer completely disproportional equity, or both; or else, you're going to
have to hire inexperienced and/or crappy people who don't mind taking a job as
employee #40 for that kind of "conventional start-up wisdom" pay/equity range.

To me, this suggests one hypothesis is that start-ups preferring generalists
is actually a bad idea. Instead, they should excel at forecasting which
specialists they'll need, then hire the best of that speciality very early on.
To entice them to put up with generalist work for a while, pay them a lot or
give them better than market equity, and be as flexible as possible with what
kinds of working style / environment you offer them.

Then when the time comes to really turn up the heat on specialist labor,
you'll already have the specialists, and they'll already know how the systems
work. At that point, you can expand hiring on the generalist front, which
should be relatively easier to do at the current start-up wage level, and have
those later-on generalists take over the maintenance and generalist work from
the early-on specialists.

This is way easier said than done, of course, but it would be interesting to
see whether there's a relationship between start-ups that succeed and start-
ups that choose to specialize early and generalize later. Most start-ups fail,
and anecdotally, most start-ups also seem very inflexible about accommodating
what an early-on specialist might want (like say, to avoid working in Agile or
to work in a quiet office) and seem more geared toward hire pools of
generalists (mandate team-wide Agile, have lots of social outings, use open-
plan offices). Maybe this is a big part of going wrong?

~~~
zaidf
Problem with that is most specialists suck or have very little interest in
generalist work.

People became specialists because they particularly enjoy that kind of work.
When you put them in an environment where things are changing rapidly,
including their day to day nature of work, in my experience most specialists
don't respond well to it.

I actually think hiring too many specialists is one of the biggest mistakes
early stage startups can make.

~~~
pottereric
The other factor to consider here is that not all specialists are focused on a
technology. Some specialists focus on a process or a business domain. If a
startup is working on financial software, finding someone that has a deep
knowledge of finance software might be incredibly valuable. This could be very
true if your software needs to meet regulatory requirements like Sarbanes
Oxley.

~~~
zaidf
I assumed the context here was developers. For other kind of specialists, they
can be INSANELY valuable from the get-go. In fact, one of the first hires I'd
recommend anyone doing enterprise startup is hiring a domain specialist. These
people are relatively inexpensive and add tremendous value in giving product
feedback between early iterations. They can also talk to early customers with
more credibility and thus help adoption of certain features that the customer
may other not see much value in.

~~~
pottereric
Actually, I was talking about developers. In my experience working on projects
that needed FDA part 11 compliance, it can be incredibly helpful to have
developers that know how to write software that meets to compliance rules from
process, validation, and auditability standpoints. I presume the same is true
for SOX or HIPPA.

------
dpweb
Short answer - between the two - specialize is superior.

If money matters to you - its easy to figure - hrs x price. Your price
generally is higher if you specialize. Best thing is to be a rare bird -
expert in something very valuable that few people can do.

You can eat good just doing basic web dev (for the time being at least), but
if you're very ambitious - to really outperform - you'll want to be more
special than that.

------
je42
T-Shape knowledge is the buzz word.:)

------
dustingetz
i think the best specialists have more general knowledge than most generalists

