I used to get feedback that I’m “distracted” because of the strange way I solve problems. No one thinks like me, understands me, or can guide me through my own brain. That’s on me. But others can provide me tools and information along the way. At my job, managers often tell me “You are doing too many things” when I come into a 1-on-1 feeling defeated.
It seems subtle, but there was a significant difference for me between “distracted” and “doing too many things”. The first was a cryptic judgement that I should actually be doing something else, and the latter was a precise description of what I experienced in my brain. Feedback like this has helped me delegate tasks back into my team when I’ve taken on too much, so I can get back to my most productive flow.
This way, I line up a single success within a series of small achievements in order to boost my confidence… because another feedback I received here is to work on my confidence. Most of us benefit from someone helping us prune bad branches or discover new paths. Good things take a lot of patience and love… from ourselves and from the community. 🚀 I talk about confidence and mentorship more in this interview.
One thing that has always unsettled me about being a technologist is the sensation that I’m taking jobs away from others. It began during my first internship in 2013 at Amazon headquarters. I noticed that homelessness is a major problem in Seattle, and the general consensus amongst the locals was that the tech companies were gentrifying the city. I had never been to Seattle before that summer, so I had no way to verify this, but the idea that me, a 20 year old computer science student, could be taking away someone’s home was disturbing to me.
The following summer, I was on a flight to SFO to begin another internship. I started chatting with a gentleman sitting next to me who seemed quite excited for me and my summer. At the end of the flight, he asked me what company I will be working at, and I told him I will be an intern at Google in Mountain View. “Ah,” he said, “You are the reason my rent is so high.” The rest of the summer went sort of like that. During many Google-hosted tech events, a protestor would interrupt a product reveal or key note speech shouting things like “Google took my home, my family away. Give them back!” Google has double decker buses that run from the Mountain View office to various parts of the Bay Area including San Francisco where I was staying, but they were unmarked. I am not an operations professional at Google, but I presumed the idea was to avoid unwanted attention on Googlers at the bus stops.
While self-driving cars cruised around Googleplex, I would go home to that same, somber scene in San Francisco’s streets of homelessness. I tried going to a few meetups to meet locals who are not technologists, and quickly realized that was a tall order. It felt like I was living in a dystopia where technologists were first class citizens and everyone else was just barely making ends meet from our patronage. I wondered what makes technologists so special.
ToyNet is my best attempt at making things better in this space. It’s a learning platform with a visual network emulator that allows you to drag and drop devices into a network, connect them, and configure them to be able to send system administration commands to each other. I saw that many nonprofits teaching students to code in prisons existed, but there was none I saw teaching computer networking in prisons. Given many incarcerated individuals spend a long period of time away from computers, I felt that fundamental understanding of networking may be easier to pick up than software engineering where the individuals would need to compete with undergraduates like myself who have access to Googleplex for jobs.
My co-founder Kunal Jha and I recruited technologists and creatives to help launch this project and market it, and we got remarkably far. We managed to build a proof of concept of not just the interactive network emulator but also a course modules workflow that includes lectures, embedded videos, animations, and skills assessments to reenforce the material for different learners. It is currently deployed on ECS containers in AWS and built in React and Flask (not Django which was the original backend).
One of the most heart warming aspects of working on this project is meeting so many other service-minded technologists. Many of us were seeking new career paths when the pandemic hit, and saw this project both as a way to develop our skills and give back to future aspiring technologists. In the process we all felt how tough it is to break into a new field and leaned on each other to be pillars in getting through the interview process. I realized that technologists need to learn a lot to make the money they make (tens of thousands of hours are needed to go from 0 to programmer), but also that anyone can make the transition if they have the financial security to fully dedicate at least one year to preparing projects, resumes, and interviews points.
Ironically, the fact that eight of our volunteer technologists now have full-time jobs means that progress on bringing ToyNet to prisons has slowed down. The backbone of ToyNet is there, so I plan to start porting more of the networking curriculum we already have in slideshow format into the curriculum format.
In this talk, my team lead Joris Bonnefoy and I share how network disruptions and CPU disruptions work underneath the hood all the way down to the networking interfaces of the Kubernnetes nodes and pods.
One of the most challenging aspects of onboarding to this codebase is understanding how the chaos controller manipulates network prio queues in order to create traffic bands that can be isolated from the rest of the network traffic and then disrupted using netem rules. My document (featured left) covers how it works.
After learning how to operate and modify chaos controller, I decided to try to create a disruption of my own. At Datadog, there had been a high volume of requests for an application-level disruption as our existing offerings focused on external factors to the application itself (such as noisy neighbors, network degradation, DNS degradation, and node failures).
Since most Datadog microservices rely on gRPC to communicate, we designed a disruption that triggers when an interceptor on the service listens to chaos requests from the application and depending on the configuration returns some percentage of application errors.
For five long years from 2015 to 2020, I woke up every morning wondering if I could ever proudly identify as a software engineer. Coding was difficult for me, and despite selfless mentor after mentor investing time into me, I would look at successful women on stage at events and think, “That is not me; I just need to get good enough to keep my job.” It’s hard to describe how baffled I still am every day that I think I’m one of those women now.
In 2020, Datadog hired me after seeing my personal project which blossomed into Project Reclass. They provided me headspace to fully be myself and encouraged me to express systems the way they exist in my mind: a rigorous spatial expanse where shapes and colors have meaning and words are an afterthought. I finally fell in love with my career.
It’s not easy to publicly discuss imposter syndrome precisely because after all these years, there is still a voice in my head asking if I’m a “stereotypical diversity hire”. Would people think I have nothing technical to share that I spend a whole spotlight talking about not fitting in? But this story would have helped me back then – the tears, the vulnerable and uncomfortable conversations that paid off, the number of teams I went through to find my niche, and the people who kept me going. Which leads me to my final statement:
Mentorship matters. Mentorship works. Tech is a tough field to break into, and each of us can help.
Tay Nishimura 