Platform generalists versus framework specialists
A trend I’ve noticed especially in Javascript/front-end jobs are emphasizing, requiring, even titling jobs after specific Javascript frameworks. “Ember.js engineer needed”. “Angular programmer”. This raises a few of thoughts for me:
- Is the framework so complicated you need someone with extensive experience building non-trivial apps?
- Is your timeline so short you don’t have time to teach anyone a framework?
Earlier in my career, when WPF was announced, I had a choice to invest time in my career to learning it. It was the obvious successor to WinForms, and *the* way to build thick-client apps in .NET, if not Windows going forward. I hesitated, and decided against it, after learning more about the technology and seeing how proprietary it was.
Instead, I doubled-down on the web, learning server-side frameworks to help build web apps more than ever. ASP.NET MVC embraced the web, unlike WebForms, which had its own invented abstractions. All the WebForms knowledge I had is more or less wasted for me, and I vowed to never again become so engrossed with a technology that I become specialist in a framework at the expense of understanding the platform it’s built upon.
I don’t want to be an “Ember” guy, an “Angular” dev, an “Aurelia” expert. I want to be a web expert, a messaging expert, a REST expert, a distributed systems expert. I saw this most clearly recently when helping out on a Spring MVC project. Because I understood web platforms, I could pick up the framework easily. The parts in Spring that were hard were hard because of the complexity of the framework, and those were parts I was a lot less inclined to be an expert upon.
One of the biggest reasons I’ve shied away from new, all-inclusive, heavyweight frameworks is it’s a tradeoff for me of potential productivity and administrivia knowledge. I’ve only got so much room in my head, and I’d much rather it be occupied with more important things, like vintage Seinfeld/Simpsons quotes.