I sincerely apologize that comments are disabled on my blog right now.

I dislike one way conversations.

However, it turns out that spammers have caught up to the technology my blog used circa 2010 to filter out nasty and wretched comments. I simply can't keep up with deleting them by hand any longer.

I am, of course, always interested in your emails and feedback. Please feel free to shoot me a note at joedu AT microsoft DOT com if you are so inclined. I promise to read and respond.

And I sincerely hope that within the next month I'll manage to upgrade my blog software. It seems like a daunting task for some reason, even though it is trivial in nature.

I have several positions open on my team here at Microsoft.

My team's responsibility spans multiple aspects of a research operating system’s programming model. The three main areas are concurrency, languages, and frameworks. When I say concurrency, I mean things like asynchrony and message passing, data and task parallelism, distributed parallelism, runtime scheduling and resource management, and heterogeneity and GPGPU. When I say languages, I mean type systems, mostly-functional programming, verified safe concurrency, and both front- and back-end compilation. And when I say frameworks, I mean virtually anything you could imagine wanting out of a platform framework: all things XML, data interoperability (database, web services, etc.), collections, transactions, multimaster synchronization, and even low level things, like regex, numerics, and globalization.

Our team is 100% developers, and we have an “everybody codes, everybody loves to code” culture. Even managers are expected to spend a significant amount of time prolifically writing code.

All of these components are new and built from the ground up. So self-drive and an ability to have a vision and make it happen are incredibly important.

We are always happy to hire great, hard-working people, regardless of years of experience. If you’re extremely strong in one or more of the abovementioned areas, more of a generalist, are an amazing coder, or all of the above, you’d fit in perfectly. This is the most amazing team of people I’ve ever worked with. If you are interested, please email your resume to me at joedu AT microsoft DOT com.

My team is hiring.  For example:

https://careers.microsoft.com/JobDetails.aspx?jid=7594&lang=en

As the job description says, we are focused mainly concurrency & parallelism at each layer of the system: kernel-mode, user-mode, frameworks, languages, compilers, ...

The sky is the limit and nothing is off the table.  I've never had so much fun in my life as I am having right now, and couldn't imagine a better group of people to do it with.  I think this is what NT must have felt like.

If you're interested, email me at joedu AT microsoft DOT com, or apply via that link.

A developer from the Parallel Extensions team, Igor Ostrovsky, recently whipped together a really neat Silverlight game.  It's called RoboZZle, and he calls it a "social puzzle game":

"RoboZZle is an online puzzle game that challenges players to program a robot to pick up all stars on a game board. The game mechanics are simple, yet allow for a wide variety of challenges that call for very different solution approaches." (from the blog entry introducing it.)

The coolest feature of this game is that you win by programming.  And there's a whole community surrounding it, complete with forums, the ability to create your own games, a ranking system, its own blog and continuously updated news, etc.  Check it out.

I just returned from TechEd Australia, which was a lot of fun.

I have a fair number of additional speaking engagements coming up:

