Why is this hard?
programmersstone.blog
programmersstone.blog
This part especially:
"Some developers can fit substantially more in their memory. I have come to believe that hinders them at least as much as it helps them. When you are at your limits, you are forced to simplify the situation in order to resume forward progress. The more regularly you are forced to do that, the better the chance that you are keeping the situation under control."
It reminds me of how Bill Gates said he'd rather hire lazy developers, because "a lazy person will find an easy way to do it." Maybe even better would be to hire lazy developers with poor working memory.
"Everyone knows that debugging is twice as hard as writing a program in the first place. So if you're as clever as you can be when you write it, how will you ever debug it?"
https://www.linusakesson.net/programming/kernighans-lever/in...
Terminally clever is when you look at code that does something impressive and say: "Oh snap, I still can't exactly get it. I've read five explanations, and still cannot understand why they are doing this here. Screwed magic. How do people even come up with such ideas?"
Genius is when you look at code that does something impressive and say: "Holy guacamole, it's so simple! Now that I see it, it looks almost obvious. Pure magic. How do people even come up with such ideas?"
Despite the superficial similarity, clever and smart can be told apart. Clever should be seen as late stage optimization, smart, as foundation.
IMHO "genius" is code that appears completely unintelligible at first glance, but then you examine it carefully and then feel immensely enlightened once you understand.
These are the two examples of such code that immediately come to mind:
https://news.ycombinator.com/item?id=22353532
https://news.ycombinator.com/item?id=28491562
The original UNIX source code may come in as a distant third, a very distant third; code that is truly "genius" is indeed extremely rare.
(Like you, I of course immediately thought about the famous Artur Whitney's page of impenetrable C.)
The genius of J (and APL) is exactly in the simplicity of the language, where a single character denotes a whole well-defined operation on arrays which might take a page of Fortran code, and these operations are orthogonal, and useful for practical purposes.
These matters are always problems of organization, and of prioritizing what the job is, what are the inputs/outputs, how do you efficiently parameterize them into messages and data packets, where do they go and how will you send it, etc.
https://neurolaunch.com/cognitive-development-in-middle-adul...
Some "facts" about humans, programming and the rest is likely just what happens as the brain ages and the nondeterministics and arbitrary preferences.
I have not begun any decline but I have more or less retired early because the profession and I have drifted too far apart and I neither can nor want to fit in with what it has become.
Being able to see across it at scale is what exposes elegant reductions to something simpler, which enhances maintainability. It is how you end up with the commits that delete a thousand lines of code.
This is how you wind up having tons of pointless parts and layers, because no one could understand the system from end to end.
Blind men plus elephant, vs seeing men plus elephant.
So even though i can write systdms complicated enought to require good types, because naming fails, i cannot because the use of all the arbitrary symbolics is a speed bump.
What might help is a LLM that could seamlessly create various overlay files which would be editable allowing for differing usecases eitger project determinative or coder preferences.
IDEs try to do this but the success of vscode suggests theres space for multiview editors.
It would be better if these fundamentals were spread out alongside code writing.
Programming is just writing code. It might or might not be complicated say you fine tune some assembly algorithm.
Developing would be next step up. As you need bigger view.
Software engineering is when you start to consider what would be good engineering and making decisions before just writing code.
Software architecturing is interdisciplinary with engineering and happens is larger systems.
I really think we have done lot of disservice, by grouping all of the things also under coding or programming.
In the 1990s, I worked as a contractor at a very large engineering corporation and I was surprised to discover they still had developers who only designed programs down to the pseudocode level and then handed them off to "programmers" for coding. I thought this was stupid as all get out as there was no feedback mechanism in place, so the "designers" never learned of and from their mistakes. (And a feedback mechanism wouldn't be enough in my opinion, as the designers really needed to be mired in the mud of producing a working system.) This was especially serious as some of the programs ran on embedded real-time computers and the designers had no hands-on experience with the real-time OS and would not gain that experience simply through designing.
Experienced programmers do bits at all 4 of the levels without consciously thinking, "I'm doing engineering here, developing there, ..."