8 ms·

"All I can say is: close your eyes and think what it might be. My first software designs were largely done with my eyes closed. Thinking if I hit that key what

"All I can say is: close your eyes and think what it might be. My first software designs were largely done with my eyes closed. Thinking if I hit that key what should happen if I hit that key..." In my experience, this is a common characteristic of the 10x programmer. It is not about frameworks, it is not about patterns; both things help, but it is really about to be able to run the system in your head.

mwcampbell 9y ago
Current real-world systems are too complex to simulate accurately in your head. I've learned to assume that I don't really understand a system until I've collected sufficient trace output from the real thing.
- jorgeleo 9y ago
  That only means that the system needs better abstraction layers so you can think of it at different depths. Of course, you need to learn enough about the system to be able to do it, I am glad you wait for that.
  - JustSomeNobody 9y ago
    And better doesn't mean more and probably means fewer.
- taeric 9y ago
  This implies you are trying to simulate fully. Just as most programmers don't have to simulate the rather complex circuitry in an adder, you probably don't have to simulate the complexities of most of your system. Or, when you do, you can take the simple parts for granted. Similar to plotting a trip to the grocery. You don't think of the effort your body is doing to stay balanced. Nor of reading labels Yet you probably have a decent idea how long the trip will take.
  - boomlinde 9y ago
    Maybe "simulate" is the wrong word, then. Especially accurate simulation. Plotting to shop groceries is not a simulation. You create a model of the problem and roughly base your solution on that. The model is based on a very large number of assumptions and a great deal of ignorance of the entirety of the process it represents. You can relatively accurately predict that when you press "OK", the dialog will close. You can maybe assume and envision a future where calling "closeDialogBox(box)" will close the dialog box. Maybe the lines in it that which simply call "box->close()" and return "STATUS_OK" can be assumed to do what you think it will do. The underlying machine code, too. The CPU, sure. In the end the whole system is beyond your control and is subject to random input like cosmic rays flipping bits, power outages, leaking caps. Before that you have the operating system, the compiler, the overall codebase, perhaps more likely sources of mental model mismatches. I certainly wouldn't draw the line of "accurate simulation" at the source code base. IMO one of our strengths as humans is that we can easily create these simplified models based on rough probabilities founded on previous experience, "gut feelings" and weighing risks and go great lengths without accurate simulation.
    - taeric 9y ago
      I'm sympathetic to your point, but I suggest you have the wrong take here. It might have been better if people referred to modeling the system, but that ship sailed, as it were. That is, we are primarily discussing how people use that phrase in informal communication. And the you'd be surprised just how far many can take the simulations in their head.
      - boomlinde 9y ago
        It's not like "simulation" is commonly used to describe one's thoughts. So your idea is that we're just arguing about some sort of hypothetical colloquial sense of the word, even though it's obviously used here in the context of comparing humans to computers?
- mattmanser 9y ago
  Are they? I "run" systems in my head all the time. I'm familiar with the code base, from that I'll know roughly where the bug is. I can tell you which function a bug will probably be in and how it's probably happening, just from having the symptoms described to me. Hell, even when I'm not familiar I can guess what's happening based on past experience. It's some sort of spatial ability, like navigating a map (though I recently found out I'm terrible at visualizing and almost completely lack a 'mind's eye'). I also find I rarely get lost in computer games and very rapidly learn FPS maps. Maybe's it's one of those weird skills you don't even realise some of the population lack. Personally I've always thought using traces are a massive crutch that are too expensive in cost vs benefit ratio, I don't get the point. Far too many extra lines of code for too little gain.
  - psyc 9y ago
    I work this way to a large extent. I have pretty good recall of the whole codebase, sufficient to step through in my head and spot actual bugs while AFK. I really dislike it when people make assertions about what others supposedly cannot do.
    - nsxwolf 9y ago
      I don't believe you.
    - 5ilv3r 9y ago
      I believe this is called "being mechanically minded". If you understand the physical rules and the components, you understand the inner workings. Good mechanics have this. Bad mechanics don't. Sadly being an auto mechanic pays little, but the skills are obvious in good programmers too.
  - foobarchu 9y ago
    Yeah, this is exactly how my brain works, and has led to my specialty being finding the difficult bugs that have eluded others. I've got a loose leaf notebook that I use to help, but all that's really in it is rough drawing of circles with labels scraweled next to them, fashioned in a shape with maybe some lines between them. All it's for is helping me imagine the system better in my head to connect the dots. It's affected my design philosophy too, I always try to design software such that I could draw it as a series of discrete components with input/output arrows between them (and, of course, the assumption that could theoretically zoom in to a component to see whats inside of it)
