While I don't consider myself an expert at programming by any means, here's a brief list of books on my current reading list. I've managed to get through some and am slowly working my way through others.

Note that some are rather expensive. Some time back, I started setting aside a portion of my paychecks for the reading list. Usually by the time I'm ready for the next one, I can afford it.

Please note that a) the books are listed in the order that I thought of them and b) the links take you to the most recent listing on FatBrain using the Monastery's [isbn://] link.

That said, here's one monk's (incomplete) reading list:

• The Art of Computer Programming, by Donald E. Knuth
• The Pragmatic Programmer, By Andrew Hunt,David Thomas
• Object-Oriented Software Construction, By Bertrand Meyer
• Design Patterns: Elements of Reusable Object Oriented Software, By Erich Gamma, et. al.
• Analysis Patterns, By Martin Fowler
• The Mythical Man-Month: Essays on Software Engineering, By Frederick P. Brooks Jr (note: anniversary edition)
• Code Complete: A Practical Handbook of Software Construction, By Steve McConnell
• After the Gold Rush: Creating a True Profession of Software Engineering, By Steve M. McConnell
• Rapid Development: Taming Wild Software Schedules, By Steve McConnell
• Software Requirements, By Karl E. Wiegers
• Debugging Applications, By J. Robbins (Note: While written for Visual Studio, this outlines techniques useful for any language, platform, or environment.)
• Code, By Charles Petzold
• Dynamics of Software Development, By Jim McCarthy
• About Face, By Alan Cooper

By the way, I second merlyn's suggestion for reading source, though wish to add an adjective: read good source. Look for stuff by people whose coding skills you (hopefully) respect. For example, I've been reading the source of CPAN modules by Lincoln Stein, Gisle Aas, <a href=http://search.cpan.org/search?mode=author&query=tilly">tilly, dominus, and others that've been mentioned before.

While it's possible to learn from bad code, there's a danger that you'll pick up bad habits in the process. Save yourself the effort and start with the good stuff

Also, it helps to locate some good periodical sites and go through their archives. TPJ, for example, has published some really useful stuff. Personally, I'm looking forward to the re-opening of their archives.

--f

To footpad's excellent list, I would add
• Programming Pearls, by Jon Bentley. Make sure to get the 2nd edition.
• Writing Efficient Programs, by Jon Bentley. Out of print. Ask around and borrow a copy.
Bentley's books are fun reads. They're written in short chapters, each illustrating a particular aspect of the craft. His optimization case studies are particulary fascinating. He takes real, (poorly) working code, and improves it step by step, measuring as he goes.

I still wonder why nobody ever cites :

MUSASHI (Eiji YOSHIKAWA)
(The Sword and the Stone, in some editions)

It's describing the way of the coder through the pleasant metaphor of a samurai...


"Only Bad Coders Badly Code In Perl" (OBC2IP)

If you're going to pick just one book, pick Code Complete. I love any book that lets me say "This book is our departmental coding standard."

xoxo,
Andy

%_=split/;/,".;;n;u;e;ot;t;her;c; ".   #   Andy Lester
'Perl ;@; a;a;j;m;er;y;t;p;n;d;s;o;'.  #   http://petdance.com
"hack";print map delete$_{$_},split//,q<   andy@petdance.com   >

For those of you without computer science degrees, how did you become experts at programming? Was it through the applied use of a programming language or through the study of more abstract programming theory, or a little bit of both?

But yes, to answer your question, "yes". I spent most of my time faced with a programming problem in front of me, and a stack of manuals to my side. Nothing like a paycheck to motivate you to solve problems in your programming.

But in the "off hours", I also spent hours and hours just reading code. I can't emphasize this point enough. Get all the code you can already written in the language you wish to learn. And in languages you don't know yet.

What happens over time is that the "rhythm" of the language starts pounding inside your head. And then you start noticing that "rhythms" from one language can be reused in another, as long as they're from common families.

If the reference manual is like the dictionary, existing code is where you learn the "idioms". How do people typically write a subroutine call? Where does argument parsing get placed? How do you handle errors? What are hashes commonly called, and why? This is makes someone fluent in the language.

For example, the Schwartzian Transform was nothing more than an idiom I had learned in LISP, recoded to Perl. That's why I was able to hack it up in a few minutes in response to a question in CLPM, and nearly without even thinking about it, because I already had thought about it when I was first playing with list processing.

And then comes along a tool like YACC, where I'm puzzled about what the term "LALR(1) Grammar" means. So I do grab theory books from time to time, and learn just enough to be dangerous. {grin} But what I learned there applied a lot to Parse::RecDescent, and I end up already writing columns using it within a short time of being exposed. Because I'm reusing the patterns in my head. The idioms of the languages.

