3 ms·

You and I agree on this being an important "muscle" to build. But this thread is not about people using this muscle, it's about people developing it afresh and

You and I agree on this being an important "muscle" to build. But this thread is not about people using this muscle, it's about people developing it afresh and further exercising it. What you described with senior engineers doing code reviews and such is analogous to a ballet dancer on stage performing, but I'm talking about doing a thousand pliés in a practice studio. The stage doesn't have a barre or a mirror, but the studio does, and it would be foolish not to use those useful tools when exercising. I'm not totally sure if we're just talking about two different things - use vs. exercise - but a plain reading of your comments makes me think that you think the best way to improve one's structural reasoning (or "mental debugger" as another commenter put it nicely) skills is to just read more code. But I'm sorry, that's just not right. It is much better for building a good mental model of how code executes to simultaneously inspect and interrogate it as you're reading. It isn't necessary, it's just better. A crutch is just not the right analogy. Rather, it's an aid that makes exercise more effective so that you're stronger when it comes time for game day. Or, to come at this from another angle: Surely you agree that just reading code is not actually helpful for developing the reasoning ability you're talking about in your comment. Wouldn't you agree that novices need to run the code they read, to see what it does? Otherwise they are guessing , and as novices, they are almost certainly guessing wrong. Without anything to check their guesses against, they are likely to just assume they're right and internalize that likely-wrong mental model. I certainly had to painstakingly undo a lot of my incorrect mental model from bad guesses early on. The more that can be avoided, the better! If you agree with that, which I suspect you do, then I'd put it to you that a debugger is just an efficient and effective tool to better aid in this process of guessing what code does and then checking those guesses, in order to further develop and internalize a correct mental model of how it works. It's like if you could run a unit test surgically exercising exactly the code path you're interested in, exactly up to your breakpoint, and assert on exactly the program state you're guessing about to confirm or deny your hypothesis. But you can do it interactively, without needing to write test code. It's an amazing capability and learning aid! It's very bad advice to tell people not to use it as they are learning.

yowlingcat 3y ago
> I'm not totally sure if we're just talking about two different things - use vs. exercise - but a plain reading of your comments makes me think that you think the best way to improve one's structural reasoning (or "mental debugger" as another commenter put it nicely) skills is to just read more code. I've already said twice, both in the original comment and in the follow up, that my point is about applied code reading in the context of code review, not in a vacuum. The first time you decided to respond to a made up point which I never made, I clarified it. Now that you're doing it a second time, it's clear you're arguing in bad faith and putting words in my mouth. I wonder why you keep on arguing against a strawman point that I never made rather than actually responding to my argument. Is it because you are incapable of understanding the point I'm making? Perhaps. Is it because you're deliberately ignoring it out of cognitive dissonance as you know it would weaken your argument, and you'd have to admit that you're arguing for something which is the wrong strategy? I hope not, but that's my best guess. The rest of your comment is impractical. If a novice is struggling with understanding and working with a piece of code, do you really think the best way for novices to learn is to "figure it out" with a debugger, or do you think they should ask for help through code review or pair programming with someone else working with them on the project? You seem to be arguing under the assumption that software engineering is a solo sport. I am arguing that software engineering is a team sport and those who treat it like a solo sport tend to underperform and plateau in their skill development. I stand by what I said. Debuggers are a crutch. Crutches can be useful but you shouldn't rely on them. Learn how to reason about code in the abstract (which you learn to do by learning fundamentals of computer science and applying them in a team context with others who can) and you won't need it because you can compile the AST of the codebase in your head. Moreover, this skill is MOST critical to develop when you're early in your career because it's when you have the neuroelasticity to learn new ways of reasoning about and problem solving with code. I was forced to do this by early career engineering leader mentors and while painful and humbling, I am very thankful for it because it put in place the practical fundamentals for me to architect large, performant, scalable and revenue generating systems from scratch with very little issues. If someone thinks that's impossible to learn whether late in their career or early in their career, that speaks more to their shortcomings than to an issue in the technique. For what it's worth, many of the strong early career engineers I've worked with (1-2 years experience max) have also been able to do this, and often times even better than many mid to late career engineers. As you may expect, these strong early career engineers end up running circles around their more experienced counterparts pretty quickly.

yowlingcat 3y ago

> I'm not totally sure if we're just talking about two different things - use vs. exercise - but a plain reading of your comments makes me think that you think the best way to improve one's structural reasoning (or "mental debugger" as another commenter put it nicely) skills is to just read more code. I've already said twice, both in the original comment and in the follow up, that my point is about applied code reading in the context of code review, not in a vacuum. The first time you decided to respond to a made up point which I never made, I clarified it. Now that you're doing it a second time, it's clear you're arguing in bad faith and putting words in my mouth. I wonder why you keep on arguing against a strawman point that I never made rather than actually responding to my argument. Is it because you are incapable of understanding the point I'm making? Perhaps. Is it because you're deliberately ignoring it out of cognitive dissonance as you know it would weaken your argument, and you'd have to admit that you're arguing for something which is the wrong strategy? I hope not, but that's my best guess. The rest of your comment is impractical. If a novice is struggling with understanding and working with a piece of code, do you really think the best way for novices to learn is to "figure it out" with a debugger, or do you think they should ask for help through code review or pair programming with someone else working with them on the project? You seem to be arguing under the assumption that software engineering is a solo sport. I am arguing that software engineering is a team sport and those who treat it like a solo sport tend to underperform and plateau in their skill development. I stand by what I said. Debuggers are a crutch. Crutches can be useful but you shouldn't rely on them. Learn how to reason about code in the abstract (which you learn to do by learning fundamentals of computer science and applying them in a team context with others who can) and you won't need it because you can compile the AST of the codebase in your head. Moreover, this skill is MOST critical to develop when you're early in your career because it's when you have the neuroelasticity to learn new ways of reasoning about and problem solving with code. I was forced to do this by early career engineering leader mentors and while painful and humbling, I am very thankful for it because it put in place the practical fundamentals for me to architect large, performant, scalable and revenue generating systems from scratch with very little issues. If someone thinks that's impossible to learn whether late in their career or early in their career, that speaks more to their shortcomings than to an issue in the technique. For what it's worth, many of the strong early career engineers I've worked with (1-2 years experience max) have also been able to do this, and often times even better than many mid to late career engineers. As you may expect, these strong early career engineers end up running circles around their more experienced counterparts pretty quickly.