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!
Pingback: Jason Haley
So, just out of curiosity, who are the other Architects on the VB team?
You have sealed you own DOOM for now I’ll never stop bugging you.
The features in VB9 are looking pretty awesome. I’m really excited about how easy it is becoming to express yourself with type-inference and the Object-Initializer syntax. Does this apply to methods too or just property assignments? Can we use it for collections in addition to arrays?
So here’s the issue I see (something to thing about for vNext). The more we can express in one line the longer that line becomes. VB has a fairly kludgey line continuation syntax and I think as the language become more and more expressive it’s something you’re going to have to deal with.
I’m NOT SUGGESTING SEMICOLONS or mandatory line termination characters as currently there are as many cases when I don’t need to break a line (if not more) than when I do. However I can’t help admiring the T-SQL parsers in the regard. Very rarely do I need to terminate a T-SQL statement with a `;’ no matter how many lines I stretch it across or what follows it. Looking at VB I see no reason why we should need either mandatory line continuation or termination. The compiler can currently tell when a physical line is not a complete logical line so it could be extended to look for logical lines independent of physical ones. Looking at my code there are obvious tell-tale markers for this.
`(` marks the beginning of a method call. Until the -matching- `)’ is encountered the line cannot logically end. Notice that though the outer method call will be line terminated the compiler places no restrictions on the inlined function calls that make up its parameters. Same way with `<‘ and `>’ on attributes. Binary operators such as `&’, OrElse, =, etc imply a second operand as does `,’ imply another element of an array initialization or another parameter of a method call (as the compiler will tell you currently). Which if not found on the current physical line might be searched for at the next physical line (or valid token, really). A Function declaration has certain parts it must have and until hitting that `As Type’ or `)’ in the case of Subs that logical line isn’t over.
Now the problem enters with the rules of where these markers have to be – must the binary operator be on the line being continued or can we look for it also on the following line if the current line ends abruptly? And dealing with rare ambiguities (I haven’t thought of any yet) where the following line could be validly compiled as a continuation of the current as well as the start of another (obviously a `Dim’ on the next line suggest that it’s not a continuation). And performance of this more flexible parsing.
In short, line continuation and termination characters are more often than not superfluous and for VB to remain (or become depending on your point of view) an elegant and expressive language you need to seriously look at how you can better support your end users’ expressiveness.
P.S. This array declaration by bounds thing is pointless if you can’t change the bounds and every coder I run into tries to do it by capacity and it’s really messing up their code.
Pingback: Public Shared SergeB.Blog()
Craig: I don’t think any of them actually have blogs or an Internet "presence," so I don’t know if I can really "out" them, but I’ll point them out if they surface… 🙂
Anthony: The line continuation question is something that we definitely are thinking about. Nothing to mention yet, but it’s certainly the case that there are a lot of situations where they could be no longer required…
I noticed you all took care of it for Xml literals, for which I’m very grateful – great job on that!
Pingback: Panopticon Central