Coding: The little details all add to our understanding
I’ve been watching an interesting presentation by Scott Hanselmann titled 'Information Overload and Managing the Flow' from OreDev where he covers various strategies to allow us to be more productive in the face of the huge amounts of information constantly threatening to overwhelm us.
One interesting suggestion he has around 37 minutes in is that when learning a new language it might be a good idea to contact someone who’s an expert in that language and get some framing knowledge on the type of stuff that’s worth learning and what we might not bother with.
While this seems like a pretty good idea I think it’s also useful to note that a lot of the knowledge that people have in a subject area comes from the little things that may seem insignificant as part of the big picture.
Donald Knuth points out something similar in his interview in Coders at Work:
Seibel:
It seems a lot of the people I’ve talked to had direct access to a machine when they were starting out. Yet Dijkstra has a paper I’m sure you’re familiar with, where he basically says we shouldn’t let computer science students touch a machine for the first few years of their training; they should spend all their time manipulating symbols.
Knuth:
But that’s not the way he learned either. He said a lot of really great things and inspirational things, but he’s not always right. Neither am I, but my take on it is this: Take a scientist in any field. The scientist gets older and says, “Oh, yes, some of the things that I’ve been doing have a really great payoff and other things, I’m not using anymore. I’m not going to have my students waste time on the stuff that doesn’t make giant steps. I’m not going to talk about low-level stuff at all. These theoretical concepts are really so powerful—that’s the whole story. Forget about how I got to this point.” I think that’s a fundamental error made by scientists in every field. They don’t realize that when you’re learning something you’ve got to see something at all levels. You’ve got to see the floor before you build the ceiling. That all goes into the brain and gets shoved down to the point where the older people forget that they needed it.
Over the last year or so I’ve played around with F#, Scala and Clojure and I’ve found with all three of them that I only start to understand how things work when I take an example from the book and then play around with it in the REPL and work out what combinations of the syntax lead to a compilation error and which don’t.
It’s a pretty inefficient way of learning if you look at it from a high level but I find it’s a necessary step for me. When I don’t fight with the compiler like this then I don’t really understand what I’ve read in a book or blog post well enough to write some code myself or explain it to someone else.
I don’t find that anything is truly a waste of time - even if it’s something indirectly related such as reading a functional programming paper or following some examples of how lazy evaluation works in another language it all contributes to our understanding.
It’s certainly useful to get advice and help from people who know a language really well but we need to be careful not to under estimate the value of making mistakes and learning from them.
About the author
I'm currently working on short form content at ClickHouse. I publish short 5 minute videos showing how to solve data problems on YouTube @LearnDataWithMark. I previously worked on graph analytics at Neo4j, where I also co-authored the O'Reilly Graph Algorithms Book with Amy Hodler.