Ask HN: The purest skills needed to become a programmer?
57 comments
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.
Enjoy the progress of making something.
Problem Solving skills.
Jiro dreams of Sushi - Available in Netflix
And Amazon Prime video. Well worth watching (especially if you like sushi).
Don't forget the Pirate Bay!
[deleted]
[deleted]
Jiro would probably read -a lot- of documentation.
I doubt that, but I suspect he would read a lot of code.
Macbook Air: https://www.youtube.com/watch?v=GkMp6B4s2K8
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.
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.
I.E Richard Stallman ?
We hosted R.S. at my school, he was less than pleasant. I feel like this is off topic however.
Yeah, well I think this is the confusion between "good" and "nice" again.
JIRA Dreams of Issues
Jokes aside, most of the skill required to be a good programmer is independent of the tools used.
Jokes aside, most of the skill required to be a good programmer is independent of the tools used.
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...
[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.)
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.)
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 ?
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 ?
Woah there, it doesn't take a year. It takes several hours to learn how to touch type slowly, the speed comes as you type every day - which you're going to do anyway. You will save time whenever you touch a keyboard for the rest of your life.
It may be true that thinking your code through takes a LOT longer than actually writing it. But: Beeing able to put a thought / idea (once it's there) to code very fast is helpful. At least I can't hold an complex idea in my head forever.
If someone is really good at 10 finger writing, he doesn't have to put thought / focus in the writing process itself. That frees him up for the thinking process.
Writing documentation is important too, and here speed can be helpful, too.
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)
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)
> 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.
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.
I'd say typing is probably the sill that's easiest to optimize.
Muphry's law strikes again :)
Muphry's law strikes again :)
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.
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.
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.
[deleted](1)
I can touch type and I have worked very hard to be a good typist. Having said that, I intentionally limit my typing to 30 wpm for several reasons. First, it has seriously helped RSI for me. About 15 years ago, I started to get warning signs that I was going to have problems. I slowed down and implemented short 2-3 second breaks every 30 or 40 seconds. I've been symptom free since then. YMMV.
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.
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 find typing speed by itself not something you explicitly need to `learn`. Any coder worth his salt would definitely have spent years typing in code which _should_ result in the coder having fast typing speed.
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.
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.
This is certainly "truer" for brainfuck and Java than for Haskell and clojure, especially if you don't have access to an IDE.
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!)
(I agree that accurate touch-typing doesn't hurt!)
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).
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).
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.
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.
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.
I think you're mixing cause with effect. Someone argued (can't find source now) that sth. similar to Moore's Law applies to programmers, their number doubles every year or two. Effectively, half of the programmers working now where not even employed two years ago.
Communication. Excellent and precise communication.
"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.
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.
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
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
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.)
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.)
Jiro would practice and be _simply_ pragmatic.
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.
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.
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:
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
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.
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
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.
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.
Develop a working methodology which works for you (and remember that new != better): 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 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).
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).
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.
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.
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.
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.
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....
[deleted]
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.
People skills. Unless you're solely writing for yourself, you will be making software either for people or with people.
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.
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.
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.
Curiosity
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.
Analytical thinking.
Determination to solve problems, and the willingness to stay with them until they are solved.
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.
Curiosity
Problem-Solving
Tenacity
a Good Memory
Everything else is learned, but those innate skills will get you there.
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