3 ms·

> whenever he completed a piece of code, he always ran it in his head a few times to make sure that nothing could go wrong It's a bit disturbing to me that th

> whenever he completed a piece of code, he always ran it in his head a few times to make sure that nothing could go wrong It's a bit disturbing to me that this is being voiced as a feat of some kind. Everybody should be doing this and most people are capable of it. I'm sure you are as well, despite your own pessimism. If you're not doing this, there's been some failing among your mentors. You can develop this skill with intent and practice and you really really really should. That's what the programming part of our job is: not pasting in snippets from Stack Overflow, not asking Copilot for something that you hope is okay, not vomiting code until it gets a big green OK from your tooling, not gluing together library functions whose implementation and constraints we don't understand. You should be developing a clear mental model of your code, what supporting utilities it references, how those utilities work and what constraints they impose, as well as actively considering edge cases that need specific attention and the constraints your code projects outward to its callers. You won't be able to do this consistently during your first couple years of working. And that's fine. But something's gone deeply wrong with your craft if you haven't gotten a handle on it once you're more professionally mature. But rather than feeling incapable of doing it yourself and in awe of those who do, you just need to commit yourself to practicing it as much as you can until it becomes second nature.

01HNNWZ0MV43FF 2y ago
I can't run code in my head if I'm working at a high level where every function calls into thousands of lines of code. This comes up a lot at work. If I'm writing 100 lines of greenfield code then yeah, anything is easy then.
- swatcoder 2y ago
  From my original comment: > what supporting utilities it references, how those utilities work and what constraints they impose The responsibility isn't to memorize and model every function called up and down your whole stack. Often, you don't even have full insight into that if you wanted it and of course you couldn't hold that all in your head even if you wanted to. But you don't need to. The responsibility is simply to thoroughly understand how each function you call works insofar as you're using it. You should be confident, not hopeful, that the state you've arranged for that function call is a valid state for it, you should have a informed, not incurious, sense of its general behavior characteristics (fast or slow, high or low resource demands, thread safety, etc), and you should be able to make informed predictions about what its output should like given the state you pass in. It's actual implementation will often be opaque, or at least opaque at some depth, but between the function's documentation, any access to its source, and your own insight of how something like that function would likely or necessarily implemented, you can and should be able to fully model it for the purposes of your own invocation.
- markus_zhang 2y ago
  That's the reason why I think getting the right position, right team and right work is the only antidote for this. If you work close to the metal you only have 1-2 levels of abstraction. If you need to call a library which calls a library which calls a VM which calls some syscall you simply don't have the brain to trace down all those -- plus you are not allowed the luxuries of tracing it down because the ticket is wanted ASAP. Getting the right job is the only thing needed to take you away from this hell.
markus_zhang 2y ago
> Everybody should be doing this and most people are capable of it. I agree with you that everyone should be doing this, but I disagree that most people are capable of it. There are two points of arguments: 1) People get tired when running code in head, so I can't do it very long. What I observe is that 10X programmers can do this consistently, even when they are tired. John Carmack is a very good example. I won't say it's in the genes, but I suspect most people don't have a huge room to improve -- or, if theoretically they have a huge room to improve, realistically they don't 2) Even when I can run code in my head, when I'm in a good condition, I can only run MY part of the code, i.e. I simply cannot run any library code. I'm working on a simple Hex editor with C++/SDL2/ImGui, and running SDL2 code and ImGui code in my head is way above my capability. Last night I kept running a piece of code in my head and I couldn't really find ANY place it could go wrong, until I figured out that must be the scan code that ImGui is using, so I switched to a recent version (mine was from 2020) and the issue went away. What I observe from the 10X programmers, is that they usually work on very low level problems, so they have the benefit of not relying on external libraries. David Cutler is a good example here.
- swatcoder 2y ago
  Like I suggested, developing the skill is largely a matter of practice and it becomes both more easy and more robust as you work to hone it. It is not the defining characteristic of "10x developers" like Carmack. He's of an especially rarified sort and not really someone to look at as a role model in the first place because his experience and background is so idiosyncratic. What we're talking about here is just an essential characteristic of "competent developers" and is among the array of characteristics that distinguish early-career developers from more genuinely senior ones. Your stepwise growth of the skill is very highly correlated with what value you'll provide as a developer (and therefore what roles and rates you can pursue). Next time you encounter a frustration like you found in (2), don't just blindly update ImGui and hope for the best. If you think it might be the problem (a great insight because you were modeling it!), open your local version of ImGui and see if you can find where it's a causing problem, because you're now going to be very invested in reading ImGui closely (to find the issue) and you're going to learn so much that will help you better model ImGui in the future, as well as better model other utilities. After you've put some effort into that, and hopefully even found the issue (but perhaps not), then go to GitHub and try to use changelogs, issues, PR's, etc to see if you can find some specific commits that might be related to the issue. Analyze those commits yourself and see what you can learn from them, improving your understanding about utilities like ImGui and how they're implemented and where bugs like the one you encountered might lurk so you can track them down more quickly in the future. Only then should you consider updating your local version. And while you might be reading this and thinking "who's got time for that?!", it doesn't really take that much time once you get the hang of it through practice, and every time you do it, you're making huge investments into your own proficiency and value (-> future roles and rates). Don't skimp, just do it! (As for #1 - "getting tired" -- aspiring athletes, whether professional or amateur, get tired during training too. And that's okay, because again, it's all a process of development and growth. To train, you push as far through the tiredness as you can, and then make the compromises you need to, always trying to push yourself a little bit farther before you do. By doing this, that wall of tiredness moves further and further out and you become that much more capable and productive.)

