+972 52-548-6969
What lies are you going to tell yourself now, dude?
This is another post on the “learning to code” series. Mostly because I think that this is an important distinction. The way I learn something new, I usually try to construct a mental model of how it works in the simplest terms, then I learn to use it, then I dig into the actual details of how it works.
The key here is that the results of the first part is usually wrong. It is a lie, but it is a good lie, in the sense that it give me the ability to gloss over details in order to understand how things are really working. It is only when I understand how something is used and under what scenarios that I can really appreciate the actual details.
A good example of that are things like:
- Memory
- Garbage Collection
- Network
If you ever wrote C, you are familiar with the way we can just allocate memory and use it. The entire system is based on the idea that it looks to you like you have full access to the entire system, and that one piece of memory is pretty much the same as anything else. It is a great mental model to go with, even if it is completely wrong. Virtual memory, OS paging, CPU cache lines are all things that really mess up with that model when you get down to really understanding how this works. So the model that you have in your head (and probably still do, unless you need to think about high perf code).
The way most people think GC works is probably based on John McCarthy's "Recursive functions of symbolic expressions and their computation by machine" and/or George E. Collins' "A method for overlapping and erasure of lists", both from 1960. While those set the basis for GC in general, there is a lot more going on, and modern GC systems work quite differently. But it is enough to get by.
And networking have this whole 7 level OSI model:
And very rarely do people need to think beyond the next layer down. We might think that we viewing a web page, and then break it down to the list of requests made, but we usually stop at that level. It is easy to just consider what happens as magical, but you sometimes need to figure out what is going on in the next layer down, how the packets are actually broken up for transports.
An example of that is when you run into issues with Nagle’s algorithm.
But trying to learn REST, for example, by focusing on the format of IPv4 vs. IPv6 packets is a non starter. We need to know just enough to understand what is going on. We are usually good with just thinking about the movement of data as just happening. Of course, later on we would need to revisit that to have better understanding of the stack. But that is usually not relevant. So we tell ourselves a little lie and move on.
As an example of when those lies comes to bite us in the ass is the Fallacies Of Distributed Computing. But for the most part, I am really in favor of dedicating just enough time to figure out a good lie and move of to the real task.
Of course, it has to be a good lie. A really good one was the Ptolemaic model of the universe:
It might be wrong, but it was close enough for the things that you needed doing.
Comments
Nitpick: the Ptolemaic model is not wrong. It might be unwieldy, awkward, unintuitive, but wrong? Nope.
Martinho, To start with, planets are moving in ellipsis, not circles in circles. Then there is the geocentric issue, etc.
I understand where you want to go with this, but it's a little confusing article.
It goes a little into The direction of The "leaky abstractions" post of Joel Spolsky.
I don't know,if it would probably been better to discuss one leaky abstraction really thorougly and show where it hit you.
@Sam - I think this was intended as a much higher-level post than what you propose. He's just explaining his usual method for learning codebases, which is an extension of his previous post. And finally, I guess he's advocating that the lie is where the key is: Attempting to figure out the steps to get from A to B may not be accurate, but it IS a useful exercise in understanding others' codebases.
Sorry, didn't finish my thought. The point is that having a specific example like that would actually cloud the post up, I think, and make it seem like it's not applicable to many places. I could be wrong on that, and can see both points.
Great post!!! I agree.
This post reminds me when we in primary school and were taught that 4 minus 10 is impossible. However during our first year in high school we were surprised to be told that it was in fact possible . we just extend the timeline to get the negatives. In your context it was a "lie" to get us through what we needed to know at the time and what our level of understanding could grasp.
@Martinho,
Also it was way wrong on the distances between the planets, a gross approximation at best.
Spolsky points out that leaky abstractions are fine if you know where the leaks are, like any analogy that cannot be identical to what it is representing. So this agrees with that. I went to school in England and my chemistry teacher would often state something e.g. covalent bonds blah blah and then say "come back next year and you will see that it is not quite so" or "in university you will learn something different". We understood that things were being simplified for our level of study.
BTW the recaptchas are ALOT easier now, maybe google has just given up.
@peter - for the reasons why recaptcha is suddenly a lot more straightforward for us mere humans, see here: http://arstechnica.com/information-technology/2013/10/recaptchas-are-finally-readable-by-normal-humans/.
tl;dr - from memory when the article on my phone I recall it's to do with the captcha algorithm now taking into account your pattern of interaction with the text entry field..
@ayende: Good article. I liked the explanation of how loading a web page results in a lot of web requests but rarely do you then need to go down an extra level. Similar to how we use tools like Fiddler to debug web traffic rather than using Wireshark, but the more detailed tool does have its uses on the odd occasion for HTTP. Example: debugging HTTP-like traffic as it passes through a router; Fiddler, and its higher level of abstraction, just doesn't apply in that case.
Comment preview