It’s my first hump day at Yext. I have a headache, probably due to two back-to-back nights of less than 6 hours sleep. You would think I would learn.
One of my teammates whom I had yet to meet returned from his July 4th holiday today. He sits right across from me. To talk to him, I have to sit up extra straight and peer over the monitors. I see three potential outcomes here: my back muscles will get stronger which should help to minimize the pain stemming from my osteoarthritis, my posture might improve, or this is going to worsen my back pain. Here’s hoping for options 1 and/or 2!
My day started out with a monthly meeting with the women’s employee resource group. Today’s topic was about overcoming fear. We all had to write down five things that we are most afraid of. I am the least emotional person I know and this was one of the hardest things I have ever had to do. Writing down the five things that scare me the most made me really think about them which was terrifying. We went around the room to share. I was pretty calm until it was my turn. As I was describing the five things that I’m afraid of, my heart started to race and I became flat out uncomfortable. When I got to the last one which was supposed to the be the item that terrifies me the most, I couldn’t say it out loud. I had to describe it in super general terms. I’m not sure anyone could tell, but my insides were shaking. The point of this exercise was for us to mentally prepare for the worst case outcome related to our fear. For the one I couldn’t say out loud, I realized that the worst case outcome is not really very likely. And there are things I could do to ensure that it never happens. Allegedly, by rationalizing myself through the worst case scenario, I should be able to keep myself under control in less upsetting situations involving this topic. I’m not eager to try this strategy out, but I’m excited to know that I have a tool in my pocket should I need it.
Nothing in life is to be feared. It is only to be understood.Marie Curie
As I mentioned yesterday, today was a 90s themed spirit day. Lots of people dressed up (who knew that stores catering to the under 21 set are currently selling 90s fashions?) The TJ Class of 1998 shirt I wore today was a bit hit. I enhanced the shirt by pointing out the names of the 6 members of that class that either started Yext or joined later.
In addition to Yexters dressing up, the office was decorated with all things 90s. We had a trivia contest that ran all day (yes, there was a question about Vanilla Ice) which livened up the office a bit (not that the office needed an excuse to be silly.) At the end of the day, we are wll invited outside to a 90s themed block party. Astro Donuts brought their famous food truck, 90s music was blaring, there was a tie-dye shirt making station, and we could play games. I spent this time trying to get to know more people. The party’s only downside is that they set up the festivities on the shady side of the building to minimize the effects of the sun. Who does that?
I started the series of training code labs I must complete before I get to work on some test projects. These labs are to get me used to how Yext does things from submitting code for review, reviewing code, and publishing code. I learned that I will be using VIM, Sublime Text 3, and IntelliJ as my primary editors. I’ve used all of these before and I’m looking forward to advancing from novice to power user of these tools.
The first lab I tackled tripped me up as there was a step missing. I have no problems asking questions, but I wanted to try and figure this one out for myself because I’m so new. I also don’t like asking questions when I know I’m supposed to know the answer. After almost 2 hours of rereading and repeating my steps, I finally asked. Turns out, there was indeed important information missing. And this wasn’t the kind of information I could have looked up. Ugh. Now I’m mad that I wasted two hours before asking for help. To my teacher friends reading this: how should we best prepare our students to know when to ask questions vs. when to try to work out the solution on their own?
Another big takeaway from today is that not only is there an engineering-wide style guide for code, there is also a style guide for commit messages. If your reviewer notices that your stuff is not formatted exactly according to the specifications, it will be rejected. You can’t say “But it still works” and ignore it. You can’t ask your reviewer to fix it. And you can’t say you are going to fix it and never do. It MUST be right in order for the code to be accepted. Now, I’ve always been a detailed-oriented person who is probably best described as particular. I’ve got to get these messages right because I don’t want my code to be rejected for something that is totally within my control. However, I can see plenty of people (mostly former students) squawking “but it’s close enough!” I want to give a hyge shoutout to Mr. Burt Kauffman, my math teacher from the MEGSSS program in South Florida from 1983-1985 who forced us to prepare and submit our math assignments in a very particular way. I’m not sure I ever understood the reason for his required format, but I appreciated that it was the way it was and the work wouldn’t be accepted until it met the standards. Who knew that he was preparing me for the commit message standards at Yext? Thanks, Mr. Kauffman!
I got the hang of copying and pasting today on my Mac desktop. Finally trained my fingers to find the
hours of sleep = 5.5; steps = 5,900; lines of code written = 0;
Comments