3 ms·

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 writ

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.

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.