I have spent a considerable amount of time talking with my wife Marianne on what I should do my first blog post about. She gets to hear all of my praises, rants, and questions as I perform my job as a Principal Quality Lead at Microsoft. Our discussions around specifics about my project have been thin lately simply because I am currently working on a super cool but clandestine product.
As it turns out we are on vacation in Newport Beach, CA as a family. Marianne and I stay at her Grandma’s house while our girls stay with their cousins at my in-laws place. The last couple of mornings Marianne and I have been taking an hour and half walk to get coffee at Starbucks and get some much-needed exercise. While on these excursions and through our discussions, my blog post topic has become clear.
At Microsoft we have a three discipline engineering paradigm; SDE (Software Development Engineers), SDET (Software Development Engineers in Test), and PM (Program Managers). All three disciplines are considered engineering and therefore engineers. The proficiency levels for determining one’s compensation are the same across all three disciplines (I will go into details of our leveling system in a future entry). That is to say that a level 63 SDE, level 63 PM, and a level 63 SDET all make the same amount of money.
For this blog post I am going to focus on the SDEs and SDETs. SDEs, for the most part, write product code. SDETs rarely, if ever, write product code yet in most cases SDETs write much more code than SDEs; it is just code that never ships.
I am just going to come out and say this and then we will dissect it somewhat – I believe that SDEs and PMs see SDETs as less experienced, not as knowledgeable about deep coding problems, and less proficient technically. Ok, I know that some of you may leave comments lambasting me over this claim but before you do please read on. Now for the next shocking statement – For roughly 40% of the SDETs I know at Microsoft I would agree with my SDE and PM brothers and sisters that feel this way.
This brings me to my first “What Makes Me Angry” point. The SDET discipline is largely responsible for bringing this perception about. Back in the Y2K timeframe Microsoft had been sued by a group of Contingent Staff (CSG) employees.
Contingent Staff – Temporary contract personnel placed at Microsoft by Volt Consulting and Excell Consulting companies.
The reason the CSGs were suing was because some of the groups at Microsoft had kept some of these people on for several years and they no longer felt like temporary employees and therefore should be extended medical and other benefits that Fulltime employees enjoy. Microsoft then forced all groups/teams with CSGs to either hire their CSGs into fulltime positions or stop the current contract with the CSG in which the CSG would have to find other employment than Microsoft for 90 days before being able to come back to Microsoft on a new contract. That new contract would be limited to 1 year, after which the CSG would need to take another 90-day break.
What most Test Groups at Microsoft did was hire a good portion of these CSGs into Test Positions. Back then there was another type of tester – an STE or Software Test Engineer. STE’s typically only did manual type test execution (walking through end user scenarios with a mouse and keyboard) or limited scripting like Visual Basic Script to execute data driven tests. The STE position is what most of the newly hired previously-CSGs became. These employees were less technical and often topped out a given compensation level (~62).
Now that you are somewhat informed on this let’s get on to the meat of the post – In ~2005 Microsoft decided to get rid of the STE role in the test discipline. In some groups like mine (at the time Live Meeting) all of the current STE’s were given the option to take provided training to learn C#, which was Microsoft’s new managed programming language and the language being used by a lot of teams in Microsoft for authoring automated tests. In some cases STE’s were re-interviewed to see if they could complete with others who wrote code (SDETs). More than not though STEs just had their title changed to SDET and kept trying to keep their head above water by adding value through opening a ton of bugs through manual adhoc or structured testing.
I believe this nontechnical influx of people into the SDET discipline has shaped the perception that most if not all SDETs have a lower ability than pure SDEs when it comes to solving difficult problems with code; especially C++, the primary native coding language used at Microsoft.
Now lets fast forward to today. 60% of the SDETs I know today are as good or better than their peer SDEs. Some of those SDETs used to be STE’s and they have worked hard to bring their skills up to the SDE expectation. Others were hired as an SDET into the company being a great SDE somewhere else. The other 40% are just not there. They work hard and the value they add in their role is in a lot of cases worth what they get paid but they would struggle in a pure coding role. Because of this disparity between employees in the SDET discipline at Microsoft the whole discipline suffers from the overall perception. My feeling is that we as Microsoft Test Leadership have contributed to this perception by not holding the bar high enough and not correcting it sooner.
I plan to continue this topic into next week’s post but I would love to hear your comments. Being that most of my current followers are MS employees, I want to pose some questions to you.
- Do you agree or disagree and why?
- What should we do different?
- Do you believe the new Quality direction internally at Microsoft will help or hurt this perception?