• Product
  • Pricing
  • Docs
  • Using PostHog
  • Community
  • Company
  • Login
  • Table of contents

  • Handbook
  • Getting started

    • Start here
    • Meetings
    • Story
    • Team
    • Investors
    • Strategy overview
    • Business model
    • Objectives
    • Roadmap
    • Brand
    • Culture
    • Values
    • Goal setting
    • Diversity and inclusion
    • Communication
    • Management
    • Offsites
    • Security
    • Brand assets
      • Team structure
      • Why Small Teams
      • Team App East
      • Team App West
      • Team Platform
      • Team Ingestion
      • Team Infrastructure
      • Team Marketing
      • Team Website and Docs
      • Team People and Ops
      • Team Customer Success
    • Compensation
    • Share options
    • Benefits
    • Time off
    • Spending money
    • Progression
    • Training
    • Feedback
    • Onboarding
    • Offboarding
      • Product Manager ramp up
    • Merch store
      • Overview
      • Engineering hiring
      • Marketing hiring
      • Operations hiring
      • Design hiring
      • Exec hiring
      • Developing locally
      • Tech stack
      • Project structure
      • How we review PRs
      • Frontend coding
      • Backend coding
      • Support hero
      • Feature ownership
      • Releasing a new version
      • Bug prioritization
      • Event ingestion explained
      • Making schema changes safely
      • How to optimize queries
      • How to write an async migration
      • How to run migrations on PostHog Cloud
      • Working with ClickHouse materialized columns
      • Deployments support
      • Working with cloud providers
      • Breaking glass to debug PostHog Cloud
      • Developing the website
      • MDX setup
    • Shipping things, step by step
    • Feature flags specification
    • Setting up SSL locally
    • Tech talks
  • Product

    • Overview
    • Product metrics
    • User feedback
    • Scale features prioritization
    • Paid features
    • Releasing as beta
  • Design

    • Overview
    • Overview
    • Personas
    • Testimonials
    • Value propositions
      • Content & SEO
      • Sponsorship
      • Paid ads
      • Email
      • Press
    • Growth strategy
    • Customer support
    • Inbound sales model
    • Sales operations
      • Managing our CRM
      • YC onboarding
      • Demos
      • Billing
      • Who we do business with
  • Table of contents

  • Handbook
  • Getting started

    • Start here
    • Meetings
    • Story
    • Team
    • Investors
    • Strategy overview
    • Business model
    • Objectives
    • Roadmap
    • Brand
    • Culture
    • Values
    • Goal setting
    • Diversity and inclusion
    • Communication
    • Management
    • Offsites
    • Security
    • Brand assets
      • Team structure
      • Why Small Teams
      • Team App East
      • Team App West
      • Team Platform
      • Team Ingestion
      • Team Infrastructure
      • Team Marketing
      • Team Website and Docs
      • Team People and Ops
      • Team Customer Success
    • Compensation
    • Share options
    • Benefits
    • Time off
    • Spending money
    • Progression
    • Training
    • Feedback
    • Onboarding
    • Offboarding
      • Product Manager ramp up
    • Merch store
      • Overview
      • Engineering hiring
      • Marketing hiring
      • Operations hiring
      • Design hiring
      • Exec hiring
      • Developing locally
      • Tech stack
      • Project structure
      • How we review PRs
      • Frontend coding
      • Backend coding
      • Support hero
      • Feature ownership
      • Releasing a new version
      • Bug prioritization
      • Event ingestion explained
      • Making schema changes safely
      • How to optimize queries
      • How to write an async migration
      • How to run migrations on PostHog Cloud
      • Working with ClickHouse materialized columns
      • Deployments support
      • Working with cloud providers
      • Breaking glass to debug PostHog Cloud
      • Developing the website
      • MDX setup
    • Shipping things, step by step
    • Feature flags specification
    • Setting up SSL locally
    • Tech talks
  • Product

    • Overview
    • Product metrics
    • User feedback
    • Scale features prioritization
    • Paid features
    • Releasing as beta
  • Design

    • Overview
    • Overview
    • Personas
    • Testimonials
    • Value propositions
      • Content & SEO
      • Sponsorship
      • Paid ads
      • Email
      • Press
    • Growth strategy
    • Customer support
    • Inbound sales model
    • Sales operations
      • Managing our CRM
      • YC onboarding
      • Demos
      • Billing
      • Who we do business with
  • Handbook
  • Engineering
  • Getting started
  • How we review PRs

