As a software engineer, I used to think that I wasn’t interested in working on infrastructure or platform work. I felt like it was something I should do more of, to build technical breadth and fill in gaps, but not something I truly wanted to do. I thought of myself as a practical product-minded engineer who was good with people, could ship features, and get things done.
People who were infrastructure “experts” seemed to enjoy long heated arguments about why their way was the best. Or they liked to spend a lot of time spouting complaints about one technology and how another one was far superior. Or they didn’t care that much about the product, and worked on things that never got recognition or had immediate product impact.
I wasn’t like them. I like to see the immediate impact of what I’ve done. And I am not dogmatic about design approaches as long as it seems simple and clean. And I don’t like to listen to or participate in long heated arguments. So maybe that whole infrastructure thing wasn’t for me.
Last year, my colleague Suguna pulled me aside and said, “Hey, what do you think about working in a small team for a few weeks to upgrade the notification system?” I have to admit, this sounded super boring to me. First of all, I wanted to work on more feature work, things I could point to and say, I shipped that. Emails were notoriously awful to work with, and I had stayed away from them because of that. But Suguna tried to convince me that that sort of frustration is exactly why platform work is challenging and exciting, and is what makes the end result of an easy-to-work-with system so incredibly rewarding. I gave her a skeptical look but reluctantly agreed to join her.
The next few weeks completely changed my mind about platform work. We were on a tight timeline to ship new features, and we needed the platform changes to do so reasonably (or really, at all). We worked on platform and features in parallel, figuring out exactly what needed to be completed for the platform to hit our next product deliverable. It sounds obvious to me now, but here I saw firsthand how we should be working on platform—not in isolation, but as a a high-impact tool and investment that would make shipping faster and more efficient.
In my mind, platform work went from dull and uninspiring to a wonderful world of optimizing under constraints, where you spend the time discussing and understanding an optimal solution, but coordinate your limited engineering resources to figure out how to work toward that ideal world while enabling product priorities to ship quickly. And in my mind, I went from someone who wasn’t interested or quite cut out to be a platform engineer to someone who is interested in and actually pretty good at infrastructure work.
This experience reinforced for me how strongly social expectations or labels can affect someone and how they think about their abilities. I had this preconceived notion that platform work was for people who were more “hardcore” than myself, who lived and breathed to code 24/7. No one even ever said that to me explicitly, but I had that notion.
A message like “it’s ok, you’re just not a math person, it’s not for everyone,” can quickly become part of someone’s self-image. An innocuous-sounding comment like “She loves art and writing, and her brother loves computers” can easily affect people’s perceptions of what they’re good at and should stick with and things that are “not for them.”
Now that I’ve discovered this one fallacy about myself that has been refuted, I wonder how many more there are that are holding me back from things I could love.
