Hacker News Reader

Comment by andai | Hacker News Reader

When learning new programming concepts, I would often have to learn them 5 or 10 times before they clicked. Once they clicked, they seemed completely obvious, and I couldn't imagine what it's like to not understand it.

Two mathematicians are discussing a theorem. The first mathematician says that the theorem is trivial. He then proceeds with two hours of exposition. At the end of the explanation, the second mathematician agrees that the theorem is indeed trivial.

View on HN

I remember this having been my experience with teaching myself to code as a kid. All I remember is initial endless frustration from having to re-read tutorials and documentation and still not understanding anything. Then at some point I can't remember, everything clicked into place and I can't understand why I didn't understand it before. Once I had those basics down, I haven't had that kind of struggle.

I went through a similar phase with math, struggled with basic algebra for years, then at some point it all clicked into place and I unintentionally ended up skipping all high school algebra to get to early calculus.

It makes it really hard when helping other people through those early concepts (like pointers), because "keep working and at some point it'll just click for you" isn't very convincing.

This describes me as well.

I’ve started to call it paying the “time tax” or “staring tax”, I have to just review tough concepts (code, concept, leetcode solution, math problem) for a long while before it eventually clicks.

That brings to mind a learning staircase that comes up in art, where you go between stages of learning to draw better and learning to observe better. Since you can't draw better until you can observe better, but you can't observe better if you can't draw well enough to match your current observation skills. So in a similar way, you have to pay some "time tax" to move forward.

> keep working and at some point it'll just click for you

Haha, monads still haven't clicked for me despite knowing F# and Clojure pretty well. I think of them as "functors that you can flatten" (and functors are "things you can `map` over", and `map` is "a structure-preserving transformation"). I know monads syntactically, but not intuitively. Despite this I still manage to work with monads pretty well - sometimes rote knowledge is enough. Maybe if my work involved discovering new monads I'd feel like I'd know them better. (I just see the same option/list/result(ish)/generator-style monads over and over.)

Ah, so you understand monads. The trick is that someone told you they're a big important deal. They aren't. They're useful, so they get used. But there's no great insight or revelation waiting for you. You've already got it.

That's the way it happened for me with computer programming.

I used to require this, but after having spent many years programming this stopped being the case. I've reached the point where i can see a new abstraction and usually immediatly understand it, regardless of language.

Has your career taken you across many different programming paradigms?

A C programmer with no experience in concatenative or, especially, functional languages will have little chance of understanding code written in Forth or Haskell. They will have to start at the bottom of the learning curve.

The differences between languages aren't just skin-deep. Same goes for the design patterns in those languages. Haskell's applicatives have no analog in C, for instance.

> Forth or Haskell

You're not wrong, but those don't crack the top-10 of in-demand languages. Enough functional paradigms have also crept into more popular languages that you wouldn't be completely lost.

Reply on news.ycombinator.com