new JuniorDeveloper()

I doubt that any of us had a painless initiation into the development world. Obviously we were expecting real-life tech to be planets apart from what we studied, but what we hadn’t braced for was the deep dive into client business rules and 3rd party integrations. As a new junior joins your company, fresh from graduation or their previous want-away career, they’re about to enter just about the most trying few weeks of their entire life. Forget taking a driver’s test – after 3 days at your first new JuniorDeveloper job, you actually wonder what you’re doing on the planet.

So how can we make the transition easier?

A Plan of Attack

The overwhelming feeling of the first few days is one of being lost. You have no sense of how much there is to learn, of how much is expected of you, or of how much progress you’re really making.

Draw up a list of technologies covered in your client products, ranked in order of scale. On the Microsoft pipeline for instance, you’ll probably end up with something like:

• C#
• MVC/EF
• Sql/Sql Server
• Javascript/Jquery/Ajax
• HTML/CSS

It’s tough to slot someone straight into an existing project, so you may want to have them spend 2 days creating a dummy project involving all of these fields. After reviewing the code, you can prepare a training battle plan to fill in the gaps.

The web is now well populated with tech training material, Codecademy and Pluralsight being two that come to mind. Also don’t forget the forgotten art of touch-typing – a basic efficiency skill that should be mandatory at all levels of your IT business – TypingWeb is free and will both measure and beef up your speed.

Additionally, let your training programme for future recruits grow organically. When you find existing developers showing a disturbing lack of knowledge on a key tech, go and add it to your future training plan straight away.

Social Adoption

The “welcome to the family” montage may be a little cute, but I’ve worked with juniors who never at any stage felt included. For every bright spark with natural social skills, there is an awkward stranger who requires you to actively manage their integration.

One simple mechanism is a schedule of one-on-ones. Set up specific meetings where the new developer can meet each of the staff they’ll be working with, in a 5 to 15 minute slot. It happens so often that you spend years at a firm and never get to know basic details about your fellow staff, details that can make a key difference in the way you treat someone.

Having a mentor is an obvious next step, identifying the go-to person when the junior gets stuck.

Survival Pack

Corporate culture can be learned the easy way, and the hard way. Avoid those agro moments by preparing a list of dos and don’ts at your business. Every new employee has a set of awkward questions they simply can’t ask (Can I look at a YouTube video? Can my phone ring? What if I have a doctor’s appointment? Is there flexi-time?) – a bit of early frankness can save a lot of awkwardness.

Define the Interruption Level

Remember those tough days – you were really stuck and didn’t want to go back to the senior dev, because the last “sorry to bother you, but” got an awkward look and sigh. So you faced the next scrum and they asked in a demeaning tone why you didn’t ask for help.

It’s in both the junior and senior’s interests to establish expectations. It’s rare that the arrangement will suit everyone, but when one of them must suffer, let it be clear who (hint: it’s usually the senior guy).

As a side note, I’ve found that other juniors are more willing to help than seniors – they’re more attune with the trivial need-to-knows that seniors assume everyone is born with. You don’t know until you know.

Watch and Learn

While I’m generally not a fan of pair programming, the value of having a new junior sit with someone is hugely beneficial.

What’s important is to get the balance right, because all that energy of your first dev job can be quickly extinguished with a week of watching someone fight with a technology you don’t understand. New juniors need to get their hands dirty fairly early on. What’s also great, in a cynical way, is where the junior takes the keyboard and the senior forces them to use the shortcuts – they will never get a better chance to learn the way of the master.

Also look at pairing again a few weeks in. Once the junior has become a bit more comfortable on their own, have them sit with a senior again, because they’ll be looking at skills and techniques they wouldn’t have noticed in previous sessions.

Thought Wiki

When I work on a new product, I write down my questions straight away. As an aside, I’ve found this to be a great way to test the software I’m being exposed to, as developers grow blind spots to bad features very quickly, and a fresh set of eyes is a great way to bring weak designs to attention.

Make a point of showing new developers how to organise their questions and then mark them off. I use Microsoft OneNote for my ramblings – it’s a great piece of knowledge-sharing and brainstorming software.

I organise my early impressions into categories like “Questions”, “To Do”, “Issues”, “Bugs”, and then use strikethrough to knock them off as they get answered.

Code Reviews

Code reviews are fundamental to the junior experience – even when they’ve written a piece of code that works, they debate in their own minds whether they’ve done it the right way. Equally, by the time you spot a horrible practice, the junior might have done so much copy-and-paste that the suggestion of a rewrite will provoke a letter of resignation.

It’s important to recognise that reviews are also an emotional process. Particularly in the early days, leave deliberate comments about the code that’s been written correctly. I’ve spent months as a junior assuming I was doing it the wrong way.

 

Want to know more?  Check our our software development technologies.

 

Eric Savage
Senior Developer
Think Tank Software Solutions