There is an interesting conversation to be had here.
Open source software requires that developers have the ability to spend time to contribute code. People need to get paid so they can support themselves, and as they get older, their families.
There are very few successful open source models, basically:
* advertising
* professional services related to the OSS offering
* enterprise licensing
* direct user support and contribution
Anything that is not one of these four models is either a student or hobby project, or is subsidized by the businesses that are paying the developers to contribute (either explicitly by hiring folks that work on the projects, or by employing and assigning people to work on features that eventually make their way back into the ecosystem).
If you don't support people getting paid to contribute to open source software, you are ceding the role of OSS developers to people in privileged positions, or demanding that they be paupers.
And in the interest of keeping the conversation non confrontational, folks suggesting patches shouldn't remove the UI elements from the code, they should provide a UI toggle to disable the nags; choosing to support the software or not, financially speaking, is an option for users, but be very explicit if the user chooses not to support it :)
That problem could be attributed to the tragedy of the Commons.
Claiming you don't work well in an open plan office and being taken at face value would lead to literally everyone saying that, because surprise, most people don't work well in open plan offices (I'm very neurotupical and I hate it).
Another way to look at it is that we've evolved as a society to go out of our way to try to accomodate people with different needs when necessary. Being given an office if you have ADHD is great. Try to go back 100 years and you'd be fired from the factory instead for not being a perfect cog in the machine.
So it's actually beautiful we are able and willing to accomodate others, when for most of history that wasn't the case at all.
I'm a strong atheist but Buddhism has always been the religion I've respected the most. At least the philosophical aspect of it.
I used to struggle with this too. To this day I use a box to pick up spiders or mosquitoes and take then outside instead of killing them. But I wouldn't doubt killing termites to save my plants.
We kill everyday. When we walk, or drive the car. We're powerful giants. But we can be respectful giants.
It doesn't absolve us from our "sins", but it's far better than nothing.
I think it can be narrowed down to "be respectful". Letting your rats die would be disrespectful to them. Killing a spider that isn't harming you is disrespectful to them. Walking on top of ants you know are there is disrespectful to them.
This is correct; the "no kill" rule is something you aim for, it doesn't mean you necessarily achieve it. In Mahayana Buddhism there's a story about the Buddha's prior lives, where he decided to kill someone out of compassion: the victim wanted to murder a lot of people, but the future-Buddha killed him to avoid his suffering [1]. Likewise, the Buddhist precepts are training rules, not necessarily commandments that will take you to hell if you break them.
A senior engineer that has always worked in the backend won't be able to be up to speed with a complex frontend app quickly and be as effective as a senior frontend.
There's just too much to know about browsers and underlying tech and a myriad it things.
Same for a senior frontend starting to work on a complex backend all with god knows how many interconnected technologies.
Being able to go from JS to TS? Sure. Being able to go from JS to Rust + Docker + (all your backend stuff here) not so much.
Unsolicited advice to all that read this comment and feel like it must be true.
A senior engineer has shown proficiency understanding complex problem domains and swashbuckling through the jargon to accomplish a goal.
If you pidgeonhole yourself in your career to just learning the jargon of one area then this comment might make a little bit of sense. If you keep abreast of words and what domain they're attached to, ramp up speed on any project of any kind has inherently less friction.
Keep abreast of words, all of them. Make toys that have nothing to do with what you're paid to build. Next time you're looking for new work -- don't let anyone strongly disagree with the fact that your experience on paper is in a particular domain. Just be able to walk the walk after you talk the talk.
I have and adjusted how I interview accordingly. Proficiency at the glossary problem of a given domain is for sure not the only thing worth covering in an interview :)
> A senior engineer that has always worked in the backend won't be able to be up to speed with a complex frontend app quickly and be as effective as a senior frontend.
And I strongly disagree with you, and I have a real life example to disprove it (i know, a single data point is just anecdata, but still).
Our team was doing mostly web front-end (your typical TS+React+Webpack+etc., you get the idea), and we got an internal transfer about 1.5 years ago. Senior engineer, not a "rockstar coder" by any means. He doesn't spend his free time working on tons of side projects, he has other hobbies that aren't related to coding. Just a really solid engineer all around.
Here is the catch: his sole experience for the past 8-10 years until that point was writing OS-level C++ code. Exactly zero experience with anything web or front-end related. In a month, he was already decently productive and pushing significant functionality-related PRs on regular. 3 months in at most, he was fully productive and indistinguishable from anyone else on the team, except he also had back-end skills that were better than those of at least half of the team.
And no, we weren't building a simple CRUD app (not that there is anything wrong with that), it was a pretty complex tool that worked and integrated across a bunch of different Office suite products.
Sidenote: Thought to mention that part about "other hobbies not related to coding" to make a point that he didn't just compensate for his lack of existing front-end knowledge by throwing some ungodly number of hours of his own free time at it to ramp up. The problem is that most people cannot afford throwing that many hours of their "free" time considering other life commitments. And no, there is nothing wrong with throwing many hours of free time to bruteforce a skill, that doesn't take away from the person's ability in it imo. But if the engineer I am talking about had done that, then my point wouldn't have generalized well.
Exactly this. A capable engineer can learn whatever's needed. The idea that you should hire only niche specialists sounds good but is completely wrong-headed. The best engineers I've ever worked with were good because they would and could pick up whatever was needed. Specialists OTOH are usually narrow-minded and lacking in motivation—and of little use outside of their one small niche.
Yup, that's pretty much why he got hired. He was clearly an all-around smart guy who knew his fundamentals, had zero issues with learning new things (in fact, seemed to enjoy it, which is always a great mark in my book), and seemed very socially smart (i.e., great to work with as a teammate). As a sidenote, "socially smart" isn't a synonym for "that guy who cannot stop obnoxiously bothering everyone with their constant chatter". "Socially smart" means that he has enough sense of tact and awareness to know when and what to say (or not to say anything at all).
The fact that he wasn't familiar with front-end tech at the time was just a tiny blip that absolutely no one was even slightly concerned about when he joined.
Yep agree. 25+ years of experience here. I went from not knowing JavaScript to delivering a complex 52 page web application using Typescript and React in 4 months. Doing web frontends is way simpler than writing compilers or optimisers in C++ (which is what I also do).
I was a reasonable good web developer and knew very few things about game development and yet I jump straight into it, pick it up fast and work at it for 7 years. After which I made a comeback to web development, picked up the new technologies and started being productive.
And before being a web developer I worked on desktop apps when they were still a thing.
I did a bit of embedded programming and worked on a few mobile apps, too.
Switching from one thing to another is not that hard as you make it sound.
I'd even argue that doing more than one kind of programming during your career is beneficial and not detrimental to both your skills and your career.
It also gets easier the more things you already know. Nowadays learning a new domain is mainly a mapping exercise. Oh this is kind of like X. Neat so that is basically a twist on Y. Especially after you’ve lived through a few hype cycles and start to realize there’s not all that much that’s foundationally new under the sun.
I’ve also worked on web frontend, games and physics, web backend, databases, near metal, very far from metal. I never felt like anything was out of my reach to pick up while working on said thing for the first time at a new company.
Of course you're right about the ramp up speed, but if you can't trust the person to figure it out: you don't want to hire them regardless.
As time goes on, I've become more and more convinced the skill to really look for in hiring is knowing how to learn. I think I've always thought this implicitly, but as I've been forced to articulate why someone someone is doing well or not, it's become more conscious.
Even if you use 100% popular languages/frameworks/infrastructure, what you do will always be new and proprietary in some (unless it's an explicit open source project that the new hire has already worked on, which is a pretty rare situation in the scheme of things). So there will always be new stuff to learn. Does the person know how to diagnose an issue when they get an error that they can't Google? For a lot of folks, even with years of experience, the answer turns out to be no.
I've jumped from game development in C to webdev in PHP to front-end in JS to image compression to native app development in Rust.
I've managed just fine. Switching required reading documentation, specs, papers, blogs, etc. but that's a norm even if you're staying within a single field and don't want to be left behind. It's not even a lengthy process. Reading is this magical process of quickly uploading expertise to your brain.
On top of that a lot of skills are transferable, even between seemingly-far domains. Algorithms, debugging, testing, refactoring, research, project management, and general development wisdom are transferable.
Here's the thing. Those differences are smaller than you might think.
An experienced frontend developer already knows how to program. They know how to write parallel and asynchronous code. They know how to deal with network instability. They know how to write and send of queries to a datastore. They know how to profile and debug code. They know how to work with a complex, mutable data structure safely. They're used to working inside of sandboxed environments and the need to use APIs.
These are all valuable skills for backend developers too. The flavors of the various low level components... matters less than most think.
There are massive differences between front-end and backend engineers.
Backend engineers deal a lot less with network instability, than frontend engineers. Frontend engineers have multiple ways of dealing with failure. And frontend engineers have a different ways of dealing with parallel and async tasks, than backend engineers.
It's not a massive challenge for a smart person to learn, but we shouldn't pretend that people don't try to apply their previous experiences to future tasks. Which is a cost, when hiring someone without specific domain experience.
Nope not true. I routinely switch between working on Typescript/React web applications and hard core C++ servers, compilers and optimisers. Most of the skills you need are the same.
I think going from backend to frontend can be more of an issue. Being a really good frontend engineer requires a strong sense of ux and design that can be completely at odds with how a backend specialist’s mind works. It’s not impossible, but might be really tough.
Going the other direction, there will be new concepts, more focus on algorithms and scalability, more focus on ops and infrastructure, etc. But it’s all still in the realm of programming.
In my ideal world, theres a UX designer to take in (and mentor in) that work. Perhaps design is baked into frontend work in smaller companies, but every place I’ve worked has had a specialist devoted to that work.
Even I, an infrastructure monkey, can follow a design doc with explicit values for widths, lengths, and font colors, faces, and sizes.
I think that in practice a frontend engineer is still going to be making a bunch of ux and design-oriented decisions during implementation, since no design ever translates perfectly. Botching these over and over really slows things down (or hurts overall quality if they never get cleaned up) compared to someone with enough design sense to improvise and fill in the gaps.
This is itself too much of a generalization. Great developers with a lot of experience across tech stacks, even if mostly back-end focused, will have very little problem getting up to speed on a complex (e.g. Angular) front-end. Learning curve? Sure, but these are the people that have proven time and again they have no problem and no fear picking up new tech stacks and applying their general problem solving skills across a huge variety of languages, frameworks, etc.
A more concerted challenge is not whether a senior developer can pick up front-end technologies, but rather whether a strongly backend focused engineers wants to do front-end. I find the latter scenario (which is more about desire and preferences) to be far more important than whether or not they have the ability, experience and aptitude to do so.
As one of those back-end-preferring developers, the thing about front-end development is that the correctness of UI code is subjective, and furthermore subject to the user's opinion. On the back end, I can write heaping piles of unit tests to verify objective correctness of math and data consistency. But on the front end, this button needs to be further to the right, and labeled in a different font.
> A senior engineer that has always worked in the backend won't be able to be up to speed with a complex frontend app quickly and be as effective as a senior frontend.
Why not? I know plenty of people who have switched domains for new jobs, and unless you are moving into something highly specialized that requires tons and tons of domain knowledge, it should take you no more than 3 months to become productive with the new tech.
I think context is important. It is good to outline why they need to be up to speed quickly.
If someone has the need for a senior frontend engineer to contribute immediately on a complex frontend app where they are directly replacing a key engineer who left, then what you said makes a lot of sense. Lots of stakeholders are likely to nervous about bringing in a solid developer who isn't already working in the discipline. Often there can be fall out in organizations from this that results in the support systems failing for the hire which compounds problems for them.
When you are thinking about the long-term health of your organization though it is useful to support people in making this transition. Why would they want to stay with your organization long-term if they can't make these kind of changes? They can likely do some frontend projects on the side and go somewhere else combining a salary bump and a discipline change.
Ultimately, you can't guarantee these opportunities for anyone, but it's a case of appearing to be reasonable. That's not the feeling you probably wanted to convey, but it's what came across.
I was gonna quibble with you, but I realized that the article title is “specific technology experience,” not “specific programming language experience,” so I think you have a point.
I mean, forklifts are a technology, but I feel pretty confident that three years as a React developer proooobably doesn’t qualify me to just hop on one of those.
But let's say you'd worked in a warehouse for 10 years before, and now wanted to upgrade to forklift driver, and were previously a truck driver. It wouldn't be unreasonable to expect you might do well in forklift training, and be able to get up to speed faster than a random 18 year old who just graduated from HS.
The forklift analogy is pretty bad; you can get proficient enough to move basic pallets with about around half an hour of effort and instruction if you've driven a car. Using one is more of a matter of thinking through the various moves than being swift and confident with the controls.
Or so says my wife, who is not a truck driver but can drive a forklift.
Right, which is the main thrust of the linked article. I think it's useful, though, to try and pick apart the boundaries where that argument breaks down; how different of a forklift do you need for your experience to stop applying, etc.
Ok I'll bite, what exactly is there to 'know' about browsers and underlying tech? Apart from the overly complex build eco systems the js frontend devs have forced upon themselves, I see no reason why a senior backend engineer can't pick that up in a week or two.
They'd probably make the frontend app faster, less complicated and use less memory.
Things a frontend dev would know that a backend may not:
- HTML and CSS (facility with selectors)
- JS syntax and semantics, common patterns and idioms, gotchas
- Web APIs
- CORS
- Frontend data persistence mechanisms (cookies, local storage, etc.)
- Critical rendering path
- Service workers (how and when to use)
- Accessibility (ARIA)
Most senior backend engineers were generating this in the server response long before frontend frameworks were a thing.
> JS syntax and semantics, common patterns and idioms, gotchas
JS syntax is based on the most common C style syntax there is. You can reach a good enough level just by knowing that. The rest of the idioms/gotchas, well those are not really necessary and are mostly flaws which JS itself is trying to fix it with the new iterations.
> Web APIs
These are well documented, are you saying a senior backend engineer will have trouble reading the docs were a frontend dev won't?
> CORS
Come on, let's be serious here.
> Frontend data persistence mechanisms (cookies, local storage, etc.)
... so a backend engineer will not know how to use state persistent mechanisms? Think about that for a second.
> Critical rendering path
A backend engineer has responses to return in the milliseconds, not hundreds afforded by frontend, they know much more about getting data ready as fast as possible.
> Service workers (how and when to use)
A mini backend in the browser, and you're saying a backend engineer won't understand that?
> Accessibility (ARIA)
Are you talking about learning the available tags, which would take less than a day, or designing for accessibility (eg. color/full blindness).
Ignoring your extreme snark and least charitable interpretation of what I've written, I'm not saying any of these things are insurmountable or even necessarily hard to learn, but they are _things to know_. I don't think you should completely dismiss all of the frontend "domain" knowledge with a wave of your hand.
As a full-stack developer who started off more frontend and leans more backend these days, JS is one of the languages I know best, for better or for worse, and knowing it has paid off for every job I've had so far. Understanding about the prototype chain has been useful for monkey-patching abandoned 3rd party library plugins that I've had to use in a pinch because there was no alternative aside from writing and maintaining my own. Knowing about variable hoisting has gotten me out of a jam when working with legacy code. Also, saying "the flaws of JS don't matter since they're going away" isn't really true since there's still a lot of old, crappy JS out there in the wild that you may be forced to interact with and browsers still have to support; things like there existing null _and_ undefined in JS aren't going away, so you need to know about them and have a plan for dealing with them. As it turns out, knowing one of the most used languages and all of its baggage is useful.
Please realise that what is complex and hard for you might not be complex or hard for a senior engineer with 20+ years of experience in different languages and frameworks. I write compilers for a living and have written 3D game engines from scratch for commercial games. I learned JavaScript and delivering a complex 52 page web application written in Typescript and using React in 4 months. It was fun and easy compared to what I normally have to deal with. So please realise that your experience is very different from somebody with a lot of experience. I am not being snarky or arrogant. Just pointing out that different experiences shape how well you adapt to new tech.
Right, and they can be picked up in a week or two by anyone who has any sort of senior level experience. Literally everything you described is not limited to JS and almost every dynamic language contains their own version of them.
Not to mention you backpedalled away from the original question about browsers and underlying tech and focused on a couple nuances in JS.
All of that is easy to learn. You just learn the bits you need to solve the specific problem you have. I went from not knowing JavaScript to completing a complex 52 page web app in 4 months. I simply just-in-time learned what I needed to learn. It wasn’t hard. It was fun actually.
Not much. I went from not knowing JavaScript to delivering a 52 page complex web application in 4 months. You just learn what you have to learn to solve the problem you have. That’s the key skill you need. If you can figure out how to quickly learn what you need to solve a problem then nothing is hard.
Yes, when I was younger and had just 20 years of experience with programming it was before 1990! Back then I knew a small amount about virtually everything in CS and virtually everything in a small portion of CS.
However things in CS changed rapidly and I made the decision to work on operating systems and basically let go of writing user interfaces. The landscape for user interface development was a mess MS Windows, NextStep, X, MacOS, and Sun Window System were all different. The web and especially browser support for JavaScript really accelerated the rate of change and I found it impossible to catch up with GUI development.
For years, I did consulting work for firms helping them with system architecture, but in the last few years I found myself unable to help with the inevitable requests for assessment of companies user interface designs. It's a bit sad for me to know so little about such an important part for so many applications.
Oh well, I've been very happy in my career, but I still remember the "good old days" where it was possible to take on virtually any task without needing a lot of time to ramp up my understanding of the tools, frameworks, and programming languages.
Nothing is absolute, of course if you take it far enough the seams of the argument tear but there is merit to it.
A senior browser frontend developer is likely to pick up mobile development quite quickly.
Likewise someone who's been doing Spring Boot Java backends for years and is proficient with databases, caching, etc. Isn't necessarily going to find it hard to switch to a serverless nodejs paradigm.
The network card person is probably able to handle the embedded microwave oven.
I believe it's not about learning how to do things. That's not that hard. It's about knowing about the gotchas - things not to do. Every technology stack has its warts and oddities.
It's not that hard to write some code that would do the job, it's hard and cost prohibitive to realize all the initially hidden nuances that might require redesign because of shortsightedness of the original one.
Requires either a really bright fast-thinking mind or just a lot of experience making one's fair share of mistakes. There are geniuses out there who can make perfect models in their heads, but I believe a lot of people just scrape by knowing where them or others had shot themselves in the foot before. And such experience only comes with time.
Yeah, I'd parse the article as saying, for example, job postings for React roles shouldn't specifically require years of experience with React. This is because Vue knowledge is highly transferable.
There's an insulting premise in such job postings that engineers are incapable of learning anything new.
When I hire a painter, I don't ask how many years experience they have with pink paint (as opposed to say white or magnolia).
> A senior engineer that has always worked in the backend won't be able to be up to speed with a complex frontend app quickly and be as effective as a senior frontend.
Of course we can nit pick and poke holes all we want. But the basic premise, to use your example, is that an experienced backend engineer can work in a backend written in C/C++, Java, Go, Rust, Python, Ruby and so on. An experienced frontend can work in Angular, React, Vue, Svelte, JS/TS/Elm/ClojureJS/.....
Not true. I went from not knowing JavaScript to delivering a 52 page web application using Typescript and React in 4 months. Meanwhile an “experienced” front-end developer spent 3 months trying to decide which framework to use. It depends on the person not whether he/she is back/front/experienced.
The point is that the market has been going up in the long term for as long as there's been a market. So you're better off just investing and forgetting about it rather than investing made from your feelings.
Having a big paying community will drive more free content, as both the paying and free customers benefit from it.
If free content start sucking, less people sign up.
Plus, some content just isn't worth privatizing, like documentation.