| |
 Sunday, February 17, 2013
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.
Tuesday, July 17, 2012
It's been quite some time since I blogged.
The reason is simple, as always: I'm having the time of my life at work.
I will try to do better blogwise in the coming months. But in the meantime ...
If you'd like to join me, Adam, and Krzysztof in our quest to build the best APIs and developer platform known to mankind, please shoot me an email with you resume. Or just apply.
In short, you could be having the time of your life too. Why wait?
Saturday, September 18, 2010
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.
Saturday, October 31, 2009
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.
Friday, March 06, 2009
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.
Friday, September 26, 2008
I just returned from TechEd Australia, which was a lot of fun.
I have a fair number of additional speaking engagements coming up:
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.
Wednesday, July 30, 2008 Wednesday, January 02, 2008
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? ;)
Monday, July 30, 2007
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!
Friday, June 08, 2007
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.
Sunday, April 29, 2007
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. |
| 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. |
Saturday, March 24, 2007
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.
Saturday, February 03, 2007
[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.
Tuesday, January 23, 2007
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:
- 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.
- 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.
- 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.
- 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.
- 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.
Monday, January 08, 2007
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.
Friday, December 22, 2006
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?
Friday, December 01, 2006
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.
Sunday, November 12, 2006
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.
Saturday, October 21, 2006
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!
Monday, October 02, 2006 Wednesday, August 09, 2006
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.
Sunday, August 06, 2006
This falls into the "fun hacks" category, meaning the result is not necessarily something you'd want to use in your everyday life. To go a step further, I strongly recommend you don't use the code shown here as-is; read the summary at the end for some rationale behind that statement. Enough with the disclaimer. On with the show...
Some requirements for our cross-process RWLock
Imagine you had the need for:
1. A managed reader/writer lock
2. that runs on down-level (pre-Vista) operating systems,
3. and that optionally works across process boundaries and AppDomains.
What do we already have that might fit the bill? The existing ReaderWriterLock type in the System.Threading namespace works fine for 1 and 2, but not 3. I suppose you could share it across AppDomains--or even processes--with some form of messaging scheme, but let's ignore that for a moment. It's a little *too* clever for my taste. Windows Vista of course comes with a new slim reader/writer lock. It's a close cousin of the Win32 CRITICAL_SECTION, and can be used for cross-AppDomain synchronization. Unfortunately, you have to P/Invoke to get at it from managed code, it won't run on pre-Vista operating systems, and doesn't work for cross-process scenarios.
Let's build it out of duct tape and barbed wire
It turns out that you can build a type that meets our requirements out of existing Windows kernel objects. All it takes is a little imagination. Here's what you need:
1. A semaphore to count the number of readers inside the lock.
2. A mutex to ensure only one writer can be in the lock at a time.
3. (Optionally) a manual-reset event used by writers to ensure no new readers enter the lock while it waits.
The scaffolding for one such implementation--which I will call the IpcReaderWriterLock--is as follows:
public class IpcReaderWriterLock : IDisposable
{
/** Fields **/
private const int DEFAULT_MAX_READER_COUNT = 25;
private const string NAME_PREFIX = @"IpcRWL#";
private readonly int m_maxReaderCount;
private Semaphore m_readerSemaphore;
private EventWaitHandle m_blockReadsEvent;
private Mutex m_writerMutex;
private int m_writerRecursionCount;
/** Constructors **/
public IpcReaderWriterLock() : this(null, DEFAULT_MAX_READER_COUNT) { }
public IpcReaderWriterLock(string name) : this(name, DEFAULT_MAX_READER_COUNT) { }
public IpcReaderWriterLock(int maxReaderCount) : this(null, maxReaderCount) { }
public IpcReaderWriterLock(string name, int maxReaderCount)
{
m_maxReaderCount = maxReaderCount;
string blockReadsEventName = null;
string writerMutexName = null;
string readerSemaphoreName = null;
if (name != null)
{
blockReadsEventName = string.Format("{0}{1}#{2}", NAME_PREFIX, name, "RdEv");
writerMutexName = string.Format("{0}{1}#{2}", NAME_PREFIX, name, "WrMtx");
readerSemaphoreName = string.Format("{0}{1}#{2}", NAME_PREFIX, name, "RdSem");
}
m_blockReadsEvent = new EventWaitHandle(true, EventResetMode.ManualReset, blockReadsEventName);
m_writerMutex = new Mutex(false, writerMutexName);
m_readerSemaphore = new Semaphore(maxReaderCount, maxReaderCount, readerSemaphoreName);
}
/** Methods **/
public void Dispose()
{
// Just close all of the kernel objects we opened during construction.
// Note: this method is not thread-safe. If threads race with
// one another to call Dispose, some nasty bugs will arise.
if (m_blockReadsEvent != null)
{
m_blockReadsEvent.Close();
m_blockReadsEvent = null;
}
if (m_writerMutex != null)
{
m_writerMutex.Close();
m_writerMutex = null;
}
if (m_readerSemaphore != null)
{
m_readerSemaphore.Close();
m_readerSemaphore = null;
}
}
public void EnterReadLock() { ... }
public void ExitReadLock() { ... }
public void EnterWriteLock() { ... }
public void ExitWriteLock() { ... }
}
Notice that we allow naming of the lock. Any name given flows into the kernel objects used underneath, enabling cross-process and cross-AppDomain communication. You just create the same IpcReaderWriterLock with the same name in multiple processes or AppDomains, and they will magically interact with one another (whether you want them to or not). An unnamed lock is isolated inside of the AppDomain in which it was created. Notice also that there's a maximum number of simultaneous readers, the default for which is 25. This isn't terribly important, but any override does impact performance (as described below).
Read and write lock implementation
Now let's implement the read-lock acquisition and release functions, EnterReadLock and ExitReadLock. We support more than one reader at a time via the use of a semaphore (#1 above). We also support preventing blocking new readers from entering the lock while the writer waits for all readers to exit (#3 above). Thus, both of these functions are quite trivial to write:
public void EnterReadLock()
{
Thread.BeginCriticalRegion();
// We first wait on the read blocking event, in case a writer
// has tried to acquire the lock and wants us to wait.
m_blockReadsEvent.WaitOne();
// Now take '1' from the reader semaphore to count the number
// of simultaneous readers inside the lock.
m_readerSemaphore.WaitOne();
}
public void ExitReadLock()
{
// Just release '1' back to the semaphore to let others know
// the number of simultaneous readers just decreased.
m_readerSemaphore.Release();
Thread.EndCriticalRegion();
}
Next comes the write-lock acquisition and release functions, EnterWriteLock and ExitWriteLock. They are slightly more complicated, but not by much. First we acquire the writer mutex. Once we've done that, we increment the recursion count, and ensure that we do some other work only the first time a writer lock is acquired on the thread. We block any new readers from entering, and then we effectively wait for all readers to exit. We do that by acquiring the semaphore n times, where n is the maximum number of readers that we support. Releasing the write lock does the reverse of all of that:
public void EnterWriteLock()
{
Thread.BeginCriticalRegion();
// We have to first ensure only one writer can get in at a time.
m_writerMutex.WaitOne();
// Increment our recursion count.
m_writerRecursionCount++;
// For the first writer who enters, we need to block new readers
// and wait for any existing readers to exit the lock.
if (m_writerRecursionCount == 1)
{
// Next we block any new readers from entering the lock.
m_blockReadsEvent.Reset();
// And lastly, we ensure that all readers have exited the lock.
// We do this by acquiring the semaphore's capacity. It's
// unfortunate that the Win32 APIs don't support a take-n
// function for semaphores.
for (int i = 0; i < m_maxReaderCount; i++)
{
m_readerSemaphore.WaitOne();
}
}
}
public void ExitWriteLock()
{
// We have to do everything in the reverse order as we did
// during acquisition. Not doing so can lead to subtle bugs,
// including lost resets and deadlocks.
m_writerRecursionCount--;
// The last writer to release has to signal readers.
if (m_writerRecursionCount == 0)
{
// We release the semaphore's capacity back, enabling readers
// to take from it. Note that as soon as we call this, other
// threads may wake up and race to acquire the semaphore. In
// fact, simultaneous readers can get in, even though we still
// have a writer in here!
m_readerSemaphore.Release(m_maxReaderCount);
// Unblock any readers that are waiting. Note: ideally we would
// do this after signaling writers, so that readers can't sneak
// in before the writer, but that would be more complicated: we
// keep it simple for now.
m_blockReadsEvent.Set();
}
// And lastly release the mutex.
m_writerMutex.ReleaseMutex();
Thread.EndCriticalRegion();
}
And that's it. A fully functioning reader/writer lock, for some definition of "functioning." The full source code can be found here: IpcReaderWriterLock.cs.
The test case
This example wouldn't be complete with a simple test case to prove that it works. The sample program included in the IpcReaderWriterLock source code creates 20 threads--10 readers and 10 writers--in 10 AppDomains. Each does a piece of work designed to expose race conditions via context switching at sensitive points. It prints out "Success" at the end, assuming it all worked. I see "Success" every time I run it, so it works on my machine at least. Hooray.
Summary: Don't use this thing
OK, OK... this lock is pretty icky and nasty to be honest, and you probably wouldn't want to use it. Ever. A simple write-lock acquisition incurs 27 kernel transitions with the default settings. This ends up costing over 1000-times the cost a simple monitor acquisition! (Yes, there are three 0's in that number... ouch.) Moreover, the cost increases proportional to the number of simultaneous readers that the lock instance supports, which is not very good. That's why I've used such a low default: 25. And it's not very reliable either, which, for anything that does cross-AppDomain or cross-process synchronization can be disastrous. One process that crashes can lead to machine-wide corruption and a user who needs to reboot the machine. A much better lock (performant, reliable, etc.) could be built using memory mapped files, although the implementation would be substantially more complicated.
I almost didn't write this post for all of these reasons. I'm not sure whether I'm doing a disservice to my readers by doing this. Instead, I hope that showing how simple Windows kernel objects can be composed together in interesting, powerful, and non-obvious ways is interesting, if only for trivia reasons. I'd also like to think that it may inspire you to think about things a little differently, perhaps helping you to write clever (but useful!) things out of the building blocks you already have.
Thursday, June 29, 2006
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.
Saturday, June 24, 2006
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...
Sunday, April 16, 2006
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.
Thursday, April 06, 2006
 |
