Evaluating code today is more complicated than it used to be.

When I started learning programming in the mid eighties, the OS and system libraries that your program used were documented in a book and didn't change often.

Even if you didn't own the book, the release cycle of the code your program depended on was stable enough that you could rely on it and it was produced by large companies that generally produced stable/reliable code.

Nowadays we have google and can find all sorts of useful libraries, the problem is that:

1. These libraries are of varying quality. So you have to evaluate the quality of the library code.
2. You often have to integrate the library with your code and with other libraries as well. You have to manage dependencies.
3. The libraries may change frequently. Meaning that you have to re-evaluate the library and how it integrates with everything more often.

This whole problem is compounded if you deal with frameworks. A framework is a type of library that typically imposes some level of 'inversion of control' on your code.

In cases where the framework is mature and solving it's problem well, and is sufficiently extensible, this saves you a lot of work.

A bad framework though is worse than code you wrote from scratch, because you lack the control to make it do what you want.

I'd say that the most valuable skill today in programming is to get good at evaluating and integrating with outside frameworks.

In the area of Java/J2EE web development I find I have to revisit the 'framework' question every 18 months and see if it is really worth upgrading Hibernate/Spring/Spring Security and various other components of my project template.

Upgrading may allow me to obtain certain benefits and new features but also introduces the possibility of new bugs.

There have been problems on Intel and AMD processors traced back to faulty microcode though.