Software Engineering Laws - Human Factors

Software is built by people. Explore the fundamental laws of human factors—from motivation (Yerkes-Dodson) to cognitive bias (Dunning-Kruger)—that every tech leader must know.

Cunningham’s Law

The best way to get the right answer on the internet is not to ask a question; it’s to post the wrong answer

This law observes a peculiar quirk of human psychology that is highly effective for soliciting technical help. A direct question asking for help can often be ignored, as it requires altruistic effort from an expert. However, a confidently stated wrong answer is a magnet for correction. It leverages the human desire to demonstrate expertise and correct inaccuracies, often resulting in a faster and more detailed response than a simple plea for assistance.

Why it happens:

• The Impulse to Correct: For many experts, the drive to fix a factual error is stronger than the drive to help a stranger. A wrong statement is a challenge to their knowledge, and responding is an act of defending the truth (and demonstrating their superior understanding).
• Lower Cognitive Load: Answering a broad question like “How do I configure Webpack?” requires a lot of effort. Correcting a specific, flawed statement like “I just need to add this one line to my webpack.config.js to enable tree-shaking, right?” is a much smaller, more targeted task. It gives the expert a clear entry point to share their knowledge.
• Demonstrating Prior Effort: Posting a wrong answer inherently proves that you have already tried to solve the problem yourself. It signals that you are not just lazily asking for a handout, which makes experts more willing to engage and share their time.

What to do about it:

1. Frame Your Problem as a Flawed Solution: When you’re stuck, formulate your query as a proposed (and likely incorrect) solution. Start with your goal, state your flawed understanding, and present your wrong answer. For example: “I need to optimize my database query. My understanding is that adding an index to every column is the best practice, but my performance is still slow. What am I missing?”
2. Be Confident, but not Combative: Present your wrong answer with a degree of confidence, but be prepared to be corrected. The goal is to trigger the corrective impulse, not to start an argument. Your aim is to get information, not to win a debate.
3. Use It as a Tool, Not a Gimmick: This isn’t about trolling or being intentionally obtuse. The most effective use of this law is when the “wrong answer” is your genuine, best-effort attempt at a solution. It’s a powerful tool for getting unstuck when you’ve reached the limits of your own knowledge, turning your confusion into a catalyst for expert engagement.

Dunning-Kruger Effect

Low performers are unable to recognize the skill and competence levels of other people

This psychological principle explains a common and dangerous dynamic on engineering teams. The skills required to be a competent developer are the very same skills required to recognize competence. A junior engineer who doesn’t understand the importance of maintainability, security, or architectural trade-offs is incapable of recognizing the absence of those qualities in their own work. This leads to the paradox where your least experienced engineers are often the most certain, while your most senior engineers are acutely aware of how much they don’t know.

Why it happens:

• The “Unknown Unknowns”: Low performers lack the metacognitive ability to realize they are low performers. They have not yet been exposed to the full scope and complexity of the domain, so their mental map of “what it takes to be good” is incomplete. They judge their work against this flawed, smaller map and find it sufficient.
• The Curse of Knowledge: Conversely, highly competent engineers often struggle to accurately assess the abilities of others. They find it difficult to remember what it was like not to know something, and may underestimate the difficulty of a task for a less experienced colleague.
• Feedback Deficits: In environments where direct, critical feedback is avoided, an individual’s inaccurate self-assessment is never challenged. Without external calibration, the overestimation of the junior and the imposter syndrome of the mid-level developer are allowed to fester.

What to do about it:

1. Create Objective Yardsticks: Don’t rely on subjective feelings of “good code.” Establish clear, objective standards. Use checklists for pull requests, define explicit coding standards, and create architectural decision records (ADRs). This provides a non-confrontational way to reveal gaps in knowledge. The feedback shifts from a personal “your approach is naive” to an impersonal “this does not meet the team’s documented standard for X.”
2. Implement Structured Peer Feedback: Use structured 360-degree feedback cycles where engineers are required to comment on the work of their peers against specific competencies. This forces a calibration. The junior receives concrete data showing how their impact is perceived, and the senior receives validation that their expertise is recognized and valuable, combating imposter syndrome.
3. Mandate Mentorship and Pair Programming: The most effective way to expose a junior to their “unknown unknowns” is to pair them with a senior on a complex task. Through observation and guided practice, the junior begins to see the deeper considerations they were previously missing. This is the fastest way to accelerate an engineer from “unconscious incompetence” to “conscious incompetence,” which is the first, critical step toward true mastery.

Yerkes-Dodson Law

Elevated arousal levels can improve performance up to a certain point

This law explains the critical difference between productive pressure and destructive stress. It dictates that performance follows an inverted U-shaped curve in response to pressure. Too little pressure leads to boredom and low performance. Too much leads to anxiety and burnout. The leader’s challenge is to keep their team in the “optimal arousal” zone—the peak of the curve where focus and effectiveness are maximized.

Why it happens:

• Low Arousal (Boredom): With no deadlines, unclear goals, or unchallenging work, there is no impetus to focus. This state encourages procrastination, over-engineering simple problems, and a general lack of engagement. Performance is poor due to inertia.
• Optimal Arousal (Flow State): When a team faces a challenging but achievable goal, their focus narrows. The brain filters out distractions, prioritizing creative problem-solving to meet the demand. This is the state of “flow,” characterized by high engagement and peak performance. The pressure is a motivating force.
• High Arousal (Burnout): When pressure becomes excessive—through impossible deadlines, constant emergencies, or a toxic culture—it triggers a threat response. Cognitive function degrades. The focus narrows to a counterproductive tunnel vision, impairing strategic thinking and increasing simple errors. This is the path to exhaustion and breakdown.

What to do about it:

1. Apply Pressure with Purpose: Pressure must be tied to clear, meaningful, and achievable goals. A vague demand to “go faster” is just noise. A specific challenge like, “Let’s land this critical feature in the next two-week sprint,” creates focused, productive tension. Use well-defined, short-term goals to guide the team’s energy.
2. Manage Work in Sprints, Not Marathons: No team can sustain peak performance indefinitely. The key is to create cycles of stress and recovery. Structure work into periods of intense focus (sprints, launch pushes) followed by periods of lower-intensity work (tech debt reduction, planning, hack weeks). This allows the team to recharge, preventing a slide into the burnout zone.
3. Act as a Pressure Regulator, Not an Amplifier: A leader’s job is to modulate stress. Be a sensor for the team’s state. Are bug rates increasing? Is communication becoming terse? Are people consistently working late without a corresponding increase in output? These are signs of overload. Your role is to intervene by de-scoping work, defending the team from external pressures, and reinforcing that long-term sustainability is the goal.