My Software Engineering Principles

I learned these through my career, from a 20 people startup to a big tech company. None of these are original, but these are the ideas I keep coming back to.

On systems

Systems > features

If a feature solves a problem, a system prevents the problem from needing to be solved again. The highest impact individual is not the one shipping the largest number of features, but the one designing systems that make shipping features faster and safer. When designing systems, I prioritize composability, extendability and clear ownership.

Scalability is also about people

A great system where a documentation update flow is an afterthought is a fragile system. No good docs means as more users onboard, they will extend the system in ways that are not supported, and the system becomes unmaintainable. It's important to set guardrails and invest in developer experience early.

On impact

Leverage > activity

The higher the scope, the more important it is to choose wisely what to focus on. Reducing future ambiguity, unblocking teams, increasing project velocity or reliability are high leverage activities that have a compounding effect. Doing a lot of feature work is not necessarily the best use of your time.

Getting signals fast

Before starting any project, it's important to think not only about what metrics we're trying to move, but how fast we can get a signal. It's common to spend too much time gathering data for a running experiment instead of focusing on other work that would move the needle faster.

On building

Ship fast, fail fast

Since the early days of my career, I set a rule for myself: create at least one pull request per day. This forced me to get things done fast and ship incrementally. Later, I set the goal of shipping a feature per week, including A/B experiment, analysis, live stakeholder presentation / critique and actual experiment rollout. I believe the sooner you put something out there, the earlier you get feedback and the faster you can iterate on it. And iteration is the key to building great products.

A great UX is the whole point

Every morning, I check new user feedback on my products. It's easy to forget about UX when you are deep in technical problems, but if users don't like/understand the experience, they won't use it. That's why thinking about performance, accessibility and smooth interactions is decisive when designing and building. When I was working on Pinterest's PinPeek feature, the hard part wasn't the actual algorithm but getting the right UX to be useful while delighting the user without getting in their way.

Developers are also users (of your code)

Establishing a culture of writing clear and predictable code is a behavior that compounds over time. "Clever" code is a tradeoff between fewer lines of code and more time spent trying to debug it for other people (or yourself after 6 months). It's important to think about the UX of your code: naming, organization, tests, etc.

On working with people

Uplevel yourself by upleveling others (to uplevel the organization)

I've taught at the coding bootcamp I attended. I've mentored juniors in my team and engineers in other teams. I've driven a company-wide mentorship program at Pinterest. Teaching others is a way to actually understand what you think you know and realize what you don't know. And there's a compounding effect: great mentor's mentees become great mentors themselves. The goal is to foster an organization culture where learning scales.

An image is worth a thousand words

Visual communication is underrated. It's easier to get stakeholder buy-in of a project by getting a quick AI-generated image of the feature than by explaining it in a block of text. Code review is sped up if authors add a before/after screenshot to the PR. I advise engineers to record manual testing screen recordings and add them to their PRs as a video attachment, it's a great way to communicate intent to reviewers and forces authors to actually test their changes, uncovering issues earlier in the SDLC.

Distill conversations into docs

In an async work environment, a lot of context gets lost in threads and meetings. I always maintain a live document that captures the status of each project. It starts with a one pager capturing problem, reason to address and proposed approach, which is key for easy onboarding. As the project progresses, more tabs are added to this document, such as a technical design document, bug bash, experiment results, decision journal. This is even more important nowadays for easy indexing by language models.

On career stuff

Do what's interesting to you

This seems obvious but it's easy to follow the crowd and forget what you actually want to do. I've built side projects and pursued ideas in my 20% time that ended up being some of my favorite works, and led to interesting outcomes. Like joining another team to help ship something (got me promoted), or picking up iOS when the team needed it, or building internal tools nobody asked for but ended up having great adoption.

Weird backgrounds are underrated

From time to time I meet another fellow engineer with a non-traditional background. These folks are always interesting, it's really hard to switch careers! Myself, before learning to code, I made videos, produced music and worked as an AV technician in live events. I believe this gave me a feel for the user and the product that I wouldn't trade for a CS degree.

Put yourself out there

I build things and write about them. Sharing your work with the world is really an act of vulnerability since folks will judge it (and judge you!), but it's a great way to improve. I keep a blog and timeline of my projects, mostly to remember what I've done and clarify what I've learned. I'm not necessarily proud of every single thing I've done, but I'm proud of the process and the learning I've done.

Get notified of new blog posts?

RSS is the correct choice, btw.