Visual Studio 2010 / .NET Framework 4 Release Candidate [UPDATED]

visual studio 2010 logo

If you’re looking for the latest and greatest version of Visual Studio, you’ll want to get your paws on the Release Candidate for Visual Studio and .NET Framework 4.0! It was made available to MSDN subscribers yesterday (if you’re an MSDN subscriber, you can download it immediately), and will be available to the general public tomorrow, Wednesday, February 10.

The changes in the Release Candidate (RC) are based on your feedback from the Beta 2 version and include improvements to:

  • General UI responsiveness (including painting, menus, remote desktop and VMs)
  • Editing (typing, scrolling, Intellisense)
  • Designers (particularly Silverlight and WPF)
  • Memory usage
  • Debugging (stepping, managed/native interop)
  • Build times
  • Solution/project load times

Here’s a Channel 9 video featuring Visual Studio General Manager Jason Zander talking about how the Visual Studio team addressed the feedback you gave for Beta 2:

Get Microsoft Silverlight

The team has tested the RC on all the projects they could get their hands on, but not all the projects in existence. That’s why we’re making the RC build freely available to you so you can try it out on your projects! We want to hear from you, so please give the RC a try and let us know what you think via our survey site.

In the meantime, the Visual Studio team is working closely with vendors who’ve created popular Visual Studio add-ins, such as Resharper, CodeRush and so on to make sure that Visual Studio 2010 works with them.

Update: An Extra Note from Scott Guthrie

