When I was starting to look around for programming help for advanced languages (C/C++), at the time, the best resource was USENET (this was before Sept 1993). With a very high signal to noise, and with many of the bigger names posting help often, I learned a lot from just reading the newsgroups and trying things out on my own. These groups also commonly referred to a few key books that I strived to own (as a poor starving grad student :-), which is how I knew to distill the bulk of the programming books out there to key volumes. Unfortunately, I doubt that today that USENET can be used in a similar fashion; while most of the comp.lang.* tree is at a reasonably high S/N ratio compared to other groups, you don't have the big names posting, and thus advice there should be always taken with a grain of salt.

But sites like PM have come to replace the problems with USENET, with a significantly high S/N ratio and moderation to deal with 'problems'. And in similar fashion, some of the bigger names in the perl industry are posting here and helping out, and recommending books and other resources. So the best way to find out good resources (books or websites or otherwise) is to continue to read and keep your preverbal ears open for any sort of help.

Now part of the problem is that books on programming and design theory are typically taylored to a language, save for the number of volumes written on OOP (which generally have a fixed langauage as an example, but are not attempting to teach that language). As an example, the excellent "Object Oriented Perl" by Damian, while a great book about perl and OOP, is strictly about perl *and* OOP, so while you can get a lot of good perl programming design ideas, it does not particually lend itself well to, say, Java or C++ and OOP. Similarly, I've read some good Java OOP design pattern books, but the information on patterns does not reversibly apply to perl.

Note that this does not mean that that nothing in, say, a C++ OOP book could be used to help in perl. While there are significant differences at the language level that cannot be shared, there are some object designs, such as the Model-View-Controller of Swing/Java, or the so-called Factory object pattern, that can be applied to perl just as well. For example, Scott Meyers has two books, 50 Effective C++ Tips and 50 More Effective C++ Tips (titles off the top of my head) that have an assortment of language specific and design pattern, language neutral tips that I would recommend for perusal for a perl programmer, though not necessarily to buy for one's bookshelf.

So again, the best solution is to listen on newsgroups and web boards akin to PM to locate solutions that might be best for the language of interest. If that's perl, then there's already a good wealth of books on programming design for that, and you'll find reviews and comments on them here at PM. But if it's in Java or C++ or other language, you'll probably need to do a bit more digging. Look around at the newsgroup FAQs for the language, for a start; I'm pretty sure that a good list of comprehensive books for most languages is included in those FAQs. Find language 'index' pages that typically enumerate all the possible resources for that language on the net and in print. Look at reader reviews at sites like Amazon, or other specific programming sites. And if possible, spend time in a browsable bookstore and read through a chapter or two and see if it meets your goals. Some books even have sample chapters on the web in PDF format that you can view as well. But this last point is important: just because 99% of the population says a book is 'significant' doesn't mean that you'll automatically gain information from it; you may find the writing style to be hard to learn from, or poor, unexplained examples, or a presumed reader level that is much higher than you expected (a good example: Programming Perl is a great book, but you *need* to know a good amount of perl before you get your money's worth from the book, while the Learning Perl is better for the perl newbie).

Update Err, HIGH S/N, that is ;-)

-----------------------------------------------------
Dr. Michael K. Neylon - mneylon-pm@masemware.com || "You've left the lens cap of your mind on again, Pinky" - The Brain
"I can see my house from here!"
It's not what you know, but knowing how to find it if you don't know that's important

