Ask HN: How do you best utilize inexperienced software engineers?

[ziffusion]

I fully get that a lot of less experienced software engineers are likely extremely smart and capable. So no offense intended.

Some of you may agree that some of the more subtle nuances of software architecture, structure and development take some time to get a handle on.

Given that, how do you best utilize inexperienced software engineers? How do you control architecture, structure and software quality without stifling individual creativeness or creating a perception of oppressiveness?

How do you guys pull off your magic as team leaders and managers?

[karmakaze]

Pair programming. I know of no better way to level up engineers. The more senior of the pair is also often learning too, especially if you rotate pairs so that the inexperienced one has recently picked something up from another senior.

And if anyone's concerned about a drop in capacity, I invite giving it an honest go and seeing for yourself. Whatever is thought to be lost is more than made up for in quality, reduction of miscommunication and building the wrong thing less often. Another big boost is the ability to maintain a 'flow context' despite interruptions, as well as much less 'down time' not moving in any direction. Some individual quiet thinking time does need to be reserved though.

[JasonCannon]

My team uses mob programming to do all of our work. So we have our Jr developers working on the same projects with our Sr Developers. This creates a ton of opportunities for knowledge transfer, mentorship, learning, and growth. We provide the opportunity for Jr's to grow and try things out not only via osmosis of working alongside more sr developers, but I will occasionally ask the Sr developers to step back, and allow the Jr's to take the lead on making decisions, and only step in to provide guidance or point out potential flaws with going down a route.

https://www.remotemobprogramming.org/ https://www.agilealliance.org/resources/experience-reports/m...

[peakaboo → JasonCannon]

I still laugh and shake my head at mob programming. It's completely exhausting and ridicolous. I tried it once and ended up spending the entire day being interrupted and talking instead of thinking. I didn't get a single minute to think alone.

[JasonCannon → peakaboo]

Our entire team loves mob programming. We don't think alone really, we talk things out and discuss things as a team. But our productivity has increased, we all leave the day tired but feeling good about the work we accomplished, it keeps us all honest with our work (no skipping unit tests, no writing bad/confusing code and calling it good enough, constant refactors). We committed to doing it for 2 weeks back in May, the first day was rough, but by day 3 we were all in. None of us want to go back to doing solo development.

[HellDunkel → JasonCannon]

So you have like 10 developers staring at the same all day? How big is your code base and what programming language do you use? How do you know everyone loves it?

[JasonCannon → HellDunkel]

5 devs. Code base is roughly 50k loc. C#/JS/HTML/CSS.

I know everyone loves it because I implemented mob programming as a trial run. We were going to give it 2 sprints (2 week sprints, so 4 weeks total) to see how it affected things, and see how we liked it. I asked my team to commit to doing that, and they agreed. In the beginning one guy stated that he didn't think he would like it, as he was an introvert and didn't think he could spend all day with everyone on a call working together. We setup rules stating that if someone needed to take some time in the day to themselves and work on their own things they could, no questions asked. He never once took that time. Occasionally there are break offs where 1 or 2 people will go tackle something else, but that's only ever to take care of an issue that would distract the rest of the mob from working on the task at hand.

We also have a team retrospective at the end of each day. We ask what went well, what didn't go well, and what should we change for tomorrow. By day three almost everyone was fully on board with mob programming. By the end of the first sprint we decided unanimously that we didn't need the second week trial, this is how we wanted to work. I went to the introverted person privately after the fact and told him I understand that when the team is all in on something it can feel weird being the only one not wanting to do it, so I asked him for his honest feelings on it. He told me that while he is drained at the end of the day, he much prefers working in this way instead of working alone. I have checked in with him a few times since then, and it's only become easier on him.

In September I had one on ones with my team. I asked each one of my team what their opinions were of the company, what their opinions were of mob programming, and what their opinions were of me as the team leader. A few people grumbled about how our sales team doing what sales teams always do. But they all said that they are happier working here than anywhere they've worked before, that mob programming has been a game changer and that they dread their next job, because they will have to not do mob programming, and that they felt like I was the best manager they've ever had because I actually care about my team.