Our goal with releasing the public RC build today is to get a lot of eyes on the product helping to find and report the remaining bugs we need to fix.  If you do find an issue, please submit a bug report via the Visual Studio Connect site and also please send me an email directly ( with details about it.  I can then route your email to someone to investigate and follow-up directly (which can help expedite the investigation).

This article also appears in Canadian Developer Connection.


Hello, Kodu!

kodu game lab

Last week, I presented Kodu (pronounced “Code-ooh”) to a group of teachers and high school students at Corpus Christi Catholic Secondary School. Kodu is a system created by Microsoft Research for programming videogames without using a traditional programming language; instead, you use a combination of menus and visual programming. It was designed to be a gentle introduction to programming that would appeal to children, but many adults – myself included – have ended up getting drawn into it, spending hours constructing and tweaking game worlds.

Kodu was built using XNA, Microsoft’s framework, toolset and runtime environment for building games for Windows, Xbox 360 and Zune. It was released for the Xbox 360 last summer as an Xbox Indie Game; you can download it for 400 Xbox points — about 5 bucks – or you can try the free trial version (it’s time-limited, but full-featured). If you don’t have an Xbox 360, you can download the Windows version of Kodu for free.

Kodu’s a little tricky to describe – it’s one of those things that’s much easier to show rather than tell. Here are a couple of videos that should give you a bit of Kodu’s flavour. First, here’s IGN’s look at Kodu:

Here’s XNA Roundup’s review of Kodu:

Kodu was designed to be programmed with the Xbox 360 gamepad, which you can use if you’re programming it on the Xbox 360 or a computer (if you’re using a computer, you’ll need either a wired Xbox gamepad plugged into one of its USB ports or a USB adapter for your wireless Xbox gamepad). If you’re using Kodu on a computer, you have the additional option of using the keyboard and mouse.

This is the first of a series of articles on Kodu programming that will appear here from time to time. If you’ve got kids (or know some) who are curious about programming, or if you’re looking to try a completely different kind of programming, get Kodu on your Xbox or PC and give it a try!

In this first installment, I’ll show you how you can build a simple little program that lets you drive an avatar around a small world. In later installments, I’ll show you more game-like elements and the “code” for a game of mine called “Stupid Sparkling Vampire Game”.

Touring Teran00bia

In addition to a programming “language”, Kodu provides you with tools for editing the worlds in which your games take place. I often start with a simple, no-fuss world that I created called “Teran00bia”. It’s a small, flat square world suitable for experimentation. If you have the Windows version of Kodu, you can download Teran00bia here. I can also share the Xbox 360 version, but you have to “friend” me on Xbox Live first – my gamertag is “Accordion Guy”.

Teran00bia is a blank slate, a world with nothing in it. Here’s what it looks like when you load it:

kodu 00

In this exercise, we want to stick a single character – Kodu – into the world and allow the player to drive him around using the controller’s left stick.

To start programming, get into Edit Mode. Press the “Back” button on the gamepad to switch to Edit Mode. Your screen should now look like this:

01 world view

In Edit Mode, the left thumbstick moves your “cursor” (the purple “donut”) around the world, while the right thumbstick changes your camera angle. You use the left bumper (that’s the button just above the left trigger) to zoom out and the right bumper (the button above the right trigger) to zoom in. The screenshot below shows a zoomed-in view of Teran00bia:

02 closer up

The floating icons near the bottom of the screen make up Kodu’s menu. You use the left and right triggers to scroll through the menu and the A button to select a menu item.

Select the Object Tool from the menu. It’s the second menu item from the left, and its icon is Kodu, who looks sort of like a blue fish with an antenna. When you select the tool, the Kodu menu disappears and you’re now using the object tool, as shown below:

03 about to add

The Object Tool lets you add items to the world or edit any existing ones. There aren’t any items in the world at the moment, so let’s add one. Use the left thumbstick to move the cursor to the spot where you want to place an object, then press the A button. The following menu will appear:

04 add menu

This menu lists the items available to you. Starting at the top and going clockwise, the items in the menu are:

  • Kodu (the game system’s mascot, who can be used as either a player character or a non-player character)
  • Apple (useful as a health power-up, but nothing stops you from making them poisonous or explosive)
  • Bots 1 (a set of characters that can be used either as player characters or non-player characters)
  • Bots 2 (more characters that can be used either as players characters or non-player characters)
  • Objects (things that characters in the game can interact with, such as rocks, coins, castles and factories)
  • Tree (another object that characters in the game can interact with – I have no idea why trees weren’t part of the set of Objects)
  • Path (lets you draw paths which Kodu and the other bots can follow)

Use the left thumbstick to select Kodu from the menu, then press the A button to confirm the selection. A Kodu will appear:

05 kodu added

You can move Kodu around by pressing the A button to select him, using the left thumbstick to pick a new location and then pressing the A button to drop him there.

What we want to do is program Kodu to move in response to the left thumbstick, as is the convention for most Xbox 360 games. While Kodu is selected, press the Y button. The screen should look like this:

06 programming

Every programmable object in the Kodu game system has a set of behaviours, each one having two parts:

  • When, which describes the event that the object will respond to
  • Do, which describes what the object will do in response to the event

The behaviours are numbered starting at 1 and are listed in order of descending priority – that is, behaviour 1 has first priority, followed by behaviour 2, then behaviour 3, and so on.

Your programming “cursor” is the pencil. Move the pencil over the “+” in the “When” part of behaviour 1 and press the A button. You’ll see a menu pop up:

07 when menu

This menu lists the events to which Kodu can react. For now, we’re concerned with making him respond to the left thumbstick, which is part of the gamepad. Select “Gamepad” from the menu with the left thumbstick, then press the A button to confirm the selection. The menu will vanish and you’ll see that a “Gamepad” tile has been added to the “When” part of behaviour 1:

08 gamepad added

We need to specify which gamepad control Kodu should respond to. Make sure the pencil is over the “+” of the “When” part of behaviour 1, then press the A button. A menu containing various controls on the gamepad will appear:

09 gamepad menu

Use the left thumbstick to select “L stick”, then press the A button. The menu will disappear and you’ll see that the “When” part of behaviour 1 has two tiles: “Gamepad” and “L Stick”:

10 ks added

We’ve just described an event that Kodu should respond to. Now it’s time to describe the response. Move the pencil over the “+” of the “Do” part of behaviour 1 and press the A button. A new menu will appear:

11 move selected

This menu lists responses to events. In this case, we want Kodu to move where the player tells him to move, which is specified by the left thumbstick. Select “Move” from the menu with the left thumbstick, then press A to confirm the selection. The menu will vanish, and you’ll see that a “Move” tile has been added to the “Do” part of behaviour 1:

12 move added

We’ve now completely defined a single behaviour for Kodu: “When the player moves the left thumbstick, move in that direction”. It’s time to take our (admittedly simple) game for a spin.

Press the Back button to stop programming Kodu. You’ll now be in the Object Tool. Press the Back button again to return to Edit Mode, where Kodu’s main programming menu will become available. Use the left trigger to select Play Mode and press A to confirm the selection.

13 play selected

The program will start with the intro screen. Press A to dismiss the intro screen.

14 opening screen

You’ll now be in the game world. Use the left thumbstick to move Kodu around:

15 gameplay

Kodu moves, but he’s not so fast. Let’s look at a way to speed him up a little. Press the Back button to exit the program and return to Edit Mode. Use the triggers to select the Object Tool from the menu, then press the A button to confirm the selection.

16 stopped

Move the cursor under Kodu so that he’s selected:

17 kodu selected

Press the Y button to program Kodu. You’ll be return to his set of behaviours:

18 current program

Move the pencil over the “+” of the “Do” part of behaviour 1, the press the A button. A menu will appear:

19 quickly selected

The menu will contain modifiers for the “Move” response. Select “Quickly” from the menu using the left thumbstick, then press the A button. The menu will disappear and you’ll see a “Quickly” tile has been added to the “Do” part of behaviour 1:

20 1 quickly

To make Kodu move even faster, you can add another “Quickly”:

21 quickly selected 2

…in fact, you can add up to three “Quickly” tiles to push Kodu to his maximum speed:

23 3 quicklies

Play Around

I could cover more Kodu features, but you should use it the way it was meant to be used – experiment! Try adding other objects to the world and adding behaviours to them. Take a look at the  programming behind the worlds that were provided with the Kodu game system (be sure to check out “Left 4 Kodu Classic”, a cute Kodu version of the zombie thriller game Left 4 Dead).


This article also appears in Canadian Developer Connection.


CUSEC 2010 Keynote: Douglas Crockford – The Software Crisis

doug crockford

At long last, the fifth in my series of notes taken from keynotes at CUSEC 2010, the 2010 edition of the Canadian University Software Engineering Conference. These are from Douglas JavaScript: The Good Parts” Crockford’s keynote in which he talks about how hard it is to make software. Doug is a senior JavaScript architect at Yahoo!, the guy behind JSON, wrote one of the first important pieces on JavaScript’s unrealized power and utility and in a former life wrote videogames (of which he has some interesting stories).

My notes from his keynote appear below.

The Software Crisis

"I made the first important discovery of the 21st century: that JavaScript has good parts!"

  • The Software Crisis dominated the computer industry for a decade: 1960s
  • The crisis was that software projects were becoming too complex to manage
  • Projects were:
    • Over budget
    • Late
    • Unreliable
    • Not fully meeting their requirements
    • Unmaintainable
    • Failing
    • Insecure (this is a relatively new thing)
  • The software crisis isn’t over — we’re now in year 45
  • It never went away, we just stopped talking about it
  • "In other news, the sun will eventually exhaust its supply of hydrogen"

Craft vs. Engineering

  • Some people said that we weren’t bringing enough engineering discipline to the practice of programming
  • Some said programming isn’t the same thing as engineering and therefore engineering discipline doesn’t apply
  • Both miss the point
  • The real problem with software is that it’s the most complex thing we make
  • It requires perfection, which humans aren’t good at
  • It’s amazing we can make software at all

Software construction

  • Computer science has taught us lots of things, but not how to manage software projects
  • In some ways, building software is like any other sort of construction
  • But in some other ways, it’s quite different
  • You have to keep in mind that "construction" when applied to software is just a poetic metaphor
  • Take the case of building a wall:
    • It’s easy to estimate, based on the size of the wall how much time it will take, and also how far progress will be at any given time during its construction.
    • Try doing that with software!
  • Part of the problem is the nature of software
    • It’s both powerful and malleable
    • The qualities are both a blessing and a curse
  • One problem: The lack of metrics
    • There’s no objective measure of quality or completeness
    • We can test software, but the tests are on the same level of quality as the software being tested
    • Consider one of the old stand-by metrics: LOC (lines of code)
      • It’s not an indicator of quality
      • Nor is it an indicator of completeness
  • Another problem: Estimation is difficult
    • Programmers, by nature, are optimists
    • You have to be and optimist to do this kind of work! You wouldn’t be able if you weren’t
    • "I think rational people could not do programming"
    • As a result, we’re probably the least qualified people to do estimating
    • What doesn’t help is encouragement from management like "You’re a smart guy, you should be able to do it in 3 months!"
  • Another problem: Programmers don’t understand how they spend their time
    • They think they spend most of their time typing
    • Measurements show that most of their time is actually spent in meetings or tech conversations
    • (And there’s also the time spent staring at the screen going "My God, what have I done?")
    • As a result of this disconnect between perception and reality, programmers tend to be skeptical of process improvements that might require more keystrokes
      • [Story about developer who refuse to switch from a CamelCase naming scheme to a words_delimited_with_underscores naming scheme]
      • The programmer had an emotional attachment to the CamelCase naming scheme and argued that the underscore-based scheme slowed things down
    • Consider the first rule of optimization: optimize the process that is taking the most time
    • When it comes to programming, that process isn’t the typing!
    • It’s the thinking, worrying and puzzling
  • Programming is a social activity
    • Solo cases are the exception
  • Cost of innovation
    • Doing what’s been done before vs. doing what hasn’t
    • We’re constantly doing things we haven’t done before
    • That’s most likely to lead us to mistakes
  • Legacy
    • In other industries, legacy is seen as the wealth of practice and tradition, the wisdom of experience
    • Not ours! In software, past accomplishments are considered to be a liability
    • The age at which programs become "legacy" is getting younger and younger
    • Some programs become legacy before they’re finished\
    • No industry disrespects legacy the way the software industry has


  • Software is not governed by Moore’s Law; it’s governed by Murphy’s Law
  • Leaps tend to come at 20 year intervals, not two year intervals
  • Leaps make it possible to implement more complex projects
  • Adoption of "leaping" software technologies tends to be very slow
  • Common responses to leaps: controversy and reluctance
  • Leap 1: Plugboards


  • Single machine programmable with plugboard
  • The original spaghetti code
  • Leap 2: Symbolic assembly language
    • The first software tool — the first program to make it easier to write programs
  • Leap 3: High level languages
    • In the 1960s, there was a lot of research on automatic programming
    • It was believed, even back then, that programming too complex and error-prone for humans to do
    • We wanted to get computers to write programs for us: we’d feed them specifications; they’d output programs
    • The result? FORTRAN
    • Still a leap forward
    • Even today, with DSLs, it’s still progamming
  • Leap 4: Structured Programming
    • Getting rid of GOTO
    • Let us write more complex programs
    • Argued for 20 years as to whether it was good idea to get rid of GOTOs
    • People who benefited most and opposed were programmers
    • Arguments and counter-arguments
    • "Had to wait for those guys to get old and die"
    • So today, virtually all our languages are GOTO-less
    • Good thing — more sophisticated programs possible
    • What was the fuss all about?
  • Leap 5: Object-Oriented programming
    • 1967: Simula released
    • 1972: Alan Kay begins Smalltalk, which was originally intended for children
    • Most of good today in tech owes a debt to Smalltalk
    • 1980: Smalltalk released. Smalltalk took 8 years — Netscape spent 8 weeks getting JavaScript ready!
    • 1985: C++ released. Essentially some of the good ideas in Smalltalk added to C
    • 1995: Java released
    • 2004: PHP with version 5 says "Okay, we’ll do it that way too"
    • A lot of time has passed between 1967 and now. Simply because a new good idea appears means it won’t be adopted quickly
    • OOP is not the last leap. It’s just that we’re so fixed on objects that we can’t see past them
  • So we’re late for the next leap
    • I think it’ll be distributed programming, the idea of taking n components and put them together to make a functioning application
    • Will live in the cloud
    • Nobody thought that we’d see signs from the next step forward in JavaScript and browsers, but that’s where it’ll likely come from
  • Some Failed Leaps
    • Artificial intelligence
      • Intelligence is much harder to understand
    • 5th generation languages
      • Japanese invested heavily it, but without much result
    • Computer-aided software engineering
      • Reborn in IDEs
    • Subjective-oriented programming, etc.


grace hoppers bug

  • Software does not have enough self-awareness to be afraid of bugs. That’s why it works as well as it does.
  • The term “bug”  is attributed to Edison, who used them to refer to flaws
    • From the Pall Mall Gazette, March 11, 1889: "Mr. Edison, I was informed, had been up the two previous nights discovering a bug in his phonograph."
  • Ever since then, defects in inventions have been called bugs and it’s become part of popular culture
  • There’s also Commodore Grace Hopper’s bug, a literal bug: a moth caught in the relay of a Navy electromechanical computer.
    • She pasted moth into her logbook
    • It’s the "first actual case of a bug being found"

Snake oil

  • Even though we know better, we love "silver bullets"
  • We tend to like people who make fantastic promises to fix our problems, if we just follow some crazy methodology of theirs:
    • Diagramming?
    • Documentation style?
    • Have all your meetings standing up?
  • Saying "nothing works" is discouraging; I’d like to give you a better story
  • The Mythical Man-Month
    • Written by Fredrick Brooks; I highly recommend this book
    • He said a lot of things in the book that seemed unreal at the time, but they were proven to be true over time
    • The source of what we know as Brooks’ Law: "Adding manpower to a late software project makes it later."
    • One of the first books to show an understanding that programming is social
    • Another idea in the book: the Second-System Effect
      • Take a team of programmers who’ve done something brilliant
      • Give them a blank slate for the next project
      • The result? They fail…hard
      • Why? They become overconfident. Their earlier success causes them to overreach
    • Another idea in the book: Prototyping
      • Software is like waffles: Make the system, throw it away, make it again
      • Counter to the notion of getting it right the first time)
      • "Make the first one to throw away" turns out to be a good idea
    • One last concept from the book: "A project become a year late one day at a time"
  • Literate Programming
    • Created by Donald Knuth
    • The idea: Programs designed to be read
    • I’ve seen lots of good programs done in this style
    • It doesn’t appear to work well in groups yet — but that’s mostly what we’re doing now
  • Incrementalism
    • The basic idea: "We’ll see you in two weeks" vs. "See you in two years"
    • Disappointments are smaller and more frequent, which are easier to manage; it lets us manage our expectations
    • It also makes us less ambitious, but that lack of ambition is helpful
    • It avoids second system problem — this doesn’t let you dream big
    • The project is always a beta, and perpetually unfinished
    • The downside of incrementalism:
    • There’s the potential that your project will become something like the Winchester House in San Jose
      • Built by Mrs. Winchester, wife of the Winchester behind Winchester guns
      • Her husband and child died tragically, and a medium told her that they were killed by the spirits of people killed by the Winchester repeating rifle
      • She was warned that they’d come after her too unless she found some way to confuse them
      • She came up with the idea that as long as she kept working on her house, the spirits would not find her
      • So her house was constantly under construction, with hired people adding new things to it all the time
      • It was built up incrementally. "This is an agile house!"
      • End result: things like stairways leading up to a ceiling:

