Do you strive to understand your tools, or simply “make it work”?

Just the other day I was talking to a friend about learning programming. I said to him that I'm quite capable of teaching someone who knows the basics of programming more as long as there's the initial foundation to build on but I'll be damned if I know how to teach someone who doesn't know how to program at all how to program.

I don't even know how I learnt to program. I was a kid at the time and I guess I basically just typed in programs from books and then played around with them. I guess this model largely follows the idea of direct instruction [1]. It's one reason I like Zed Shaw's Learn Python the Hard Way [2] because it starts by just saying "type this in... actually type it don't copy and paste it" because for beginners this approach actually works (well).

One thing I find interesting is that many non-programmers I know are afraid to just start pressing buttons and messing around with stuff to get the computer to do what they want. They want to know how to do it before they start. I think this fits in with the theme of direct instruction as I've learnt the behaviour of doing something without knowing exactly what will happen. Without this willingness to try (fail) your ability to learn seems to be incredibly impeded to the point of being near-impossible (IMHO).

To bring this back to understanding your tools I would say I follow this pattern:

- If I can, I'll learn just enough to get by;

- I'll slowly accrue new techniques and knowledge as time goes by and I use it (studying this kind of thing without needing to use it is virtually useless for me); and

- For things that are most key to what I do I'll expend time and energy delving deeper into them but this applies more to languages, APIs, frameworks, platforms, etc than it does the tool. The tool is, after all, a means to an end not an end in itself.

For me I've found learning tools to follow a fairly similar pattern to learning (human not computer) languages: I can try and memorize things all I want but I seem to have this base rate at which I will accumulate "instinctive" knowledge that is a function of how much I use something with very little variation up or down.

YMMV.

[1]: http://en.wikipedia.org/wiki/Direct_instruction

[2]: http://learnpythonthehardway.org/

He thinks that only about a third of the populace can learn programming at all, and that may be the difference between teaching someone who knows the basics of programming vs teaching programming to a non-programmer.

For example, yesterday I got fired from my employer on my 90th day for not being productive enough. I can't fault my employer because I understand his perspective. He needs employees that are productive. I spent most of my 90 days learning the tools and EXACTLY how they work, without much to show for it. This was my fault. I spent too much time learning.

This is true with many things that I learn on my own as well. For example, in the last few days I started teaching myself Kohana PHP framework. If some of MY applications are going to be using it, I want to know exactly how it works and everything about it. I want to be an "expert" at everything, but I'm not quite sure how realistic that is.

I think I am going to try to change my ways to only learn enough to "make it work". If the tool is worthwhile to use over and over again, it is inevitable to develop an intimiate understanding of the way it works over time. I think it is more important to be able to have awesome products to show for the time you invest in your tools.

The understand-your-tools side builds the tools that the make-it-work side uses. The feedback between both sides is important for improvement. The success of the make-it-work side helps to quantify the value of the ideas coming from the understand-your-tools side. It's unfortunate that these two points are often treated like opposing sides.

The problem is that learning to build/configure/use XYZ is almost always a wasted effort, it is not like learning a new algorithm that will be useful knowledge for decades, so if the effort is too big I consider it wasted time.

Examples of tools that are not easy to master but that I'm trying to learn well are vim (it's 15 years I use it), and git. Both tools pay back a lot, and in the case of git it is hard to learn not because it is hard per-se, but since you are learning general concepts about distributed VCS, so it's not a wasted effort.