
Ask HN: The purest skills needed to become a programmer? - TbobbyZ
I recently watched Jiro Dreams of Sushi. It&#x27;s a documentary on a 85 year old man named Jiro who has spent 75 years of his life learning to make sushi. He&#x27;s addicted to his craft and has made his number one focus in life perfecting the art of making sushi.<p>Jiro lives a way of a shokunin which is<p>&quot;defined by both Japanese and Japanese-English dictionaries as &#x27;craftsman&#x27; or &#x27;artisan,&#x27; but such a literal description does not fully express the deeper meaning. The Japanese apprentice is taught that shokunin means not only having technical skills, but also implies an attitude and social consciousness. ... The shokunin has a social obligation to work his&#x2F;her best for the general welfare of the people. This obligation is both spiritual and material, in that no matter what it is, the shokunin&#x27;s responsibility is to fulfill the requirement.&quot;- Tasio Odate<p>Jiro has simplified everything in his working environment from cooking techniques and tools. He his pure in his focus of only making the best sushi possible and does so with a team of 5-6 chefs under him.<p>If Jiro was a computer programmer instead of a sushi chef, what would be his techniques and tools to perfect the art of computer programming?<p>Here is a list I have so far:<p>-Text editor
-A programming language
-Databases
-Algorithms
-Math
-Debugging
-Tests
-Writing Documentation&#x2F;Comments
======
greenyoda
You talk about techniques and tools. Having seen the movie, I think that
Jiro's most important quality is his passionate dedication to satisfying his
customers with a high-quality product and experience. This doesn't have much
to do with his tools - the tool set of a sushi chef is quite limited, and
hasn't changed much over many years. Any other other sushi chef would use the
same tools. The intuition he uses to select his fish in the market and how he
presents it to the customer are more important than what kind of knife he
uses.

I think Jiro-like programmers would similarly be distinguished by their mental
attitudes, and not by their tool sets. For example, satisfying the customer -
by creating code that's reliable, secure, easy to use and cost-effective -
would be their most important goal. Their own satisfaction would be derived
from fulfilling those goals, not from getting rich or using the latest trendy
frameworks. (I have nothing against people who want to advance their careers
or build billion-dollar companies, but that's not what Jiro is about. After
all these years, he still has just his one hole-in-the-wall sushi bar.)

------
perlgeek
If Jiro was a programmer, he certainly wouldn't limit himself to one
programming language or editor, just like the sushi chef doesn't use just one
tool.

He would use all the tools that make it possible or easier to write good
software (version control, tests, continuous integration, possibly code
quality metric tools) without being married to one in particular. He'd switch
to better languages and tools as he becomes aware of them, as far as the
switches are practical.

He would have a broad overview of the underlying theories (algorithms,
computability, complexity, various fields of math), and dive deep into those
that matter for the problem at hand.

He'd write clear documentation that the end user can understand.

He'd continue to evolve his tools and skills, and where he finds the current
tools lacking, he'd improve on them, or even write his own - but only so far
as it doesn't distract him too much from actually producing the software that
is his focus.

He'd be aware of his customer's requirements, and equally important, of the
goals behind those requirements.

He would be aware of security and moral implications of his software, and
refuse to compromise on them.

He wouldn't rant on hackernews, but be available for mentoring to those who
strive to imitate him.

~~~
thewarrior
I.E Richard Stallman ?

~~~
spdub
We hosted R.S. at my school, he was less than pleasant. I feel like this is
off topic however.

~~~
verytrivial
Yeah, well I think this is the confusion between "good" and "nice" again.

------
jlebar
I used to tell the students I TA'ed that their first task -- assuming they
were physically able to do so -- was to be able to type at 60wpm with high
accuracy, without looking at the keys. Many students, and indeed many
professional programmers can't, and I'm increasingly convinced it holds them
back [1].

Surely at least until you can type quickly and accurately, you're not going to
get much out of learning to use a complex editor like emacs or vim, and indeed
most command-line tools are going to be a chore to use.

As Jeff Atwood says, "When was the last time you saw a hunt-and-peck pianist?"
[2]

[1] This is of course not an original thought. Here's Jeff Atwood saying the
same thing: [http://blog.codinghorror.com/we-are-typists-first-
programmer...](http://blog.codinghorror.com/we-are-typists-first-programmers-
second/)