winchester house stairs

      • "You’re programmers, you know what happened here!”
      • Chimneys that didn’t go up all the way to the ceiling

winchester house chimney

      • No rhyme nor reason
  • Go watch Mr. Blandings Builds His Dream House (1948)
    • It’s the best movie ever made about project management
    • Blandings’ problems:
      • Lack of knowledge of technology
      • Poor control over requirements
    • [Joey’s note: This movie’s been remade in modernized form with Tom Hanks in The Money Pit(1986) and Ice Cube in Are We Done Yet? (2007).]
  • Feature Cost
    • Development time
    • Deployment cost
    • Maintenance cost (bloat, cruft)
    • Download time
    • User confusion/training
    • Bug delivery
  • Code Value
    • Microview: good coding conventions
    • Macroview: good architecture
  • We need better program architecture
  • Architecture is hard, but conventions is easy
  • Think of how hospitals were improved just through simple conventions of hygiene, such as washing your hands
    • The simplest thing we can do to increase the value of our code is to make it readable
      • For example, when returning a value from a method, we should use return value, not return(value) — the latter implies that return is a function
    • Whatever improves human parsing of programs is helpful
  • Communicating
    • You should think of programs as a medium of intentional communication:
      • Communicating detailed instructions with the machine
      • Communicating with your development community
      • Communicating with yourself (and especially your future self)
  • Good architecture is about not collapsing into a puddle of confusion, and should enable you to change a correct program into another correct program
  • Cruft
    • It’s software scar tissue
    • Comes from lots of sources:
      • Premature optimization
      • Inexperience
      • Misread source
      • Feature enhancement
      • Death marches (which are the most avoidable source of cruft)
      • As cruft accumulates, complexity grows and progress slows
  • Eventually, the code itself becomes a source of friction


  • It’s "software obesity"
  • In the old days, memory was expensive and you didn’t get much of it, so your programs were lean by necessity
  • Having only 8K – 64K of RAM in a machine put incredible constraints on what you could do
  • I used to dream of the day when memory would cheap and abundant enough so that we wouldn’t have to do evil things to get programs to fit
  • Now I wonder if maybe those constraints weren’t so bad
  • "Bugs hide in those rolls of fat in our programs"
  • Insecurity
    • Most programs these days have marginal security
    • Programs that once didn’t have security implications now do
    • Any bug is potentially a security bug
    • Good secure programming is good programming
    • Thinking about security might make programming easier
  • Refactoring
    • The process of code refinement, involving things like:
      • Correction of formatting
      • Insertion of documentation
      • Removal of cruft and bloat
      • Restructuring
  • Perhaps we should take advice from Exodus: "Plant and harvest crops for six years, but let the land rest and lie fallow during the seventh year."
  • Maybe do six sprints where you add new features, but on the seventh sprint, don’t add new features at all
      • Sometimes the best course is to start over
        • This is quite difficult to accept
        • The pain of the crash
          • Loss of a week’s work, a day’s work, an hour’s work, is unbearable
  • The illusion of completion
    • "It’s in the can!"
    • I once worked as an expert witness on conflict between 2 game companies
      • The original game company had split up; the new company was being sued for plagiarizing the original company’s game engine
      • I reviewed both game engines and determined that the new game company had written a whole new engine in 2 month — they’d learned for the experiences writing an engine for the old company
      • The owner of the old company couldn’t accept that; he thought the value of the codebase was 100 man-years, not 1
      • An experienced team can redo what they just created quickly. The team’s focus must be on simplicity to avoid second system effect
  • Have regular code readings
    • Don’t wait until release to do code reviews
    • Do team code reading regularly during development
    • Problems can be discovered early
    • Good techniques can be shared early
    • Experienced developers can lead by example; novice developers learn from the group
    • They should be: frequent, helpful and respectful
      • You need a healthy team – a dysfunctional one will tear itself apart


  • Quality first. Quality last.
  • Readable code. Code reading.
  • Invest in the quality of your code base.
  • Invest in your programmers and managers.
  • Quality is the most important feature.
  • If you look at all the polished, completed code you write at the end of a year, you could type it all in a day
  • Typing is not what we do; it’s thinking and communicating

