Last year October 2018 I started a new position as a software developer contractor in Cape Town South Africa, The company Tech stack is full Microsoft with amazing software engineers, My key responsibilities focused on building small to medium features, support work, software delivery using Web API's, C#.Net, Asp.net Webforms, SQL and hands-on some DevOps stuff. As a developer, I spent most of my time on pair programming with seniors lead engineers, problem-solving while generating and evaluating realistic solutions.

Now before we kick start, here is a little bit about my background. I have been working in the software development industry for about 3 years and during this period I have worked for two companies and before that, I did some freelancing work right after I graduated. From freelancing, I joined a start-up company called Bountly which was a service, bridging service seekers and service provider platform. At Bountly I worked as a software developer intern, there I worked directly with the CTO for approximately one year, during this period I built the front-end portions of new features and lot of exposure to many aspects of the fast-growing startup. At this point, the company were sold, and I decided to move on, and so I discovered Code Collective, Code Collective is a software development consulting company, providing product ownership for ambitious tech first entrepreneurs.

There has probably never been a better time to be a software engineer than right now. Most businesses and organizations across the world make use of technology for their day to day operations. For some of these companies, their whole product/business is technology. Added to this is the fact that technology keeps advancing (new technologies and frameworks get released often). Businesses need to keep their technology up to date to remain relevant. Every person with internet access (which eventually will be the whole world) uses lots of apps and websites every day. All this has resulted in a massive demand for people with the skills to build software – the software engineers.

The demand and supply curve for software engineers is not balancing. As it stands demand is much higher than supply. A truly valuable developer is one of the hardest things to find for companies. If you are involved in recruitment you’ll know what I am talking about, the competition is fierce and candidates are constantly being baited from one company to another with promises of free gadgets, gym memberships, equity, remote contract work with 3 months off every year, along with some of the best salaries in the world.

Companies spend a lot of time in the hiring efforts for software engineers. If we step back and consider the reason you want to hire a software engineer at your company – ideally once you hire the person you want them to provide value at your company. You want a new software engineer to be productive as soon as possible and to be productive for the long term.

There’s nothing worse than feeling you are wasting your time. Imagine putting all your time, energy, and resources into hiring someone and then they never become productive or worse they quit within a few months. The cost of replacing a recently hired employee is 30-50% of their salary. Companies lose 25% of their employees in the first year, and all too often due to faulty employee onboarding processes. It is a waste of time, money and it is bad for your company’s reputation if an employee leaves early on. Skilled software engineers are so high in demand that they can afford the luxury of switching jobs as often as they like, which takes the importance of onboarding and retention to a whole new level.

When I looked at what would make great onboarding for software engineers I thought about what traits I believe make a good all-round software engineer. I then thought about how I could help someone develop those traits. I came up with 3 key areas to focus on once a new software engineer joins a company:

1. Tools / Technologies
2. Domain Knowledge
3. Soft Skills

I will drill down into each of these 3 areas, explain what they are and how to provide the ideal training / environment for your new software engineer to succeed in them.

Tools/Technologies

When looking at tools/technologies I am referring to the following:

1 What programming languages do you use at your company? Examples could be Ruby, C# or Python and many more. 2 What frameworks do you use at your company? Examples could be Ruby on Rails, Django or ASP.NET and many more. 3 How is the architecture of your systems structured? Do you have one monolith application or is your system split into multiple services. If your system is split into multiple services how do they communicate with each other? 4 What source control tool do you use and what are your workflows when using that tool? 5 How is your infrastructure set up? Where is your code hosted? Is this all done in an automated way or is it manual? 6 What build and continuous integration tools do you use? Where does code go to once a developer pushes it up? What runs the unit and integration tests? How does the code eventually get to production? 7. What coding standards and preferred practices do you have in place at your company? A software engineer may join your company having used similar technologies at a previous company but they will still need to understand your coding standards and preferred practices within those technologies.

So what are some of the things you can do to ensure a new software engineer gets up to speed with the things listed above?

Make real changes to the codebase

In the early days of a software engineer joining your company give them a chance to make a real change to the codebase that gets pushed to production. Even if the change is really small such as a text change to the view it will still be valuable. Making any change to the production codebase means the new software engineer has to checkout the codebase (exposing them to the source control tools), make the change and run the tests (exposing them to the structure of the codebase and how to run the tests), push up the code and run the tests on a build server (exposing them to the build and continuous integration tools) and finally deploy the change to production (exposing them to how changes get shipped to production). Any small change to the codebase allows a new software engineer to understand the full workflow of how something comes from being a requirement to being live on production. So give your new software engineer a chance to make a production change as early as possible.

Pair Programming

In the early days of a software engineer joining your company they should pair program on most tasks with a software engineer who has been at the company for much longer. Pair programming will allow the new software engineer to learn about your company’s systems as they will have someone experienced to answer any questions they have and show them how things work. Pair programming will also allow the new software engineer to build confidence as they will get a sense of involvement in the tasks they will be working on. Ideally you want the new software engineer to pair program with different team members so they get to know all their colleagues and also learn from a diverse set of people. The key learning here is do not isolate a new software engineer and leave them to solve problems by themselves as it can be frustrating.

Onboarding documentaltion

If your company has any onboarding documentation that could be useful to a new starter you want to share that documentation with them in the early days. It may be documentation that was specifically prepared to help new starters get up to speed, or it can be general documentation that is also useful to existing team members (such as current architecture diagrams). The important thing here is that any useful documentation is shared early on after someone has joined so they can consume it when they are eager to learn and get up to speed. An important thing to remember about any documentation is that it must be kept up to date else it may give outdated information. If your new software engineers identify any missing or outdated information in your documentation use it as an opportunity to update the documentation before the next person starts.

