A generalist software engineer can learn ${buzzword}
4 コメント
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.
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.
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.
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.
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.
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... :)
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... :)
The problem with this sort of categorization is that it'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.
In fact, it is likely that a strong generalist can outperform say a "Ruby ninja." 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.
I suspect the reason why this categorization exists is because it's unnerving to think that a generalist can outperform a specialist. It's similar to how the theory of multiple intelligences was conceived because general intelligence is scary. Regardless, it's a silly idea and it would be great if engineering orgs can realize the potential of generalists.