Comment by ysofunny
3 months ago
one of the main things I've generalized from programming:
that we must think about everything as if it were two completely disjointed things: what we or the user or the interface does, and how it works... and the potentially completely 'unrelated' reality of what the computer is actually doing
consider for example, git. git has a lot of subcommands we seldom use directly, but all commands we use a lot are always combinations, or rarely scripts, of multiple of them seldomly used git (sub?)commands
the point being, how the mind of the programmer is all about saying and thinking about "git commit" but actually knowing and considering that it really is many runs of "git hash-object" and lots of other git subcommands behind the scenes.... and so on given how there's gonna be syscalls and eventually assembly instructions moving AND COPYING bits all over the computer
I really love this framing of it. I think this is exactly what I spend most of my time doing.
Although I might say there are three levels I'm thinking about all the time: There are the interface and the "what will the computer actually do" levels, but also a really important one in between of thinking about the future reader of the code.
What's interesting, now that you've got me thinking about this, is that I'm not only doing this exercise while programming, but that it's also what I'm doing during all the other parts of my work. While in meetings discussing what to do and how and in what sequence, it's this same exercise of thinking about how we'll need to interface to the human world, and then how we'll get the computer to do what we need, and then how we'll do both those things in a way that will be comprehensible and maintainable.
So I think you've really hit the nail on the head here. To me, this is the job.