-- Randal L. Schwartz, Perl hacker

Your words reinforce my thoughts on how closely programming and language (spoken and written) are related. I'm sure that's a topic quite a few books have been written on already.

I will definitely take your advice to read other people's code. It's something I haven't been doing much of. Thanks.

$PM = "Perl Monk's";
$MCF = "Most Clueless Friar";
$nysus = $PM . $MCF;

The theory is nice because it gives a person a framework within which they can think about programming languages in general. The most enlightening course I took in college was a comparative OS course, but only because I had been working in a real-time system and the course finally gave me the correct language to think about what was happening.

For the most part, I have come by my knowledge the hard way. Write enough code that you then have to maintain 6 months later and you quickly figure out the value of comments and documentation. Spend enough time trying to remember what command line options are available and you learn the value of -h options and Getopt::Long. Re-invent certain wheels enough times and you learn to either make a module or to search CPAN first and steal^wuse somebody else's wheel.

I would recommend, for what terribly little my opinion is worth, picking up the book on programming theory and language design. I would recommend learning several different programming languages. Both will allow you to approach a problem, determine the best tool and use it effectively. Which, in my mind, is what really defines an expert programmer.

mikfire

• Learn a new language. Rewrite some of your old code in the new language.
• Explore a new technology. Read a book about something not specifically related. Ask yourself how they designed it and why they made the decisions they made.
• Solve a new problem. Read a question on clpm or a golf challenge or a SoPW question, attack it yourself, and then compare it to the other answers.
• Ask a new question, like "What happens if I bless a typeglob? Can I access a scalar and an array even if I pass just a scalar reference as $self?" Then write code to try it.
• Rewrite an old program, but do something differently. (Perl makes this easy.) Some solutions are better than others, but knowing more about the language helps you solve other problems.
• Read a module's interface, then see if you can recreate it without reading the code.
• Look at a problem and write an interface to attack it. Then compare it to a module that solves the same program.

Seek out people who are more skilled or experienced than you, and ask them to review your code, or to let you look over their shoulder while they code. I've picked up a lot of my technique from watching others.

Convene a "coding" group, to review and critique each others' code. The challenge of knowing that your code will be subject to peer review is marvelous for quickening the mind and reenforcing good habits.

This is not a book that assumes certain principles as built into some programming language—rather this book teaches the fundimental ideas that later got put into those languages. In fact, I found more than one compiler implemented malloc() directly out of Knuth's answer section!

—John

There is an old saying:

"Those that can do, those that can't teach"

No amount of book knowledge will ever substitute for practical
experience. 

The practice practice practice advice is impossible to fault.

This being said, in the texts you will find 'perls'
of wisdom to help you avoid the age old pitfalls. While you 
may need to reinvent a wheel or two to learn your stuff there
is no need to get run over by a bus in the name of experience.

For out and out syntax practice deconstructing obfuscated 
code will teach you a lot and provides an endpoint, reading
code comes a somewhat poor second. JAPHs make for 10 minutes
of intense thought to understand them - all in all a nice bite
sized syntax problem.

Summary

Do code
Do make mistakes
Do not repeat your mistakes, make new ones!
Do ask if you need help
Do read at least one book cover to cover
Do not take it too seriously
Do enjoy

Tip:If you have been coding for 36 hours straight take a break.

tachyon

my $answer=[q;7566626f206f7420756f7920656d6f636c65772049;];
print join''=>reverse split''=>pack H42=>$answer->[0]=>eval;
[download]

Several responses have mentioned some excellent texts for reference. I have not yet seen anyone recommend Mastering Algorithms with Perl by Jon Orwant, Jarkko Hietaniemi & John Macdonald which is an excellent introduction to theory using perl.

Sriram Srinivasan's book on Advanced Perl is now quite dated and needs an update (as do the perlxs and perlxstut pod pages).

Unfortunately (or fortunately :-) Perl's weak typing means that a lot of what goes into computer theory: data structures, algorithms, etc. is altogether too easy. Most of the other formal monographs on theory spend tens, or hundreds of lines of code just dealing with strong typing allocation, a subject that is only rarely broached with perl. Knuth's texts on TAOCP for example are written in MMIX, an assembler for the imaginary MIX hardware.

Of course, the very best thing you can do is go to college, ignore the CS department, and study math and English. That's only partly tongue-in-cheek advice.

adamsj

They laughed at Joan of Arc, but she went right ahead and built it. --Gracie Allen