Let's be realistic.. let's say you are a c++ programmer and want to learn some modern JS framework. I bet you it will literally take less than a week of concentrated study work for you to become better than 80-90% of people working with it. You can get a book on the subject, there's great tutorials, heck, just reading the reference will get you far.
This is true for a lot of stuff on youtube, coursera etc. I believe. It's for people who don't want to get to the destination faster, by reading a few books and doing the exercises in them.
I've worked in both of these kinds of domains and different kinds of people thrive at doing each. The kind of problems you face are different.
Most of the backend C++ types I've worked with aren't so great at "design for failure" types of environments whereas on the web development side of things I've found people are much more receptive.
I'm working with a few hundred backend engineers who all have a hard time with thinking infrastructure is always available and can handle infinite throughput. They absolutely stink at reasoning about the network. And these aren't dummies -- they're all MIT/Waterloo/etc grads.
> I'm working with a few hundred backend engineers who all have a hard time with thinking infrastructure is always available and can handle infinite throughput.
Could you clarify this statement? Are you saying you work with hundreds of backend engineers:
- who all believe infra is always available and can handle infinite throughput (???)
or
- who can't wrap their head around an environment where infra is so scalable / high availability that it might as well be "infinite" and so they are always looking designing for tradeoffs that don't exist in your environment?
If the former, where do these people work? If the latter, where do these people work?
I know there are plenty of engineers with those gaps, and they learn from experience, as one does.
My issue was with the statement that all backend engineers you work with (hundreds of them!) have this weakness. Does not match my experience, so I was wondering where you work.
The barrier to entry is not the availability of materials, it's the jargon and working knowledge of the ecosystem required to find those materials and decide which are worth your time.
I've been the C++ programmer with a week to learn a modern JS framework. I'll never do that again, and will always hire an expert to bring myself and a project up to speed. It's a massive waste of time and money.
You also won't be "better" than anyone else at it, since expert-level C++ knowledge is not very translatable to other domains (but that's a C++ problem more than anything, working in it is like playing a piano and not riding a bike).
Why on earth would you think that? C++ programmers are not “better” than web developers. They work in very different domains, and skills built up in one don’t necessarily transfer to the other.
C++ has a high barrier because it exposes the inherent complexity of computing. If you've managed to fight through that you can probably pick up the simplified concepts in Javascript, Python, Ruby, etc.
All the non trendy languages have loads to teach, even TCL forums were full of surprises. Perl talks (say damian conway on perl6/raku grammar traits) are so infinitely better than 80% of any trending topic.
I think it’s the same process, just at a higher velocity.
Jobs have always been at risk of obsolescence. Jobs either require continual learning (typically the “professions”, e.g., physician, lawyer,...) or were at risk for being irrelevant. In the past, the pace of irrelevance was often slow enough to span a lifetime or multiple generations so people could still make a (slowly dwindling) living. Now the turnover just seems much faster that irrelevance can come at multiple times in ones career.
What’s the quote? “There future will belong to those who learn, unlearn, and relearn.”
I agree, but think that statement does a disservice to programming by treating it as a monolithic domain. It’s telling a mechanical engineer “mechanical things will never deprecate”. That’s true, but doesn’t help the ME whose career may have been built in, say, a fossil fuel power plant.
I have a feeling that anybody in physically based engineering will never lose use of his knowledge. You don't spend time using trendy inventions at the pace of computing. Many programmers fiddle with plumbing onto <framework-of-the-day> until they get a new position. Not a lot to remember beside social reflexes and 'best practices'.
The pace is certainly different but I’ve found most engineers lose those skills that aren’t directly relevant to their job at hand. Ask that power plant engineer to do fluid dynamics and they’d likely be lost. The physical engineering disciplines are often hyper-specialized as well
Sure you forget but if you come into a fluid dynamic problem, you know that the universe didn't move to a new paradigm, I assume it's a different feeling to know that you can revisit the knowledge instead of navigating a totally new structure.
I’ve found Engineering to be similar. A relatively small percentage of engineers are actually crunching numbers in the academic sense. Most of the work is around learning a limited number of tools that may not translate effectively into another position
Wow. That article starts with "programmers continually learn new technologies" and does a kickflip at the end into "so bootcamps are good". I admire the skill of whoever wrote that, but ugh - what a nasty piece of PR.
