Education of a Programmer
medium.com
medium.com
1) When a distinguished but elderly scientist states that something is possible, he is almost certainly right. When he states that something is impossible, he is very probably wrong.
2) The only way of discovering the limits of the possible is to venture a little way past them into the impossible.
3) Any sufficiently advanced technology is indistinguishable from magic.
Big fan of The Zen of Python.
Life is short. I spend it miserly on those things I have to or want to care about and wifi and car engines aren't those things (now).
superficial understanding you'll forget in a couple weeks? sure. but nothing more, unless you're some sort of savant.
When I was a kid, I wanted to know how all the black boxes worked -- one of my greatest days was when my father explained the internal combustion engine well enough that cars no longer seemed like magic.
Later I noticed that many people -- especially when talking about electronics -- would ask "How does it work?", when they actually meant "How do you use it?" I thought this was just a quirk of the Australian dialect, but as I gained more experience with people, I realised it was really an aspect of human thought.
To most people, knowing "how it works" is no more than being familiar enough with the magic spells that you can use them with confidence.
Sure, I'd love to live forever so I could take the time to fully understand everything, but unfortunately I have to optimize my time, and learning the ins and outs of an engine just isn't that important in my day to day life.
While I tried to convey my own excitements and my dislikes, I was careful in my comment not to say that everyone most like the same things.
What I will say though is that there is a difference between known how a thing works and how to use it. Very often you only need the latter. But thinking that it equals the former is just an error.
But then you find a way to try and turn even that into a flaw of some sort, and continue with your narrative that it's somehow a problem that people don't take the time to fully understand everything they use.
What I meant by "well enough" is that the explanation that he gave -- or even the one that I now have in my head -- is nowhere near the truth. Engines are complicated, and I will never truly understand them. But at least they can be demystified.
It's necessary to see beyond chosen words. I might ask how a computer program works and it could mean "how do you use it," or "how does it function." The other party has to infer my meaning.
I don't think you can take a phrase that is common in your life and apply it to everyone else. Words / phrase have different meanings in different contexts for different people.
I like the (literal) treatment of this topic in Harry Potter and the Method of Rationality.
Never heard of it before. For anyone else interested; http://www.hpmor.com/
I trust that the interface, be it the C++ standard, or boost::whatever, is well enough tested that I don't need to know "how it works".
It would be nice to know how everything works but there is only finite time in the working day.
You can understand the source of your libraries just fine, but still be grateful that they are usually hidden behind interfaces that let the compiler help you spot silly mistakes.
(OK, less so in C++, more so in eg Haskell.)
PS. Australian here. Yes, people do speak like that, but I agree with your conclusion.
I saw "how does it work" used as "how to use it" on American TV https://www.youtube.com/watch?v=MEFXhopARyw
And knowing that there are hard limits on understanding is important. It is almost reassuring: yes, you don't (and can't) understand x right now, but you will be able to when you enhance your mental models! Learning is powerful! Contrast that to "you can understand anything just as you are" which is a dangerous attitude, IMO, because it teaches that students don't need to change. But what is learning, if not that?
Admittedly, some technical folks are apt to take words literally and don't response well to the usage of the word "magic/magical" even when its meant in a figurative sense.
and you may claim there is a reason behind everything, but good luck finding the reason. no one will ever find the reason for every single bug, issue, problem, etc. they come across. so just because there might exist a reason, the fact that it can't be practically found makes that stance a bit mystical itself.
We will see conspicuously interesting ads, thanks to ever more accurate, automated analysis of our communications and browsing patterns. Sometimes, such analysis will be performed to stop criminals (mainly terrorists, paedophiles, and intellectual thieves).
How about getting our shit together and starting to fight this nightmare?
Upgrade cost of network complexity: The Internet has smart edges ... and a simple core. Adding an new Internet service is just a matter of distributing an application ... Compare this to voice, where one has to upgrade the entire core. - RFC3439 (2002)
In a more general sense, taking the bull by the horns and dealing with the underlying, sometimes unwanted, realities of the system rather than burying one’s head in the sand and pretending the problems do not exist (only to be forced to deal with them later and apply band-aid solutions that are not robust).
As he goes on to say Rather than trying to hide it, you accept it and design for it.
The similarities between that claim and this one are striking.
The section on "performance" is so spot on. It is remarkable how rare it is that programmers think in these terms. There is no absolute truth to any particular performance optimization; optimizations only exist within the context of a complex topology of resource constraints that vary with time and application. It seems like a lot of work but this type of analysis becomes routine and automatic with experience. You really do have to evaluate your optimizations from first principles each time.
Props also for "Einsteinian" (I use the terms relativistic/Newtonian). I frequently say "all software systems are distributed systems". Programmers often resist the idea but it actually makes the design of systems much easier once you fully embrace the implications.
This is something that becomes evident when you stop using OOP languages, and then you cannot unsee it anymore.
Go read Learn Yourself a Haskell.
As usual, added to https://github.com/globalcitizen/taoup
I particularly liked the light speed analysis technique, the bold statement that a clean start is a fundamental technique in managing complexity, and the expression of effective technical management as the design of transparent, self-coordinating feedback loops.
edit-001: feynman's infamous algorithm contains more detail: http://wiki.c2.com/?FeynmanAlgorithm
"What one programmer can do in one month, two programmers can do in two months." - Fred Brooks
Had the author really not heard this idea from Lamport already?
In that model, Very Clever People build a consistent distributed database which merely mortal application developers can treat as if it were a single instance. I think Crowley wants application developers to just accept nature of distributed systems.