This article also appears in Canadian Developer Connection.


The Evolution of Type Taste from Grade School to Present


You young’uns may have learned about typefaces and the difference between serif and sans serif from using the “font” settings on your computers, but I learned from using Letraset (and often, its budget-priced brother, Geotype). They were sheets of rub-down transfer lettering and clip art. The principle behind Letraset wasn’t all that different from temporary tattoos. The stuff went the way of the dodo once desktop publishing and laser, inkjet and dye sublimation printers caught on.

Graphic artist and typeface fancier Jessica Hische – who recently wrote the brilliant “The work you do while you procrastinate is the work you should be doing for the rest of your life” – posted this great graphic showing the evolution of her type taste from grade school to the present day. Click it to see it at full size. Oh, I remember my Helvetica Condensed Black Oblique phase…

Jessica Hische's "Evolution of Type Taste from Grade School to Present" -- from Curlz to Archer and Gotham

This article also appears in The Adventures of Accordion Guy in the 21st Century.


Lessons from the Other Side

Sheep Canada and Other Perspectives

Cover of "Sheep Canada" magazine

Every now and again, I make it a point to pick up some reading material on a field or industry that’s completely unrelated to my own. I find that it both satisfies my curiosity and helps me see things from a completely different perspective. In one particular case, when I found a copy of Sheep Canada lying abandoned on a subway seat, I enjoyed the puzzled and concerned looks from the other passengers as I read the magazine. Not only did I get a little entertainment, but I learned a little bit about what goes into making the lamb chops and sweaters I love.

