I am living proof it’s possible to work at GitLab and not be particularly technical, or even particularly quick about learning technical things. Three months ago I joined the company having never used the tool and with no idea what a merge request or an issue was. I’d never touched Git or pushed a commit, and I certainly had never owned a laptop with Docker on it.
If you’re like me, fear not. Here’s everything you need to know to jump right in.
It’s an issue
Let’s start with the thing that confused me the most in the first weeks – issues. An issue is something you create if you want to start an initiative, or simply keep track of an idea. Derived from the software development space (obviously), it’s like the starting point in any work-related conversation. Have a great idea for a new GitLab feature? Open an issue. Have an idea for a marketing campaign? Start an issue. Anyone can chime in on your issue and it becomes a place to not only have a conversation but also to keep track of the conversation. At GitLab we call all that “chiming in” collaboration. Collaboration is central to the company’s culture and our mission “everyone can contribute.” Issues are sort of the file folders we store all that collaboration in. (And, because you might hear this term and wonder about it, as I did...an “epic” is a collection of related issues, sort of how a filing cabinet holds file folders, to use a very old school analogy.)
Lanes merge ahead
A merge request is a formalized way to request something (usually in the GitLab handbook or blog) be created or changed. Creating a merge request triggers GitLab.com to rebuild the entire website (which is both cool and sort of scary the first few times you do it). When you submit a merge request you’ll get a message that says the pipeline is running, meaning the process of rebuilding the entire website has begun. That’s not a small undertaking, so it can take 15 minutes, or more, for your merge request to go through. If it does go through, you’ll get a message that says “passed with warnings!” Ignore the “warnings” – builds always pass with warnings. These warnings are usually not relevant if you're not contributing code. The key thing is it passed. (Speaking from personal experience, refreshing the page or simply staring at the “pipeline running” message doesn’t actually make it go faster.)
Notice the term is merge request. That means once it’s passed you’ll need to ask someone who has magical merging powers to actually merge it (usually your manager). You do that by assigning the request to them (top right of the MR form) and leaving them a comment asking them to do so.
All aboard
You’ll get a big onboarding issue on day one. Do not panic. Take your time. And realize that some of what you’re doing will only make sense in a month, or even a few months (like all that time I spent downloading Git).
Most of the onboarding tasks are very straightforward and helpful. But ultimately you’ll have to add yourself to the team page, creating your first merge request in the process. Anything involving the team page can be very tricky because it is based on .yml files (cranky, touchy things that are pronounced a little like the vegetable, “yaml”) so do not be afraid to ask for help. The #mr-buddies, #git-help, or #questions channels in Slack can be great resources. You’ll want to remember to use “command F” to search through the hundreds of files on the team page to find your entry.
Don’t worry – no matter how much of a struggle it is to add yourself to the team page, you’re unlikely to actually “break” anything on about.gitlab.com. (I’ll freely admit it took me several days to accomplish this one task… )
Communication
In an all-remote company, communication is vital. But how to communicate at GitLab doesn’t necessarily come naturally to someone like me who came from an email and phone call culture. Our communication methods are spelled out in the handbook, but here’s the quick version: You want to communicate primarily within GitLab. That means within an issue – tag someone with their GitLab “handle” (@vsilverthorne as an example) – in the discussion box. Or the same thing can happen in a merge request. Whoever you tag will get a notification in their To-do list on GitLab, and may also be notified via email. But speaking as someone who’s been pointed in the right direction after using Slack or email instead of GitLab, trust me when I say within GitLab is the first and best way to communicate.
If it’s urgent, Slack can be a good choice. Slack is also a great place to ask questions, chit-chat with colleagues and/or share common interests. GitLab has lots of groups on Slack for everything from crafty people to gardeners. Email is the last choice because much of the company checks it only occasionally.
Meetup IRL or virtually
The video call on Zoom is another key GitLab practice and although I was a little skeptical it could be more effective than a phone call, I’m now a convert. Not only do you get to know people better because you can see them, the ability to screen share is invaluable, particularly when you’re learning something new. I never feel “camera ready” though, so if you feel that way, you’re far from alone. Luckily, there is a function on Zoom called "Touch up my appearance." It's like FaceTune for the workplace instead of Instagram. Just go into Zoom>Preferences>Video and under My Video check "Touch up my appearance." This way your dark circles won't be making an appearance in the latest video on GitLab Unfiltered.
If meetups are possible in real life, I’d suggest those too. At an all-remote company you do have to put time and energy into feeling like you’re part of the team.
Are there other challenges you’ve encountered when you were brand new to GitLab that would have been helped by a clearer or more detailed explanation? Let us know and we’ll update this blog post (and the handbook).
Cover image by Charlotte Karlsen on Unsplash
