"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.
I have seen many systems that were overly complicated because the developers couldn’t keep it all in their head. It led instead to poorly designed modularity along boundaries selected to be small enough that they could keep it in their heads, to the detriment of both efficiency and maintainability.
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.
Plus people with intellectual limitations are not immune to their own variant of over engineering. They will at times pile up useless layers and intermediate steps thinking they created something incredible or replicated badly something they saw on YouTube the week before.
"having as much working memory as possible as is useful. don't remember inconsequential details" isn't very actionable. someone could turn that into a blog post that only nerds would be interested in reading. I don't use that term pejoratively though.
I find it funny that type systems often confuse me even though theyre trying clarify the the components, and while in a few more seconds i can parse them, i simply cant scan them.
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.
Yeah, there's just no magic bullet: a single file with all the code is easy to ctrlf but context disappears. Multiple folders mimics hierarchy and dependency but can easily mismatch control structure or circularity of flow.
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.
"There are clever, hardworking, stupid, and lazy officers. Usually two characteristics are combined. Some are clever and hardworking; their place is the General Staff. The next ones are stupid and lazy; they make up 90 percent of every army and are suited to routine duties. Anyone who is both clever and lazy is qualified for the highest leadership duties, because he possesses the mental clarity and strength of nerve necessary for difficult decisions. One must beware of anyone who is both stupid and hardworking; he must not be entrusted with any responsibility because he will always only cause damage." -- Kurt von Hammerstein
"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?"
My rule is simple, grug style: "smart good, clever bad".
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.
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?"
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:
My point is that genius is exactly not that. Code like in these examples is, to my mind, a tour de force, only interesting as a curiosity, or an example of a terrible but clever hack.
(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.
I have a high IQ and some combination of low key autism and ADHD which hinder my memory to some extent. I've gone my whole career finding the status quo way of doing things overengineered. I keep my stuff simple and I always see the team around me drowning in bugs and redesigns from their overcomplicated and unnecessary layers of abstraction and indirection that don't match how the business needs have evolved. I don't write a line of code until it's needed, and I find maintenance and extension of my code to be easy.
Well, I don't think that's memory dependent. I have an exceptional working and long term memory (and now I am not ashamed to admit it) and people around me cook up some really stupid solutions. Premature abstraction, overreach, focusing on the wrong things, etc.
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.
I'm in my mid 40s and I would agree with the article, my most important development started around my late 30s. But it didn't take the form of changing my philosophy about complexity or coming closer to resembling a more conforming or conventional developer.
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.
That's the way it was decades ago. In the mid-1980s, a headhunter cold-called me at work and asked what I did. I answered, "I'm a computer programmer." Sounding severely disappointed, he said, "Oh ... Is there anyone in your office who designs programs?" I responded, "Yes, we all do." I was aware of this mindset from books I'd read in the late 1970s when I first got interested in computers.
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, ..."
Excellent.
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.
I have seen many systems that were overly complicated because the developers couldn’t keep it all in their head. It led instead to poorly designed modularity along boundaries selected to be small enough that they could keep it in their heads, to the detriment of both efficiency and maintainability.
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.
Plus people with intellectual limitations are not immune to their own variant of over engineering. They will at times pile up useless layers and intermediate steps thinking they created something incredible or replicated badly something they saw on YouTube the week before.
"having as much working memory as possible as is useful. don't remember inconsequential details" isn't very actionable. someone could turn that into a blog post that only nerds would be interested in reading. I don't use that term pejoratively though.
100%
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.
I find it funny that type systems often confuse me even though theyre trying clarify the the components, and while in a few more seconds i can parse them, i simply cant scan them.
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.
Yeah, there's just no magic bullet: a single file with all the code is easy to ctrlf but context disappears. Multiple folders mimics hierarchy and dependency but can easily mismatch control structure or circularity of flow.
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.
"There are clever, hardworking, stupid, and lazy officers. Usually two characteristics are combined. Some are clever and hardworking; their place is the General Staff. The next ones are stupid and lazy; they make up 90 percent of every army and are suited to routine duties. Anyone who is both clever and lazy is qualified for the highest leadership duties, because he possesses the mental clarity and strength of nerve necessary for difficult decisions. One must beware of anyone who is both stupid and hardworking; he must not be entrusted with any responsibility because he will always only cause damage." -- Kurt von Hammerstein
Martin Fowler: "Now I'm a pretty lazy person and am prepared to work quite hard in order to avoid work."
Reminded me of this gem from Brian Kernighan:
"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?"
My rule is simple, grug style: "smart good, clever bad".
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.
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?"
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.
My point is that genius is exactly not that. Code like in these examples is, to my mind, a tour de force, only interesting as a curiosity, or an example of a terrible but clever hack.
(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.
But to some people apl/j are horrible, they will prefer their spaghetti of routines massaging random dicts where everything is "obvious"
The answer is Kernighan's Lever: "because you'll learn".
https://www.linusakesson.net/programming/kernighans-lever/in...
I have a high IQ and some combination of low key autism and ADHD which hinder my memory to some extent. I've gone my whole career finding the status quo way of doing things overengineered. I keep my stuff simple and I always see the team around me drowning in bugs and redesigns from their overcomplicated and unnecessary layers of abstraction and indirection that don't match how the business needs have evolved. I don't write a line of code until it's needed, and I find maintenance and extension of my code to be easy.
Well, I don't think that's memory dependent. I have an exceptional working and long term memory (and now I am not ashamed to admit it) and people around me cook up some really stupid solutions. Premature abstraction, overreach, focusing on the wrong things, etc.
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.
I agree, I think my traits nudged me in this direction but it could also come from wisdom and good judgment alone.
I assume you are not yet 40.
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'm in my mid 40s and I would agree with the article, my most important development started around my late 30s. But it didn't take the form of changing my philosophy about complexity or coming closer to resembling a more conforming or conventional developer.
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.
Yes. Programming isn't just writing code.
It would be better if these fundamentals were spread out alongside code writing.
Sometimes I think it would be good to have separate terms.
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.
That's the way it was decades ago. In the mid-1980s, a headhunter cold-called me at work and asked what I did. I answered, "I'm a computer programmer." Sounding severely disappointed, he said, "Oh ... Is there anyone in your office who designs programs?" I responded, "Yes, we all do." I was aware of this mindset from books I'd read in the late 1970s when I first got interested in computers.
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, ..."
[dead]