Teach Yourself Programming in 10 Years.(norvig.com)
norvig.com
Teach Yourself Programming in 10 Years.
http://www.norvig.com/21-days.html
32 comments
This is offtopic, but: why / how do you find so many duplicate articles? When I saw that this was posted, I was immediately pretty sure you'd leave a comment linking to past posts. Are you doing this manually, or do you have a script (that, e.g., checks the 'new' page and searches for the title and URL on searchyc?)
Why and how are different. "Why" is because I prefer to see discussions linked together rather than spread. In this case there is some previous discussion (although not a lot) and anyone coming across this and finding it interesting might find the previous discussion worth reading also. They could search for it themselves, but it's easy for me to do, and one person's work (mine) saving lots of people work seems a good trade-off.
"How" is different. I just tend to remember stuff like this easily, so I know if something's duplicated. A quick search will usually find it, and that often turns up other stuff that I find interesting in its own right. I haven't scripted this, I just remember stuff.
That also feeds back into the "Why." I've found many things of value (to me) on HN because an article that was vaguely interesting prompted a search for an earlier duplicate, and that search turned up related, more interesting material. Having found any duplicates I then put in the comment to help save other people some time because, well, why not?
However, I'm pretty much considering stopping. Although I'm not really bothered about karma, the recent instance of PG linking the ability to vote to one's average karma has made me re-evaluate what I'm doing. Although it's only approximate, clearly "karma" embodies an indication of the behavior PG wants. Flagging duplicates like this drags down my average karma because it rarely gets up-voted and occasionally gets down-voted. That suggests that, in some sense, PG doesn't want me to do it, even if I think it saves people time and helps to cross-connect related discussions.
If you'd like to discuss this more, feel free to email me.
"How" is different. I just tend to remember stuff like this easily, so I know if something's duplicated. A quick search will usually find it, and that often turns up other stuff that I find interesting in its own right. I haven't scripted this, I just remember stuff.
That also feeds back into the "Why." I've found many things of value (to me) on HN because an article that was vaguely interesting prompted a search for an earlier duplicate, and that search turned up related, more interesting material. Having found any duplicates I then put in the comment to help save other people some time because, well, why not?
However, I'm pretty much considering stopping. Although I'm not really bothered about karma, the recent instance of PG linking the ability to vote to one's average karma has made me re-evaluate what I'm doing. Although it's only approximate, clearly "karma" embodies an indication of the behavior PG wants. Flagging duplicates like this drags down my average karma because it rarely gets up-voted and occasionally gets down-voted. That suggests that, in some sense, PG doesn't want me to do it, even if I think it saves people time and helps to cross-connect related discussions.
If you'd like to discuss this more, feel free to email me.
To allay your concerns, I almost always upvote links to previous submissions on HN. I make them, and find such links valuable, so I upvote them when someone else makes them.
P.S. I find the best way to find previous HN threads that I remember is a site-restricted Google search with a few keywords, e.g.,
http://www.google.com/search?q=site%3Anews.ycombinator.com+p...
P.S. I find the best way to find previous HN threads that I remember is a site-restricted Google search with a few keywords, e.g.,
http://www.google.com/search?q=site%3Anews.ycombinator.com+p...
"... I find the best way to find previous HN threads that I remember is a site-restricted Google search ..."
Way better ~ http://searchyc.com/previously+submitted?sort=by_date
Way better ~ http://searchyc.com/previously+submitted?sort=by_date
I find both Google and searchyc useful. When one doesn't find what I'm looking for, the other usually does.
I make a practice of executing such a search before I submit a link. Of course, for me it's a VERY occasional practice. ;-)
Separately, would it be useful if HN had a sort presentation that listed posts/threads recently commented upon -- perhaps further weighted by post score -- as opposed to just recent comments (where the quantity combined with flatness of presentation quickly overwhelms me)? Of course, one would have trouble finding the new comment within the old thread -- particularly active ones -- unless there was further utility added to locate it within the thread of conversation of such a post. (If it was in response to a parent comment, it would not sort to the top.)
At which point, the current presentation paradigm for the site is starting to change significantly. Representing both a lot of work for PG, and an open-ended question as to the effects upon the community dynamics.
So... perhaps we are better off with what we have. If a page/topic is brought up again after after a significant period of time (more than a few days), it is handled as a new discussion. With thoughtful people like Rider... perhaps citing older posts/threads for further reference.
Separately, would it be useful if HN had a sort presentation that listed posts/threads recently commented upon -- perhaps further weighted by post score -- as opposed to just recent comments (where the quantity combined with flatness of presentation quickly overwhelms me)? Of course, one would have trouble finding the new comment within the old thread -- particularly active ones -- unless there was further utility added to locate it within the thread of conversation of such a post. (If it was in response to a parent comment, it would not sort to the top.)
At which point, the current presentation paradigm for the site is starting to change significantly. Representing both a lot of work for PG, and an open-ended question as to the effects upon the community dynamics.
So... perhaps we are better off with what we have. If a page/topic is brought up again after after a significant period of time (more than a few days), it is handled as a new discussion. With thoughtful people like Rider... perhaps citing older posts/threads for further reference.
What I don't understand (coming from communities where duplicate posts are simply killed) is why this manner of handling is favored. I do understand that the community cycles in more people who haven't seen all the older links, and so it's nice to present them again for their sake every once in a while. However, if that's the goal, why start with a fresh discussion thread every time? Why not just put the old one on the front page again, together with the discussion attached to it? Presumably the comments haven't rotted.
With new times come new perspectives. The downside is that new people don't know that the same-old, same-old points have already been made argued to death already. But what if they have a new insight, or times have changed and the old ideas are no longer relevant? If they see pages of discussion, they might be suckered into thinking their new thoughts are irrelevant, when the opposite may be true.
In general, I like starting over with a blank page if enough time has passed that we will have new faces and changed circumstances. Two weeks is not enough, but a blog post from two years ago might be interesting to re-examine with fresh eyes.
In general, I like starting over with a blank page if enough time has passed that we will have new faces and changed circumstances. Two weeks is not enough, but a blog post from two years ago might be interesting to re-examine with fresh eyes.
I think that a site like HN works best if you do what you think is right and ignore what PG wants on a case-by-case basis. If overall your actions are getting downvoted, then clearly there is a fit problem between you and HN, and either you must change, HN must change, or you should go elsewhere.
However if overall you are getting positive karma, then overall there is a good fit and don't worry about the odd bit of behaviour that gets negative karma. Unless it's something specifically discouraged, I think you should let it slide.
FWIW, I don't think karma reflects utility for something like this. I just saw someone post "[2005]" as a comment on another post, and it got some upmods. Obviously that's helpful in a certain way, but I didn't bother to upmod it myself. That doesn't mean I don't appreciate it.
So... tl;dr; version: Rock on!
However if overall you are getting positive karma, then overall there is a good fit and don't worry about the odd bit of behaviour that gets negative karma. Unless it's something specifically discouraged, I think you should let it slide.
FWIW, I don't think karma reflects utility for something like this. I just saw someone post "[2005]" as a comment on another post, and it got some upmods. Obviously that's helpful in a certain way, but I didn't bother to upmod it myself. That doesn't mean I don't appreciate it.
So... tl;dr; version: Rock on!
Because you're considering stopping, I wanted to say that I find this sort of post very helpful. Many times I've found much more interesting discussion on previous submissions because of you, or learned something I otherwise would have missed. My upvotes apparently are discarded by PG's algorithm, but if I could I would contribute karma - this is behavior I greatly appreciate and would like to support.
Thank you. Comments like yours, and all the upvotes for the discussion, are being taken into consideration, and your feedback is appreciated. If you had an email address in your profile I'd've said so directly.
>> Why is everyone in such a rush?
Because everybody has different goals. Although many programmers seek to become masters of their craft, I suspect many more look at programming as a tool to be used in furthering some other pursuit. Those who see it as a tool are understandably better-served by "Learn C Before Dinner!" books than they are by a 10-year program.
This reality may be frustrating to experienced coders. It results in legions of sloppy programmers producing piss-poor code. It is, however, reality. And I'm not sure it's such a bad thing. Most of the people I interact with don't know a thing about computers -- I'm pleasantly surprised when I talk to someone who's had a run-in with some programming, no matter how brief.
Because everybody has different goals. Although many programmers seek to become masters of their craft, I suspect many more look at programming as a tool to be used in furthering some other pursuit. Those who see it as a tool are understandably better-served by "Learn C Before Dinner!" books than they are by a 10-year program.
This reality may be frustrating to experienced coders. It results in legions of sloppy programmers producing piss-poor code. It is, however, reality. And I'm not sure it's such a bad thing. Most of the people I interact with don't know a thing about computers -- I'm pleasantly surprised when I talk to someone who's had a run-in with some programming, no matter how brief.
If you are not interested in learning how to do it properly, then hire someone who is. Failing that, do not attempt to do it in C.
I agree with this being reposted occasionally, as its lessons are fresh to newcomers.
Several of the other comments reference useful books on the topics, particularly on algorithms. One book that has a lot of important lessons about becoming a good programmer is Coders at Work.
One of the interviews is with Peter Norvig who tells about a bloggers failed attempt at solving sudoku. Peter's solution used a very novel approach to the problem that is non-obvious, and I would put this in the category of what you can learn from studying algorithms. They are not all about reducing computational complexity. Perhaps the other extreme example is an epic stack overflow answer that repeats many times that you can't use regular expressions to properly parse html. And this keeps coming up, it seems.
And I found the lessons in Coders at Work somewhat startling. I recommend it to new programmers and old programmers alike. It's not about the IDE, it's not about the language, it's not about the testing.
Several of the other comments reference useful books on the topics, particularly on algorithms. One book that has a lot of important lessons about becoming a good programmer is Coders at Work.
One of the interviews is with Peter Norvig who tells about a bloggers failed attempt at solving sudoku. Peter's solution used a very novel approach to the problem that is non-obvious, and I would put this in the category of what you can learn from studying algorithms. They are not all about reducing computational complexity. Perhaps the other extreme example is an epic stack overflow answer that repeats many times that you can't use regular expressions to properly parse html. And this keeps coming up, it seems.
And I found the lessons in Coders at Work somewhat startling. I recommend it to new programmers and old programmers alike. It's not about the IDE, it's not about the language, it's not about the testing.
I realised last night that I've actually been programming for almost 10 years now.
And you know; Im still going to be learning something in another 10 years. I think that's a really good thing.
And you know; Im still going to be learning something in another 10 years. I think that's a really good thing.
or you can take a algorithm class and become one within 2 years, as somebody once stated ;)
I don't think it works quite like that.
When I got my first programming job, straight out of high school, I finished tasks in 2 days that took the other programmers there 4 months. I figured that if I was that much faster than them, I ought to be able to become a world-class programmer in just a couple years (or more accurately, I thought I could become a world-class physicist in my 4 years of college and then a world-class programmer in the 2 years afterwards).
So I resolved to take all the shortcuts I could. I'd read all the classic books in the field and learn from those with more experience than me. I'd take internships with experienced, accomplished programmers and pick their brains for everything I could. I'd take on volunteer coding tasks so I could get some experience building things on my own. I'd cherry-pick all the tough courses at college so I got the best part of a CS degree without having to sit through stuff I already knew.
I did all that. I've read all the classic CS books - GoF patterns, Mythical Man Month, Extreme Programming stuff, Pragmatic Programmer, Knuth, SICP, TAPL, Dragon Book, On Lisp, etc. I've worked with programmers that wrote large chunks of curses, Rogue, vi, Jini, JavaSpaces, HotSpot, Gallery, Stratus, Equalogic, DEC compilers, Python, Google, and a bunch of other projects they don't brag about. I wrote Amherst's course-evaluation system, and rewrote the software for a 100k-user site, and wrote one of the front-page hits for [haskell tutorial]. I have that CS degree, and aced the algorithms class of which you speak, and took compiler design and OS and computer graphics too.
It's been 9.5 years since that first programming job, and it still feels like I have a really long way to go before I'm actually a world-class programmer.
The part I didn't realize, in my youthful arrogance, was that I was comparing myself to the wrong people. When Norvig tells you how to become a programmer in 10 years, he's assuming you're already taking all the shortcuts you can. It still takes 10 years. Most of the people you'll meet straight out of high school, or in most colleges, or in random companies, will never become programmers in the sense that Norvig's talking about. Eventually they'll give up trying, and start grumbling on Reddit about how the software industry is mostly boring cubicle farms where they push around Enterprise JavaBeans and never use the algorithms that they learned in college.
When I got my first programming job, straight out of high school, I finished tasks in 2 days that took the other programmers there 4 months. I figured that if I was that much faster than them, I ought to be able to become a world-class programmer in just a couple years (or more accurately, I thought I could become a world-class physicist in my 4 years of college and then a world-class programmer in the 2 years afterwards).
So I resolved to take all the shortcuts I could. I'd read all the classic books in the field and learn from those with more experience than me. I'd take internships with experienced, accomplished programmers and pick their brains for everything I could. I'd take on volunteer coding tasks so I could get some experience building things on my own. I'd cherry-pick all the tough courses at college so I got the best part of a CS degree without having to sit through stuff I already knew.
I did all that. I've read all the classic CS books - GoF patterns, Mythical Man Month, Extreme Programming stuff, Pragmatic Programmer, Knuth, SICP, TAPL, Dragon Book, On Lisp, etc. I've worked with programmers that wrote large chunks of curses, Rogue, vi, Jini, JavaSpaces, HotSpot, Gallery, Stratus, Equalogic, DEC compilers, Python, Google, and a bunch of other projects they don't brag about. I wrote Amherst's course-evaluation system, and rewrote the software for a 100k-user site, and wrote one of the front-page hits for [haskell tutorial]. I have that CS degree, and aced the algorithms class of which you speak, and took compiler design and OS and computer graphics too.
It's been 9.5 years since that first programming job, and it still feels like I have a really long way to go before I'm actually a world-class programmer.
The part I didn't realize, in my youthful arrogance, was that I was comparing myself to the wrong people. When Norvig tells you how to become a programmer in 10 years, he's assuming you're already taking all the shortcuts you can. It still takes 10 years. Most of the people you'll meet straight out of high school, or in most colleges, or in random companies, will never become programmers in the sense that Norvig's talking about. Eventually they'll give up trying, and start grumbling on Reddit about how the software industry is mostly boring cubicle farms where they push around Enterprise JavaBeans and never use the algorithms that they learned in college.
> It's been 9.5 years since that first programming job, and it still feels like I have a really long way to go before I'm actually a world-class programmer.
It's interesting how as we get more experience, we become a more aware of the shortcomings of our knowledge and skill. It's been ~9.5 years for me as well (took an systems/ops job that involved a great deal of programming in Nov 2000 as a junior in HS, was "writing code" before that) and I'm only now learning how much more there is for me to learn.
It's interesting how as we get more experience, we become a more aware of the shortcomings of our knowledge and skill. It's been ~9.5 years for me as well (took an systems/ops job that involved a great deal of programming in Nov 2000 as a junior in HS, was "writing code" before that) and I'm only now learning how much more there is for me to learn.
Which topics in programming interest you now?
Professionally, I've been doing mostly web UIs, bunch of JavaScript. Personally - I've always had a fondness for programming language design, theory, and implementation and (naturally) am working on my own compiler. I've also picked up a bit of an interest in machine learning and distributed processing, mostly because of where I work now.
You certainly should take an algorithm class (better yet, two) and/or work through -- including the homework problems -- two to three algorithm text books (I highly suggest Knuth's TAOCP, CLRS and Steve Kiena's Algorithm Design Manual). However, after that, you will:
* Become more aware of the shortcomings of your knowledge of algorithms (both directly -- algorithms which you don't yet know/understand and indirectly -- algorithms which don't yet exist). That's a huge benefit.
* Learn a bit the analysis of algorithms and how to prove an algorithm correct
* Learn a bit about algorithm design
* Most importantly, you will learn about classes of problems, classes of algorithms and several implementations of these classes of algorithms. You will be able to reason from "real world problem" to "falls under these classes of problems" to "solvable by these algorithms" and then apply an instance of an algorithm to the problem.
You will not become an algorist (that would take its own ten years), nor will you become a programmer. It will certainly help you become a programmer, but there's more to programming than algorithms.
That being said, there's a path to be crossed. At one stage one thinks that writing graphical demos in assembly or (depending on the decade) web apps backed by databases is the "golden nugget" of programming. Then there's the road through learning algorithms, data structures and non-imperative programming languages, which is culminates in writing your own compiler (or any other project which requires a great deal of coding and puts together data structures, algorithms, hardware/OS knowledge, theoretical CS knowledge e.g. automata and language theory). There's a lot more that follows until one becomes a great programmer, but I can't tell you what those "milestones" are, as I am not there yet.
* Become more aware of the shortcomings of your knowledge of algorithms (both directly -- algorithms which you don't yet know/understand and indirectly -- algorithms which don't yet exist). That's a huge benefit.
* Learn a bit the analysis of algorithms and how to prove an algorithm correct
* Learn a bit about algorithm design
* Most importantly, you will learn about classes of problems, classes of algorithms and several implementations of these classes of algorithms. You will be able to reason from "real world problem" to "falls under these classes of problems" to "solvable by these algorithms" and then apply an instance of an algorithm to the problem.
You will not become an algorist (that would take its own ten years), nor will you become a programmer. It will certainly help you become a programmer, but there's more to programming than algorithms.
That being said, there's a path to be crossed. At one stage one thinks that writing graphical demos in assembly or (depending on the decade) web apps backed by databases is the "golden nugget" of programming. Then there's the road through learning algorithms, data structures and non-imperative programming languages, which is culminates in writing your own compiler (or any other project which requires a great deal of coding and puts together data structures, algorithms, hardware/OS knowledge, theoretical CS knowledge e.g. automata and language theory). There's a lot more that follows until one becomes a great programmer, but I can't tell you what those "milestones" are, as I am not there yet.
There's more to good code than algorithms. I really don't understand why some people in the HN community continually overstate the importance of algorithms. This is about the last place on the internet you need to go convincing people algorithms are cool.
Yes, algorithms are great. They are not everything, however.
Taking an algorithms class will only elevate you above some very basic mistakes. It will not make you an expert. Also not all algorithms professors are Knuth. I've seen the code of the ones who think that study of algorithms is sufficient to know programming and it's not pretty.
Yes, algorithms are great. They are not everything, however.
Taking an algorithms class will only elevate you above some very basic mistakes. It will not make you an expert. Also not all algorithms professors are Knuth. I've seen the code of the ones who think that study of algorithms is sufficient to know programming and it's not pretty.
I fully agree with this. Far more important to me than a great algorithm is readable, maintainable, and well-structured code.
If your algorithms suck but your code is readable, maintainable, and well-structured, it'll be a lot easier to find someone who has a better knowledge of algorithms to come fix it. While, if your code is unreadable, unmaintainable, and/or poorly structured but has great algorithms, you'll have a much harder time finding someone to fix it (or even fixing it yourself).
Here's what Rob Pike had to say on the role of algorithms in programming (from the recent HN submission on the Basics of Unix Philosophy http://www.faqs.org/docs/artu/ch01s06.html )
"Rule 3. Fancy algorithms are slow when n is small, and n is usually small. Fancy algorithms have big constants. Until you know that n is frequently going to be big, don't get fancy. (Even if n does get big, use Rule 2 first.)
Rule 4. Fancy algorithms are buggier than simple ones, and they're much harder to implement. Use simple algorithms as well as simple data structures.
Rule 5. Data dominates. If you've chosen the right data structures and organized things well, the algorithms will almost always be self-evident. Data structures, not algorithms, are central to programming."
If your algorithms suck but your code is readable, maintainable, and well-structured, it'll be a lot easier to find someone who has a better knowledge of algorithms to come fix it. While, if your code is unreadable, unmaintainable, and/or poorly structured but has great algorithms, you'll have a much harder time finding someone to fix it (or even fixing it yourself).
Here's what Rob Pike had to say on the role of algorithms in programming (from the recent HN submission on the Basics of Unix Philosophy http://www.faqs.org/docs/artu/ch01s06.html )
"Rule 3. Fancy algorithms are slow when n is small, and n is usually small. Fancy algorithms have big constants. Until you know that n is frequently going to be big, don't get fancy. (Even if n does get big, use Rule 2 first.)
Rule 4. Fancy algorithms are buggier than simple ones, and they're much harder to implement. Use simple algorithms as well as simple data structures.
Rule 5. Data dominates. If you've chosen the right data structures and organized things well, the algorithms will almost always be self-evident. Data structures, not algorithms, are central to programming."
Who said that algorithms are everything? No, of course they are not. In C-languages you have about 50% memory management, then you have code architecture. But algorithms are the very heart of programming, and the most important topic. Look, if you have the algorithm to carry out a task, then its just a question whether you have the tools to accomplish it, and if you know your tools to do it. The latter could be the equivalent of knowing your programming language.
A knowledge of algorithms doesn't teach you to pick the right problems to solve.
Once you get it down into problems like "sort this list" the code practically writes itself and the correct algorithms are simple to determine. Figuring out how to take a complex problem and break it down into problems that you then can throw your algorithm knowledge at is a whole art that takes years of study. A firm grasp of algorithms is essential but not sufficient and it can only help inform your decisions, not provide firm answers.
Picking the right problems is the heart of programming. Figuring out which algorithm to throw at a sub-problem is the heart of contract work.
Once you get it down into problems like "sort this list" the code practically writes itself and the correct algorithms are simple to determine. Figuring out how to take a complex problem and break it down into problems that you then can throw your algorithm knowledge at is a whole art that takes years of study. A firm grasp of algorithms is essential but not sufficient and it can only help inform your decisions, not provide firm answers.
Picking the right problems is the heart of programming. Figuring out which algorithm to throw at a sub-problem is the heart of contract work.
"A knowledge of algorithms doesn't teach you to pick the right problems to solve."
That is true. To create a application, one needs a Use Case. A Use Case will provide the most abstract solution to what the app will be doing. Then you can take the top down design approach, by dividing the Use Case into a several abstract sub problems. That is known as code architecture and belongs to System Engineering. The System Engineer needs a domain-expert help to identify what problems that needs to be solved.
Then..
Programming is carrying out those abstract sub-problems (interfaces) to become a concrete solution using a specific programming language. To complete such a task, one needs a person that knows his/hers algorithms design techniques, sorting, searching, string processing, graph problems, combinatorial problems, geometric problems and numerical problems. And lastly, the analysis of the respective algorithms.
Once you know what to solve, its just a matter of being able to carry out the task.
I think you might have confused the programmers job with the job of actually creating the entire software - which in general terms is non-sense. To sum up:
The software engineer (the project lead) takes care of identifying the sub-problems, after creating the Use Case with the domain expert (often the customer).
The programmer solves those sub-problems bottoms up, by focusing on creating the atomic parts as efficient as possible.
That is true. To create a application, one needs a Use Case. A Use Case will provide the most abstract solution to what the app will be doing. Then you can take the top down design approach, by dividing the Use Case into a several abstract sub problems. That is known as code architecture and belongs to System Engineering. The System Engineer needs a domain-expert help to identify what problems that needs to be solved.
Then..
Programming is carrying out those abstract sub-problems (interfaces) to become a concrete solution using a specific programming language. To complete such a task, one needs a person that knows his/hers algorithms design techniques, sorting, searching, string processing, graph problems, combinatorial problems, geometric problems and numerical problems. And lastly, the analysis of the respective algorithms.
Once you know what to solve, its just a matter of being able to carry out the task.
I think you might have confused the programmers job with the job of actually creating the entire software - which in general terms is non-sense. To sum up:
The software engineer (the project lead) takes care of identifying the sub-problems, after creating the Use Case with the domain expert (often the customer).
The programmer solves those sub-problems bottoms up, by focusing on creating the atomic parts as efficient as possible.
"The software engineer (the project lead) takes care of identifying the sub-problems, after creating the Use Case with the domain expert (often the customer).
The programmer solves those sub-problems bottoms up, by focusing on creating the atomic parts as efficient as possible."
This is how yucky enterprise monstrosities get built. The "software engineer"/programmer division is nonsensical and sounds like something one would find in Wipro or Accenture, not so much at (say) Google or Facebook.
"I think you might have confused the programmers job with the job of actually creating the entire software - which in general terms is nonsense."
:-D .
The term you are looking for (since you seem to be fond of labels to sratify coders), for people who just implement whatever their "lead" tells them to is "code monkey".
The programmer solves those sub-problems bottoms up, by focusing on creating the atomic parts as efficient as possible."
This is how yucky enterprise monstrosities get built. The "software engineer"/programmer division is nonsensical and sounds like something one would find in Wipro or Accenture, not so much at (say) Google or Facebook.
"I think you might have confused the programmers job with the job of actually creating the entire software - which in general terms is nonsense."
:-D .
The term you are looking for (since you seem to be fond of labels to sratify coders), for people who just implement whatever their "lead" tells them to is "code monkey".
Then please tell me how software gets built. Provide me with a methodology, instead of being a arrogant fool like you are now.
Yes, a code monkey is a term I'm familiar with. But you need good communication skills too.
Yes, a code monkey is a term I'm familiar with. But you need good communication skills too.
I focused on algorithms in grad school and I've had some kind of programming job for (fuck) 12 years now, so I guess I'm nearly in programming puberty. I believe algorithms touches on something fundamental and provides a foundation that cannot be avoided. However, a house is more than the foundations. Algorithms does not touch on any engineering issues like software maintenance, productively achieving a goal (you can spend your life on interesting tangents) or (generally) performance of systems as a whole.
He addresses the topic of "book learning" explicitly in the post.
If you want, put in four years at a college (or more at a graduate school). This will give you access to some jobs that require credentials, and it will give you a deeper understanding of the field, but if you don't enjoy school, you can (with some dedication) get similar experience on the job. In any case, book learning alone won't be enough. "Computer science education cannot make anybody an expert programmer any more than studying brushes and pigment can make somebody an expert painter" says Eric Raymond, author of The New Hacker's Dictionary. One of the best programmers I ever hired had only a High School degree; he's produced a lot of great software, has his own news group, and made enough in stock options to buy his own nightclub.
If you want, put in four years at a college (or more at a graduate school). This will give you access to some jobs that require credentials, and it will give you a deeper understanding of the field, but if you don't enjoy school, you can (with some dedication) get similar experience on the job. In any case, book learning alone won't be enough. "Computer science education cannot make anybody an expert programmer any more than studying brushes and pigment can make somebody an expert painter" says Eric Raymond, author of The New Hacker's Dictionary. One of the best programmers I ever hired had only a High School degree; he's produced a lot of great software, has his own news group, and made enough in stock options to buy his own nightclub.
Is 10 years when the site comes up? 503 Unavailable.
Mentioned quite regularly: http://searchyc.com/teach+yourself+norvig+ten