Blog
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
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
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
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
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
Basic guide to running a good A/B test
This is a basic introduction on how to run a good A/B test. A/B testing is a method where your user pool is segmented into multiple groups, allowing you to test different product interactions and understand how these changes affect user behavior. For any metric / data driven team, A/B testing serves as a critical tool in measuring success. This is part of a series (The Opinionated Engineer) where I share my strong opinions on engineering practices. ...
June 6, 2025
Less finger-pointing, more preventions
Every time there’s a major outage at Meta, the first question I get from friends and family is usually “did they fire the person who caused it?” which is where I have to explain this concept of No Blame SEV Culture. Especially for an outage so big that a significant number of users are affected, the individual causing it likely does not have ill intent and there are likely multiple different processes and systems that failed along the way to get us here in the first place. ...
May 30, 2025
Review today or debug tomorrow
Ask a programmer to review 10 lines of code, he’ll find 10 issues. Ask him to do 500 lines and he’ll say it looks good. - @girayozil Code review is a really subjective thing where each team or even individual runs things very differently. However, a bad code review process can lead to bad code smells and unnecessary tech debt (just ask all the vibe coders out there 🫣). I will try my best to share my rather opinionated takes while explaining the reasoning behind each of them. ...
May 23, 2025
Just a DB with some HTMLs
When I had the idea on the series about The Opinionated Engineer, I figured maybe that’s something worth setting up a newsletter service over. That said, after some consideration, I just thought that I didn’t need anything too complex and decided to roll my own because “how hard could it be?”. As far as I can tell, I think it’s working fine so far(?) and took me around one whole day to put the whole thing together from my couch. You can find all of it’s source code here on GitHub. ...
May 21, 2025
It's both self-promotion and communication
This piece is specifically more about Meta’s unique culture of “posting” about things but I imagine it can be a useful reference on communication in general. Many people loathe this process and complain about how it’s just a lot of “self-promotion” and while there’s definitely some truth to it, it’s also a valuable communication avenue that you can leverage to your advantage. As we will explore further below, posting by itself is more of a bonus as the post will still require actual substance (which is your work lol). ...
May 16, 2025