During the past couple of years I’ve had the honor to work with a lot of talented young engineers, who were doing their first professional steps. As a technical leader I was accustomed to work with professionals, that had long grown out of junior roles, so having to deal with the needs of newly graduates has been a new experience for me, and one that taught me a lot.
Grounding
A common theme with newly grads (with one exception) was, that they all thought they knew what they were doing (that actually kindof reminded me of my first years on the job as well). The thing here is, that they usually don’t. Some will have some experiences with writing software, some will have little experience, but none had the mindset and the abilities required to write production quality code. And – quite frankly – that’s okay. These people just finished their CompSci degrees, which usually will require some degree of programming, but, on a whole, the time they spent writing code is too little to gain significant experience there. Also: The usual exercises these people get assigned during their course lack the complexity found in even moderably large codebases. At last: They will usually get little to no feedback as to the quality of the code they hand in – at least in german universities people are graded by the degree to which the code solves the problem.
This latter bit – grading on pure problemsolving – is in my opinion, quite damaging, as it fosters a mindset where hacks are somehow okay, poor structure is negligible and a “this is my code, don’t look at it” attitude will thrive. The lack of feedback will also not help to somehow alleviate the mentioned issues.
In the end we’ll end up with new hires that sport an A+ degree, but will need a lot of training until we can even think about handing their work over to customers. This training is very straining for both, us, the “pros” and for the newhires. The latter will have to unlearn behavior that was acceptable for the past couple of years, while the experienced developers will have to muster a lot of patience.
Dealing with it…
So, how should one deal with a freshly minted CompSci major that has all the self-confidence of Donald Trump, but about the same degree of technical skills? During the past years I’ve adopted an approach that tries to humble our new hires a bit. In the first couple of weeks I usually let them do some excercises that – hopefully – have some business relevance, but are not critical. In these excercises I’ll slowly try to get them to understand what kind of codequality is required. For most excercises this will take several rounds of reviews and improvements. In some cases up to four reviews and reworks until the code is “good enough”. The important thing for me is, to never let them get away with even remotely shoddy work. The written solutions might not be optimal, but at this stage I want them to learn a craft, and that craft is to write readable code that is reasonably bugfree and does not cause any warnings. These three items are actually enough work to keep them busy for at least eight weeks.
I’m fully aware that this approach is very taxing (it is for me – in most cases I could’ve done the work that takes north of three days with this approach in a couple of hours), however I firmly that it is my responsiblity as a leader and mentor to guide young developers to a point where they can produce code to the highest standards on a regular basis, however this will need some investments, and – thankfully – my employer is willing to bear that cost.