I also like asking people questions about their work, especially if it’s in field different from my own. It probably stems from the fact that everyone in my immediate family is in medicine; I’m the “black sheep” who went into computer programming. I often chat with my wife and her co-workers at the University of Toronto’s Mark S. Bonham Centre for Sexual Diversity Studies (a fascinating line of work, by the bye), my father-in-law about that branch of the insurance industry that concerns itself with executive benefits, friends who work in the television and movie industries, and so on. I love hearing their stories and find that seeing their perspectives broadens my own.

I’ve even taken on little non-developer side jobs just to get a different perspective. I’ve moved an entire warehouse of high-end dresses, had a fair bit of success as a street musician, gotten ink-stained at an old school print shop and even had a stint as an accordion-playing go-go dancer at a Toronto nightclub.

You Go Hither and I’ll Go Thither

It’s this “wanderlust of the mind” that probably led me, a guy who was actually quite happy in the “develop on the Mac, deploy on Linux” world, to becoming a Developer Evangelist with Microsoft. Each world has its own history, culture, customer base and approach to technology, and each offers lessons to the other. As I’ve said before, technology is a great big smorgasbord, where there are enough seats and dishes for everyone and every taste. Wouldn’t it be a waste if you stuck only with the dishes you knew?

I’ve spent the last year getting reacquainted with the Microsoft development world, and it’s different in many ways. There’s the obvious stuff such as operating systems, programming languages and tools. There’s also the more subtle stuff: conference demographics and what people do in the hallways at conference, the sort of apps that get written, what people do in their spare time and so on.

