[borgia]

>Training in this industry is basically a lie told to children. It doesn't exist at startups and barely exists at corporates.

Should it really though? As developers/testers/whatever position we occupy in the tech space, most of us are pretty good at picking up new languages/technologies/frameworks/tools etc. in a pretty short amount of time.

Personally I think having well working teams with not only people of solid experience at the helm, but who have good communication skills and enjoy sharing knowledge, is far better in terms of developing juniors / new developers than simply sticking them on a few formalized training courses every year. Throw in collaborative 10%/20%/etc. time and you've a recipe for good development teams, in my opinion.

Now, when you're talking about transitioning from a development position into project/team management and above, there should be training/mentoring/etc. provided, but in terms of core tech skills I don't think formalized training is the way to go.

[forgottenpass]

Should it really though? As developers/testers/whatever position we occupy in the tech space, most of us are pretty good at picking up new languages/technologies/frameworks/tools etc. in a pretty short amount of time.

Yes, it should exist. You've argued against whatever image of formalized training you seem to have a problem with, but provided a decent argument training (in general) should be provided. If developers are expected of to continually learn new things, and it can be done in a short amount of time, it is all the more reasonable for the business to treat that as training and budget time and money for it as such.

The types of gaining knowledge that you acknowledge in your post are "a few formalized training courses every year" and "good communication skills and enjoy sharing knowledge". You seem to be ignoring the large band of training that exist between those two. Which is also the where most ongoing learning happens.

Good communication skills and "collaborative time" allocated with percentages pulled from your rear is a fine (if slow) way to get people up to speed with the tech used at the office. But only serves to poorly normalize knowledge across the office.

[eropple]

> Should it really though? As developers/testers/whatever position we occupy in the tech space, most of us are pretty good at picking up new languages/technologies/frameworks/tools etc. in a pretty short amount of time.

Given the amount of loyalty companies expect workers to have and the possessiveness when they're hired away by better offers--to the point of calling it poaching, a word whose historical connotations are those of stealing animals from someone else's land!--yes, I think a modicum of giving a shit about your employees and deigning to train them is certainly in order. If you're going to treat people like chattel, at least treat them well.

[FLUX-YOU]

Yeah it should. Feedback is good for learning and hopefully training has some of that. I don't think learning to code in a bubble where you can just get everything working is good long term. Code reviews alone are enough training for some people though.

[pjc50]

most of us are pretty good at picking up new languages/technologies/frameworks/tools etc. in a pretty short amount of time

Isn't this the other way round? Because there isn't a reliable path to teaching programming to people who aren't self-motivated solo learners, that's the only kind of person who acquires the skills, and so when you look around a tech workplace that's the kind of person you see.