Macha

The general consensus is that the one of the best ways to learn how to program better, beyond learning the basic syntax is to just go ahead and write some programs on your own. Another consensus is that the best type of program to write is one that scratches your own itch. Yet another consensus is that it is best to avoid the "Not Invented Here" syndrome of writing everything from scratch and instead reuse as much code as possible.

However, for someone learning to program today, for the most part, large parts of any itch that could be scratched has already been done so by someone else. Usually, this is someone who has done a much better job of it than any newbie code. This means that if they follow the advice regarding NIH, they would be reduced to writing glue code for quite some time, tying together libraries written by other people while they program relatively boring code.

The problem with this is twofold:

1. The newbie doesn't really learn much about designing their own programs. Sure, they see how the (hopefully) well written libraries do it, but they don't get to see the thought process required, or any of the refactoring that removes earlier bad design decisions.
2. Glue code is boring. How many people are driven away from programming by this experience?

One of the first big programs I wrote personally was a PHP social network. I did many parts of it from scratch - a database abstraction library, a templating system, even a primitive MVC system¹, and so on. The code that resulted was horrible, and probably riddled with security problems, but I learned a lot from the process.

How would a newbie do that nowadays? They'd install cakePHP or Django or Rails, getting them a DBA layer, templating, MVC all written for them. And sure, the resulting program will probably be cleaner and less buggy, as all the hard parts are handled by the framework. But the job of the programmer gets relegated to writing some models and a few views that are pretty much the same everywhere.

But then a lot of the benefit from trying to write a program for themselves just isn't there. They don't get the benefit of finding out why some ideas don't work, as they just use the framework. Most of what they learn are the APIs of the framework, not any of the thought processes involved in creating the program. Not to mention, while people writing more complex programs than anything a newbie might be delighted to have that problem taken out of their hands, as they figure out how to make their database not fall over with 20k users.

The fun of programming is solving new problems. That's why Rails and co. are so popular. After you've written your second or third wep app, then these problems quickly become old problems, and having Rails handle them for you is really convenient. But for a new programmer, they haven't solved these before. Their programs will not be as ambitious (as anything that ambitious will most likely be dismissed by them as too hard), so having Rails solve these problems will leave them without any problems to solve.

Of course, another benefit is that when they are finished, they can go look at the existing solution to see how it compares to their own solution. This can help them to compare the thoughts that led to their own solution to the (presumably) better result of the existing solution. If they managed to find some itch that hadn't been scratched by someone else already, they wouldn't be able to find a sample to compare to their own work.

In short, laying off the avoidance of "Not Invented Here" can help newbies learn quicker in many cases than being relegated to writing glue code.