.png)
One of the worst ways to start a developer at a new job is to have them immediately start coding on your project. Instead, the initial days of any new hire should be spent making sure they have sufficient knowledge and training to be successful once they start coding.
At Admios, we devote a few weeks to training and onboarding to ensure our developers unleash their full potential when they hit the terminal. Here are some of our best practices.
Sometimes the Obvious, Isn't
When training new developers, teams often miss the obvious. Can this developer communicate clearly? Can they learn new skills? Can they debug a problem? Instead of focusing on deep technical skills, begin with the basics to make sure they are covered.
- How to communicate and behave like a professional
- Specifically, how to make commitments - If I could teach all developers one thing it would be don’t agree to do something you aren’t sure you can do.
- How to function as part of a team - There’s a difference between arguing and being a jack ass. Encourage the former and fire the latter. - How to estimate their own velocity and track their time - You can’t make accurate commitments until you understand how long it really takes you to code.
- A basic understanding of various software development methodologies
What does a good job look like? Set standards early
Once the basics are covered make sure the developer has a clear sense of what doing a good job means. At Admios, we cover the following:
- How to use TDD/BDD - Before you can start coding you need to understand what your code needs to do. The best way to demonstrate that your code actually does what it's supposed to are tests that pass.
- What clean code looks like - Coding a solution that works isn’t good enough. It has to be maintainable code that anyone can work on. This is not the same for every language, but we set up a basic set of principles that everyone knows and can willing choose to violate if it’s appropriate in the stack they are working on. If someone can tell it's code you wrote, something is very wrong. Unlike literature, great code is anonymous.
- How to approach debugging - Inevitably, bugs will happen. It’s amazing how many developers don’t have a personal strategy for attacking bugs. Correct this immediately.
- How and why to use source control - Once you have code that works properly, you need to get it into the production system in a manner that doesn’t break the application. Properly managed source control is the answer. Source control tends to be a skill that developers learn on the job. Frequently, no one has spent time thinking about why it’s used and how it could be better.
Finally, make sure everyone learns how to learn
It’s just as bad to blindly embrace every new trend as to think that your single skill is the only appropriate solution. Technology is always changing. Developers should understand this and learn to think critically about new technologies. The best way to do this is to get them to improve the training as they are going through it. Ask for feedback and when they highlight problems have them search for solutions.
Shared knowledge creates a shared culture, or invest in your people and they will invest in you
At Admios, after we started our training program we noticed an unanticipated side benefit. Our training program had fostered a sense of teamwork that we had only experienced sporadically before. More experience devs started to naturally look out for the new hires as they went through the more difficult material and mentor them. Since they team had made an investment in them, everyone was more willing to invest in the team. At the end of the day, that’s the ultimate goal.
Are you looking for more devs? Nearshore software development might be a good fit for you!
