We all have blind spots. In the last week, I have encountered three blind spots. I am writing about them because I have learned something useful from the experience and I want to know what you did in similar circumstance. First, to be fair, let me tell you briefly about my three points of invisibility . Mercifully, I will be brief.
I have a series of resumes that I keep current. I update them whenever I do something that I believe is significant. I knew they missed something, but I did not know what. I even had my peers review my resumes and all said they were OK or better. Still, the resumes seldom got the results I wanted.
The blindingly obvious omission was any mention of the work I had done on the Web or with the Internet. I work and use it on a daily basis, I hear and read about it everywhere, especially here in the Valley. But, I failed to mention it anywhere in my resumes. Why and what happened may be illustrative.
In doing this newsletter, I have needed to get down and dirty with the Web, its tools and its foibles. This practical experience, as opposed to the arms-length experience I had had before, made the Web real for me. So when I went to update my resumes, I asked what I had been doing with myself lately and I realized that I had failed to mention the Web anywhere in my resume.
The first lesson was that practical experience makes things real. Terribly obvious; but, again, part of my blind spot was forgetting the obvious. The second lesson was that I often ignore my environment – I take it so much for granted that I discount it totally.
My second blind spot occurred preparing for the presentation I gave last month at the ACCU monthly meeting. I had shown an implementation of hash tables. As you may know, unless we are talking about perfect hash tables, we can expect collisions where different key values have equal hash values. The normal approach is to create linked lists of keys with equal hash values. There are a number of weakness with this approach. One is that linking list elements using pointers means that the list elements can not be relocated with impunity. There may be something else pointing to a given link. Peter Sotos, one of our members at the meeting then asked the obvious question: “Why not make the overflow list into a vector and use element indices as the links between list elements?”
This suggestion neatly solves the problem of relocating or expanding the list. All external references to list elements remain valid. So why didn’t I see it? After all, I was doing the coding.
The answer was that I had thought about this solution, but discarded it without giving it any real thought. I didn’t take the time to evaluate my alternatives.
The last blind spot occurred today at a luncheon meeting of the Business Marketing Association. Our speaker, Agnieszka Winkler, had a group of five of us form a large circle. We then threw a series of four balls to each other. It was a shambles. She commented on how slow we were and then had us move in closer and repeat the exercise. If possible, it was a worse shambles. Again, she noted that we were still too slow. How to fix the problem? At that moment, the light came on in my head and I realized the answer (I leave it to the reader as an exercise ;-)).
What I did not mention was that the balls were dark blue and I could not see them against the background when they were tossed to me. At least this was the excuse I used for dropping most of the balls sent my way.
The solution to the exercise eliminated the color problem entirely. Thus, the more elegant solutions eliminate problems. Often, the more elegant the solution, the more problems are eliminated. Thus, I learned that if you turn this truism around and identify the problems you want to eliminate, you can arrive at elegant solutions.
Trends this month’s shows current language demands in Figures #1 and #2. The normalized demand for languages in Figure #2 shows that the demand for Java now outstrips the demand for both C and C++ by a fair margin.
Figure #1
Figure #2
Figure #3 shows the demand for C and C++ has dropped in the last 30 days by comparison to Java, HTML, Perl and XML. Notice that VB has also declined in demand since last month.
Figure #3
Silicon Valley still maintains its uniqueness with respect to employment. (Sound familiar ;-).
The percentage of software engineering jobs decreased this month from 37% to 26.6% of the 194,000+ technical jobs listed. Of these 51,000+ software-engineering openings, 89.8% are in Silicon Valley. This shows a marked increase from last month and shows that Silicon Valley firms use the net by better than a 4:1 margin over the rest of the country when hiring software engineers.
Internet technology continues to dominate everything technical here in the Valley. Figure 3 shows that demand for those technologies directly related to the Internet are accelerating ever faster. While demand for basic tools like C, C++, and VB are still strong, the demand for Web-based technologies are in greatest demand. Based on other studies, the perceived demand for Internet appliances is fueling this trend.
You may have heard that templates can be used to do complex calculations at compile time. Serious tools, like Blitz++, and silly things like computing factorials are examples. Since serious tools tend to be large, we’ll use a silly example here.
The factorial function is normally computed from the following:
fact(0) = 1
fact(n) = n · fact(n-1)
We can use this definition to write a template to evaluate the function at compile time. We declare a class template containing an enumerated type.
The first part implements the recursive definition.
Try it out and play with it, then check out the results of the Blitz project. Other examples are at Tod Veldhuizen's home page.
template<int n>
struct fact {
enum { res = n*fact<n-1>::res };
};The second defines the "0" value:
template<> struct fact<0> { enum { res = 1 }; };