I finally got around to listening to the last recorded webcast in this spring's Ignite Your Career webcast series from Microsoft Canada. Joey has a handy set of links to all the episodes on the Canadian Developers Blog. This series is very different from most Microsoft webcasts - it's not really about technology. It's about the things you need to learn to advance your career that are not straight technology like picking up a new language or a new development paradigm.

• Industry Insights and Trends (featuring Joel Semeniuk)
• Discovering Your Trusted Resources (featuring Richard Campbell)
• How to Establish and Maintain a Healthy Work/Life Balance
• How to Become a Great Leader (featuring Barry Gervin)
• Building, Managing and Strengthening Your Team
• Women in IT Panel Discussion

All the webcasts have been recorded and are well worth a download and a listen.

Kate

I grew up in Southern Ontario (Kitchener Waterloo area) before moving to Toronto and now to my current home between Toronto and Peterborough, which possibly isn't Southern Ontario any more. Imagine my surprise, reading an article in The Economist, to come across this:

Ms Munro comes from southern Ontario, an area of considerable psychic murkiness and oddity. Her stories dwell on her own people and their peculiarities: their repressed emotions, respectable fronts, hidden sexual excesses, outbreaks of violence, lurid crimes and long-held grudges.

Psychic murkiness, eh? If you say so.

Kate

Well, obviously some programmers are poor communicators, just as some programmers are good painters or poor singers. But Leon Bambrick (Secret Geek) says "the better you program, the worse you communicate." And he means it. Basically good programmers have a number of habits that work well when talking to (or listening to) a compiler, but hurt you when you're dealing with people. And the comments dig in to the "how can I get better?" part of the problem. Worth a read.

Kate

Further to that video of Brian Noyes and client technologies, Tim Huckaby has written a terrific paper on the topic. His personal history and experience position him perfectly to understand the real technical reasons (as well as the make-your-boss-happy or the go-home-on-time ones) why you should use a "smart client", "rich client", "Windows client" application for certain kinds of applications. He also knows when you shouldn't. Definitely recommended reading and if you want to tell him your thoughts, he's set up a blog post for comments.

Kate

We have all worked with star developers. When I come into a client to mentor, occasionally they have one developer who is just a star. I can pretty much spot them in the first half hour these days. Other times they have a developer who would say "I am a star" but who wouldn't get that designation from me. Tim Stall has a nice list of things that make a developer a star. As I went through the list I was thinking "yes! yes!" and finally "hire! hire!" which is also what happens when I meet real stars. (Don't worry, I have never poached a dev from a client and never would, but "would you hire this person" is still an incredibly useful summary of someone's skills.) I especially like "22. Knows when the rules do not apply". It can't be taught, and dear heaven can people get this one wrong. When you meet someone who gets this right, it is such a relief.

The list doesn't tell you how to become that sort of person, but I am quite sure the rest of the Internet has some hints. So will I if I meet you in a mentoring context.

Kate

An illuminating post from Dr. Rick Kirschner on bringing out the best in others. He gives ten specific rules, which act as nice reminders only after you've read the paragraphs that go with each. A lot of this maps well to things I am doing and things I have read elsewhere, but in far longer than a paragraph. Other things, like "useful assumptions" are new and bring me an "aha" that I enjoy.

Read it over and see if you don't learn something.

Kate

Stephan has blogged some breaking changes to the STL in beta 1 of VS 2010. These are breaking in the sense that your old code, which worked, might not work when you move it to the latest release. I had this with a demo (not real code) that didn't bother #including <iterator> because it was including something else that included it etc. So my old code wouldn't build in Dev10. Simple enough fix to add the #include.

That alone (4 simple problems, and how to fix them) makes the post worth reading. But it's also a fantastic example of the transparency and visibility the team blog provides. Look at this sentence:

In VC10 Beta 1, I added operator->() to CAdapt, allowing v[i]->Something() to compile unchanged. 

Not "we added". Not "it was decided to add". Not "some faceless decider, whose motives and reasoning are not accessible to the mere mortals who just read our decisions, added". Simply "I added". Stephan, STL, a real person whose posts we can recognize by font alone, added an operator. I think as C++ developers we are a very lucky lot, to have this kind of window into how and why the tools change as time goes by.

The conversation continues in the comments, btw. On the C++ team blog, if a post interests you, you should always read the comments too. Folks ask stuff and team members (not always those who posted the original) answer.

Kate

Oooh, I like this a lot.

That is a little snippet from a query of work items in VS2010 (cropped from a larger pic obviously). You can add a work item and then add other work items that are part of it, break it down into smaller pieces just as though you are in project. This is a huge deal for me! I found this as part of an incredibly long and comprehensive post (with a dozen screenshots) on Brian Harry's blog. This is going to be a must-upgrade for me just for the VSTS stuff - and I love the new editor, and plenty more besides. So far not a single project I've upgraded has had any issues, they've all just worked.

Kate