How I approach any given programming problem depends upon the nature of the problem. The first questions I always ask are "what needs to be done" and "why does it need to be done". That second question is crucial. Quite often programmers gather all their specs without asking "why" and return with an program that fits the specs, but not the needs. Users often are not able to accurately state what they want. When you understand why they want it, you usually can provide them with assistance in understanding their needs.

After I've answered "what" and "why", I determine my available resources. Whether or not I'm forced to use a MS SQL database, have a dedicated file server, or am able to specify what tools my customers can use (usually in terms of browser) makes a huge difference in terms of what I can do. There's also schedule and budget, but I think that's beyond what you're asking.

After I've gotten my users to sign off on the work, I start to dig in. If it's something simple, I often find a program that does something similar and modify it. However, for moderate-to-difficult tasks, I start from scratch. Typically, I'll do a rough heirachical sketch of the program functions. For tough jobs, I do a modified Warnier-Orr diagram of the components along with diagrams showing how different pieces interact. Of course, I also look for CPAN modules (if I'm using Perl) that will handle the functionality I have drawn up. No way in heck are you going to find me writing my own CGI parser.

Then comes the programming, debugging, development of test plans, etc. If enough of the work is done properly up-front, the programming and follow-up is actually the easy part. Note that all through this phase, I want to go back to my customers (if possible) and say "is this what you want?" Too many times a programmer or company will go into seclusion for a month or two and come back with an unuseable product because they didn't bother to consult with their end-users (can anyone say <a href=http://www.iarchitect.com/lotus.htm">"Lotus Notes"? I knew you could).

However, I think the most important thing is to learn fundamental concepts of structured programming. The beauty of a properly structured program is that you can revisit it later, break it down easily, and swap out portions with better code without interfering with the over-all functionality (at least, that's how it should work).

The rest is just experience. Personally, I read the Perl Cookbook quite a bit. The code in there provides great examples of how to code and plan for eventualities.

Cheers,
Ovid

Join the Perlmonks Setiathome Group or just go the the link and check out our stats.