The path toward becomming an "expert" Windows developer used to be pretty straightforward.  You needed only the most basic understanding of C++ to qualify for a job (if you could define a virtual function and explain the "slicing" problem, you were in), you worked your way through Kruglinski's introductory text on MFC, skimmed each month's issue of "Microsoft System's Journal", and eventually learned to check the index of Prosise's "Programming Windows With MFC" and the Table of Contents of the "MFC Answer Book" before starting any feature, since there was a good chance the authors had already done most of your work for you.  After two or three years of implementing features, you'd probably gotten around to tackling "MFC Internals", and Richter's "Advanced Windows", and maybe Cooper's "About Face", and one or more of McConnell's treatises on process ("Rapid Development", "Code Complete"...), which would put your skills pretty much on par with those of senior Windows developers working just about anywhere.  If you were REALLY concientious, you might have picked up a copy of Petzold's "Programming Windows", the GOF's "Design Patterns", and maybe even a few business-side books like Cusumano's "Microsoft Secrets" -- and then tried to figure out how any of this related to pounding out new features in whatever convoluted MFC mess you happened to be maintaining.  For tools, you relied exclusively on Visual Source Safe and the Visual Studio IDE, and probably watched with detached interest every year or so, as managers fended off some wild-eyed radical agitating to switch to Borland's OWL.

The last time I set aside some serious "study time" between jobs (on that occassion, it was involuntary -- the company shut down and laid everyone off), I had already done all of the above, and I ended up spending ten months hanging out in coffee shops, reading Eckel, Meyers, and others on C++, and programming simple demos in DirectX, before taking what turned out to be a really great opportunity, writing a DX-based digital video editing utility at a hardware startup.  At the time, I had actually been toying with the idea of getting into game development (what developer hasn't?), but suicidal margins were taking out those companies left and right, with a thousand eager job candidates for any position at one of the remaining "name" companies.

Since then, of course, the bar for attaining (and maintaining) any degree of Windows developer "expertise" has been raised, requiring continuous monitoring of dev. community RSS feeds, evaluation of CTP builds of upcoming technologies, and a reference library of critically important material from Lowy and Sells and Richter... and that was BEFORE this wave of .Net 3.0/3.5 tools and technologies that's now looming overhead.

In my current "sabbatical", I'm exploring different ways to architect and implement non-trivial WPF/WCF/WF/Linq applications, while trying to maintain the discipline required to write associated unit tests, and work within the confines of a continuous integration build environment.  I'm trying to understand issues like whether it is still useful, in WPF, to apply the WinForms technique of centralizing marshalling of communications to the UI thread in the business layer (via AsyncOperation), BEFORE raising events to the UI.  Are there situations where data binding to UI elements is NOT a practical strategy?  When is it better to set bindings manually, versus relying strictly on Xaml (via ObjectDataProvider etc.)?  How should source code be organized to best support CI automation?  How do implementation strategies, such as the use of the Singleton pattern, impact unit testing, Xaml integration, and the ability to "hand off" the entire UI layer to designers working with Blend?  Is there a real net benefit to adding extra architecture layers just to support unit testing of the UI?  If so, is it better to use some canned framework like SCSF/Acropolis, or just to roll your own, as Jeremy Miller has suggested?  I've also spent a surprising amount of time and energy resolving issues with open source tools, many of which suffer from REALLY poor documentation, and sometimes don't want to play well together.

I figure its going to take me another month or two before I'm satisfied that I'm able to provide definitive direction to a development department, rather than having to suffer someone's else's WAG (Wild *ss Guess) approach to implementation or dev. process.  My timing may have been a little early, in terms of widespread .Net 3.0/3.5 adoption and available job opportunities, but as long as I haven't jumped the gun by two or three YEARS, I think I can probably endure this pain and suffering a while longer.

Now, if you'll excuse me, my latte's getting cold, and I want to finish testing this new validation strategy in time to catch a matinee at the theatre next door...