4 Lessons From My 4 Years at Instagram & Facebook as a Software Engineer
Context
I joined Facebook as a software engineer (9/6/2016) and today is my four year “Faceversary” (9/6/2020). I want to take the opportunity to reflect and organize my thoughts around some of the most important lessons from the past four years. I still have a lot to learn, but I hope sharing this can still provide value.
To err on the side of clarity, I’m not writing this because I plan on leaving; I’m writing this because introspective reflection through writing is how I best internalize my learnings and growth.
This place is full of the most brilliant people from all backgrounds and I’m constantly in awe of how lucky I am to be in the same room.
I first joined one of the Messenger teams in Menlo Park. After six months, our team disbanded. I transferred to NYC to join the Instagram Search and Explore team as an iOS engineer. I chose NYC because I desired the diversity in industry(not everyone you meet is in tech), having four beautiful seasons, and the energy of a real city life(Commuting from SF to Menlo Park just wasn’t it).
I’ve stayed on Instagram since for 3.5 years and worked on various features across Discovery, Explore, Search, Location Pages, Hashtag Pages, Location/Hashtag/Sticker Stories, Save, Collections, Keyword Search, Integrity and Privacy, and more recently Shopping.
With further ado, here are the 4 top learnings from my 4 years at Facebook & Instagram
Learnings
Kill Your Darlings
I came across this quote originally from Stephen King’s memoirs on writing,
Kill your darlings, kill your darlings, even when it breaks your egocentric little scribbler’s heart, kill your darlings.
which describes the process of detaching emotions from what you’ve written in editing, the art of addition by subtraction.
As a software engineer working in a fast paced environment. The features you build, no matter how long they take, how many people worked on it, or how promising it seemed during planning, there’s always a chance it will get killed before you finish, after you finish but doesn’t ship, or ship and then get unshipped.
The best way to create successful products for your customers is to iterate as fast as possible and learn from testing and data. Thrash is a natural positive byproduct of this approach to product development
Earlier in my career, I took a lot of pride in what I built but hadn’t learn to detach the result from the process. You can do everything right, build the perfect product that you all love with no bugs, then learn that your customers don’t love it as much or it tradeoffs against a different non-negotiable metric based on company priority.
Take pride in HOW you build your product, but detach your emotions and identity FROM the product. Reacting emotionally from the results reflects immaturity and inability to make rational & unbiased decisions. A failed project is only a failure if you didn’t learn from it or gained valuable insights about the product and your users.
Fall in love with the problem, not your solution.
Kill your darlings. Don’t let your ego get in the way of the team/company. Detach the result from the process and detach emotions from learnings.
Occam’s Razor / Do The Simple Thing First
From an engineering perspective, the philosophy of the Occam’s Razor is— “the simplest solution is usually the right one”. This is something I constantly find myself going back to as the most important principle of problem solving.
When there is overwhelming complexity in a proposed architecture or solution, I always like to take a step back, re-evaluate what we’re really trying to solve/build and think if there is a much simpler way to get to the same goal. Sometimes you’ll realize —
- The problem you’re trying to solve isn’t actually the real problem.
- The complex solution is a poor band aid that actually takes more time than fixing the core root cause.
- What you’re trying to build can be much simpler if you narrow the scope of the solution to just the problem.
- The tangled complexity is actually unnecessary dependency that should each be encapsulated and decoupled.
Programming paradigms I subscribe to heavily in my work are Single source of Truth, Immutability, One Direction Data Flow, Single Responsibility Classes and Encapsulation. They all follow the same principle of keeping things simple by reducing variables and dependencies. There’s no perfect architecture but I find that if all layers of my architecture abide by this principle, the system I come up with always turns out more robust, easily understandable and extendable / delete-able. Refactoring is my all time favorite programming book that taught me many of these concepts.
From a product perspective, “Do the simple thing first” has always been the top value I resonated with the most out of Instagram’s core values. I like the simplicity in the Instagram app without bloated features compared to the main Facebook app. I believe is also due to this core identity of the Instagram product philosophy. This takes a very active role of addition by subtraction that I think Instagram does a great job of. By constantly unshipping features that are no longer relevant for the sake of simplicity in user experience and the codebase. Doing the simple also helps you move faster.
“Simplicity is the end result of long, hard work, not the starting point” — Frederick Maitland
The Underrated Importance of Soft Skills
While coding skills is fundamental to becoming a good software engineer. From my observation, the best software engineers are often ones who have the combination of coding and very strong soft skills.
Engineering isn’t just about building things, it’s also figuring out what’s the right thing to build and also convincing others. Specially at Facebook, where engineers are expected to drive and own a big part of the roadmap and direction on projects. You’re not only working with other engineers of different stacks, but also designers, content, product, research, management, people from other teams…etc. Often times, getting alignment on what to build can be more challenging than actually building it. You need soft skills to make sure what you build can actually be shipped.
When it comes to creating ideas and getting buy-in for what to build, what I see the best engineers do is quickly hack a prototype together and get it in people’s hands to try. Pitching an idea is “easier done than said” rather than “easier said than done”. Playing around with something in your hands is at least 10X more enticing than seeing a mock and hearing words. Hackathons are a great place to flex that muscle.
When you want to ship a feature, not only do you need to build it, you also need to convince a room full of stakeholders and team members why your feature should launch with a narrative for the user experience, strong data support and buy-in from leadership.
Soft skills isn’t just about verbal communication either, I believe writing skills is the most underrated skill in life. Being able to concisely and clearly get to the point with writing, and write notes / documentation that answer questions before they are asked. Writing is a key skill specially in a world where communication is shifting more asynchronous than real time.
(Extreme) Ownership
Within our team / org, we have a manifesto called “DRI” — “Directly Responsible Individual”. The idea is to give engineers full end-to-end ownership of a project from planning to launch. The goal is to empower individuals, create accountability and reduce dependencies. We avoid dependencies on managers to tell the team what to do, and increase reliance on the team to self-organize and figure out how to proceed. A successful DRI make managers feel like they’re not really needed after assigning the project ownership.
A manager of mine once introduced me to the book “Extreme Ownership” by Jocko Willink that goes along well with this concept and helped me grow tremendously at work and outside of work.
A key concept is things that happen to you that are not always your fault but are always your full responsibility.
- It’s not my fault that someone wrote a bad commit that introduce a bad bug, but it is my responsibility to think — How can I have architected my components better so this mistake was not even possible to introduce in the first place? What alerts or tests can I add to catch the regression earlier?
- It’s not my fault that this project I own failed due to x, y, z — but it is my responsibility to have tried my best to see it ahead of time to unblock and maybe prevented it.
- It’s not my fault that a teammate was struggling and could not produce at the level expected — rather than blame them about the project’s failure– what could I have done to make a more encouraging environment or to unblock them, etc. The failure is just as much on me as it was on them.
- It’s not my fault that what the team needs the most does not align with what I need the most for my career progression, but it is my responsibility to manage up and communicate explicitly to make sure both my career progression and team needs are taken care of.
- It’s not entirely my fault that my life is the way it is, but it is entirely my responsibility to make it the way I want.
Take extreme ownership over your codebase, your project, your career, your mindfulness, and your relationships will make things easier for you and everyone around you.
Conclusion
There’s no way to cover the amount of things I’ve learned in the past four years with a few bullet points, but I wanted to take my own advice in keeping this writing simple and concise. I still have a lot more learning and growing to do, but I hope these personal lessons can still be helpful!
One learning that stands out to me from my career progression at Facebook is the most rewarding thing is not focusing on what you’ve done but what you’ve empowered others to be able to do, that’s the best way to increase your scope, scale your impact and grow your influence.
At four years of Facebook & Instagram, I learned to do the simple thing first, kill your darlings, value soft skills and take extreme ownership over my work and my life. These lessons not only helped me in my career but also had an enormous impact on my life outside of work.
I’ll end this writing with 1 more thing, my favorite aphorism I learned at Facebook that I think of all the time that empowers my ambitions and adventures in my life the most.
Huge thanks to Mike Chuang, Yvon Huang, Justin Kong, Brian Budd, Stepan Parunashvili, Joe Averbukh, Jesse Hendrickson, Alex Reichert, Giff Huang for reviewing this essay and providing valuable feedback!
