Have you ever watched a junior developer learn something in a week that took you months? Or worked with a senior engineer who refused to touch a new framework because “the old way works fine”?
I’ve been on both sides. Early in my career, I picked up new tools quickly because I had nothing to unlearn. Later, I caught myself resisting changes that felt unnecessary. I remember pushing back when my team wanted to adopt a new testing approach. My argument sounded reasonable — “we’re already shipping, why change what works?” — but the real reason was that I didn’t want to feel like a beginner again.
That reluctance to be uncomfortable is what Carol Dweck calls a fixed mindset. And recognizing it in myself was the first step toward doing something about it.
What Growth Mindset Actually Means (and What It Doesn’t)
Dweck’s research at Stanford draws a simple distinction. People with a fixed mindset believe their abilities are mostly innate — you’re either good at something or you’re not. People with a growth mindset believe abilities develop through effort, practice, and feedback.
For developers, this shows up in concrete ways. A fixed-mindset response to a failed deployment might be “I’m not good at infrastructure.” A growth-mindset response is “I don’t understand this part of the deployment pipeline yet. What do I need to learn?”
But here’s something important: Dweck herself has pushed back on how her research gets oversimplified. In a 2016 piece for Harvard Business Review, she warned against what she calls “false growth mindset” — praising effort regardless of outcome, or just declaring “I can learn anything!” without actually changing your approach. Saying you have a growth mindset doesn’t make it true. The work has to follow.
In my experience, the developers who genuinely practice growth mindset don’t talk about it much. They just keep showing up with questions, admitting what they don’t know, and getting measurably better over time.
Where I’ve Seen It Matter Most
When the Technology Shifts Under You
Every developer eventually faces a moment where the tools they’ve mastered become obsolete, or at least optional. I’ve lived through several of these shifts. Each time, my first instinct was to dismiss the new thing. Each time, I eventually had to sit down, accept that I was a beginner again, and start learning.
The developers I’ve seen navigate these transitions well share a common trait: they don’t wait until the shift is forced on them. They carve out time to experiment before it’s urgent. They’re comfortable saying “I don’t know this yet” in front of their team.
The ones who struggle aren’t less talented. They just can’t tolerate the discomfort of being bad at something again. And in a field where the ground moves every few years, that discomfort tolerance might be the most important skill you can develop.
When You Get Feedback That Stings
Early in my career, I had a code review come back covered in comments. Not nitpicks — real architectural concerns. My first reaction was defensive. My second reaction, about an hour later, was to actually read through the comments carefully. Almost all of them made my code better.
That experience taught me something I’ve tried to carry forward: the gap between receiving feedback and acting on it is where growth mindset lives. It’s not about being grateful in the moment (that’s a lot to ask). It’s about coming back the next day, rereading the feedback with fresh eyes, and using it.
One practical move I’ve found helpful: when you get tough feedback, wait before responding. Sleep on it if you can. Then come back and separate the delivery from the content. The content is almost always more useful than it felt in the moment.
When You’re Asked to Do Something You’ve Never Done
I wrote about this in my post on what I look for when hiring developers — growth mindset is one of the three qualities I screen for. The interview question I use is simple: “Tell me about a time you were wrong about a technical decision.” Candidates with a growth mindset answer honestly. They describe what they missed, what they learned, and how it changed their approach. Candidates with a fixed mindset redirect to a story where they were ultimately right.
The same pattern shows up on the job. When someone on your team is asked to lead a project in an area they don’t know well, watch their response. Do they start by asking questions and scoping what they need to learn? Or do they either overcommit (“I’ve got this”) or retreat (“that’s not my area”)?
The Honest Cost
I want to be straightforward about something the motivational version of growth mindset leaves out: it’s tiring.
Learning a new framework at 9pm after a full day of work is not fun. Admitting to your team that you don’t understand a system you’re supposed to own is uncomfortable. Sitting through code reviews where you’re clearly the least experienced person in the room takes real humility.
Growth mindset doesn’t mean you enjoy all of that. It means you do it anyway because you’ve seen the compounding returns. The developer who spent six uncomfortable months learning a new domain is the one who can bridge two teams a year later. The manager who admitted they didn’t understand the architecture is the one the team actually trusts.
Anders Ericsson’s research on deliberate practice reinforces this: the kind of practice that actually builds expertise happens at the edge of your current ability, with tight feedback loops, focused on specific skills. Just “staying curious” or “taking online courses” isn’t enough. You have to practice the things that are hard for you, specifically, repeatedly.
Growth Mindset in the Age of AI
One more thing worth saying. Growth mindset for developers increasingly means being willing to rethink how you work alongside AI tools. I’ve seen developers dismiss AI-assisted coding outright (“it writes bad code”) and I’ve seen others lean into it so hard they stop thinking critically about the output.
The growth-mindset approach, in my experience, is somewhere in the middle: learn the tools, understand their limitations, and figure out where they make you better versus where they make you lazy. That takes the same willingness to be a beginner, the same tolerance for discomfort, and the same honesty about what you actually know.
Resources
- Mindset: The New Psychology of Success by Carol S. Dweck
- What Having a Growth Mindset Actually Means by Carol S. Dweck (HBR, 2016)
- Peak: Secrets from the New Science of Expertise by Anders Ericsson and Robert Pool
- What I Actually Look for When Hiring Software Developers — my post on screening for growth mindset during interviews
- The Soft Skills That Actually Matter in Software Development — related post on psychological safety and why it matters for teams
Leave a Reply