
A generalist software engineer can learn ${buzzword} - lambdabit
There are a lot of frustrating things when it comes to the hiring process. But by far the most frustrating thing is the obsession by recruiters to categorize engineers by a trendy framework, language or buzzword. React engineer, Java engineer, data engineer, Ruby ninja, and so forth.<p>The problem with this sort of categorization is that it&#x27;s trivial to learn another framework or language for a generalist. It takes a week or two to get up to speed in a ${buzzword} while it takes much longer to become proficient in programming fundamentals. Things like object oriented design, algorithms, systems design, architectural patterns, debugging, etc.<p>In fact, it is likely that a strong generalist can outperform say a &quot;Ruby ninja.&quot; A strong generalist can create reusuable modules that are easy to understand, maintain, test, and extend. Meanwhile, the ability to use a slightly shorter syntax in Ruby provides minimal benefits.<p>I suspect the reason why this categorization exists is because it&#x27;s unnerving to think that a generalist can outperform a specialist. It&#x27;s similar to how the theory of multiple intelligences was conceived because general intelligence is scary. Regardless, it&#x27;s a silly idea and it would be great if engineering orgs can realize the potential of generalists.
======
hinkley
I was listening to some interview or podcast about a year ago and the line
that really struck me, in the "I've always known this but didn't have the
words" sort of way, was this:

How ages faster than Why.

Many of the tools we use are trying to wrestle with the same set of problems
we've been dealing with since at least the early 90s. Physics and Information
Theory don't change just because you found a new syntax for a programming
language. Most of the 'novel' concurrency models people plow into their new
framework were all documented by Tony Hoare over a five year period in the
70's.

And all of these libraries, with rare exceptions, are building over the same
set of wire protocols and OS abstractions.

The challenge for any of us is staying committed to the work. You can get
their by learning perseverance, or trick yourself into it with zeal. Amp
yourself up with regrettable levels of excitement and dive in head first. But
if you take that option, you're going to spend your whole career running from
one thing to the next, until you get some perspective or get out.

Zeal is made uncomfortable by ambivalence, and it _hates_ dissent.

The hard part is not learning the new way to do the same thing. Chesterton's
Fence has your back. The hard part is telling an interviewer that what they're
doing isn't all that novel without them getting offended or labeling you a wet
blanket. But how else do you convince them you can come in 'cold', as they see
it, and contribute, because it's not cold. The future is already here, it's
just unevenly distributed.

I have a million things I want to get done that I only rarely get to work on
because we're so busy dealing with distractions. I don't need buzzwords to do
any of it, but I do need progress, and that's hard to find when everyone is
running in circles.

------
coolbreeze
Can a generalist learn anything and write clean code... yes. Will they
understand the nuances and history of a large frameworked codebase as quick as
someone with the specific experience... No. Why hire someone without the
experience if you don't need to? Learning a framework ecosystem can take a lot
of time. Available libs, best practices, coding style, dev practices,
deployment practices, etc... If it takes and extra six months that's
expensive.

------
borplk
The main reason for this is that most people/recruiters/companies are too lazy
and uncaring and incompetent to identify the better candidates without relying
on buzzwords.

Chasing buzzwords is the path of least resistance.

It's also a little bit like "nobody got fired for buying IBM".

Insecure recruiters/organisations who have no ability to use other means of
identifying good engineers rely on the perceived safety of finding "$buzzword
ninja".

If things don't turn out too well and a generalist was hired it's easy to
blame the people involved with "you obviously hired someone who had nothing to
do with this".

There are two categories of companies that tend to avoid this. One is tiny
smart startups with savvy founders.

The other is giants with strong engineering culture like Google and Netflix
who have the resources and the will and the long term incentives to prioritise
finding good employees over buzzword matching.

------
cylim
It is hard to prove that you can learn fast.

If you can learn the buzzword framework in 2weeks, then you should be able to
fool the HR in day one and perform good enough in the technical interview.

Besides that, if the company insist on the buzzword, it won't be a suitable
company for you... :)

