React Developers Onboarding Checklist: Your Essential Guide to Getting Started

Neo

2022-01-01•7 min read

React Developers Onboarding Checklist: Your Essential Guide to Getting Started

Welcome to the team! This checklist is designed to help you get up to speed quickly and efficiently. It covers key areas of our development process, communication channels, and technical stack. Feel free to ask questions at any point – we're here to help you succeed!

1. GENERAL & PROJECT OVERVIEW

Let's start with the big picture to set the stage.

  1. ✅ Is this a greenfield project or an existing one?
    • Why it matters: Understanding if you're building from scratch (greenfield) or contributing to an established codebase helps set expectations for initial tasks, tech debt, and learning curve.
    • Example: This is a greenfield project, so we'll be making a lot of foundational decisions together.
  2. ✅ Who are the key team members and their roles?
    • Why it matters: Knowing who's who (e.g., project manager, tech lead, other developers, QA) helps you understand the team structure and who to approach for specific questions.
    • Example: Meet Sarah, our Tech Lead; John, our Backend Engineer; and Emily, our QA Specialist.
  3. ✅ What will my first 30 days look like?
    • Why it matters: Getting a clear roadmap for your initial weeks helps you prioritize learning and feel productive from day one.
    • Example: Week 1 will be setting up your environment and exploring the codebase. Week 2, you'll pick up a small bug fix.

2. COMMUNICATION CHANNELS

Knowing how and where the team communicates is vital for seamless collaboration.

  1. ✅ Real-Time Communication:
    • Which platform do we use?
      • Slack, MS Teams, Discord
    • Why it matters: For quick questions, urgent discussions, and daily banter.
    • Example: We use Slack for all real-time chat. Our main channels are #general, #frontend-devs, and #random.
  2. ✅ Task Management:
    • Where do we track our work?
      • JIRA, Trello, Asana, Linear
    • Why it matters: To see current tasks, project progress, and what's coming next.
    • Example: Our sprints and tasks are managed in JIRA. You'll find your initial tickets in the 'Onboarding' epic.
  3. ✅ Code Collaboration & Reviews:
    • Which platform do we use for Pull Requests (PRs)?
      • GitHub, GitLab, Bitbucket
    • Why it matters: This is where code changes are proposed, reviewed, and merged.
    • Example: All our code lives on GitHub. Please open a Pull Request for any new feature or bug fix you work on.
  4. ✅ Email:
    • What kind of communication happens via email?
    • Why it matters: Often for official announcements, external communication, or less urgent, longer-form discussions.
    • Example: Email is mostly for company-wide announcements and external communication. Keep an eye on your inbox for HR updates.
  5. ✅ Meetings:
    • What regular meetings do we have?
      • Stand-ups, Sprint Reviews, Retrospectives, Planning
    • What is their frequency?
    • Why it matters: To sync up, discuss progress, address blockers, and plan future work.
    • Example: We have a 15-minute daily stand-up at 9 AM EST and a weekly sprint review on Fridays.

3. DEVELOPMENT WORKFLOW

Understanding the rhythm of how code moves from idea to production.

  1. ✅ What's our Agile methodology?
    • Kanban, Scrum, or a hybrid approach?
    • Why it matters: Knowing the methodology (e.g., fixed-length sprints in Scrum vs. continuous flow in Kanban) helps you understand the team's pace and planning.
    • Example: We follow a Scrum methodology with 2-week sprints.
  2. ✅ Do we do code reviews?
    • Why it matters: Code reviews are crucial for quality, knowledge sharing, and maintaining code consistency.
    • Example: Yes, all code goes through peer review. Aim to get at least one approval before merging.
  3. ✅ Do we use feature branches?
    • Why it matters: This defines how new features or fixes are isolated during development before being merged into the main codebase.
    • Example: We use a feature branching strategy. Please create a new branch from develop for each task.

4. API & DATA

Connecting the frontend to the backend.

  1. ✅ What kind of API does our backend offer?
    • REST, GraphQL, gRPC?
    • Why it matters: Determines how you structure your data fetching and interaction with the server.
    • Example: Our primary API is a RESTful API. We also use GraphQL for some specific queries.
  2. ✅ Where can I find the API documentation?
    • Swagger/OpenAPI, Postman collection, internal wiki?
    • Why it matters: Essential for understanding available endpoints, request/response formats, and authentication.
    • Example: You can find our API documentation at docs.our-api.com/swagger and also a Postman collection in our shared drive.

5. UI/UX & DESIGN

How we translate design into user interfaces.

  1. ✅ Should I aim for "look good" or "pixel-perfect"? ⚠
    • Why it matters: Understanding the fidelity expectation saves time and rework. Some teams prioritize speed, others strict adherence to design.
    • Example: For new features, we aim for pixel-perfect implementation based on the designs. For quick iterations, 'look good' is acceptable initially.
  2. ✅ Where do I get the mockups and design assets from?
    • Figma, Sketch, Adobe XD, Zeplin?
    • Why it matters: This is your source of truth for visual implementation.
    • Example: All our designs are in Figma. You'll find the link to the project in our JIRA tickets.
  3. ✅ What color scheme, fonts, and assets should I use?
    • Design system, style guide, Tailwind config?
    • Why it matters: Ensures consistency across the application.
    • Example: We have a comprehensive design system documented on Storybook, which includes our color palette, typography, and spacing.
  4. ✅ Are we using in-house icons or an external library?
    • Why it matters: Knowing where to find and how to use icons is key for UI development.
    • Example: We use a mix of an in-house SVG icon library and React-Icons for common generic icons.

6. FRONTEND DEVELOPMENT SPECIFICS

Diving into the React stack and development practices.

  1. ✅ Which core libraries and frameworks do we use?
    • React version, Next.js, create-react-app, UI libraries (e.g., Material UI, Ant Design, Chakra UI, Tailwind CSS)?
    • Why it matters: Familiarity with the main tools is foundational.
    • Example: We're currently on React 18, using Next.js 14 for routing and SSR, and Tailwind CSS for styling.
  2. ✅ How much customization is typically needed for UI components?
    • Why it matters: Helps gauge whether to use off-the-shelf components or build custom ones.
    • Example: We aim to use our internal component library first. If a component isn't available or needs significant visual deviation, we'll build it custom.
  3. ✅ Are we using a state management library?
    • Redux, Zustand, Recoil, Jotai, Context API, just local state?
    • Why it matters: Defines how global or complex application state is managed.
    • Example: For complex global state, we use Zustand. For simpler component-level state, React's useState and useContext are preferred.
  4. ✅ How do we fetch data?
    • React Query, SWR, Axios, native Fetch?
    • Why it matters: Impacts how you handle loading states, caching, and error handling for data requests.
    • Example: We primarily use React-Query for all data fetching, caching, and synchronization with our API.
  5. ✅ Should we use TypeScript?
    • Why it matters: TypeScript adds type safety, which can prevent bugs and improve code maintainability, especially in larger codebases.
    • Example: Yes, all new code and refactors should be written in TypeScript for better type safety and developer experience.
  6. ✅ How much should be tested? ⚠
    • Unit tests, integration tests, end-to-end (E2E) tests? What coverage percentage are we aiming for?
    • Why it matters: Understanding the testing culture and expectations is crucial for delivering robust code.
    • Example: We aim for high unit test coverage (80%+) for critical logic and have integration tests for key user flows. We use Jest and React Testing Library for unit/integration tests, and Cypress for E2E.

Conclusion

This checklist is a living document, and your feedback is always welcome! We're excited to have you on board and look forward to building amazing things together. If you have any questions that aren't covered here, don't hesitate to ask your mentor or any team member.