Don Dodge

Don Dodge is experiencing the same thing…just in reverse. Just as I’ve gone from being a Mac guy to running Windows 7 as my primary operating system, he’s crossed over from Windows to the Mac OS and writing about his experiences with the transition in an article titled From MSFT Evangelist to Mac Enthusiast – The Other Side of the Road.

There are some lessons to be learned from Don’s observations, a fact that wasn’t lost on Todd Bishop. In his article on Don’s “switching” experience, he writes:

This sentence, in particular, caught my attention: "After years of defending Microsoft against the Apple fanatics I decided to go to the other side of the road to see for myself," Dodge writes.

Good for him, but the fact that he hadn’t seen the other side of the road as a Microsoft employee is a symptom of a larger problem at the Redmond company. Loyalty to and appreciation for your own products is nice, to a point, but after interacting with people at Microsoft for the better part of the past decade, I’ve never quite understood, logically, why it’s taboo for its employees to use competing products.

…think what would happen if Microsoft employees experienced and saw around them, every day, a true reflection of the competitive landscape — including Microsoft products and rival technologies. My hunch is that they’d come away with a better understanding of what motivates specific consumer actions, and how they might be able to get consumers to pick Microsoft products instead.

Todd, you took the words right out of my mouth. It’s right along the lines of my own philosophy, which I wrote about in the article Evangelist, Immigrant and Shaman:

