My Google Journey (8)
Day 8 (6/2)
Activities:
- Received and began work on starter project!
- Played board games with my host and his manager for lunch.
- Submitted my first Pull Request!!
What I Learned Today:
- My work today reaffirmed the notion that it’s always okay to ask for help, and know how long you should wait before asking for it. I was working on creating a test case that ended up exposing a bug with various other tests but I couldn’t figure out how to fix it. I ended up simply asking for help as early as I could and got that problem resolved before the end of the day. The time and frustration saved was well-worth swallowing my pride.
- It’s okay to take a break sometimes. This is one aspect that I love about Google. They consistently provide opportunities for you to pursue other interests, hobbies, activities, etc. while also having a culture where coworkers will not look down on you for doing so. Like today, I just played a couple of games with my host and his manager, and it was a fun way to bond with them. Even if I wasn’t being the most productive possible, it still felt nice to be in a workplace where I could also freely spend time getting to know the people I was sitting next to.
- It’s perfectly alright if you don’t always know what you’re doing either — and make sure to give yourself a break if you’re just getting started. I feel like it’s easy for me to be my own biggest critic, but that’s not always the healthiest thing to do especially when you’re getting started with something new. Just have patience and go easy on yourself at first just so you have time to learn and adjust to what you’re doing. My host was quick to point this out earlier in the day when I felt really stupid for some easy mistakes I was making.
- There are a lot of factors you have to take into consideration to make technology truly accessible to everyone. One of my team members wrote a short summary that I read over that basically described the different factors that can go into making a technology more or less inclusive, and it was really crazy to think how even the smallest things could impact your users. For instance, too much gameification could unconsciously end up turning away female users because video games are societally geared towards males. Another example is how educational resources should be prepared so it can be presented to a classroom whenever possible — since disadvantaged minorities often don’t know or have access to these resources outside of one. Reading this paper was probably one of the most eye-opening moments to me of how much I can truly help or hurt people through the software and design decisions I make.
Reflection:
After reading my co-worker’s article, I began to think hard about how fascinating it is that every design decision can truly make or break a software. This truly reaffirmed to me the importance of diversity in technology; without women, it’d be incredibly easy for men to overlook factors that could implicitly discriminate against women, and without minorities on a dev team, it’s easy to accidently discriminate against other minorities. This is not to say that these demographics purposefully work against those who are unlike them. In fact, the most surprising thing to me was who subtle these factors were. While it makes sense that disadvantaged minorities usually don’t know about all the resources that are available to them, we don’t always stop to think on how we can make our software more accessible. In the end, diversity truly isn’t just a quota that every company needs to fulfill because of mandates, but because for the good of the company and the widespread accessibility of their products, they need diversity — of thought, of race, of sexuality, of gender, and more.