Code reviews often hinge on pattern matching heuristics rather than an objective evaluation of code. Reviewers rely on **visual cues, personal preferences, and familiarity with patterns** in the code, which introduces their own biases. This reliance on pattern recognition often creates confrontational situations without clear paths to resolution. Feedback needs to be based on more objective measures. ## The Neuroscience of Reading Code The human brain processes code using a combination of language, visual, and working memory areas, leading to biases based on familiarity and superficial structure. ### Neural Mechanisms Involved in Reading Code The neuroscience behind code comprehension reveals that several areas of the brain work together when developers read and understand code. 1. **Language and Math Processing Areas** - **Broca's and Wernicke's Areas**: Traditionally associated with language processing, these regions are activated during code comprehension, indicating that reading code has similarities to reading natural language. - **Intraparietal Sulcus (IPS)**: The IPS, involved in numerical and logical reasoning, is also active when developers solve coding problems. This points to a mathematical nature of code comprehension which is an additional domain of neuroscience that can tie into our understanding. 2. **Visual Processing and the Ventral Stream** - **Visual Cortex Activation**: The primary visual cortex processes visual aspects of code, such as syntax highlighting and overall structure. - **Ventral Stream (What Pathway)**: This pathway, responsible for object recognition, helps developers identify familiar coding patterns and structures. 3. **Working Memory and the Prefrontal Cortex** - **Dorsolateral Prefrontal Cortex (DLPFC)**: This area is engaged in maintaining and manipulating code elements during comprehension. - **Executive Functions**: The prefrontal cortex aids in planning, decision-making, and error detection during code analysis. ## Cognitive Processes in Code Comprehension ### Chunking Theory Chunking is a process by which individual pieces of information are grouped into larger, meaningful units. In coding, experienced programmers recognize common code patterns as chunks, reducing cognitive load and enabling faster comprehension. Through experience, developers build a repertoire of these chunks, allowing them to efficiently parse and understand complex code. However, this reliance on chunking can be problematic in code reviews. Reviewers often experience bias towards patterns they recognize, leading to an increased cognitive load when they encounter unfamiliar code structures. If code does not conform to these established patterns, it can create an impression that the code is inherently "wrong," even if it is logically sound and functional. This additional cognitive load can lead to unfair assessments, with reviewers favoring familiar code over innovative or equally effective alternatives. ### Cognitive Load Theory Cognitive load theory describes how different types of mental effort affect a person's ability to understand information. In coding, **intrinsic load** refers to the inherent difficulty of a task, such as understanding a complex algorithm. The more complex the logic, the higher the intrinsic load. **Extraneous load**, on the other hand, is influenced by how information is presented—poorly structured or overly convoluted code unnecessarily increases this load, making it harder for a reviewer to comprehend. **Germane load** relates to the cognitive effort directed at learning and understanding new schemas. **Mental models** are cognitive frameworks that help developers organize and interpret information. Developers use these schemas to understand code behavior, predict outcomes, and debug effectively. With experience, developers begin to automate the recognition of certain code patterns, reducing the conscious effort required to process them. However, this reliance on established mental models can contribute to biases during code reviews, as reviewers may reject code that does not fit their pre-existing schemas. ### Empirical Studies on Code Comprehension 1. **fMRI Studies** - **Brain Activation Patterns**: Research has shown that reading code activates brain regions involved in language, memory, and attention. - **Comparative Studies**: Experts and novices display different neural activations, with expertise reducing the cognitive load required to comprehend code. 2. **Eye-Tracking Research** - **Visual Attention**: Eye-tracking studies demonstrate that experienced programmers focus on distinct parts of the code compared to novices, often predicting areas of interest based on code structure. - **Pattern Recognition**: Experts employ rapid saccades and fixations, utilizing pattern recognition to process code efficiently. These studies highlight that expertise significantly changes how code is processed, with experienced developers leveraging chunking and mental models to reduce cognitive load. However, this same expertise can contribute to biases during code reviews, where unfamiliar code structures cause resistance due to the extra cognitive effort required, leading to negative feedback. ## What Should Be Done Instead Shift away from relying on pattern matching and instead provide feedback using objective standards. ### Reducing Cognitive Load in Code 1. **Rely on Lint Rules**: Consistent formatting reduces extraneous cognitive load, aiding in comprehension. Linting tools enforce standardized formatting, removing the need for debate over individual idiosyncrasies. 2. **Evaluate Design Complexity by Number of Files**: Evaluate design and code complexity via the number of files that comprise a feature. The fewer the number of files, the less cognitive load is required to trace and understand the full implementation. Too many files can lead to unnecessary abstraction, forcing reviewers to navigate through multiple files, which increases both extraneous and intrinsic load. ### Objective Code Evaluation Metrics 1. **Cyclomatic Complexity**: Utilize cyclomatic complexity to ensure that functions remain comprehensible and do not become overly complex. Keeping cyclomatic complexity low makes the code easier to test and maintain. 2. **O(1) Complexity Targets**: Where possible, aim for O(1) or simpler computational complexity. Reducing computational complexity ensures that the intrinsic load remains low, making logic easier to trace and improving code performance. 3. **Minimize Clicks to Functionality**: Measure the number of "clicks" or steps it takes to reach the core functionality of the code. Fewer clicks imply less abstraction and make it easier for reviewers to follow and understand code logic. 4. **AI Contextual Understanding and Maintainability**: To improve readability, employ objective measurements such as line lengths, documentation coverage, etc. Additionally, write code in a way that encapsulates all necessary information and context so that when provided to a GPT tool, the tool can make modifications without requiring further context or clarification. Structure features with a code and file arrangement that can be loaded into and maintained by an LLM. ## Additional Cognitive Biases ### Expertise-Induced Bias - **Overreliance on Familiar Patterns**: Experts may dismiss unconventional code that doesn't fit their established schemas, potentially overlooking innovative solutions. - **Fixation on Previous Knowledge**: Known as the Einstellung effect, prior experience can hinder problem-solving by limiting one's perspective. ### The Halo Effect - **Definition**: The overall impression of a person influences specific judgments about their work. - **Application in Code Reviews**: A reviewer may favor code written by developers with a strong reputation, overlooking potential issues. ### Cognitive Ease and Fluency - **Definition**: Information that is easy to process is perceived as better or more truthful. - **Impact on Code Perception**: Readable code with familiar patterns is judged more favorably, even if alternative approaches are functionally superior. ### Anchoring in Code Assessment - **Initial Impressions**: The first piece of code reviewed sets an anchor, influencing subsequent judgments. - **Adjustments**: Reviewers may insufficiently adjust their assessments from this initial anchor, leading to biased evaluations.