What does it take to become a SharePoint developer? You should understand how SharePoint looks to a user, and the best way to learn that is by using it. You should know where to find the documentation for the object model and for CAML, and that means lots of Googling because it's not all in MSDN by any means. And then of course you need to be a developer. Mike Fitzmaurice makes it pretty clear that means an all-around good .NET developer. He's inspired by Gregory MacBeth's inaugural blog post that lists the steps to becoming a good SharePoint developer. Gregory sets the bar pretty high - step 0 is get your MCSD, and then the real learning can begin. My attention was caught by Mike's postscript that in addition to being an all-round .NET dev, in VB or C# as you prefer, and learning the SharePoint-specific material, you're also going to need C++:

Attention tool builders and other interested developers — in the next release, protocol handler development and IFilter development will still need to be in C++.  Do not wait for the rules to change, because they won’t (at least not before “v4”).  If you want to extend our search technology to new content sources and formats, you might as well get started now.  Search gets a lot better in many ways, but the method for developing IFilters/protocol handlers isn’t one of them.

So, all round .NET dev, SharePoint object model, CAML etc, and while you're at it, C++. No wonder I'm finding good SharePoint devs rather hard to find!

Kate

Sessions and abstracts, along with speaker names, are starting to appear on the Tech Ed sessions page. My C++ talks have been christened DEV 330 and DEV 331. You can search on the session code or my name to see the abstracts.  Doesn't look like you can start to build your calendar yet, but watch for it.

Since the speaker dropdown is populated, I just had to check: I counted 8 Brians, and 11 obvious women, not counting the chances that an Alex, Chris, or Pat could be a woman. I also see some fellow RDs and some Speaker Bureau folks. Should be a fun week!

Kate

How's this for a party? A five-day C++ conference, C++ Connections, held in conjunction with Visual Studio Connections,  ASP.NET Connections, and SQL Server Magazine Connections from Nov 7-11 2005 in fabulous Vegas at the marvelous Mandalay Bay resort. My standard introduction line on C++ matters is “I've been working in C++ since before Microsoft had a C++ compiler.“ It isn't 20 years for me (I never used cfront) but it sure is close.

Think you could speak there? The call for papers is on Herb Sutter's blog. Am I speaking there? I hope so, I will report back with details when I have them. This is going to be fun!

Kate

I'm going to be travelling across Canada in April and May to deliver the next round of Deep Dives -- these ones on Smart Client development with VSTO 2005. Here's the abstract:

Recommended Audience: Developer.

Microsoft Office has established itself as the standard for office productivity applications. Knowledge workers use the Office tools (word and excel) to create and mine data. The experience and familiarity with these tools can be leveraged to build a new breed of applications to make working with important information easier using Word and Excel as application interfaces.

This session will explore the details of creating Smart Client Applications using Microsoft Office System and Visual Studio Tools for Office. This session will include data access techniques for online and offline work, security considerations and leveraging the .NET Framework and web services to interact with Line of Business applications. This session will also provide attendees with prescriptive guidance on choices for application development, comparing all the possibilities for smart client development, in the form of a decision matrix.

Here's the schedule and some links to register:

	Ottawa	April 19
	Waterloo	April 20
	Windsor	April 21
	Vancouver	April 26
	Calgary	April 27
	Halifax	April 28
	Toronto	May 3
	Montreal	May 4

I am preparing the material right now, and it's all Visual Studio 2005 and VSTO 2005 -- if you've seen me do VSTO 2003 material before, you're going to be delighted with the new tool! It's much more designery and much less “now simply provide implementations for the following 20 functions with almost identical names.” That means there's time to show cooler stuff, and I fully intend to. See you there!

Kate

I went over to the MSDN Canada site to get some question of mine answered, and got completely distracted by today's poll. The results as of this morning:

Hmmm....

Kate

I'm a little late getting this blog posting up... I kind of had to recover from the event. Sam rolled into town in the early afternoon and what a blast! The pre-event agenda was gossip, code names, and assorted gems I will not be sharing. Plus great sushi -- in Whitby, much to my surprise -- and plenty of geek talk. For the event itself we were in a new venue and had to sort out some logistics around projecting and such, but it worked in the end. We had about double our usual attendance. I have never seen so much note-taking! Then when the crowd left, it was time for beer and more discussion, until the dreaded “you don't have to go home, but you can't stay here.” Time for Sam to meet a true Canadian institution... Tim Hortons . Other blog entries on the evening: Eli, Sam, and Jean-Luc. Though I notice Sam neglected to mention that he actually likes C++/CLI .

If you're an INETA speaker and you haven't come to my group yet, you don't know the fun you're missing. Just say the word, and I'll request you. And if you live within an hour or two's drive of Oshawa or Whitby, and haven't been to a meeting yet, resolve right now to come to the next one. It may not feature beer, but you'll be glad you came.

Kate

Back in the 80's, one of the classic anecdotes around corporate gender unfairness was the idea of the meeting that finished up in the mens room, inaccessible to the women left standing in the hall. If this  is how those meetings went, we were worried for nothing.

See you at Tech Ed, guys!

Kate

Last night I spoke at the Metro Toronto .NET Users Group on Interop between J2EE and .NET apps, using a variety of techniques but especially Web Services. There was a bit of code, but really the emphasis was on philosophy, the kind of “big picture” approaches you can take to make interop happen. I mentioned more than once that it's important to know what exactly you mean by interop and what it is that you want your two (or three, or more) applications to be able to do together. The sorts of projects that really don't work are the ones that start “how can we use BizTalk in our firm?”. Start with a business problem, and if it looks like BizTalk will make it possible to solve the problem, then go from there, but don't pick the solution and then go looking for a problem.

This came back around in the post-presentation questions and chat, and we got to talking about the importance of requirements. I'm hip deep in a project where we spent months just settling the requirements, but as a result the project has moved forward into code after spending years (before I came on board) getting about halfway through design and then stopping and starting over. For Enterprise work (and these interop issues are generally Enterprise) there is simply no substitute for real solid business requirements that are completely nailed down before anyone starts designing, followed by a properly thought through design. I don't go through all that for three day projects, putting together a little Sharepoint web part or some Windows Service that sends email at night about additions to the database today, but I sure go through it for anything that needs more than one programmer or that will take more than a month.

I was reminded of a funny article I read a while back called Agile Bridge Building, which mocks Agile Software Development by dissing bridge design in favour of showing the client Working Wood as soon as possible. Basically, you stick a log out into the river and right away you've started to build your bridge. This process naturally produces requirements, since now we have consensus that the log should actually reach all the way to the other side of the river! Why waste a lot of time in meetings trying to develop this requirement in advance? Once there's working wood, a genuine prototype, the stakeholders can quickly agree on what's important. And all without the hassles of paying someone for requirements and design. There's more, so I recommend you read the whole article. And to be honest, if I lived in the woods and was sick of wading through a small stream to get to the far side of my property, I probably would apply Agile Bridge Building to the problem, just as I don't particularly design every speck of software I write. But I'm glad the folks who built the bridges I drove over today designed them first, and I'm glad I know how to gather requirements, get consensus on functionality, and design the big projects I code before I code them.

Kate