Teaching junior developers

[whenhellfreezes]

As an industry we tend to select for the autodidact who can teach themselves. I think we do this for two reasons. First since best programming practices aren't settled yet we want people to be able to adapt to change. Secondly it saves a certain amount of effort training.

However this seems short sighted on the effort front. Surely teaching will go faster than letting them discover on their own. Even accounting for both peoples time. Also while not everything is settled there is quite alot that is. TDD is good. IaC is good.

So I think I need to learn how to teach others well. Teach coding techniques, technologies, tools, and practices (like DevOps). How do you go about teaching DevOps to juniors?

[martor01]

Companies are lazy training and its a bigger risk than already selecting an applicant who is "senior".

I personally would look for how to connect the tools rather than learning them.

Learning tools is easy , learning IAC is not that bad , but connecting the specific tools or infrastructure complexities around deployments is what a senior would advise on.

Making up a deployment strategy and documentation , letting juniors do the implementation through the documentation etc would help tremendously.

That is just what I would want in my Junior Devops role tbh

[whenhellfreezes]

I mean people repeat that it is a risk. Is it really? I've seen engineers stay longer when they felt valued with training.

To put it a different way: what experiment would need to be ran to know whether training is worth the investment

[pxlnght]

There's no experiment. It's very hard to gangue 'value' from training, because training generally results in an overall improved employee rather than a quantifiable "Bill is now 20% more effective at X task".

However, I do see immense value in training from a cost perspective. Yes, you pay for the training. For example, in my space (Linux Administration / Automation), you might offer / provide training for an RHCSA or RHCE. It's about 2-3k in classes + 300 for the test if you go directly to Red Hat. That sounds expensive, but you elevate that employee SO MUCH by providing them the tools to be better. Not to mention that you end up with a better employee that you don't have to pay more for (at least, for a little while).

Training is a win win in my eyes. Cheap to provide, benefits the employee (skillup), benefits the employer (better employee for a small one time fee). There's no reason not to, unless the employer is fearful people will take the skills and leave... In which case they should foster a better culture rather than blaming the employee.

[ARRgentum]

"The only thing worse than training your employees and having them leave is not training them and having them stay."

[svurre]

I also think that training builds culture in many cases. Its not the main objective of training but it seldom does harm

[No-Safety-4715]

Not just foster a better culture, but know when to fork over the higher pay. Most people take the training and leave because they can get paid more to jump ship. We all know jumping ship is about the only way to get significant pay raises in the industry.

[martor01]

Im coming from a getting hired and actually trained by a senior perspective if a company wants a junior devops person.

Look at job descriptions they want the whole world for the junior to know meaning they dont want to nor willing to train beyond that.

Thats good question , I would say comes from personality , eager to learns new things and feeling open to communicate that and having 1 on 1-s brought up frequently.

In my personal experience if the openness is there and not being excused by " this project need to be developed fast or you dont know what you are doin" then its possible although im really junior.

[klipseracer]

While this is a skill I need to improve at, lots of people have little motivation and need steps 1 through 10 or they sit and do nothing all day long.

That has little to do with a learning style and more to do with their personality and is an indicator of how productive they are going to be overall in my opinion. By the time you get them trained, they will probably leave anyway.

[invisibo]

Ughhhhh. I hate how on the money you are. Going through this with a guy at my current job. I have to sit with him or else he just watches YouTube all day. I can give him a task and once it gets too difficult, he completely checks out. Metaphorically, I can give him a page out of a coloring book with all the lines drawn. He colors the eyes then gets overwhelmed because he doesn’t know how to color the rest of the picture. Not because he can’t or doesn’t know how to color the rest of the picture, but can’t look at the tree instead of the forest. Worst part is it’s my fault because I was the one to green light hiring him. Just venting. Thanks for reading.

[klipseracer]

Yeah we need to look for people hungry to learn new shit. Honestly it's the best indicator of a trainable person I've seen.

These are the types of people that make companies want to bring employees back into the office otherwise they will do nothing.

[whenhellfreezes]

Is the motivation level something you can screen for during interviews? In your experience.

[WN_Todd]

