

Do you strive to understand your tools, or simply “make it work”? - rglover
http://kylewritescode.com/post/10163606803/do-you-strive-to-understand-your-tools-or-simply-make

======
antirez
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.

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

~~~
mey
Agreed, I take the same approach. The world is not black/white, hacks/optimal.
There is a balancing act to be had, including balancing time spent against
future issues from that solution.

------
5teev
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...](http://www.ted.com/talks/thomas_thwaites_how_i_built_a_toaster_from_scratch.html)

~~~
hackinthebochs
The difference between appliances and tools we physically use and programming
tools is that the abstraction for physical tools is necessarily as simple as
possible. Cars being one of the most complex tools we interact with, it still
has a very basic and well defined set of abstractions to learn.

Software tools on the other hand have a way of spiraling in complexity. We're
so good at using physical tools because this simplicity allows us to learn
their use on an unconscious level, ie. muscle memory. The take home here is
that we need to radically simplify the programmming tools we use.
Unfortunately the trend towards frameworks rather than libraries is moving in
the wrong direction.

~~~
true_religion
In the context of the tool analogy, you're right: we should pick libraries and
not frameworks.

However, many software projects are complex machines---and like real world
machines they're made of parts.

It'd better then to have a framework because the framework assures you that
all these parts ought to work together, or at least have been designed to a
certain abstract standard.

Imagine building a car but rather than being able to order Ford-fitted parts
or Toyota-fitted parts, you'd just get generic parts that you then have to
machine yourself in order to make work. Every part, every screw, everything.
It'd take tens times as long as if you only had to machine rare parts (e.g. a
1965 engine block to fit a 1973 model frame).

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

~~~
5hoom
I think you make an excellent point.

Tools that are "internally cohesive" reward the effort put into learning them.

Knowledge gained learning one function of an internally cohesive tool can
often be applied to others, opening up new functionality and encouraging you
to learn more about the tool.

This way your understanding of good tools tends to grow organically instead of
the jarring pile of rote-learning that a kludgy tool tends to require.

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

~~~
aangjie
Yep... i know. it's kind of an information addiction. I have been there still
working through it. but one thing i have found useful is trying to be aware of
what am doing moment by moment. Rescuetime.com has been a great help in
summing up my activities and gives me pointers to avoid things not to do.

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

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

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

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

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

Lesson #1 from my car hacking hobby.

~~~
mrbogle
Just out of curiosity, what kind of car hacking? I used to do a bit of Honda
ECU hacking. It was a lot of fun.

~~~
orenmazor
these days I'm driving a 1989 YJ wrangler. it's a hilariously impractical
vehicle (not off roading yet), but it's unbelievably fun to work on, despite
being carbureted. everything's just so accessible and simple.

before this I was all over the vws (1.8t, tdi, and then an idi), with all the
usual vw stuff (especially diesels. I love diesels).

I think my next step will be either a subaru (track car), or a honda/bmw (just
a get-around car).

I'm pretty limited tho since I live in Ottawa and have no garage. ask me if
I've looked into starting a garage co-op here, and I'll tell you terrible
insurance related woes.

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

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

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

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

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

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

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

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

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

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

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

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

------
schiptsov
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! ^_^

------
SIK
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."

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

------
kailashbadu
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)

------
cletus
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/>

~~~
bediger
You may be interested in "The Camel Has Two Humps":
<http://www.eis.mdx.ac.uk/research/PhDArea/saeed/paper1.pdf> and other work by
Saeed Dehnahdi: <http://www.eis.mdx.ac.uk/research/PhDArea/saeed/>

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.

~~~
0x12
That paper has done a lot of damage.

I also think that if you write a paper like that, that it should include a lot
of qualifiers as to what you think you've discovered and what research might
be done in order to validate/disprove your findings.

Broadly binning a large part of the population as far as a fairly basic
ability is concerned (the ability to instruct another entity, which is the
essence of programming) based on some extremely flawed tests is not the way
science should be done.

Try the 'test' they give to people on a population and then try this test on
another population of similar size and observe the difference:

    
    
      move 10 to a
      move 20 to b
      move contents of b to a
    

The fact that programmers use '=' in a way that non-programmers would never
use it should not be part of any 'aptitude' test. That's just syntax and it
would give anybody with even a cursory knowledge of programming a huge
advantage. Even just the assumption that statements are to be executed in a
particular sequence greatly affects the outcome of tests like this and you may
have to specify such a thing up-front if you expect people to be on a level
playing field.

Note that I'm not saying that the conclusion of the paper is wrong, I simply
object to the hidden assumptions behind the design of the test. Removing those
assumptions would be pretty tricky thing to do with 100% accuracy, and in the
end the conclusions reached in the paper might still stand (but I doubt that
they would be the same in magnitude).

~~~
william42
But the predictor _isn't_ whether the testee gets these problems right. The
predictor is whether the testee uses a _consistent_ mental model for the
problem--that is, someone who interprets "a=b" as "move contents of a to b"
will end up programming as well as someone who does the converse, but not
someone who picks and chooses without being sure.

~~~
0x12
Yes, I read the paper.

Try coming up with a 'consistent mental model' that works with random
execution sequences.

Then try again for one that works backwards. And so on.

At best this test determines which people are going to be 'easy' to teach
programming. But just like sales start at 'no' teaching starts when the
subject is having problems, not when it's easy.

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

