For its first CTV campaign, Jennifer Aniston’s DTC haircare brand LolaVie had a few non-negotiables. The campaign had to be simple. It had to demonstrate measurable impact. And it had to be full-funnel.

LolaVie used Roku Ads Manager to test and optimize creatives — reaching millions of potential customers at all stages of their purchase journeys. Roku Ads Manager helped the brand convey LolaVie’s playful voice while helping drive omnichannel sales across both ecommerce and retail touchpoints.

The campaign included an Action Ad overlay that let viewers shop directly from their TVs by clicking OK on their Roku remote. This guided them to the website to buy LolaVie products.

Discover how Roku Ads Manager helped LolaVie drive big sales and customer growth with self-serve TV ads.

The DTC beauty category is crowded. To break through, Jennifer Anniston’s brand LolaVie, worked with Roku Ads Manager to easily set up, test, and optimize CTV ad creatives. The campaign helped drive a big lift in sales and customer growth, helping LolaVie break through in the crowded beauty category.

Learn more.

Hey Junior Engineers!

Code review feedback can feel random — sometimes your PR gets merged in five minutes, other times it comes back with twenty comments. The difference usually isn't your code quality. It's that seniors are evaluating things juniors aren't taught to think about yet.

When a senior engineer opens your pull request, they're running through a mental model that goes well beyond "does this code work?"

Here's what they're actually evaluating — and what most juniors don't realize is being judged:

The most common feedback juniors receive is some version of: "I had to read this three times to understand what it does." Seniors have been burned by clever code they couldn't debug at 11pm during an outage. They default to preferring obvious code over compact code.

What juniors often do: Write the most concise version of a solution — a one-liner where a five-liner would communicate intent clearly.

What seniors want: Variable names that read like sentences. Functions that do one thing. Code that a new hire could follow without needing context.

Juniors tend to write for the happy path — the case where everything works. Seniors open your PR and immediately ask: what happens when this API returns null? What if this list is empty? What if the user passes an unexpected type?

Missing error handling is one of the most consistent gaps in junior PRs. It signals that the author tested "does it work?" but not "what happens when it breaks?"

What to do: Before submitting a PR, ask yourself: what are the three most likely ways this could fail in production? Then handle them — or at least acknowledge them in a comment.

Senior engineers get nervous when a PR that should change ten lines changes two hundred. Large diffs are harder to review, harder to roll back, and harder to understand. They often signal that a junior touched things they weren't sure about or refactored opportunistically without a clear plan.

What seniors want: Small, focused PRs. One concern per change. If you found a bug while working on a feature — open a separate PR for the bug.

You don't need to micro-optimize every loop. But seniors notice when a junior adds an N+1 query to a database call, runs an expensive operation inside a loop that runs thousands of times, or fetches more data than the feature actually needs.

This isn't a deep performance engineering skill — it's pattern recognition. The way to develop it: when you write code that touches a database or loops over a collection, ask yourself "at what scale does this become a problem?" You don't need to solve it immediately. You need to notice it.

A PR without tests makes seniors ask: how do you know this works? How will we know if it breaks in six months?

But more importantly, code that's difficult to test is often code with hidden design problems. Untestable code tends to be tightly coupled, does too many things at once, or relies on global state. When a senior says "this should be easier to test," they're often diagnosing a structural problem — not just asking for more coverage.

Many juniors treat the PR description as optional. Seniors treat it as a first impression.

A good PR description answers: what does this change do, why was it made, and how did you test it? A PR with no description (or just "fixes stuff") forces the reviewer to reverse-engineer your intent from the code — which slows them down and signals a lack of care.

The practical checklist before you submit any PR:

Most juniors dread getting comments on their PR. Flip that mindset.

Every comment a senior leaves is free mentorship. They're showing you exactly how they think about code — which is what you're trying to learn. When you get feedback, don't just fix it and move on. Ask yourself: why did they suggest this? What pattern are they applying? Can I apply that same pattern next time before they have to tell me?

Juniors who improve fastest are the ones who treat code review comments as a curriculum, not a report card.

One concrete habit: after a PR is merged, re-read the review comments once. Write down any patterns you want to remember. Over time, you'll internalize the checklist and start catching things before they're flagged.

Understanding Code Review Best Practices — Google's Engineering Practices Guide
Google's internal engineering documentation, made public, covers how reviewers and authors should approach code review. Unusually practical and specific — the section on what to look for in a CL (change list) is directly applicable to any PR workflow.
https://google.github.io/eng-practices/review/?utm_source=jr.engineer&utm_medium=referral&utm_campaign=code-review-skills-what-seniors-look-for

"The Code Review Pyramid" — Gunnar Morling
A short, well-structured article that gives code review concerns a clear hierarchy: from code style at the base to API design and functionality at the top. Useful visual model for understanding what matters most.
https://www.morling.dev/blog/the-code-review-pyramid/?utm_source=jr.engineer&utm_medium=referral&utm_campaign=code-review-skills-what-seniors-look-for

"How to Make Your Code Reviewer Fall in Love with You" — mtlynch.io
A frank, experience-based guide from a senior engineer on what makes PRs a pleasure vs. a chore to review. Covers PR size, description quality, and how to respond to feedback. One of the most practical pieces on this topic.
https://mtlynch.io/code-review-love/?utm_source=jr.engineer&utm_medium=referral&utm_campaign=code-review-skills-what-seniors-look-for

Q: I keep getting lots of comments on my PRs and it feels personal. Is it?

Almost never. Senior engineers who leave a lot of comments on junior PRs are usually the ones who are most invested in helping you grow. The reviews that should concern you are the ones where a PR gets rubber-stamped with no feedback — that often means no one is looking closely enough to help you improve.

That said, feedback delivery varies. Some seniors are blunt to the point of feeling harsh. If a comment stings, try reading it as technical feedback about the code, not a judgment about you as a developer. The code isn't you.

If you genuinely can't tell whether a comment is about the code or about you, it's fine to ask for clarification: "I want to make sure I understand the concern — is this about X, or is there a broader pattern I should think about?" That kind of question usually gets a useful answer and shows maturity.

The juniors who grow fastest are almost always the ones who can detach their ego from their code early. It's a skill. It takes practice.

What's the worst code review comment you've ever received — or the one that actually changed how you write code? Hit reply and tell me. I read every one.