Ask HN: The purest skills needed to become a programmer?
Jiro lives a way of a shokunin which is
"defined by both Japanese and Japanese-English dictionaries as 'craftsman' or 'artisan,' 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/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's responsibility is to fulfill the requirement."- Tasio Odate
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.
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?
Here is a list I have so far:
-Text editor -A programming language -Databases -Algorithms -Math -Debugging -Tests -Writing Documentation/Comments
57 comments
[ 5.0 ms ] story [ 85.8 ms ] threadHe 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.
Jokes aside, most of the skill required to be a good programmer is independent of the tools used.
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...
[2] 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.)
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 ?
And 60wpm isn't that much. My impression is that some young people write that on their smartphone ;) (though definately you couldn't call that high accuracy)
I wouldn't necessarily recommend spending a year learning to type, but I would definitely recommend writing documentation as a process that will improve your code. Writing proper specifications, proposals, documentation, etc highlights problems amazingly well. I would argue that is what makes you a better coder, more than actually writing code, because explaining how your code works is the best way to see how your code could be improved.
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.
Muphry's law strikes again :)
To say that you need fast typing to be a good programmer feels like a reversal of cause and effect to me. IMO People should be taught to love coding, then they'll naturally pick up touch typing by themselves.
More importantly, when I intentionally slowed my typing my coding improved dramatically. I went from short bursts of thinking followed by short bursts of typing, to continuous thinking. I started thinking about things that I had never considered before. Since I had time, I started to wonder if what I was typing was really the best way to solve my problem.
When I am coaching others, especially junior people with only a couple of years under their belts, I tell them to slow down. Like you, I am a huge proponent of learning to touch type properly. You should practice and refine your technique. However, I highly recommend typing slowly, steadily and calmly.
(I agree that accurate touch-typing doesn't hurt!)
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).
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.
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.
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
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.)
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.
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:
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
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 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 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).
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.
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.