When we deal with a complex, unfamiliar codebase, our ability to comprehend its architecture, logic flows, and modular interactions is limited by our working memory capacity. Cognitive overload frequently occurs when first onboarding onto projects with massive codebases authored by many engineers over the years. Overloaded by myriad classes, functions, data flows, and interconnections spanning files, interfaces, databases, we become overwhelmed, which makes it nearly impossible to make progress in understanding the system.
Pair programming can expand our information processing abilities as we unravel complex code. Verbalising questions forces both programmers to organise thoughts and build shared mental models. The dialogue also uncovers holes in understanding, asking a question like “What data enters this function?” can quickly surface critical differences in prior knowledge. Debugging together enables one programmer to track logical flow while the other watches the variable states across the stack trace. The right programming partner matters - an experienced architect may notice hidden patterns faster than a new intern. But even explaining code to a rubber duck forces more systematic reasoning than solo debugging.
On the other hand mob programming with larger coder groups is not necessarily better for complex tasks. Coordinating real-time code changes across 6 simultaneous programmers becomes chaos, filled with decision making blocks and diffusion of responsibility. However, code walkthrough sessions and organised workshops can be useful group techniques when it comes to knowledge sharing. Code reviews, design doc brainstorming, and GitHub issues discussions also enable larger groups of people to develop shared understanding of the system and result in useful abstractions that simplify future discussions of a specific part of the codebase.
The key is deliberately balancing intense solo analysis with targeted peer discussions. Done right, this helps overcome the shortcomings of our working memory by leveraging the group cognition - the synergy of knowledge that two programmers have about the problem and its context. Of course, this is not the only way of dealing with complexity - improving design of a system for better modularity, the use of better abstractions, good naming practices and documentation also help maintain a productive level of cognitive load across solo programmers and small groups of engineers working on large codebases. However, the right amount of collaboration would certainly push all those good practices forward and keep them at the core of the team’s engineering culture.
Knowing when to go heads down into a problem on your own versus bringing in an additional perspective of your teammate is a critical skill to develop for being successful as a software developer.