
The need for tooling and the need for mastering your tools - r4um
http://muratbuffalo.blogspot.com/2018/03/master-your-tools.html
======
accidentalrebel
The tool for me that I have spent a lot of time learning and improving is my
Emacs environment.

It wasn't easy but as soon as I got the hang of things I was able to improve a
lot in terms of overall productivity. Knowing how to debug when things go
wrong and where to look to solve it was the first step in my learning journey.
I eventually started heavily customizing by making scripts and packages to
further suit my needs.

> After you master a tool, you internalize it and go minimalist, and reduce it
> to first principles. This line made me feel like I'm on the right track.
> Just recently I've cleared up the fluff in my emacs config leaving only
> simple but effective and essential tools. I realized that I've made a lot of
> edits to my config and that each one taught me something that eventually led
> to where i am now. In a way, clearing things out was a learning experience
> in itself.

I still have a lot to learn though. Just recently I've made a jump to reading
the enacs source and even took the time to contribute to Remacs, a Rust port
of Emacs. I'll admit that this one is a bit overwhelming and may even seem
overdoing it, but it is still a fun learning experience.

I sure do love my tool.

~~~
jrimbault
Same with vim (and other text editors), at first I started customizing
heavily. Now I can get going with just 3 settings.

    
    
        syntax on
        set number
        set relativenumber

~~~
weaksauce
As a long time vim user and lover of the idea of vim. emacs is better at being
a vim than vim is. (org, magit, helm, swoop, and all the other great packages
are a bonus and work as well as they do because of the way emacs was created.)
vim modal editing is life but vim's implementation is really bad
comparatively.

