3 ms·

I disagree with respect to frameworks like React, Angular and Vue. Yes, they all "do the same thing" when viewed from a distance, but up close the details of sa

I disagree with respect to frameworks like React, Angular and Vue. Yes, they all "do the same thing" when viewed from a distance, but up close the details of say, managing state with hooks in React, is very different from managing state with services and RxJS observables in Angular. These differences aren't always sexy, but understanding them is usually the difference between a developer who can deliver a high-quality solution and solve difficult problems and one who can hack together something that sort-of works with enough Googling. In my experience, a lot of "overengineering" in these kind of frameworks is really devs with insufficient understanding of their details inventing unnecessary workarounds and abstractions. So, yes, devs flitting between frameworks is a problem, but not because they're doing the wrong kind of learning, but because they never learn enough to be truly effective. And I don't think this is a result of some pervasive attentional deficit, but because hiring practices, especially in consultancy, favour direct commercial experience above everything, and devs are economically incentivised to maximise their earning potential and pool of job opportunities by working with as many technologies as possible.

mkagenius 6y ago
> high-quality solution and solve difficult problems and one who can hack together something that sort-of works with enough Googling Are you assuming enough Googling can't produce high quality solution?
- BigJono 6y ago
  Yes that's an absolutely sound assumption when it comes to web development. The vast majority of resources are written by people that fall into the exact category stupidcar described, with superficial knowledge of the libraries they're using. If anything, Googling gets you further from the simple, clean solution a lot of the time unless you're already experienced and can sift through the bad sources of information.
BigJono 6y ago
Understanding the differences is only important if you're hopping jobs to a different tech stack though. Which is why the 'following the market' reason is mostly bullshit if you live in a good city and didn't pick something originally that's gone the way of the dodo. You may open yourself up to more opportunities by being familiar with multiple front-end frameworks, but you're going to be a worse fit for a lot of them, because if my stack is React and Django, why on earth would I hire a veteran React dev that has spent 3 months learning some Vue instead of some Django? Or AWS? Or anything else that I could possibly have in my stack. You're basically resigning yourself to hitting only one checkbox, when there's other candidates out there that can hit more. The big front-end frameworks are far from the most egregious examples too. You raised a great point about people not learning enough to be effective. I'm a big fan of React, but it's ecosystem has a massive problem with this. People are so dependency crazed that every single dev has experience with 10 out of the 200 commonly used dependencies and it's always a different 10 to whatever is being used on the project. Most team's solution to this is to crank their package.json up to 100 dependencies so everyone can feel at home, and everyone goes on these fucking odysseys of superficially learning a ludicrous amount of APIs other people have written without ever producing anything meaningful themselves.
crimsonalucard1 6y ago
>but up close the details of say, managing state with hooks in React, is very different from managing state with services and RxJS observables in Angular. I would say learning the detailed difference when needed for the project is in fact extremely trivial. The wrong kind of learning is thinking that you're improving your skills by memorizing and learning all of these details even when it is not required by your current project. I would say max it takes about 2 weeks to a month for a developer to get good with react. It's not even a big deal if you think about it, but hiring managers still look for "relevant experience." Don't learn the details unless it's relevant to the project. To improve your overall skills as a developer: Learn the fundamentals. Though I have noticed one thing. Many recruiters and even technical hiring managers are buzzword driven. Buzzwords are often related to details so to pad your resume you have to learn the details. Ultimately though, if you end up never touching that detail or that detail changes then you wasted your time learning it. Learn the fundamentals because the fundamentals never change. Honestly you're the kind of developer that the OP is talking about, but then again most developers are like that.

mkagenius 6y ago

> high-quality solution and solve difficult problems and one who can hack together something that sort-of works with enough Googling Are you assuming enough Googling can't produce high quality solution?

BigJono 6y ago
Yes that's an absolutely sound assumption when it comes to web development. The vast majority of resources are written by people that fall into the exact category stupidcar described, with superficial knowledge of the libraries they're using. If anything, Googling gets you further from the simple, clean solution a lot of the time unless you're already experienced and can sift through the bad sources of information.

BigJono 6y ago

Understanding the differences is only important if you're hopping jobs to a different tech stack though. Which is why the 'following the market' reason is mostly bullshit if you live in a good city and didn't pick something originally that's gone the way of the dodo. You may open yourself up to more opportunities by being familiar with multiple front-end frameworks, but you're going to be a worse fit for a lot of them, because if my stack is React and Django, why on earth would I hire a veteran React dev that has spent 3 months learning some Vue instead of some Django? Or AWS? Or anything else that I could possibly have in my stack. You're basically resigning yourself to hitting only one checkbox, when there's other candidates out there that can hit more. The big front-end frameworks are far from the most egregious examples too. You raised a great point about people not learning enough to be effective. I'm a big fan of React, but it's ecosystem has a massive problem with this. People are so dependency crazed that every single dev has experience with 10 out of the 200 commonly used dependencies and it's always a different 10 to whatever is being used on the project. Most team's solution to this is to crank their package.json up to 100 dependencies so everyone can feel at home, and everyone goes on these fucking odysseys of superficially learning a ludicrous amount of APIs other people have written without ever producing anything meaningful themselves.

crimsonalucard1 6y ago

>but up close the details of say, managing state with hooks in React, is very different from managing state with services and RxJS observables in Angular. I would say learning the detailed difference when needed for the project is in fact extremely trivial. The wrong kind of learning is thinking that you're improving your skills by memorizing and learning all of these details even when it is not required by your current project. I would say max it takes about 2 weeks to a month for a developer to get good with react. It's not even a big deal if you think about it, but hiring managers still look for "relevant experience." Don't learn the details unless it's relevant to the project. To improve your overall skills as a developer: Learn the fundamentals. Though I have noticed one thing. Many recruiters and even technical hiring managers are buzzword driven. Buzzwords are often related to details so to pad your resume you have to learn the details. Ultimately though, if you end up never touching that detail or that detail changes then you wasted your time learning it. Learn the fundamentals because the fundamentals never change. Honestly you're the kind of developer that the OP is talking about, but then again most developers are like that.