How does your organisation train programmers?

Here's my usual playbook for onboarding engineers: Start by giving the person a high level overview of your systems and them let them go setup "company things" for the rest of the day. This gives the brain a rest from the technical stuff with menial work.

The next day, and throughout the first week, give them deeper dives into individual systems. Every time you do this start from the overview again, so they're reminded. Always keep it a conversation, go back to different parts when the engineer asks questions that show they haven't understood something you've gone over before. This is normal as you're unloading a lot of knowledge you've built over time. Make sure you keep focused on the mission of sharing knowledge and do not let yourself get lost into too many side chats about how your pet peeves are never prioritised to be fixed and how you hate technical debt - this is not the time.

Once they've setup their company emails and whatever your HR demands, start by giving them a simple task and leave them on their own with the expectation that they will reach out once blocked. Check if they're blocked yourself multiple times during the day. A new dev might be reluctant to reach out for fear of being perceived as too junior. Let them know this is not a concern, the concern is to ramp them up as soon as possible and questions are the best way to do it.

Remember to ask them about the pace, how they're feeling, what they're struggling with or if they're eager for more. Some people will prefer a few more days reading docs, others prefer to jump in to the work straight away. I've seen both approaches work and try to adjust myself to the way the person likes to work best.

Increasingly give them more complex tasks, have them pair with other engineers. Remember that not only you're onboarding them on the systems, you're onboarding them to the people. Make sure their work is throughly reviewed, take your time to explain why things are done in certain ways, take all oportunities to give further back context.

As time goes on, apply a similar playbook to give them extra duties, complex issues to solve, more permissions, etc.

PS: Grove's book is great, definitely recommend it

Training as a separate activity from normal work activities is not my mental model, and I expect many others. Rather, training should be interwoven in all of the daily activities that allow people with more or differentiated experience to share what they know with the others around them.

Code review is training. Do you consider training one of the primary purposes of code review? In my experience, different teams are highly variable on this. But avoiding bike shedding, explaining context and knowledge without dictating direction, and asking good questions shares knowledge and makes everyone improve.

Postmortems are training. Learning what went wrong and what could be done better next time is close to the definition of training.

Performance / peer reviews (when done well - a rarity) are training - they are a time to step back and think at a higher level about where there's room for improvement and what to concentrate on. Andy Grove explicitly talks about performance reviews as training: "giving reviews is the single most important form of task-relevant feedback"

If your definition of training only includes classrooms, learning budgets, conferences, etc than I encourage you to broaden your view as to what constitutes training. If these venues help you learn, then I hope your organization supports you access them. But don't mistake their absence or their low prominence for a lack of training with an organization

This simply doesn't apply to software engineering, for two reasons:

1) Training isn't a separate exercise from doing the work. We learn in this job, forever. Whether it is a new tech, a new codebase, or simply improving our skills, all coders learn almost every day. We all look back at our code from a year ago and realize how much we have grown.

2) When worrying about "the customer paying the tuition", coders aren't the problem. That concept is more a problem when a new tech comes out, and all the consulting firms will send you expensive consultants to implement it for you - clearly, they have no experience either, so you are paying full rates for their learning curve.

Now that I write it out, it seems like the key difference is whether you are creating tech, or consuming tech. Training applies to consumption, but creation is a completely different process.

I work for Red Hat, and Red Hat is the best at training I've ever seen (which you would hope for an org that sells training :-D).

"Enablement" is encouraged and provided liberally. There are pros and cons about Red Hat just as every company, but this is the first place I've been where I felt like I was the bottle neck in advancement. At past companies I had to buy my own books, build my own labs, etc. Red Hat provides a RHLS subscription for free to employees, which comes with labs and such (if you work for a company that gives RHLS subs to employees, you are really shorting yourself if you don't take it. It's amazing how many companies I work with as a consultant have available/purchased subs but no employees wanting to use them). There are also internal/partner resources as well. There is enough training available for free to employees/partners that you will never consume it all.

I've never worked for a company that trained programmers. You ether knew what you said you knew, or you didn't. Management would weed out the imposters in the end.

I am a bit rogue, and buy PDF books for my team on trendy tech, some applicable to their day to day, but mostly what is trendy in job postings.

I don’t try to hold them back.

I was also able to send a team member to SF earlier this year for a week to a ML bootcamp.

And last year, I got a few members from multiple teams to attend a 3 day state security con.

Beyond that, I do try to be a mentor, and try to engage by answering why we do what we do and the historical context of how we got there.

I guess I also have some informal documents that are part of a curriculum, but there is no official single source of truth.

Pair programming works pretty well depending on personalities and skill gap. I've learned a lot just by watching others code.

There are lots of things you can do, for example in my company I set up:

- weekly training sessions where devs share experience and what they've learned or organize workshops for each other

- book clubs where a group of people discuss a technical book/paper they're reading together chapter by chapter

- regular hackathons (I count them as learning) every 3 months where you can play with whatever tech you want

- I buy them practically anything they want in terms of education and encourage them to do it on our 1:1s

- the usual pairing of juniors and seniors for mentorship

- a #learn channel on slack where people post interesting new things related to our tech stack or insights

As someone getting onboarded now, getting left to compete a toy project using the tech stack the new company uses is working out well. Blockers sometimes happen, so regular check in are appreciated. It also helps to ask questions you can't really formulate into a Google search.

I don't know how others feel, but please don't overload me with more company info than needed. I almost certainly don't remember it. Let me fit in and find it in my own after the initial high level overview.

