Working Code Podcast - Episode 043: Relay Race Programming
You might think that "programming" is a relatively straightforward concept: take abstract ideas and codify them into lines-of-code (LOC). But, within this broad abstraction, there are a multitude of implementation details. Some engineers love to hunker down and write code inside a metaphorical bubble; mob programmers love to dog-pile on the same machine, blitzing the problem until it's obliterated; and, pair programmers methodically alternate responsibilities between a "driver" and a "navigator" in cooperative pairing sessions.
On today's episode, Carol shares her team's approach to product development which sounds more like "Relay Race Programming". First, her team does some up-front design and planning in order to orient the work. Then, her team divvies up the tasks, processes the work in parallel, and keeps a constant line-of-communication open such that they can unblock each other as soon as issues arise. While this approach takes some getting used to, Carol believes that it has increased her productivity, decreased her Pull-Request review latency, and opened the door to many more mentorship opportunities.
All that and more on this week's show:
... featuring these beautiful, beautiful people:
- Adam Tuttle → Website, Twitter, LinkedIn
- Carol Weiler → Twitter, LinkedIn
- Tim Cunningham → Twitter, LinkedIn
- Ben Nadel (that's me) → Website, Twitter, LinkedIn
With audio editing and engineering by ZCross Media.
For the full show notes and links, visit the episode page. And, be sure to follow the show! Our website is workingcode.dev and we're @WorkingCodePod on Twitter and Instagram. Or, leave us a message at (512) 253-2633 (that's 512-253-CODE). New episodes drop weekly on Wednesday.
Reader Comments
@Ben,
I too work on a team where we're pretty much always working on separate projects, and the only collaboration are at the intersection points not overlapping. I wish we had enough time to do more knowledge transfer, if only for better coverage during vacations, if not for handling team members leaving better. Thankfully, for us, it's more about coverage, as I've only lost two devs from my team over the last 10 years.
I wonder if there's a loose connection from this episode to the previous episode "Strong opinions, loosely held" with what I might term "Strong code ownership, loosely held". You probably want strong code ownership by your devs, so that they feel empowered to do what they need to as well as dive in when there's something not working well, but no so much that you're walking on eggshells if someone else needs to work on it.
@Danilo,
My team has an extremely high "bus factor" for certain areas of the app. For example, our billing/payment system was completely rewritten 2-years ago when we switched payment processors. It was rewritten by a single developer; and, to date, he's the only person on my team that understand how any of it works. As such, he'll be "that guy" until the end of time 🤣 or, at least, until the end of the legacy platform.
I have such a love-hate relationship with this idea. On the one hand, putting so many eggs in one basket is dangerous. But, on the other hand, it means that when work does have to get done, we know we have someone who can jump in an karate chop the problem with [relative] ease (as opposed to having another dev jump in, learn up on the system, and then try to complete the task).
I definitely feel strong ownership over the code. But, I also try to follow the "Boy Scout Rule" as defined by Robert "Uncle Bob" Martin, which simply states that you should leave code better than you found it. So, when I have to jump in and work on other people's code, if I see something "gross", I at least try to clean it up a bit if I can.
@Ben,
I totally get leaving code better than when you found it, but based on how you were talking about having a negative reaction when someone else's touches your code, it seems that you're not quite feeling it if it is someone else tries to leave the code better when it's your code.
We can all be better when it comes to working with others. And we can all benefit from multiple eyes being on the code, if only from a knowledge transfer benefit. We have someone that's been on the team for 25 years, and so many times it's been, "well, I can show such and such how to do it, but that'll take 5 times as long, and I have so many other things to do, so I'll do by myself just to get it done, and we'll train next time". Unfortunately, next time is like tomorrow, it's never tomorrow. 😢
@Danilo,
Ha ha, yeah, I do have issues sometimes when people touch my precious code! 😨 But, I hope that my issue is when people are not leaving it better, but instead just slapping updates in. One that grinds my gears is when there's an existing list like:
... which is clearly alphabetized and then someone comes in and pulls this:
.... ok, ok, must calm down.