My Google Journey (9)

Day 9 (6/5)

One of the various nap pods around the MTV campus

Activities:

• Submitted and successfully merged my first Pull Request!
• Read recommended articles about communication
• Watched videos, workshops, and trainings related to the art of communication
• Joined my team for my first Monday Board Game Lunch

What I Learned Today:

• While I’ve previously stressed the importance of knowing when to ask for help, I’ve learned it’s also important to be prepared — even over-prepared — when you decide to do so. Today I struggled a couple of times to try and articulate the struggles I was having with the code I was working with, and this often got in the way of me getting the help I really needed. While I am still relatively new to the codebase, I think it would have served me better to write down and/or prepare my questions and concerns beforehand — even conducting any needed research — before reaching out to my hosts/mentors for help.
• To be accomplish clean code, you have to be detail-oriented. I am the type of person who tends to get tired of things when I’ve worked on them for a long period of time. For example, I cannot cram for writing essays or projects because after many hours of trying to crank it out, I’ll just be too sick of looking at my own work to even be bothered with editing it to perfection. I just end up sending it off without a second look, and this habit of mine often leads me into trouble. This trait of mine especially comes to bite me in the butt when it comes to code reviews because I’ll tend to overlook or forget certain things before sending it off for approval. While it’s not a huge issue in the fast-paced world of software development, this is definitely a lesson that I need to drill into my own head.
• Sometimes, it’s better to be more tentative than overly confident. Throughout all of the videos and articles I read today about communication, one thing that stuck out was one persons’ advice on Powerless Speaking — where you as the speaker are placed at an authoritative disadvantage. The presenter’s example was a time when he had to speak and lead a workshop as a 24-year-old to a group of retired and active duty soldiers who were all 50+-years-old. Obviously, he was at a disadvantage due to his age, but he found that when he admitted and even joked about this vulnerability, his audience became more receptive to what he was saying. In these situations, it was better to admit your weaknesses (but without undermining your credibility) because it makes you more relatable and makes your audience more receptive to what you have to say.

Delicious churros from one of the food trucks

Reflection:

I’ve been finding more and more that knowing when and how to ask for help is more a fine art than anything. It’s very easy to get stuck in your head (and your pride) to the point that you refuse to ask for help — which ends up hurting your productivity. Not asking for help also tends to leave your coworkers in the dark about your own progress — as they’ll simply assume that you’re working along just fine without any problem. On the other hand, it’s also easy to get so caught up in asking questions that you don’t end up giving yourself a chance to try and find an answer — which again hurts you and your opportunity to grow as a problem solver. In previous internships, I think I tended to struggle on the side of the spectrum where I wouldn’t communicate my struggles with my coworkers. I was even told that I could communicate more with my team about these topics. However, now that I have started to make a conscious effort to try and ask for help when needed, I still feel like I’m fighting to get a balance. How does anyone truly know when they should give up and ask for help?

One of the lessons I listed above for today discusses a personality trait of mine that I feel tends to make me a weaker programmer in certain ways. However, I think my drive and my love of logic and problem solving helps me be a better programmer as well. This gets me thinking then about whether all programmers have common traits that make them inclined for this occupation, or does everyone have their own unique strengths and weaknesses even within the same field? I feel like everyone in Computer Science has to love solving puzzles and problems since that’s what they do all day, but perhaps I’m just making that assumption because that’s what made me fall in love with the field. I’d love to see what research has been done — if any — to see how all people in Computer Science may be similar or different from each other.