01HNNWZ0MV43FF 2y ago

I can't run code in my head if I'm working at a high level where every function calls into thousands of lines of code. This comes up a lot at work. If I'm writing 100 lines of greenfield code then yeah, anything is easy then.

swatcoder 2y ago
From my original comment: > what supporting utilities it references, how those utilities work and what constraints they impose The responsibility isn't to memorize and model every function called up and down your whole stack. Often, you don't even have full insight into that if you wanted it and of course you couldn't hold that all in your head even if you wanted to. But you don't need to. The responsibility is simply to thoroughly understand how each function you call works insofar as you're using it. You should be confident, not hopeful, that the state you've arranged for that function call is a valid state for it, you should have a informed, not incurious, sense of its general behavior characteristics (fast or slow, high or low resource demands, thread safety, etc), and you should be able to make informed predictions about what its output should like given the state you pass in. It's actual implementation will often be opaque, or at least opaque at some depth, but between the function's documentation, any access to its source, and your own insight of how something like that function would likely or necessarily implemented, you can and should be able to fully model it for the purposes of your own invocation.
markus_zhang 2y ago
That's the reason why I think getting the right position, right team and right work is the only antidote for this. If you work close to the metal you only have 1-2 levels of abstraction. If you need to call a library which calls a library which calls a VM which calls some syscall you simply don't have the brain to trace down all those -- plus you are not allowed the luxuries of tracing it down because the ticket is wanted ASAP. Getting the right job is the only thing needed to take you away from this hell.

markus_zhang 2y ago

> Everybody should be doing this and most people are capable of it. I agree with you that everyone should be doing this, but I disagree that most people are capable of it. There are two points of arguments: 1) People get tired when running code in head, so I can't do it very long. What I observe is that 10X programmers can do this consistently, even when they are tired. John Carmack is a very good example. I won't say it's in the genes, but I suspect most people don't have a huge room to improve -- or, if theoretically they have a huge room to improve, realistically they don't 2) Even when I can run code in my head, when I'm in a good condition, I can only run MY part of the code, i.e. I simply cannot run any library code. I'm working on a simple Hex editor with C++/SDL2/ImGui, and running SDL2 code and ImGui code in my head is way above my capability. Last night I kept running a piece of code in my head and I couldn't really find ANY place it could go wrong, until I figured out that must be the scan code that ImGui is using, so I switched to a recent version (mine was from 2020) and the issue went away. What I observe from the 10X programmers, is that they usually work on very low level problems, so they have the benefit of not relying on external libraries. David Cutler is a good example here.

swatcoder 2y ago
Like I suggested, developing the skill is largely a matter of practice and it becomes both more easy and more robust as you work to hone it. It is not the defining characteristic of "10x developers" like Carmack. He's of an especially rarified sort and not really someone to look at as a role model in the first place because his experience and background is so idiosyncratic. What we're talking about here is just an essential characteristic of "competent developers" and is among the array of characteristics that distinguish early-career developers from more genuinely senior ones. Your stepwise growth of the skill is very highly correlated with what value you'll provide as a developer (and therefore what roles and rates you can pursue). Next time you encounter a frustration like you found in (2), don't just blindly update ImGui and hope for the best. If you think it might be the problem (a great insight because you were modeling it!), open your local version of ImGui and see if you can find where it's a causing problem, because you're now going to be very invested in reading ImGui closely (to find the issue) and you're going to learn so much that will help you better model ImGui in the future, as well as better model other utilities. After you've put some effort into that, and hopefully even found the issue (but perhaps not), then go to GitHub and try to use changelogs, issues, PR's, etc to see if you can find some specific commits that might be related to the issue. Analyze those commits yourself and see what you can learn from them, improving your understanding about utilities like ImGui and how they're implemented and where bugs like the one you encountered might lurk so you can track them down more quickly in the future. Only then should you consider updating your local version. And while you might be reading this and thinking "who's got time for that?!", it doesn't really take that much time once you get the hang of it through practice, and every time you do it, you're making huge investments into your own proficiency and value (-> future roles and rates). Don't skimp, just do it! (As for #1 - "getting tired" -- aspiring athletes, whether professional or amateur, get tired during training too. And that's okay, because again, it's all a process of development and growth. To train, you push as far through the tiredness as you can, and then make the compromises you need to, always trying to push yourself a little bit farther before you do. By doing this, that wall of tiredness moves further and further out and you become that much more capable and productive.)