This is a very intruiging graph that immediately gets you thinking about survival rates, about whether new cases are rising or falling, and the obvious contrasts between, say, prostate and pancreatic cancers. But Jon then goes on to link to a post about how to make graphs like this yourself featuring your own numbers (sales? expenses? bug rates? time spent?) in Excel. I am consistent amazed at what Excel will do for people who know what they're doing. Check it out.

Andrew Clifford has a slightly controversial blog post in which he makes this claim: real programmers don't test. Well, on further investigation, what he really says is that really good and experienced programmers don't have a separate testing step at the end. And even in that diluted form, I'm not sure I agree. My developers think of tests before they code, and they test as they go, but on large development projects (and some small tasks for that matter) I still have a tester take a run through the system to make sure there is nothing that we would cringe if the client were to find .

The Braidy Tester has a way of thinking that may scare you a bit and a huge list of tests that you need to run at the end in his "you are not done yet" lists for testers and developers. The first item on the developer list is the most important to me -- when you find a bug, ask yourself why it didn't turn up earlier. Why did we wait until we were 90% complete to test with their old data? Why did nobody print this before? Why has it been three months since anybody tried adding a customer record before using this screen? "Why" questions tend to hurt a bit, but they prevent pain in the future. And folks who test as they go, who test in their minds before they design or code, can fly through a "you are not done yet" list and say "yes I am!"

Another tip from Steve Clayton, this one about Hotmap, which aggregates local.live.com searches and maps, letting you know what places people are asking for maps of - where they want to go. Steve did an England map, but I did Ontario and surrounding areas. The darker red squares have had more map requests:

To a certain extent it just correlates with population, but also with Internet use, how visited a place is, and perhaps a certain Microsoft-vs-Google demographic as well.

The transparency from Microsoft these days is getting frankly astonishing. Here's something I've never seen before, courtesy of Steve Clayton, blue-monster-spreader:

When you understand where a company gets revenue from (and where it doesn't) then things are more likely to make sense to you. Steve's comments about SharePoint are interesting too and follow his link back to Todd Bishop's take on this.

A former Softie friend of mine IM'ed me about this job. Sure, you need C++ skills, but there's more to it than that. They need a variety of skills because you'll get to do a variety of work... off the top of his head he listed:

multiplayer game infrastructure

chat and presence application

drm / installer

IE toolbar

flash applets

a bunch of other stuff

There's a Craiglist ad, which includes application instructions. This is in Seattle, by the way.

Long Zheng has a lot of Microsoft-watching going on. This image comes from a slide he highlighted from Steve Ballmer's presentation for FAM (I already highlighted Craig Mundie's comments to the same audience.)

If you want to get started in C++ development, or try some parts of it you haven't tried before (remote debugging, perhaps?) then you should take a look at these little video lessons on MSDN. They're adding more as they go, so keep an eye on it...

And so the world is going to move more and more away from one CPU that is multiplexed to do everything to many CPUs, and perhaps specialty CPUs. This is not the world that the programmers target today. This kind of complexity was historically reserved only for the wizards who wrote the core operating system; or, in the world of supercomputing in science and engineering, people who had the ultimate requirement for computational performance built big machines like this and have used them to solve some of the world's tough computational problems. That was always a niche part of the industry.

This presages a change where the industry at large, the whole concept of applications, will ultimately have to be restructured in order to think about how to take advantage of these machines, because they won't just get faster every year. They'll get more powerful, but in fact only if you're able to master these problems of concurrency and complexity.

The concurrency is a real challenge, because the way the industry has grown up writing software - the languages that we chose, the model of synchronization and orchestration, are actually not things that lend themselves toward either exposing parallelism or allowing large-scale composition of big systems and it's in part why we and everybody else, as the software grows in scale, you know, deal to a greater and greater degree with the difficulty of perfecting the software, making it absolutely secure, being able to predict every aspect of its operation. And so today we face the dual challenge of having the prospect of meeting even bigger, more sophisticated pieces of software to do the powerful things that we want, and to do it in an environment where to get that performance at the client on an individual application will require the mastery of parallelism.

This is Microsoft's Chief Research & Strategy Officer, folks. And he says what I say: concurrency is hard, and the future is concurrent. I know we all get by in this crazy churning world of constant new releases by ignoring stuff, but you can't ignore this.