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

I consider a tool that requires me to dig too much inside its internals a bad tool, and a tool I can't start using, even if in a very inefficient way, after reading 2 minutes of quick start, a tool that is not good for me.

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.

I dig as deep as necessary to make things work cleanly, and generally no deeper. (The exception is innately fascinating topics, like compilers.) I can't stand kludging around aimlessly until things work, but I can't read the source of every library, either.

At the moment, I'm trying to build a drop-in blog engine for Rails 3.1, which involves reading a fair amount of source code. But I need to wrap this up today and start on a different client project tomorrow, so I can't afford to dive too deeply.

You can ask these same questions about a lot of things we use every day. Do you have deep knowledge of how your car works, or just a superficial understanding of the basics to keep it running? How about your refrigerator? Household plumbing? Your computer? And how deep is "superficial"?

Another question to ask yourself is, "If it breaks, could you fix it?" And what is fixing it? Swapping parts, fiddling with function params, without knowing exactly what went wrong at a deep level? Paying someone to fix it for you? Is it "understanding" to know whom to pay for what repair?

I believe it is possible to have a thorough understanding of every aspect of every tool we use, but this would tend to limit the extent most of us would build up from it, as time spent learning these fundamentals is no longer available for deriving from them. If we assume humans have limited time and capacity for understanding what already is, it's by necessity that we use certain inventions as black boxes in order to build from them.

Or maybe the question is, "Should you be able to build your own toaster?"

http://www.ted.com/talks/thomas_thwaites_how_i_built_a_toast...

For me, it depends on the tool. If I think the tool is internally cohesive, and the underlying reasons for its behavior are sound, I'll learn about them it and try to figure out its behavior.

If I think the tool is a sloppy stack of hacks, I don't care how it works --- I actively avoid the nightmare. I don't want to spend my time figuring out which bad decisions, bugs, and corner cases made it behave in a certain way.

I have found that I ALWAYS try to learn as much as I can to have a fully intimate understand of the tools that I use. However, I have also found that this has more often than not been a huge disservice to myself.

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.

Understanding your tools in detail is a great way to differentiate yourelf. I make it a point to understand my working subject matter in great detail. At one point in my career, I did a lot of telecom consulting. Work ranged from voice network design all the way down to troubleshooting. I could have done my job by simply being a "phone ringer" (someone who just calls someone else to solve problems), but I found that by understanding the technologies in detail, I could discern fact from fiction when dealing with third-parties. This made me extremely valuable to my clients. I don't think I worked with a company that didn't float me a job offer at some point.

Bottom line: Understanding your tools in depth allows you to differentiate outcomes that will be opaque to less knowledgable competitors.

Depends on how much respect I have for the tool.

The TCP/IP stack: strive to understand it.

Random Java SOAP abomination: get in, make it work, get out.

Even the most trivial of applications today will depend on an incredible amount of carefully crafted, clever to genius code (operating systems, databases, compilers, VMs, ...). I'm always deeply humbled when I think of all the engineering smarts and effort that went into the stack I'm working with every day.

There's no chance in hell to understand all the tools. It's quite possible to understand the concepts and general principles these tools are built around (i.e., all the stuff you get taught in a proper computer science course), which I think is what one should thrive for.

Note that even understanding the concepts will not even nearly equip you to (easily) understand and re-implement these tools, there's a lot more to any properly crafted tool than just the rough concepts.

I think this is an important indicators of whether you should be an entrepreneur or a software developer. The best developers are fascinated by the processes that animate their work; sometimes they can't dig down all the way given time constraints but I find that they (and I) could happily analyze (and ideally rewrite) the entire gordian knot of a complex system.

Entrepreneurs have a totally different profile. Instead of the "how" and "what" of the project, they focus on the "why" and the "who cares". Will this project be valuable? Should I pivot this idea? Who is my first customer and what do they want?

These tendencies don't coexists very well -- they both want to be priority 1 in my mind. While I've been writing code, polishing scripts, reading kernel code, and accumulating my 5000 lines of emacs-lisp hacks, my friends chose different routes and started small businesses or pursued influence and high salaries. Now I'm a super-wonky developer and they're much better at sniffing out the real value in the world. Each of us has our place and on some days I'd rather be them. Somehow though, and somewhat mysteriously, when it comes time to choose I'd rather be rewriting the low level than pursuing meaning at the high-level.

If you don't understand how something works, you will never understand why it stopped working.

Lesson #1 from my car hacking hobby.