- vanderZwan 9y ago
  That is still thinking within the boundaries of programming logic. The point that Ted Nelson makes is that you should never stop thinking beyond the immediacy of that, and always remember what the code is ultimately hoping to achieve in the end: > "Thinking if I hit that key what should happen if I hit that key..." The answer to what should happen is not rooted in thinking about the code. Programming is taking meaningful thoughts and turning them into thoughtless instructions that can be executed by a machine. And that is hard! We take it for granted now, but something as basic as the idea to use on- and off-switches (which is what bits are) as representations of numbers, let alone strings of letters, is a ridiculous leap of thought. Then we built more complex software on top of that more similar ridiculous leaps of thought. None of those leaps came directly from the code itself.
Zaak 9y ago
In a similar vein, the real task of debugging is not to make the program stop doing the wrong thing. It is to create in your mind an understanding of why the program as written necessarily behaves in the way it does. Once you have that understanding, actually fixing the problem is straightforward.
ZenoArrow 9y ago
> "In my experience, this is a common characteristic of the 10x programmer. It is not about frameworks, it is not about patterns; both things help, but it is really about to be able to run the system in your head." I think this extends to users as well. Well before I knew how to program I'd approach new software as if I'd designed it myself, unconsciously putting myself in the mind of the designer. The applications I struggled to learn were those where I couldn't build a mental model of what it was doing and why.
mattgreenrocks 9y ago
> this is a common characteristic of the 10x programmer. It is not about frameworks, it is not about patterns IMO, the hope is that tooling can somehow obviate the need for 10x programmers (and their annoying salary requirements) by putting enough guard rails in place. But the reality is additional layers of abstraction all come at a cost (computational/cognitive), systems thinking is still required (the core trait of effective programmers), and, most importantly, great programs aren't made by distilling current best practices into tools. As much as the industry tries, it can't replicate hard-won experience.
psadri 9y ago
Doing things in your head is like accessing L1 cache and not hitting RAM or disk.
- contingencies 9y ago
  Doing things exclusively in your head works for some types of creativity, empathy or experiential simulation tasks, but is a restriction otherwise. To think, you have to write. If you're thinking without writing, you only think you're thinking. - Leslie Lamport

mwcampbell 9y ago

Current real-world systems are too complex to simulate accurately in your head. I've learned to assume that I don't really understand a system until I've collected sufficient trace output from the real thing.

jorgeleo 9y ago
That only means that the system needs better abstraction layers so you can think of it at different depths. Of course, you need to learn enough about the system to be able to do it, I am glad you wait for that.
- JustSomeNobody 9y ago
  And better doesn't mean more and probably means fewer.
taeric 9y ago
This implies you are trying to simulate fully. Just as most programmers don't have to simulate the rather complex circuitry in an adder, you probably don't have to simulate the complexities of most of your system. Or, when you do, you can take the simple parts for granted. Similar to plotting a trip to the grocery. You don't think of the effort your body is doing to stay balanced. Nor of reading labels Yet you probably have a decent idea how long the trip will take.
- boomlinde 9y ago
  Maybe "simulate" is the wrong word, then. Especially accurate simulation. Plotting to shop groceries is not a simulation. You create a model of the problem and roughly base your solution on that. The model is based on a very large number of assumptions and a great deal of ignorance of the entirety of the process it represents. You can relatively accurately predict that when you press "OK", the dialog will close. You can maybe assume and envision a future where calling "closeDialogBox(box)" will close the dialog box. Maybe the lines in it that which simply call "box->close()" and return "STATUS_OK" can be assumed to do what you think it will do. The underlying machine code, too. The CPU, sure. In the end the whole system is beyond your control and is subject to random input like cosmic rays flipping bits, power outages, leaking caps. Before that you have the operating system, the compiler, the overall codebase, perhaps more likely sources of mental model mismatches. I certainly wouldn't draw the line of "accurate simulation" at the source code base. IMO one of our strengths as humans is that we can easily create these simplified models based on rough probabilities founded on previous experience, "gut feelings" and weighing risks and go great lengths without accurate simulation.
  - taeric 9y ago
    I'm sympathetic to your point, but I suggest you have the wrong take here. It might have been better if people referred to modeling the system, but that ship sailed, as it were. That is, we are primarily discussing how people use that phrase in informal communication. And the you'd be surprised just how far many can take the simulations in their head.
    - boomlinde 9y ago
      It's not like "simulation" is commonly used to describe one's thoughts. So your idea is that we're just arguing about some sort of hypothetical colloquial sense of the word, even though it's obviously used here in the context of comparing humans to computers?
