The Collab Lab offers early-career engineers the chance to gain real-world collaborative experience by working remotely on projects with other developers. Our program includes modules to help you excel as a teammate and prepare for your first developer role.
The goal of this project is to work together to build a “smart” shopping list that learns your shopping habits over time, putting items you are most likely to need to buy in the near future at the top.
Every team builds their app from the same set of instructions, but each comes out a little differently, reflecting the personality of the group.
📺 Check out a video demo of the app team #6 made here:
When new developers and mentors join the Collab Lab community they join a group of brilliant and supportive friends that stretch across the globe. Every quarter a new cohort starts that consists of several regionally-based teams. Those teams are comprised of four developers who collaborate to complete an app of their own and three mentors to help support them through the project.
Knowing how to code is just one aspect of being a professional web developer. Another super important skill is knowing how to collaborate effectively on a software team—that’s where Collab Lab comes into play!
A portion of your dedicated hours each week will be spent pair programming with your partner for the week—this is where the most magical collaboration happens.
Pair programming offers some really exciting opportunities to teach/learn from your partner, get a different perspective and/or insight on the issues you’re facing, and drive forward progress on your goals.
There is no one “right” way to pair program, but in general you will meet with your partner on Zoom to work through the story or task you’ve chosen for that week. You’re encouraged to test out different approaches to pair programming to see what works best for your and your partners’ collaboration styles.
The project is organized in GitHub as a set of user stories, each with a description of the desired functionality as well as acceptance criteria that describe how you know whether the task or story is complete. You can find the stories on the project board on GitHub. This is referred to as the “backlog” (the collection of stories) and represents the work needed to complete the project.
A task or story is “done” when the following are all true:
- The AC have been met
- In the case of a UI feature, it has been reviewed for accessibility
- The code to complete the task or implement the feature has been reviewed and approved by the other pair of developers
- The Product Owner (i.e. one of the mentors) has accepted the work as satisfactorily meeting the requirements
Each week the team will split into pairs and each pair will be responsible for completing a single story from the backlog.
At the end of the 10 week project all of the stories will be complete and we will have a beautifully functioning app that the team has collaboratively built!
It’s super helpful both to yourself and the mentors for you to document your work. This can prevent you from losing track of details or decisions you make with your pair buddy. It also allows mentors to catch up on your progress when you ask for help.
One of the first things you & your pair buddy should do each week is create a draft PR for your work. This allows you to have a conversation about the work right alongside the code. Coupled with questions and discussions about your approach in the issue itself, this is nice way of documenting your progress as you go.
Most of our team coordination will happen through the Collab Lab Slack team and in particular your team channel.
If you’re not already super familiar with Slack, no worries! Here are a couple of tips to help you use it like a pro!
- Threads threads threads! No seriously, threads! 😅 Threads are great because they do 2 really helpful things:
- They encapsulate conversations so the future you is able to find both the question and the answer in one place
- They keep notifications to a minimum, giving people the option of following a conversation or not.
- Speaking of notifications, tag people in when you need their attention. “
@stacie, could you review this PR?” is better than “Can someone review this PR?” because the latter may not be seen for a while depending on the person’s notification settings. When you need to alert the whole channel to something use@here. We also have groups set up such as@group-tcl-9and@group-tcl-9-mentorsas shortcuts to tagging in certain groups. Use them! - Use GIFs and emoji liberally! Communicating via text can come across really dry. Don’t be afraid to communicate a little emotion along with that question about React hooks! 🤪
Note: You can disable the animation of gifs and emoji in the Slack app itself. Visit the Slack Help Center to learn more.
Work will be done on feature branches in git. Branches should be named in the following way:
<initials of person 1>-<initials of person 2>-<short description>
For example:
st-an-connect-to-firestore
The hypothetical example above has Stacie Taylor and Alejandro Ñáñez working together on connecting the app to Firestore. Each of them will be able to work on the feature branch independently, but only one of them will submit the merge request when the work is ready (described in more detail below).
When you’re ready to start work on a feature, one person in your pair should create a local branch following the naming convention above, then push the branch to GitHub so your pair buddy can pull it down to their local environment. The following steps should work to do just this:
git checkout -b an-example-feature-branch
git push -u origin an-example-feature-branch
When you and your pair partner have working code that you believe is ready to be merged to main and deployed, you will follow the following steps:
- Create a “pull request” (PR).
- Notify the other pair team in Slack that you have a new PR for them to review.
- Incorporate feedback from the other pair team into your work until both you and they are satisfied the code is ready to be merged.
- Request that one of the mentors review the PR for final approval.
- Once approved, merge the PR into
main. (Your code will be built and deployed to production automatically thanks to Firebase Hosting.) - Check your work on the production site.
- Celebrate! 🥳
The project should take about 60 hours total over the 10 weeks. That breaks down to roughly 6 hours per week. At least 2-3 hours of that time will be spent pair programming with your partner, 1 hour will be allotted for Weekly Syncs, and the rest of your time will be researching, code reviewing, exploring learning modules, and organizing your work.
A week sounds like a long time in some ways, but part of working on a team is accounting for coordination costs. Let’s walk back our goal of demoing from the production URL on the weekend to see when different things need to happen. This example timeline assumes the Weekly Sync is on Sunday.
- Monday, Tuesday, Wednesday — Work out approach, research if needed, and pair program
- Thursday — Complete story and ask for peer feedback
- Friday — Respond to/give peer feedback on PRs and ping mentors for feedback
- Saturday — Respond to mentor feedback on PRs
- Sunday — Demo on production!
Having watched many cohorts before yours, our advice is to front-load the work as much as possible in the first couple of days of each week. Some of the stories are trickier than they appear on the surface!
Every weekend the team will gather for 1-hour on Zoom for a Weekly Sync. Those meetings will always follow a familiar pattern:
- Demos/technical discussion (15 minutes)
- The call will always start with each pair presenting a quick demo of the feature they built in “production”, the live version of the app that is deployed to the web for the world to see. This is followed by a concise walk-through of the code they wrote to build it. This is a common practice on most software teams that lets you practice talking about your work, which can come in handy in a job interview setting!
- Learning module discussion (30 minutes every other week)
- Each week, you'll explore a range of modules at your own pace, focused on vital skills like git, code reviewing, job fit and technical interviewing. These modules will help you become a great teammate and prepare for your first developer role. In weekly syncs, you can discuss these topics with your team and gain valuable insights from your mentors.
- Retrospective (30 minutes every other week)
- In our retros, we will share appreciation of our teammates, talk about what went well from a process perspective, and discuss what we could do to improve how we’re working together.
- Planning (15 minutes)
- Mentors meet with pairs to talk through approach to the upcoming week’s work (15 minutes)
Whew, that was a lot, right? There’s a good chance (💯%) we’re forgetting or glossing over something important, so please be noisy on Slack as things come up. We will do our best to get you unstuck. Also, lean on each other for help as well! Finally, work in the open so everyone can benefit from your questions.
Let's run through a quick, high-level recap of what your time at The Collab Lab will look like:
- During your time at The Collab Lab, you’ll gain experience working on a software team, led by people in the industry, on a project structured in a way very close to what you’d see at many companies.
- We will spend 10 weeks working together to build a smart shopping list app. See a demo of the same app that a previous team built here.
- Collab Lab teams consist of 4 developers and 3 mentors.
- Each week, the team’s developers will break up into 2 pairs. Each pair will tackle a single issue from the project board in the team’s GitHub repo.
- Developers will each spend about 6 hours per week working on the project. These hours include pair programming with weekly partners, researching, working with partner asynchronously on issues, creating pull requests, and doing code reviews.
- Each weekend during the program, the team will have a Weekly Sync where developers will demo the feature they built in the previous week and a mentor will lead a learning module or the team participate in a retrospective.
Your team will kick off the project with your first weekly sync this weekend. In the meeting we will present a Learning Module on git best practices and get everyone set up to collaborate on the app. Afterwards you will schedule pair programming sessions with your partner to work through your story of the week!
Margaret Hamilton and her team's code for the Apollo Project