from Hacker News

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

by ziffusion on 11/5/21, 6:34 PM with 12 comments

• by karmakaze on 11/5/21, 10:42 PM

  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.

• by JasonCannon on 11/5/21, 7:31 PM

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

• by givemeethekeys on 11/5/21, 8:55 PM

  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.

• by Communitivity on 11/5/21, 7:02 PM

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

• by Graffur on 11/6/21, 1:39 PM

  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.

• by fdgsdfogijq on 11/5/21, 8:11 PM

  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

• by honkycat on 11/5/21, 8:32 PM

  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.