14 ms·

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 effe

by obedm 5y ago

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.

atwebb 5y ago
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.
- orra 5y ago
  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).
ketzo 5y ago
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.
- xxpor 5y ago
  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.
  - falcolas 5y ago
    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.
    - xxpor 5y ago
      I do wonder how long it would take me to get used to driving with rear wheel steering...
      - falcolas 5y ago
        Surprisingly quickly, especially if you’ve ever done any… shenanagains… in reverse.
  - ketzo 5y ago
    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.
  - JAlexoid 5y ago
    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.
    - xxpor 5y ago
      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.
ghotli 5y ago
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.
- JAlexoid 5y ago
  > 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.
  - ghotli 5y ago
    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 :)
    - JAlexoid 5y ago
      That's why one of the first things I check - proof of walking.
xxpor 5y ago
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.
- goodpoint 5y ago
  > 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.
zepolen 5y ago
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.
- stank345 5y ago
  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)
  - zepolen 5y ago
    > 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).
    - 5y ago
falcolas 5y ago
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.
- danenania 5y ago
  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.
  - falcolas 5y ago
    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.
    - danenania 5y ago
      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.
- 5y ago
zerkten 5y ago
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.
todd8 5y ago
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.
- DeathArrow 5y ago
  >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.
  - todd8 5y ago
    I've got a fun project in mind, I will give it a try.
DeathArrow 5y ago
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.
- redisman 5y ago
  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.
deleted 5y ago
[deleted]
pornel 5y ago
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.
nsotelo 5y ago
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.
- drdaeman 5y ago
  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.
yumraj 5y ago
> 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...
filoleg 5y ago
> 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.
- mywittyname 5y ago
  Hire for smart, capable people first. Being an OS-level C++ engineer is definitely a marker for smart and capable.
  - filoleg 5y ago
    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.
deleted 5y ago
[deleted]
speby 5y ago
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.
- logfromblammo 5y ago
  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.
RussianCow 5y ago
> 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.
mbrodersen 5y ago
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.

by obedm 5y ago

atwebb 5y ago

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.

orra 5y ago
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).

ketzo 5y ago

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.

xxpor 5y ago
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.
- falcolas 5y ago
  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.
  - xxpor 5y ago
    I do wonder how long it would take me to get used to driving with rear wheel steering...
    - falcolas 5y ago
      Surprisingly quickly, especially if you’ve ever done any… shenanagains… in reverse.
- ketzo 5y ago
  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.
- JAlexoid 5y ago
  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.
  - xxpor 5y ago
    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.

ghotli 5y ago

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.

JAlexoid 5y ago
> 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.
- ghotli 5y ago
  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 :)
  - JAlexoid 5y ago
    That's why one of the first things I check - proof of walking.

xxpor 5y ago

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.

goodpoint 5y ago
> 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.

zepolen 5y ago

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.

stank345 5y ago
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)
- zepolen 5y ago
  > 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).
  - 5y ago

falcolas 5y ago

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.

danenania 5y ago
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.
- falcolas 5y ago
  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.
  - danenania 5y ago
    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.
5y ago

zerkten 5y ago

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.

todd8 5y ago

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.

DeathArrow 5y ago
>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.
- todd8 5y ago
  I've got a fun project in mind, I will give it a try.

DeathArrow 5y ago

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.

redisman 5y ago
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.

deleted 5y ago

[deleted]

pornel 5y ago

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.

nsotelo 5y ago

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.

drdaeman 5y ago
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.

yumraj 5y ago

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

filoleg 5y ago

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

mywittyname 5y ago
Hire for smart, capable people first. Being an OS-level C++ engineer is definitely a marker for smart and capable.
- filoleg 5y ago
  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.

deleted 5y ago

[deleted]

speby 5y ago

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.

logfromblammo 5y ago
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.

RussianCow 5y ago

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

mbrodersen 5y ago

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.