One of my biggest disappointments in pair programming over the past few years is realizing how many developers are unable to explain what the code they just wro

One of my biggest disappointments in pair programming over the past few years is realizing how many developers are unable to explain what the code they just wrote actually does. Like, they can't do a verbal debug, stepping through each line and describing the expected state. Everyone copies from the best, but it seems a lot of developers just copy, paste and then let the IDE autofix any warnings. The code block becomes a magical incantation rather than a sequence of operations. It never occurred to me that the reason I look at code differently is simply because I am from am older generation. I only started coding professionally in the 90s, but even then compiling wasn't especially fast so it was expected to review code before kicking off a build. And as a kid in the 80s I spent more time reading code in books and magazines than actually at a computer typing it in, so I had to think about and imagine what it would do. There is definitely a lot to be said for the modern world of linters, unit tests etc running continuously - I wouldn't want to give up any of that up! But I do wonder if the developers who aren't able to explain what their code actually does are missing some fundamental skill. Clearly it doesn't matter to the customer because these developers still produce working products, but it feels to me like some level of quality has been lost.