Onboard a Developer in Their First Week
16 Jun 2026Not a toy task. A real, small, low-risk change that ships to production. Nothing builds confidence, theirs and the team’s, like seeing their name in the deploy log in week one. Delay that past two weeks and you’ve taught them that shipping here is slow and cautious, which becomes a self-fulfilling culture.
Day one: access and orientation, not architecture lectures
- All accounts, repo access, and environment set up before they arrive, not on day one while they watch you fumble with permissions.
- A working local dev environment by lunch. If setup takes longer than a morning, that’s a broken onboarding doc, not a hard problem — fix the doc, don’t just walk them through it verbally again.
- One person assigned as their point of contact for the week, not necessarily you, but someone specific, not “ask in Slack.”
Day two and three: read code by changing it
Skip the “read the whole codebase” instruction — nobody retains an architecture tour with no task attached. Instead, assign a small real bug or a tiny feature immediately. They’ll read exactly the code that matters, motivated by a concrete goal, and remember it because they used it.
The first PR checklist
- Small enough to review in one sitting — under 200 lines is a reasonable target.
- Touches a part of the codebase with existing tests, so they see the testing pattern in context, not in the abstract.
- Low blast radius if something’s wrong — not the payments code, not the auth flow.
- Reviewed same-day, with comments that explain the “why” behind each suggestion, not just the fix.
What kills week one
- No clear first task. “Look around and see what interests you” sounds generous and is actually paralyzing for someone who doesn’t yet know what’s safe to touch.
- Silent code review. A PR that sits for two days with no comment reads as “nobody’s paying attention here,” even if everyone’s just busy.
- Too much documentation, too little context. A thousand-line onboarding doc gets skimmed, not read. A short doc plus a person to ask beats a long doc every time.
The Friday check-in
Fifteen minutes, informal. Ask three things: what confused you this week, what took longer than it should have, and what you’d fix about this onboarding process if you ran it again. New hires see friction that everyone else has stopped noticing — that feedback is the highest-value thing they’ll give you all month, and it decays fast once they’re used to how things work here.
The actual success metric
Not “did they finish the reading list.” Did they ship something real, did someone review it kindly, and do they know who to ask when they’re stuck. Everything else is scaffolding around those three things.