One benefit to immersing myself in a new space, software development, is being exposed to new tools and practices I’d like to apply to Mechanical Engineering. The biggest is Pair Programming which is pretty central to The Recurse Center. If you’re not familiar, the basic idea is two people look at one screen together (either virtually or in person) and write code collaboratively. One person usually “drives” while the other “co-pilots” but switching off every 15 minutes or so is encouraged. This practice is widely used outside of Recurse though. I’ve met at least one Recurser who worked for a company you’ve heard of where their team exclusively programmed in pairs. Here’s my pitch why this should be common practice in Mechanical Engineering:
- Built in design review: The two engineers are continuously checking each-others work. This ensures at least two people have carefully reviewed what is being created in detail versus the “yeah I spun your CAD model around” design reviews that happen after a design is created.
- Problem Solving: A partner to bounce ideas off of or troubleshoot with is extremely helpful when working–to use a Recurse phrase–“at the edge of your abilities”. You get unstuck faster than when you have to stop and find help.
- Learning and Development: Nothing says the skill levels of the pair must be evenly matched. In fact it rarely happens. Even if one person is an expert at bearing design, they may not be an expert in Solidworks, which someone out of college may know really well. So by working together, the bearing expert learns a few CAD tricks, and the junior employee learns more about the bearing design. All sorts of pair matches work–Pairing can be a great way to learn something you know nothing about, all the way to forming an “A Team” and tackle something really hard together.
- Redundancy: Two people become familiar with the design so critical knowledge doesn’t become isolated in a single person.
- Teamwork: Pairing is a great way to have the casual contact that builds relationships between team members. It works well virtually so it’s a great way to work together, even if you’re not literally “together”. You’re also accountable to your partner to work in organized blocks of time with a clear purpose.
- Productivity: It may seem like twice the effort goes into producing the same result but that’s nearsighted. When you look at all the benefits like those discussed above, the work is higher quality, and will result in time savings in the long run.
I used some mechanical engineering examples to illustrate my point, but I could have taken that all out and made it totally generic and it still would be a clear case that Mechies should be pairing. Another thesis I could make is “parametric CAD design is just programming shapes” and if programmers find pairing useful, why shouldn’t shape programmers use it too? A theme of people who have “never graduated” Recuse is that part of the transformation is having the time and space to experiment with new ways and philosophies of working. Well I’m here to say in Week 4 that pair programming works and it would work in more spaces than programming!