4 ms·
I think there's some dynamics at play here that obscure the situation. First of all, there's a tendency for depth engineers to be more visible. But this is ext
by lordnacho 6y ago
I think there's some dynamics at play here that obscure the situation.
First of all, there's a tendency for depth engineers to be more visible. But this is extreme; there's a handful of top names in StackOverflow for a tag like csharp or django, but that doesn't mean number 1000 in a given tag is an amateur at it, he's likely pretty good. Similarly, not everyone writes respected blogs, but the people who do tend to be ones who spent a heck of a lot of time in one niche. That doesn't mean you need a known blogger for your project.
Second, there's a tendency for hiring firms to want a dev fully trained in some vertical. This may sound sensible but often isn't. If you have some person who did a lot of work in RoR, but you have a Py/Django project, couldn't you expect him to get up to speed reasonably quickly? I think in a lot of cases, yes. Whether you'll be allowed to take that risk depends on the situation, and often you won't be. This works the other way too: a lot of devs will decide not to bother applying.
Third, diminishing returns. Like a lot of knowledge stuff, there's a sort of pareto principle here. You can learn most of anything in way under half the time to learn the whole thing, if that's even possible. If your project is not super specialized in one vertical, but still requires a lot of verticals, you benefit from having a guy who knows a lot about a lot of stuff.
- bogwog 6y ago> If you have some person who did a lot of work in RoR, but you have a Py/Django project, couldn't you expect him to get up to speed reasonably quickly? I wonder what is the average time for an experienced engineer to transition into a different, but similar technology (like RoR -> Django) and be able to work productively in it. It can’t be very long. Maybe 2 weeks? If you had a number, you could calculate the costs as part of a standard onboarding process. You’d just need to make sure that you hire someone who can demonstrate a willingness to learn the new thing. This seems like it could be much cheaper than hiring an expert with the most years of experience in the particular combination of technologies in your stack, without compromising on quality. And the perspective from someone with a breadth of knowledge is more likely to yield innovations that provide your company/project with a competitive advantage, compared to the expert that has been working on the same thing for many years.
- drzaiusx11 6y ago> I wonder what is the average time for an experienced engineer to transition into a different, but similar technology (like RoR -> Django) and be able to work productively in it. As someone who's done this probably too many times (Perl cgi -> cakePHP -> Play framework -> Spring -> Node.js/Express -> Flask -> Sinatra) I'd say your two week estimate sounds about right, at least given my personal experience. After switching you quickly notice patterns and apply your past experience from other languages and frameworks. After a few weeks to a couple months you produce idiomatic code indistinguishable from your peers. And those examples are just web framework transitions. As someone with not enough sense to stay put, I've wandered as far as: * embedded C and assembly for microcontrollers * writing kernel modules and device drivers * designing, programming and assembling custom hardware (pcbs, enclosures) * writing mobile applications (iOS/hybrid) * being a frontend engineer (jQuery -> moo -> knockout -> backbone -> redux+react) I've jumped fields from robotics research, social networking, healthcare, fintech, and consumer electronics. It's been a wild ride and looking back I honestly wouldn't change much in hindsight. As a generalist I work best on the early side of projects where I end up "wearing lots of hats." 'Tend to stick to a place for 5 or so years until everyone becomes specialists, then move on. As you say though the key is the willingness to learn. As far as your point on generalists being cheaper than experts--I've found that pay honestly has more to do with soft skills than "expertise." (Good communication, self advocacy skills, etc.)