A tree grown in a greenhouse, shielded from wind, develops weaker wood than one grown in the open.
This isn’t a metaphor. It’s engineering. Trees under mechanical load develop what is called reaction wood: a denser tissue structure formed in response to physical stress. Without the stress, the signal for that structural response never comes. The tree grows. But it doesn’t develop what makes it strong. Researchers discovered this when they noticed that trees grown in protected indoor environments were collapsing under their own weight, well before they should have.
I think about this when I watch engineering cohorts across years.
The students who find the first two years hard, who struggle with the daily practice, who produce shaky first versions of software before they produce good ones, who get corrective feedback early and often, tend to do something different from the students who coast. They build the structural equivalent of reaction wood. Mental models that hold up under load. Habits of inquiry that activate when something breaks. A tolerance for uncertainty that doesn’t paralyse them at the wrong moment.
The gap between the two groups doesn’t show up in Year 1. It shows up in Year 3, when the work starts requiring judgment rather than execution.
What the research calls desirable difficulties
This has a name.
Robert Bjork at UCLA has spent decades studying a phenomenon he calls desirable difficulties. The term sounds like a contradiction. Difficulties are supposed to be problems to eliminate, not features to preserve.
The finding is that certain design choices which make learning harder in the short term produce significantly better retention and transfer in the long run. Spacing practice sessions instead of cramming. Interleaving topics rather than finishing one completely before starting another. Using retrieval prompts during a course, not just at its end. Each feels less productive in the moment. Each outperforms the easier alternative across careful experimental conditions.
The mechanism is retrievability. When material is easy to access from memory, the act of retrieving it leaves little trace. When it is harder to retrieve, pulling it out of memory strengthens the pathway. The difficulty is not damaging the learning. It is producing the learning. This is counterintuitive, and most students and programmes act as if it isn’t true, pacing courses to minimise friction instead of calibrating it.
The full research picture, including Ebbinghaus, Ericsson, Sweller, and Lave and Wenger, is in the learning-science pillar on this blog. The specific point here is what Bjork’s findings mean for who outperforms, and when.
The ceiling that appears at year three
An engineer who coasted through Year 1 often has the grades to show for it. What they may not have is the underlying structure.
Grades in a lecture-heavy programme measure something real. The student understood the material well enough to answer questions about it under exam conditions. What they don’t measure is whether the student built the mental models that survive retrieval under pressure, in a context different from the one where they were first encountered.
Here’s what I see at year three. The early coaster reaches a point where the work stops being about understanding and starts being about judgment. Which abstraction do you reach for? What do you do when the system behaves in a way no lecture described? How do you hold the state of a complex codebase in your head while you are eliminating hypotheses about what is wrong?
These skills aren’t built by passing exams. They’re built by doing real work, with real constraints, under feedback, over a sustained period of time. Engineers who had to build those skills early because the programme demanded it tend to have them at year three. Engineers who didn’t often discover the gap precisely when the work starts requiring it.
This isn’t a moral argument. The engineer who coasted isn’t at fault. The programme that made coasting possible bears the structural weight.
The distinction that matters: productive versus unproductive struggle
This is where the argument needs to be careful, because it can get misused.
Not all early difficulty is productive. Difficulty without feedback isn’t desirable. It’s just difficult.
K. Anders Ericsson’s research on deliberate practice is specific about this. Expertise is built through practice that pushes slightly beyond current ability, with immediate and specific feedback on each attempt. The feedback component isn’t optional. It’s what makes practice deliberate rather than merely repetitive. Without it, a student can practise for thousands of hours and not improve, because they’re repeating the same errors without the signal to correct them.
The students who struggled early and outperformed later did not just struggle. They struggled in an environment that gave them something to do with the struggle. A mentor who caught the specific error and named it. A system that showed them where the code broke and invited another attempt the same session. A community of peers encountering the same difficulty, which made the difficulty feel navigable rather than isolating.
The difference between productive struggle and unproductive struggle is feedback density. How quickly does a specific response arrive? Is it specific to this attempt, or generic? Can the student act on it before the learning moment closes?
Most engineering programmes aren’t designed to produce productive struggle. They produce unproductive struggle by accident, through the mismatch between pace and preparation, with feedback that arrives months later as an exam grade. That kind of difficulty doesn’t build capacity. It builds frustration, and sometimes attrition.
What this means for how a programme should be designed
If productive struggle is the mechanism, then the design question isn’t whether to make the programme hard. It’s whether the difficulty is calibrated, has fast feedback, and sits inside a community of practice that makes it navigable.
At Kalvium, the DOJO system runs daily coding practice across multiple programming languages, with a belt-progression structure that keeps the challenge calibrated to where the student actually is. Six belts per language, each requiring demonstrated performance before the next becomes available. The daily volume is the point. The accumulated effect of thousands of small retrieval and application cycles across four years builds a kind of mechanical strength that a single capstone in Year 4 cannot replicate.
Production code starts from Month 1. Not a tutorial. Not a toy project with a predetermined answer. Real architectural decisions, even small ones, that the student doesn’t fully understand yet, with mentors close enough to give feedback within the session. The understanding forms while the building is happening. That’s the structure Bjork’s research implies, and it’s why production from the first month isn’t about rushing students. It’s about getting to the volume of productive struggle early enough that four years of accumulation is possible.
From Semester 3, students move into one of four work tracks: Simulated Work, Internship, Open Source contributions, or building AI-native products. The difficulty scales. But so does the structure around it: mentors from industry, live feedback from codebases that care whether the code is correct, peers going through the same process in adjacent lanes.
What this produces at year four is a different kind of readiness than what a lecture-first programme produces. Not more knowledge. More capacity for the work that knowledge needs to do.
The work-integrated B.Tech piece gets into the structural logic of how that works across four years. It’s the design question underneath this one.
A closing admission
I want to be honest about something. The argument above can sound clean from the outside. Productive struggle is good. Here’s how to produce it. Here’s what it delivers.
Living it is less clean.
I’ve watched cohorts where students hit the difficulty hard and some of them didn’t find the feedback fast enough. Where the gap between the struggle and the response was larger than the design intended. Where the productive difficulty tipped into unproductive isolation for a specific student in a specific week. HEROS, the real-time learning monitoring system, exists partly for that reason. Mentors review progress regularly and flag when someone’s struggling without navigating. Squads mean the student isn’t encountering the difficulty completely alone.
But I won’t claim we’ve solved it. The design is right. The execution is iterative.
The tree grown in the wind is stronger. That’s still true. The point is that wind without structure, early and relentless enough, can break a young tree before it’s developed enough to respond. The programme’s job is to calibrate both: enough resistance to build strength, enough mentorship to keep the difficulty productive.
We’re still getting that calibration right. I suspect we will be for a while.
Deepak is a co-founder of Kalvium. He writes at the intersection of education design, philosophy, and how engineering careers are actually built. Read more from Deepak or explore the B.Tech category.