I've built a relationship with my team over the last year that I've been their leader, and many of them for the year prior before I was their manager (before that, it was just me and another employee). We've built a culture where we all treat eachother as equals, whether they've been here from the beginning (me) or people who are brand new. We openly discuss issues and frustrations that we have, and work through them together. They have had issue with some things that I've done as leader, that they've discussed with me and we've addressed and fixed. So I know it's not just them being too afraid to say they don't like mob programming or whatever.

[givemeethekeys]

The following has worked well for junior software engineers wherever I've seen it implemented:

- Put them on bug fix duty first. There's a lot to learn here both technically and soft skills too.

- Set aside smaller projects - perhaps not the main driver of business, but nice to haves that one or two people can tackle and give them a chance to own them.

- Pay attention to what they're showing interest in - perhaps it is software, but you never know, perhaps it is another role entirely (project management, support, testing, product management.. who knows.. maybe they really like the business side). If that's what they're drawn to, then suggest that they talk to other teams.

[Communitivity]

There are three types of inexperienced software engineers. There are the ones who want to learn and grow, and that is split into the ones who are also willing and able to put the time into it (let's call them A s), and the ones who aren't (let's call them A' s). Then there are the ones who do not want to learn and grow (let's call them Bs).

An A or A' can be coached and mentored. Even some Bs can be motivated into becoming As or A's. The Bs that can't should be cut loose.

Realize that these individuals are like a tiny seed. They require lots of water and attention to grow. When they do grow though, they can grow into a tall oak that provides shelter for others to grow (ok, forestry majors please don't rain on my metaphor, I know about crowding). In my experience having mentored more than a handful of people (maybe more than two), the experience is very worth it. There will be some bad apples that sour the experience for a bit, but most people are either As or A's that want to be As).

A common mistake is to tell them what to do and how to do it. This is sometimes needed, but stunts their growth. As you do things, show them how you did it, explain your decisions. Then give them tasks (smaller at first). The growth from entry level code, to developer and sr dev, to software engineer and sr sw eng, to system engineer and beyond is in many ways and expansion of the complexity that the individual can handle thinking and reasoning about. So start with a function or set of functions, graduate to a class, a module, a package/namespace, a service, and then an app. Or whatever similar ladder makes sense for your domain, language, and product.

Do design and code reviews. Be gentle - these reviews may be looked on as the storm a tiny sapling has to weather. Don't say this is wrong on designs. Instead ask them why they decided to do it this way. Ask them 'what would happen if X', etc., and lead them to come to their own conclusions. Do enforce a coding style and good habits (such as PRs, code reviews, unit testing).

Realize that experience or inexperience is relative. To the 52 year old that's been coding since he was 11, in the domains he's coded in many people are inexperienced.

Also realize that experience is not just relative but scoped. The same 52 year old walking into a FPGA shop is a rank noob, and should know it (if they think they aren't then that's another problem, and often worse than inexperience).

[Graffur]

When I was inexperienced the best thing for me was to be paired with someone very experienced in a mentorship type of way. We would get a task and he would do it with me watching and asking questions. After learning a bit I would do similar tasks myself and still ask questions if I got stuck.

[fdgsdfogijq]

The way big tech does it is hire top engineers at like 500k a year, and then have them watch every CR from a team of like ten junior engineers. The model scales well, you just need a top knotch lead who is relentless about quality

[HellDunkel → fdgsdfogijq]

I would like to know more about this. Can you point me to sources of tell a little if your own personal experience?

[honkycat]

Don't hire Jr. engineers to save money. They are useless for a LONG time. Hire them to give mid-level engineers a chance to develop leadership.

Have them pair program basically all of the time.

Watch their PRs like a hawk and don't be surprised when you have to do 5 revisions for simple features.