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