My most unrewarding educational experiences felt like I was being fire hosed solutions to problems I didn't have. This is a big challenge in the early stages of learning any subject.
Interestingly, experienced software developers benefit from barely-learning about many solutions to problems they don't have, yet. What I mean is a style of skimming stuff like API documentation. You don't really learn it. You can't recall details. But you can recognize its applicability. Someday a problem tickles your memory, and you know roughly where to go looking for the details. And of course then you're really motivated to learn it, for real. You have an immediate need.
This is a great point. I enjoy reading about various languages and paradigms even if I don't have a particular problem I need to solve, just to see what's out there. But without a concrete problem I'm actually trying to solve, I never go very far into actually applying these techniques at the time I learn about them.
Similarly, I've never found tutorial-style docs helpful, at least not the type where they walk you through solving some toy problem. But if I'm actually trying to solve something, I'll use the tutorial examples to crib from while implementing my actual solution.
I've read about Goroutines and channels, but never implemented anything with them (my experience with go consists of writing a BF interpreyer). But it looks like I'm going to have to work with a library in C++ that uses the same principles, and having that vague background knowledge helps a great deal.
Interestingly, I personally find that if there's an external motivator for solving these toy problems (for example, in a class or job interview situation), I don't have this same motivation difficulty. But if it's purely for my own amusement, I'm way too lazy.
I think of this as building mental / intellectual toolboxes.
Carpenters and mechanics, etc, like having tons of tools even if they know most won't really get any serious use, because suddenly that one tool might just save the day. The same thing definitely applies to computers, the more techniques and tools you know and the better you are at finding applicable tools, the faster you can solve whatever problems that you might encounter.
Yes!! Strongly agree. Your comment hints on why breadth of shallow knowledge (in web development) is so important: it's hard to apply somebody else's solution to a "solved problem" (e.g. email validation) when you don't know that solution exists in the first place. Often times, in software, gaining knowledge of the existence of a solution is about as useful as gaining knowledge of the application of that solution. The reason is that solutions to many software-related problems - be they data structures or form validation - often come with documentation, and figuring out how to apply the solution is relatively easy.
Knowing that the solution is there to be applied prevents you from reinventing the wheel.
Precisely. I had been struggling to find the right balance between studying something deep enough that I can draw on this knowledge when needed but not going so deep that I get bored and nothing comes out of it.
greghendershott Thanks for putting into words how I and many around me solve problems with code. I have a few associates that need a new approach to learning to solve problems with a specific problem. I think this article and the comments here on hacker new will form the basis of a conversation and hopefully some ah-ha moments after I create a headache for them.
This is a fantastic article, and is true in all walks of life. I'm a technical manager is a big corporation, and half of my problem is trying to explain to people why they need the stuff we do. In this case, they know they have problems, but they have other "forms of aspirin" they've found that half-bandaid the problem. Our solutions are much better, but they don't know that; it's up to me to explain to them what the problem is with their band-aid solutions and why our approach fixes them.
Thinking about this even more, this is the problem faced by virtually all salespeople. You won't buy my whatever until you know why you NEED my whatever. Even if you THINK you need my whatever, I have to make sure you understand what problem my whatever is solving, because if you buy it thinking it solves A but it really solves B then you'll be really pissed when you find out that you just paid for something that doesn't solve your problem (A).
Very good article, and the door/key analogy is fantastic.
People thinking they have a good solution when they don't is an interesting problem. A good technical example of this is parsing xml with regex or generating xml with string.format, I've had to explain to colleagues why this is bad so many times and many of them are stubborn and wonder why we should change something that "works". Initially they think the difference only carries academic significance, such as claiming i++ is faster than ++i. Usually you have to show them an example of valid xml that fails the regex before they realize that it is a problem. Kornish wrote a comment above about how important it is to know that certain problems have known solutions, in the same way its equally important to know what is not good "solutions" to certain problems.
I suffer so much when I see people using Go's "path" package to manipulate system filepaths (instead of "path/filepath" package)... Just because it happens to work on Linux/OS X (and maybe even modern Windows).
They just don't see what's wrong with doing that and it kills me.
Yes! In fact I've often considered this question in the context of teaching physics - wouldn't it be wonderful if you started with a really hard problem, flailed around for a while, and then learned the thing that could solve it for you? Instead (in basic mechanics) we get "f=ma" and then see how it applies to a bunch of systems, instead of first looking at some idealized systems and challenging a student to ask some really basic questions about it. (Not necessarily the full equations of motion, which might not make sense yet, but basic stuff like "how fast does this weight need to move before it leaves contact with this curved surface").
(Actually, it's a little more involved with "F=ma" because really that's a key to a bunch of other keys - it yields closed form solutions to a bunch of important problems which are characterized by whether "a" is constant (linear motion), proportional to x (a spring), proportional to x^2 (gravity, electrostatics), their rotational analogues, and so on. BTW it still trips me out that Newton saw this connection to so many disparate systems, but I'm deeply grateful that he did.)
What is most astonishing is when and using what mathematics Newton recognized this. The next "big batch" came some 140 (!) years later: Cauchy's work on calculus, Carnot with the second law of thermodynamics and Bolyai's geometry were all created around 1820-1825. That Newton 140 years earlier could pull this off, and it's not like he had vague ideas which we understand today well and just attribute to him -- no, he got the laws and the maths precisely.
It is a whole another thing that his work is incredibly hard to understand today mostly because we learn calculus as Cauchy and Weierstrass laid it down. There was a course at our univ which teached Newton's calculus it was incredibly hard, I left it early.
This is especially true if you are teaching yourself new programming languages. I'm currently learning Elixir because it looks fun. I've learned the syntax and stuff but I'm having a hard time learning OTP/BEAM/processes/etc because well, the most advanced thing I've done is a collage image generator in Node. I just don't feel like I need it (though I'm gonna try my hardest to!).
It's the same thing with all these functional languages like Elm and ClojureScript. I've had fun playing with them, but I've only been seriously programming for fun for a year and a half. I haven't had the pain of managing state in a large application that the people that hype those languages have.
This is the best thing I've read in ages. I found myself instantly realising how so many past occasions have related to it... Like the author I'll probably spend the rest of my life noticing places where this crops up.
Brilliant article. I have always found something off about people saying - "why reinvent the wheel?" Well, this article confirms that reinventing the wheel will make you a good learner (and in turn a good teacher) while reusing the wheel will make you 'efficient' worker. Whats the tradeoff? Something to think about!
Spot on. I think this can be applied to having tests also and arguably agile/XP.
Something everyone on HN is going to agree on is having tests and having a good test coverage. But why? Why should I if I am a newbie?
Because our experience has given us a headache and tests have been the asprin that makes sure that these headaches don't occur again.
Arguably agile because many people here don't believe in it. Why don't they believe in it? Because they have never had the headaches it is meant to help, or they have never tried it when they had the headache, or someone else on their team had the pain and not them.
Very interesting. Though I do wish he would have gone in depth about that duplicated code that he talked so much about.
I've been programming Scala professionally for a year now, in a very Functional way because of pressure from senior engineers. So I use flatMaps and for comprehensions all the time and I get that it's simpler than alternative ways to write it but I still don't really understand the core of what a monad really is.
I feel like I use monads all the time and I even have a know what people mean when they use them in a sentence. For example, when referring to a 'for comprehension' in Scala: "Well, what monad are you in?". I get it... I basically interpret that as "All statements in the for comprehension must return a Try or Future" or any other monad, but those are the ones I use a lot. I get that it's basically a flatMat? I guess I haven't actually manually converted for comprehensions to flatMaps, I just use whichever one seems to solve the problem the cleanest way at the time.
So I feel like I get it, kinda. But I'm still not like "monads! wow, so cool!" To me it's more like, "Okay, that's how you write that in Scala".
What sort of problem could you challenge a newbie with to entice them into learning to programming? It would need to have a simple enough solution to be possible to do with just the basic but painful enough for the newbie really desire the automation. It's easy to come up with something that would appeal to technical or mathematic minded, but much harder to for a child or alpha type.
The solution to that is "download some sorting and filtering software". You can force them to write their own, but it'll be like selling aspirins for the pain caused by your blow to their head; unless you're their school teacher -and even if you are- they may just end up resenting you.
Interestingly, experienced software developers benefit from barely-learning about many solutions to problems they don't have, yet. What I mean is a style of skimming stuff like API documentation. You don't really learn it. You can't recall details. But you can recognize its applicability. Someday a problem tickles your memory, and you know roughly where to go looking for the details. And of course then you're really motivated to learn it, for real. You have an immediate need.