> Individualized attention from an expert human probably is indeed the best way to learn and develop skills, but it doesn't scale.
> Any tool that helps a novice build a more accurate mental model of a subject is a benefit, not a crutch. Holding an ideology in opposition to such tools is foolishness.
It looks like you really don't have a substantial argument or credible results to show for why your proposed approach is better, so I'll refute this one: no, any tool that helps a novice build a more accurate model is not necessarily a benefit. It's the same reason that you don't ride a bicycle with training wheels forever, and the same reason singers who can't sing without auto-tune atrophy in their development.
I'm glad you're at least conceding the value of individualized attention from an expert human being the best way to learn and develop skills, but I disagree with you that it doesn't scale. In fact, I'll refute it most strongly -- it's the only thing that /does/ scale.
If you are a novice engineer and you want to progress as fast as possible, start doing real code review as soon as you can. As I mentioned earlier, you don't need to get that from being gainfully employed -- you can and will pick up all of these skills in open source contributions. Start contributing and you'll get feedback. Work on the feedback and you'll start learning what code review is all about in practice. Learn what code review is all about in practice and you'll stop fumbling around in the dark with a debugger.
You only have so many hours in the day. Spend it on what really matters, and spend it on the most important muscles. Do your deadlifts and squats rather than ab crunches.
Hilariously, you and I seem to entirely agree about the point I have by far the strongest conviction on, which is that passively reading code is not the best way to level up skills.
You think people should be taking advantage of human support to learn by actively doing, and I think they should be taking advantage of both human support, if available, and also whatever computer tools are at their disposal independently.
The only reason I started arguing with you is that this prideful machismo ideology of disdain for useful tools that is common among programmers has become a giant pet peeve of mine, over the years since I held that foolish ideology myself. I'm not arguing with you, I'm arguing with myself a decade ago, when I could have avoided a lot of silliness.
> You only have so many hours in the day. Spend it on what really matters, and spend it on the most important muscles.
I also only have so many hours in the day, frankly not nearly enough as it is to do my work and take care of my family, and I don't want to spend any of them trying to figure out how to mentor people who send broken code for review without bothering to first figure out why it doesn't work how they expected and how to fix it. That is not a valuable use of anyone's time; there are plenty of tools available to off-load this to computers, without taking advantage of someone else's "only so many hours in the day".
What I am interested in mentoring people on in a code review or pairing session are the interesting non-mechanical facets of the craft. I love discussing that stuff. But please don't come to me with "I don't understand why this data structure holds this value at this point in the program"; you can figure that out yourself and learn something on your own in the process.
It looks like we are both arguing with ourselves from a decade ago, so at least we share that common ground :)
Candidly, I don't know how constructive this conversation is at this point; given that you've mentioned "I also only have so many hours in the day, frankly not nearly enough as it is to do my work and take care of my family, and I don't want to spend any of them trying to figure out how to mentor people who send broken code for review without bothering to first figure out why it doesn't work how they expected and how to fix it" I find it hard to believe that being one of the best builders in the world is really your goal or that coding is anything more than a vocation for you rather than a calling. And there's nothing wrong with that, but it's going to mean we will simply talk past each other having two completely different conversations.
However, my advice is for those who are not content to be good enough at writing software to maintain a stable job in tech until retirement, but for those who want to go above and beyond that, and stop at nothing to be the best of the best and reap the rewards, internal fulfillment, and sense of purpose that comes with that. Realistically that isn't and it shouldn't be most the goal of most early stage engineers in the field -- it's an expensive goal that even if attained only will make a very specific kind of person (like myself) fulfilled. Your advice is likely good for the former category, while mine would be poor.
For those in the latter category, I'll contextualize my advice based on the this very well written blog post by Dan Luu about the difference between p95 proficiency and p99 mastery. You can sum up my argument as stating that overreliance on debuggers (and other tools such as IDEs) is absolutely something that you see in p95s that you don't see in p99s. P99s can utilize debuggers, IDEs and other tools but it doesn't materially affect how quickly they can execute because of how well trained, fast and accurate their "mental math" flavored problem solving ability already is [1]. If you're curious, please take a look through the linked blog post and see how much you agree with it.
It looks like you really don't have a substantial argument or credible results to show for why your proposed approach is better, so I'll refute this one: no, any tool that helps a novice build a more accurate model is not necessarily a benefit. It's the same reason that you don't ride a bicycle with training wheels forever, and the same reason singers who can't sing without auto-tune atrophy in their development.
I'm glad you're at least conceding the value of individualized attention from an expert human being the best way to learn and develop skills, but I disagree with you that it doesn't scale. In fact, I'll refute it most strongly -- it's the only thing that /does/ scale.
If you are a novice engineer and you want to progress as fast as possible, start doing real code review as soon as you can. As I mentioned earlier, you don't need to get that from being gainfully employed -- you can and will pick up all of these skills in open source contributions. Start contributing and you'll get feedback. Work on the feedback and you'll start learning what code review is all about in practice. Learn what code review is all about in practice and you'll stop fumbling around in the dark with a debugger.
You only have so many hours in the day. Spend it on what really matters, and spend it on the most important muscles. Do your deadlifts and squats rather than ab crunches.