Random thoughts to up and coming developers.


A few days ago I had a colleague drop an “interested” computer science student off at my office to talk about “stuff”.  I talked with this individual for about twenty minutes, I had no specific goals, but after reflecting back on the conversation I thought it might be worthwhile doing a bit of a brain dump.

So first off, some context, for the last year I have been working on services related to the Xbox One.  Now that we’ve launched I feel a bit more willing and able to talk a bit about my experiences.

First off, my path to where I’m at hasn’t ever really been straightforward, but one constant has been a strong love technology and a desire to actually work in it.

I spent a long time in college, I always new I wanted to work on software but it took me going through some rocky life lessons to really apply myself.  However eventually I did learn those life lessons and apply myself I did.   I think this drive and my enthusiasm for software is what really got me into Microsoft.

So I guess my first piece of advice to students looking to get a job in software.  Love what you are going to be working on.  Make sure you are going to enjoy working at a computer for eight to twelve hours a day, you’re going to be doing it for a long time,  assuming you keep the same general career path.  I’ve seen the difference it makes and trust me, the person who is happy to invest themselves into what they are doing is always going to “win” over someone who doesn’t, they’ll have a better career trajectory and they’ll be better at what they do.  So Love what you do, it will help keep you happy which will help keep people around you happy.

My next piece of advice for college students in particular is to never overestimate any experience even if it’s “free unprofessional work”.  Join hobbyist groups that are doing something like what you want to do.  Work on projects for yourself.  Just go out and do some programming, the more you do it, the better prepared you’re going to be for working in the “real world”.   I cannot stress enough that working on stuff even if it’s only for a weekend or two will be good for you.  If you can work in a group on something even better.  The reality is that most software is not written by one person but by groups of people.  If you’re going to be a good developer you are going to have to learn to program with other programmers.

Don’t shy away from failure.  Heck fail spectacularly.  Sometimes  you need to fail ten or twenty times before you succeed spectacularly.  Failures are just life experience, they help you learn how to judge your limits, how to push beyond them or even that limits exist.

Learn to use source control, difference based code reviews, unit testing and the idea of gated builds.  These are all part of the real workflow a professional developer does.  At Microsoft we use a couple of different solutions for source control but one that is publically available is Team Foundation Server.  We use TFS internally and there are often free options host on the TFS web services for small development projects (of five or fewer people).  TFS is also great in that if provides a lot of the tooling to get to the other big process (gated build, code reviews, and visual studio solutions support unit test projects).

Learn about patterns, use them if you understand why it is appropriate otherwise just  focus on writing code that is a simple to understand as possible.

So that’s my advice.

Now, here’s what it’s been like to be a “professional” for me.  When I started at Microsoft I actually started out in Testing.  I worked developing automation and testing publishing of applications within Visual Studio.  At least within Microsoft where much of what the test organization is responsible is repeatable automation, programming is a big part of what you do day to day.

Writing automated tests is an art form in that you have to balance the long term value gained from the automation against the specificity of the validation it does.  As a simple example it’s pretty easy to write a test that does something like open Word and type a few lines of text and then validated the text shows up.  It’s a little harder to decide what you should check about the text.  For example: does the default font, borders and paragraph style matter?   The question of “what matters to the customer” combined with “what do we specifically want to prevent breaking” pretty much define the goal of automation.  Of course there’s many other things testers do at Microsoft.

Over time I worked myself deeper into the test tools and eventually made a transition from tester to developer.  Initially the difference wasn’t terribly obvious because I worked on the same test tools used within the Visual Studio organization I had been working with.  As I described it I went from owning test cases to owning test framework bugs.  Over time that changed though and I spent more time working on things outside of  the test automation framework I owned.

Eventually I moved to work on Xbox Live. I did this to broaden my experience to work on services but also because I’m very passionate about games.  I’ve been playing games since the original NES days.

I spend about fifty percent of my time actively writing code to either fix bugs or create new features.  The rest of my time is spent debugging , inspecting logs and other evidence to understand problems, going to meetings and dealing with other communication.  As a tester I did a wider variety of things, but to be honest I love code so much that being “just a developer” has actually been a bit better of place for me to be.  Of course just because I’m a developer doesn’t mean I don’t test, I still write unit tests and validate any changes I do before checking in.

Primarily I write code in C# but I have also worked in VB .Net and C++.  I also am passingly familiar with PowerShell scripting (I suspect I’ll end up getting better as I find more usages for it in my current role) and have written more batch scripts that I like to admit.  To be honest the more I’ve worked in software, in many ways code is code is code.  Different languages will tend to lead to different types of mistakes but in the end software is deterministic (given you can replicate the exact circumstance and timing) and does exactly what it is programmed to do.

Working on a console as it is being built is both more and less glamorous than you might imagine.  Getting to see early versions of the hardware can be both exciting and frustrating because often things are fairly non-functional.

You can often see the potential very early on for what each thing might be.  As the development cycle moves on, a lot of things that are abstract demos turn into real features.  Some things get cut, you learn to focus on what matters to the core experience versus what is nice to have, or can be done later.

You argue and fight to get things done right, to make sure that the final experience is good and the systems work in a way that is manageable.

Sometimes you build something, change it, change it, change it and then look at it a few weeks later after someone else has changed it a few times.  At this point it’s completely unrecognizable, sometimes for the best, sometimes you liked how it was before better.

Things break, then work then break again before working.  Then suddenly all the rushing around to get stuff done hits a high point where you are barely at home at all.  To be honest you’re so embroiled in just getting that last bit done you don’t quite realize just how much time you’re actually in the office.  Then it all stops, everything that is going to be done for launch is done, you need to stop and watch it go out.

I was a complete wreck of nerves on launch week.  I had two things going on, first I volunteered to be in the office during the graveyard hours for that week to be there in case any issues arose.  So I had to completely reverse my sleep schedule.  That by itself would have resulted in not getting great sleep.  But also launch week is all anticipation, there’s not much you can do but wait for things to happen.  I only slept for about three hours each night during that week.  I spent all of the rest of my time in the office or getting ready to be in the office.

You try to prepare yourself for figuring out any problems that might crop up.   Then it’s launch night.  At 3 AM a small group of us gathered under the three story countdown timer to get a quick snapshot of the first transition from “countdown” to “released”.  We shuffled back to our offices and watched with baited breath our telemetry.

After twenty minutes we started to see traffic to our service increase significantly as people start using the features that use our service.  It’s real, real people in the real world are seeing and using stuff I worked on for the first time.  It’s exciting, terrifying and wonderful all at the same time.

As it turns out this launch was great, our services worked better than expected, the one major issue we had was out of our control and quickly resolved.  So the celebratory mood kicks in.  We partied, and we partied hard.  And while I spent that first week of launch in my office during the hours of 2AM to 10AM (and actually I was around for a lot more time than that), it was spent doing what I love.  Playing games on a console I helped make while watching and seeing that code I wrote was being used by thousands of people.  Yes, I helped make Xbox One.  That’s what it’s like to work in software.