
Locked doors, headaches, and intellectual need - luu
http://mkremins.github.io/blog/doors-headaches-intellectual-need/
======
greghendershott
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.

~~~
QuercusMax
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.

~~~
Natanael_L
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.

------
eykanal
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.

~~~
Too
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.

~~~
shurcooL
Oh man.

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.

------
javajosh
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.)

~~~
chx
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.

------
sotojuan
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.

------
techdragon
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.

~~~
scrollaway
Same. It's not often, even on HN, that I come out of an article with so many
lightbulbs lighting up. Beautiful.

------
visionf
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!

------
justifier
i often cite this great write up of the evolution of a famous video game
franchise when discussing specific ills of education

[http://tevisthompson.com/saving-zelda/](http://tevisthompson.com/saving-
zelda/)

it reads as fine companion to the original post

------
chippy
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.

------
scottious
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".

------
pcl
That's a great article! I suspect that I'd be able to write better docs and
give better talks if I take it to heart.

------
tinco
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.

~~~
jib
Sorting long lists is a good one. Filtering of various kinds.

~~~
icebraining
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.