• JAOO in Aarhus, Denmark (next week) [http://jaoo.dk/conference/]: Parallel Extensions
• PDC in LA (precon on Oct 26) [http://www.microsoftpdc.com/]: Concurrency pre-con
• TechEd EMEA in Barcelona (Nov 10-14) [http://www.microsoft.com/emea/teched2008/]: Parallel Extensions
• QCON in San Francisco, (Nov 19-21) [http://qconsf.com/sf2008/conference/]: Functional programming and parallelism

As of the PDC the book will also be readily available.  Wahoo!

If you'll be at any of the conferences and want to meet up, please drop me a line.

I have two new positions open on my team.

1. http://members.microsoft.com/careers/search/details.aspx?JobID=955B4B91-F863-492C-B839-63964E7966B9
2. http://members.microsoft.com/careers/search/details.aspx?JobID=6B22807F-71BF-4939-ACB4-EC380106AFBF

If you want to shape the future of the runtimes, languages, and libraries that millions of developers use every day, this is a perfect opportunity.

And you'll get to workwithsomeamazingpeople too.

You can submit your resume on the website or just email me at joedu @ you-know-where dot com.

I've been very remiss with blogging lately.  This was mostly due to travel (5 weeks out of the past 2 months), but also because I'm focused intensely on the book, and have been super busy working on Parallel Extensions: the December CTP, hiring for our team, planning what we do in the next year, designing stuff, implementing stuff, ... it's been a lot of fun.  I've also been trying to learn classical guitar after 15 years of playing electric and some acoustic (metal, rock, blues).  It's more challenging than I anticipated... I guess I should have started when I was six.

Somewhere in there, I recorded an episode of .NET Rocks with Carl and Richard about Parallel Extensions: check it out.  I haven't listened to it yet, but I distinctly remember having a lot of fun.  When the hour was up, I couldn't believe how quickly the time had passed.

Happy New Year, everybody.  I promise to blog more in the coming months.  Famous last words, eh?  ;)

My book, Concurrent Programming on Windows, is shaping up quite nicely.  (Given that I've been working on it for over a year now, I suppose it had better be!)  I’ve been surprised at the amazing level of anticipation and excitement from blog readers, coworkers, and Microsoft customers, and I really can’t wait for it to be finished.  Thanks for the patience so far.

I feel like I’m almost on the home stretch.  End of September is my current target for completion.  It’s looking like it’ll contain 18 chapters, with 3 appendices, and will have a total running length of somewhere around 700 pages.  The reasons it has taken so long are numerous, but the primary reason is that the content is quite deep and detail-oriented—more than I expected at the start—and I’ve wanted to take the time to get it just right rather than cut corners.  My editors recently gave me feedback that there will be very little developmental editing required, since I’m (ahem) very, uhh, meticulous when it comes to writing.  And feedback from technical reviewers has been very positive as well.  I think both are good news.

I’m confident the end product will be worth the wait.

In the meantime, it seems that some of the abstractions I’ve built while writing the book will likely become part of a future release of the .NET Framework.  Keep an eye out on Channel9 for some additional details in a few months time.  Right now is a super exiting time to be in the field of computer science, that’s for sure...  Laissez les bons temps rouler!

It's coming to be that time of year at Microsoft: review time.  Actually, it's a multi-month process, but the first step involves assessing how well (or, in some cases, how poorly) you've done at certain tasks you set out to pursue a year prior.  Part of this process also involves discussing career aspirations with those who care to listen and help, which usually means your manager.

So, Joe: What do you want to be when you grow up?  ;)

Technical Fellow is the highest title at Microsoft awarded to technical contributors.  Some TFs manage people too, but most do not.  According to Microsoft.com, there are 18.  Two people I work with closely, Anders Hejlsberg and Burton Smith, are TFs, and, until just recently, Jim Gray was also.  There are others I know and recognize, but I am not deeply familiar with all of them.  This lead me to wonder about the contributions and accomplishments the others have had throughout their careers, and so I did some reading.  Aside from causing a bit of depression and a realization that I have quite a long mountain to climb ahead of me, I ended up reading Butler Lampson’s immensely wonderful paper “Hints for Computer System Design” (HTML, PDF).

Yeah, yeah, I’m only 24 years behind the times.  In the paper, Butler provides many sound principles backed by concrete examples illustrating tradeoffs between functionality, speed, and fault-tolerance, drawn mostly from his experience building operating and distributed systems.  As I read it the paper, I was struck by how much his advice applies to building just about any kind of complicated software system, including frameworks.

A few random teaser quotes:

“Designing a computer system is very different from designing an algorithm:

The external interface (that is, the requirement) is less precisely defined, more complex, and more subject to change.

The system has much more internal structure, and hence many internal interfaces.

The measure of success is much less clear.

The designer usually finds himself floundering in a sea of possibilities, unclear about how one choice will limit his freedom to make other choices, or affect the size and performance of the entire system. There probably isn’t a ‘best’ way to build the system, or even any major part of it; much more important is to avoid choosing a terrible way, and to have clear division of responsibilities among the parts.”

---

“Do one thing at a time, and do it well. An interface should capture the minimum essentials of an abstraction. Don’t generalize; generalizations are generally wrong.”

---

“Keep secrets of the implementation. Secrets are assumptions about an implementation that client programs are not allowed to make. In other words, they are things that can change; the interface defines the things that cannot change (without simultaneous changes to both implementation and client). Obviously, it is easier to program and modify a system if its parts make fewer assumptions about each other. On the other hand, the system may not be easier to design—it’s hard to design a good interface.”

---

“One way to improve performance is to increase the number of assumptions that one part of a system makes about another; the additional assumptions often allow less work to be done, sometimes a lot less.”

---

“When in doubt, use brute force. Especially as the cost of hardware declines, a straightforward, easily analyzed solution that requires a lot of special-purpose computing cycles is better than a complex, poorly characterized one that may work well if certain assumptions are satisfied.”

Needless to say, I strongly recommend the paper.  Now back to my career planning.  I think I’ll start by writing a prolific and influential paper that will still be highly relevant, quoted, and recommended 24 years into the future.  Thankfully I'm still comparatively young so if I get started soon I just might be around to see the 24 year mark.

Long time readers will remember that I used to regularly blog about what I've been reading lately. (See here, here, here, and here for examples.) Well, it's been close to a year since I've posted such a list. So here's a little bit of a clearance of my back- log. (And this isn't even everything! I guess I read a lot.) I've separated the list into geek and non-geek books.

Geek books:

The Soul of a New Machine -- Tracy Kidder

10 of 10. I'm only 16 years late on this one. This book is about DG's race to build a machine to contend with DEC's VAX, and has some great story telling. It reads almost like a fiction book, with great character building, a nice storyline running through the book, etc. The geek factor is low on this one, though I suppose it _is_ a book about a bunch of geeks building hardware, so it's a little up there. Evidently it won the Pulitzer prize.

Programming Pearls -- Jon Bentley
	10 of 10. Another one in the category of "how the heck did I not read this sooner?" This book is a collection of essays on various programming tasks, and gives tons of insight on engineering software in general. The prose is even entertaining too. This book now occupies a special place on my bookshelf.

Java Concurrency in Practice -- Brian Goetz, et. al

10 of 10. This is a very down-to-earth, pragmatic overview of concurrency in Java. It even has chapters on testing and debugging, which get very little coverage in most articles but are clearly important. Though its focus is on Java, many of the ideas are more general, and thus it's a must-read for any serious Windows or .NET concurrency programmer. It's not as good as my upcoming book, but given that you can't buy mine yet, it will do for now ;).

The Old New Thing: Practical Development Throughout the Evolution of Windows -- Raymond Chen

8 of 10. I'm sure everybody who reads my blog reads Raymond's too. If you do, then the book will be quite familiar to you. It's a collection of essays, most of which are edited versions of ones that have appeared on Raymond's blog in the past. I really like the layout and organization of chapters. One downside: Raymond apparently tried to keep it from becoming too geeky (he mentions several times, "for you non-programmers, you can skip this chapter"), but c'mon: how many non-programmers are actually going to read this book? IMHO he should have just let loose and never looked back.

Software Pioneers -- Manfred Broy (editor), Ernst Denert (editor)

8 of 10. This book is a collection of classic articles by precisely what the book's title suggests, software pioneers: Friedrich L. Bauer (ALGOL), Ole-Johan Dahl (Simula), Niklaus Wirth (Pascal), Fred Brooks (Mythical Man Month, OS/360), Alan Kay (GUIs), Rudolf Bayer (B-trees), Peter Chen (E/R modeling), Edsger Dijkstra (obvious), Tony Hoare (CSPs, axiomatic semantics), David Parnas, John Guttag (abstract data types), Michael Jackson (JSP), Tom DeMarco (structured analysis), Michael Fagan (code inspection), Barry Boehm (engineering economics) and Erich Gamma (design patterns). Most of the papers are available on the net, but having them in a printed hardcover is really nice. There are also some new write-ups and an accompanying CD which contains talks from all of the above people. Nice.

An APL Compiler -- Timothy Budd
	8 of 10. An overview of Timothy Budd's APL compiler, from front to back end. (For those not up on APL, it's a great language. See the next item.) Also contains a chapter on compiling high level program statements to vector ISAs, which is quite timely and interesting.

APL with a Mathematical Accent -- C. A. Reiter, W. R. Jones
	8 of 10. This is the best overview and reference book on APL I've encountered to date. For $120, you get the cheesiest binding and printing ever, so be prepared to be disappointed in that department, but the content is well worth it. Covers APL from start to finish and has some handy reference charts.

Inside OS/2 -- Gordon Letwin

8 of 10. I picked this book up after reading Larry Osterman's blog entry about how acquiring a critical section in OS/2 effectively suspended all threads in the system until it was released. Sure enough, that's how it worked. Funny. Anyway, this book was fun because it takes you back in time, and, since Gordon was the chief architect for OS/2, the writing gives a ton of insight into software design and architecture when OS/2 was being developed. Though there is plenty of detail which is fairly useless today (like how to specifically use DosCWait), I enjoyed skimming it.

Dreaming in Code: Two Dozen Programmers, Three Years, 4,732 Bugs, and One Quest for Transcendent Software -- Scott Rosenberg

7 of 10. In the style of Soul of a New Machine (see above), this book takes you through the development of Chandler, a start -up software project lead by Mitch Kapor, the founder of Lotus. I generally agree with most of the reviews on Amazon: the book idea was good, the writing is very good, but the project he chose to follow was crap. As far as I know, Chandler is now dead, and the start-up didn't seem like a place buzzing with immensely passionate people, no matter how hard the author tried to convey that. He should have chosen Windows Vista or something ;).

Non-(computer-)geek books:

Molecular Gastronomy: Exploring the Science of Flavor -- Hervey This

10 of 10. This is THE book on molecular gastronomy, literally. Hervey basically invented the field, from what I understand, and this book is a great collection of easy-to-read essays on the topic. You'll walk away with a better scientific understanding of what cooking is all about, including how various new-age techniques work, and perhaps even the confidence to try some of it out on your own. This is a must read for any serious food geek.

The Making of a Chef: Mastering Heat at the Culinary Institute -- Michael Ruhlman

10 of 10. In this book, the author enrolls at the Cullinary Institute of America (CIA) and goes through basically the full cirriculum. The book is written excellently, and you feel like you're right there in class with him. And you certainly walk away with a deep and lucid appreciation for those who are slaves to the knife, cooking up delicious food because they love it. I was considering a stint at the CIA ... until I read this ... I'm now convinced that I couldn't handle it ;).

This is your Brain on Music: The Science of a Human Obsession -- Daniel J. Levitin

10 of 10. So many of you probably don't know that I'm a music geek too. I write a lot of material -- actually, I've been writing a whole lot more lately -- though I don't play live at all anymore. This book has some light introduction to music theory, but the great part is the way the author dives into cognitive neuroscience and the effect of music on people, their brains, and their psychology. The book is incredibly unique and will instill a newfound appreciation of every nuance of that next breakbeat you hear.

The Soul of a Chef: The Journey Toward Perfection -- Michael Ruhlman
	10 of 10. Great follow-up to The Making of a Chef. The delves into the make-up of a chef, starting with the master chef exam at the CIA, and then profiling two chefs: Michael Symon (Lola) and Thomas Keller (French Laundry, per se). While the whole thing is great, the 1/3 of the book devoted to Thomas Keller makes the book wortwhile.

Heat: An Amateur's Adventures as Kitchen Slave, Line Cook, Pasta-Maker, and Apprentice to a Dante-Quoting Butcher in Tuscany -- Bill Buford

10 of 10. I couldn't put this book down for a whole weekend, and then I was sad when it was done. The writing is extraordinary, and makes you feel like you're there, learning to make various pastas, to be a line cook at Babbo in New York, to try and learn what you can from Mario, and to travel to Italy to learn from some very interesting characters indeed. Easily one of my favorite reads from 2006.

A Cook's Tour -- Anthony Bourdain

9 of 10. After reading Kitchen Confidential, I couldn't not read A Cook's Tour. Anthony is extremely entertaining, crude, and raw. That's what he does best. This is the book version of his late TV show with the same title. In it, he travels the world, tasting regional cuisines and reporting "from the trenches". Lots of mouth watering street food, bizzare encounters, exotic beverages, etc. If you can't afford to do a foodie world-tour yourself, this is the next best thing.

Guns, Germs, and Steel: The Fates of Human Societies -- Jared M. Diamond

9 of 10. This book needs little introduction. It won the Pulitzer prize, after all. The book describes how certain socieites came to dominate various geographies of the world, including (as the title suggests) the role of guns, germs (disease), and steel in the process. For obvious reasons, the writing is a tad dry, but it's so jam packed full of interesting data and written incredibly methodically, both of which more than make up for the dryness.

The Omnivore's Dilemma: A Natural History of Four Meals -- Michael Pollan
	9 of 10. This book takes you through many different forms of eating, from corn and our new industrialized food system, to farming, to hunting and foraging, and beyond. Each section concludes with a meal characteristic of one particular style of food creation. Though at times the writing gives a hint of an agenda, the writing is generally excellent, and many facts are presented for consideration.

The Reach of a Chef: Beyond the Kitchen -- Michael Ruhlman
	8 of 10. This is the third of Ruhlman's XXX of a Chef series of books, and I really enjoyed it. This one looks at chefs and their influence inside and outside of the kitchen. That includes Grant Achatz (of Alinea), how he studied under Keller and became an American pioneer of molecular gastronomy, various Food TV celebs, and so on. Great read.

The Essays of Warren Buffett: Lessons for Corporate America -- Warren Buffet, Lawrence A. Cunningham (editor)

8 of 10. Sometime in 2005, I stumbled across the archive of Warren Buffet's letters to the Berkshire Hathaway shareholders, dating back to 1977. I immediately printed them all out and have a stack of many 1,000 pages in my office to this day. Though they are fairly lengthy, there are many great lessons to be learned from reading them. This book is an edited down version of those essays. Very edited and abridged, actually, but some of the more important points are pulled out and analyzed. And the best part is that if you want to drill into more detail, all of the letters are available online.

Judgment of Paris: California vs. France and the Historic 1976 Paris Tasting that Revolutionized Wine -- Michael Ruhlman

7 of 10. All wine lovers need to read this. I gave it 7 out of 10 simply because the writing style is actually pretty bad IMHO. But the content itself is great, and of historical signifciance. Wikipedia has a page on the event, but in summary, in 1976 many Bordeaux 1st growths, etc. were pitted against various California winemakers in a blind tasting. The tasting was held in Paris, and the judges were all French. Everybody believed the US wines would fall short, but it turned out that the US fared quite well: the book is the story of events leading up to and including this tasting.

The Nasty Bits: Collected Varietal Cuts, Usable Trim, Scraps, and Bones -- Anthony Bourdain

7 of 10. To be entirely honest, this book was VERY entertaining, but fell a bit short of my expectations. This is a collection of fairly disjoint essays, almost the kind of thing you'd expect to see on a blog. Each reads very well on its own, but it lacked the kind of cohesive feel I was looking for. Nevertheless, Anthony is always entertaining, crude, funny, and makes me laugh. This book was no exception.

Prior to coming to Microsoft, I had been a developer for about 6 years.  Back in 2004, when contemplating moving to a different company, I decided I was ready for a shift in focus.  Namely, I wanted to move away from the details of writing code and move towards higher-level architecture, design, and strategy.  So I joined Microsoft as a program manager (PM).

Now, less than 3 years later, I’ve moved back to being a software development engineer (SDE, i.e. developer).  Is it forever?  Who knows?  I didn’t move back because I disliked the PM job (as some might assume).  In fact, I thoroughly enjoyed most aspects of being a PM.  After a few months in my new role I actually find myself missing some of them from time to time.  There wasn’t any single thing that spurred the decision: it was fairly complicated, and involved a mixture of pursuing a specific opportunity, seeking growth, realizing I was missing many things that I enjoyed doing as a developer, and, I suppose, some degree of relapsing back to something I am more comfortable with.

I've written up some details about why I decided to change.  Who knows, maybe it will help somebody out there choose the right role for themselves?

The specific opportunity

The opportunity I’m referring to was, of course, PLINQ, and it came about at just the right time.  I spent the year leading up to my decision gradually focusing more and more on PLINQ.  At first, PLINQ was just a crazy idea.  Then I did some prototyping in my free time, had some quick successes, and was amazed at how simple it was to write parallel programs with LINQ queries.  I showed some people, and most really latched on to the idea; they could understand the value of the system with just a 30 second elevator pitch.  These positive reactions motivated me to stick with the idea, and to keep driving hard.  Then there was interest from the C# team, interest from executives, a BillG ThinkWeek paper, and finally, somebody wanted to do it for real.

In some sense, it was like a start-up.  I had an idea, figured it was an idea worth pursuing, did some prototyping, sold it among my peers, and finally convinced a VC team to fund the execution of the idea.  Well, if it truly were a start-up, what would I then want to do?  Code all night long, obviously!  I wanted to architect and design the actual product version, implement the darned thing, and feel the whole process from start to finish from several perspectives.  Doing PLINQ as a technical lead/developer seemed like a natural next step.

I should also note that I had considered taking developer positions before the PLINQ job.  But in all of those instances, I chose not to for two reasons: I was having a blast as the concurrency PM on the CLR team and because the right opportunity hadn't arisen to steal me away.

This was also a great growth opportunity for me.  Though I was a developer in the past, it was seldom my own idea that I was implementing, and this time it’s different.  I had set the ship sailing in a direction that I was happy with, and experiencing the consequences of that direction is something I seriously wanted.  It’s less about control than it is about feeling more ownership and responsibility for the direction in which our team is headed.  It’s also a way of putting my butt on the line, hopefully winning more trust and respect in the process, showing that I can actually follow through on good ideas (rather than just having the idea itself).  Most PMs certainly get a lot more of the influence and coarse-grained ownership opportunity than most SDEs, but my particular situation was such that my high-level contributions, leadership skills, and domain-experience will be more valuable and influential where I am now.  This last part turned out to be less of a SDE vs. PM thing (i.e. I could have probably had those things as a PLINQ PM too), but it played a huge role in my decision to change teams.

I missed writing code

During the many long nights of prototyping PLINQ, it also kept reminding me how much I loved coding and how much I missed it as a PM.  Put simply: I love programming.  Anybody who’s done something they love and gotten lost in it knows what “flow” is.  I used to experience flow when I played music, but I haven’t done that for so long that programming is now the only time I really feel it.  Maybe it has to do with the fact that I started coding when my brain was still in development (13 years old), and so I tend to be comfortable thinking in code.  You know: no conscious thought, just a direct conduit from your brain to your fingertips.  There is a sense of time standing still, the code simply appearing on the screen in a magical blur, and at some point the thing actually works.  You can get up, stretch, make some tea, map out the next few hours for a moment, and then you’re back into it.  Lost in the fun of it all.  It’s just great, and nothing I ever did as a PM gave me this feeling.

There’s an art to writing code.  Sure, there’s a non-negligible scientific and mathematical component to programming, but I like to think of development as the artful application of those formal techniques.  Inventing, structuring, and reifying abstractions, naming them, the careful placement of comments and whitespace, traversing the state space in your head, using intuition to make certain trade-offs, and so on.

Perhaps the most creative and artistic activity as a PM that I really enjoyed was writing.  But to be honest, I’ve always enjoyed the kind of writing I do on my own time—writing blog essays and books—more than the more prevalent style of writing that a PM tends to do (say, design specifications).  I would get the chance to write a strategic or influential technical document from time to time, but the rate at which I will contribute such things as a SDE seems like it will be the same as when I was a PM.  It has been so far, at least.  If you have the insight and know how, when, and with whom to share and present it, people will listen, regardless of your title.

Designing new things was also of course a creative activity I loved as a PM, but I’m doing more design work as a developer than when I was a PM.  Not all SDEs design higher-level things, but I do regularly and work closely with many architects, distinguished engineers, and technical fellows in the process.  Developers also get to design more at a slightly lower level of abstraction.  But everything's just an abstraction anyway, so the "level" doesn't matter much (to me) anyway.

Prior to PLINQ, my Sencha interpreter/compiler (Scheme at first and later, Common LISP) was my hobby development project.  (And, of course, there were many late nights spent on TopCoder.)  I was basically spending my days as a PM and my nights as a developer.  To be honest, I enjoy doing both things and, aside from the time it took to do both, it made me very happy.  But in retrospect, it turned out to be rather unhealthy.  Writing code was my sole hobby, and I evicted all of my pre-Microsoft hobbies from my system to make room for it.  Now I get to write code during the day, do the components of PM that I enjoyed most, and still preserve my sanity.  I’m just getting back into the things I used to love doing: writing more than just technical blog essays and books, playing guitar, sports, working out, food and wine, and basically just getting outside and feeling healthier, both mentally and physically.  Maybe I'm getting old.

Fractured role structure

There are plenty of things I miss as a PM.  But I associate the absence of many such things with where we are with the PLINQ project.  High-level planning, becoming familiar with the competition and pertinent research in the area, thinking about product strategy, etc. are all certainly crucial activities throughout the project, but they are much more prevalent and involved at the outset.  As the project shifts into execution mode, there’s a lot of thinking about release plans, customer interaction, and team building and management.  I enjoy those things too, but I also love the design, architecture, and implementation of software.  I still get to do them, just not as frequently.  As a developer, you tend not to be involved in as many management discussions and decisions, but I can cope with this knowing I have a solid PM and management team working with me.  I know that if there's anything that requires my attention or where my feedback would be valuable, they won't hesitate to bring it to me.

To be completely honest, I dislike the completely fractured role structure that most of Microsoft employs.  (And “dislike” is putting it mildly.)  I do believe that people need to specialize, particularly as they grow in their career.  You simply can’t do it all and expect to move up to the next level of your career without abstracting some details.  But when you get down to it, there really isn’t much of a difference between PM, SDE, and SDE/T.  I've been doing interviews for PM and SDE lately, and we expect one to have a better business- and customer-sense, while the other needs to be solid algorithmically and implementation-wise, but there's a substantial overlap.  There are obviously certain responsibilities which are unique to each role, but more often than not, the roles are fluid and (when things are going well) people are able to fill in whatever gaps happen to arise that they are good at filling.  I just don’t think this kind of specialization necessarily needs to be forced.  Maybe I'm influenced by my own style of sitting on the edge between the two roles.  Each project needs its own unique structure, and some dedicated managers, but it doesn’t happen according to some magical formula.  As I understand things, this is how it works at Google, and just about every research department I’ve ever known (including MSR).

I should also mention that the grass isn't all a vibrant shade of green on the other side of the fence.  A PM gets to operate at a higher-level, seldom spending more than 10 minutes triaging and talking to a developer about any particular bug, for example.  In contrast, a developer must focus on details most of the time.  This might mean spending anywhere from 1 minute to 1 week on just a single bug.  Some people enjoy getting lost in details (in fact, it can help lead to flow, though bug fixing is more investigative work than anything else, which isn't as conducive).  Checking in a bug makes it really easy to quantify “success” and some people need this.  (Not me.)  I prefer more ambiguous tasks which usually means design or coding an entirely new algorithm, and I find fixing bugs tedious.  This means the late-in-the-game product cycle will be a little rough for me.  But that’s OK: the details are of course part of the engineering process, so I do it and don’t ever find myself thinking “wow, I dislike this” while I'm doing it.  A lot of developers tend to be tools geeks, too.  They love building complex ecosystems of engineering support tools.  I’m not into that.  I value solid engineering practices, but prefer things to be as simple as possible such that nothing gets in between me, the code, and the compiler.  Reality isn’t quite always like this, and tools are often the most effective means to ensure certain quality properties of your product, but I still strive to eliminate (or avoid adding) as much unnecessary obstructions as possible.  A wise man once said "keep it as simple as possible, but no simpler."

Some final words

At the end of the day, when I look at influential people I've bonded with across the company, most (but certainly not all) rose up through the ranks as developers.  That’s clearly very subjective and personal: that’s not to say there aren’t great PMs (past or present), only that most architects, distinguished engineers, technical fellows, and researchers have or are coders at heart.   Moreover, I simply see myself being more successful as a SDE.  Not only have I done it for longer, but the career skills required to move from developer to architect to distinguished engineer (in Microsoft) align more closely with the skills I already have.  While PMs can move to architecture with time, it simply looks like a much longer road from where I stand.

And after saying all of this, I truly believe job title doesn’t matter that much at all.  Ability and good intuition matter.  We’re all just shipping software.  At the end of the day, we do what needs to get done for that to happen, regardless of what hat we happen to be wearing at the time.

[Update 2/19/07: the search for Jim has been called off after just about three weeks.  Thanks to everybody who helped, and best wishes to Jim's family.]

Jim Gray, a Microsoft technical fellow who is best known for his seminal work on database transactions and data management, has been missing for almost a week.  He took his 40-foot sailboat, Tenacious, last Sunday to scatter the remains of his late mother near the Farallon Islands off the coast of California, and has been missing ever since.  This article has additional details.

Although the Coast Guard has called off the search, friends and family are chartering private aircraft, scouring satellite imagery, and NASA even made a special run of its ER-2 aircraft to generate additional data.  Werner Vogels has more information on his website, including how you can help with the search.

Jim actually provided important feedback while I was thinking and writing about PLINQ, and was one of the most supportive and excited reviewers of the project.  Not to mention all of the papers he wrote or was involved with that inspired a lot of the direction.  I’d be very sad to see his life cut short, particularly in this way.

Joel tagged me on this silly 5 things you didn't know about me meme.  Since it's floating around, and because I’d hate to disappoint a crazy Australian who’s apt to shoot vinegar in my eyes with a Super Soaker (woof, woof), I figure I'll give it a shot:

1. I played in a heavy metal band when I was a teenager.  I was the lead guitarist, and loved to shred it up, with a sort of { 80's metal, 90's heavy metal, neo-classical, blues } style, influenced heavily by Slayer, Metallica, Pantera, GnR, Yngwie Malmsteen, Joe Satriani, and Stevie Ray Vaughan.  (Odd combination?  You bet!)  Don’t ask for pictures, I have conveniently "lost" them.  I stopped playing guitar for several years, but picked it back up in the past year and have been playing daily (focusing on building better music theory technical depth, but still shredding: my recent obsession is Dragonforce).  I also created several independent industrial and experimental techno CDs.  I try again every now and again, but I seem to have lost the patience.
2. I stopped playing in the heavy metal band because I "accidentally" punched a guy in the face in a mosh pit at a Sepultura concert.  This broke my hand in several places and was quite unpleasant.  (I did stay for the whole set, I'm happy to report.  The bar was kind enough to supply a plastic cup with some ice.)  The emergency room wrapped it in a cast, and then after 4 weeks, it had healed incorrectly.  So then I had to have it manually rebroken, and spent the entire summer in a new cast.  At the end, I had no hand or arm strength, my finger was crooked (making it hard to hold a pick), and my band had broken up because we couldn't play out (and they apparently didn't have the motivation to replace me temporarily).  This was the end of my dreams of being a rock star.
3. When I was 18 years old, I weighed a whopping 260 pounds.  Most of it was muscle, resulting from me working out literally every single day, and I have the stretch marks to show it.  I was a big dude, benched a little more than my weight, and even played center for a short period in high school football (I wasn’t keen on the fact that it’s apparently protocol that the quarterback routinely lays his hands on the center’s butt).  Now I weigh about 160 and have no muscle.
4. I started programming when I was 12.  This came about because a local gaming place (Gamer's Guild in Milford, MA) had set up a new BBS system, on which they provided several MUDs, MOOs, MUSHes, etc., on their Commodore Amiga 3000's and 4000.  I became hooked, especially when I found out you could get access to the source code and actually change it.  When CircleMUD came out, circa '92 (IIRC), I got serious about hacking code, doing the bulk of my MUD programming on a hand-assembled Slackware Linux 1.0 IBM PC.  Ironically, yours truly (a Microsoft employee) did most of his learning on the Linux OS, using GNU's C Compiler.  (I actually refused to use DOS until I started doing games programming that required graphics and found some cool DOS toolkits.  I refused Windows even longer, until I got sick of using 'lynx' to browse the WWW.  I have always found Windows API programming, with UPPER_CASE type names everywhere, rather ugly and I simply didn't get it at first.)  I set up my own 8-line BBS and later in '94 converted to co-located Internet hosting, running a heavily modified CircleMUD (3.1?) for a year and a half.  There was typically around 20 players signed on at any given point.
5. I am VERY obsessive about things.  I want to buy as many books as I can get my hold on, read them all the time, write code every waking moment, drink wine every night, go out for 15 course dinners every night, play guitar and learn every scale, major and minor, mode, modification, chord, arpeggio, I like to work, work, work until I am barely awake, and so on.  It drives my friends completely nuts, but it keeps me busy.  I've been that way ever since I was a little kid, so I don't think it's going to change anytime soon.

I don't know many people, so I'm going to commit meme heresy and not link to anybody else.  Sorry.

I will be giving a PLINQ talk at the Declarative Aspects of Multicore Programming (DAMP) workshop at POPL next week:

[Update: 1/23/07 -- added a link to the slide deck below.]

PLINQ: A Query Language for Data Parallel Programming

Microsoft’s language integrated query (LINQ) technology provides an expressive syntax and suite of APIs which facilitate classic data parallel operations: filtering, mapping, reductions, loop tiling, sorts, nested loops parallelism, prefix scans, and more.  In this talk, we look at a new set of extensions to the LINQ technology, called parallel LINQ (PLINQ), which automatically optimizes and parallelizes query operations based on dynamic runtime information.  We believe that the use of a familiar SQL-like syntax will broaden the reach of PLINQ in industry, and provides programmers with a more declarative and flexible way of expressing data-intensive computations.

Download presentation (PPT).

The workshop is being chaired by Guy Blelloch from CMU, is located in Nice, France, and features some interesting recent research in the field of parallel programming.  If anybody will be in town and wants to meet up, please drop me a line at joedu AT microsoft.

You might have noticed I'm blogging a lot more about native code than I used to.  Most of my day-to-day work still has to do with managed code, but I've been dazzled by all the new cool things in Vista that you can't do yet in managed code (and probably won't be able to for some time to come, since the CLR needs to keep running on old OSes).  And, besides, many low-level Windows changes impact managed code too, like the fairness post from last week.

My question to you is:  Do you vehemently like or dislike either category of post?  Does the split between the two work?  I'm trying hard to keep it at about 50/50. 

I'm wondering not just for blogging reasons.  As you might imagine, my book is looking to be very similar to my blog.  It is, after all, "Concurrent Programming on Windows", which sometimes involves using native code to access features that managed doesn't expose to you.  Similarly, the CLR gives you many things that Windows alone doesn't give you.  I'm trying reeeeealllly hard to ensure the prose is not schizophrenic, flows and progresses nicely, and doesn't repeat things: e.g. "here's how you do it in VC++, here's how you do it in C#, ..."  This can be a challenge for many things, but is obviously very important.  Thankfully a huge portion of the book is more about applying the technologies generally, which tends to be pretty common across both environments.

So ... what do you think?

I recently left the CLR team to join a new team focusing on parallelism on Microsoft's platform in the 3-10 year timeframe.

I am leading design and development of the Parallel LINQ (PLINQ) project that I alluded to here.

We're looking for supersmart technical people to join the team and help change the face of programming for anybody writing code on the CLR or VC++. PLINQ isn't the only project. Solid CS skills are a must, but you don't necessarily have to be a concurrency guru (right away).

These job postings have some detail:

http://members.microsoft.com/careers/search/results.aspx?FromCP=Y&JobCategoryCodeID=&JobLocationCodeID=&JobProductCodeID=&JobTitleCodeID=&Divisions=&TargetLevels=&Keywords=2012%20&JobCode=&ManagerAlias=&Interval=10

If something catches your eye, respond on the jobs site or send me your resume directly at joedu AT you-know-where DOT com (i.e. microsoft DOT com).

I'll of course still be blogging about everything concurrency related, so you won't notice much of a difference content-wise. And I'm still happy to answer any CLR related questions and help you find the right folks inside the team to listen to your feedback.

I just read Dijkstra’s "My recollection of operating system design", note #1303. He describes issues with the design and implementation of THE operating system, written several years afterward in retrospect. Theme-wise, he focuses on concurrency, resource management and scheduling, fault tolerance, and real-time considerations for fairness. I found the paper to be quite fascinating and easy to read. I enjoyed the theme of concurrency woven throughout, particularly reading about both the failed and successful approaches. The original hand-written note can be found here.

Here are some choice quotes that I was drawn to with some comments by yours truly:

"... [with this] we have achieved CCC (= Completely Concealed Concurrency) in the sense that our two machines are now functionality equivalent in the sense that, fed with the same program, they will produce exactly the same output. As long as speed of execution is unobservable, it is impossible to determine which of the two machines did execute your program." (pp. 5)

[Comment: Although the details are quite different, I was struck by CCC’s goal of isolation among tasks running concurrently in the system and its resemblance to STM, at least in terms of overarching design goals.]

"Thus CCC improved the efficiency ... but the comfortable invisibility of concurrency had a high price ... To maximize throughput, we would like each reader to read at its maximum speed most of the time ... but with CCC, the calculator has no means of identifying that input stream: the invisibility of concurrency has made the notion of "first-come-first-served" inapplicable. The moral of the story was that, essentially for the sake of efficiency, concurrency should become somewhat visible. It became so, and then, all hell broke loose." (pp. 7-8)

[Comment: Again, STM often requires breaking this isolation to improve scalability of certain data structures, a la open nesting (see Moss ’06). Although there isn’t as much practical experience with such things, it is quite clear that open nesting can certainly cause all hell to break loose (see Agrawal, et. al, '06).)]

"In retrospect, the problems were in roughly three areas: (i) The basic mechanics of switching the central processor from one task to another, (ii) The strategy for scheduling the central processor and the scope of its commitment, (iii) The logical problems that emerge when a number of resources are shared by a number of competitors ... Those years taught me that the ability to detect timely that some theory is needed is crucial for successful software design." (pp. 9)

"We learned to distinguish between "essential urgency," where failure to be in time would derail the computation, and "moral urgency," where the failure would only hurt the efficiency... [this] taught us that in resource allocation one could (and therefore should) separate the concerns of necessity and of desirability." (pp. 18)

[Comment: This is a great lesson to learn when it comes to reliability in general. There is a large difference between statistically reliable and completely reliable. All software is statistically reliable to a degree, it’s only a matter of the statistical details, in particular the statistical frequency of failure, whereas very little software, at least on commercial non-real-time systems like Windows, is completely reliable, in other words, cannot fail.]

"With the symmetry between CPU and peripheral clearly understood, symmetric synchronizing primitives could not fail to be conceived and I introduced the operations P and V on semaphores. Initially my semaphores were binary ... When I showed this to Bram and Carel, Carel immediately suggested to generalize the binary semaphore to a natural semaphore ... How valuable this generalization was we would soon discover." (pp. 23-24)

"Many peripherals could be designed in such a way that they did not confront the CPU with real-time obligations ... but the problem was, that these same devices would often now confront the CPU with situations of "moral urgency" ... The solution was to allow the CPU to build up a queue of commands and to enable the channel to switch without CPU intervention to the next command in the queue. Synchronization was controlled by two counting semaphores in what we now know as the producer/consumer arrangement ..." (pp. 24)

[Comment: Obviously when scheduling concurrent tasks, e.g. in a user-mode scheduler, one has to worry about fairness and prioritization too. His writings are generally applicable.]

"In retrospect I am sorry that I postponed widespread publication until 1967 and think that I would have served mankind better if I had enabled The Evil One to improve its product." (pp. 27)

[Comment: I had to laugh at this. Dijkstra wrote this regarding his design for semaphores and synchronizing channels, referring to IBM as "The Evil One" and IBM/360 as "its product". Times have changed things, but not by much: Microsoft is now, I suppose, "The Evil One," at least for many people.]

"For economic reasons one wants to avoid in a multiprogramming system the so-called "busy form of waiting," in which the central processor is unproductively engaged in the waiting cycle of a temporarily stopped program, for it is better to grant the processor to a program that may actually proceed." (pp. 28)

"Halfway the multiprogramming project in Eindhoven I realized that we would have been in grave difficulties had we not seen in time the possibility of definitely unintended deadlocks. From that experience we concluded that a successful systems designer should recognize as early as possible situations in which some theory was needed. In our case we needed enough theory about deadlocks and their prevention to develop what became known as "the banker's algorithm," without which the multiprogramming system would only have been possible in a very crude form." (pp. 36)

I hope at least one other person out there finds this interesting. We've certainly made progress over the past 40+ years, although maybe not as much as we think. As Dijkstra says in this note several times, perhaps one of the largest improvements in the state of the art since he worked on THE has been the development of terminology. It's incredibly hard to build on top of prior work if you haven't the terms to talk and reason about what has worked and what has failed.

As many of you know, I'm right in the middle of writing a new book on concurrency. I'm curious what people would like to see covered and in what proportions.

If you had $100 to spend as you see fit across any number of the following concurrency topics, how would you distribute it?

(0) Parallel algorithms (Comp Sci., technology agnostic)
(1) Architecting large scale concurrent programs
(2) Windows concurrency internals
(3) CLR concurrency internals
(4) Windows (Win32) concurrency API best practices
(5) CLR concurrency API best practices
(6) Client-side concurrency
(7) Server-side concurrency
(8) Reusable concurrency primitives (building and using them)
(9) Performance and scalability
(A) Debugging

I know there's some overlap and that each isn't entirely orthogonal, but that's okay. If there's something missing, feel free to add it to your response and allocate some funds for it.

I'm looking forward to seeing what y'all think!

Here are the slides for my JAOO'06 talk Concurrency and the composition of frameworks:

JAOO-06__ConcurrencyAndFrameworks.ppt (2.06 MB)

The Lang.NET Symposium was held here in Redmond, WA last week.  My pal, Erik Meijer, the monadic maniac of Head in the Box, Lambda the Ultimate, and now VB 9 fame, helped pull together the killer agenda, which is always a recipe for a good time.  Thottam, a PM on the CLR team, just posted a great summary on his blog.  He sent it out over email last week, and I'm really glad he posted it for everyone else to see.  There are a bunch of good language geek links lurking within. 

I'll be speaking at JAOO'06 in Denmark this October. They have an entire track dedicated to concurrency. If you're in the area (or don't mind the travel), I highly recommend checking it out:

Concurrency and the composition of frameworks

Abstract:
Multi-core computer architectures pose both a threat and an opportunity to modern software. The amount of computing power that will soon be available will enable mainstream applications to solve problems that require computing power that has until recently only been available in supercomputers. But it also means that our software needs to evolve alongside to better support and enable the levels of concurrency we'll need to effectively use all of those cores. This fact applies as much to reusable software libraries as it does to applications themselves.

This new direction imposes some new and interesting constraints on the architecture of reusable software components, including the need to remain thread agnostic, expose latency characteristics and mechanisms for hiding latency, and, for computationally expensive library routines, some way to carry them out in parallel based on the context in which they were called. These are all areas which have not yet been researched heavily and which commercial library vendors are only now beginning to seriously deal with.

This talk presents an overview of the problem, identifies some key challenges, and proposes some direction for enabling our software to both take advantage of concurrency and to avoid inhibiting it. While the discussion has been derived from experiences on the Windows and .NET Framework platforms, the ideas presented aim to transcend any specific technology.

If you're in Denmark and want to meet up to chat, definitely drop me a line.

It shouldn't be news to anybody that Bill is transitioning into a new role in 2 years. I figured I'd dump some of my thoughts about this onto paper. Remember: This is in no way the official company view on the matter, nor is it motivated by any sort of company-private information.

First, I am surprised that Bill didn't make this transition sooner. I think it's admirable how he's been able to maneuver through the technology details for so long. He refused to completely give up his technical edge. And I think it's cool that he can venture out into entirely new verticals with the premise in hand that all you need is a bunch of really smart, motivated people to succeed. It's risky. And it's a sort of an antithesis to traditionalist business management views.

From talking to colleagues about this news, however, I think people tend to downplay the importance of having Bill around. Externally, there's no doubt he's a huge part of our PR, whether you like him or not. That's probably why the stock has been flat after the announcement. Not having him in charge of technical direction may open up some new avenues that we wouldn't have otherwise explored. New blood is always healthy. At the same time, though, it takes a functioning system and runs the risk of disrupting it. But I'm more worried about the internal climate...

Just as Dave Cutler is a god to the NT Team, Bill is a role model for every technical person in the company. He's a geek. He talks like one, he looks like one, and he acts like one. He was very successful at a young age, was self-taught, and didn't need college to do and succeed at what he loved. And he has an inconceivable level of power and influence both within and outside the company. For a place that's full of uber-geek MS-for-lifers who joined the firm straight out of college, and who wouldn't think about leaving (with Bill around at least), all of these are very important traits. While Ray Ozzie is a very accomplished and intelligent guy, he's missing almost all of the traits I mentioned above. And I think people will notice.

In the past month alone, I've had a BillG Review and received feedback from him on two spring ThinkWeek papers that I submitted. These were my first personal interactions with Bill, and perhaps my last. I was impressed. He's scary smart. There's no doubt he's very clever and can effortlessly cut through complexity to understand the core of really deep technical problems. There's no way the new senior technical leadership will have the same traits and to the same degree. It's not that they aren't great people. I've had several meetings with Craig Mundie recently, our CTO, and he's extraordinarily insightful and talented. I found myself blown away by some points he was making. But Bill's just too good to beat.

So here's the gist of it all. Microsoft in the past has been a technically motivated company. Bill's passion was around how we could use technology to change the world. But at the same time, he cared about how that technology was architected and built. He didn't simply spew MBA mumbo-jumbo. Microsoft feels like a company full of 100s of start-ups, each of which reports to the same technical leader, all fighting tooth and nail to build the greatest technology possible. I think all of that is going to change. I conjecture that we're at the beginning of a major shift, where Microsoft will slowly evolve from a technology-driven company to a business-driven company. The two are not mutually exclusive, obviously, but the balance will shift. We'll do more projects based on business reasons and less based on pure technology reasons. We'll waste less money in the process. It had to happen sooner or later. But for the geeks like me, I have to wonder whether it will remain as much of an enjoyable place to work. Or whether those who are looking for such an environment will be forced to go elsewhere...

I'm writing an article for an upcoming MSDN Magazine CLR Inside Out column. And I am looking for topic suggestions.

Of course, my expertise is around concurrency, but I'm also a CLR internals-kinda geek. So, what do you want to read about?

I have some ideas. But I'll post them after I hear yours.