
Ask HN: How does your organisation train programmers? - kqr
In <i>High Output Management</i>, Andy Grove stresses the importance of training staff in their duties. In fact, he lists it as one of only two methods of improving performance (the other pertaining motivation).<p>Of course, any time we do anything we &quot;train&quot; ourselves in it and get better at it, but if this was the only training one had, it would be what Grove discourages and refers to as &quot;the customer paying the tuition.&quot;<p>So, clearly, Grove refers to actual, explicit training that is not simply learning on the job. He never goes into detail about how to do this; I assume because it&#x27;s such an obvious, in-grained thing in all other disciplines that it needs no details.<p>Yet I&#x27;ve never seen it done in software engineering. So how does your organisation do it? Why do you think it works? What have you tried that didn&#x27;t work?<p>Have you decided not to do it? Why?
======
vasco
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

~~~
ozim
This answer is sound but for different question.

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?

~~~
scarface74
For technical subjects just give me a reimbursement for training materials -
Udemy, PluralSight, O’Reilly, etc.

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.

~~~
nitrogen
_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.

~~~
scarface74
My favorite way to learn is iterative.

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.

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

~~~
wccrawford
In addition to that, answering questions is training.

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.

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

~~~
kqr
Are you implying that Intel's microchip architecture engineers were doing a
job qualitatively different from software engineers of today? That they were
mainly consumers of technology, and not creating it? Genuinely having trouble
understanding your response.

~~~
codingdave
That is a good question - I'd say that yes, they absolutely are different than
software professionals -- their level of work brings in some aspects of both
categories - they consume/use their engineering education, then create new
work based upon that foundation, and have a combination of skills from both
their training and their experiences.

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

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

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

~~~
mesaframe
What about things people they say they don't know. You can't expect everyone
to know everything. You definitely want people to work on things after
company's has taken them on onboard.

~~~
the_hoser
If they didn't have a skill we needed, then they didn't get hired.

~~~
kyawzazaw
what is the size of your org and what is the average tenure there?

What is the ramp up time expected too?

~~~
the_hoser
They varied. The one I currently work for is fairly large (~300 people in
software and product, which constitutes maybe 1-2% of the total number of
employees). I've worked for larger and smaller companies, though.

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.

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

~~~
myth_drannon
Do they read these books on the job at a separate dedicated time?

~~~
dillonmckay
If they have some downtime, but I do not explicitly block time.

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.

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

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

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

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

~~~
matfil
_\- 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.

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

------
greenie_beans
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. :(

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

~~~
mesaframe
> good programmers are usually not good teachers or mentors. And good teachers
> don't know about the specific stuff on your project.

Can you cite any source?

~~~
namelosw
Unfortunately, no. That only comes from personal experience and the
experiences from all the project which tried to train people.

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.

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

~~~
sunaurus
> Organisations who actively pay for trainings are rare.

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.

~~~
comprev
Perhaps it's related to some EU employment law about "career progression"?

Every contract I've signed certainly had such things in there.

Often employers say they'll pay for exams but not allocate study time during
your working week.

~~~
alfiedotwtf
I’m not sure how it is now, but in Australia a while ago, I’d you wanted to
import workers because you couldn’t source talent locally, you also had to
train your local staff to justify visas

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

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

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

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

------
deeblering4
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!

------
eric_khun
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...](https://erickhun.com/posts/sharing-knowledge-in-a-remote-team/)

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

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

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

~~~
smoe
I think both are true.

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.

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

Practice makes permanent not perfect.

------
ssss11
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)

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

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

------
taigi100
Easy! It doesn't :(

------
sushshshsh
My company gave me a task and said good luck!

