Hacker News Reader

Comment by obedm | Hacker News Reader

I strongly disagree.

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.

View on HN

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.

> Just be able to walk the walk after you talk the talk.

Lucky you. You must not have been burned and haven't wasted your time on someone that couldn't walk the walk.

I have wasted enough months of my life on people like that.

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 :)

That's why one of the first things I check - proof of walking.

> 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.

Hire for smart, capable people first.

Being an OS-level C++ engineer is definitely a marker for smart and capable.

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.

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.

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.

> 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.

Spot on. That's why you hire people that can learn and think - not robots.

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.

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.

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.

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.

Every message in moderation, I guess.

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.

I do wonder how long it would take me to get used to driving with rear wheel steering...

Surprisingly quickly, especially if you’ve ever done any… shenanagains… in reverse.

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.

Actually, forklifts are rear wheel steering equipment. So your truck driving experience is not at all relevant... and may be a hindrance.

From my perspective a HS graduate with a lot of hand-eye-coordination experience is a better choice - than you.

depends what you're looking for, someone who has a CDL is probably a lot better at being responsible with something that can kill someone.

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.

>They'd probably make the frontend app faster, less complicated and use less memory.

And while at that, get rid of those nasty frameworks.

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)

> HTML and CSS (facility with selectors)

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.

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.

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.

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.

>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

You can't know everything even in one domain. But once you are a good programmer, you can pick up fast most domains.

If you want to do GUI, just try it. You will be amazed that you can actually pick it up pretty fast.

I've got a fun project in mind, I will give it a try.

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.

Etc.

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.

Those are discipline differences. At least I am getting the JS to TS (or tSQL to pgSQL or something) from this reference.

Technology is a bit overloaded though so we may be picking up different meanings entirely.

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/.....

And, so on...

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.

Reply on news.ycombinator.com