Yes! I often find that I am much worse at holding tons of information in my brain than my peers. I seem to be better at finding abstractions, and I think that's in large part due to necessity imposed by that comparative limitation.
I feel like their original quote doesn't support the rest of the article:
> it’s time to turn back to old documents to figure out the logic behind some of the engineering decisions. Dodd says it’s easy to find the engineering decisions, but harder to find the reasoning.
It's not that they don't understand what the code is doing. It's that they don't understand why the code is doing what it's doing. Abstractions do not help with why. Documentation does. This is why I try to include as much of the why in the form of comments and long commit messages. Including alternatives considered and why I chose not to use them.
I like the thesis about abstraction, but the example of the Voyager code base is a little bit contrived.
1) technological limitations, namely in processing and memory probably play a large role in some of the decisions made.
2) software engineering best practices such as DRY, KISS as they relate to abstraction have evolved considerably in the 30+ years (perhaps to some extent because the limitations of observation 1 have been lifted).
Obviously the Voyager code base still has the same technological constraints today since hardware can't be updated on a probe currently traveling on the fringes of our galaxy.
It would have been nice to have a more modern example to elucidate the point regarding empathy for peers.
In fact, the same could apply to the thought process in creating a new programming language. Take for example PHP, it was originally intended as a "Personal Home Page," taking PERL and CGI as its model. Method signatures are inconsistent, and not a lot of thought was made early on to certain points that might have been made, had the creator of this language not intended it for his own personal use. In my own experience, PHP offers less empathy for peers because many of the decisions made are from a single-minded use-case. Contrast that with other higher level programming languages where the introduction or removal of new operators is a subject that is heavily deliberated upon from the perspective of or empathy for peers.
> Imagine an alien race with the cognitive faculties to reason about individual electron trajectories. Would those aliens fall back to the same abstraction?
How am I to answer that if the assumption there are individual electrons is wrong?
Additionally, how are we to answer that if the assumption that aliens could or should possess such faculties is wrong? There is no finite amount of processing power that makes individual electron trajectories feasible or rational to reason about in the general-case.
Abstraction and conceptualization are at the core of what makes us human. Some people think technology is cold and hard and inanimate, but when I look at it I see the exact opposite.
A great way to be motivated to write abstract code is to first understand how cool it is!
The phenomenon described here is spot on but the OP is being generous when suggesting that it is merely a "noblesse oblige" for the "smart" developer to write clearer code. In my experience these developers very quickly lose creative control of their own spaghetti -- primarily because of the combinatorial complexity that always stacks up when one doesn't value simplicity.
Its as Rich Hickey pointed out in his now-famous Simple Made Easy talk, "A juggler can juggle 3 balls. A really good juggler can juggle 9. No juggler can juggle 90 or 900." I know the "smart" developers the OP describes very well and they aren't just doing a disservice to his fellow programmer but to their own creative possibilities with their code.
I've been a Hal Abelson and Sussman devotee for many years but I've been on the fence about the whole, "executed incidentally by computers," idea this year after Mike Acton's talk and digging into the data-oriented design philosophy.
As a long-time Lisp user it's quite comfortable to think of the world in abstractions and having a programmable programming language allows me to bring the domain to my code in a way that no other language can.
However one always hits the non-theoretical limits of the target platform. At that point it becomes a challenge to remove all of the abstractions to gain performance back or find difficult bugs in generated code.
It always comes back to data.
The challenge for engineers trying to decipher the intent behind code is that the intent went undocumented. It's too challenging and costly to encode those things in the source of a program. For a system like Voyager one must make conscious concessions about the data and use every trick they have to perform the transformations they need with the chips they have on that device. I don't think a sufficiently high-level language is going to help much -- even one that can synthesize a program capable of running on Voyager's hardware.
It is crucial, I think, to be able to describe and document your data. You can re-create the program from the data.
Synthesis might be one avenue if machine learning is capable of producing models that can generate their own ideas and theorems. Until then the problem space is still too large, I think, to move it out of NP. Maybe if we get the graph isomorphism into P.
But if we get that far I don't think we'll need programmers anymore.
I don't have any comments about the content, but I really liked that there was a TL;DR at the top of the article to set the stage regarding what I was about to read. I wish more articles would do that!
I don't think Von Neumann failed to make an abstraction, I think using the time to impact is about exploiting the structure or symmetry of the problem, and does not provide a good example of an abstraction being made.
Abstraction not only has a play on science but also on the social part of our lives.
Take money for instance. When you see a great amount of cash you're immediately amazed, or when you see someone purposely burning money you get confused.
In physical reality it's all just paper. You see such paper as value (and not as valuable) without even thinking about it (we don't "process" the abstraction).
17 comments
[ 4.7 ms ] story [ 53.2 ms ] thread> it’s time to turn back to old documents to figure out the logic behind some of the engineering decisions. Dodd says it’s easy to find the engineering decisions, but harder to find the reasoning.
It's not that they don't understand what the code is doing. It's that they don't understand why the code is doing what it's doing. Abstractions do not help with why. Documentation does. This is why I try to include as much of the why in the form of comments and long commit messages. Including alternatives considered and why I chose not to use them.
1) technological limitations, namely in processing and memory probably play a large role in some of the decisions made.
2) software engineering best practices such as DRY, KISS as they relate to abstraction have evolved considerably in the 30+ years (perhaps to some extent because the limitations of observation 1 have been lifted).
Obviously the Voyager code base still has the same technological constraints today since hardware can't be updated on a probe currently traveling on the fringes of our galaxy.
It would have been nice to have a more modern example to elucidate the point regarding empathy for peers.
In fact, the same could apply to the thought process in creating a new programming language. Take for example PHP, it was originally intended as a "Personal Home Page," taking PERL and CGI as its model. Method signatures are inconsistent, and not a lot of thought was made early on to certain points that might have been made, had the creator of this language not intended it for his own personal use. In my own experience, PHP offers less empathy for peers because many of the decisions made are from a single-minded use-case. Contrast that with other higher level programming languages where the introduction or removal of new operators is a subject that is heavily deliberated upon from the perspective of or empathy for peers.
citation: http://threevirtues.com/
How am I to answer that if the assumption there are individual electrons is wrong?
A great way to be motivated to write abstract code is to first understand how cool it is!
Its as Rich Hickey pointed out in his now-famous Simple Made Easy talk, "A juggler can juggle 3 balls. A really good juggler can juggle 9. No juggler can juggle 90 or 900." I know the "smart" developers the OP describes very well and they aren't just doing a disservice to his fellow programmer but to their own creative possibilities with their code.
As a long-time Lisp user it's quite comfortable to think of the world in abstractions and having a programmable programming language allows me to bring the domain to my code in a way that no other language can.
However one always hits the non-theoretical limits of the target platform. At that point it becomes a challenge to remove all of the abstractions to gain performance back or find difficult bugs in generated code.
It always comes back to data.
The challenge for engineers trying to decipher the intent behind code is that the intent went undocumented. It's too challenging and costly to encode those things in the source of a program. For a system like Voyager one must make conscious concessions about the data and use every trick they have to perform the transformations they need with the chips they have on that device. I don't think a sufficiently high-level language is going to help much -- even one that can synthesize a program capable of running on Voyager's hardware.
It is crucial, I think, to be able to describe and document your data. You can re-create the program from the data.
Synthesis might be one avenue if machine learning is capable of producing models that can generate their own ideas and theorems. Until then the problem space is still too large, I think, to move it out of NP. Maybe if we get the graph isomorphism into P.
But if we get that far I don't think we'll need programmers anymore.
http://www.ppig.org/papers/20th-blackwell.pdf
Take money for instance. When you see a great amount of cash you're immediately amazed, or when you see someone purposely burning money you get confused.
In physical reality it's all just paper. You see such paper as value (and not as valuable) without even thinking about it (we don't "process" the abstraction).