= 27d567bc2d48d9f40e9ccc20ea370b15)
Nanashi comments on The most important meta-skill - Less Wrong
You are viewing a comment permalink. View the original post to see all comments and the full post content.
= 783df68a0f980790206b9ea87794c5b6)
Loading…= b715d02e85f7b3b4ae65ca3d3e450868)
Subscribe to RSS Feed
Powered by Reddit
= f037147d6e6c911a85753b9abdedda8d)
You are viewing a comment permalink. View the original post to see all comments and the full post content.
Comments (70)
I have a feeling that's a bit of a relic.
Long time ago programming environments were primitive and Real Men wrote their own sorts and hash tables (there is a canonical story from even more Ancient Times). But times have changed. I can't imagine a serious situation (as opposed to e.g. a programming contest) where I would have to write my own sort routine from scratch -- similarly to how I can't imagine needing to construct a washing machine out of a tub, an electric motor, pulleys, and belts.
I certainly still care about performance properties of various sorts, but I don't care about their internal details as long as the performance properties hold. I suspect that the interview questions of the "implement a bubble sort on this piece of paper" variety if anything aim more at "have you been paying attention during your CS classes" and less at "do you have a deep understanding of what your program is doing".
The capacity of human minds is limited and I'll accept climbing up higher in abstraction levels at the price of forgetting how the lower-level gears turn.
Yes, this this this this this this this. "The capacity of human minds is limited and I'll accept climbing up higher in abstraction levels at the price of forgetting how the lower-level gears turn." If I could upvote this multiple times, I would.
This is the crux of this entire approach. Learn the higher level, applied abstractions. And learn the very basic fundamentals. Forget learning how the lower-level gears turn: just learn the fundamental laws of physics. If you ever need to figure out a lower-level gear, you can just derive it from your knowledge of the fundamentals, combined with your big-picture knowledge of how that gear fits into the overall system.
That only works if there are few levels of abstraction; I doubt that you can derive how do programs work at the machine codes level based of your knowledge of physics and high-level programming. Sometimes, gears are so small that you can't even see them on your top level big picture, and sometimes just climbing up one level of abstraction takes enormous effort if you don't know in advance how to do it.
I think that you should understand, at least once, how the system works on each level and refresh/deepen that knowledge when you need it.
The definition of "fundamentals" differs though, depending on how abstract you get. The more layers of abstraction, the more abstract the fundamentals. If my goal is high-level programming, I don't need to know how to write code on bare metal.
That's why I advocate breaking things down until you reach the level of triviality for you personally. Most people will find, "writing a for-loop" to be trivial, without having to go farther down the rabbit hole. At a certain point, breaking things down too far actually makes things less trivial.