our company is facing the problem that we do not find any experienced Ember.js devs here in germany or south africa to work on our app.
Unfortunately this becomes a problem when trying to scale up our dev team, so much so that we are considering moving away from Ember.js
An alternative would be to train experienced javascript developers to adopt Ember.js.
Iâm wondering if other have this problem and can share ideas and experience how to overcome the problem.
IMO this attitude â regardless of tech stack â is a mistake companies make.
Any solid Javascript developer should be able to become productive in your app in a matter of hours. If that isnât true, figure out what about your process is broken.
Talking specifically about Ember: the learning curve for modern Ember is very modest. Anybody who has worked on front-end JS apps will be productive very quickly, and theyâll know how to ask the right questions when they hit rarer edge cases.
I agree. Basing your technology choices on hiring pool doesnât seem like a good idea for any company (although it is far too common). Unless your codebase is very old (which would present the same issues in any framework) thereâs a ton of overlap in concepts and tools.
Our team is evaluating onboarding right now and operating under the assumption that we wonât get people already experienced in Ember. Our general approach is something like the following:
identify what is âEmber knowledgeâ and what is âour team conventionâ and keep the two clearly separated
try to automate enforcement of team decisions and convention as much as possible (lint rules, automated tests, developer tooling for pushing devs down the âhappy pathâ)
surface a âcheat sheetâ comparing major framework concepts and syntax so itâs easy to find the Ember analog even if someone is âthinking in Vueâ for example (e.g. Routing comparison, contrasting the reactivity models, modifiers vs useLayoutEffect, etc) and some of the concepts in Ember (like Services, Ember Data) that donât have direct counterparts in Vue/React
strong pointers to the official docs and community precedent
emphasis on good design patterns (which in broad strokes are completely framework agnostic) like good core single purpose atomic components, one-way data flow, responsible encapsulation of side-effects, etc
spending time 1:1 mentoring on anything that isnât sticking, or a few of the things in Ember that are unique and/or complex (e.g. Ember Data if you use it)
Our codebase is very large and has been around for a long time (started Ember 1.6 I think) so by far the hardest parts of onboarding someone are all related to bits of outdated code, tech debt that hasnât been addressed yet, or weird/old styles and patterns that havenât been refactored yet. And of course these sorts of things will happen in a long lived app regardless of framework choice.
Because Ember focuses on convention over configuration (in contrast to React/Vue) I think itâs easier to pick up in a lot of ways because it saves you from having to make so many decisions upfront. Apps that use React across various companies could look very different because React itself is just a tiny library. So all that to say: just because someone has experience in React doesnât mean they have experience in your React, which in my experience can be almost as big a jump as a different framework entirely.
âBasing your technology choices on hiring pool doesnât seem like a good ideaâ.
Well, popularity changes over time, so you are never âsafeâ choosing one or the other. Specifically with long living complex projects. Choosing the âright tools for the jobâ is a big topic to discuss.
The fact remains that emberjs developers are hard to find. Iâm convinced it makes more sense to build up new emberjs devs than changing the tech stack.
@dknutsen, good to know you guys see similarities here. we have run some recruitment campaigns to find talent motivated to learn emberjs, most applicants dropped out specifically because they had no interest in learning emberjs. Iâm working on improving our campaigns, any interest in sharing the learnings?
I totally second the previous replies here, so I will just share my experience with recruiting in our tech team.
Basically we just search Javascript developers with the only âconditionâ being that they are wanting to learn and are not the âeverything-beside-[INSERT FRAMEWORK]-is-sh*tâ type From there, the process is:
a quick call to talk about tech and know a bit more about them and why they like what they are using at the moment (usually React or Angular)
we send them a small test and insist that they do it in whatever framework they feel productive with. We know that this makes us work a bit more when we review it because the we donât necessarily know the chosen framework and will go and check the docs. Itâs more to see how they approach the problem even if itâs a small one (implementation and testing)
we review it with them a couple days later but itâs still a discussion to know if they wouldâve done something differently if they had more time and ask a couple questions about some implementation details.
Once thatâs done and they joined us, we donât drop them on a project directly and let them play with Emberâs SuperRental tutorial and we are in case of questions.As @ef4 said, the learning curve for modern Ember is very modest. The only âproblemâ we tend to have is that they learn modern Ember, but land in a codebase with older code, which is a bit confusing.
Today, we are 3 devs on the frontend and Iâm the only one w/ 7 years of Ember, and my teammates come from Angular and React (and even teammates from backend take some frontend features from time to time). At some point in the onboarding, I also ask them how they wouldâve implemented some parts of the SuperRental app in their âusualâ framework and show them the âEmber wayâ.
just to give an update on our progress. Basically we are doing what you guys suggested. still recruiting emberjs senior devs though, also including more freelancer in our process which seems to work better. slow but steady growth so far!
From there, the process is: