It's amazing to me that I'm still on the same team 4+ years after I joined. As I wrote in my Two Years post, a lot has changed on the team, and I'm doing much different work now that I was back then, but I'm finding it challenging and rewarding. I'm going to reference that post because I remember only snippets of what it was like back then, but I found it facinating going back and reading my thinking back then. Overall I think it holds up, and it's not like I wrote anything controversial or dumb back then, but I would like to expand on those thoughts now that I have double(!) the experience. And yes, we've changed managers multiple times since the last post.
"Software engineering isn't 100% coding. Especially at more senior levels. Deciding what to code is a huge part of the job, code needs to have a why and how agreed on beforehand."
This is totally still true and still underappreciated, but it's facinating that I didn't mention anything about people. I know now that leading other people about what to code is the layer of abstraction higher than deciding what to code yourself. At WhatsApp/Meta this roughly correlates with the promotion levels, IC3s (Junior Software Engineers) are just implementing task-level code, IC4s (Software Engineers) are implemeting project-level code, IC5s (Senior Software Engineers) are implementing project designs, IC6s (Staff Software Engineers) are leading teams / multiple projects, etc up through orgs, company, industry, universe, etc. Just like system design is a completely different skill than programming, leading other engineers is a completely different skill again. Leading other engineers might sound like managing, and as the seniority gets higher there does tend to be more overlap in the responsibilities of engineers and managers, but I think the difference is in the technicality of being an engineer, where you have to program and design, and lead others, whereas a manager deals with the day-to-day manager stuff of making sure people are happy and productive.
The other big thing that stuck out to me from my post two years ago was about prioritization. Prioritizing what work to do took a lot of my mental energy back then, but that's changed. Don't worry, there's still way too much work to do, so I still do plenty of prioritization, maybe even more now, but I've gotten so used to it and maybe better at it, so that it's not such a mental an emotional toil.
An idea that I didn't write about back then is the concept of depth and breadth of experience in a codebase. Depth is literally end-to-end depth within a callstack, like that you could debug a feature from client to database (can you tell that I work on web stacks?). Breadth would be understanding multiple features, and having the ability to reason about their similarities and differences and build abstractions and libraries or make improvements that cover across feature stacks. I find expanding my skills and experience in both of these directions interesting and rewarding. It's fun to be able to fix a subtle bug or implement a complex requirement change in a feature I work on, and it's also fun to build out new features or take on projects to improve existing features I haven't worked on before. I've noticed that some high level engineers focus more on one or the other of these, and I think I tend to lean toward the depth side, which is backed up by the fact that I haven't changed teams in 4+ years. But we have gained ownership of lots of new features!
Another thing that's changed since my last post is my work/life balance, or more specifically my work/life separation. Being a "good" professional software engineer was and is a huge part of my identity. I find fufilment in my family, friends, and hobbies too of course, but as I gain more experience my confidence and identity as a Software Engineer has become even more important to me. When I first joined a FAANG Silicon Valley tech company, I felt excitement, impostor syndrome, and energy to learn and make a good impression. Now I know that I can fit in at what I thought would be an impossible job to get when I was a teenager tinkering with a Raspberry Pi on the floor, I feel less stressed about learning enough to prove myself, but a responsibility to hold together the team and WhatsApp's quality. Now it feels like with enough time and alignment I can be a part of solving any problem we have, and the opportunities to "make impact" - as they say in Silicon Valley - are sitting right in front of me.