4 Key Steps for Successful Developer Onboarding
4 Key Steps for Successful Developer Onboarding
A developer’s first few weeks on a new project can be challenging. They're working with a new development team, learning new tools, trying to understand an unfamiliar codebase, and feeling pressure to get up to speed quickly.
If organizations don’t have an onboarding process in place, developers are left to their own devices to work through that big ball of mud and attempt to make changes without breaking things.
So, how do you set new developers up for success on Day One? How do you get them productive faster?
If you want new developers to be comfortable working on your product and confident in your company’s vision, it’s important to have a successful onboarding process in place.
Step 1: Boost confidence from Day One
Last week, CodeLogic’s Chief Software Architect, Brandon Tylke and Product Director, Eric Minick hosted the webinar, Getting New Developers Up to Speed – FAST. In this video, Brandon and Eric outline the current state of onboarding, the problems they’re seeing, and the practices they use and recommend to onboard developers efficiently.
Step 2: Get the basics right
Developers want to feel secure when they start a new position. Ensure your new hires feel welcome and supported from day one by setting up their laptop with the tools they need, confirming their system credentials are in place, and working with HR to verify their benefits and streamline housekeeping.
Get the basics right, so your new developer focuses on the work at hand instead of administrative stressors that delay productivity.
Step 3: Use a pairing approach
Working on a new codebase, especially in a remote setting, isn’t easy. Take pressure off your developer by pairing them with a seasoned team member. A pairing approach helps familiarize new developers with the team dynamic and the codebase. With an “onboarding buddy,” new team members can feel comfortable asking questions without feeling like they’re bothering the rest of the team.
Next, provide clear, up-to-date, and legible documentation so developers can understand the application’s history and where to make changes. Once you provide useful documentation they can implement, assign work-items with modest complexity, that set them up for success and play to their strengths. It’s important to give new developers internal code exposure without setting them up for failure.
Step 4: Provide a safety net
Mistakes happen. Invest in the testing process to make sure that when mistakes occur while a developer is still new, it’s easy to recover and remediate.
Brandon Tylke explains the testing process he uses with his team at CodeLogic:
“When we onboard a new developer, or any developer, they have the ability to do a full product simulation locally…We actually have a full test suite set up to run all of the tests so that not only does it work on [a team member’s] machine, it also works on CI/CD and [new devs] have confidence with the code [they’ve] worked on – that’s it’s not going to break the build or someone else’s build.”
This also includes setting up guardrails for coding styles and conventions and automating the path to production, so developers feel confident pushing code to production.
The code review process
The reviewer is then able to check the CI system to ensure that no new static analysis concerns have been introduced, that all tests have passed, that test coverage is at an acceptable level, that the code builds and runs on more than the developer’s system, and that no CodeLogic governance rules have been triggered. At this point, the reviewer can proceed with confidence that the code meets all baseline requirements and only needs to review syntax for readability and sufficient comments.
Integration branch tests
After a merge request is approved, the code is merged into a common integration branch where the CI system again builds and runs all unit tests. This ensures that the new code works not only on the developer’s branch, but also when merged with any code introduced by other feature branches.
From this point on, all code promotion is automated. After the integration branch tests pass, the code is promoted by the CI system to a QA branch, where both unit tests and integration tests run, and code is deployed into a QA environment where automated analysis occurs.
Master branch - QA process
Again, after all tests pass, code is promoted to a master branch where artifacts are produced and made available for release. This allows us to cut a release at any time, knowing that all parts of the system have been tested and work together as expected. Once we have created a release candidate, it is again deployed into a QA environment where automated analysis is run again and a final, manual QA process occurs.
The takeaway
While no process is perfect, this is the process that works for us and allows us to create and release new features to customers, at a steady and repeatable pace, without burning weekends.