As software engineers, we look for best practices throughout the whole software life cycle. We are constantly engaged in research and rethinking as we investigate new technologies and find tighter ways to factor complexity. However, developing better projects faster isn’t just about improving your tools; it’s also about improving your developers. Therefore, we do our best to understand developer work and keep track of research that helps us to understand the coding process as a human process, a series of practices, and a discipline of the body and mind. Yet how do we know what we know?
Recent cognitive science research has debunked three myths about how we think when we code:
Cognition is primarily mental and takes place in the brain.
Actually, cognition is embodied and takes place through the interaction of neurons throughout the whole body. In one of the most fascinating and influential lines of research of the last decade, scientists have shown repeatedly that paralyzing small facial muscles with Botox not only reduces the subject’s reported feelings of emotion, but it also decreases their ability to perceive and recognize the emotions of others.
We don’t know yet if long-term computer use or coding can lead to flatness of affect or trouble perceiving the emotions of others, but we do know that pairing, especially in-person pairing, where there are multiple layers of sensory cues, enlists a wider range of expressive faculties in cognition, which may be one reason why most people find it easier to concentrate and solve problems when they feel connected to their pair.
Coding is similar to math and thinking about coding is like mathematical reason.
We now know that coding is more similar to language and memory cognition than math. In one of the first fMRI studies to investigate how we think when we code, subjects who were trying to solve a coding problem engaged areas of the brain which have been correlated with language and memory rather than mathematical or spatial reasoning. Actually, this is not a new intuition at all; Dijkstra, one of the founders of computer science, proposed the same thing in 1971. The difference is that now we have a grid for understanding the brain as divided into areas by function or type of reasoning, so it is actually possible to evaluate his hypothesis.
Pairing always improves performance.
It turns out that pairing can improve performance most of the time, but it only does so if the pair works well together. What does it mean to “work well together”? Using a technique originally developed for predicting which marriages end in divorce, researchers can predict a pair’s performance based on a few minutes of high-resolution video footage of the pair’s facial muscles. This video is used to determine “hedonic balance,” a measure of the extent to which a pair of people are able to return consistently to a pleasurable mode of interaction.
There are many reasons to opt for pair programming, and at Cloud City it is the approach we advocate for most projects. Pair programming socializes knowledge about your codebase and tools, increasing your “bus factor,” or the number of engineers who would need to be hit by a bus before no one knows how to fix a thing. It ensures developers are engaged in a focused, accountable research process around coding problems. But, for your developers to perform best, your team has to have a good culture: one that predisposes individuals to connect and support each other, and avoids reinforcing defensive behaviors. Our specialty is adding to a growing company’s engineering team, creating a healthy culture and firmly establishing best practices. As a result, you can expect your engagement with Cloud City to improve your engineering team’s velocity.