All companies have a job ladder a person “climbs” as they progress through their career. Often this job ladder and a person’s title are tied together. Microsoft separates the ladder (i.e., the responsibilities of and expectations for a person) and the title – essentially separating your role from the proficiency with which you fill that role. If you’re a developer and don’t have any direct reports, you’re generally a Software Development Engineer. Likewise, if you’re a tester and don’t have any direct reports, you’re generally a Software Test Engineer.
In the last several years a new title has appeared: Software Development Engineer in Test, often abbreviated SDE/T. Various people have asked me over the years to explain what I look for in SDE/Ts, or whether I think a certain STE is ready to become an SDE/T. This is my answer.
Before I can tell you what a *great* SDE/T is, I need to tell you what I think an SDE/T is. “SDE/T” has almost as many different definitions as there are different teams, ranging from “if you write code you’re an SDE/T” to strict “spends nn percent of the time coding something other than test cases” to simply “writes dev-quality code”.
The one thing every definition has in common is the concept of a tester that develops – which could be restated as a developer working in the test space. Either way, a great SDE/T clearly must be both a great tester and a great developer.
A great SDE/T, then
First and foremost, a great SDE/T is a great tester. Developers can write tools for testers just as easily as they can write tools for any other client, but just as the most successful applications achieve that state in part because their developers truly “got” the problem being solved, being a great SDE/T requires a tester mentality. In other words, being a great SDE/T requires being a great tester.
A great SDE/T clearly must be a great developer. Lots of testers write tools to make their jobs easier, and these tools can become a vital part of the feature team’s or product team’s testing strategy. Many of these tools, however, are not well written. A great SDE/T makes a difference not just because their tools get the job done but because those tools are well crafted and easily maintained – the only kind of application a great developer writes.
Lives to make things that breaks things
A great SDE/T constantly invents new tools that help them find bugs. A great SDE/T sees a tool in every task they contemplate. A great SDE/T’s driving force is writing code that breaks other code.
Is a synergy of the developer and tester worlds
“Software Development Engineer in Test” doesn’t tell the entire story. A great SDE/T is more than a great tester who happens to also be a great developer (or vice versa). A great SDE/T combines their deep knowledge of how applications are written with their deep knowledge of where bugs lurk and how to find them to create tools that help testers find more bugs and help developer write fewer bugs.
The Rumored Existence Of Great SDE/Ts
Am I a great SDE/T? No. I have areas to work on. Do I have any great SDE/Ts on my team? No. They all have areas to work on as well. Have I ever met a great SDE/T? No.
My team, however, is full of good SDE/Ts that are each great in certain areas. I daresay I myself am a good SDE/T and am great in certain areas. I certainly know other good SDE/Ts that are great in certain areas.
Thanks to colleagues Mike, Mario, John, and Scott (none of whom blog yet, gosh darn it) for taking the time to review these posts, provide excellent feedback, and suggest additional hallmarks!
*** Comments, questions, feedback? Want a fun job on a great team? Send two coding samples and an explanation of why you chose them, and of course your resume, to me at michhu at microsoft dot com. I need a tester and test lead, and my team needs a data binding developer, program managers, and a product manager. Great coding skills required for all positions.