Live data from Hacker News

Teach Yourself Programming in 10 Years.

norvig.com

21–30 of 33 posts

Re: Teach Yourself Programming in 10 Years.

#21
post #19

>> 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. I…

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.

Re: Teach Yourself Programming in 10 Years.

#23

Earlier quoted context omitted.

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 goo…

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.

Re: Teach Yourself Programming in 10 Years.

#24
post #2

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 worl…

Which topics in programming interest you now?

Re: Teach Yourself Programming in 10 Years.

#25

Earlier quoted context omitted.

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 worl…

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.

Re: Teach Yourself Programming in 10 Years.

#26
post #2

or you can take a algorithm class and become one within 2 years, as somebody once stated ;)

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 a…

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.

Re: Teach Yourself Programming in 10 Years.

#27
post #26

Earlier quoted context omitted.

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 a…

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 e…

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.

Re: Teach Yourself Programming in 10 Years.

#28
post #26

Earlier quoted context omitted.

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 e…

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…

"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.

Re: Teach Yourself Programming in 10 Years.

#29
post #2

or you can take a algorithm class and become one within 2 years, as somebody once stated ;)

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 a…

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."

Re: Teach Yourself Programming in 10 Years.

#30
post #28

Earlier quoted context omitted.

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…

"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 En…

"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".

Post reply on HN