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?
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.
https://www.remotemobprogramming.org/ https://www.agilealliance.org/resources/experience-reports/m...
- 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.
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).
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.