How we review PRs

Last updated: Mar 15, 2022

On this page

  • Have a flick through the code changes
  • What to look for:
  • What not to look for:
  • Run the code yourself
  • What to look for:
  • What not to look for:

Almost all PRs made to PostHog repositories will need a review from another engineer. We do this because, almost every time we review a PR, we find a bug, a performance issue, unnecessary code or UX that could have been confusing. Here's how we do it:

Have a flick through the code changes

What to look for:

  • Does the code fit into our coding conventions?
  • Is the code free of bugs?
  • How will the solution perform with at huge scale?
    • Are the database queries scalable (do they use the right indexes)?
    • Are the migrations safe?
  • Are there tests and do they test the right things?
  • Is the solution secure?
    • Is there no leakage of data between projects/organizations?
  • Is the code properly instrumented for product analytics?
  • Is there logging for changes changes potentially affecting infrastructure?

What not to look for:

  • Syntax formatting. If we're arguing about syntax, that means we should be using a formatter or linter rule.

Run the code yourself

What to look for:

  • Does the PR actually solve an issue?
    • Are we building the right thing? (We should be willing to throw away PRs or start over)
  • Does the change offer a good user experience?
  • Does the UI of the change fit into our design system?
  • Should the code be behind a feature flag?
    • If the code is behind a feature flag, do all cases work properly? (in particular, make sure the old functionality does not break)
  • Are all possible paths and inputs covered? (Try to break things!)

What not to look for:

  • Issues unrelated to this PR. Create new, separate issues for those.

The emphasis should be on getting something out quickly. Endless review cycles sap energy and enthusiasm.

Questions?

Was this page useful?

Next article

Frontend coding conventions

In this page you can find a collection of guidelines, style suggestions, and tips for making contributions to the codebase. Two layers: Kea -> React Our frontend webapp is written with Kea and React as two separate layers. Kea is used to organise the app's data for rendering (we call this the data or state layer), and React is used to render the computed state (this is the view or template layer). We try to be very explicit about this separation, and avoid local React state wherever…

Read next article

Authors

  • Michael Matloka
    Michael Matloka
  • Charles Cook
    Charles Cook
  • adrienbrault
    adrienbrault

Share

Jump to:

  • Have a flick through the code changes
  • Run the code yourself
  • Questions?
  • Edit this page
  • Raise an issue
  • Toggle content width
  • Toggle dark mode
  • About
  • Blog
  • Newsletter
  • Careers
  • Support
  • Contact sales

Product OS suite

Product overview

Analytics
  • Funnels
  • Trends
  • Paths

Pricing

Features
  • Session recording
  • Feature flags
  • Experimentation
  • Heatmaps

Customers

Platform
  • Correlation analysis
  • Collaboration
  • Apps

Community

Discussion
  • Questions?
  • Slack
  • Issues
  • Contact sales
Get involved
  • Roadmap
  • Contributors
  • Merch
  • PostHog FM
  • Marketplace

Docs

Getting started
  • PostHog Cloud
  • Self-hosted
  • Compare options
  • Tutorials
  • PostHog on GitHub
Install & integrate
  • Installation
  • Docs
  • API
  • Apps
User guides
  • Cohorts
  • Funnels
  • Sessions
  • Data
  • Events

Company

About
  • Our story
  • Team
  • Handbook
  • Investors
  • Careers
Resources
  • FAQ
  • Ask a question
  • Blog
  • Press
  • Merch
  • YouTube
© 2022 PostHog, Inc.
  • Code of conduct
  • Privacy
  • Terms