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.
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.
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.
Knowing that the solution is there to be applied prevents you from reinventing the wheel.
Thanks! That's the most condensed description of a problem with current education system so far! :)
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.
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.
(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.)
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.
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.
it reads as fine companion to the original post
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.
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".
i wanted to teach a friend programming and as such showed this person how to solve problems i had that made me interested in programming
the problem was the friend was additionally uninterested in the problem as well as learning to program a solution
so instead we just spent time together working in the same space and i asked them to tell me whenever they were frustrated by their tools
i knew whatever the ill i could use programming to solve it, be it with bash one liners, computer vision, simple robotics, whatever
i find that the best way to make someone interested in something is the align the thing to their interests
That's a little presumptuous, dont you think?