Mastering Code Reviews: A Guide to Better PRs and Clean SQL

Learn best practices for data engineering PRs, including naming conventions, dbt documentation, local testing, and etiquette for faster code approvals.

#pull-request#data-engineering#sql-best-practices#dbt#code-review#data-analytics#git-etiquette

Watch
Pitch

How to Make Reviewers Approve Your PR

A Guide to Clean SQL, Happy AEs, and Fewer Headaches By Miriam Revilla Alvarez

Made by

The Game Plan

1. The Reviewer's Perspective (Why we are like this)
2. Follow Best Practices (Naming & Folders)
3. Documentation (No creative writing)
4. Testing & The 'To Test' Section
5. Etiquette 101
6. Kahoot! Deathmatch

Isometric 3D map illustration showing a path from mess to clean data, clean vector art

Made by

The Reviewer's Perspective 🧐

Why are we strict?

We feel responsible for Production. Broken logic = 3AM wake-up calls.

Ambiguous names (e.g., 'id') cause cognitive load and bugs 6 months later.

We want you to succeed, but we need to protect the data reliability.

Made by

Naming Conventions & Folders

The Rules

Model Prefixes (Non-negotiable):
• stg_ : Staging models
• prep_ : Prep models
• event_ : Curated event data

Why?
Instantly tells the user the granularity and type of data.

computer folder structure diagram simple flat design

Example: hub_shifts.sql lives under central_ops_team / staffing / shifts / curated.
Start clean, stay clean.

Made by

Documentation: Not a Creative Writing Class

❌ Bad:
{% docs is_active %}
It is active.
{% enddocs %}

Reviewer Reaction: Thanks, I can read.

✅ Good:
{% docs is_external_last_mile_rider_profile %}
TRUE if external_agency_name is not empty. Used to identify contracted riders.
{% enddocs %}

Reviewer Reaction: 🤩 Clarity!

Meme of someone squinting at a small paper or confusion

Made by

🧪 Testing: The Bare Minimum

1. Run Tests Locally (Always)
.yml tests are your first defense.
unique, not_null, relationships.

2. Why?
If these fail, we waste time iterating on typos. Don't be that person.

Made by

The 'To Test' Section is Mandatory

Passing .yml tests matches syntax.
'To Test' matches REALITY.

Include:
✅ Confirmation .yml tests passed
🧠 Validation queries (Show intent!)
📊 Row count comparisons
⚠️ Explicit callouts for weird data

screenshot of a github PR description with a checklist checked

Made by

Validate Business Logic (Show us the Data!)

Don't just run the code. Prove the result makes sense.
Ex: A process change should reduce tickets. Show the drop!

Chart

Made by

🤩 How to Keep Your Reviewer Happy

bullet_1: Reply to comments
Don't ghost us. Explain your fix or argue your case (politely).

bullet_2: Don't resolve your own threads
That's the reviewer's job. It helps us track what is still pending.

bullet_3: Fix it everywhere
If we comment on line 10, check if line 50 has the same issue.

Happy high five office colleagues illustration flat style

Made by

🎓 Be a Great PR Citizen

1. Post in #data-analytics-community when ready.
2. Fill in 'What's the problem' and 'dbt statements'.
3. No 'Draft' PRs for review (Wait until you are done!).
4. Re-request review ONLY when you are actually done fixing things.

Made by

IT'S KAHOOT TIME! 📱

Q1: Which folder implies ownership?
(A: The closest one to dependencies)

Q2: Who resolves PR comments?
(A: The Reviewer only)

Q3: What prefix is used for curated Event data?
(A: event_)

Q4: Is the 'To Test' section optional?
(A: No, never.)

