This content originally appeared on DEV Community and was authored by Marty Roque
“Every man I meet is in some way my superior; and in that I can learn of him.”
— Ralph Waldo Emerson
When Ralph Waldo Emerson wrote these words in the 1800s, he probably wasn’t thinking about code reviews. But this philosophy became my secret weapon for better software and stronger teams.
The Hierarchy Trap in Tech
The tech industry loves hierarchies. Junior, Mid-level, Senior, Staff, Principal. We wear these titles like badges, and unconsciously, they shape how we interact with each other.
I fell into this trap early. As a “senior” developer, I approached code reviews and pair programming sessions as teaching opportunities—I was there to share my wisdom with less experienced developers.
I was missing half the conversation.
Emerson’s insight flipped this dynamic entirely. What if, instead of focusing on what I could teach, I approached every interaction wondering what I could learn?
The Transformation: From Teacher to Student
After that code review revelation, I started applying Emerson’s principle deliberately. Here’s what changed:
Before: The “Teaching” Mindset
“This component is doing too much. You should break it down into smaller components for better maintainability.”
After: The “Learning” Mindset
“I notice this component handles multiple responsibilities. What was your thinking behind keeping them together? I’m curious if there’s a context I’m missing that makes this approach beneficial.”
The difference is subtle but profound. The first comment assumes I know the right answer. The second acknowledges that the developer might have insights I lack.
What Junior Developers Taught Me
Over the past few years, here are some surprising lessons I’ve learned from developers with less “experience”:
1. Fresh Eyes See Old Problems Differently
A junior developer questioned why we were manually managing form state when we could use a form library. Her fresh perspective led us to adopt React Hook Form, reducing our form-related bugs.
// What I was doing (overcomplicated):
const [formData, setFormData] = useState({});
const [errors, setErrors] = useState({});
const [touched, setTouched] = useState({});
// ... 50 more lines of manual state management
// What she suggested (elegant):
const { register, handleSubmit, formState: { errors } } = useForm();
// Done.
2. Modern Solutions to Legacy Problems
Junior developers often come with knowledge of the latest tools and approaches. They haven’t yet learned that “we’ve always done it this way.”
A team member introduced our team to React Query, transforming how we handle server state. I was still writing custom hooks with useEffect and useState for every API call.
3. User-First Thinking
Less experienced developers often think more like users because they haven’t been deep in the technical weeds for years. They ask questions like:
- “Why does the user have to click three times for this?”
- “What if someone doesn’t understand this error message?”
These questions often lead to better UX decisions than my technically-focused optimization concerns.
The Socratic Code Review
Emerson’s principle transformed my code review process into what I call “Socratic Code Reviews”—focused on learning through questioning rather than teaching through telling.
Traditional Code Review:
- Point out issues
- Suggest solutions
- Approve or request changes
Socratic Code Review:
- Ask about reasoning
- Explore alternatives together
- Learn from different perspectives
This shift in mindset led me to completely reimagine the code review process. Instead of…
// Instead of: "Use const instead of let here"
// I ask: "I see you used let here—are you planning to reassign this variable later in the function?"
// Instead of: "This function is too long"
// I ask: "This function handles several distinct operations. What do you think about the trade-offs between keeping it unified vs. splitting it up?"
// Instead of: "You should add error handling"
// I ask: "What kinds of errors do you think we might encounter here? How should the user experience those errors?"
Learning from Different Experience Levels
The Emerson principle works at every level:
From Junior Developers:
- Latest tools and techniques
- Fresh perspectives on old problems
- User-focused thinking
- Willingness to question established patterns
From Senior Developers:
- Battle-tested architectural patterns
- War stories about what breaks at scale
- Long-term maintenance perspectives
- Domain expertise
From Peer Developers:
- Different problem-solving approaches
- Alternative implementation strategies
- Cross-domain knowledge
- Different debugging techniques
The Compound Effect of Intellectual Humility
After applying Emerson’s wisdom throughout my 13 years in development, I’ve noticed compound effects:
- Better Code: Teams produce higher-quality solutions when everyone’s ideas are valued
- Faster Learning: I learn new techniques and tools much faster than when I relied only on senior-level resources
- Stronger Teams: Psychological safety increases when people feel their insights are genuinely welcomed
- Personal Growth: My technical skills have accelerated because I’m learning from 5-10 different perspectives instead of just my own
Making This Practical: Your Next Code Review
Here’s how to apply Emerson’s principle starting with your very next code review:
1. Replace Statements with Questions
- “This could be optimized” → “What do you think about the performance implications here?”
- “Use this pattern instead” → “Have you considered this alternative pattern? What are the trade-offs?”
2. Assume Positive Intent
Every code choice was made for a reason. Your job is to understand that reason before suggesting alternatives.
3. Share Your Thinking Process
- “I usually approach this differently because…”
- “In my experience, X tends to cause Y, but maybe that’s not relevant here…”
4. Ask for Their Experience
- “Have you used this pattern before? How did it work out?”
- “What other approaches did you consider?”
The Paradox of Expertise
Here’s what Emerson understood that took me years to learn: True expertise isn’t about knowing more than everyone else. It’s about learning more from everyone else.
The moment you think you’re the smartest person in the room is the moment you stop growing. In software development, where technologies evolve daily and user needs constantly shift, the ability to learn from others isn’t just helpful—it’s essential for survival.
Your Challenge This Week
Pick one person on your team who you normally think of as “less experienced” than you. In your next interaction with them—whether it’s a code review, pair programming session, or casual conversation—approach it with genuine curiosity about what they might teach you.
Ask yourself: “What does this person know that I don’t?”
You might be surprised by the answer.
The best developers I know aren’t the ones who have all the answers. They’re the ones who ask the best questions and remain genuinely curious about other people’s solutions.
What’s the most surprising thing you’ve learned from a “junior” developer? Share your story in the comments—I’m genuinely curious to learn from your experience.
This content originally appeared on DEV Community and was authored by Marty Roque