3 ms·

Charles Simonyi said: "It’s probably just that aging changes your mode of thinking. Right now, I have to really concentrate and I might even get a headache jus

by dkarl 4y ago

Charles Simonyi said: "It’s probably just that aging changes your mode of thinking. Right now, I have to really concentrate and I might even get a headache just trying to imagine something clearly and distinctly with twenty or thirty components. When I was young, I could imagine a castle with twenty rooms with each room having ten different objects in it. I would have no problem. I can’t do that anymore. Now I think more in terms of earlier experiences. I see a network of inchoate clouds, instead of the picture-postcard clearness. But I do write better programs."[0] I can believe the part about better programs. Can you imagine working with somebody who can clearly visualize software with 200 sub-components in it? I once worked with software written by someone who had similar powers. He was a hardware designer. His software had very little organization; he wrote imperatively and remembered where everything was. Six months after he handed a program off to me, I spoke with him and told him I was currently trying to figure out where a particular component was initialized, and he told me exactly where, in what part of what file. IIRC, some hardware registers were being initialized in a procedure that was allocating working space for a numerical part of the program, because that's here he happened to open the log file for the first time, and he wanted the logging from the hardware registers to be the first thing in the log file, before he logged the fact that the memory had been allocated successfully. He remembered this with no hesitation, more than six months after he last touched the code, possibly two years after he made the decision to initialize the hardware in that spot. Someone with less mental horsepower, like me, has to organize their code into modules with clear names and responsibilities. [0] https://programmersatwork.wordpress.com/programmers-at-work-charles-simonyi/ https://programmersatwork.wordpress.com/programmers-at-work-...

bqmjjx0kac 4y ago
Thanks in part to ADHD, I'm sure, I have severe tunnel vision while reading and writing code. I need to constantly diagram, take notes, and walk through call stacks (and re-walk) just to maintain my mental model. I am insanely jealous of people who can keep everything in their head. Maybe there's a silver lining in that my methods are more resistant to brain-busting situations, depression, cognitive decline, etc., but I'm not sure that I'm convinced.
- kortex 4y ago
  The flip side of that is people who can keep everything in their head often write code which reflects exactly that, and that code is very hard for others to scrutinize. I try to lean into just such a silver lining. I like to write my code for worst-case future-me: what would it take for my sleep-deprived, Monday morning, uncaffeinated brain to make sense of? It definitely helps, especially even considering that approach, I often find I overestimate my future ability to understand past code.
riskable 4y ago
> some hardware registers were being initialized in a procedure that was allocating working space for a numerical part of the program, because that's here he happened to open the log file for the first time, and he wanted the logging from the hardware registers to be the first thing in the log file, before he logged the fact that the memory had been allocated successfully. To be fair (haha) I went from writing super organized code with loads of concise, well-documented files to writing code just as you describe when I started designing hardware and writing more complicated embedded firmwares. For whatever reason, hardware initialization boilerplate doesn't like to be spread out or organized. As soon as you try your code ends up breaking outright or becoming a vastly more complicated, gigantic mess. It's because the hardware is soooo specific and we as software developers want to make interfaces that are as generic, high-level, and re-usable as possible. Example: You can't just write a function that takes two pin numbers and initializes I2C on them so you can talk with some module. You usually have to know--ahead of time--which two pins you're going to be passing to that function (so the types match; because each pin has its own special type haha) so the function can initialize the correct I2C bus on the chip (in the right way)... Which immediately makes such a function non-generic and kinda pointless since you'll never be able to re-use it in anything else for any other purpose. You quickly get into the habit of saying to yourself, "Why am I making this a separate function again?" Also, the order of operations matters so much more in embedded stuff than it does in regular software. I could totally see the situation where you want to initialize logging immediately after initializing some hardware because you want the logs to reflect values that you only happen to have available during initialization... You don't need them after initialization so why waste precious memory keeping variables around just so you can log them later? Just setup the logger in the same code, write your variables, and be done with it! Makes sense, right? Hah! Only in the world of embedded firmware!

by dkarl 4y ago

bqmjjx0kac 4y ago

Thanks in part to ADHD, I'm sure, I have severe tunnel vision while reading and writing code. I need to constantly diagram, take notes, and walk through call stacks (and re-walk) just to maintain my mental model. I am insanely jealous of people who can keep everything in their head. Maybe there's a silver lining in that my methods are more resistant to brain-busting situations, depression, cognitive decline, etc., but I'm not sure that I'm convinced.

kortex 4y ago
The flip side of that is people who can keep everything in their head often write code which reflects exactly that, and that code is very hard for others to scrutinize. I try to lean into just such a silver lining. I like to write my code for worst-case future-me: what would it take for my sleep-deprived, Monday morning, uncaffeinated brain to make sense of? It definitely helps, especially even considering that approach, I often find I overestimate my future ability to understand past code.

riskable 4y ago

> some hardware registers were being initialized in a procedure that was allocating working space for a numerical part of the program, because that's here he happened to open the log file for the first time, and he wanted the logging from the hardware registers to be the first thing in the log file, before he logged the fact that the memory had been allocated successfully. To be fair (haha) I went from writing super organized code with loads of concise, well-documented files to writing code just as you describe when I started designing hardware and writing more complicated embedded firmwares. For whatever reason, hardware initialization boilerplate doesn't like to be spread out or organized. As soon as you try your code ends up breaking outright or becoming a vastly more complicated, gigantic mess. It's because the hardware is soooo specific and we as software developers want to make interfaces that are as generic, high-level, and re-usable as possible. Example: You can't just write a function that takes two pin numbers and initializes I2C on them so you can talk with some module. You usually have to know--ahead of time--which two pins you're going to be passing to that function (so the types match; because each pin has its own special type haha) so the function can initialize the correct I2C bus on the chip (in the right way)... Which immediately makes such a function non-generic and kinda pointless since you'll never be able to re-use it in anything else for any other purpose. You quickly get into the habit of saying to yourself, "Why am I making this a separate function again?" Also, the order of operations matters so much more in embedded stuff than it does in regular software. I could totally see the situation where you want to initialize logging immediately after initializing some hardware because you want the logs to reflect values that you only happen to have available during initialization... You don't need them after initialization so why waste precious memory keeping variables around just so you can log them later? Just setup the logger in the same code, write your variables, and be done with it! Makes sense, right? Hah! Only in the world of embedded firmware!