[Part 3] Developer onboarding: building smart habits

[Part 3] Developer onboarding: building smart habits

When a new person joins your team, everything comes at them all at once: new projects, processes, tools, technologies, and codebase. In this blog post series we talk about the best strategies that can transform a potentially overwhelming transition into a seamless and productive journey.

(1) Improving your developer onboarding approach
(2) Developer onboarding: best practices
(3) Developer onboarding: smart habits
(4) Developer onboarding: documentation must-haves
(5) Developer onboarding: documentation common mistakes

As the onboarding journey progresses beyond the initial stages, the focus shifts towards building smart habits that foster collaboration, skill development, and continuous growth.

This phase encompasses the adoption of pair programming practices, committing their first PR, embracing a mindset of ongoing learning, and developing effective debugging workflows. All setting the foundation for a developer's long-term success within the team and organization.

Pair programming


Pair programming sessions are a great way to familiarize your new hire with the overall codebase and coding standards. It's a practice that has long-term benefits:

  • It's a bridge to meaningful relationships: newcomers paired with mentors learn faster and build connections that drive collaboration.
  • It ensures team redundancy and knowledge sharing: at least two people are always familiar with different aspects of the system.
  • It results in higher quality code: the feedback loop is immediate instead of having to wait for pull requests.
  • It builds debugging intuition: new engineers learn how experienced developers approach problems, what they check first, and how they investigate issues systematically.

It's important to note that this is a collaborative exercise and not just a "watch me code" session. Passive shadowing should be alternated with hands-on practice in learning the codebase, development environment, and systems architecture, which is invaluable to building confidence in a safe environment.

In remote or hybrid settings, pair programming requires intentional setup. Use tools that support screen sharing, co-editing, and voice communication. Some teams find success with scheduled pairing sessions, while others prefer ad-hoc pairing through virtual "office hours." Find what works for your team.

Coding: the first contributions


To start, new engineers should be assigned 3-5 small, non-critical tasks that touch different areas of the code base. For example simple "technical debt" tasks, well-contained features, bug fixes, and test coverage. Alternatively, they could tackle sandbox projects where they can experiment, fail, and learn without fear.

The objective is to facilitate the developer's ramp-up with real, but manageable, work so that we can nurture their confidence and sense of achievement for contributing meaningfully to the team.

First PR guidelines:

  • Keep the scope small enough to review in 20-30 minutes
  • Ensure the task has clear acceptance criteria and definition of done
  • Assign a reviewer who will provide thorough, educational feedback
  • Celebrate the first merged PR!
  • Use the PR review as a teaching moment about code standards, testing practices, and team conventions

Building debugging confidence


One habit that often gets overlooked during onboarding is teaching new engineers how to debug effectively in your specific environment. Every team has its own debugging culture: some rely heavily on logs, others on interactive debuggers, and increasingly, teams use full stack session recordings to understand user issues.

Introducing new engineers to your debugging workflow early helps them become self-sufficient faster. Consider these practices:

Shadow a bug investigation: Have the new engineer observe (or better yet, pair on) a real bug investigation from start to finish. Walk them through:

  • How the bug was reported and triaged
  • What information you gather first (session recording, user reports, etc.)
  • How you reproduce the issue locally or observe it in production
  • The process for identifying root cause
  • How you verify the fix works

Practice on resolved issues: Give new engineers access to previously resolved bugs with their session recordings or debugging artifacts. Let them "solve" the mystery independently, then compare their investigation approach with what actually happened. This builds pattern recognition without the pressure of a live production issue.

Normalize asking for help: Make it clear that getting stuck is normal and asking for help is encouraged. Show them where to find documentation, who to ask for different types of questions, and what information to include when requesting assistance. The faster they learn to unblock themselves effectively, the more confident they'll become.

Document common gotchas: Every codebase has quirks: configuration issues that look like bugs, third-party API behaviors that seem broken, edge cases that trip up newcomers. Keep a running list of these gotchas and share them proactively during onboarding.

Ongoing learning


In tech, the journey of learning never ends. Your company should encourage you to dedicate time to online courses, workshops, and challenges… or just to reading documentation and exploring new tools.

Modern learning happens in many forms:

  • Formal training: Conferences, online courses, certifications
  • Internal knowledge sharing: Lunch-and-learns, tech talks, architecture reviews
  • Asynchronous learning: Documentation, recorded presentations, technical blog posts
  • Learning in public: Writing about what you're learning, contributing to open source, sharing insights with the team

Set clear expectations about learning time. Some companies offer dedicated learning hours each week or quarter. Others encourage learning through work: tackling stretch assignments, exploring new technologies through proof-of-concepts, or rotating through different parts of the codebase.

Drive collaboration from the start


As the previous sections show, there's so much more to onboarding than simply mastering the tech stack. Being productive also encompasses feeling valued and secure in asking questions, having all the resources you need to fully understand your team's domain, and being able to effectively collaborate with your new colleagues.

Driving collaboration from the start becomes even more critical now that most engineering teams are distributed. While the COVID pandemic certainly accelerated the global distribution of the workforce, the decentralization of teams is a trend that developed in parallel with the rise of global, highly-available modern software systems. Despite recent return-to-office policies, remote and hybrid work remains the norm: recent data shows that 71% of US employees prefer a hybrid or remote job, and this preference is even stronger among software engineers.

Effective onboarding of a new member to a distributed team necessitates a deliberate focus on fostering connections, building trust, and ensuring effective communication channels and tools.

Collaboration strategies for distributed teams:

Async-first documentation: Write down decisions, processes, and context so team members across time zones can stay informed without requiring synchronous meetings.

Overcommunicate intentionally: What feels obvious to experienced team members might be mysterious to newcomers. Explain the "why" behind decisions, share context liberally, and make room for questions in every interaction.

Create virtual water cooler moments: Remote work can feel isolating. Schedule informal hangouts, virtual coffee chats, or dedicated Slack channels for non-work conversation. Strong teams have social bonds, not just professional ones.

Invest in the right tools: Choose tools that support visual collaboration, effective asynchronous communication, and transparent workflows. Whether it's documentation platforms, design tools, or debugging systems, the right tooling makes distributed collaboration seamless rather than painful.

Make work visible: In an office, you can see when colleagues are heads-down coding or available for questions. In distributed settings, use status indicators, shared calendars, and regular updates to make work patterns visible and respect each other's focus time.

Onboarding new developers is a complex process and success is a team sport. To empower your team, choose the right tools for collaboration, establish communication best practices, and create an environment where new engineers feel supported as they build confidence and competence.


GETTING STARTED WITH MULTIPLAYER

👀 If this is the first time you’ve heard about Multiplayer, you may want to see full stack session recordings in action. You can do that in our free sandbox: sandbox.multiplayer.app

If you’re ready to trial Multiplayer you can start a free plan at any time 👇

Start a free plan