~~~
falcolas
I have to disagree. Evil mode in emacs is (on the scale of vim clones) pretty
good, but it is still an emulation of vim within emacs, and there are a lot of
hard stops throughout the experience for a long time vim user. The biggest
hard stop for me was the implementation of C-[, which interpreted word
boundaries differently than vim - differently than emacs even.

Of course, if all you're looking for is modal editing in emacs and don't mind
falling back to emacs keybinds, then evil mode will do just fine for you.

~~~
weaksauce
You can change word boundaries pretty easily though. There is a little bit of
friction in some things like that but nothing that is insurmountable. Every
single keystroke is a function that can be changed and even wrapped with
"advice" to leave the function alone but change the before, after, or both
before and after the function is called.

------
jacobolus
This is the main reason I am ambivalent about the typical school (even the
best ones I know about, and from first grade up through the undergraduate
level). Compared to the amount of time spent, relatively little is focused on
mastering all of the metacognitive skills required for expert problem solving
in any domain. Almost all work is done at the shallowest surface level with
shallow delayed feedback and an overemphasis on punishing minor errors or non-
standard output formatting, and on judging/ranking the students. There is a
parade of 'content' to get through, but little chance for students to work on
problems which are truly difficult (for the student at their current level,
e.g. taking more than a few hours to figure out a single problem) or larger-
scale projects of personal interest. Very seldom is the work revisited or
iterated. Ideas and methods from one discipline are seldom applied to another.
Students are systematically discouraged from taking any kind of risk. (This is
not primarily the fault of individual educators: scaling close personal
attention from experts is just uneconomical given current societal resources
available for education, and schools have many difficult constraints on
pedagogy.)

~~~
triangleman
>There is a parade of 'content' to get through

Did you know that the content is also shallow? According to E.D. Hirsch [1],
one of the reasons low-income and other marginalized groups do bad in schools
after elementary school is because they lack the exposure to "cultural
vocabulary" and end up feeling like a fish out of water when any more
challenging material comes up.

So in line with the spirit of the OP, some of the "tooling" that we need in
education is simply a deeper understanding of the national culture that all
well-educated people have naturally adopted.

For instance, you could help low income students by simply having them watch
shows like _The Big Bang Theory_ and then maybe have a discussion about it in
class. (And I say this as someone who doesn't like that show. But I know it
speaks a very strong cultural language used by well-educated Americans.)

[1]
[https://en.wikipedia.org/wiki/Cultural_literacy](https://en.wikipedia.org/wiki/Cultural_literacy)

~~~
jacobolus
I don’t think watching TV sitcoms is going to cut it. If you look at the
density of ideas, richness of references, complexity of sentences, etc.,
pretty much any written material (novels, nonfiction aimed at teenagers,
magazines, newspapers, ...) blows those out of the water. The teacher would do
better to just read to the students for 30m every day, instead of having them
watch a show for that time.

------
jitl
I like tools. I like building them, and I like using good ones. I love the
feeling of leverage from using my tools together to accomplish in days things
that would have taken weeks or months without.

As a tools author though I struggle to produce things that are both _powerful_
yet also easy to use. I tend to build things that are too “UNIX-y” - and I end
up with blank stares from co-workers (users) when I ask them, “did you read
the —-help output?” Or likewise when I suggest that perhaps they can wrap
tools in bash scripts or aliases and bolt things together...

~~~
spc476
About 20 years ago a friend and I were doing some contract work for a company.
I was an undergrad (Comp Sci) and she was a graduate student (also Comp Sci---
same college). Our task was to add links to a glossary in about 100 pages of
HTML and my friend just started doing it all by hand (well, editing each file
one at a time). I had to fight with her to stop and just think about the
problem. We were both familiar with Unix, and we were working on a Unix system
(SCO, but the company had blown thousands of dollars for the entire SCO works)
and I realized we had access to lex.

Normally, one uses lex in conjunction with compilers, but it would work for
this job---as each word was found, generate the output with a link to the
glossary; otherwise just copy the input to the output. Half an hour later we
were done with the entire task.

I just now realized that there may have been more to the approaches than I
realized. I was looking at this very tedious task and _not_ wanting to do it.
Why not have the computer do the boring grunt work of finding and editing? But
we were being paid hourly and it could have been that my friend was looking
forward to doing this very tedious job for _hours_ and making that much more
money. I am reminded of the Upton Sinclair quote, "It is difficult to get a
man to understand something, when his salary depends upon his not
understanding it."

It could also have been that I think differently and realized the application
of a standard Unix tool normally used for one task was appropriate for this
task and my friend just couldn't see it. Either could be possible.

I have to wonder how much of this is due to "not understanding that the
computer can be instructed to do the boring stuff" versus the "I don't want to
code myself out of a job."

~~~
jacobolus
Finding and deploying tools you know about (but wouldn't immediately think of)
in non-standard ways is a meta-cognitive skill which can be practiced. It's
possible you had some relevant past problem-solving experience which your
friend did not. It is also possible that you had systematically been
socialized to pursue different high-level strategies toward work – I have many
friends who were children of working professionals and were taught to value
'working hard' above looking for shortcuts.

Aside: It's not only the explicit prospect of hours of work that might have
stymied your friend... research suggests that when working for a reward people
are typically less creative and less thoughtful than when intrinsically
motivated (see Alfie Kohn's book _Punished by Rewards_ ).

~~~
spc476
Well, I had helped her with her compiler project a year earlier, but given
that we _both_ had experience with lex I'm not sure if we both saw the
relevence or not. Your other point makes sense.

And your point about hard work _really_ makes since given her background and
personality.

~~~
jacobolus
You might enjoy Alan Schoenfeld's book _Mathematical Problem Solving_ , which
tries to analyze the way that novice problem solvers make a hash of relatively
easy 'non-standard' problems, while expert problem solvers prevail, even when
the novices have more immediate and direct experience with the required
background knowledge for the problem. The biggest difference is that the
experts do a lot more planning, introspection, and strategic adjustment along
the way, while the novices immediately start down one wrong track and get
stuck in the weeds, forgetting what they were trying to do or why.

------
taeric
Mastery of tooling is easily the most successful nerdsnipe you can do in an
org. It abounds with metaphors to sharp physical tools that are ironically
required to perform tasks safely. And, to an extent, it is obvious to see that
people with more mastery over their toolchest will be able to outperform those
of lesser mastery.

However, it is also easy to find evidence that quality of tooling does _not_
translate to quality products in software. Not the least piece of evidence is
Linux and the rise of free as in beer tooling.

I think it can easily diverge into navel gazing. It isn't that tooling is
unimportant. But that it should not become the focus. If you want to make
quality products, obsess over the quality of your product. Don't get
distracted by what you know about what went into it. Focus on the product.
Period.

Yes, you will at times have to settle for a proxy measure. No, they will not
be perfect. Nor can they be. Don't fixate on a single metric, but collect many
and constantly ask yourself what the metric is telling you about the product.
Not about itself.

~~~
jacobolus
This is mostly talking about a different type of tooling and a different type
of mastery. 'Tools' here might be something like 'immutable data structures',
'formal analysis of algorithms', 'linear algebra', 'debugging', 'usability
studies', or 'project management', rather than some specific piece of
software.

The examples given (paxos and map-reduce) are very high level concepts, which
open the door to products which would be impossible or qualitatively very
different without them.

~~~
taeric
To an extent, sure. But, I could replace "experience" with every usage of
"tool" in the article and find that it makes more sense to me.

When you lack experience building anything, it seems natural to think that the
tools used by practitioners enable them to do what they do. After gaining
experience, lots of it, you find that the tools can help build a scaffolding,
but what you are really building can often be obscured by the scaffolding.
Which is why it is not uncommon to see some experts that can work with minimal
tooling. They have built their ability to see the product and end goal,
without the need of some tooling.

Which is not to say you can always get by without tooling. No amount of
internalizing the instrument and idea of flying will help a pilot fly without
a plane, after all.

~~~
jacobolus
Again, the experts have a whole bag of conceptual tools to pull out and apply
at moment's notice, collected and honed over a lifetime, which the novices
don't even know exist. That's what makes them experts.

In e.g. painting those tools might include knowledge of anatomy, lighting,
human color vision, paint chemistry, composition, perspective, art history,
specific stroke techniques, ..., plus time management, working with live
models, managing client expectations, a collection of unused ideas to try,
previsualization, judging and adjusting preliminary sketches, ..., none of
which has anything to do with the specific canvas or brushes or subject. The
expert will get better results from inferior paints and brushes and studio,
because of all their other hidden tools. What seems from outside like 'minimal
tooling' is actually a cornucopia of tools.

~~~
taeric
My assertion is still that this is a great nerd snipe.

There are two aspects here. First, metaphorical tools are stretching the
usefulness of the term tool to an extent. We already have a term for that,
knowledge. It serves a different purpose than tooling. Specifically, tools act
as great methods to let someone without the knowledge benefit from it.

So, the standard library of most languages helps give tools to developers such
that they don't have to know the details of the data structures. Just as
paints let a painter not have to know the details of the pigments or other
components of their supplies.

Then there is the aspect that the knowledge doesn't necessarily translate to
results. It is easy to see how many critics are far more knowledgeable of
their fields than many of the practitioners. Yet, your average practitioner is
probably accomplishing more than your average critic.

I want to stress again, though, that it is not that tooling is unimportant. It
is just an easy nerd snipe and is an easy way to divert from your actual task
at hand and get very little accomplished.

~~~
jacobolus
If you prefer substitute 'principles, concepts, methods, and metacognitive
skills' for 'tools'. Try not to get hung up on the precise labels. Factual
knowledge is only a small part of what we are talking about here.

The 'critics' have an entirely different toolset from 'practitioners'. Even
their factual knowledge is of a different type, grounded in a different
context, and not easily comparable. Likewise it doesn't make much sense to
compare their 'accomplishments': criticism is its own valuable discipline with
different goals.

------
eecc
Speaking of tooling and differential mathematics (mentioned in the article
itself,) I also basically flunked “Analisi II” (and quite probably never fully
understood Analisi I,) the Italian equivalents of Calculus.

Only when I changed Università and retook Analisi II, taught by a different
prof, who demonstrated everything using more powerful and meaningful tools did
I get it all.

Same thing with electromagnetism; couldn’t ever _not_ make a mistake with
those pesky Maxwell equations until I bumped into some lecture notes treating
them with Diadic Calculus (a kind of tensor) and voila, I passed.

My brain is pretty average, particularly when referring to working memory.
Give me a strong abstraction and I get it, ask me to wade through the minutiae
and I lose it.

~~~
castle-bravo
I don't think you're alone in this. A lot of my coursework is presented as a
series of exercises in memorizing solutions to special cases and applying
those solutions in a treadmill of quizzes, assignments, and exams. I find
myself craving better, more powerful abstractions that subsume the special
cases; complex numbers are a great source of satisfaction to me for this
reason.

------
edwinyzh
I like software tools which is handy. I needed to do mindmapping in my way and
I built MindVisualizer ([http://innovationgear.com/mind-mapping-
software/);](http://innovationgear.com/mind-mapping-software/\);) I needed to
edit my web pages in my way and I built LIVEditor
([http://liveditor.com/index.php](http://liveditor.com/index.php)).

------
thriftwy
I don't like tuning my tools.

You spend a few hours tinkering with settings, then two years pass like a
breeze, you have reinstalled your system / on another employer's laptop, and
you have to re-configure everything. From memory. That's frustrating.

Yes, I carry around a .zshrc from the times when I still made the effort.

Otherwise I would prefer convention over configuration. Just provide sane
defaults. Please.

Moreover, when you're an infrequent programmer, you would want to invest the
least into tuning tools. E.g. I won't waste time setting up configs on a
zillion servers that I visit. I'll use bash. It's better today than it was 15
years ago.

~~~
majewsky
> You spend a few hours tinkering with settings, then two years pass like a
> breeze, you have reinstalled your system / on another employer's laptop, and
> you have to re-configure everything. From memory. That's frustrating.

That's why we treat configuration as code these days. Put _all_ configuration
files that matter in a repo.

And if a tool does not take a plain-text config file, or at least allow you to
export settings to a plain-text file for later re-import, it's frankly not
worth your time.

~~~
thriftwy
I am not a DevOps so I won't be able to _deploy_ that repo contents for the
fear of my life.

~~~
majewsky
What's particularly hard (or particularly DevOps) about a simple shell script
that creates a bunch of symlinks? This is what I use:
[https://github.com/majewsky/devenv/blob/master/install.sh](https://github.com/majewsky/devenv/blob/master/install.sh)

------
camnora
The book The Art of Learning explains these concepts in depth very well.

------
montyf
I wrote a blog post on tool mastery a few days ago, mostly in response to an
egregious article named "You are not your tools"[0], but also to write down
some of my recent thoughts on this topic[1].

I agree with the OP that internalizing a tool changes your brain for the
better. Everyone knows that learning a new language (human language) expands
your brain and improves your ability to learn _more_ languages. Let's continue
this example, just to make things clearer. Mastering foreign languages is not
a cakewalk, despite scattered marketing claims that you can do it in a year or
even three months. From the OP:

> Just having a passing familiarity with the tool doesn't empower you.

You can't learn Korean just by visiting Korea and waiting for osmosis to take
effect. Even people who live in foreign countries for decades fail to learn
the language if they don't put in the appropriate effort -- I've seen it
happen. But "You are not your tools" makes the following dim-witted assertion:

> Spend your time listening and learning from everyone, whatever tools they
> use: most skills will transfer just fine.

That's exactly the opposite of what you should do. You will internalize
nothing with this plan, nothing will "transfer" (if anything you will have
interference[2]), and you will just end up like so many other mediocre
programmers I see. Anyone who's learned a foreign language knows this -- you
need skillful Practice and Concentration. Trying to learn two languages at
once takes more than twice as much effort than if you focused on one, if you
don't do it with great skill.

Quote from my blog post:

> There is a huge gap between the average programmer and the real hacker. On
> one side of the gap is the doe-eyed little boy who goes into every project
> clueless about how to start, searching for a relevant tutorial on Google
> while frantically asking questions on StackOverflow. On the other side is
> the man who plunges into the project with an air of mastery, controlling his
> environment with a fluid ease which is rare and somewhat dangerous – a man
> who’s already finishing the task by the time the boy has gotten his first
> response on StackOverflow. Which side of that gap do you want to be on all
> your life?

Now returning to the OP.

> What qualifies as a tool? Does critical reading qualify? How about writing
> well?

These absolutely qualify. These are fundamental tools -- mastering them will
improve many other areas of your life. But you would not believe how few
programmers take the time to improve these skills, or even care. Sometimes I
get the feeling that the average programmer hasn't read a single book in his
life (apart from maybe some programming or self-improvement books, which are
generally poorly written and unimaginative). It shows.

> What are the tools that benefited you the most?

Emacs, without question. I took the time to learn it during a spell of happy
unemployment as I was living abroad. This one decision has paid enormous
dividends in my life, but only because I took the time to truly master this
tool. It not only has made me more productive at pretty much everything I do
on computers (which in itself is valuable -- the more prolific you are, the
better you become), but it made me _smarter_ and _more confident_ on account
of having mastered something. Men are supposed to be experts. Mastering
something silences your inner critic and cues your brain in to your innate
self-worth -- it's how male brains seem to function.

You can learn Vim instead, but please avoid IDEs. Easy-to-use, lowest-common-
demoninator, "thoughtless" tools actually seem to be making people dumber.
It's the path of least resistance versus the path of blood, sweat and tears --
and they go in opposite directions.

A question the OP should have asked, but didn't:

> How do you know when you've mastered a tool?

You will know. It changes the way you see the world. New possibilities arise,
the horizon broadens, and you begin to see with lucidity how powerful you are
and how far your potential truly goes.

As J. Peterson says,

> People create their worlds with the tools they have directly at hand. Faulty
> tools produce faulty results. Repeated use of the same faulty tools produces
> the same faulty results.

A quote from Kafka on the Shore:

> Pointless thinking is worse than no thinking at all.

[0]: [https://codewithoutrules.com/2018/03/23/you-are-not-your-
too...](https://codewithoutrules.com/2018/03/23/you-are-not-your-tools/).
These kinds of articles are not just idiotic, but harmful to society -- the
attitude expressed here will make people worse at their jobs and at life, and
we should speak out against this pernicious mindset.

[1]: I won't post my article here, as my blog can be found on my user page. I
posted it on Reddit and received a hostile and, well, juvenile response. A lot
of people took issue with the idea that certain tools are better than others
(seems like Vim/Emacs are not liked there) and the idea of someone taking
mastery seriously ("You must be fun at parties" was, I kid you not, an upvoted
response). It's not just about mastering your tools, but mastering your
environment by extension. It's about power -- the power to change our world --
for the better. Many people embody a mediocrity mindset and go through life
without skill or strategy -- they unconsciously know their own inadequacy, and
you can see this on their faces.

[2]:
[https://en.wikipedia.org/wiki/Interference_theory](https://en.wikipedia.org/wiki/Interference_theory)

~~~
yodsanklai
> You can learn Vim instead, but please avoid IDEs. Easy-to-use, lowest-
> common-demoninator, "thoughtless" tools actually seem to be making people
> dumber.

I would argue that you should learn both. It really depends on the context.
Vim/emacs are nice, but for certain tasks, IDEs are more suitable. I would
also recommend to master your OS shortcuts, we edit a lot of text outside
vim/emacs.

~~~
Kagerjay
I would argue that learning both is important, but its always better to learn
the dumb tools first (IDE). Dumb tools were made for a reason because they are
the lowest common denominator and therefore easier to get things done. Your
time spent on tooling could have been used elsewhere.

VIM / emacs are great if you work in a unix environment, but as a windows user
Id rather have nice GUI tools. Requires less memorization to do the same
tasks.

I would also argue against memorizing shortcuts as well, and if you do, only a
select few that you often use. Rather have a quick reference file on hand for
these shortcuts to memorize.

~~~
TeMPOraL
If you subscribe to the view that Emacs is an OS disguised as an editor, you
can get pretty far with it on Windows too. I do recommend that.

------
joesmo
Almost every software tool decision I make is one of garbage quality with
features vs ok quality with no features. I can choose a text editor that does
the basics but nothing else I need or an ide that does everything poorly. From
browsers to package managers to debuggers to operations tools, the quality of
software tools is absolutely atrocious. Why master any of this garbage when
more garbage tools will be required later? It's hard to stay sane just using
them. Yes, non software tools like reading and writing comprehension are
useful, but for the most part, investing heavily in a tool that's bound to
fail over and over again seems like a terrible idea. Then again, there simply
isn't enough time to write proper versions of these tools. But amazing things
have been built with much less tooling than we use today which leads me to
think that the proliferation of software tools partly exists only to make the
tool developers happy as they create useless rube Goldberg machines
(especially in js land).