Learning resources list / Training Budget

A new software engineer may join your company having used different tools / technologies at their previous companies. You will need to help them with extra learning material for them to get up to speed with your tools / technologies. Your company should keep a list of known good learning resources a new software engineer can use to get up speed with your company’s tools / technologies. These learning resources could be a list of books to read, or online tutorials to take on. People have different preferred learning styles so find out from your new software engineer how they prefer to learn and point them towards the correct resources. Ideally your company has a training budget for its employees and allows the software engineer to spend some of that training budget to buy the books or online tutorials. Invest in training your employees and it will pay off when they become productive. An example of this in practice is when a new software engineer joins our company and has no Ruby or Ruby on Rails experience if they prefer books I normally recommend the Programming Ruby (commonly known as The PickAxe) book and the Agile Web Development with Rails book. If they prefer online video tutorials there are tools such as Pluralsite and LinkedIn Learning that also have good resources.

Domain Knowledge

If you successfully onboard a new software engineer on the tools / technologies you will have an engineer who is confident they understand all your technologies and can write code using the programming languages at your company. However software engineering is not just about writing code, it is more involved than that. The code that a software engineer writes must align with a problem their company is trying to solve and actually solve that problem once it is deployed to production. So every software engineer needs to have a good understanding of the business domain they are working in. When a new software engineer joins your company you need to educate them on what your company does, why your company exists, and what your company goals are.

Include training

Educating your new software engineer about the business should happen through some sort of business induction training. How this will happen in practice will differ with each company depending on company size, complexity of the business domain and which people in your company hold most of the knowledge. In some companies it may be enough for the new software engineer to go through the business domain with another more experience engineer who understands it well or the team product owner who may have more knowledge about how the business operates. In slightly bigger companies you can have more formalised induction training in place where each company department hosts a session and explains how they work and what their purpose is. The goal here is to ensure your new software engineer has a full understanding of the business as this will help them build the correct software, possibly suggest ideas that will help the business grow, or question requirements when they are asked to build features. You can only do all these things if you have a good understanding of the business.

Soft Skills

If you have successfully onboarded a software engineer on tools / technologies and domain knowledge you are almost done. You will be left with one more area. In a majority of companies these days people work in teams not in isolation. When a new software engineer joins your company they are likely to be placed in a team where they will be working with other engineers, quality assurance engineers, a product owner, and perhaps a scrum master if you are applying Scrum. Further to that your new software engineer is definitely going to interact with other employees from other company departments or the direct users of the software they build. This means every engineer needs to communicate and interact with other humans as they get their work done. This communication and interaction with other people is normally classified as soft skills. The last pillar of onboarding a new software engineer properly is to ensure you help them with their soft skills. This is usually the area most neglected by people in the software industry but arguably it is the most important. So how do you do help a new software engineer develop their soft skills?

Let them lead team reviews / company wide demos

Once a new software engineer has settled down at your company give them the opportunity to present the work they have been doing to other people. This can happen in the regular team review sessions or a company wide demo of the work their team has been doing. Allowing someone to present their work gives them the opportunity to grow their presentation skills and communication skills. A key skill every software engineer should master is being able to explain a feature they have built to a non-technical person without including any technical jargon in the explanation. Allowing someone to present their work also gives them the opportunity to show they understand the business and why they built the work they are presenting. Finally giving someone an opportunity to present to a wider business audience gives them visibility across the company, people will now know who they are and they can approach them later to chat about the work they presented.

Team building

To help a new software engineer settle into your company and build relationships with their new colleagues you must organise some team building activities. Arrange activities that take the team outside of the normal day to day work grind. The idea here is that people get to know each other outside of just solving work problems all the time. Your team can unplug, relax and chat about their lives and general interests outside of work. The actual team building activity is up to you and your team. It could be just post work social dinner / drinks, a braai or an actual booked fun activity such as go-karting. Whatever activity you choose the idea is to allow people some time off work to get to know each other and build relationships, this will likely translate to them working better together. For a new software engineer it allows them to get to know their new team members.

Pair programming

I’ve mentioned pair programming again here even though I listed it earlier in the tools / technologies section. I believe pair programming also helps one grow their soft skills as by its nature pair programming involves communicating and interacting with another software engineer. Coming up with a solution to a problem together and aligning with another engineer despite differing starting opinions helps cultivate good team relationships.

Workplace culture

Every company has a workplace culture they try to live by. I have listed this here as it is important for new software engineers to have good examples of how to act / behave according to your culture. In the early days a new software engineer will be watching and learning from existing employees. How you behave as existing employees influences a new software engineer’s future behavior. So all existing employees must be great examples of the culture you have set for your company.

At this point you will have successfully onboarded a new software engineer with tools / technologies, domain knowledge and soft skills. You have given them a big chance to bring value to your company and be productive as soon as possible and for the long term.

In summary the goal is for your new software engineer to write code, learn about the company, and get to know their colleagues.

My experience at Code Collective seeing the growth our engineering team focus on building high-values creative software. The principles and practices I have shared above are things we have tried and tested as I have seen the success of the team. I’m hoping they can add value to your onboarding process.

Additional tip

• Senior engineers need to be onboarded too. Onboarding well does not only apply to junior engineers.
• The average employee takes upwards of six months to become fully competent in their role. Don’t overwhelm people. Check in early and often. Set the right expectations when someone new starts at your company.
• Every person has their own learning styles so onboarding practices will be slightly different for each individual but the principles will remain the same.