A tech stack should be a well-balanced portfolio
staysaasy.com
staysaasy.com
I think this is worth examining in a lot more detail.
I accept that candidates are going to be put off by obsolete or terrible technology. I wouldn't take a job working on a Java 1.7 codebase, for example. Or ATG (now Oracle Commerce) - i did three years on that, and will never touch it again.
But if a candidate is motivated to take a job because they get to use shiny new technology, i would suggest that they are not, in fact, a good candidate. In my experience, magpieism is associated with weaker programmers; not the very worst, but second quartile, say - people who get very engaged with superficial details, but don't think about deeper things.
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.
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.
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.
Are you assuming enough Googling can't produce high quality solution?
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.
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.
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.
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.
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.
The answer is yes, they would still need to be pushed hard. "Build it and they will come" works only in movies.
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.
Devs have that idea because that's how many companies hire.
In my experience the tech stack is good indicator of how technology is viewed at a company. Java and C# shops I have encountered are very process driven, bureaucratic firms. In my experience they are management focused as opposed to tech focused. Where firms that use Python, Node, Haskell, Rust, Go, etc tend to be more tech forward. The reason I want to use "shiny new technology" is because I want to work at the latter as opposed to the former, I'd be happy to write C or PHP even at a tech focused firm but I rarely see jobs like that advertised.
So yeah, magpie developers are a thing, but it's not just superficial developers, but superficial recruiters and companies as well.
For front-end stuff I've been using React, and while React is a great technology, it did attract a lot of inexperienced programmers initially. Nowadays, React by itself isn't the new shiny, so that effect has diminished, but the magpie-ism has taken on a new form: I find myself on a lot of projects fighting to keep out bleeding-edge JS libraries with > 100 dependencies.
It's not hard to build a tool that demos well. It's much harder to build a tool that will withstand the tests of time.
However, my experience with looking for jobs in London is that if I don’t have more experience with most of the stack than someone else in a company/recruiter’s candidate set, I will not get the job (regardless of how well I communicate my ability to work in teams or problem solve). Even after 15 years professional coding and a Masters in Software Engineering.
How does your position work for you? Have you been able to learn new stacks “on the job”? Can we characterise a hiring pattern for different geographic areas? Do you go learning a prospective employer or client’s problem domain before making contact with them, and base conversations around that?
Yes, I try to do exactly that. The goal is to be able to speak their language in the interview as well as determine if I'm interested. I try and find out everything I can about the company, their product and the product of any competitors. If I'm enthusiastic about it, I figure out where to send my resume.
As far as tech stacks, I've learned Java, Progress, C#, various scripting and shell languages all on the job without ever knowing them prior to getting the job (I started my career as a C++ programmer which I already knew, so there's that).
I think the key has been the fact that when I interview I already know about the company and their product and domain and I can ask pointed, intelligent questions and generally have a great discussion about it with them. The companies that have hired me knowing I don't know, say, Java, haven't cared. The companies that don't hire me because I don't know Java, only care about hiring Java developers and I'm glad they spared me the trouble.
I don't know if it is luck, but I generally don't get many rejections. I also don't generally send my resume to more than a few companies before getting hired.
There are a lot more companies that want you to have experience with their technology stack than those that just want “smart people” (tm) and that will take the time to train you.
On the other hand, salary compression and inversion are real. Your market value will go up by $some_big_number but HR policies will only allow raises of $some_small_number. So you have to keep your eye on the market and be prepared to jump ship.
Anecdotally, I was once hired for a company that wanted to build a new product in .Net. The new product didn’t find a market, but their legacy product written in PHP did. None of us wanted to spend a year doing PHP development. All 14 of us left within six months.
Seems like exactly the point OP is making. By hiring devs that cared more about the stack than the product, your employer got screwed when the product with the boring stack took off.
But the rest of the story....
The department we worked for was an independent startup that got acquired by a Fortune 10 company (at the time) shortly before they started ramping up. The manager of the department was one of the original developers and founders. Even he left soon afterwards.
I'm not sure it's about shiny tech, but the opportunity to grow and learn, and use those skills to become more marketable. The best developers (in my experience) have a growth mindset, and that includes learning new technology and new techniques.
In fact, one thing I've learned from working on bleeding-edge tech stacks is that communities around bleeding-edge tech stacks can often be narrow-minded in a way that hinders learning. Many (but not all) members Go community, for example, seem intent on not learning anything from other languages: if you point out that coroutines predate Go by decades and there's a lot to learn about their use from other languages, or that Go actually has a fairly weak type system, you'll get a lot of defensive pushback from Go fanboys who know literally nothing about other languages that contain coroutines, and don't understand that there's a difference between static types and strong types. There are good programmers in bad ecosystems--the folks who are bringing in generics might yet make Go a decent language--but remember that there was immense infighting to get there: I've been keeping track of Go long enough to remember all the people ranting that Go didn't need generics because it had `go generate`--a glorified C macro system (since they couldn't be arsed to learn from the mistakes of even one of the most adjacent languages) that breaks the entire point of not including generics in the first place (to keep the compiler single-pass).
If this is the sort of "growing and learning" you're talking about, I generally tend to avoid working with people who "grow and learn" in this way.
No, it's not. The key phrase is "growth mindset" [1]. That does not mean throwing away knowledge or blindly accepting the shiny new objects. I think that's where we're disconnected?
[1] https://www.brainpickings.org/2014/01/29/carol-dweck-mindset...
If you're far enough behind, you get problems with tools and dependencies that stopped supporting the old stuff. That can get very painful and annoying. I'd be generally careful about chasing all the shiny and new stuff, but there is also risk in lagging behind too far once it seems like most people jumped ship.
You want engineers who love to grow, learn and solve problems. Startups in general have rather boring problems to solve compared to large companies. Learning and mastering a new technology however is a problem space that startups can provide their engineers.
> In European culture, the magpie is reputed to collect shiny objects, often in fiction things like wedding rings or other valuable or significant objects (often causing consternation at the disappearance, and false accusation of humans in the plot of the story); the most well-known example probably being Rossini's opera "La Gazza Ladra" (The Thieving Magpie). Recent research [8] has shown that there is little truth in the legend, and that magpies - like many animals - are actually unsettled by shiny, blue, or otherwise unusual objects.
Or should there be a Rust based React framework? How would that work? If it exists then it’s gotta be more performant, so yeah, let’s use that.
I don’t know if this is magpie enough now days. It’s hard to even make fun of this because the irony is even the joke becomes outdated lol.
There are a few different Rust frontend frameworks that compile to assembly that are roughly based on the ideas of React. Yew is the most prominent.
I would argue that this attitude often exists at the corporate level as well.
Most companies I've worked exist in a perpetual state of migration from monolith to Micro services. Basically the overall architecture remains static in the sense that it's always a giant monolith sitting in the center with some satellite services surrounding it.
The migration to microservices and kubernetes is 99% buzzword driven and rarely has nothing to do with whether or not the product will benefit from the migration. The weirdest part about it is that it's many times a never ending thing initiative. It's very rare for a company to actually arrive to a point where every component of their system is split out into small pieces. It usually just stays permanently as some services surrounding a monolith despite all the talk.
When entire companies are like this it's usually a sign that the entire company is weak. My experience has been that many companies have this attitude and many programmers share it.
If all/most programmers share this general attitude then I wouldn't call these "new technology chasers" bad as most people are like this.
I may be biased because I know I talk a lot. But my experience has actually shown that this is not true.
People who don't know a lot of things tend to stay silent. This strategy works consistently to allow many people to hide extraordinary gaps in knowledge. It's very common and the strategy works.
When you see a person not talking too much... human bias tends to err on the fact that he's just not a talker or he may be deep in thought. Never do you think that a person isn't talking because he doesn't know anything. To be not biased is to consider all the possibilities and basically 90% of people just skip over the thought that the person isn't talking because he doesn't know anything.
Now for a talker, the bias goes in the other direction because a talker has an incredibly higher chance of saying something you disagree with or is flat out wrong. This chance is higher EVEN when the talker is more knowledgeable than the non-talker simply because the talker places himself on the pedestal of judgement every time he opens his mouth while the non-talker avoids it.
If you know a non-talker who may or may not have kept his trap shut after you explained something to him, really the only way to confirm whether he knows what you're talking about is to ask him confirmation questions after you talked to him. If you don't do this, likely he'll just google the info later and pretend that he always was on top of everything.
You have to really watch out for this bias. Even as a talker I tended to bias towards thinking that the quiet nice guy was more intelligent. The reality is, "magpieism" has no correlation to how good or bad someone is... if someone talks a lot they could go either way, it's just that because they talk a lot, you have a ton of info on how good they are based off of what they say... while the non-talker you have no info and your judgement is (unknowingly to you) influenced by your biased optimistic assumptions.
If someone is quiet there is a higher chance that he's quiet because he's totally lost. And if he's quiet often... then there's a higher chance that he's totally lost all the time.
For us, the risky choice in our stack [1] was Haskell. It's been amazing and has paid off immensely, but the challenges are very real. Over time we've wanted to go whole in on things like ReasonML too, but we haven't pulled the trigger or made safer choices, because that one golden ticket has been used up.
(I can't take credit for coming up with this, but I don't know who did! I'm sure it's already better articulated somewhere.)
More on topic, I find it a bit disheartening that people are discouraged from picking a niche library and are instead supposed to look at GitHub's star system. So if it's not on GitHub or if my users don't star it enough, you shouldn't consider it for use in production? Shouldn't the documentation, code quality, open issues / maintainer responsiveness to issues, etc. speak for itself?
Just because it's disheartening doesn't mean it's unwise.
> So if it's not on GitHub or if my users don't star it enough, you shouldn't consider it for use in production?
If it's big enough to be popular and not be on Github, that's a good sign. If it's not that popular and refuses to be (also) on Github, that's a really bad sign.
> Shouldn't the documentation, code quality, open issues / maintainer responsiveness to issues, etc. speak for itself?
No, because popularity adds value well beyond those things. It tells you that other people have found that the piece of tech is "good enough". They've already run into issues for you, so that you don't have to. They've already trained on it so you don't have to train. Popular projects are made better just by being popular, which is self-reinforcing.
Of course that means sometimes ill-conceived technology (like HTML/CSS/Javascript) wins out over contenders that are better "on paper".
A star does not mean someone used a library for an extended period of time and decided to endorse the project by giving it a star. I expect most people use it as a like button (showing appreciation for or approval of the work and nothing else), a bookmark (since you can view your stars), or both.
Looking at my own stars on GitHub, the first one is something I never used, I just liked that someone documented the protocol for me and published some software around it, so I could make my (planned) open source alternative to the vendor's proprietary crapware more easily.
The second one is a factorio mod that I enjoyed using.
The third is a list with an overview of algorithms. I suppose I gave it a star for similar reasons as why I might give a comment or article an upvote.
The fourth is a simple PHP project that looks nice, but I honestly don't remember seeing it and I certainly never ran it.
So that's n=1 but given how easy it is to leave a star and that there is no way to leave a negative star or any sort of comment: no, stars have nothing to do with endorsement, quality, running into issues, or any such quality. If I want to leave a comment to indicate or warn that something is broken, of bad quality, or something similarly negative, a ticket ("issue") is what I might create, and so I circle back to my previous statement: look at other qualities like developer responsiveness in tickets, past tickets...
A "clones+downloads from unique IPs+users" or something similar might be a metric for how often this was actually attempted to be used, and given that most people wouldn't forward bad software to others, that might say something about it beyond some threshold. But it still doesn't tell you anything about their experience with it, for that you'll (currently) really have to look at other factors.
Similarly, a project that has 5000 unanswered issues is going to have more users than one with 50 closed issues.
In lieu of any better metric, this is the way to gauge popularity.
Not sure why I bothered replying to you if you're literally saying "I don't care what you just wrote"
I did not repeat the argument. Let me explain it differently:
Let's say that on average N% of people give a project a star because they're active users and (100-N)% give a star for any other reason. There is no reason to assume that N will be significantly different for similar projects. I don't know N, but it doesn't matter how big N is, more stars still imply more active users.
Is there going to be variance here? Of course, but it's unlikely to distort the metric to the point where it becomes invalid, unless you have very samples (stars).
Indeed, if there's one project with 10 stars and another with 5 stars, the chances are high that it's just noise. You cannot get a good estimate of which project has more active users in that case. However, you can tell that neither are popular and both are risky dependencies.
Yeah, it's pretty gross for two reasons:
1. Reinforces the broken belief that the best way to evaluate things is based on the perception of others, rather than the intrinsic qualities (like those you mentioned)
2. Adopts a purely consumeristic view of open source
The striking thing is that now these sorts of views are said out loud with no sense of shame.
It's not always the best way, it's a shortcut. While you're spending time figuring out which JSON library is the best by some metric that might ultimately be irrelevant to the task at hand, I'm going with the popular option that is almost certainly "good enough" for me - otherwise it wouldn't be popular. That gives me an advantage over you, 98% of the time.
> Adopts a purely consumeristic view of open source
I don't see how this relates to popularity. Most users of open source will always be consumers, whether something is popular or not. However, if something is popular, the likelihood of someone to contribute back also grows.
Furthermore, if something is popular and there's an issue, somebody else will most likely run into it before me, write about it, get feedback on it, and so on. That's a valuable contribution, even though it isn't code.
I'm saying that if you have the choice between a handful of projects that solve more or less the same problem that you actually have, just going with the most popular one is probably going to be the best choice, because having all these other people in the same boat is valuable.
I agree with limiting dependencies and points of failure, but that's orthogonal.
The smaller a library is, the easier it is generally to just fork it and maintain it yourself if you need to. In that case there is no big danger in choosing an unpopular one. But for large, complex dependencies it can be very problematic if they become unmaintained. That is a risk that is always there, and that you have to keep in mind while choosing your dependencies.
> Every time you aren’t boring in a technology pick, you’re likely not optimizing for your company’s best interests.
Really helps to underscore the difference between choosing something shiny and choosing something pragmatic and efficient. When we do the former (as I'm sure most of us gravitate towards), it's very easy to kid ourselves that we'll somehow make the product greater as a result, but in reality we're only serving our own interests (learning something new and fun) rather than the company's!
What? I'm going to have a choice of two bits of tech and I'm gonna decide to use one over the other cos it's 'boring but not too boring'? Come on now. These are rules for people who don't know what they're doing aren't they?
Understand your requirements. Understand the technology you propose to use.