[2] [http://blog.codinghorror.com/the-keyboard-
cult/](http://blog.codinghorror.com/the-keyboard-cult/) (I should mention that
I don't agree with most of this post, but the line about pianists has always
stuck with me.)

~~~
elnygren
If typing speed is the bottleneck in your programming, you are doing way too
easy and trivial stuff. Start thinking about how to make more advanced
tools/frameworks/architectures/whatever-it-is-you-do that allow you to think
more and code less.

OK, I do see that it will never be a bad thing to be a fast typer. However,
spend a year learning to type faster or spend a year learning more math, logic
and advanced progamming concepts ?

~~~
emsy
> If typing speed is the bottleneck in your programming, you are doing way too
> easy and trivial stuff.

That's just your assumption. I'd say typing is probably the sill that's
easiest to optimize. Even if you just type 10% of your time, cutting it down
by half is a significant improvement. Also, proper typing will boost your
confidence and free your mind for more relevant things.

To draw parallels with Jiro: Cooks learn how to properly use a knife before
they're even allowed to cook. They do so by exercising preperation over and
over.

~~~
icebraining
_I 'd say typing is probably the sill that's easiest to optimize._

Muphry's law strikes again :)

------
methodin
Aside from the obvious factors like desire and technical ability, the single
greatest motivator to being an excellent programmer is the pursuit of
perfection while simultaneously understanding that it is impossible. Building
something that is never complete and ever-changing really boils down to how
many bad ways you've done it before and knowing which ones to avoid in
situations.

The only excellent programmers are the ones who've written a million lines of
terrible code and understand which methods have the best probability of
achieving a decent deal of success before the inevitable refactor (anyone can
pick up a book and turn everything into a Factory).

Write shitty code - each session is a brick in the foundation of an endless
skyscraper which gets more complex the higher you go. At some point you'll
start to program with the foresight to make your code easier to change down
the road without breaking everything and causing headaches. That's really all
that anyone needs in a programmer - making the future easier while allowing
the present to function as it needs to with as little issues as possible.

At some point you'll work on code made by inexperienced programmers that's
been built upon for years. If you are experienced enough, that code is
actually the most interesting thing in the world to transform and simplify.

tl;dr: Languages, tools, ides, setups are all insignificant if you've
implementing patterns in every wrong way as possible. Knowing what not to do
is more valuable than knowing one way to do it.

~~~
legedemon
I'm right now working on the type of code you've mentioned. I have 5000 lines
long classes in Ruby and arcane names for methods and variables. The person
who hired me warned me that it'll be a very frustrating experience but as
you've rightly pointed out, it has been very interesting to refactor that code
into neat little libraries and other classes.

------
swatow
Personally I don't think that programming can be compared to sushi making or
any other craft. I know this goes against majority thought in HN, but I think
intelligence is the most important thing for a programmer, followed by
domain/language specific knowledge, followed by appropriate choice of tools.

I think the market reflects my assessment, where young smart developers can
get paid a lot more than much more experienced developers. My view is also
consistent with the common advice I see on HN, which is to develop deep
expertise in a popular language/technology, and ensure this knowledge is
always up to date (as opposed to mastering the art of programming in general).

~~~
ramblerman
I think baseline intelligence is required that may or may not be of a moderate
to high average. But beyond that you don't get a better programmer by adding
intelligence points.

Those young smart developers you speak of have experience too. They've been
playing with these tools since they were 13 and love what they do.

~~~
swatow
In my experience you do get a better programmer as you add IQ points. In fact
I think that the technical interviews for software companies are in part
measuring general intelligence, although in a programming context. As people
rightly point out, you are very unlikely to actually need to solve the kinds
of problems they ask in these interviews while on the job.

------
zhoujianfu
The purest skills needed to be a programmer are the abilities to think like a
user, to think like a computer, and to translate between the two.

