Enough time has passed that I feel safe blogging about my prior project here at Microsoft, “Midori.” In the months to come, I’ll publish a dozen-or-so articles covering the most interesting aspects of this project, and my key take-aways.
There’s one especially important trait I look for in great team members: intellectual honesty. Many other traits typically follow suit, but lacking this foundation can lead to frequent Kobayashi Maru situations. At best, those slow down the team without adding value, and at worst, turn an entire team toxic and ruin its core cultural values. And it can happen quickly.
It seems that I completely blow away and recreate my blog every two years or so. The time has come. I ended up horking my prior setup and have moved everything over to GitHub.
One technique we explored in my team’s language work is something we call “fail-fast.” The idea is that a program fails as quickly as possible after a bug has been detected. This idea isn’t really all that novel, but the ruthless application of it, perhaps, was.
No matter how smart of a leader you are, you’re going to be wrong sometimes. Often even. And you won’t always have the best ideas.
I work in a team where the microkernel is developed in close partnership with the backend code-generator. Where the language is developed in close partnership with the class libraries. Where it’s just as common for a language designer to comment on the best use of the language style in the implementation of the filesystem, as it is for such an exchange in the context of the web browser, as it is for a device driver developer to help influence the overall async programming model’s design to better suit his or her scenarios.
One of the first questions I ask when joining a new team is: Where do code reviews happen?
My team has been designing and implementing a set of “systems programming” extensions to C# over the past 4 years. At long last, I’ll begin sharing our experiences in a series of blog posts.
What I am about to say admittedly flies in the face of common wisdom. But I grow more convinced of it by the day. Put simply, there ought not to be a distinction between software research and software engineering.
I am naturally drawn to teams that work at an insane pace. The momentum, and persistent drive to increase that momentum, generates amazing results. And it’s crazy fun.