Pairing is more than just coding with someone else. Pairing is about communication, teaching, learning, positive reinforcements, and growing. This is why at Virtual Coffee, we’re challenging our members to practice their pairing in the month of May and we’re inviting everyone at Dev to join us too!
Before you start, we recommend you take a look at Martin Fowler’s article On Pair Programming.
It seems like my Twitter feed is all about folks joining or asking about invites to Bluesky. I was lucky enough to get an invite this week to be able to check it out, and the user experience is a lot like Twitter, but what’s going on behind the scenes is really interesting.
I collect open source projects like some people collect discord servers. To be accurate, I have 525 repositories. Now, before you yell at me, many of those are from my bootcamp lessons when I was learning to code. But I’ve been known to start and stop projects more than once. What I have learned through that experience is the importance of consistency. If you’re in an organization that has multiple repositories, you might find yourself adding the same files over and over–files like the CODE_OF_CONDUCT.md, Pull Request (PR) and Issue templates, and CONTRIBUTING.md. As developers, adding these files repeatedly starts to feel like we’re violating DRY code principles. Fortunately, the .github repository can help solve this problem.
Communication is key to maintaining a healthy open source project. It’s even more important if one of your projects has more than 100,000 stars. Using a tool like GitHub discussions provides an opportunity for communication for more than bug reports, show and tell, or product announcements. It can provide a path to support and connect the community, and that’s exactly how Vercel is using discussions on their Next.js repository.
I don’t remember writing my first Pull Request (PR), and to be honest, I actually looked to see if I could find it for this post, but I know that I was really nervous because I wasn’t sure if I was doing it “right.” I think I actually spent more time worrying about it than I did actually writing the thing. The good news is that there isn’t really a right way to write a PR, but there are some best practices that can guide your writing and help the maintainer to be able to understand the changes.