mattmanser 9y ago
Are they? I "run" systems in my head all the time. I'm familiar with the code base, from that I'll know roughly where the bug is. I can tell you which function a bug will probably be in and how it's probably happening, just from having the symptoms described to me. Hell, even when I'm not familiar I can guess what's happening based on past experience. It's some sort of spatial ability, like navigating a map (though I recently found out I'm terrible at visualizing and almost completely lack a 'mind's eye'). I also find I rarely get lost in computer games and very rapidly learn FPS maps. Maybe's it's one of those weird skills you don't even realise some of the population lack. Personally I've always thought using traces are a massive crutch that are too expensive in cost vs benefit ratio, I don't get the point. Far too many extra lines of code for too little gain.
- psyc 9y ago
  I work this way to a large extent. I have pretty good recall of the whole codebase, sufficient to step through in my head and spot actual bugs while AFK. I really dislike it when people make assertions about what others supposedly cannot do.
  - nsxwolf 9y ago
    I don't believe you.
  - 5ilv3r 9y ago
    I believe this is called "being mechanically minded". If you understand the physical rules and the components, you understand the inner workings. Good mechanics have this. Bad mechanics don't. Sadly being an auto mechanic pays little, but the skills are obvious in good programmers too.
- foobarchu 9y ago
  Yeah, this is exactly how my brain works, and has led to my specialty being finding the difficult bugs that have eluded others. I've got a loose leaf notebook that I use to help, but all that's really in it is rough drawing of circles with labels scraweled next to them, fashioned in a shape with maybe some lines between them. All it's for is helping me imagine the system better in my head to connect the dots. It's affected my design philosophy too, I always try to design software such that I could draw it as a series of discrete components with input/output arrows between them (and, of course, the assumption that could theoretically zoom in to a component to see whats inside of it)
vanderZwan 9y ago
That is still thinking within the boundaries of programming logic. The point that Ted Nelson makes is that you should never stop thinking beyond the immediacy of that, and always remember what the code is ultimately hoping to achieve in the end: > "Thinking if I hit that key what should happen if I hit that key..." The answer to what should happen is not rooted in thinking about the code. Programming is taking meaningful thoughts and turning them into thoughtless instructions that can be executed by a machine. And that is hard! We take it for granted now, but something as basic as the idea to use on- and off-switches (which is what bits are) as representations of numbers, let alone strings of letters, is a ridiculous leap of thought. Then we built more complex software on top of that more similar ridiculous leaps of thought. None of those leaps came directly from the code itself.

Zaak 9y ago

In a similar vein, the real task of debugging is not to make the program stop doing the wrong thing. It is to create in your mind an understanding of why the program as written necessarily behaves in the way it does. Once you have that understanding, actually fixing the problem is straightforward.

ZenoArrow 9y ago

> "In my experience, this is a common characteristic of the 10x programmer. It is not about frameworks, it is not about patterns; both things help, but it is really about to be able to run the system in your head." I think this extends to users as well. Well before I knew how to program I'd approach new software as if I'd designed it myself, unconsciously putting myself in the mind of the designer. The applications I struggled to learn were those where I couldn't build a mental model of what it was doing and why.

mattgreenrocks 9y ago

> this is a common characteristic of the 10x programmer. It is not about frameworks, it is not about patterns IMO, the hope is that tooling can somehow obviate the need for 10x programmers (and their annoying salary requirements) by putting enough guard rails in place. But the reality is additional layers of abstraction all come at a cost (computational/cognitive), systems thinking is still required (the core trait of effective programmers), and, most importantly, great programs aren't made by distilling current best practices into tools. As much as the industry tries, it can't replicate hard-won experience.

psadri 9y ago

Doing things in your head is like accessing L1 cache and not hitting RAM or disk.

contingencies 9y ago
Doing things exclusively in your head works for some types of creativity, empathy or experiential simulation tasks, but is a restriction otherwise. To think, you have to write. If you're thinking without writing, you only think you're thinking. - Leslie Lamport