Being a good programmer, in my opinion, deals with more than just code. It includes your ability to look at, understand, and solve problems in an ordered and defined method (we'll call it algorithmically). It also deals with knowing how to use the right tools for the job at hand. Personally, I try to stay away from religious wars dealing with languages. I've had occasion to write applications in various languages, and I'd like to think that I used the right tool for the job, and that I didn't try to shoe horn my favorite language into the application merely because it was my favorite.

Update: I made an algorithm allusion, but failed to include texts:

• Cormen, Rivest
• Aho
• Sipser

Gain some exposure to other languages, and try to incorporate them into how you solve problems. If nothing else, it will strengthen your abilities with your weapon, er, language of choice.

I read Design Patterns and got a lot from it, but it's not for the faint of heart. Also, as a companion that adds some new views, Design Patterns Explained is good. These deal with OO design in C++, but the patterns discussed hold true, and can apply to most projects.

My last suggestion is the most difficult to fulfill, but usually the most rewarding. Find a mentor, someone near-by that you can learn from. My strongest coding moments were under the watchful eye of a mentor. I don't even know if he knew he was playing that role. He was near-god-like in his ability to solve problems, understand code and implement a well organized solution in almost no time. He created some algorithms for highspeed data acquisition (sensors on automobiles, etc) that were phenominal. Being in that environment motivated me, and taught me what it meant to be a good software engineer, and not just a programmer.

Good Luck,

C-.

Update: Ack, how could I have forgotten Prof Don Knuth's work. I turned around and it was on my shelf, staring me in the face. I repent.

Design in General

• Norman, D. A. (1990). The design of everyday things. New York: Doubleday.
• Norman, D. A. (1992). Turn signals are the facial expressions of automobiles. Reading, MA: Addison-Wesley.
• Norman, D. A. (1993). Things that make us smart. Reading, MA: Addison-Wesley.

Design and Computer Programming

• Design & Memory. By Peter H. Huyck and Nellie W. Kremenak. New York, NY., McGraw Hill, 1980.
• Patterns of Software. By Richard P. Gabriel. New York, NY., Oxford University Press, 1996
• Structure and Interpretation of Computer Programs. By Harold Abelson and Gerald Jay Sussman with Julie Sussman. Cambridge, MA., MIT Press, 1985.

Best of All

• Design for the Real World. By Victor Papanek. New York, NY., Bantam Books, 1973.
• The Art of Computer Programming. By Donald E. Knuth. Reading, MA., Addison–Wesley, 1997.

hsm

Some of the replies to this node might help you. They definitely helped me...

Kevin O'Rourke

------
We are the carpenters and bricklayers of the Information Age.

Don't go borrowing trouble. For programmers, this means Worry only about what you need to implement.

If you truely want software design skills firstly you need to master OO. Then you need to master design methods like UML http://www.uml.org and Class diagrams, Use case diagrams and flow control diagrams should also be used at the design stage.

Buy a book on Software engineering like Software Engineering by Ian Sommerville

They are usually not worth bothering with in the real world as they can consume more time than actually writing the program.

The argument is that good design save you time in the maintenance of large projects.

Actually, if you truly want software design skills, then you need to master how to cook Julienne fries perfectly every time. *grins*

This is a perfect example of a religious statement - something that is said through belief, not proof. While hakkr may (or may not) have some validity, s/he cannot prove any of it.

To tell you the truth, you have to know what you want to do and how much effort you want to put into it. Then, and only then, can you determine how you want to design it. For example, I'm working on two projects right now, both of them games. One, I'm designing on the fly. The other, I'm going through requirements-HL design-LL design-mockups-etc. The whole 9 yards. Why? The first game is tiny and I'm just playing. The second is huge and I want to market it.

What's the difference? Well, if I want to sell something for millions of dollars, I need to prove to the purchaser(s) that it works. The only way to do that is to document what I did. If I don't care about that, then who needs design docs!

As another disagreement with hakkr, software design is PERFECTLY in line with laziness. I'm lazy, so I don't want to do it over ten times. I want to do it once, only once, and be able to prove it. (That's where hubris comes in!) Impatience? Well, why design is in line with impatience is left as an exercise for the reader.

------
We are the carpenters and bricklayers of the Information Age.

Don't go borrowing trouble. For programmers, this means Worry only about what you need to implement.

I digress, you need to have OO programming skills in order to use the design methods.

There is no point making a Class diagram if you don't know how to write a class.

OO code is also easier to maintain. As for impatience the impatient programmer skips the design and gets straight on down to good ol' perl hacking. Also I'm an advocate for design especially whilst working on 'million dollar' projects i.e 'big projects' like I said.

However you are indeed you are right, long term lazyness favours design short term lazyness favours none

Of late I've been picking up some design insights from a different perspective, by reading Doing Hard Time: Developing Real-Time Systems with UML, Objects, Frameworks and Patterns, by Bruce Powel Douglass.

Much of my professional life has been lived with the attitude that "by the time it ships, we'll have twice the memory and twice the processor power, so don't worry about _______," which is fine with many classes of applications, but not for those that have rigid response constraints and Very Bad Consequences for missing them. Learning some of what hardcore embedded designers go through to make reliable, safe systems has been a real eye openner. It might not apply directly to Perl, but good ideas make great compost.

UML is the industry standard for modeling software systems.
It is wisely recommended several times on this very page and it's Object Orientated.