I ussually make it work first, then slowly begin to understand the tools through working with them.

I'm of the school that in many things, if you have to teach someone how to use it, you've done it wrong. Let the user learn by doing.

Probably can't apply to everything, but we should work as had as we can to try to get there.

Not only do I like understanding my tools, I build my own tools. I find abstractions and go after them whenever possible. There is always an upfront cost to this but the end result is a cleaner system.

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.

For me, it's kind of the default state of mind, building models of reality, and I can go as far as doing it unconsciously. Just a few hours ago I was in a friend's office talking to him about 3D models and through no conscious decision of mine I started twiddling around with a perforator. The point where I realized what my purpose had been was when I broke the flow of the conversation with the complete non-sequitur, "oh, now I know what that twiddly part on a spring does - you pull it and lock the perforator making it more compact".

I know other people that do that too. For some of us, the immediate reaction to a new thing is "ooh, shiny, how does it work? Let's run some experiments." The scientific mindset is useful, I think, no matter what you wish to exploit.

I had never considered it. I can't 'make it work' without understanding it, so I consider it a non-issue.

I mean, I suppose minimal projects could get completed, but I never work on minimal projects. Mine always have edge cases, and that requires knowledge.

I would love it if documentation facilitating understanding was available for general technologies. Learning how != learning why. For example, I have many times tried to learn CSS and it would be _great_ if anyone would care to explain in broad terms what the theory behind it is. Why choose the primitives that they chose, it CSS 'turing complete' for layout? If so, why? Who came up with it? The same goes for many technologies. I would like to have some history, a theoretical backround, and the improvements that the tool tries to solve.

Powerful tools require a good understanding of them to get the most out of them.

The best powerful tools don't require an in-depth understanding of them to get started (think git, rails or Linux). But mastering them over time will make you better by orders of magnitude than the copy-pasters with no fundamental knowledge of the tools they use every day.

The trick is in figuring out which tools are good, and which of them you want to commit to.

If I can reuse the knowledge gained by understanding it, I go for it. In understanding, I can reduce complexity, or at least try, for future users.

Also if I find something that is complex, e.g. OAuth, I try to preserve the sources of information I used to reach a decent level of understanding for maintenance purposes.

If I'm just doing something quick and not worried about future usage, I just make it work.

I strive to understand the proper way to use the tool to make it work, most of the time I don't really care how the tool works as long as I understand the best and most efficient way the tool was indented to be used.

If later I have a strong desire to understand how it works I'll dive in, but most software tools I don't care to know.

I don't really care about the detail inner workings of my car.

A lot of time these two options go hand in hand.

That said, a lot of the tools I use at work are built by myself or my team. I trust them, so "making it work" is enough for me, especially because I don't always have the time to understand everything 100%.

If I'm doing something as a hobby, I try to understand it, because time isn't really a factor there, and that's the fun part, right?

For bowling, the underlying is basic physics, something that is never going to change, never go away.

For technology or tools, the underlying specifics are going to change insanely fast, so if you are learning it, you will need to unlearn soon (and learn something else).

So should you learn internals of libc? STL? JVM, bytecode? rt.jar? .NET CLR? V8 JIT?

I try to understand as much as I can. Recently, I tried to deploy a rails app without capistrano (the manual way). But, People are saying, like why are you even doing that?

I don't know. I want to know what is going on? Know it first, automate next, thats what I try to do most of the times.

Why it's very useful for developers to learn assembler, know computer at hardware level, know how instal Linux From Scratch, compile their own webserver/db/etc, sysadmin stuff.

Know that first. Then, if you choose, go use turn key systems/hosting environments.

Yes, we did! That is why we love Erlang but not Node.js, Lisp/Scheme instead of Java, Python3/Ruby instead of PHP, C but not C++, Postgres instead of MySQL, postfix, but not sendmail, Emacs instead of Eclipse, vim in terminal window and never use mc! ^_^

This seems like a false dichotomy.

We all just want to make things work. Oftentimes with programming, having a better understanding of your tools helps you become better at "making it work."

I know this is cliched, but it /should/ just work. It should be easy enough for the end user to have a basic understanding of that tool.

when I am working on my own project I try to dig as deeper as as I feel like. If I am a working on a client project I try to dig only as deep as I need to (with limited success)

I find there's a lot of hand-waving that goes on when you initially learn something.

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/

Has this guy disassembled and come to understand the inner workings of the drill he used? Because that's the deep tool knowledge in this analogy, not the insight into the interaction between hole position and ball/player performance.