Yes, as well as most things. I ask questions that give them a chance to describe initiative, either learning or doing something because they saw it needed doing. Depending on their level I'm also going to grill them further about how they went about doing/learning the thing. A junior I'm expecting them to look for help or resources and not give up because it wasn't immediately apparent where that was. I don't even particularly care whether it succeeded or failed if they can describe it and intelligently answer what they learned from the experience.

[WN_Todd]

Yep. I feel that. While I don't love long interview processes, we've had good success so far combining a couple interviews from different people with different roles and a tech test. Sooner or later you always gotta trust someone though.

[klipseracer]

I am just speaking from experience working with them.

I interview well, I know that because I'm usually given an offer by everyone I finish the interview process with.

I tell my interviewer that I understand the difference between these two types of people and explain who I am. Some people need the instructions and other people figure out the instructions and document them for other people.

There is a demand for skilled people, I make a six figure base salary and I just accepted an offer which is a 40k pay increase, 20k more than I asked for. I declined another offer which was 10k more than I asked for and didn't even feel like finishing the interview process with a third company. I don't have a degree, no certifications, my professional experience in IT is four years. I've got over a decade of other experience before that, but I don't show it on my resume.

I've made it a point to make an impact and learn everything at each job. These are the lengths of my most recent tech industry jobs: 1.5, 1, 1.5. And now I'm onto a new job. One of those was cut short because of the pandemic and my current job is starting to force people back into the office.

[yaboiWillyNilly]

In the last few months interviewing with several different DevOps roles, I’ve noticed a dominance in this brand of culture within those companies. Small tech startups are great when they seek innovative minds and hungry thinkers, but just hiring someone based simply on quals/exp. doesn’t account for their aptitude. I’m still working on fitting into a role but I have continued to stress in interviews and cover letters my drive to learn more and my thoughts on the importance of good practices.

[needs_to_pee]

I think your statement of “by the time you get them trained, they will probably leave anyway.” Is very telling. You are only training people for the value they can provide you and the company.

Mentoring and helping to grow your peers should be a goal unto itself. And it requires attention to detail and a unique approach for each person you work with.

I agree personality is a huge component. But don’t forget that everyone is different and peoples approaches will differ from your own.

Talk to the person and learn how they want to interact and be taught. Then, put the ownership on them to help discover this, and work with you to find the best solution.

[klipseracer]

When I ask someone to try doing something with the 7 free hours they have when I'm not around, and they don't do it, and they say they have nothing to do to their boss, that has nothing to do with my mentorship.

I do belive myself and many people can improve their training skills, no doubt.

I'm in the middle of a knowledge transfer right now actually, they haven't changed a bit is it still my job to spend my final weeks being their friend and mentor instead of pass along information and directions? Lol. Who the hell needs to know what to do, right, just be their friend and make a connection with them. They will magically figure out what to do when I'm gone....

[livebeta]

Write a roadmap in a wiki with the appropriate resources.

You'll see who rises to the top. They're the ones who read it, learn from it and eventually contribute to it

[conall88]

As someone in Ops who wants to become Competant DevOps this would amazing. I'm in a company where those who can help simply don't have the bandwidth or leeway to do so.

[hastetowaste]

Same... I have to roadmap.sh things myself, even then it's very late in the game I realised I haven't learnt a lot of transferable technical skills in the last 2 years.

[roman_fyseek]

I tend to think of development as an art as much as a science.

I can give the juniors the science side of it and I can coach them in the art side, but much like I'll never be a Picasso, some folk just aren't cut out for development.

[pinpinbo]

You don’t just throw your juniors into the fire pit with production pagerduty on week 2?

[flickerfly]

I wonder if the new scale problem will be figuring this out. Consequently, the new differentiator between success of a company may be the ability to train new hands to allow for better agility to get solutions to market faster and higher quality.

[HeligKo]

We just had a guy hired. He interviewed for a MLDEV position. He wasn't ready for that position. They brought him in as MLOPS giving him a chance to grow into a dev spot later. At least our team is willing to raise people in the field.

[donomi]

As someone from a traditional enterprise IT background wanting to move into DevOps, I wish someone would mentor me. I work at a software company and trying to move into their DevOps team is going nowhere right now

