Teaching machines is hard

Week four at Hacker School:

1. User Authentication and Access Control: hashes, salts and cookies
2. Project Euler using Julia
3. Machine Learning with a neural network

This past week sounds like a productive week, but somehow I feel that I’m not accomplishing enough.  Does anyone else feel that no matter how much they accomplish, it’s not enough?

Maybe it’s my global (holistic) learner style that Mel explained, which causes me to jump around a lot and not feel satisfied with a concept until that magic aha-moment where everything finally clicks.

“Global learner […] absorbs information almost randomly, in no apparent logical sequence. […] but sometimes everything “clicks” and thereafter she can do problems intuitively […]. Although these folks are often global systems thinkers and potentially super-creative, the structure of school poses difficulties for them and they frequently drop out.”

This week, I only hit that satisfying moment on 1 out of the 3 aforementioned projects.

Dreaming in Assembly

When learning a new concept, it is very common to experience dreams somehow related to the material.  Some researchers hypothesize that dreaming is a nifty result of your brain’s biological process of long-term memory consolidation.

Defragging your brain during sleep allows short term memories to be re-encoded, by strengthening neural traces of recent events.  This also serves to integrate these new traces with previously stored knowledge and older memories.

Have you ever dreamt in code?

How hackers learn… (for fun_and_profit in life):

Perhaps the most interesting thing I learned so far in Hacker School is that you should design learning like you design code.  This was inspired by a presentation that Mel Chua gave to our batch.  It’s a very powerful idea that I feel is worth exploring, analyzing and sharing.

In this post, I will attempt to cover how and why programmers learn, how they design code and why everyone could benefit from adopting the “design to learn” model.

Why developers learn:

In The Dark Knight, the Joker said, “If you’re good at something, never do it for free”.  Programming can be a very profitable career choice.  So it’s safe to say that some developers do it for the $money.  They understand the supply-demand curve of market economics.  To most people, computers are highly useful magic black-boxes of awesomeness, so those who wield the power to create and control them are wizards.  Mastering a language, technology stack or project implementation yields great rewards when those skills solve real-world problems.  Just imagine how much XYZ Company will pay for a level-60 Java wizard!

1. Learn to code
2. …
3. Profit

But what about software engineers who aren’t in it for the money? Their motivation is probably a bit more interesting and complex.  For some, it is the autonomy and creativity of creating novel code.  Or maybe it’s the competence felt when basking in the praise of technophobes whose desktops always need rescuing (Mom, I promise I’ll fix your Internet as soon as I get some free time).

There is no such thing as a best solution, be it a tool, a language, or an operating system. There can only be systems that are more appropriate in a particular set of circumstances.