We like to think of software engineering as a purely logical pursuit—a world of if/else statements and mathematical certainty. But the hardware we run on (our brains) comes pre-installed with "mental shortcuts" that can lead to catastrophic bugs in our judgment. This roundtable is an open post-mortem on the human element of engineering. We’ll discuss how cognitive biases—like clinging to a failing architecture because we’ve already spent months on it, or trusting a buggy PR just because it was submitted by a "rockstar" dev—distort our technical decisions. Come prepared to share your own "logical" lapses and discuss how we can build better team processes to counteract our own biological programming. Topics for the Circle: The "Rockstar" Halo: How our perception of coworkers colors our code reviews. The Sunk Cost Trap: Recognizing when to pivot vs. when to keep polishing a "lemon" solution. Reframing the Problem: How the way we describe a bug or a feature dictates the technical path we choose. Ego vs. Evidence: Building a team culture where "being right" is less important than "getting it right." Kick-off Questions: Can anyone share a time you championed a specific tool or architecture, realized halfway through it was the wrong choice, but kept going anyway? What was the moment you finally let go? Do you find yourself skimming code reviews more quickly when they come from a senior dev you admire versus a junior dev you don't know? How do we fix that bias without slowing down the pipeline? We often judge a new codebase based on the 'mess' we just came from (The Contrast Effect). How do we set objective standards for 'good code' that don't just depend on how much we hated our last project? How does this look to you? If you’re happy with this direction or want to tweak the abstract/questions, please let me know by March 6th. We’re really looking forward to seeing the insights your session will spark!