Last month, I talked about how the definition of an expert programmer has changed over the years that I’ve been working in this business (see my editorial, “What’s an Expert?”). Back when I started programming, an expert was someone who knew the ins and outs of a particular language and even, sometimes, of a particular compiler. (“Oh, that error message just means that you didn’t declare the variable as Automatic.”) With the continued influence of object-oriented programming, languages have actually gotten simpler as various object models have taken over the functions that used to have to be built into a language. Rather than extend VBA, for instance, to work with relational databases, Microsoft made the DAO model available to VBA programmers. Nowadays, an expert is someone familiar with all of the nuances of some object model.

I shouldn’t ignore one other kind of expert: the tool wizard. As the languages have become simpler, their development environments and tools have become more powerful and more integrated with the language. The Access IDE, for instance, lets you build quite complicated reports if you know how to take advantage of it. Visual Basic’s IDE now includes a Data Environment Designer that lets you create objects for accessing data without writing code. One of the deficiencies of Internet development tools is that the development environments (like Visual InterDev) aren’t integrated with the runtime environments (for instance, the browsers and Web servers).

Still, I think that the object model experts are the people we currently regard as the wizards. This has had an effect on the way I think about development. It used to be that you could become a wizard in all of the tools that you used. Back in the bad old days, I made a living by knowing more about PL/1, DL/1, and CICs than anyone around me. Some of the knowledge that I acquired back in those days has continued to be valuable: how to work with people, problem-solving skills, system design strategies, and so on. My ability to design relational databases is still serving me in good stead (though <sigh> it will eventually be supplanted by object-oriented database design). But it’s just not possible anymore for me to know more than my peers about all of VBA, ADO, MTS, ASP, HTML, DHTML, and all of the other acronyms that I work with now.

Even if I could learn all of these technologies, it would be impossible to keep up with them as they change. My old technologies, in addition to being few in number, were slow to change. Moreover, they tended to evolve over time rather than get completely redesigned. The tools that I work with these days tend to be replaced (DAO vs. ADO) or change radically (Visual Basic 3 to Visual Basic 6).

So, how have I handled this? I’ve given up. And I suggest that you do the same.

I’ve decided that if I want to keep up with any technology, I’m going to have to keep my focus restricted to a limited number of technologies. Even at that, I’m probably going to have resign myself to never knowing all about the latest versions. I don’t, for instance, have any idea how the Data Environment in Visual Basic works, I just know that it exists. While the details will differ, I suspect that you’re in the same boat: You can’t keep up with everything, you know a couple of tools very well, you have a hazy idea about some others, and you’ve heard of (and are worrying about) most of them. The fact that you’re reading this newsletter suggests that you’ve decided that Access is one of the core technologies that you want to learn very well (good choice, by the way).

My decision to give up puts me in a quandary. As I suggested last issue, you can’t build applications without getting involved in all of these technologies. Since you can’t know them all, what are you going to do?

The answer, I think, is programming shops with staffs that consist of developers who have a good general knowledge of many technologies. Each staff member will also have to be an expert in one or more object models. For the shop managers, building a project team will consists of determining what the critical success factors are for the project (Web access, data access, raw performance, UI design) and stocking the team with the resident experts in those technologies. For the other technologies that the project requires, the necessary experts must be available for consultation but won’t be on the team (or will be brought on for the short period of time that they’re needed). Among other things, this means that many shops will rely on consultants for background on technologies that they’ve chosen not to keep in-house.

But so many of us work alone, either in small shops or as independent consultants. This is where your personal network comes in. When I have a question about the technologies that I’m not familiar with, I know someone who knows that tool very well, indeed. These aren’t people that I work with–at least not on any ongoing formal basis–but they’re people whom I can call upon. You don’t necessarily have to know these people, either. The various usegroups provide a virtual network of access to experts in whatever domain the usegroup is devoted to.

This attitude toward skills and networks has an impact on how you should be organizing your career. But that’s a topic for next month’s issue.