What Microsoft needs badly is a shaman. They need somebody who is situated physically within their culture, but outside it spiritually. This isn’t a person who hates Microsoft, but it’s a person who can actually see it. I can do this for you. Give me a hut in your parking lot. I will eat mushrooms, roll around in your cafeteria, and tell you the Goddamned truth.

Awkward family photo featuring family in the Sunday best with one boy in biker leather.

It’s the style in which I do my work. Yes, I devote a lot of time and effort to Microsoft’s tools and technologies, but I make sure that they’re not the only things I look at. I try to keep abreast of things like the IDE conventions in XCode, what’s happening in the worlds of the iPhone and Android, non-Microsoft languages and frameworks such as PHP, Python and Django, Ruby and Rails, templating systems like HAML and Sass and the NoSQL movement. Each has lessons (the Microsoft term is “learnings”, which I refuse to use, since I consider it a non-word) that can be incorporated into the Microsoft world, just as I’m sure that we too have lessons to offer to these other worlds. And in the end, we’ll all get better tools and technologies for our work, life and play.

It’s something you should try as well. Try using some tool or technology that you wouldn’t normally use. Hang out with developers from “the other side”. Pick up a copy of Sheep Canada. Broaden your perspective and see what you’ll learn!

This article also appears in Canadian Developer Connection.