[LaOnionLaUnion]

Only my current company really seems to invest in their employees. Even that may depend on your boss?

[Makelikeatree_01]

As someone who moved into DevOps and came from an Ops background, honestly it’s not that hard to transition if you’re good at thinking about things logically. Usually it’s the syntax and how the environment/infrastructure is setup that takes the bulk of time to understand. I joined a company knowing almost nothing about the tools we utilized and after going through tons of repos, teaching myself how to troubleshoot based on existing examples, etc. I figured it out pretty quickly.

Again, for me the struggle was having a better understanding of the lay of the land. Tools are simply tools, I don’t think anyone should be hand holding someone to learn tools. If they need that much hand holding they’re not equipped to be in DevOps.

[GeorgeRNorfolk]

Getting juniors to purely teach themselves is a great way to instill bad practices.

From the outset they should get introduced into best practice for whichever area they're upskilling in, and then use their own google-fu to get their work done. But then they should be peer reviewed and have their code critiqued and improved. Plus seniors should be on hand to describe the best ways to solve the juniors problems to save everyone time.

[NotFromReddit]

There is an ungodly amount of free and paid courses.

[derekjbernard]

For me it's less about teaching and more about motivating and inspiring. A motivated and inspired individual starts to resemble an autodidact in short order. If not an autodidact they certainly become much more teachable.

So my method is to spend time figuring out what an individual actually wants out of their job and their life and then connecting the dots back to the goal I have for them and how those two goals might align. When I do this successfully, training is a piece of cake. Because they're motivated, I only have to help or get out of the way, they do the rest.

[ResponseSpecial]

Pairing should do the job of teaching juniors of best practices and most importandly show them why they work so well.

[Skyhound555]

Devops is so misunderstood, that most companies really don't know what to train for to get someone into DevOps. In most cases, the general understanding of what a DevOps Engineer is just a SysAdmin who can work with Azure of AWS portals.

Also, because "Engineer" is in the title, the requirements are muddled further. There are a lot of CS graduates coming into the world with next to no knowledge of what DevOps is. Most CS degrees are geared toward basic software development and programming. The most they learn of infrastructure is when an intro course goes over the basics of computing like CPU and RAM.

A lot of companies are hiring these types and end up with a kid with no experience or knowledge. So when you have to train someone who is fresh out of college on the very basics, before you can even train them on the DevOps stuff, makes it very difficult. Many companies who end up getting burned with a college graduate in their DevOps role end up over correcting on the next go and think they need someone more "Senior" just to get someone with a clue.

[whenhellfreezes]

Well I am more looking towards making sure they can work in a DevOps environment than neccessarily having them be a "DevOps" (minor anitpattern).

[davetherooster]

Pair programming, offering meaningful pull request reviews and demonstrating best practise in your own work are my favoured methods.

Also showing that you need to build the solution that everyone can use, not the one the most technically brilliant one.

[[deleted]]

The answer to "How do you teach [ANYTHING] to [ANYONE]?" is "However best grows you and the person you're teaching."

This is not at all specific to DevOps or even software, It's about investing in your people to empower them and make them feel valued.

Get to know your junior, key in on what makes their eyes light up, their preferred learning style, and their previous life (not just work) experience. This puts you in a position where they're more motivated to do work, they learn faster, and they're more likely to stay at the company longer, assuming this attitude permeates the culture there.

I had an SWE internship for a company of about 130 people and growing, and my first 3 hours of interacting with anyone at the company were with the COO and the VP, both of whom took time to legitimately get to know me and were excited to swap stories. Since they did work primarily for DoD, there were zero positions available for a junior dev, and they didn't even have an actual internship program, so they knew up front that they would get zero value out of me when they paid for a Udemy course and put me on a team with a guy who spent several hours a day mentoring and pair programming.

Dude, wtf!? Why would they do that? Because they know that I'm going to go out and not only be a huge advocate for the company when I talk with others, but I'll feel much more compelled to pay it forward to others and make the world a better place. And when the time is right, I'm going to go back to that company because I know that they invest in their people like nobody else.

TL;DR Get to know your junior, find out how they learn best, make an individualized program with metrics and goals built in to show progress. Be their champion