We can ask heretical questions such as why OOP should be used in all programming situations as many of its proponents insist. We can question the wisdom of allowing C programmers to write the narratives and code examples for the Help system in VB.NET. We can wonder why structures are included in VB.NET if OOP experts insist that you should never use them.
We can freely applaud VB.NET when it improves on traditional VB programming features (streaming and serialization, for instance), and point out when VB.NET creates needless confusion. (Some collections in VB.NET are zero-based; some are one-based. And there's no rhyme or reason involved, no pattern you can discover, no rule you can learn, to deal with this problem.)
Another benefit of being outside programming and academic officialdom is that we can be clear. There is a lingo developing around programming, and too much of it appears to serve no real purpose other than job protection. If others cannot read your source code, or even understand your comments, then it's likely they'll respect you and you'll keep your job. Likewise, if you follow the party line and keep your geek-speak up-to-date, you'll be on the team. So the usual little closed society of a priest class is being built. Remember that only a short time ago mass was said in Latin, a language that the churchgoers couldn't understand. And if you visit a college class in music theory or film theory today, you won't comprehend most of what's being said.
When we do now and then indulge in techie jargon in this book, it's usually to let you know what's meant by the latest catchphrases. True, the term overloaded signature is used in this book, but right next to it is the parenthetical explanation (more than one argument list), just so you'll know what the heck is being discussed. And when terminology, such as strongly typed, has several different meanings, we point that out to you.
There's one final benefit derived from the authors' status as independent writers, free of any obligation to particular corporations or institutions: we can be entertaining, or at least less boring than the average computer book. Academic articles and books, including many programming books, deliberately avoid amusing or interesting writing. It's thought in some circles that if your writing isn't obscure or tedious, then you must not be discussing anything sufficiently serious. We take the position that honest, understandable, direct, and interesting writing is preferable to the alternative.