When I lived in Amsterdam in 2014, my friend Samuel ran a weekly meetup, called a “peer lab”, at a café near the city centre. You just showed up at the same time as other developers, grab a coffee, hop on the wifi, and work on whatever you wanted to. If you ran into problems, there were other engineers to talk to and ask for help.
I really liked the peer lab. Working remotely for a company across the ocean left me short on in-person interactions with other developers, which was common for other attendees. We worked remotely but worked together every Saturday morning. (Samuel ran the meetup on Saturday mornings to keep recruiters from showing up.)
When I moved to New York, one of the first things I did was start a peer lab of my own out of the Artsy office. They provided the space, the wifi, and some pizza, and my colleague Orta and I ran the event. Every Saturday, still, but more because by then I was in the habbit of starting my weekend off with a productive start.
Eventually, I built a website to help other people start their own peer labs: peerlab.community. Dozens of peer labs have been created in all kinds of countries: The United States, Canada, Russia, Hong Kong, India, Australia, Spain… all over! It’s been really rewarding to take Samuel’s idea, reproduce it in New York, and then help replicate that around the world.
Last month marks five years since I started the peer lab in New York. It’s been a rewarding journey – I’ve made a lot of friends, and I’ve had a positive impact on a lot of people’s lives. But in this post, I wanted to focus on what I’ve learned running the same weekly meetup for five years. These are lessons that I have learned, but they might be applicable for other meetups, too.
Without a doubt, the most important lesson I learned was to keep the meetup simple. This was something Samuel taught me, but it’s something I’ve re-learned myself.
Peer labs don’t have talks. There are no speakers to coordinate. No planning required at all. The hardest part is to just show up every week.
One Saturday, someone who ran a peer lab in another city showed up to ours in New York. They brought an idea: have a short, optional standup where people introduce themselves and what they’re working on. What a great idea! It’s great because it’s high-impact while being pretty simple. So now we do a standup, too.
I’ve always ran the peer lab with at least one other person. When I first moved to New York, Orta helped me out. He showed up most Saturdays anyway, but if I was sick or on vacation, he could take over for me. Nowadays, it’s Justin, Matt, and other Artsy Engineers who help out. Nowadays, peer labs are a de facto part of Artsy Engineering.
A few years ago, while I was going through some severe depression, I decided that I needed my Saturdays back to myself for a while. Someone from the NYC tech community took over running the meetup out of a nearby coworking space for three months, until I was ready to run things again.
Peer labs are a place to learn, but not be taught. The thing is, some people want to be taught. As the organizer of the meetup, people would naturally come to me with their questions. I usually redirect them back to another attendee, so the two can learn from each other. Of course, sometimes the questions are super-interesting, so I’m always on the look out for interesting conversations.
At various times, people have asked for a peer lab Slack / Discord server, or prepared talks, or something that would require more work from me. Blah. I’m already donating every Saturday morning, and if Peer labs were too much more work, I probably wouldn’t do them (at least, do them weekly).
To keep the meetup simple (see the first point) I had to get okay with saying “no” to people’s suggestions for the peer lab, too.
Saying “no” has been a lifelong struggle of mine. If you struggle to say “no” yourself, let me introduce you to my favourite way to turn someone down: “I’d love to, but I can’t.”
Finally, I try to imbue the meetup with a sense of Ash Furrow-ness. This is a meetup that I run with other engineers, but since I created it I am very happy to give it a distinctly me feeling.
Within software engineering, there exists a culture of decorating one’s laptop lid with stickers. Stickers can show people the kind of technologies you’re into, which podcasts you like, what teams you respect, etc. I’ve heard it described as “flagging for nerds”, which, yeah that’s pretty accurate.
I love this. I love this aspect of my professional culture. In the records of me speaking at conferences, you’ll usually see my laptop lid covered in stickers.
Beginner engineers can have a hard time getting started. That’s why I added a sticker exchange to the peer lab.
Not many people leave stickers, but plenty of people take them. Over the years, I’ve grabbed extra stickers from conferences and meetups that I’m at. I also periodically contact companies and teams I respect to get stickers directly.
So there we go. That’s been what I’ve learned from the last half-decade of running a peer lab. It’s been an extraordinarily rewarding experience, and I highly recommend you start your own.
I really have to emphasize here that you should start your own. Don’t worry if it doesn’t take off, or you get busy, or whatever. If you run a peer lab for a few months and then stop, that means you did a successful peer lab, and I’m proud of you.