Q5: Where do you post your PR link?
(A: #data-analytics-community)

Made by

DESIGNER-MADE
PRESENTATION,
GENERATED FROM
YOUR PROMPT

Create your own professional slide deck with real images, data charts, and unique design in under a minute.

Generate For Free

Mastering Code Reviews: A Guide to Better PRs and Clean SQL

Learn best practices for data engineering PRs, including naming conventions, dbt documentation, local testing, and etiquette for faster code approvals.

How to Make Reviewers Approve Your PR

A Guide to Clean SQL, Happy AEs, and Fewer Headaches By Miriam Revilla Alvarez

The Game Plan

1. The Reviewer's Perspective (Why we are like this) 2. Follow Best Practices (Naming & Folders) 3. Documentation (No creative writing) 4. Testing & The 'To Test' Section 5. Etiquette 101 6. Kahoot! Deathmatch

The Reviewer's Perspective 🧐

Why are we strict?

We feel responsible for Production. Broken logic = 3AM wake-up calls. Ambiguous names (e.g., 'id') cause cognitive load and bugs 6 months later. We want you to succeed, but we need to protect the data reliability.

Naming Conventions & Folders

Model Prefixes (Non-negotiable): • <code>stg_</code> : Staging models • <code>prep_</code> : Prep models • <code>event_</code> : Curated event data Why? Instantly tells the user the granularity and type of data.

Example: hub_shifts.sql lives under central_ops_team / staffing / shifts / curated. Start clean, stay clean.

Documentation: Not a Creative Writing Class

❌ Bad: {% docs is_active %} It is active. {% enddocs %} Reviewer Reaction: Thanks, I can read.

✅ Good: {% docs is_external_last_mile_rider_profile %} TRUE if external_agency_name is not empty. Used to identify contracted riders. {% enddocs %} Reviewer Reaction: 🤩 Clarity!

🧪 Testing: The Bare Minimum

1. Run Tests Locally (Always) .yml tests are your first defense. unique, not_null, relationships. 2. Why? If these fail, we waste time iterating on typos. Don't be that person.

The 'To Test' Section is Mandatory

Passing .yml tests matches syntax. 'To Test' matches REALITY. Include: ✅ Confirmation .yml tests passed 🧠 Validation queries (Show intent!) 📊 Row count comparisons ⚠️ Explicit callouts for weird data

Validate Business Logic (Show us the Data!)

Don't just run the code. Prove the result makes sense. Ex: A process change should reduce tickets. Show the drop!

🤩 How to Keep Your Reviewer Happy

bullet_1: Reply to comments Don't ghost us. Explain your fix or argue your case (politely). bullet_2: Don't resolve your own threads That's the reviewer's job. It helps us track what is still pending. bullet_3: Fix it everywhere If we comment on line 10, check if line 50 has the same issue.

🎓 Be a Great PR Citizen

1. Post in #data-analytics-community when ready. 2. Fill in 'What's the problem' and 'dbt statements'. 3. No 'Draft' PRs for review (Wait until you are done!). 4. Re-request review ONLY when you are actually done fixing things.

IT'S KAHOOT TIME! 📱

Q1: Which folder implies ownership? (A: The closest one to dependencies) Q2: Who resolves PR comments? (A: The Reviewer only) Q3: What prefix is used for curated Event data? (A: event_) Q4: Is the 'To Test' section optional? (A: No, never.) Q5: Where do you post your PR link? (A: #data-analytics-community)

pull-request
data-engineering
sql-best-practices
dbt
code-review
data-analytics
git-etiquette

How to Make Reviewers Approve Your PR

A Guide to Clean SQL, Happy AEs, and Fewer Headaches By Miriam Revilla Alvarez

The Reviewer's Perspective 🧐

Naming Conventions & Folders

Documentation: Not a Creative Writing Class

🧪 Testing: The Bare Minimum

The 'To Test' Section is Mandatory

Validate Business Logic (Show us the Data!)

🤩 How to Keep Your Reviewer Happy

🎓 Be a Great PR Citizen

IT'S KAHOOT TIME! 📱

DESIGNER-MADE PRESENTATION, GENERATED FROM YOUR PROMPT

Mastering Code Reviews: A Guide to Better PRs and Clean SQL

DESIGNER-MADE
PRESENTATION,
GENERATED FROM
YOUR PROMPT