Ask HN: How does your organisation train programmers? | Hacker News Reader

Ask HN: How does your organisation train programmers?

123 pointskqr64 comments

In High Output Management, 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).

Of course, any time we do anything we "train" 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 "the customer paying the tuition."

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's such an obvious, in-grained thing in all other disciplines that it needs no details.

Yet I'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't work?

Have you decided not to do it? Why?

View on HN

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

This is fantastic.

That's an awesome approach! I wish all tech companies followed this or similar approach. The faster you get a new member on-board the faster they'll start creating value.

This is an extremely concise clear set of instructions of how to give instructions to a newcomer. It's extremely well written - thank you! If this is reflective of your actual on the ground onboarding then your team members are lucky to work with you

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

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?

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.

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.

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.

I agree with thorough review. As I've been initiated recently into a new company I've felt it's a great time to get a deep review - potentially from an expert - of ingrained/embedded systems. In theory you have someone, you deem as competent, taking a fresh view of all your systems to a deep level.

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.

I know this is a 8 day old comment but I just wanted to say it is fantastic. I've had the unfortunate situation of graduating and only ending up in workplace that treat the new guy with content only. But after managing myself I'm in a position where a new guy start soon and I'll definitely keep this in mind when I interact with him!

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

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.

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.

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.

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.

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.

There's a whole lot of job requirements that don't involve knowing how to program.

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

Maybe so, but I've never worked for a company that trained programmers. It was always assumed that the wonderful open office plan will facilitate the transmission of tribal knowledge like that.

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.

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

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

What is the ramp up time expected too?

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.

I have only seen software training twice in my career.

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

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

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.

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

It might work for you, but I wouldn’t work for a company where I had to spend 80% of my time pair programming. We could discuss architecture and high level requirements.

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

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

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.

> good programmers are usually not good teachers or mentors

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

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

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.

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.

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

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.

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

Anything really? Say you work as backend developer, would they pay a training on machine learning or computer vision?

I worked as a backend developer and got reimbursed for both a JS course and a machine learning course. As long as you can provide a plausible reason why it makes you more effective, managers are usually more than happy to sign off on it. In this case it was pretty straightforward to come up with a good story on how understanding adjacent product development areas would make me a more effective dev.

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

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.

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

Reply on news.ycombinator.com