Sunday, March 11, 2012

Learning: the Hacker Way

I have had a fair amount of discussions on continuous learning and knowledge sharing the past few days. It became rather obvious that a lot of us have developed their own techniques, but also that maybe most of us are still in search of more efficient techniques. Having gone through several phases myself, I would like to share my current way of learning: the Hacker Way.

Here are some snippets taken from a recent letter from Mark Zuckerberg addressed to the Facebook shareholders.
Hacking is an inherently hands-on and active discipline. Instead of debating for days whether a new idea is possible or what the best way to build something is, hackers would rather just prototype something and see what works. There's a hacker mantra that you'll hear a lot around Facebook offices: Code wins arguments.
I like to believe learning should be a hands-on activity as well. Basically, stop consuming, start producing. Don't get me wrong, I do think there is value in reading blog posts (I might be slightly biased on this one), reading books and watching videos, but I find that this value is marginal compared to what you gain by actually doing it.

I remember I wanted to step up my JavaScript game two years ago, and ordered a book. A few months after finishing the book, I finally had the chance to implement something in JavaScript, but I couldn't. I remembered some syntax, and most concepts, but I couldn't do it. Eventually I really learned JavaScript by doing it on the job, having to constantly fall back on the book and Stackoverflow, making costly mistakes along the way.

It's not a terrible idea to pick up a new technology on the job, but it very much depends on the environment. If you're in the consultancy business, there often is no room to pick up a brand new technology on the job. Customers expect you to know what you're doing.
Imagine you really want to get into mobile development, and you were able to get in the race for a new mobile project. Getting interviewed by the customer, you have to admit that you haven't built something for mobile yet, but you did read a book and you find mobile development really interesting. It's really hard to sell that. If you are able to show something you made, and talk about things that work and things that don't work in the real world, the customer can get a far better feel if you would be a good fit for the project.
The Hacker Way is an approach to building that involves continuous improvement and iteration. Hackers believe that something can always be better, and that nothing is ever complete. 
Hacker culture is also extremely open and meritocratic. Hackers believe that the best idea and implementation should always win - not the person who is best at lobbying for an idea or the person who manages the most people. 
This is where it becomes interesting and where you can really make the difference as a company.

Depending on various parameters, you often don't have the room to experiment on the day job, but if you're building something by yourself or in a small team without these constraints, you can get wild: experiment, innovate and fail often. Not only do you build experience faster, but you also (maybe indirectly) challenge existing practices and build a deeper understanding of the used methodologies and technologies. Also, having the freedom to innovate, aspiring to get closer to the Silver Bullet, can bring yourself, the company and the industry to the next level.

This is just the first step of the cycle though. The next step should be to get these little projects and acquired experiences out there. Share them with your peers and the community, educate those who want to listen and ask for feedback from those who care, hopefully fueling the inspiration of others.

A welcome side-effect might be that the results could be used to extend your personal and your company's portfolio. This can help you prove that you can do more than just talk the walk, talk is cheap after all.

