I always have a tendency to feel self-righteous at this point, thinking “Well, I need to know exactly how this works, or there may be an unintended consequence in my code implementation,” and I feel not only this need for justification, but also a bit embarrassed for not meeting the deadline.
Having to ask for more time to complete the part of the project for which I am responsible (or irresponsible, as the case may be ;-) is a very stressful situation, and I have learned the hard way that it can easily lead to exhaustion, which tends to lead to even more lost time stemming from the extra bugs in my code base.
I know a great many programmers who are always looking for new ways to do things, and over my admittedly short and not-so-illustrious career as a web programmer, I’ve found that one of the hardest things to learn as a programmer is the Gestalt Theory, or as I like to call it, learning to see the Big Picture.
In this age of program complexity, there are a multitude of different areas in which one could conceivably get stuck, and without some view of the overall project, you can spend whole days, weeks, months, or even years studying just a single area or aspect of programming. In some scenarios this is fine; for instance, if you are a GUI specialist working on Aqua for Apple, for instance, then it is your job to study user interfaces, and to know them better than anyone else. And if you’re working as a DBA for a multinational banking conglomerate, well, who cares if you don’t ever bother to learn mod_perl? (I know, sad but true!)
Just offhand, I can list a dozen programming areas; sockets, file I/O and permissions, graphical interfaces, DBI, persistence, multi-threading, even deceptively simple areas like table design in SQL databases, in which I could conceivably spend weeks mastering the subject matter. This is a luxury I can’t afford, and I know of only a very few programmers who have found the means to study the areas that interest them at will.
With such a large number of programming aspects available to us, how can one hope to become an expert in all of them? Well, the short answer is that you can’t. Although I would absolutely love to spend a whole day playing with Astro::Moonphase, I simply cannot afford to do so while working on a project. Eventually, one must choose, and specialize in those areas we wish to master. Eventually, we learn to trust the skills of those around us; to rely on the works of others to take care of the nitty-gritty details of those areas in which we are perhaps not so skilled.
And that’s why Perl is such a marvelous beast. Because Perl, to some degree, allows me to select a combination of parts built by some very skillful engineers, without necessarily having to know how to run a tool & die shop myself. Perl lets me see the forest for the trees, as the expression goes. I sometimes feel like CPAN is a giant machine shop, filled with expertly forged axels, shiny spark plugs, and CV joints, and it is my job as the mechanic to figure out how to build a working engine.
When we put those parts together into the engines that drive our sites, we might do well to appreciate the skill that went in those carefully turned modules, but also, perhaps even more importantly, realize that if we had to do it all ourselves, we would never have the time to spend learning the fun stuff. ;-)