Here is your computer, here is your AWS account credentials, here is our Bitbucket with all the code. Here is our chat for any questions. You can dig through the Atlassian docs but there’s a lot of misinformation, plus only like 5% of our systems are documented. :(

My team does pair programming on >80% of all production code and has done so for the entire 18 years this product has been around. From entry level to architect, we find that pairing is the best way to reduce defects, get more features, and knock down silos. While it has downsides around keeping a coherent architecture and hiring, we're now the market leader in our niche and are holding fast. Meanwhile many competitors come and go as they buckle under the weight of the immense complexity of the domain.

I think for large and complex domains, it allows us a competitive advantage as our developer costs stay lower due to rapid onboarding and rapid growth of individuals. Very quickly our team members rise to the average skill of the whole team. We're a small team, and yet stay very effective as an aggregate over long time spans. Also the quality of the codebase stays extremely high, with very high test coverage and a robust CI process.

I consider pairing as another tool in the shed for dealing with large complex domains just like strong static typing, a good type system with union types and no nulls, static analysis, and unit testing. These are all impossible see if they impact productivity because software productivity is unmeasurable. However, I'd want all of them as competitive advantages in a large and complex domain. Plenty of people reasonably debate their value, but many domains aren't complex enough to warrant the extra costs.

I'd expect that if we were doing standard CRUD work, it would be overkill vs just throwing more bodies at the problem, but CRUD is a relatively small part of our product (large bank financial analysis and workflow)

We also do:

- reading clubs

- weekly 10% self-directed and dedicated research time

- additional research time with sign-off from a lead

At a company I worked for in the past, we simply threw them into the bug pit and reaped the ones who survived.

Let's face it, good programmers are usually not good teachers or mentors. And good teachers don't know about the specific stuff on your project.

We do pair programming for many years, it works pretty well in terms of training. The best part is you don't have to pull your hair off to come up with a perfect training plan (which most of the time does not very work as expected). You can consider skill is somewhat infectious, and then by pairing and switching pairs, the skill will naturally spread across the team in a passive manner.

If your project cannot afford pair programming, maybe you can exchange the training budget with just pairing with graduates or make it only happens in the onboarding period.

Organisations who actively pay for trainings are rare. I have been part of some (cryptography training, specific cloud training, etc.) But mostly, they don't forbid or they even encourage to share experience and provide time to read. For instance, I'm reading HN or other blogs aggregator during my work day. Or prepare presentation for my colleagues.

I don’t know if it’s the right thing to do but the consulting company I work for pays for all staff to do whatever online courses (Linux Academy, A Cloud Guru, Udemy etc...) that lead us towards getting certifications such as GCP or AWS certs (which they also pay for), personally i don’t agree with the ecosystem of proprietary certifications but on the other hand i do appreciate the opportunity to learn while being paid and the certs do help your future prospects for many people, additionally we can opt in to be sent to conferences such as DevOpsDays, BlackHat/Ruxcon, YOW etc... which they will pay for (within reason). They do so because they have a good hiring process where I truly believe they’re very good at only hiring committed and driven people.

Well if you believe in quality you should invest heavily in your engineers. Make sure they do things proper way, means if they are adding a button to your app , they should do like big boys do. Give them time and training for that. Even if they leave they will be thankful and always best advertisement for your company. There is a human factor in it, people think if they share everything they know they will loose the edge over their colleagues, such people are not team players, they are heros. We are still struggling startup but we spend so much time reviewing code, sharing tips and helping peers is core part of our culture. Engineer training is a culture not career phase.

My two cents.

My organization got a seat on the advisory committee of the local University's CS department and steers their curriculum to meet our business needs. Then we hire their graduates.

Here’s root access, heres merge privs in code review, heres a shard drive with recordings of past q&a sessions and a link to the wiki. Let me know if you have any questions!

For knowledge sharing in a remote team (been working 6y remotely), we do lot of videos sharing called Snackchat and Impromptus Knowledge Screencasts [1].

When there is a question, we give the answer, but also try to give the more context as possible , with a link to a document or slack conversation.

[1] https://erickhun.com/posts/sharing-knowledge-in-a-remote-tea...

Why train when your organization only hires the best of the best, ninja, gurus? When everyone is too busy knowing everything to ever learn something new. That way they're be so scared that someone will find out they don't know something that they'll secretly spend all their free time trying desperately trying to stay ahead and all of their work time treating each other like crap all while I play another round of golf.

A lot of Grove's management practice is mangled when applied to most companies, things like OKRs being a stunning example. That fashion seems to have replaced misaapplication of Drucker. In both cases, the philosophy is cherry-picked for the parts that seem to apply to profit and efficiency at the cost of the human parts that make them sustainable - things like training, focus on building continued relationships, etc.

In one startup I worked for the training went like this: "here's your laptop, there's the repo". It wasn't just done to me either.

>Of course, any time we do anything we "train" ourselves in it and get better at it, //

This isn't true AFAICT, we reinforce our method and knowledge - if that's wrong/limited then we reinforce a poor ability; I suspect that makes it harder to learn an improvement later. As I age I find I fall in to old habits even when I know better ways, the older way feels 'natural'.

> Of course, any time we do anything we "train" ourselves in it and get better at it

Practice makes permanent not perfect.

Not programming but I work in a Project Management Office in a global corporation. This company sends all PM’s and BA’s on a job-relevant training course each year.

This is the only company that I’ve received real training from in a ~15 year career

(I have had a few small 1 day or less internal courses.. “negotiations”, “leading people” etc)

- Sending staff to courses, conferences and meetups on the company's money, usually with a budget.

- Senior developers teaching juniors.

- Encouraging internal talks for whatever topic.

- Good internal documentation about processes, tools, and things to know in general.

- Dedicated time for research only, before starting to implement in unknown domains.

"trainning" ad-hoc: throw them inside a team, assign a couple tasks to them, and hope they will ask for help and someone will listen, when googling proves unfruitful...

Easy! It doesn't :(

My company gave me a task and said good luck!