Back in December, when discussing my bout of writer’s block, I said that I should probably write an entry “What the Hell I Do [at Microsoft],” since I think that the question is sometimes a little murky (even to me). Most of my career I was just a “developer” or “manager,” but now that I am an “architect,” things are a little more complicated.
As far as I can tell, “architect” is such a general title at Microsoft that it’s practically meaningless. It can mean totally different things in different organizations. In my case, being an “architect” seems to mean:
- I’ve been around a long time.
- I’m a developer (more or less).
- I don’t manage anybody.
(For those paying close attention, my title when I started this blog was “Technical Lead,” which was an even more meaningless term, especially since I used to be a “Technical Lead” on Access when I was much, much, much more junior. And I believe that my title will soon change to “Principal Architect,” which only means that if you’re an internal Microsoft person, you’ll have a general idea of what my career ladder level is.)
I should also be clear that I am an architect working on Visual Basic, not the “architect of Visual Basic.” There are at least three other people who work on Visual Basic that share the title of “architect” with me, all of whom do wildly different things. Basically, we’re just a bunch of senior developers who didn’t want to manage people but were useful enough to keep around anyway.
So that’s my title, but what do I actually do? Well, my standard cocktail party answer is “go to meetings and write emails.” And (very) occasionally write blog entries. However, if you wanted to pin me down a bit more, I tend to spend my time doing the following:
- Attending language design meetings. We tend to have two hour design meetings every week on Monday and Friday to talk about Visual Basic language design. This is where we hash out new ideas, work through details, and deal with followup issues. With where we are in Orcas, it’s mostly followup issues at this point, but we should start gearing up to do some early thinking about post-Orcas soon.
- Writing the language specification. This is a seasonal activity, so to speak, since it’s really only done later in the release cycle when the various individual feature specifications have settled down. It’s sort of a last formalization step for all the features and a chance for me to do a pass through everything we’ve decided. I’m actually just about to start this for Orcas.
- Doing community stuff. This includes blogging, going to conferences and giving talks. I don’t do a huge amount of this in any one year, but it’s something I’m trying to do more of.
- Writing code. Amazingly enough, I still do this. It tends to be what we call “long-lead” work, though, stuff that’s maybe a little further than prototype but not real production. For example, I did a lot of work on getting the first couple of LINQ CTPs (the pre-Orcas CTPs) out the door. And I’m doing a lot of work right now on some other code that might appear a little at MIX and (I hope) a lot more at the PDC.
- Answering questions. As the longest serving member of the language team, I get a lot of random questions from people about design questions, past and present.
- Talking to other teams. Whatever I’m working on usually interacts with other teams in some way, shape or form. With LINQ, I spent a lot of time talking with the C# team and SQL team. With the stuff I’m working on now, I’m spending a lot of time talking with other teams. Coordination is frequently the name of the game.
- Trying madly to keep up with my email. Like the rest of the universe.
Of course, what anyone does at Microsoft always tends to be a moving target, so I’m sure I can write this same entry each year and it’ll be a little different each time. I guess that’s what keeps life interesting!
In my “