4 ms·

I used to organize corporate trainings. A basic [language here] one would take 2 weeks and barely get people comfortable with what they learned. You could do mo

by jiofih 5y ago

I used to organize corporate trainings. A basic [language here] one would take 2 weeks and barely get people comfortable with what they learned. You could do more with an intensive format of 40hrs/week, but to think you can train people in two weeks for completely different roles an have them come out effective employees is just... wishful thinking to be polite. If that was possible you’d see your peers changing career all the time to chase higher pay. The closest thing would be a bootcamp which usually are 3-6 months long, and again, doesn’t make up for the lack of work experience. Also we have no idea what kind of switch this would be about, so it’s pure speculation on your part.

specialist 5y ago
Sure. 3-6 months is usual for new hires, retraining. For comparison, I onboarded ~20 domain experts, pushing real code to prod in 1 week, unsupervised in 2. New language, new tooling, new stack, new specs, new clients. YMMV. > ...pure speculation on your part. Heh. Our part. After that CEO's video, I'm completely comfortable to assume more of the same.
- jiofih 5y ago
  When I say speculation, I mean regarding what retraining would entail. You’re assuming a simple switch in technology stack, when in reality there are varying degrees of difficulty in switching roles (eg web to native mobile development, FE dev to payment infrastructure, CRUD apps to high perf networking, and so on), some of which require years in experience to be effective. Or maybe they need 36 marketers instead, you can’t really “retrain” for a new BsC. There’s really no reason for a company to take the risk of “hiring” 36 juniors other than a vague sense of the company being indebted to them - which they’re not, if employees were well compensated and treated fairly. It’s a business relationship. You don’t owe them, they don’t owe you anything.
  - unity1001 5y ago
    The things you describe are not stack switches. They are domain switches. Domain switching is more difficult and some people may be unwilling to do so, but for especially senior devs, its still pretty reasonably doable.
unity1001 5y ago
Make it 3 months along with learning the existing codebase in addition to the stack. Still much cheaper than getting new people and building up them from scratch. The loss of product expertise and product-domain knowledge is a bigger kick in the balls of the organization than the amount of dollars shuffled in salaries with the change.

by jiofih 5y ago

specialist 5y ago

Sure. 3-6 months is usual for new hires, retraining. For comparison, I onboarded ~20 domain experts, pushing real code to prod in 1 week, unsupervised in 2. New language, new tooling, new stack, new specs, new clients. YMMV. > ...pure speculation on your part. Heh. Our part. After that CEO's video, I'm completely comfortable to assume more of the same.

jiofih 5y ago
When I say speculation, I mean regarding what retraining would entail. You’re assuming a simple switch in technology stack, when in reality there are varying degrees of difficulty in switching roles (eg web to native mobile development, FE dev to payment infrastructure, CRUD apps to high perf networking, and so on), some of which require years in experience to be effective. Or maybe they need 36 marketers instead, you can’t really “retrain” for a new BsC. There’s really no reason for a company to take the risk of “hiring” 36 juniors other than a vague sense of the company being indebted to them - which they’re not, if employees were well compensated and treated fairly. It’s a business relationship. You don’t owe them, they don’t owe you anything.
- unity1001 5y ago
  The things you describe are not stack switches. They are domain switches. Domain switching is more difficult and some people may be unwilling to do so, but for especially senior devs, its still pretty reasonably doable.

unity1001 5y ago

Make it 3 months along with learning the existing codebase in addition to the stack. Still much cheaper than getting new people and building up them from scratch. The loss of product expertise and product-domain knowledge is a bigger kick in the balls of the organization than the amount of dollars shuffled in salaries with the change.