(I agree that accurate touch-typing doesn't hurt!)

------
jnardiello
Develop a working methodology which works for you (and remember that new !=
better):
[http://en.wikipedia.org/wiki/5S_%28methodology%29#Seiri](http://en.wikipedia.org/wiki/5S_%28methodology%29#Seiri)

Having your tools where you expect them to be and mastering them (shortcuts,
how to save keystrokes, how to type efficiently, how to perform
daily/repetitive tasks with low friction) is key factor. Personally this is
the reason why I use VIM over some modern IDE, i value more being fast and
keep improving over the years than having the latest feature which is likely
going to slow you down due to lack of consistency.

The beginner's mind -
[http://en.wikipedia.org/wiki/Shoshin](http://en.wikipedia.org/wiki/Shoshin)
Avoid at all costs to close yourself inside your craft and job. Avoid strong
opinions and realize that you will never know enough, you'll likely keep
learning from others and improve, this is why you should keep over the years
the beginner's mind.

Be a Tenzo.
[http://en.wikipedia.org/wiki/Tenzo](http://en.wikipedia.org/wiki/Tenzo)
Understand that you have responsibilities and that you must work hard, both
for you and for the others.

In short, i think these are the requirements to be a good programmer (as well
as a good professional in general).

------
tux
"It's a documentary on a 85 year old man named Jiro who has spent 75 years of
his life learning to make sushi."

Good programmers never stop learning. If you have ability to learn on your own
this is the only skill you will ever need. Everything else comes naturally.

------
kriro
I had an interesting debate with a coworker the other day. We were talking
about HS level students and how to get them interested in programming and what
skills they might find useful along the way.

I used to be in the "math all day every day" camp. My perspective has shifted
quite a bit. For non-English speaking countries my recommendation would
be...English. It's pretty shocking how many HS students are taught and/or
write code in German here.

Learn to think/communicate in English as quickly as possible and learn good
search/selflearning skills would be my #1 recommendation. Followed by "work
with other people as much as possible, especially if what they do is kind of
strange for you (artists etc.)"

It's not really mastering your craft and more base level but you have to start
somewhere.

------
illicium
JIRA Dreams of Issues

Jokes aside, most of the skill required to be a good programmer is independent
of the tools used.

------
devnonymous
Like others have said -- ability to type without waiting any mental effort in
the process and reading a lot of code helps.

However, I'd like to stree the one thing that most programmers ignore or worse
still are unawre of -- Programming is _NOT_ like making sushi simply because
it is __NOT __a singular, individual effort. Programming is a _social_
activity, even if you never ever meet another developer in person -- coding is
communication -- it is communicating the the authors of libraries and tools
using the APIs and interfaces that they have created ...while also creating
your own 'story/conversation/...can't find the word for it'

To repeat the Hal Abelson quote in the context of what I am saying:

    
    
      > Programs must be written for people to read, and only incidentally for machines to execute.
    

Unlike sushi making, programmers collaborate. They build on top of each others
work. So in this context, another skill that's extermely important to
cultivate as a programmer is the ability to communicate intent both via code
(ie: modularity, good stucture, good variable names ...etC) and otherwise
(documentation, following standards so that you don't surprise your 'users'
\-- who could also mean other developers, ..etc) are important as well.

So, on a higher level than specific skill, I'd urge you to stop thinking of
programming as a sole activity that you indulge in. A lot of good programming
advice (like the quote above or the robustness principle[1] or 'There are two
ways of constructing a software design: One way is to make it so simple that
there are obviously no deficiencies and the other way is to make it so
complicated that there are no obvious deficiencies.') when seen in the light
of a 'more-than-one-person' activity suddenlly make a whole lot of more good
sense.

Ok, I think the point is made. :-)

[1] Be conservative in what you do, be liberal in what you accept from others
[http://en.wikipedia.org/wiki/Robustness_principle](http://en.wikipedia.org/wiki/Robustness_principle)

~~~
TbobbyZ
Would it be fair to say that he collaborates with the 5-6 chefs he is over? I
believe in the documentary he says his team does 95% of the work before he
makes the dish in front of the customers. In addition, that 95% they are doing
he taught them how to do.

~~~
eswat
Right. In the documentary’s case you can see multiple people contributing to
then end product: one will head to the market to gather the fish, one to cook
the rice, one to massage the meat if needed, one to smoke the meat if needed,
etc. Even in simple take-out sushi restaurants there’s usually a lot of moving
parts behind the scenes, far from an individual effort. Just that one person
will end up assembling the pieces into a final product in the end.

------
bitwize
An absolute prerequisite for learning to program is the capability to reason
about causes and effects -- both forwards (determining what the effect of a
particular statement would be) and backwards (creating a list of candidates
for what may have caused a particular observed effect). All else -- design,
architecture, algorithm complexity, debugging -- follows from this. And it is
a rare skill. Cultivate it in yourself and you will go far.

------
hwang89
Macbook Air:
[https://www.youtube.com/watch?v=GkMp6B4s2K8](https://www.youtube.com/watch?v=GkMp6B4s2K8)

------
flohofwoe
A bit dull, but the ability to take a vaguely described problem, turn this
vague description into a clear definition, split it into smaller problems,
prioritize, and stay on the task until it is done. Don't have your head in the
clouds, don't leave a trail of unfinished projects behind you, write code that
you're proud of, practice the art daily.

------
CmonDev
Is it even comparable? As a developer I can create my own languages and tools.
As a sushi chef you cannot genetically engineer new kinds of fish - only new
combinations of existing stuff. Don't forget that programming is not a craft,
art, or science. It's a combination of all. Sushi making is lacking the
science component.

------
BmoreDaniel
The most important skill for a programmer is to learn to think before you
code: [http://www.wired.com/2013/01/code-bugs-programming-why-we-
ne...](http://www.wired.com/2013/01/code-bugs-programming-why-we-need-specs/).

------
eikenberry
You don't get it. It is not about if there are some tools that are better for
his vision or not. Each artist is different. It is what facilitates the
vision, your vision. What tools best allow you to express it, those are the
ones to focus on.

------
Beltiras
Self-critical thinking. If you can't attack your own work with the same
passion as if it were a creation of your worst enemy then you will build
things that will break easily.

------
vacri
People skills. Unless you're solely writing for yourself, you will be making
software either for people or with people.

------
taphangum
Determination to solve problems, and the willingness to stay with them until
they are solved.

------
LarryMade2
Purest skills - I will be more rudimentary

Curiosity

Problem-Solving

Tenacity

a Good Memory

Everything else is learned, but those innate skills will get you there.

------
benhamner
Communication. Excellent and precise communication.

------
droopyEyelids
Jiro would probably read -a lot- of documentation.

~~~
lgas
I doubt that, but I suspect he would read a lot of code.

------
needs
Jiro would practice and be _simply_ pragmatic.

------
neduma
Jiro dreams of Sushi - Available in Netflix

~~~
greenyoda
And Amazon Prime video. Well worth watching (especially if you like sushi).

~~~
frozenport
Don't forget the Pirate Bay!

------
Hz8NSD
Enjoy the progress of making something.

------
pknerd
Problem Solving skills.

------
therealunreal
Analytical thinking.

------
dqdo
Curiosity

------
dwarman
Stay awake, pay attention, and love what you do.

Clearly, everyone commenting here must be doing so from the position of
believing themselves to be good programmers with pure skill sets already in
place. I have to include myself in that assessment, of course. But, note how
we are all a little different. Or a lot. So I agree with those who emphasize
attitude, although even in that there is a lot of wiggle room. What we have
are anecdotes, not prescriptions - we can tell our stories but you know,
really, everyone's path to mastery will be different. Different drives,
different talents, different happy accidents. But, much time, much dedication,
much passion, and not only freedom from the fear of making mistakes but
rejoicing in them - opportunities for learning, and the shorter term the joys
of debugging and problem solving.

For, if one does not love the journey for itself, one will never stay the
course.

For myself, I fell into computers as a career entirely by accident, aided by a
perceptive girlfriend's advice when I was down and out as a 2nd year Physics
undergrad in 1967, forced to drop out by family issues. No degree, 19 years
young, and basically a C student. She suggested I seek a job as a programmer.

Not surprisingly, none of the big 5 were particularly interested despite my
perfect scores on their aptitude tests. (? what ?). But one passed me on to a
different track at a sister company, and to my great surprise they hired me on
the spot to debug their computers as they came out of manufacturing. I have no
idea what they saw in me, but it was a revelation. I could do it. From day
one. Room sized hand built discrete component monsters. Elliott 4100 series.

And ever since, that job included, I have always been surprised that people
want to actually pay me to do what I love, and to ride out those unpredictable
deep thought intermissions when nothing apparent is happening with me. That I
am still fully employed, at senior technical levels, is I think a token of how
I am perceived, and I take it t be my qualification for commenting here.

So. Passion. Joy of challenges. Endurance, persistence, and open to the luck
of the draw wrt career path (mine looks like a classical Drunkards Walk -
transistors to pixels, ALU to 4G graphical language design). Always learning,
always doing new stuff, always going where no-one has gone before - and short
of an academic career this pressing out on the boundaries has to be pretty
special to computers.

And the tools. The original question. There is no prescriptive answer to that
one. For every project, often even every phase, there are new things to learn
and invent, and the invention part usually has to include custom tools. And,
personally, I gave up learning the current technological SOA in tools just for
the learning, because typically by the time they became the right one for a
new task they were already outmoded and something else was in vogue. So my
tool focus is whatever helps me do the work right now. Picking new tools and
technology up quickly are the key. And I don't think that can be taught. It is
one's mental toolkit that is the key, one's habits and tricks of thought and
problem solving in their most abstract meanings. And I believe only love of
the work brings those forth. Because we are all wired differently, some more
differently than others, and we all have different satori moments which result
in the laying down of the memes of Mind that shape those tools.

In short, stay awake, and pay attention, and love what you do. The rest will
take care of itself.

Oh, yes, one more thing. Think of the poor folks who have to maintain what you
did after you have moved on. Or, as was my painful jab for this, even if it is
yourself six months later. Style is a tool unto itself.

------
jimminy
The first step is defining the goals/requirements of being a programmer. The
generality of such a question makes any answer hard, and likely cause one to
stray from the core. I will try to keep what follows pure as possible, and
disregard specific skills required for web development vs. low-level systems
vs application development, etc.

Having watched Jiro Dreams Of Sushi, his task is to provide excellence in
food, in service, and overall experience. And at the root he needs to
understand each component of the food and the service intimately, so that he
can put them together in a way that is both pleasurable and fitting to the
customer. He uses what he knows and the resources he has to create the best
dishes he can.

For a programmer, the core of our trade is algorithms, and their combinations.
You may not need to know them at the smallest details, or even that they are
called algorithms, but to accomplish anything you will use them. Combining
larger programs together in a specific way to perform something novel is an
algorithm, though we may not call it that.

Next, data structures, understanding how to store information in a way that
your algorithms can use and alter. This underlying knowledge is key to
creating larger things from many small things.

Next, simplicity, combining logic and code together to accomplish the goals
alone is not enough. While it may be simple to combine large things together,
the question should exist of whether it could be done more simply. Simplicity
can be hard to accomplish, but is easy to appreciate. Simplicity means
avoiding cleverness, if possible, as it can make the program hard to be
changed or maintained. Simplicity is elegant refinement, which leads to doing
small things very well.

Those three things, in my mind, are the only pure things necessary to being a
programmer. Algorithms, data structures, and simplicity.

The reasons none of the other things apply in my mind to the overly-general
title of just programmer is that they are not required by every programmer.

Text Editor - Cannot pen and paper be used just as well in the task of
constructing a program as a text edit?

Programming Language - Maybe I could have leniency here, you do need language
to describe yourself, but not necessarily a programming language.

Databases - This is much higher-level than a regular data-structure, and as
such isn't a necessity. Applies more to specific fields.

Algorithms - Yes, even if not known by name.

Math - This isn't a requirement, though it is a nicety. Some get by without
knowing much more than the very basics of Arithmetic and maybe a little basic
Algebra. It applies more to specific fields.

Debugging & Testing - These aren't necessary, but they help ensure quality or
finding issues.

Documentation/Comments - If the code is simple enough, it should describe
itself. That isn't to say documentation and comments aren't important, but
they aren't necessities either. You should describe as much in comments and
documentation as necessary, to provide clarity and usable instruction, and is
a great skill to have.

I hope I've explained things clearly enough. Knowing one's craft is
understanding the fundamentals, and that comes much further ahead of the tools
one uses, within reason. In my opinion the single best thing for describing
the craft of programming is the Unix Philosophy[1].

[1]:
[http://en.wikipedia.org/wiki/Unix_philosophy](http://en.wikipedia.org/wiki/Unix_philosophy)

