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.”

The New House Analogy

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.

Why "Huh?" Moments Matter

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:

1. Documentation gaps: Places where tribal knowledge hasn't been properly captured
2. Technical debt: Legacy decisions that no longer make sense in the current context
3. Onboarding obstacles: Hurdles that slow down the time-to-productivity for every new hire
4. Potential bugs: Areas where ambiguity might lead to mistakes

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.

Implementing a "Huh?" Journal

Here's how to capture these insights:

For New Team Members:

• During your first two weeks, keep a dedicated document or notebook for recording moments of confusion
• Note down anything that makes you pause, question, or need to ask for clarification
• Be specific: record the file, function, service, or process that triggered the confusion
• Capture your initial thoughts: "I expected X but found Y" or "This seems more complex than necessary because..."
• Don't self-censor—even if you later learn there's a good reason for something, the initial confusion is still valuable data

For Engineering Managers:

• Set the expectation from day one that this journal is valuable and will be reviewed
• Schedule a dedicated session at the end of weeks one and two to review the journal
• Create psychological safety by emphasizing that the journal isn't criticism but valuable insight
• Take notes and prioritize which observations might warrant changes
• Recognize patterns across multiple new hires' journals
• Be transparent about what can be addressed now versus later
• Help new team members understand the historical context that led to current design decisions

Finding Balance: Observation vs. Action

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:

1. Surface invisible issues: Things the existing team has grown blind to
2. Prioritize thoughtfully: Distinguish between critical issues and acceptable quirks
3. Build context: Help new members understand why certain trade-offs were made
4. Identify documentation gaps: Sometimes the "huh?" is simply missing explanation

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.

Beyond Onboarding: Creating a "Huh?" Culture

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.

Real-World Impacts

At CaseMark, we implemented this practice last year. Some of the improvements that resulted from new hires' "huh?" moments include:

• Rewriting confusing naming conventions in our API layer that had caused bugs for three previous quarters
• Creating automated setup scripts that cut onboarding time by 60%
• Discovering an undocumented dependency that was causing intermittent test failures
• Identifying three services that could be consolidated, reducing operational overhead

But the benefits weren't just technical. We also observed:

• New team members felt their observations were validated and heard from day one
• Discussions around "huh?" moments became opportunities for knowledge sharing about historical decisions
• The feeling of needing to "rewrite everything unfamiliar" diminished as understanding increased
• Documentation improved significantly where knowledge gaps were identified

Getting Started

To implement this practice on your team:

1. Create a simple template for the "huh?" journal
2. Include it in your onboarding documentation
3. Schedule the review sessions in advance
4. Maintain a separate list for "quick fixes" that can be addressed immediately
5. Track which insights led to meaningful improvements
6. Share successes with the wider team to reinforce the value

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.

Conclusion

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.