Fast Learning: Is it bad?

Question

As many of you must have noticed, learning to program is not an overnight thing, it takes years of hard work (I really should refer here to this wonderful article of Peter Norvig). But there's a lot you can do to make an impressive fast progress, you can use the online tutorials, websites like projecteuler or CodingBat, Stackoverflow help, or any other quickie stuff that can give you the ability to actually get something done... You may not need all the very basic things that you will get if you go to school or learn by some formal way. They might be skipped, and if nothing goes wrong, your work will be done without dealing with them (I'm not talking about making a kernel or some huge thing, but things like making a website, a program to sort files, basic database management scripting, or anything else that may actually gets you to be hired or brings money somehow)...

So, the question is: To what degree can you get by fast learning?? What are the benefits of all the things that is taught in schools about programming? (and here I mean the theoretical stuff of how internal stuff works and philosophy of programming techniques or any abstraction articles, not the practical part), and is it possible for a person to keep going and up-progressing this way or he has to switch to the slow-steady way if he wish to progress?? Thank you.. Any personal experience or link to a personal experience will be highly appreciated...

EDIT: and an important question: if you think fast learning makes a person a low-level or medium level, but not gonna take him to the high level or architect level, how can he catch up to what he missed of principles or theoretical sides on-the-go, while he is progressing?? like a top-down approach of learning practically then dig deeper at the principles he missed,, how can that be achieved ??

Answer 1

I would have to separate what you mean by fast learning to really get a solid answer.

As I see it there are 2 types of fast learning:

1. People that learn chronologically fast through natural ability, dedication, and perseverance.
2. People that take shortcuts and miss foundational aspects of programming, yet fulfill requirements.

There's nothing wrong with #1, other than burnout, and it isn't prohibitive of any learning style, generally.

The problem with #2 is that you never really get a complete picture of why programming works. Sure, you understand how to put pieces together, and you may understand many different programming languages and technologies, but at heart you're probably still a coder and not a programmer or architect.

A rare few will make all the connections as they go along, but most will need to go through some level of theory explained, whether through an experienced mentor, books, or preferably projects with others, if they expect to get past mid-level programming.

What is taught in various schools is not something we can quantify as valuable or not; much of that depends on the school and the student. Education in general though, is the most valuable way a rising programmer can spend their time if they want to continue progressing.

So how well can somebody do with fast learning (#2)? Not very well, IMO. They will never be better than a mid level when honestly compared with peers, and will not be able to understand how to architect or refactor complex systems across large teams.

There are other things that we simply cannot learn well without significant life experience, such as teamwork, recovering from large project failures, balancing various business expectations, and implementation of new technologies that supplant the old ones you just spent a decade supporting.

A well-rounded senior level programmer or architect is probably several times more productive than a mid-level coder that has been fast learning (#2) their way through everything. Possibly even one (or maybe two!) orders of magnitude faster. Great programmers don't progress linearly year over year; they progress, to a point, exponentially.

Answer 2

It's not the rate of learning that matters, but the depth of understanding.

With understanding comes the ability to analyze and solve problems that you haven't seen before. Without it, you're baffled whenever your situation doesn't match the template from whatever step-by-step tutorial you're following. Understanding is the solid foundation for your system of beliefs on a topic; without it, you'll have a hard time thinking critically about ideas related to that topic, and you won't really be able to decide what must be true and what's just plain crazy.

Sometimes it's fine to know how to do something without having a deep understanding of why you should do it that way. A common example is that you can drive a car without really knowing how an engine or a transmission works. Closer to home, all programmers use libraries or frameworks to get things done without necessarily knowing what goes on under the covers. Frameworks encapsulate knowledge for others to use easily, and that makes programmers vastly more productive than we would be otherwise.

So, understanding is obviously good, and not needing to understand everything can also be good. Where should you draw the line? Should you learn enough that you can use the incredible tools that others have built for you, or should you become a guru of all things binary? Only you can decide that.

You should know, though, that at some point the approach that you call "fast learning" is much, much less efficient than the "slow steady" focus on fundamentals. The so-called "fast" method is a top-down approach in which you have to solve each new problem independently. The "slow steady" approach is more bottom-up: you learn a bunch of fundamental principles, and those become building blocks that you can combine and configure in endless variety.

Think about math for a minute. You've probably learned how to solve some different types of word problems. If that's all you learn, though, you'll be stuck as soon as you encounter a word problem that doesn't match the kinds of problems you know how to solve. That's why a good teacher will help you learn to figure out how to solve a problem. There's no step-by-step method for that, but there are a number of principles that you can learn and apply.

Finally, there's an old proverb:

Give a man a fish and you feed him for a day; teach a man to fish and you feed him for a lifetime.

Answer 3

I believe it would all boil down to how many words can be read in a minute in a way that all meanings of the read text can be understood and retained for all kinds of use. This, not just for reading, but for listening, watching moving objects and pictures and movies, etc. That is, only so much could be grasped and applied in a given time frame.

Learning software engineering principles, programming techniques, algorithms, data structures, etc is bound to take a few years of work. Going to university and spending four years there is one way known to work. You could learn all by yourself too, perhaps quicker, perhaps slower.

Some programmers, like there are in all other crafts, are prodigious. But for the rest, programming in ten years appears to work.