Re: Web Front End Advice

Bruce Vining wrote:

Besides "whats actually going on", learning the lower level support also enables you to know what the system is capable of, as opposed to what the tool provider decided to surface/externalize. It lets the application developer know when it might be appropriate to dive a bit deeper and directly use an API or similiar construct.

Not only that, but inevitably when you use any framework, there comes a time when you use that framework in a way the designer didn't intend. This typically shows up as a defect, or at least an operational anomaly (in IBM parlance, an "unpredicted result" <grin>). In any case, when the code doesn't work the way you want it to, if you understand the underlying code, it's much easier to identify the reason for the failure and make an intelligent choice as to whether there's a workaround, whether you need to change your design or whether you may have to abandon the framework entirely.

But sort of the side benefit of knowing the code is a retained sense of ownership. Too often these days (and this is me settin' in my rockin' chair, with my teeth in a glass beside me) when something doesn't work right, I hear the words "they should..." as a prelude to some complaint about how the framework doesn't work "right" and it's not the programmer's fault, it's that damned framework.

Heck, back in the day the compilers made mistakes. We had to identify those, and then go in and fix the generated code manually (and then remember to do it every time we recompiled that code). But that was our job - our job was to make the computer work. And while computer programming has gotten much more complex over the years and it's unlikely that any of us would get a lot of productive work done without some help from tools, I still say that the number one thing that differentiates a programmer and a coder is a thorough understanding of how his tools work.

However, this is dangerously close to an opinion-oriented rant, so I better quit <grin>.

Joe