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

I think original question is "How do you make devs grow when they are already couple years in the organisation?".

On-boarding is quite easy because you know what to teach to a person. It is obvious that person does not know your system and is willing to learn about it, because they are starting new job.

What to do with people who know your system in and out? How to get to know what they would be interested in learning? What would be thing they can learn so it aligns with company goals? How to teach a group of 10 devs without burning whole budget on useless stuff?

Sometimes it can be as simple as having lunch and learns. For awhile it seemed like every company I went to wanted to have one on Domain Driven Design.

Let employees do proof of concept work with new to the company technology and then do a deep dive presentation.

But personally, I don’t like to be “taught”. I prefer to learn on my own.

I had this view for a long time, and it seems common among engineers I've worked with and mentored. It's such a common view that I was advised never to use the word "teach" or "training" and instead say "knowledge share". And to some extent it is impossible to teach what can only be learned by doing.

But more and more I feel like the self-teaching learning curve is an S curve and we all approach diminishing returns. I suspect that in the right group of self- and mutually-motivated, highly talented people (not just engineers), one could level up significantly faster through coaching and interaction than through self study alone, no matter how much of an autodidact one is.

1. Proof of concept 1 or 2 people depending on the scope

2. Get Feedback

3. Iterate

4. Get Feedback

5. Is there consensus (either agreement or “disagree and commit”) to move forward? If no, go back to step 3.

6. Document process and best practices in the Wiki along with a model implementation. Of course this also goes through a continuous improvement process.

At the end of the day, results beat theory.

This is how we introduced most of our “cloud native” initiatives, security, logging, monitoring, a better configuration process, a CI/CD pipeline,Lambda, Fargate (serverless Docker), moved toward a more performant data store for OLAP processes (Redshift) etc.

There was just way too much theory and nothing to show for it before I and one other “architect” on another team basically pushed the issue with the backing of our then new CTO. We started to get a number of other people onboard. Amazingly enough, despite the stereotypes, our off shore contractors (who had been at the company for years before they started adding on developers in the US), were more aggressive about changing the status quo and doing things “the right way” when they had cover from us than the newly hired team leads right across the room.

When you have too many people trying to learn at the same time, some learn at a slower pace, some have different interest (I won’t go near the clusterf%%% of modern frontend development) and some don’t want to learn at all and just want to coast.

Things that seem wrong might be because they are wrong - people learning will be inclined to think they are the problem. Thorough review might reveal systemic faults.

It's worth pointing out that most of the advice is simple and hopefully self evident. Which is in itself a good thing - as we say about code KISS

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

Sometimes this happens directly, but quite often it's during daily "standups" (which we do sitting, via video, and it's as much socialization as work) we often talk about problems that people are having and give them suggestions. This tends to be most helpful to novice programmers, but we all benefit from it sometimes.

And assigning reasonable tickets is training, too. We also start out our junior programmers with easy bugfix tickets and give them plenty of time to explore the code, answering a ton of questions. Then we give them gradually larger projects as they show they can handle them.

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.

They certainly create new work... while consuming the knowledge gained from a solid engineering education.

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

What is the ramp up time expected too?

The company I work for now actually has fairly long tenure times, 4 years or more. There really isn't an expected ramp-up time. Each project handles onboarding their own way. "Hit the ground running, learn as you go." is pretty popular.

On complicated systems on large technical estates with varied or niche business requirements, a lack of training can be extremely counter productive.

A lack of progress often more likely indicates poor management than that the new employee is an "imposter".

At Travelocity I became a developer because I was involuntarily reclassify into development. If I wanted to keep my job I had to learn it. Any time tough challenges came up I was expected to train myself and figure out how to do it the right way. Copy/pasting from an external source or hoping some framework/tool would do my job for me were unacceptable. This line of thinking evaporated the moment I separated for a military deployment.

At Bank of America they will pay for you to attend some boot camp class about using some framework.

In absolutely every other case you were expected know what you needed the moment you walked through the door and there is never training or any other kind of professional growth once you get there. If you want to get better or learn some new school you are writing code on your own outside office hours.

That sets false expectations and bias in hiring and candidate selection. If you look at almost any posted developer open rec the listed qualifications are usually a list of tools, frameworks, and languages. Rarely is the list of qualifications specific to skills or performance.

The expectation is to hire a tool money that can turn a figurative wrench instead of an engineer who can create a more powerful/efficient system. The bias kicks in during candidate selection. The company knows it needs a capable candidate to be selected for the given set of requirements but there is no formal industry guidance to define any kind of baseline.

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.

If they spent 3 days on the PDF during work, I would have a talk.

But, an hour or two here or there, I have no issue with that.

- 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

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.

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

These are both really great ideas, and have the advantage that they work for people who prefer to work through new stuff in private. Sometimes, organizations seem determined to combine learning/exploratory stuff with team-building exercises (A lot of Hackathon-type end up in this bucket, for instance), and to my mind that can end up severely limiting the amount of quiet experimentation that happens.

How are (at least pre-Covid) the developers situated where it isn’t noisy?

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.

Hire people with exceptional communications skills and empathy. Then help them become good programmers. Problem solved.

Can you cite any source?

I've given several courses internally in my company. I found some concepts I knew well, I cannot make them digest easily. While some graduates understand it, while others are frustrated. Then when we are having lunch, I found some of the graduates can explain them to other people in a way they can understand - I missed many details which I would take for granted.

Maybe this depends on region? I've worked at 5 different companies in the EU, and every one of them reimbursed pretty much any kind of training I wanted (including physical courses, conferences, online courses and books). In fact, I regularly see software dev job ads that list a personal development budget as a benefit.

My two cents.

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

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

With training we reinforce our method and knowledge - whether good or bad. But even choosing a bad method you still get better but maybe hit diminishing returns faster. A good method lets you get better in a more sustainable way and avoid hurting yourself.

E.g. when an art teacher tells you to draw from your shoulder instead of fingers, wrist and elbow as almost everyone is used to. In the beginning you probably get worse and frustrated, but down the line it makes a ton of a difference having to ability to do so even if not needed for everything.

Practice makes permanent not perfect.

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)

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