Hidden Privacy / Security Pitfalls

Sometimes good coding practice isn't good enough

Most software engineers think of this as “someone else’s problem” (usually a privacy engineer or security engineer), but realistically, there’s only so much stuff (bad code lol) they can catch. Especially if you work in some of the more sensitive areas, it’s not realistic to have them do code audits for every change. This means that you as the code author (or reviewer) need to at least pick up some basic instincts about things that can pose risks. ...

August 23, 2025

Sync git submodules with GitHub Action

I needed to share some object code across multiple repos (to ensure the consistency of the RESTful API JSON serialization and deserialization). So I created a dedicated repository where all the shared code lives, then imported it across other repos as a submodule. In this case, I used a library I made - wings - but usually you’d probably use something like Thrift or Protocol Buffers. Another common use case would be to have a repository hosting shared cross-platform (iOS + Android) low-level code. ...

August 8, 2025

Firefighting Heroes

Symptoms of an unhealthy reliability system

We love celebrating heroes in general. So when a hero shows up to save the day, it’s only natural that we make sure to recognize their contribution. While it might feel counterintuitive, we should strive to not need heroes entirely instead of hoping that next time when tragedy strikes, a hero will turn up once again. This is not to diminish the value of heroes. They still play a very important role in firefighting and are doing the right thing in an urgent situation. However, in a perfect world, they shouldn’t be necessary at all and we should at least aspire to work towards building a system with that level of reliability. ...

August 1, 2025

Major Incident Runbook

Take a deep breath, you got this!

I wrote a similar version of this internally at Meta a few years ago for my org after finding myself in the middle of a few SEV1s in a row – and being consulted / asked for support in other similar situations. I thought this might be something useful to share (as a public version) as well. This won’t be perfectly fitting for all use cases, but having a runbook works as an anchor in the midst of chaos, helping to get you unstuck from “what’s next?”. Admittedly, this is an incomplete runbook that serves more as a template for your team or company to complete with more specific tooling guides (using which tool to achieve what, etc.). ...

July 25, 2025

Understanding the Value of Dev Tools

Making the business case for building dev tools

I’m largely approaching this from the perspective of building an internal dev tool (since this is mostly where my personal experiences are coming from), especially if you’re someone who wants to build an internal tool but is having trouble framing it in a way where its value can be understood by the decision makers. I’m also excluding situations where you “have to” build certain tools to track certain information in order to comply with a legal requirement, since I don’t think that would be controversial to comply with. I’d imagine the framework for using an external dev tool, while similar, also poses extra complexity on paying vs building. ...

July 18, 2025

Internal Tooling Ideas

When and what to build for internal tools?

For years, I built and maintained the only logged-out accessible dev tool set / platform at Meta. That earned me some reputation (in a certain circle) of being “the idea guy on internal tools”. Whenever I’m asked about how I keep coming up with good ideas for valuable tools to build, my go-to answer has been “I build tools when I get annoyed while doing my job”. I’ll try to expand that into more details below. ...

July 11, 2025

Early takes on vibe-coding

Is it a mid-level engineer yet?

I keep hearing about vibe-coding and I’ve always written the majority of code myself. While at Meta, I got a chance to try out CodeCompose. It worked really well as an autocomplete but when it tried to do anything more than 5 lines at a time, it would - on many occasions - commit bugs that aren’t immediately obvious at first sight. Generally, I’ve caught them by looking at the generated code and wondering “huh this isn’t how I’d do this, why?”. That said, it definitely helped me code and ship faster especially on mundane tasks. Vibe-coding though, seems like taking it to a whole new level (using even less supervision and care on the code being committed). ...

July 3, 2025

Experiment Review Process

Holding the quality bar for user experience

Mature growth teams would organize a centralized experiment review meeting as a way to share learnings to a wider audience, consult for feedback / next step recommendations, while also holding engineers accountable for the changes they are attempting to ship. The review sessions should be open to anyone to sign up (presenting their experiments) or to participate in general. However, key decision makers (like senior growth engineers, product managers, designers, data scientists) should be required to attend so decisions to ship / not ship / iterate will be made with everyone’s concerns addressed. ...

June 27, 2025

Growth Engineer

Taking fine-tuning to the next level

While I’ve shipped a lot of growth wins (literally the first line on my resume), I’m actually very far from a prototypical growth engineer. That said, in this piece, I want to explore a bit more into what it’s like being a growth engineer and what makes you good at being one. Growth engineers are generally 1 -> 100 experts instead of 0 -> 1. They fine-tune every little detail by running a lot of experiments with marginal changes to understand the user problem and drive growth impact (line goes up). ...

June 20, 2025

Product Growth Opportunities

Finding ideas that brings you from 1 -> 100

It’s never easy to come up with new ideas that help with growth, but identifying the problem makes it easier. You’ll notice that for the most part in this piece, I’ll talk about “where” the opportunities are instead of “what” because that’s usually very domain specific and highly depends on the type of problem you ended up needing to solve. This is part of a series (The Opinionated Engineer) where I share my strong opinions on engineering practices. ...

June 13, 2025