My new book is finally on book shelves and in my hands. What a relief.
Now it's time to rinse and repeat. I've been quite lazy with regards to the new book project, but it's time to get serious. I'm laying down some pretty intense milestones over the next few months. We'll see if I can hit the dates.
While the .NET Framework book used primarily a breadth-oriented approach, the Concurrency book is quite different. It covers a smaller set of topics, albeit very depth-oriented. |
Saturday, January 21, 2006
This deck, from a recent POPL presentation, offers a fascinating view on the future of mainstream games-programming languages, specifically around safety and concurrency: http://www.cs.princeton.edu/~dpw/popl/06/Tim-POPL.ppt.
(Of course, if I had a link to a video-taping of the talk or a detailed paper, that would be more useful; but I don't.)
An interesting conclusion--reinforcing a growing commonplace belief, at least here at Microsoft--is that there is no single concurrency model that works for all problems. In other words, there is no silver bullet. A combination of isolation (via STM), with implicit- and data-parallelism is discussed.
Tuesday, January 10, 2006
I recently uploaded a new page to serve as the online-companion for my .NET Framework 2.0 book.
It doesn't contain much right now, but it does have a lot of links to references I used throughout (books and articles): /books/netfx20/netfx20_book_resources.html.
Tuesday, December 20, 2005
Now that the book's quieted down, I have more time to do things like code, read, drink wine, eat, and sleep. In that order.
And I've changed roles at Microsoft to focus entirely on concurrency.
I'm wrapping up development on some C++ code I wrote for an upcoming MSDN article. I also intend to spend quite a bit of time over the holiday finishing up another project that has really tested my thinking and coding skills. I love stuff like that. When carefully and intentionally crafted code must play nicely with the topology of the underlying machine. I have a presentation to the C# Design Team in late January to show 'em what I got, so I need to get these ideas down into code and optimized ASAP.
I've also become quite hooked on the sweet sounds of System of a Down. My 5 Top Played bands in iTunes right now are (in order): System of a Down, Ill Nino, Mudvayne, Machine Head, and Misfits. I've also been playing a bit more guitar lately, recording a little, but not being overly happy with the end result. Someday.
By the way, if you want to buy me any books, here's a condensed Wish List:
Interestingly, a number of those authors currently work at Microsoft.
Have a happy holidays everybody.
Friday, November 25, 2005
I joined Microsoft mid-way through Whidbey's lifecycle. Mid-way means post-feature development, for the most part. There were plenty of unplanned features that I got to design and work on, but those were handled quite differently than the initial development process. The impression I formed during this period was that of a very regimented, structured, and process-heavy software engineering practice. Clearly this is good to ensure people don't screw up too badly, but it also places unnecessary constraints on your best talent.
Or, as Paul Graham said in his essay Hackers & Painters:
Big companies want to decrease the standard deviation of design outcomes because they want to avoid disasters. But when you damp oscillations, you lose the high points as well as the low.
At first, I thought this was necessary for the type of project I was working on, when compared to the projects I'd worked on in the past. But now that 2.0 is out the door, I'm enjoying myself quite a bit more.
Scrounging for change
Planning the direction for future releases is clearly a complex game, consisting of a mixture of top-down (where must the business go?) and bottom-up (what features do we want to do?) analysis. Customer needs come from all directions. At some point, somebody presumably must pull the trigger and unleash the team in a concrete and coordinated direction. Some don't have the stomache for this, but without it paralysis analysis sets in.
Of course, direction is a funny thing. It typically emerges over time rather than being planned explicitly, whether those doing the planning realize it or not. This particular case is no different. Before we even shipped Whidbey Beta2, we knew the primary focuses for Orcas, even down to the feature level in many cases. I suspect most people are already half-way down the path we'll eventually go, e.g. because they've been dreaming of and prototyping the new features they would like to implement for well over a year already.
But (in theory) somebody has to capture that, refine it, and communicate it to form a shared understanding. Presumably for purposes of making sure management is OK with what everybody wants to implement. But of course, what everybody wants to implement must first be turned into market segmentation and value propositions. OK, that statement is a tad cynical. Although I'm sure the process in this case will ferret out some thought bugs before they get put into code--which is clearly a good thing--I can't help but wonder whether the cost is worth the benefit. This deserves separate analysis, of course.
Flying under the radar
Planning aside, the projects I am most interested in as we move into the next few releases are the tiny incubation efforts. These are ordinarily small groups of individuals from across the company (including product teams and research). Such groups are a diverse mix of people with different backgrouns and goals, yet are drawn together because of a shared interest. If people are responsible for allocating their own time "on the side" to work on something, you can safely bet they are passionate about it and (more than) qualified to work on it. Being united by a shared interest can lead to fun collaboration and great end results. Generics is an example of a (big) project that evolved this way.
In many cases, there is no clear support from management in terms of funding for these projects. A head nod about its importance is about all you'll usually get at first. And in fact, often such wild-west efforts can go against the spirit of the planning. In terms of funding, research is funded to research it and obviously product teams can communicate with research. But for product teams to get something worthy of the productization stamp of approval (that's a vigorous management head-nod), clearly there's some level of prototyping that is needed. But simultaneously, most capable developers are focusing on staying inside the bounds of the aforementioned processes and fixing bugs. This is a slight catch-22.
Regardless of tedious funding problems, I enjoy these efforts the most. The path is not pre-defined--we must find it--and the ability for one individual to contribute substantially is very high. They feel like start-ups. But you don't have to worry about paying the bills and recruiting the best talent (the perks of working at a place like Microsoft). Many such projects I've been involved in have been primarily thought exercises. But a few have recently been given some level of funding. The groups of people that are working on them are, as noted above, often genuinely interested in what's being built. This is great. Very little process is needed...only enough to ensure we hit the deadlines for integration with the main product, and to report back to management to make sure they feel comfortable.
Only time will tell whether this approach will lead to better results. But something seems intuitively correct about the attitude that enabling your best people to do what they were hired for will lead to huge successes. Obvious corollaries can be drawn from this statement.
Thursday, November 03, 2005
I targeted PDC as the date for completing the writing process for my book. I essentially hit that, leaving the Chapter on Transactions until after I returned, which was done within a week.
And then I targeted my vacation to Maui as the date for completion of the author review process. This is when I read through what I've written, incorporate feedback from editors and technical reviewers, and crank out the final text that I am happy with.
Well, that date is here and I haven't accomplished my goal. I did the Chapters that were roughest first, requiring quite a bit of wordsmithing. I have a few left, but it should be easy work. With that said, the weeks immediately following my return are going to be tough. I'd mentally tagged this vacation as a transition from book to post-book life, and it seems this won't be the case.
The good news is that I'm particularly satisfied with how the finished Chapters came out. The book will be highly complimentary to others on the market, but offers a great deal of unique coverage and new-to-2.0 topics.
Technical posts will return in a few weeks time. Bear with me. I've been having a difficult time finding material. For example,
- I thought I was clever when I figured out how to debug LCG methods in SOS, until I saw this. (!!)
- Using the 2.0 hosting APIs, I wrote a host that monitors lock acquisitions/releases, and warns you of potentially deadlocking patterns. (E.g. if it ever notices that one thread acquires A..B and another acquires B..A, although they might not have overlapped (yet).) But unfortunately, it required about 1,000 lines of code, and thus isn't a short blog post!
Happy hacking!
Tuesday, October 04, 2005 Wednesday, September 14, 2005 Sunday, August 14, 2005
I encountered a great quote recently while listening to Business at the Speed of Thought by Bill Gates. It really hit home with me:
"We always overestimate the change that will occur in the next two years and underestimate the change that will occur in the next ten. Don't let yourself be lulled into inaction."
Of course, the definition of "inaction" is up for grabs. Perhaps complacency would have been a more appropriate word. Action is great, but sufficient action is another thing altogether.
Sunday, July 17, 2005
Note to self: if you happen to write code that AVs the FJIT in Rotor, this prevents you from building the FX tree. I honestly don't quite know why the runtime is loaded there and what managed code executes, but according to Jan Kotas, a dev on the CLR team, it is. And furthermore, the debugging experience kind of sucked... the build log had no errors in it, but binplace failed to find the output DLL when it tried to copy. Sure enough it didn't get built. I'm pasting the error for folks searching in the future:
Binplacing - objd\rotor_x86\system.xml.dll for all platforms
binplace : warning BNP0000: CopyFile(C:\dev\play\sscli-1.0__STM\fx\src\xml\objd\rotor_x86\System.Xml.dll,C:\dev\play\sscli-1.0__STM\build\v1.x86chk.rotor\.\System.Xml.dll) failed 2
binplace : error BNP0000: Unable to place file objd\rotor_x86\System.Xml.dll - exiting.
It killed at least 1 hour of my time tracking it down. Running a quick test under the devenv debugger:
C:\dev\play\sscli-1.0__STM\tests\il_bvt\base\objd>devenv /debugexe %TARGETCOMPLUS%\clix.exe ceq.exe
Did the trick. Stupid bug, easily fixed, and now I'm back building the tree again. Hoorah.
Friday, July 08, 2005
Brad just pointed out the recent DotNetRocks episode with the PDC planning folks. They give a good insight into the insanity that goes behind planning such a huge event. I'm helping to organize the CLR Team's presence there, but my part is minimal compared to some guys (like the folks in the interview).
I'm really psyched about PDC this year. We've got a plethora of great talks lined up, and some of the best technical speakers you'll find this side of tha' Missisippi. Just take a look at the talks we've release thus far...
And they have an RSS feed so you can keep an eye on the talks as they are released!
If you haven't convinced your boss to pay yet, better work harder (and faster).
The fun begins 2 months from this weekend!
Wednesday, June 22, 2005
Contrary to popular belief, I am still alive.
Is it me or has the whole blogsphere gone quiet over the past few weeks? Guess everybody I subscribe to is heads down shipping Whidbey.
I'm coming up on my 1yr anniversary with Microsoft. This is damned amazing, it really feels like only a few months. (Doesn't everybody say that?) It's been fun thus far, and I think it's only going to get better.
I can't come up with anything intelligent to say right now, so I'm just going go byte-byte (sic).
Byte-byte.
Saturday, May 21, 2005
It's been a while since I've posted anything about my book.
I'm wrapping up my next chapter this weekend (I'm over half way done page-count-wise :P), and was interested in any opinions out there on the content. To reiterate: my goal is to cover CLR and FCL topics which haven't gotten a lot of love to date, with a focus on v2.0, while still painting a complete enough picture to be useful mostly on its own (with some previous experience with the technology of course). I think assemblies, loading internals, and how to deal with versioning problems are some that have been neglected (except for on Suzanne Cook's blog, of course).
Also, if you're interested in being a reviewer, drop me a line at joedu (at@at) bluebytesoftware (DOT.DOT) com. Please provide a brief bio of yourself so I know who's serious and who isn't.
Here's a rough layout. Comments welcome (uninteresting bullets, missed items, etc.):
Assemblies: Packaging & Deployment
- Units of Execution & Reuse
- A Look Inside Portable Executable (PE) Files
- Strong Naming
- Metadata, Metadata, Metadata
- Manifests & Modules
- Dynamic Assemblies
- Asssembly Loading
- Loading By Hand
- Inside the Bind, Map, Load Process
- Probing ("Fusion")
- Custom Assembly Binding
- Execution
- EXE Bootstrapping
- Other Hosts (IE, SQL Server "Yukon")
- Code Sharing
- AppDomain Isolation
- Deployment & Configuration
- XCopy
- The GAC
- ClickOnce
- Configuration
- Versioning
- AppCompat
- Rolling Forward
- Versioning Libraries
- Versioning Applications
- Servicing Deployed Apps
Structured exception handling and all of the challenges associated with it aren't new topics about which developers must worry. I was flipping through my copy of The C++ Programming Language (3rd Edition) this morning and ended up rediscovering Appendex E on C++ Standard-Library Exception Safety. Understanding what consistency and failure guarantees you intend to make with your library and then actually making them, knowing what to expect from a pre-written library and when and how to program defensively against it, and all such related topics were challenging with C++ and remain a challenge with C#. It's amazing how many of these things are directly transferrable between technologies.
He mentions in the book that all of the appendices are available on the web, so I did a quick search. Voila! Here it is [PDF].
Even if you're not a C++-er, you'll find a ton of great information in that article. Enjoy. I did (again).
Thursday, May 12, 2005
Wow. Something bad happened to my blog over the last 24 hours. First, random Service Unavailable messages. Then, my blog started serving up Kanji. Rather than debug the problem I decided to wipe it out and upgrade to dasBlog 1.7.
I'd actually intended to do this weeks ago. I had also intended to redesign the site. The old one was pretty heavyweight, crowded, and the homepage itself is a couple 100k in size. But because of the quick fix nature, I didn't get a chance to do much right now. It's fairly plain, but I like the simplicity. I'll try to shnazz it up at some point.
Now I just need to fix the broken images problem. Methinks my hosting company is throttling my bandwidth, and they might cut down on images as the first tier of throttling. I should probably thank them, as it might prevent me from spiking even higher and paying extra per MB/mo. Traffic on this site has increased a lot over the past few months, and I suspect I'm going to have to pay the extra $$$ for the additional bandwidth.
Thursday, April 28, 2005
I'm not doing a good job keeping up with the ~150 blogs to which I subscribe. 1,000s of posts behind (17,440/36,207). Scoble, man, I don't know how you do it.
So as a quick fix, I decided to refactor the list to aggregate my current Top 20. The way I decided this is, given my reading habits and interests, what 20 people's posts would I be most likely to read upon noticing a new entry? Obviously, the reasoning differs from person to person.
Figured I'd share it out in case you were missing one of them (btw, my blogroll's always available on the RHS of the site).
In ascending alpha-numeric order; my top 5 are bolded:
Saturday, March 26, 2005
Simon's "how to write a great research paper" material is simply great. I think I need to follow his advice, particularly about starting to write early and often.
I've countless ideas bouncing inside my head, most of which will simply get lost, but many of which I truly believe should see the light of day. I think I'm a bit of an over-thinker, and tend to wait until my ideas sufficiently mature before expressing them. It's weird, but I guess I've always been like that. The problem is, I have so much stuff that goes on in a typical day, so many ideas coming and going, that I'm not able to mature those ideas as I would like. Most of it just gathers dust and eventually dissapears. I suspect a lot of people have this problem.
Ideas are cheap.
There's a significant difference between an idea and an implementation of that idea. This, too, is where I get caught up. Sure I could come up with some nice theoretical goop, but if there's no implementation, what the hell good is it? Somebody might read it someday, but likely not. But unfortunately, implementing an idea is much more costly than simply thinking it. And I tend to get bored pretty quickly anyhow, instead preempting progress in order to gravitate towards better ideas that I perceive to be more worth my time.
It seems to me that the most successful people in our society are those that can follow through and execute on mediocre-to-good ideas. There's much more value in being able to implement an idea (be it your own or somebody elses) than actually thinking it in the first place.
Open source seems to be pretty helpful in solving this problem. Similar to how a senior researcher will often be given a group of folks to implement his/her ideas, if you can start an open source project and convince a bunch of people it's worthwhile you can acheive much more in a shorter period of time than doing it by yourself. Of course, commercial environments are much like this, too, but it's often more difficult to sell ideas in a corporate environment. In a smaller business, you're likely to have a better chance. Starting a start-up to implement your idea is another great option, one that's usually significantly most costly than any of the others above.
I mention all of this without discussing goals. What is the goal of implementing an idea anyhow? For some, I suppose it's money. A good implementation of a good idea probably will get some level of recognition, and with clever distribution models for that idea, you could make some cash. But for a lot of people, I think it's laying the foundation for future ideas. As Simon puts it, infecting your audience with your idea. So when I mention “benefit,“ it's highly subjective based on whether you're a greedy bastard or a naive idealog (of course there are other choices, too ;)).
How does one evaluate the cost/benefit of following through on an idea? I wonder if there are any decent models out there that would help. I suppose choosing between ideas is a bit like branching between possible nodes in a graph in elementary utility theory. Simply calculate the probability of a given outcome, cost of traversing the node, and perceived benefit, and simply seek to minimize cost and maximize benefit. Seems so simple. The inherent lack of structure in human thought troubles me. The fact that I put up with it even more so.
Random.
Back to writing my book.
Friday, March 25, 2005
From Paul Graham's recent post
I think you should say "College is where faking starts to stop working."
This statement is up for interpretation. But I at least think I understand the gist.
I've always been fascinated with academia at least partially for this reason, and I've noticed a progressing desire as I age to be in environments where “faking it” is less and less tolerable. Microsoft is certainly more of a meritocracy, most academic organizations even more so. (Although, from what I hear, tenure tends to spoil this effect in many cases.) I spend countless hours of recreational time in order to improve my own thinking, mostly by studying formal theories and interesting works, but also through exercises such as writing compilers and learning new programming languages and ideas. It frustrates me to no end when somebody can get by, not on the merit or accuracy of their ideas, but rather due to politics or the networking effect of a bunch of fakers who can't recognize the difference.
But I am also very cognizant of what I do not know or understand. This, I think, is equally as important to knowing a lot. Well, at least in a person interesting in contributing at least one idea of importance to a field. Interestingly, Simon makes this same point in his “how to write a good research paper” talk referenced here. He advises that the process of understanding what you do not know helps you to better focus your research activities to fill in the gaps. I couldn't agree more. (In my limited experience.) The sooner you identify these areas, the sooner you can make progress.
I also find it interesting that, through the act of filling knowledge gaps, the foundational knowledge built up in your head seems to shift, sometimes causing other areas to become obsolete. This tends to create new gaps which need to be re-filled in the context of the new shifted foundation, but also creates new and interesting connections and clarifications on previously faulty mental models (which you might have thought were accurate, and which still likely aren't). But it's a beautiful, iterative process. No room for faking. And it certainly never ends.
Monday, March 21, 2005
Just a quick reminder, as Brad and Kit mentioned, a bunch of the CLR and BCL team will be at the Chili's in the Bellevue Crossroads mall tomorrow (Tue, 3/22). Starts at roughly 5:30pm... I'm hoping there will be more customers and partners than Microsoft employees!
Monday, February 28, 2005
Via the Daily ACK, the University of Washington has their Computer Science & Engineering colloquium series available online.
One gem in this series is "Google: A Behind-the-Scenes Look." The presenter discusses a little bit about culture, a tad about their algorithms, data centers, trends, ongoing research, and so on. Each of the topics could have a dedicated video in its own right. Still a great breadth-first overview.
I've always loved data. It seems to me that all of the creative and elegant software out there has arisen directly as a result of humans needing to deal with and categorize information. No data? Not much to do, now, is there? Sure, sure, ... people often cook up some hypothesis or artificial goal in order to get motivated, but processing information is so ingrained in what we are and do that it truly seems to be the reason for human existence.
Alright, maybe that was too preachy/zen-like/whatever. Just watch the damned video. :)
Saturday, January 22, 2005
So a while back I thought I'd be clever and post something entitled “Laptxp Pxrnx” (where x = o). It was completely innocent and simply depicted my three laptops strutting their stuff. They typically do not wear clothing and thus I had no compunction about posting photographs of them in their natural state.
Well, just recently I've begun to get a flurry of hits from Google (mostly from image search), and I'm confident that the massive amount of referral spam I get is at least somewhat related. Moreover, I am actually frightened by some of the search terms I see in the referrals.
Out of this I have distilled a moral: Avoid using naughty terms, even when you meant no harm. Google does not know intent, and dirty dirty people will stumble across your website. :)
(Btw: I am probably just improving the pxrnx post's page rank by linking to it above... ugh...)
Monday, January 17, 2005
Ouch. Them's are fightin' words. Break out the steer.
Friday, December 31, 2004
My flight for Boston leaves in 8 hours. I'm going home for a week to visit.
Should be a great time, lots of family and friends I haven't seen since moving out last June.
And I get to eat at Blue Ginger on New Year's eve with friends. Awesome prix fixe menu with paired wines. This'll be the third year in a row.
Posting and progress on much of anything will be light. I'll be back in the new year!
Tuesday, December 28, 2004
I just posted an internal thread we had recently to Channel9. The topic was a new set of DG updates resulting from security reviews. The thread actually ended up being a bit long (and had broken off into many semi-related tangents), so it had to be cut at about 1/4 of the entire thread.
It's worth a read.
Monday, December 27, 2004
The beauty of podcasting is that it gives everyone a voice, even those who might not typically have a channel through which to deliver a message. Race, socio-ecnomic class, and geographic don't matter. Solely based on the merit of content (or the individual), other people can subscribe and listen in on a regular basis. This is obviously one of the great facets of blogging, too.
Unfortunately, the podsphere is overpopulated with the incessant ramblings of boring people who lack anything interesting to say. Yes, they certainly deserve a voice. However, with hundreds of thousands of U.S. troops overseas and similar numbers of people (more?) affected by the recent earthquake and tsunamis, all of which would probably love to have their story heard (and quite frankly, would likely have a deeper message to send), why is this so? I realize podcasting isn't the first thing somebody thinks of in a tragic situation, but for the troops especially--where they must deal with lengthy stays overseas and have family members who likely have the necessary technology to receive such data--it seems this would be an amazing use of the technology. I suspect it's primarily due to lack of equipment and infrastructure.
We need to change that.
This is one reason why I intend to continue investing my life in making technology better and improving its reach: So that we don't have lame excuses such as this standing in the way of the creation and dissemination of information, regardless of who wants to publish or subscribe.
Sunday, November 07, 2004
When I should be writing and instead procrastinate, I come up with whacky ideas like identifying which words I make too liberal use of.
Breakdown of all words ocurring 25 or more times in my first chapter:
| the: |
1049 |
to: |
691 |
a: |
599 |
of: |
513 |
is: |
353 |
| and: |
332 |
this: |
319 |
in: |
305 |
you: |
295 |
that: |
292 |
| string: |
252 |
for: |
225 |
=: |
178 |
an: |
178 |
are: |
170 |
| it: |
157 |
as: |
157 |
with: |
155 |
will: |
150 |
on: |
130 |
| if: |
122 |
be: |
120 |
can: |
111 |
or: |
104 |
console: |
97 |
| type: |
96 |
example: |
88 |
object: |
85 |
method: |
84 |
when: |
81 |
| also: |
80 |
by: |
79 |
these: |
77 |
which: |
74 |
int: |
70 |
| number: |
70 |
code: |
70 |
use: |
70 |
using: |
69 |
instance: |
69 |
| your: |
67 |
gc: |
67 |
types: |
63 |
its: |
62 |
there: |
61 |
| s: |
59 |
value: |
59 |
{: |
59 |
}: |
56 |
class: |
56 |
| do: |
56 |
not: |
56 |
other: |
56 |
new: |
55 |
//: |
55 |
| from: |
55 |
time: |
55 |
but: |
54 |
simply: |
54 |
two: |
54 |
| methods: |
53 |
more: |
52 |
datetime: |
52 |
have: |
50 |
character: |
49 |
| any: |
48 |
at: |
47 |
should: |
45 |
characters: |
45 |
strings: |
44 |
| one: |
44 |
all: |
43 |
return: |
41 |
true: |
40 |
actually: |
40 |
| need: |
40 |
call: |
40 |
so: |
39 |
operations: |
39 |
0: |
39 |
| some: |
39 |
numbers: |
38 |
than: |
37 |
reference: |
37 |
system: |
37 |
| chapter: |
36 |
up: |
36 |
formatting: |
36 |
result: |
36 |
i: |
36 |
| set: |
36 |
just: |
35 |
because: |
35 |
data: |
35 |
following: |
35 |
| often: |
34 |
returns: |
34 |
into: |
34 |
information: |
34 |
such: |
34 |
| most: |
34 |
they: |
34 |
array: |
33 |
single: |
32 |
e: |
32 |
| only: |
32 |
same: |
32 |
we: |
32 |
available: |
32 |
has: |
32 |
| each: |
32 |
first: |
31 |
them: |
31 |
objects: |
30 |
public: |
30 |
| boolean: |
30 |
consider: |
29 |
out: |
29 |
exception: |
29 |
decimal: |
29 |
| would: |
29 |
point: |
29 |
static: |
28 |
10: |
28 |
values: |
28 |
| how: |
28 |
stringbuilder: |
28 |
end: |
27 |
even: |
27 |
provides: |
26 |
| equality: |
26 |
format: |
26 |
instances: |
26 |
buffer: |
25 |
Interestingly, I have 59 opening curly braces {, but only 56 closing! Yikes... Wish I could do some lexical analysis on my Word document.
Tuesday, October 26, 2004
I subjected a friend tonight to the oh-so-exciting task of providing feedback on my book. I'm finding outside input very helpful actually, mostly because the separation of good writing from technical content is an important one to make. Others are good at providing a relatively objective opinion on the words and sentence structure itself. I simply despise the common excuse that just because someone's a nerd, they aren't able to communicate well (or even in a grammatically correct fashion). And they get away with it, too! Not to say that I have mastered these skills yet, but I digress...
Anyhow, here it be:
“This book is so boring, it has to be good.”
Sunday, October 17, 2004
KitG posted the Nullable specification just the other day. To me as a Microsoft newbie (yes, I still recall what it's like on the outside), the fact that folks can now readily obtain previews of technologies and read the design specifications is pretty freaking cool... one step closer to complete transparency.
Tuesday, October 12, 2004
I need to set up a wiki or some other good means of capturing references and other interesting data. Bookmarks just don't cut it. In the absence of that, I'll just dump the top of my stack right here.
John McCarthy is a smart, smart man. The inventive capabilities of human beings never cease to amaze me.
Some Scheme papers...
A couple other random links...
I've been searching for and have only found a few digital copies of the papers referenced in the last link. This is a great candidate for a wiki so links can easily be added as they are located...
Saturday, October 02, 2004
I've been really bad about blogging lately. So much to do, and so little time in which to do any of it. One thing sure remains constant: time keeps ticking away.
Over the last couple weeks, I've been working on a book proposal and outline. It got submitted last night. I was approached by a publisher a few weeks back to author a book, and if all continues going well I'll likely take the offer. I'm particularly excited about the project albeit a bit scared about the time commitment.
Progress on my Scheme compiler has been minimal because of the book effort. This is really a shame because I'd spend all day working on it if I could. Like I said, time is something I'm short on at the moment.
I began writing a paper which I'd love to complete, but that will likely take some time. It explores using structural equivalence for type matching and operational subsumption, foregoing the artificial inheritance policy that OO slams on types. I'm particularly interested in exploring how this would enable rich ecosystems of types to borrow and share implementations from each other at runtime, introducing mutations in parallel. Basically, an evolutionary type system.
Microsoft has been going well, although it obviously eats up most of my time and energy. Mostly this is a shame, simply because I have research work like my Scheme compiler that I am completely in love with. The energy people have there is just sickening at times, and it's difficult to remain in the game 100% of the time. I've found that it's easy to fall behind and lose effectiveness, simply because of a loss of focus for a minimal amount of time.
I had one of those "you're a moron" moments today. Was sitting there, and suddenly some guy shows up at my office door. I was so involved in what I was doing, my brain just couldn't do the context switch fast enough. Paraphrasing... "Hi, I'm Herb. Do you agree with the premise of the email I sent earlier?" I responded, "The value type finalizer thing?" Blank stare between the two of us. Him: "Value types don't have finalizers..." Perplexed, I thought about it for a moment. Ahh, yes... "Oh, disposable value types." Turns out it was Herb Sutter, a C++ Architect and smart dude. It always amazes me how whenever I open my mouth I make myself look like an idiot.
I went to a friend's place last weekend to hang out. It's great to unwind and let the noggin' relax for a little bit. Unfortunately, it again reminded me of my lack of a strong long term career goal. I used to think that it was being a (successful) entrepreneur, as various business topics have always interested me (such as competition and macro-economics). However, computer science is my passion, and academia and/or a research environment seems like a natural fit. I thought of this because many of the folks at the gettogether were PhD's and there was at least one professor from UoW. I wonder every day if that's my real calling.
Chilled with KitG, JoelPob, and AMoore tonight for a couple beers. Two Aussies and a New Zealander. All on the same team. Who woulda thunk it? Good fun.
Anyhow, it's only 1AM and I've got some reading to do!
Monday, September 27, 2004
Another one of those "What kind of person am I?" surveys... courtesy of Mr. Sells.
 |
 our distinct personality, The Prime Minister might be found in most of the thriving kingdoms of the time. You are a strategist who pursues the most efficient and logical path toward the realization of the goal that you perceive or visualize. You will often only associate with those people who can assist you in the implementation of your plan. Inept assistants may be immediately discarded as excess baggage. To do otherwise could be seen as inefficient and illogical. On the positive side, you can be rationally idealistic and analytically ideological. You can be a bold decision maker and risk taker who can move society ahead by years instead of minutes. On the negative side, you may be unmerciful, impatient, impetuous and impulsive. Interestingly, your preference is just as applicable in today's corporate kingdoms.
|
I especially love the bit about being impatient and impulsive. Me? Naahhh...
Friday, September 24, 2004
We just had a DevDiv get-together (that's Developer Division for nonconformists out there)... free beer, and a couple hours to wind down is never a bad thing. At one point, we had a discussion burning away about the optimal number of children a couple should have. In the midst, the following gem popped up:
Brad: I've been successful at convincing her we should have a prime number of children.
Anthony: Yes, then at least you could store them properly in a hashtable.
<ensuing laughter>
Good point, I thought.
Sunday, September 05, 2004
I have a relatively shnazzy home theater system... nothing extraordinarily special, but we have a dedicated entertainment room, a 57“ Sony widescreen display, and a Bose Lifestyle sound system. And, what do I use such toys for?...
Watching movies, of course. 
Which movies? These ones:
- Structure and Interpretation of Computer Programs
The classic MIT course, video captured from the mid-80s. It's amazing watching this how little has changed in the field of computer science since then. Yeah, yeah, different languages, some new fancy shmancy runtimes, APIs, and the like... but the foundation seems to be proving fairly rock solid. The accompanying Wizard book is available online in its entirety, as well as some wiki content on c2. Caution: downloads are massive.
- Dynamic Languages Wizard Series
This series consists of three panel discussions covering language-design goop. Specifically, there's one for runtime, one on compilation, and another on language design. Definitely worth watching each once, perhaps twice. (Unfortunately, these are in QuickTime format. I actually installed that crapware just so I could watch these videos... what a man will do for his love of geekhood.)
Any other suggestions for similar online content out there? Thanks to Peter Drayton for the pointers to both of these.
(Yeah, yeah, using my DVD burner'd probably be significantly easier than my hack wiring... but, I'm a cheapo. Last I checked, blank DVDs are hovering in the low-to-mid $10s.)
There are a couple other DVD-based videos which I am particularly fond of, too:
 |
Triumph of the Nerds
Done by Robert Cringely, there are three primary documentaries on a single DVD, each of which details a particular step in the evolution of personal computing. For some reason, I have watched the entire series 5 or so times... it's just good entertainment! It contains interviews with BillG, Steve Balmer, Larry Ellison, etc. way back in the day... as well as the creator of the Altair! Oh man, I'm getting so excited typing this that I think I'll go steep a cup of tea and watch it right now. |
 |
Revolution OS
Details the rise of the Linux OS and FSF/GNU, through interviews with Linus Torvalds, Richard Stallman, Eric Raymonds, among others. Contains a couple skewed perspectives (I recommend ignoring the narration), but all-in-all I found it informative. |
Monday, August 23, 2004
You just have to love the age of ubiquitous, blazingly quick Internet access. Virtual information at your fingertips...
>ping -t www.bluebytesoftware.com
Reply from 209.35.183.214: bytes=32 time=78ms TTL=48
Reply from 209.35.183.214: bytes=32 time=79ms TTL=48
Reply from 209.35.183.214: bytes=32 time=80ms TTL=48
Reply from 209.35.183.214: bytes=32 time=77ms TTL=48
Reply from 209.35.183.214: bytes=32 time=82ms TTL=48
Reply from 209.35.183.214: bytes=32 time=77ms TTL=48
Reply from 209.35.183.214: bytes=32 time=93ms TTL=48
Reply from 209.35.183.214: bytes=32 time=79ms TTL=48
Reply from 209.35.183.214: bytes=32 time=79ms TTL=48
Request timed out.
Request timed out.
Reply from 209.35.183.214: bytes=32 time=78ms TTL=48
Reply from 209.35.183.214: bytes=32 time=84ms TTL=48
Reply from 209.35.183.214: bytes=32 time=79ms TTL=48
Request timed out.
Request timed out.
Request timed out.
Reply from 209.35.183.214: bytes=32 time=80ms TTL=48
Reply from 209.35.183.214: bytes=32 time=79ms TTL=48
Reply from 209.35.183.214: bytes=32 time=92ms TTL=48
Reply from 209.35.183.214: bytes=32 time=77ms TTL=48
Request timed out.
Request timed out.
Reply from 209.35.183.214: bytes=32 time=2173ms TTL=48
Reply from 209.35.183.214: bytes=32 time=80ms TTL=48
Reply from 209.35.183.214: bytes=32 time=77ms TTL=48
Request timed out.
Request timed out.
Reply from 209.35.183.214: bytes=32 time=77ms TTL=48
Reply from 209.35.183.214: bytes=32 time=77ms TTL=48
Reply from 209.35.183.214: bytes=32 time=81ms TTL=48
Reply from 209.35.183.214: bytes=32 time=94ms TTL=48
Request timed out.
Reply from 209.35.183.214: bytes=32 time=159ms TTL=48
Reply from 209.35.183.214: bytes=32 time=80ms TTL=48
Reply from 209.35.183.214: bytes=32 time=88ms TTL=48
Reply from 209.35.183.214: bytes=32 time=345ms TTL=48
Request timed out.
Request timed out.
Request timed out.
Request timed out.
Request timed out.
Request timed out.
Request timed out.
Request timed out.
Request timed out.
Request timed out.
Request timed out.
Request timed out.
Request timed out.
Request timed out.
Request timed out.
Request timed out.
Request timed out.
Request timed out.
Request timed out.
Request timed out.
Request timed out.
Request timed out.
Request timed out.
Request timed out.
Saturday, August 14, 2004
340hp. 4.2L V8. German engineered.
I love it. And yes, I enjoy frivolous, wallet draining toys.
Saturday, August 07, 2004
I'm not sure why, but that frightening Playskool doll from the 80s and its accompanying theme song (which sends chills down my spine when I reminisce about it, I might add) popped into my head when contemplating this post. I'm sure that little invention is to blame for many a child's nightmares... Anywho, on to the real content. Right-o.
When I saw BradA's post about the ISV Buddy program back in early July, I ran right out and signed up immediately. I decided only to sign up for 1 right now, as I was hesistant to overcommit on bandwidth...
Well, I just received information about my newly assigned buddy today! The whole concept is really cool - that is, hooking up an ISV professional working “down in the trenches” with a Microsoft professional also “down in the trenches.” It's a bit like a penpal thing, but with perhaps more structure and concrete goals. I'm looking forward to it.
(By the way, when I first arrived at MS, I was a little concerned and confused when I saw posters depicting Sanjay Parthasarathy and Eric Rudder (two MS execs) as bobbleheads, accompanied by the phrase “He's not kooky, he's my buddy.“ littering the walls. It all made sense as soon as I read Brad's post... To the poster designers' credit, they did include a URL at which one could read more information on the program. I suppose the ever increasing proliferation of sticky notes with colorful comments by other employees that decorated each poster diverted my attention enough that I never thought to go read more about it. This video shows the animated version of the poster. :) )
If you're unfamiliar with the program, I recommend you check it out. |
Monday, August 02, 2004
I'm aware there's a problem adding comments at the moment (i.e. they don't show up at all)... Please continue adding them. I am still receiving the email notifications with the full details.
I'll fix this tonight and will manually add the backlog of comments once it's functional again.
Update: They're baaaack... I guess that's what happens when you upload a couple rounds of digital images (400+MB), forgetting that only a limited quota of space is available for the taking. Duhhh...
Tuesday, June 08, 2004
Upgraded to dasBlog 1.6... reworked the layout and color scheme of the site...
Just making sure it functions properly!
Friday, June 04, 2004
...comes in many forms.
(defun fib (n)
(if (< n 2)
1
(+ (fib (- n 1)) (fib (- n 2))))) |
|
 |
 |
Thursday, June 03, 2004
"Human beings have been reduced to consumers."
"Americans are just now waking up to the real world [of Globalization]."
"Globalization has to be a two way traffic."
The Discovery channel is currently airing a special entitled "Thomas L. Fieldman Reporting: The Other Side of Outsourcing." Its content is mainly concerned with the impacts of outsourcing on India's traditionally family- and ritual-centric culture. I still need to digest some of the information, but it's definitely an eye-opening viewpoint.
I usually don't post simply for “Mindless Link Propagation” - as Dare calls it - but this post is of particular importance.
Josh Ledgard, Chief Community Evangelist at Microsoft, talks about the legal implications and challenges (via Scoble) that arise when early community involvement is solicited in the product lifecycle. It sucks big time when such legal barriers have the potential to force one to sidestep in the wrong direction... but consider the consequences. Yikes.
(BTW, I find Scoble's response pretty ignorant and childish, and akin to a teenage fit of rebellion. Dude, there's a reason legal departments restrict certain things... because there are implications should these safeguards not be put into place. Microsoft owns its IP, and as such can tell anybody - yes, even Scoble - what they are or are not able to do with it. Regardless of on whose time it occurs.)
Wednesday, June 02, 2004
ABC DEF
Anything significant about this sequence?
Yup. The seating pattern on the 737 I am currently flying on. In seat F.
Just a moment ago, man in seat D says to woman in seat E, "Huh, huh... if it smells in a minute, it's because I farted."
Loudly. He had headphones on, and some people's ears don't take to altitudes of 35,000 feet very well, so he may not have realized it. But that's no excuse. I heard it loud and clear. But even worse...
Moments later, man in seat D's ass particles entered my nostrils. Splendid.
Exhausting day yesterday. 80%, brain faltered in some key areas. Didn't step back enough. Sit back and wait.
Had some more curry last night, this time from Chutney's in downtown Belevue (via Don Box yet again). The food was awesome, albeit a little toned down (”Americanized”). I think my body is wondering what the hell I'm doing to it - extra spicy korma yesterday night (as hot as they could make it 7/7, a mistake in hindsight) and vindaloo last night (this time I went a little milder 4/5).
Monday, May 31, 2004
I'm in Redmond for a couple days (staying in Belevue actually). I've never been before, and have a couple of observations after one half day.
- Hotel staff, Starbucks baristas, and random strangers engaged in conversation with me. People I've never met previously. Courtesy and friendliness? Does it really still exist?
- In general, people seem to have a little less stick stuck up their bums in comparison to back home (MA).
- Plenty of Indian restaurants. Lost in the yellow pages, I turned to an expert for some help. My take-out chicken korma, vegetable samosa, paneer naan, and gulab jamun from Kanishka were awesome. Unfortunately, I can't keep the leftovers as I don't have a fridge in my room.
- Lots of trees, even more than New England.
- It's almost 9pm, and it's still light out! (???)
Monday, May 24, 2004
A man can never have too many laptop computers...  
Isn't it just a thing of beauty?
Sunday, May 23, 2004
It's that time of year again. Yup, that's right: the time when many of the toasts popping up in my aggregator are about a single topic... TechEd.
Unfortunately, I'm not able to make it this year. With a wedding in the process of being planned, family events this week, the real possibility of some significant changes in my life, and in general a lot of stuff going on, I've opted to go the less risky route. Wish I could make it. For those of you who will be there, throw a few back for me (oh, and soak up some knowledge, too...)!
Sunday, May 09, 2004
Am I the only one who finds the task of hyperlinking references made in blog entries tedious and repetitive? Either I'm missing something and am a moron, or I need to move to a Blog/Wiki engine to prevent from having to deal with such minutia, for example hyperlinking to the WS-ReliableMessaging specification time after time after time after time after time after time and again.
Monday, April 19, 2004
I found the following meme via IanG, so I
decided to join in:
Grab the nearest book. Open the book
to page 23. Find the fifth sentence. Post the text of the sentence in your
journal along with these instructions.
My nearest book was "Logistics and
Supply Chain Management;" on page 23, the fifth sentence says:
So much has been written and
talked about service, quality and excellence that there is no escaping the fact
that the customer in today’s marketplace is more demanding, not just of
product quality, but also of service.
|
|
Me
Joe  is an architect and developer on a systems incubation project at Microsoft.
Recent
| Comments disabled ... sorry |
| Work fun |
| We are hiring |
| Jobs |
| RoboZZle: a new social puzzle game |
| Upcoming talks |
| New parallel computing jobs |
| Happy New Year & .NET Rocks! |
| Book update |
| Butler Lampson's "Hints for Computer System Design" |
| Books in my brain |
| Developer to PM, and then back again |
| Jim Gray missing for nearly a week |
| 5 things you didn't know about me (off topic) |
| PLINQ talk at DAMP workshop (co-located with POPL 2007) |
| Poll: Managed, native, or both? |
| A new role for me at Microsoft |
| Dijkstra: My recollection of operating system design |
| Concurrency book -- what do you want to see? |
| JAOO'06 Slides: Concurrency and the composition of frameworks |
| Lang.NET Symposium '06 -- Thottam's write-up |
| A fun hack: Cross-process RWLock using Windows kernel objects |
| Upcoming speaking at JAOO'06: Concurrency and the composition of frameworks |
| My take on the BillG thing |
| MSDN mag - CLR Inside Out: What do you want to see? |
| Books |
| Games and concurrent programming |
| Online book companion |
| Books for me, sir, please and thank you |
| Scrounging for change |
| The Book, life, and more non-technical goop |
| PDC Talk: Writing a Compiler in One Hour |
| Well that was fun! |
| Don't be lulled into inaction |
| Debugging FX build problems on Rotor (FJIT AV) |
| PDC 2k5 |
| bloink |
| The book: assembly chapter structure |
| Bjarne on exception safety |
| Performing surgery on the blog |
| Refactoring the blogroll |
| Ideas and implementation |
| Are you faking it? |
| Geek dinner in Bellevue tomorrow |
| Behind the scenes at Google |
| Random: Avoid naughty keywords |
| Bad code names? |
| Off to New England |
| Internal DG thread on Channel9 |
| Podcasting, improving the reach of technology |
| Word count analysis |
| A great book review quote |
| The Nullable specification |
| Linkopedia |
| Going ons |
| Your distinct personality: The Prime Minister |
| Optimal number of children |
| Movie recommendations for long weekends |
| Surfing at the speed of light |
| Vroom, vroom |
| My buddy, my buddy... My buddy and meeeee... |
| Blog comments |
| Test |
| Natural beauty |
| The Westernization of India |
| Community involvement and legal implications |
| Nasty, nasty, nasty |
| More chillin' in Redmond |
| Chillin' out in Redmond |
| Laptop porno |
| TechEd |
| Hyperlinking |
| Page 23 Meme |
Search
Browse
Disclaimer:
The content of this site are my own personal opinions and do
not represent my employer's view in anyway.
© 2013, Joe Duffy
|
|