1.6. We Learn by Doing

The problem with working in the computing field is that technology insists on advancing. Learn something new today, and 2 years down the road, it is obsolete. Because of this, it's necessary to continue learning the latest new technology, which means lots of reading and lots of training. While at Bell Labs, I formulated two rules of training that I'd like to share with you:

These rules have proved true every place that I have ever worked throughout my career. Banks, insurance, manufacturing, whateverit doesn't matter. These rules have always held true.

There is, however, a way to skirt these rules. Simply try the examples, play with them, alter the code, make it better, break it, and fix it. There is no substitute for immersing yourself in any subject to learn that subject. It might be difficult at first, and sometimes it might even be painful, but the easiest way to learn is by doing.

1.6.1. Coding by Hand

Currently, coding web applications by hand has fallen out of favor, and rightly so, replaced by packaged components that can be dragged and dropped. Unfortunately, although the practice of using components means that individual pages are developed quicker, it also means that it isn't always easy to determine what the components are actually doing behind the scenes. This is especially true when the underlying code isn't fully understood because the developers skipped ahead to the parts that will keep them employed.

However, when learning something new, or trying to explain it to someone else, I have a strong tendency to code an application by hand. In part, the reason for this is that it gives me a better feel for the new subject. Of course, the other part is that I coded classic ASP for quite some time and spend a great deal of time writing client-side workarounds for managers who insisted on the use of design-time controls. Although it improved developers' JavaScript skills considerably, it had the same effect upon those developers that mercury had upon hat makers in the nineteenth century. Don't believe me? Go ask Alice.

Seriously, though, the idea of coding at least the first couple of applications by hand is to attempt to get a feel for the technology. Feel free to ignore my advice on this subject. What does matter, however, is making it easier for us in the end, which is why tools are important.

1.6.2. Tools to Make Tools

If the idea of coding by hand is repugnant to you, consider this: On some level, somebody coded something by hand. It is a pretty sure bet that there are no software tool trees, although I have used several that weren't quite ripe yet.

Many developers have issues with the very concept of creating their own common tools for web development. The first issue probably relates to the idea of job security; after all, if a company has a "developer in a box," why would it pay for the real thing? The answer to this is relatively simple: What if they want changes to what's in the box? Let me put it another way: Have you ever written some code and played the "I bet you can't guess what this does" game? I have, and not only is it good for feeding the old ego, but it is a blast, too! Of course, there is the tendency to strut around like Foghorn Leghorn afterward, but as long as you avoid the young chicken hawk developer and the old dog developer, everything will be fine. Also remember that, by himself, the weasel isn't a real threat.

Another issue is the "I can tell you, but then I'll have to kill you" mindset. A while back, I had a manager with this mindset; she seemed to withhold required information just for fun from every assignment. For example, she once gave me the assignment to produce a report from a payroll file and then told me that I didn't have high enough security to see either the file or the file layout. Somebody once said that information is power, and some people take it to heart. The danger with this philosophy is that information can literally be taken to the grave, or it is so out-of-date that it no longer applies.

Finally, there's what I believe to be the biggest issue, which I call "The Wonder Tool"; it dices, it slices, and it even makes julienne fries. Similar to the "feature creep" that we're all familiar with, but with a difference, it starts out unrealistic. "The Wonder Tool" is a mouse designed to government specifications, more commonly called an elephant. For the interest of sanity (yeah, right, me talking about sanity), it makes far more sense to break up the tool into more manageable pieces. For example, let's say that we need common tools to do X and Y, both of which need a routine to do Z. Rather than code Z twice as part of X and Y, it makes more sense to code a separate tool to do Z and have X and Y use this tool. And who knows? Sometime in the future, you might need a few Zs, and you'll already have them.