For two months earlier this year, I had the privilege of working with a team of three other developers and three mentors during the spring 2021 cohort of Collab Lab. If you’re not familiar with the Collab Lab, according to their website they provide participants with an opportunity to “gain practical experience by working remotely on real world projects with other early-career developers.” It was an amazing experience, and I learned so much during my time there.

Our team of four software developers met weekly with our mentors as we worked to develop a smart shopping app. Our mentors, experienced software engineering professionals, led learning modules on topics like code review, pair programming, communication for developers, and accessibility. During the week, we would pair program to meet the acceptance criteria on GitHub issues for our project, submit PRs, and provide code reviews to our teammates. In our weekly meetings, we shared demos of our feature work, and participated in retrospectives with the team.

Through it all, I learned so much about how to be a good software engineering team member. Here are some of my biggest takeaways:

Write clear documentation

Especially as an early-career developer, it can be tempting to try to make your skills look more impressive by adding complexity for the sake of complexity. This is completely the wrong instinct. Your priority should be on making your code easy to understand.

How can you do this? Write clean code, but also write clear documentation! Before my experience with The Collab Lab, I always thought of documentation as just MDN, and the official documentation of widely used libraries and frameworks. That’s just the tip of the iceberg! Documentation also encompasses everything from descriptive PRs and commit messages to thoughtful comments in your code. As a developer, basically anything you write for people instead of computers is documentation. Make sure you’re writing it to be as helpful as possible.

Descriptive PRs and commit messages

One thing I really loved was that Collab Lab created a template for us to use when creating pull requests. All of our PRs included a description of the change, a list of the acceptance criteria, a checklist of the types of changes made, before and after screenshots or screen recordings of our app, and the testing steps/QA criteria. While this meant that we had to spend a little extra time creating the PRs, the benefit was twofold: 1) the process of creating the PR could help us catch errors before sending the code to be reviewed and 2) code review was so much easier when everyone had a clear understanding of what had been changed and why.

Similarly, writing meaningful commit messages makes code review much easier on your team, and it also makes it easier down the line for yourself and others to understand why changes have been made.

Thoughtful comments in your code

I had been under the impression that code comments were a mark of weakness, and to be avoided at all costs. That is, until one of our mentors, Luis, shared this fantastic video from Sarah Drasner on “The Art of Comments,” that was an eye-opener for me.

While commented-out code (or as Sarah refers to it, “hoarders, but for code” 💀) can certainly clutter up your files, intentional and considered comments can improve the quality of your code.

If you have an unintuitive solution to a tricky bug, it could be helpful to leave a comment explaining why it’s necessary. If you found a solution on Stack Overflow, it could be helpful to leave a comment with a link to the page.

Inclusion necessitates accessibility

One of my favorite things about The Collab Lab was the emphasis on accessibility. The apps we built were expected to be accessible, one of our learning modules was dedicated to accessibility, and throughout the spring cohort we were sent a wealth of accessibility resources and articles through Slack.

To me, an emphasis on accessibility is a natural extension of Collab Lab’s mission:

The Collab Lab increases access to web development jobs for early-career developers and, in particular, people in under-represented groups in tech by providing experiential skills training in software team collaboration and career management.

A mission that prioritizes bringing opportunity to under-represented groups in tech speaks to a desire for a more inclusive tech world. One facet of this is of course bringing more diversity to the teams developing technology. Another is to ensure that the tech we are building is built for everyone, which means making it accessible.

If you’re interested in learning more about accessibility, I’d recommend starting with this article written by the former head of accessibility at the BBC, or the A11y Project (a11y is a numeronym for accessibility, if you haven’t come across that term before).

I learned so much and am so grateful for my time at The Collab Lab, and highly encourage fellow early-career developers to apply! Tomorrow is the deadline for the summer 2021 cohort, and if you’re reading this after June 19, 2021 you can follow the Collab Lab on Twitter to find out about upcoming cohorts!