134 likes
·
1.7K reads
15 comments
Yes! This is awesome to see!
I've long been a big advocate for pair programming. Sadly, as careers go on, software engineers become less and less interested in pairing, for some reason. I've seen a senior engineer storm out of the room when it was suggested that they pair program on a ticket: "I don't need to pair! I'm not a child!" (true story).
A couple things I'd like to add to your post—if I may—would be that effective pairing starts with good expectations and setup.
1. — It helps if you can have a machine setup that you're both familiar with (you're probably going to have to disable a lot of the short-cuts, sadly), and you 100% need two keyboards (however that situation looks)... I used to bring my external keyboard to work with me so I could hand my laptop to a pair, and use my own external keyboard at the same time.
2. — You'll also want to ensure that you keep taking breaks, as it can be intensive. IMO also, it's okay if some things are not paired on. When you get good at pairing it's easy to know when something is a pairing thing and when it's not. However, a mantra I had in an old team was: "default to pairing". i.e a task should be shown that pairing isn't necessary, not the other way around.
3. — If you've never tried "Ping Pong Pair Programming" I highly suggest you do. Or another exercise that's great is just setting a 10 / 15-minute timer and swapping whoever is driving the session (this is a lot more useful than it might sound). And as a rule of thumb, I bias towards the least experienced developer having fingers on the keyboard.
Anyway, these are just some general thoughts or ideas I wanted to throw into the mix. I don't see a lot of posts about pairing nowadays, and apart from teams I've introduced pairing to, I've not actually seen it ever in the wild throughout my career.
Thanks for the write up ✌️
Wow Lou, really appreciate you sharing and adding some very valuable thoughts to this conversation!
I've tried ping-pong pairing in bootcamp, but not with my CTO. Reason being is that when we work on some of his stuff, I haven't the foggiest where to start- the gap in knowledge is too wide at this point. Definitely hope to try other types of pairing in the future though, as I skill-up!
(Also, we could be better at taking breaks... 😅)
Thanks again, Lou! 🙏
Annie 🦄⚡ amazing, sounds like a great environment, I'm envious! I wish my induction was that healthy! 🙏 Keep up the posts.
Awesome post, I feel like I would absolutely THRIVE if given an opportunity like this. I'm hoping I get one in the future once I get out of boot camp.
Thank you!
I hope you will too! I didn't really do pair-programming for my first 1.25 years as a dev but now, knowing the benefits, it's hard to imagine not having it. Best wishes, Paolo 😊
Great Post! I am actually building a platform where developers can find other devs to pair program with.
Check it out: mydevfriend
This probably changed my perspective on pair-programming for the better. Definitely going to try it out more now!
Thanks Annie 🦄⚡!
Yay!!! So glad to hear, Bhargav! It took me a while to get into the swing of things and definitely works better with someone you trust/get along with. But as with many things in life, practice makes better! Have fuuunnn & squash 'em bugs good!!! 😁
Annie 🦄⚡ this is spot on. Great work.
Pair programming can be so disorienting, but eventually you get accustomed to it. I think it's also a better product when more minds attack a problem or equation. Keep up the great work!
Thanks so much Brett, I couldn't agree more!! My CTO has looked at something I've coded before and was like, "Hmmm.. I didn't think of doing it that way, but I like it!!!" 🤟
Great work Annie
This is really interesting and explains everything well, and sums things up really good. This is gonna be a really useful resource for me. Awesome work :D
Annie 🦄⚡ you rock, my friend! 🔥
Awww, you made my morning Catalin. 🤗 Right back atcha!
I really liked reading your post imposter syndrome is a problem many developers have to deal with. This is a great resource.