I started teaching myself to code a little over a year ago, and even going in I knew that I needed to make sure to make the pursuit social. I value the encouragement and accountability that I can’t get just working on my own, and I also knew that networking was theoretically going be useful somewhere down the line. But I had no idea just how quickly a few fun Meetups would lead me into the biggest challenge and best learning experience that I could have asked for: The Collab Lab.
Two months ago I got accepted into the second cohort of this brand new sort of bootcamp, a place for junior developers, recent bootcamp graduates, and newbie self-taught students like myself to join up in a team to tackle a project and learn about the enormous fraction of a web developer’s career that isn’t covered in code tutorials. For 8 weeks, we built a React app from the ground up, attended weekly conference calls, collaborated on code with our teammates, shared resources, patched bugs, stressed out publicly on Slack, and in the end got some indispensable experience that I sincerely doubt we could have found in any other code school, Meetup, or online resource that I have come across.
This post is my own reflection on the project, now that it is completed. I’ll break it down into eight things that I learned, one for each week, in no particular order and with no guarantee that I won’t ramble on well outside the margins of any reasonable reader’s patience. To start off, here is a time lapse of our team’s weekly demos, showing the app from its initial stages all the way up to the final polish:
We called it Listably, and here it is, a working web app and smart shopping list, hosted on Netlify. Feel free to try it out.
Learning React was far easier for me because I had a consistent set of challenges to overcome, and because I could look at what my teammates were doing and ask them questions about how it worked, or go directly to our coaches to get an explanation from someone who has been using the technology for years.
Right off the bat, we started out by focusing on communication. The project started out with a Zoom conference call to get to know each other a bit, and both teams, two students apiece, started a Github wiki page to keep track of our progress, brainstorm, and collect the resources that we found the most helpful in one place. To be honest, I’m super proud just of this one aspect of Collab Lab. The organization is soooooooo satisfying, and I never could have guessed how important that attention to detail would become based on all the time that I’d spent working on solo projects, for myself and by myself. Here is our lovely wiki home page, with each team’s notes for all 8 weeks:
Pro Tip: Wiki pages are a great place to store sensitive DB information, because no one except you will ever care about reading them.
At the end of week 1/start of week 2, we did another conference call to demo what we'd accomplished, ask more questions, and get started with our new group pairings:
Just getting used to web developer jargon, getting familiar with the concepts of breaking a task down and assigning jobs to each team, and getting comfortable with discussing code on video calls would have been enough to make this project worth the effort.
I love that each of these things would have confused me and made me uncomfortable 8 weeks ago, since they were basically brand new concepts, but now I feel that when I get a job I will already know the ropes.
Most of all, I know that I am now 100% better at explaining code that I’ve written out loud. I am better at making sense to other people out of material that only made partial sense, inside my head, in the past.
Pro Tip: A coder with a strong grasp of developer jargon should be able to summarize an entire topic in such a way that no one else on the team is 100% certain whether they are correct or making things up.
Before Collab Lab, I’d assumed that coding was always done alone. You’d write something, then show it to your team, end of story. Pair programming is a game changer. Just like code reviews or conference calls, pair programming forces you to articulate what you think you know. Every session is a mini exercise in the Feyman Technique.
Pair programming also comes with hazards. I found out that it can be easy to let the more knowledgeable partner drive the whole time. It can feel difficult to suggest taking over if you don’t feel confident about the material, and it can be hard to slow down and explain what you are doing if you get in a flow, get excited, and just want to finish up the work. But navigating those patterns is completely worth it.
Pro Tip: If you find that you are unable to explain how a technology or approach should work, simply ask someone else in the meeting to explain their understanding, and then nod and say something like, "That's basically correct."
Anyone working on their own projects, and many people working on their assignments for various bootcamps, might get the wrong impression of just how powerful Git can be, and how complicated it can get. I feel so much more comfortable with managing branches than I did in the past, and also much more motivated to continue learning now that I can see what a lifesaver certain tools can be. For instance, I only learned about Git Rebase in week 8, and I know it would have saved me some headaches if I'd only found it early on 😭😭.
Specifically, this project taught me how important it is to create separate branches for side issues and patches. So much better than digging through the commits looking for a file I changed 2 days ago.
Pro Tip: When dealing with merge conflicts, never accept any incoming changes, because if the other team wrote their code once, they won't mind doing it again.
Everyone knows that a newbie asking newbie questions might get their head bit off on Stack Overflow or Reddit, and they might come away with no information about how to improve their question in the future, and attribute the incivility to anonymity and trolling.
But what happens if your own team can't help you, because your questions are too vague even for them?
Over the course of this project I was frustrated to find out just how often my questions appear crystal clear while coming out of my mouth, only to get cloudy the moment anyone else has the misfortune of hearing them. It is so important to not assume that other people know what you mean, to put yourself in their shoes and imagine how your question would sound if they aren't currently by some cosmic coincidence reading the same article that you are.
This works in the opposite direction, too: If I think I know what someone else is asking me, I'd do us both a favor by verifying that with my own questions, rather than shooting them a link to an unrelated subject that leaves them more confused than before they asked.
Pro Tip: If you need to exit any conversation quickly, just yell, "Read the docs!" and run away. Oddly enough, not a single one of my coaches or teammates at Collab Lab put this tip to use...
I'd estimate that 70% of the actual coding in the project seemed objective. Sure, there are other ways we could have gone about using hooks or naming variables, but the way towards accomplishing the week's AC was to follow a linear path, using the best idea the either team member could come up with at the moment.
Then, there was the other 30%. It is much harder to make a decision on styling or organization when there is no single right decision. Group dynamics with subjective decisions are more difficult; I learned that I'm more likely to feel stubborn about using MY idea if it is about styling or app structure that feels good to me. I learned that picking your 'battles' (i.e. discussions about preferences on margins 😂) is important, and compromise is important.
Pro Tip: Always insist that your opinion is the best for every issue in the production process, otherwise your team will sense weakness and question the supremacy of your theories.
The conference call for week seven was especially important for me, because Caitlyn gave a great talk about her experience moving from the Collab Lab, in the first cohort, to her first coding job. She talked about how much of the job involves meetings, writing just a few lines of code and reading hundreds, and how many different considerations go into writing good code for a company project rather than a bootcamp lesson or tutorial. Some of what she had to say felt intimidating, a lot felt encouraging, and all of it was insightful.
Pro Tip: I hope no one is taking any of these Pro Tips seriously...THEY AREN'T GOOD IDEAS
I have spent most of my life working on creative projects, and then facing the inevitable struggle of finishing them. Does it need more work, or am I being a perfectionist? If I call it finished, am I being lazy, or pragmatic?
Honestly, this entire period of the project was far easier because it wasn't just my thing. It is sort of low-key amazing to have a structured timetable, a deadline, and a whole team to work together on polishing the final details (and agreeing on what details are nitpicks that aren't worth the effort).
Pro Tip: Van Gogh once said, "No project is ever truly done if you just quit the job before the deadline, refuse to push your commits, and steal the company server." [emphasis mine]
Thanks so much to everyone who participated in this project with me, and to the coaches who put it together. Collab Lab was free for the four of us, and our three excellent coaches all volunteered their time. We used freemium tools, but the project could use some donations to upgrade on Github and Slack, etc. Please consider sponsoring the program.
The Collab Lab Cohort #2 consisted of:
Follow Cohort #3's progress, and beyond, at @_collab_lab