I want to know from you what the flaws are in my way of thinking. Is the described technique naive, too idealistic or unrealistic?
Which technique has proven to work best for you?


  1. So what are your thoughts on how to learn a new language that you don't require on the job? For example, you needed Javascript on the job, but you want to learn how to make an iOS app using Objective C. How would you approach it without reading from the beginning?
    I'm looking for advice as much as I am perspective.

    1. Get _some_ study in, but as little as possible. Start working on something small as soon as possible.

  2. Much better than the alternative (all consumption, zero production), but still not quite ideal in my personal experience. A two-phase approach is better - first comes the dead-zone, which is getting from boot-camp to the front-line. Sad as it is, you can't just jump straight into everything. I tried that when I first started learning to code, and I hit the same experience as you with JS - constant fallback on StackOverflow. Extremely frustrating since progress was unnecessarily slow and I didn't understand the fundamental philosophies behind the coding process and structure.

    My current approach which is presently proving fantastic (we'll see where it goes) is to 1. bust through the dead-zone with brute force (I nicknamed it the dead-zone because it's precisely that for me - I can't get passionate enough to crank through it without imposing a strict regimen of study because it's not a project I can own and challenge myself with) and 2. get to working on a concrete personal/work project asap. Once I'm on the project I become obsessive and learn rapidly how all the pieces fit together - but that initial phase of consumption is invaluable for broad grasp of the subject at hand and understanding how all the pieces integrate into a whole.

    That said, the ideal circumstance is that you're able to produce piecemeal as you progress through the initial consumption phase as well - Learn Python the Hard Way is a great example that's worked very well personally as an intro to Python, precisely because of its piecemeal hands-on approach. The Django Book tutorial is a nice counterexample - had to rush through that one so I could begin a project and incorporate what I'd learned before I forgot it as there were significantly fewer opportunities for incremental imprinting of acquired knowledge. It wasn't a bad experience, as I did manage to get through it in time before I lost the majority of what I'd learn, but that kind of consumptive material is severely limited by time - if you find yourself forced to consume something like that, get through it as *fast* as you can and start producing whenever you feel your knowledge slipping away.

    TL;DR Consume a bit as fast as you can then produce

  3. Aka the lean approach to learning; what I have been doing all my life ever since I got out of school: take some example code and start experimenting: failing often but early.
    Gain experience as fast as you possibly can by getting out of your comfort zone.

  4. I find copy and modify type tutorials works well with a right amount of consumption and production. Macro and micro go hand in hand. Conceptual informs the concrete and vice versa. Good article.

    1. For sure. Also, fix the bug examples are quite good. You learn a bucket load of things when fixing bugs.

  5. I also believe that nothing substitutes getting your hands on and creating something but i feel reading previously and understanding the direction of whatever you are trying to use will really increase your productivity and let you end with a better end product knowledge.

    For example if you are learning to use and MVC framework understanding why the division of concerns matters will let you get a lot more from the experience by influencing the decisions of where to place the code and what not.

    1. Sure, I agree. A part of the learning process has to consist of consuming, but for most people it stops right there, which I think is plain wrong.

      Also, a lot of questions pop into my mind while building, that's when I search for the complementary theory I'm lacking.

  6. If you really want to understand Javascript, read and understand the CoffeeScript source code. It is fantastically well written and once you understand it (took me roughly 5-10 times through to understand every single part of it) you will understand pretty much the entire JS language (as well as CS).

  7. Great article! The hacker way of learning is basically what I used to learn anything from software to language. But there's two problems to it:

    1. It's just like building a house. You need a solid foundation before building it up so that the house doesn't fall down in the future. Of course, spending a lot of time on planning instead of actually building it is bad, too.

    2. You'd better only use the hacker way on your personal projects because it takes a lot of time. I think of it also as the perfectionist way of learning. The projects you do on your job have time constrains and set criteria, so you don't really have chance and the time to improve on your work again and again after it's finished. On the other hand, you are basically free to do anything on your personal projects, so the hacker way or the perfectionist way of learning isn't much a problem.

  8. Hackers steal passwords and information from innocent people's computers. Your article appears to be trying to paint hackers as honest people instead of the criminals that they most certainly are.

    1. Those would be 'crackers', not Hackers... but try to explain that to Hollywood, the Media and Politicians.

      ps: we are no Nerds either.


  9. I think it depends entirely on what you're learning, and what knowledge you bring to the table. There's a world of difference between an experienced programmer picking up another language or framework and an inexperienced junior just starting out. The former would probably go straight for the hacker method, while the latter would be better off not doing so - it's painful how many times I've met (Java) programmers that have learnt on the job, can do certain tasks well, but have no idea of what a classloader is, for example.

  10. Defintely learning by doing is the best way. However, as others have stated that you do need a solid foundation to start with. The only real difference with the hacker way of learning is that your foundations get stronger with every new day of learning. Everyday is a school day!

    This is one of the primary reasons why I love this job we do!