I love reading the book Code Complete, by Steve McConnell. The following comes from it, in its chapter where he discussed Curiosity.

Once you admit that your brain is too small to understand most programs and you realize that effective programming is a search for ways to offset that fact, you begin a career-long search for ways to compensate. In the development of a superior programmer, curiosity about technical subjects must be a priority. The relevant technical information changes continually.
…
If you aren’t curious enough to keep up with the changes, you might find yourself down at the old-programmers’ home playing cards with T0Bone Rex and the Brontosaurus sisters.
…
Programmers are so busy working they often don’t have time to be curious about how they might do their jobs better.

Build your awareness of the development process.
The more aware you are of the development process, whether from reading or from your own observations about software development, the better position you’re in to understand changes and to move your group in a good direction.

If your workload consists entirely of short-term assignments that don’t develop your skills, be dissatisfied.
…
If you’re not learning, you’re turning into a dinosaur.

You are in too much demand to spend time working for management that doesn’t have your interest in mind. Despite some ups and downs and some jobs moving overseas, the average number of software jobs available in the U.S. is expected to increase….

Experiment
…
If you don’t know how a feature of your language works, write a short program to exercise the feature and see how it works. Prototype! Watch the program execute in the debugger. You’re better off working with a short program to test a concept than you are writing a larger program with a feature you don’t quite understand.

Read about problem solving
Problem solving is the core activity in building computer software.

Analyze and plan before you act

Learn about successful projects
One especially good way to learn about programming is to study the work of great programmers. Jon Bentley thinks that you should be able to sit down with a glass of brandy and a good cigar and read a program the way you would a good novel.

Read
Documentation phobia is rampant among programmers. Computer documentation tends to be poorly written and poorly organized, but for all its problems, there’s much to gain from overcoming an excessive fear of computer-screen photons or paper products.

Read other books or periodicals
One book is more than most programmers read each year (DeMarco and Lister 1999). A little reading goes a long way toward professional advancement.

Affiliate with other professionals
Find other people who care about sharpening their software-development skills. Attend a conference, join a local user group, or participate in an online discussion group.

Make a commitment to professional development
Good programmers constantly look for ways to become better. Consider the following professional development ladder used at my company and several others:
Level 1: Beginning
A beginner is a programmer capable of using the basic capabilities of one language. Such a person can write classes, routines, loops, and conditionals and use many of the features of a language.

Level 2: Introductory
An intermediate programmer who has moved past the beginner phase is capable of using the basic capabilities of multiple languages and is very comfortable in at least one language.

Level 3: Competency
A competent programmer has expertise in a language or an environment or both. A programmer at this level might know all the intricacies of J2EE or have the Annotated C++ Reference Manual memorized. Programmers at this level are valuable to their companies, and many programmers never move beyond this level.

Leve 4: Leadership
A leader has the expertise of a Level3 programmer and recognizes that programming is only 15 percent communicating with the computer and 85% communicating with people. Only 30% of an average programmer’s time is spent working alone (McCue 1978) Even less time is spent communicating with the computer. The guru writes code for an audience of people rather than machines. True guru-level programmers write code that’s crystal-clear, and they document it, too. They don’t want to waste their valuable gray cells reconstructing the logic of a section of code that they could have read in one-sentence comment.

A great coder who doesn’t emphasize readability is probably stuck at Level 3.
… The main reason people write unreadable code is that their code is bad. They don’t say to themselves, “My code is bad, so I’ll make it hard to read.” They just don’t understand their code well enough to make it readable, which locks them into one of the lower levels.

…

It’s no sin to be a beginner or an intermediate. It’s no sin to be a competent programmer instead of a leader. The sin is in how long you remain a beginner or intermediate after you know what you have to do to improve.