How to Develop Software Engineering Skills in the Age of AI - infoq.com

Software engineering skill development requires slowing down. Tools and AI can accelerate outcomes, but they may not support skill development, Chelsea Troy mentioned in her presentation Leveling up as a Programmer in the Age of AI at Craft conference. Engineers must understand how systems work to learn things. Senior developers can coach juniors by using learning techniques.

There are two modes of software engineering: figuring stuff out and doing stuff. When we want to do stuff, we often speed up. To figure stuff out, we need to slow down, Troy argues. And if doing stuff depends on figuring stuff out, then we’re going to be stuck the faster we try to go: we have to downshift to get anywhere.

Activities that promote learning are, by design, inefficient. They require attention and engagement, to add insult to injury on something that we feel bad at, Troy explained:

We have to sit with something that we feel bad at, and we have to struggle with it. It is that uncomfortable emotion, the confusion, the frustration, that is necessary for us to build cognitive capacity.

Using tools as outcome accelerants often doesn’t support skill development. Even with AI available to us, we need to understand how the systems we are trying to modify work, Troy said.

One concept of the neuroscience of learning is spaced repetition. Skill development reduced to its essentials requires focused attention interspersed with quality sleep, Troy said. She suggested helping junior colleagues by spreading out learning across several bouts of quality sleep, to make it stick.

We internalize information better if we try to guess it first; learning happens when we teach a brain that is already thinking. Troy explained how this concept of outcome prediction works:

As you are learning how something works, you can just stop at each step and ask yourself, "What do I think the next step should be and why, given what I know right now?" And once you have answered, keep going with your learning to find out what the answer actually is. By stopping to ask yourself that question, you can drastically increase the likelihood that you’re going to internalize the answer.

Troy also mentioned the concept of format diversification: people learn information better when they see the same information in multiple different formats rather than repeatedly in the same format:

The reason people think they’re kinesthetic learners is that they read it, listen to it, or see it first, and then they try it and break it. It is the second or sometimes the third way in which they are encountering this information; that’s when it sticks.

Generative AI has changed the landscape of skill development for software engineering. But the biology and psychology of how we solve problems has not changed so quickly, Troy argued. For us to use tools effectively, it’s helpful to understand how they work, but it’s critical to understand how we work and continue to both train ourselves and coach our junior colleagues in techniques and strategies that work with the way we learn, she concluded.

InfoQ interviewed Chelsea Troy after her talk.

InfoQ: What are the cognitive barriers to learning as a software developer in an AI-enabled world?

Chelsea Troy: The cognitive barriers to learning remain largely what they’ve been, because our cognitive structure and potential have not fundamentally changed. But the expectation of an ever-increasing pace of work makes those barriers higher stakes.

Frequently, learning a subject means slowing down and sitting with it. When that becomes a non-option for professional success, developers feel forced to take shortcuts, and they never come back for the learning objective. That’s a systemic barrier, incumbent on managers to guardrail against by managing upwards.

InfoQ: How can we enable learning with junior developers?

Troy: A problem we face often today is the potential for learners to conflate "work completed" with "learning objective accomplished."

When I teach in a classroom of 25 students, I’m not asking them to write a compiler for a small arithmetic language because I personally require 25 copies of this compiler. The actual compilers these students produce are, in fact, of no practical use to me. I’m asking them to do this assignment because the exercise of designing the compiler gives them personal experience with design questions that we discuss for the rest of the quarter. Sure, Claude can write the compiler, but that completely misses the point, because the point was never the compiler. The compiler is a toy problem for learning how to think about harder problems.Learners, academic or professional, benefit from reflecting on how they, as practitioners, want to change in the course of doing their learning. That change—not the quality of the exercise artifact—is the key performance indicator. When folks are new to the industry, they may require the guidance of a more senior developer to determine what change in their thinking an exercise should target. And to succeed in that guidance, senior developers must develop the capacity to pay close attention to a junior developers’ work—not their assumptions about what juniors do, but this developer’s actual work—and respond to that work in their coaching.