5 ms·
I really, really want to double down on this, because it's not expressed often enough or nearly well enough. There is a huge contingent of devs (I work in the
by BigJono 6y ago
I really, really want to double down on this, because it's not expressed often enough or nearly well enough.
There is a huge contingent of devs (I work in the consulting space, maybe this isn't everywhere) who have this idea that 'upskilling' is all about using new libraries in some toy project to familiarise themselves with the API of the library. They finish a project using React, then ask to be put on a Vue or Angular one next so they can 'widen their skillset'.
You can pretty much split learning up into three kinds: Learning how to solve new problems, learning how to solve the same problems in a different way, or learning how to solve the same problems in the same way, but with a different representation.
Learning the API of new libraries is almost always the latter, and people constantly mistake it for the second one and think they're making progress. Worse, people do this shit long before they've exhausted their options for the first kind of learning (which is the best).
React, Angular and Vue all do the same thing. They all do it roughly in the same way. Even when libraries do things a different way, learning the API is often still the 3rd kind of learning unless the library's abstraction is leaky as shit and you have to learn all the intricacies of their approach anyway.
Focusing on the wrong kind of learning makes a worse dev than you otherwise would have been. I've worked with a handful of great devs, and a fuckton of devs that know 20x as many libraries but churn out nothing but overengineered unmaintainable shit.
If you want to distinguish yourself from the crowd, learn a boring technology in an area that you're not as proficient in. Don't chase the fancy shit just to build stuff you could already fucking build in half as many lines of code.
- scarface74 6y agoDon’t blame the devs - blame the market. Most companies insist on developers who don’t have to be trained on their stack. Most developers therefore do resume driven development. It’s as much of a “gravity problem” as being forced to “grind leetCode” to get into $BigTech.
- mattgreenrocks 6y agoThe market is wrong, but devs should take responsibility for their own professional development. Resume-driven development may optimize for the market, but it probably isn't the fastest way to learn.
- scarface74 6y agoThe purpose for learning tech is to put money in my bank account. Why would I take a job and work eight hours a day using non marketable technology and then spend my free time doing side projects that “don’t count” as much as what you do on a job when I could just choose a company where I get paid while learning new tech and I can spend my free time on basically anything else?
- deleted 6y ago[deleted]
- withinboredom 6y agoOnce you’ve been around long enough. It just doesn’t matter. There are many ways to write a resume that don’t focus on job history, so you can market yourself in a way that makes you most appealing to the company you want to be hired by. You also get bonus points for having a “unique but standard” resume that’s tailored to the work you’d be doing instead of where you’ve worked (unless that’s something you want to highlight because it might get you in the door faster.)
- scarface74 6y agoIn my case is 25 years “long enough” [1]? The only way that I landed a job at $BigTech, without having to go through the “leetCode”/algorithm dog and pony show, work remotely, and without having to move from my relatively low cost of living area was by doing plenty of resume driven development and targeting my experience toward either Amazon (AWS) or Microsoft (Azure). Before, my current job at Amazon, I didn’t care what company I was hired by. In my local market (large metro area on the East Coast) all companies were paying within the same range. By making sure that my resume was in sync with the market brings a lot of optionality (or at least did before Covid) [1] to be honest, I stayed at one job too long until 2008 and was firmly in “expert beginner” territory.
- randomdata 6y ago> They finish a project using React, then ask to be put on a Vue or Angular one next so they can 'widen their skillset'. Seems like reasonable behaviour. When looking for your next job, the first question asked is "Do you know tech stack X?" People are always going to optimize for market demand. When companies stop caring about your familiarity with specific technologies, people will stop seeing learning specific technologies as an end goal. > If you want to distinguish yourself from the crowd, learn a boring technology in an area that you're not as proficient in. I'm not sure I agree. I've spent an inordinate amount of time learning about concepts, which can be applied using either boring or exciting tech stacks, that have never successfully caught on outside. To stand out, my time would have been better spent focusing on one thing and becoming more familiar with the equivalents of React, Angular, and Vue around that thing. For personal growth I don't regret spending that time. I'm glad to have had the opportunity to expand my horizons. But in terms of standing out among others, it hasn't proven to be useful. Knowing both React and Vue is much more eye-catching.
- twic 6y ago> When looking for your next job, the first question asked is "Do you know tech stack X?" I've never been asked that. I have had jobs where i was expected to know a particular programming language, but never some specific framework within it. I don't doubt that these jobs exist. But if someone is hiring permanent employees on the basis of flavour of the month frameworks, they have no idea what they are doing, and i would advise against working for them.
- em-bee 6y agounfortunately they seem to still be in the majority. companies are not interested in training and overestimate what it takes to learn a new stack. they also want people who can hit the ground running. i see that kind of job offer frequently
- randomdata 6y ago> I have had jobs where i was expected to know a particular programming language Which falls under the same thing we are talking about. If you know one programming language, you can figure out them all. You'll probably fall down flat when it comes to idioms of an unfamiliar language, but the same can be said around the idioms of frameworks. Many programming languages even include their own frameworks out of the box as part of the standard library, muddying the lines further. As far as this discussion goes, there is no meaningful distinction to be made here. > But if someone is hiring permanent employees on the basis of flavour of the month frameworks, they have no idea what they are doing The ask isn't necessarily flavour of the month. I still see tons of jobs looking for people with experience in Rails, for example. It hasn't been popular for at least a decade. However, from the job seeker perspective only knowing Rails limits to only Rails jobs, even when one knows everything about web development and could just as easily develop a web application in bash if you asked. > and i would advise against working for them. It is not an unreasonable ask, to be honest. Gaining familiarity with idioms is unquestionably the hardest problem in computer science, even above what the familiar joke suggests. While you can start to write code in a new language/framework almost immediately, It can take years to gain the understanding necessary to write great code. That is why businesses shy away from great programmers who don't know the idioms of a particular system adopted within the business.
- mattgreenrocks 6y agoLibraries, frameworks, and even languages are just implementation details. (If they were half as good as they purported to be, would they need to be pushed so hard? Food for thought.) Benefit of experience is that you start to see that every new shiny thing that comes out teaches you so _little_ compared to diving deep into different domains of programming. It's fine to immerse yourself in learning a platform and different libraries really well. But when it starts to feel too same-y, that's your cue to branch out. One problem is that devs focus far too much on their own perceived "employability," optimizing for jamming every single library on their resume, rather than learning to convey that they could spin up on a tech stack in a reasonable amount of time in a new gig.
- brlewis 6y ago> If they were half as good as they purported to be, would they need to be pushed so hard? Food for thought The answer is yes, they would still need to be pushed hard. "Build it and they will come" works only in movies.
- stupidcar 6y agoI 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 agoYes 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 agoUnderstanding 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.
- michaelchisari 6y agowho have this idea that 'upskilling' is all about using new libraries Devs have that idea because that's how many companies hire.