How purposeful questioning provides benefits beyond code improvement
Imagine moving into a new house. During those first few days, you notice everything—the squeaky bathroom door, the cabinet that doesn't quite close, the light switch placed in an awkward spot. A wise homeowner addresses these issues immediately before unpacking all their belongings, knowing that once they've lived in the house for a month, those same issues will fade into the background of daily life.
When a new developer joins your team—especially an experienced one—they bring this same "new house" perspective to your codebase, architecture, and processes. Their initial confusion, those moments where they tilt their head and think "huh?", might be the most valuable feedback you'll ever receive about your engineering practices.
This isn't about embarking on a complete rewrite or overhaul of existing systems. It's about capturing valuable observations from people who haven't yet developed the same blind spots as your existing team. That’s the “power of Huh.”
Think of it like moving into a new house. As many homeowners know, there's wisdom in fixing issues immediately after purchase but before fully moving in. That squeaky door or sticky cabinet that seems unbearable during the first week becomes practically invisible after a month of living with it.
My father once told me: "Paint everything and fix everything that's broken now before moving your furniture in." It's not just about practicality—it's about capturing problems while they're still visible to you. Once your couch is in place and your routine established, that crooked light fixture you once couldn't stop staring at simply disappears from your awareness.
The same psychological adaptation happens in codebases. What initially appears as an obvious flaw to a newcomer—a confusing naming convention, an overcomplicated process, an unintuitive API—gradually fades into the background for those who work with it daily. Soon, the team doesn't even notice the "squeaky doors" in their codebase anymore.
Every engineering team develops blind spots. Over time, we become accustomed to quirks in our systems, unusual naming conventions, unexpected dependencies, and peculiar workarounds. These oddities become invisible to us—they're just "how things work around here."
It's the same psychological adaptation that makes you stop noticing that crooked picture frame in your living room or the strange workflow needed to start your dishwasher. What was once jarring becomes normal through repeated exposure.
But to a newcomer, these moments of confusion are bright red flags. They represent:
The more senior the engineer, the more valuable these observations become. Seasoned developers have seen many codebases and have intuition about what "feels wrong" or unnecessarily complex.
Here's how to capture these insights:
There's a natural tendency for new team members—especially experienced engineers—to notice all the broken windows and immediately want to rewrite everything. This enthusiasm is valuable but needs channeling.
Think of the new homeowner who walks into a fixer-upper and becomes overwhelmed by the endless list of potential improvements. Not everything needs to be addressed at once, but certain things—like that bathroom door that wakes up the whole house when opened at night—should be fixed before the opportunity is lost.
The "huh?" journal isn't necessarily a to-do list. It's an opportunity to:
The goal isn't to fix everything—that's rarely practical. Instead, use these observations to make deliberate decisions about what's worth addressing now, what should go on the technical debt backlog, and what remains as an acknowledged quirk with documented reasoning. This process can actually reduce the urge to rework everything unfamiliar by providing clarity on why things are the way they are.
This practice doesn't need to end after onboarding. Teams that excel at continuous improvement often maintain a "huh?" channel in their chat tool or a dedicated section in their retrospectives.
Some teams even schedule periodic "fresh eyes" sessions where engineers rotate to unfamiliar parts of the codebase specifically to bring new perspective.
At CaseMark, we implemented this practice last year. Some of the improvements that resulted from new hires' "huh?" moments include:
But the benefits weren't just technical. We also observed:
To implement this practice on your team:
Just like fixing a house's issues before moving in all your furniture, addressing the most jarring "huh?" moments early in a developer's tenure both improves the codebase and prevents that valuable perspective from fading away as they acclimate.
The most valuable feedback often comes from those who aren't yet immersed in your team's collective assumptions. By systematically capturing those "huh?" moments, you transform brief windows of fresh perspective into lasting improvements for your engineering organization.
Just as you might walk through a friend's home and immediately notice things they've become blind to ("How can you stand that dripping faucet?"), your newest team members possess a fleeting superpower—the ability to see your codebase as it truly is, not as you've grown accustomed to it being.
Remember: today's new hire confusion is tomorrow's cleaner architecture, better documentation, and smoother onboarding for everyone who follows. Don't let those squeaky doors remain unfixed until nobody hears them anymore.
How purposeful questioning provides benefits beyond code improvement
Imagine moving into a new house. During those first few days, you notice everything—the squeaky bathroom door, the cabinet that doesn't quite close, the light switch placed in an awkward spot. A wise homeowner addresses these issues immediately before unpacking all their belongings, knowing that once they've lived in the house for a month, those same issues will fade into the background of daily life.
When a new developer joins your team—especially an experienced one—they bring this same "new house" perspective to your codebase, architecture, and processes. Their initial confusion, those moments where they tilt their head and think "huh?", might be the most valuable feedback you'll ever receive about your engineering practices.
This isn't about embarking on a complete rewrite or overhaul of existing systems. It's about capturing valuable observations from people who haven't yet developed the same blind spots as your existing team. That’s the “power of Huh.”
Think of it like moving into a new house. As many homeowners know, there's wisdom in fixing issues immediately after purchase but before fully moving in. That squeaky door or sticky cabinet that seems unbearable during the first week becomes practically invisible after a month of living with it.
My father once told me: "Paint everything and fix everything that's broken now before moving your furniture in." It's not just about practicality—it's about capturing problems while they're still visible to you. Once your couch is in place and your routine established, that crooked light fixture you once couldn't stop staring at simply disappears from your awareness.
The same psychological adaptation happens in codebases. What initially appears as an obvious flaw to a newcomer—a confusing naming convention, an overcomplicated process, an unintuitive API—gradually fades into the background for those who work with it daily. Soon, the team doesn't even notice the "squeaky doors" in their codebase anymore.
Every engineering team develops blind spots. Over time, we become accustomed to quirks in our systems, unusual naming conventions, unexpected dependencies, and peculiar workarounds. These oddities become invisible to us—they're just "how things work around here."
It's the same psychological adaptation that makes you stop noticing that crooked picture frame in your living room or the strange workflow needed to start your dishwasher. What was once jarring becomes normal through repeated exposure.
But to a newcomer, these moments of confusion are bright red flags. They represent:
The more senior the engineer, the more valuable these observations become. Seasoned developers have seen many codebases and have intuition about what "feels wrong" or unnecessarily complex.
Here's how to capture these insights:
There's a natural tendency for new team members—especially experienced engineers—to notice all the broken windows and immediately want to rewrite everything. This enthusiasm is valuable but needs channeling.
Think of the new homeowner who walks into a fixer-upper and becomes overwhelmed by the endless list of potential improvements. Not everything needs to be addressed at once, but certain things—like that bathroom door that wakes up the whole house when opened at night—should be fixed before the opportunity is lost.
The "huh?" journal isn't necessarily a to-do list. It's an opportunity to:
The goal isn't to fix everything—that's rarely practical. Instead, use these observations to make deliberate decisions about what's worth addressing now, what should go on the technical debt backlog, and what remains as an acknowledged quirk with documented reasoning. This process can actually reduce the urge to rework everything unfamiliar by providing clarity on why things are the way they are.
This practice doesn't need to end after onboarding. Teams that excel at continuous improvement often maintain a "huh?" channel in their chat tool or a dedicated section in their retrospectives.
Some teams even schedule periodic "fresh eyes" sessions where engineers rotate to unfamiliar parts of the codebase specifically to bring new perspective.
At CaseMark, we implemented this practice last year. Some of the improvements that resulted from new hires' "huh?" moments include:
But the benefits weren't just technical. We also observed:
To implement this practice on your team:
Just like fixing a house's issues before moving in all your furniture, addressing the most jarring "huh?" moments early in a developer's tenure both improves the codebase and prevents that valuable perspective from fading away as they acclimate.
The most valuable feedback often comes from those who aren't yet immersed in your team's collective assumptions. By systematically capturing those "huh?" moments, you transform brief windows of fresh perspective into lasting improvements for your engineering organization.
Just as you might walk through a friend's home and immediately notice things they've become blind to ("How can you stand that dripping faucet?"), your newest team members possess a fleeting superpower—the ability to see your codebase as it truly is, not as you've grown accustomed to it being.
Remember: today's new hire confusion is tomorrow's cleaner architecture, better documentation, and smoother onboarding for everyone who follows. Don't let those squeaky doors remain unfixed until nobody hears them anymore.
