Working with engineering in the past used to feel so foreign to me. I never truly understood all the complexities of collaborative software development, and in full transparency, I still don’t. However, using GitLab has taught me how to contribute to the success of our product.
We believe everyone can contribute
At GitLab, one of our goals is to ensure that everyone can contribute to GitLab the application and the company. To help share this working knowledge, everyone that works at GitLab must add themselves to the team page. Conquering this development task can be daunting because there are new terms and lots of steps. However, our documentation does a great job of helping reduce the barrier of entry.
Develop shared empathy
I never had access to the codebase in previous product teams because it was far too time-consuming to get a build environment configured on my computer. For GitLab, this is a requirement so that I can review changes before they go to production. During onboarding, I invested a decent amount of time setting up the GitLab Development Kit (gdk) on my computer. It was a challenge, but now I know why getting developers up and running can be incredibly complex. I can even more greatly appreciate the GitPod integration, which does all the heavy lifting of setup for you in minutes.
Source: GitLab Support for Gitpod is Here
Once my setup was ready to go, I was able to jump in. When I started at GitLab there was a quarterly goal to migrate our button components to the new front-end we were using. I migrated several buttons, but the one I am most proud of required me to step into an area of GitLab I was completely unfamiliar with. I had to get a niche button to verify that my changes were correct, which required me to learn how to get Terminal working in the GitLab WebIDE. Then, I reached out to other designers and team members to get my runners to function correctly. This helped me understand more complex areas of GitLab better than just reading the documentation. It is one thing to read about something, and a totally different beast to make something work yourself.
This idea of dogfooding is something we uphold as a sub-value at GitLab. By using GitLab to contribute to GitLab the application and company, we put ourselves in our users’ shoes. If we don’t like something then we are that much more motivated to change it.
Diversify skill sets
As a designer, I want to have a functional understanding of the frontend framework I am designing within. Having the basics down allowed me to communicate expectations, minimize assumptions, and ask insightful questions. Working through the initial learning curve has helped me tremendously in the coming months for scoping designs and working alongside engineering.
Sometimes rather than just sending a mockup to my engineers, I’ll open a Merge Request to propose a change instead. For example, I could have asked them to update the border color of a table, but I discovered removing an extra CSS class would fix the problem; submitting that change was much faster than creating a mockup and chatting about it asynchronously.
It's much easier to get input from engineers if you are talking about something specific in the codebase, instead of something more nebulous like border colors. Engineers will have to dig into the codebase to reference what is there, so help save them a step if you can. Discussing an explicit change is actionable, which is why we say everything starts with a merge request.
"It's much easier to get input from engineers if you are talking about something specific in the codebase."
Doing smaller and simpler changes made me comfortable trying more complex ideas like replacing label colors with common names. Each merge request taught me something new. I learned more about keeping my code formatting clean, writing good commit messages, and how to resolve failing pipelines. All things that contributors to GitLab must learn at some point in time.
As I learn about the different nuances that come with various pages in GitLab, I rely less on asking questions because I can look them up myself. For example, it is not always visually identifiable in the GitLab UI if a page is coded in HAML or Vue. Before I suggest a change or even start designing in some cases, I look for these differences in the codebase. Touching HAML can be more complicated than working with the Vue components documented in Pajamas.
For User Research, I can use these small changes for Short Tests instead of using complex prototypes in Figma. Using research to drive decision-making can help reduce subjective bias for implementing an idea.
Testing a live environment can be useful for validating changes · View Merge Request
Not only can I make more informed design decisions, but I can also contribute ideas that others are excited about. I am actively working on two:
I started working on both ideas while I was between meetings, and I have continued to progress them along ad-hoc. It has been fun to see some of my ideas make it into GitLab, but I also have a nice collection of scrapped ideas.
Conclusion
I have already come a long way from making my first Merge Request at GitLab. I thought I knew the basics of git, but going through this process helped me get my feet wet with more complex development and working in a single repository. I learned about having others review and approve my changes, the magic of seeing checkmarks for all pipelines, and finally, the Merge Request badge turning from Open to Merged.
If you are interested in learning how I create small merge requests, then watch this walkthrough of my process.