Musings on leadership

Nathan Brixius — Wed, 11 Jun 2008 22:10:00 GMT

It occurs to me that there's a difference between "getting the most" and "getting the best" from someone.

What makes a good software developer

Nathan Brixius — Tue, 24 Jul 2007 03:59:00 GMT

A colleague asked me to jot down some thoughts on what makes a good developer at Microsoft. This is by no means complete, but three statements come to mind when I think about strong developers:

We are engineers, not hackers.
A strong dev should be able to fill any engineering role in the company.
Senior devs improve their teams by action and by example.

We are engineers, not hackers. My dev manager in Project (my previous team) said this years ago and it has stuck with me ever since. Engineering is a craft whereas hacking is a hobby, and I expect a Microsoft dev to seek to become a master of the craft. Engineers understand common patterns underlying the problems they solve and seek to make their code predictable and reliable. (This doesn't suck the creativity or joy out of the process, rather it should liberate us.) For an engineer, process is not an end to itself but a tool for arriving at solid designs and trustworthy code. Engineers take great pride in their creations and stand behind them.

Engineering practices apply to all stages of software development. In the design phase I expect a structured approach that leads to a design that clearly meets the needs described in the spec. The deliverable is a design doc that describes how the feature is implemented. A good design doc is an aid to the developer, his/her peers, as well as Test/PM. I don't want to get into details about what makes a good design doc, but it should describe the primary design and implementation challenges and how they are addressed, and why other reasonable approaches were rejected. On a services team it's particularly important to think of the impact the feature has on setup, deployment, and monitoring, and account for these early.

Everyone has things to say about coding guidelines, so I won't dwell on them much here. I assembled a set of team-wide guidelines and I expect those to be followed. I always look for simplicity and consistency. As a services team I particularly value unit tests and tracing.

Finally, I expect a positive handoff to test. By this I mean a detailed TRD (test release document) that describes what the feature does, what works, what doesn't work, and suggestions for testing the feature. I expect code to be structured so that it is easy to test as possible. I don't particularly care for metrics based on the number of bugs a dev fixes. I value developers who prevent bugs from happening in the first place, and it's easiest to do this in the earliest stages of the project before any code is written. This begs the question of how do we measure the quality of a feature relative to the time spent on it. I don't have easy answers except to say that if leads and peers are involved in the entire development process, it is easier to come to a collective understanding of how challenging a feature is and how well the developer has done at implementing it. In other words, it comes down to judgment.

A strong dev should be able to fill any engineering role in the company. The statement applies in two ways. First, a dev should be able to wear their "PM hat" or "test hat" and operate effectively within that role. Perhaps this is statement is too "old school Microsoft", and I certainly don't mean to detract from the roles of Test and PM. After all, Test and PM are also engineering disciplines. I simply mean that devs have a deep understanding of customer requirements and are able to make their own assessments of the relative priority of features and work items, and can make suggestions as to how to improve the experience. Devs should be able to be ruthless testers of their own (and their teammates) features and provide actionable feedback that results in improvements. They write unit tests, which guarantee a certain level of quality. Having the ability to operate in another role also prevents a dev from becoming blocked, and provides broader perspectives which assist devs in interacting with their Test and PM counterparts. Everyone understands where everyone else is coming from, and that makes for a more enjoyable working environment.

Secondly the statement means that a dev is not dependent on domain-specific knowledge to be effective. A deep understanding of specific technologies, code bases, and design patterns is essential for good engineers. But a strong dev is not a "one trick pony" that can only work in one area (though they may prefer to do so, and may be asked to do so from time to time). A dev has technical depth, but also technical breadth, which allows them to see how their code functions to serve a larger purpose. I'd like to think that I could be dropped into the middle of Windows, and though I would probably hate it, I would be effective.

Senior devs improve their teams by action and by example. There are only so many hours in a day, so at a certain point it becomes more difficult to provide more value by simply coding more or working longer. Actions that make others better have a compounding benefit that can have a huge impact over time. Most of us can think of old timers that seem to have an awesome level of productivity, to the extent that it's hard to understand how they can be that effective. I suggest that in most cases, these old timers have mastered the art of making others better. First, they typically do not worry themselves about things like "scope" or "area". Making Microsoft better is their "area", and that extends to fixing bugs in other dev's code, fixing build problems, improving processes, giving feedback to other teams. Master devs share knowledge, through conversations, whiteboard sessions, documents, blogs. They cringe when they hear people talk about "their code"; it's "our code". Their movements are not hurried, but always with purpose. They've got time for other people, and still get their work done. They're able to do this because they identify patterns in their work and automate them, either by defining a design pattern, or by architecting the system appropriately, or by writing tools that do their work for them. Then they share this knowledge with the rest of the team and build a culture where others do the same. Lastly, they continually seek new opportunities to make themselves and their team better. These opportunities come up all the time in a product cycle; a master dev spots them first and steps in to fill a need, for example by forwarding an email to someone who knows the answer; seeing that a new platform component could help implement features in two different projects; adding a new unit test that enforces a coding or stylistic convention.

I love it when devs are passionate about delivering something that works and is useful!

How to generate a GUID in 250K easy steps

Nathan Brixius — Mon, 04 Dec 2006 23:31:00 GMT

A friend on my previous team wrote a tool to generate GUID values where the first two bytes are zero. (And I'll say right here that I don't think there is a legitimate need for such a tool, but that's not the point.) I'm working from memory but the C# code was something like:

public static Guid Generate()
{
   Guid guid = Guid.NewGuid();
   while (!guid.ToString().StartsWith("0000"))
   {
      guid = Guid.NewGuid();
   }
   return guid;
}

As I said, it was for a tool, and it would only get called once so the perf doesn't really matter; it gets the job done. I just thought it was a pretty funny approach. The friend in question was an excellent programmer, so I am going to blame it on too many limoncellos. All I know is that now he's in law school.

Generating a GUID and just zeroing out the first two bytes (using ToByteArray and the appropriate Guid ctor) appears to be about 250,000 times faster. That seems about right, if you think about it.

The Jordan Rules

Nathan Brixius — Wed, 29 Nov 2006 01:33:00 GMT

Part of what I am enjoying about The Best and The Brightest are the profiles of the generals, presidents, and policy makers. McGeorge Bundy was the Special Assistant for National Security Affairs under JFK and LBJ; prior to this he was a faculty member and president of Harvard.

p.58: "Even the slight nastiness, which has from time to time been a Bundy trademark, was an advantage; he had the ability to be unfair, to go after special men and give them special privileges, people like Riesman and Erikson who did not teach as much as other members of the faculty."

When I read this passage I immediately thought to myself, "Jordan Rules". The Jordan Rules is the name of Tribune writer Stan Smith's book on the Chicago Bulls' first championship season. If I remember correctly, in the book the term refers not to how the Pistons would try to defend Jordan but instead the special accommodations made by teammates and coaches because of his star status. Another theme is Jordan learning that he needs his teammates to win, but to me that's less interesting. What interests me is that there are two sets of rules - one for Jordan and one for everyone else - and ultimately that's okay because MJ is MJ. There's 12 (or maybe 15, I forget) guys on a team so the system can work. It is clear why Jordan gets special privileges because everyone sees the results (and the means) for themselves. If a guy is outworking you, whipping you in practice, and carrying your team in games it's hard to argue too much. This kind of power can be damaging if taken too far (see: Kobe Bryant). Back to the quote, I'm not so sure the Jordan Rules work as well in a larger organization like a university because "the stars" are less visible. To be clear, I'm not necessarily advocating it, I just think it's an interesting concept. Questions like these have been popping up every few pages as I work through the book.

Last note: David Halberstam has also written a book about Jordan, it's called "Playing for Keeps". I haven't read it, though.

Nathan Brixius : The Best and the Brightest

Musings on leadership

What makes a good software developer

How to generate a GUID in 250K easy steps

The Jordan Rules