I've been riding the PC industry surf since 1976. In that time, I've seen corporations rise and fall with the ebb and flow of the market and the competition's technical innovations. Given the trend over the past 25 years, it's easy to predict what 2002 has in store for SQL Server developers and DBAs: change. Now that Microsoft has launched an entirely new platform—the Microsoft .NET Framework—those who have the skills to apply its new languages and architectural designs will be more in demand than those who stick with the current COM-based technologies such as ADO and Visual Studio (VS) 6.0. However, I don't recommend ADO.NET or .NET-generated applications for everyone. Sure, the new technology is cool and alluring and it might be the solution for some troubled Active Server Pages (ASP) or COM architectures, but many organizations still need the server-side functionality that's still unimplemented in ADO.NET.
Developers who know what's going on behind the scenes in SQL Server will be especially sought after because they not only know the mechanics of how to create efficient applications, they also know why these high-performance solutions work best. In addition, the market will reward developers who design scalability and performance into their database and application designs instead of trying to tack performance patches on later. Web sites and the applications that feed and expose them in particular will need to perform better, protect data better, and be less expensive to create and support than other applications. Developers who understand how to create highly scalable solutions that can handle a few million extra customers will be in high demand.
I recommend that SQL Server developers hone their knowledge of the available tools. Get smarter on both ADO and ADO.NET—they're very different. COM-based ADO is the veteran technology with complete support for existing client/server designs. ADO.NET is unproven, but it's the product of many years of intensive research at Microsoft and far better suited for most Web-based and middle-tier solutions than ADO is. (For more information about the differences between ADO and ADO.NET, see Dino Esposito, "ADO.NET: A Bridge to the Future," June 2001, InstantDoc ID 20744.) Developers, even if you don't plan to use .NET, become familiar with its architectures and the features it implements. That way, when it's time to start a new project, you can say with confidence: "I can do that easily with .NET" or with equal confidence: ".NET isn't the best approach for this solution. We can use ADO."
At this point, some of you are out of work and others are expecting to soon join the lines at the unemployment office. After I was laid off the first time, I found that the time I invested in my skill set was worth the effort, and learning new techniques and processes gave me something to do every day. Since then, each time I've been out of work, I've forced myself to learn a new language or learn how to write to a new platform. I did most of this training on my own. With no employer to pay for seminars or classes, I usually bought a few books and started experimenting. For those fortunate enough to work in an industry that's not in a downturn, the same advice applies—keep learning and growing. Every industry from fast food to forestry and from fishing to technology has changed so dramatically in the last decade that someone returning after a long sleep wouldn't recognize what's going on. Don't be caught napping when your boss comes by with a fistful of pink slips.
