That is the beginning of knowledge - the discovery of something we do not understand.
-Leto Atreides II, God-Emperor of Dune
1. The IRL Mentor
Asynchronous communication is the future; it simultaneously puts everyone on the same page and, in order to work well, requires everybody to be on the same page. This takes some time to get the hang of, since our present-day lives are, for the most part, synchronous. I live in the same city as my Internship Manager, Emilie, and I believe that was crucial to my success as an intern. Having Emilie as part of both my synchronous and asynchronous life helped me merge the two together in a way that allowed me to learn and do a lot during my short time at GitLab.
Basically, if we understand that Tech has its own language, having Emilie to mentor me in person was like spending time with a native-speaker. I was able to see how her tech skills are an integral part of the way she thinks, and she doesn’t waste time second-guessing herself. She also taught me that that is a learned skill--so often we assume folks are born-with-it, but Emilie took the time to illustrate how discipline is the foundation of confidence. Confidence takes time to cultivate asynchronistically, especially if you’re at all prone to Imposter Syndrome, so an IRL mentor like her served as a great example for me.
2. Schedule, Schedule, Schedule!
Being a part of a remote workplace means you have to schedule everything--especially social calls! I had some great coffee chats with folks from around the world, and it really helped me understand how GitLab works on a macro level. People > product, and productive people run on schedules. This isn’t something I was completely unaware of, but I knew it as well as I know I how to eat a balanced diet with plenty of fresh fruits and veggies (I don’t). It’s not a pattern I had ingrained in me beforehand, because I’ve either flexible work schedules or little-to-no follow-up on projects, so this was, again, something I had to learn.
3. Mistake-Making
As an intern, any mistake I was capable of making didn’t have any negative ripple effects to any part of the Data Team, so I took that opportunity and ran with it. Throughout my mistake-making, it was reiterated that this was the foundation of learning, an essential part of being human and working with data, and that it didn’t reflect my actual skills or ability. The GitLab Data Team was such a solid team to learn with because they all understood the initial rush of adrenaline and shame that goes along with mistake-making, and they also carried the wisdom of folks who have made mistakes when the stakes were higher--not intern-level, but full-time. Having their support was not only very encouraging, but also helped to develop my mistake-making skills. I’d say I’m about Bard level in my own personal mistake-making RPG.
This is my major mistake-making takeaway: the language of tech is polysemic, and breaking down denotation versus connotation required a lot of me breaking things. I’ve spent a lot of time with semiotics and much less time with SQL queries, but I found a lot of the same rules apply. There’s generally something non-verbal that’s connoted with ideas that are literally denoted--typed, spoken, etc--and that connotation gets lost in the crosshairs of data. Data is deliberate, but language is inherently unstable, so miscommunication happens, and mistakes are a part of learning how to be a better data analyst. I will never get to a point where I won’t make mistakes--I’ll just be making new, different ones, perhaps less regularly, but they will always be a part of my life.
4. Take a Break - The Work isn’t Going Anywhere
The danger of burnout, especially with remote work, is well documented at GitLab. Strong measures are taken to prevent burnout, since you could, in theory, work around the clock if you really wanted to (or felt like it was necessary). I got that in theory, sure, but when I had an ear infection that brought along weird vertigo-like symptoms during the first part of my internship, I felt incredibly guilty for taking days off. I remember shamefully telling Emilie I hadn’t made any progress because I wasn’t feeling well, and that I felt bad, or like I was slacking, or something, and then we had a Luke-Yoda moment I’ll never forget: Please, don’t let that concern you. The work will be here when you’re ready.
Ah! That was such an important lesson that I’m sure I’ll be re-learning in various capacities for the rest of my life, but in that exact moment, it was a slack-jawed realization of the best kind. The work will be here when I’m ready! ‘Pushing through’ illness of any kind isn’t what the work is about, and, really, only makes you prone to fuzzy thinking and more mistakes. Even though time happens simultaneously in an asychronistic workplace doesn’t mean that you have to happen simultaneously. We haven’t reached that dimension yet.
5. Change: The Only Constant
Data is alive. When you’re a data analyst, you need to cultivate an intimate relationship with your data. You have to care for it, tend to it, teach it, help it, develop it, watch it, play with it, get angry with it, love it. It might not always tell you what you want to hear, or do what you want it to do, but it always tells the truth. Just like people, no data set is perfect, and you have to work with it in order to get the information you want, or the task you want it to perform. GitLab is itself an agent of change, a tool for tracking changes and making improvements, pulsing with activity, always updating, alive. GitLab taught me that it’s all a process--beyond the literal beginnings and endings, life is just a series of commits to the Master Branch, so make your README.mds good, push, pull, and prosper.