The Myth of the Myth of 10x

I first heard of “10x” software development through the writings of Steve McConnell. Code Complete remains one of my favorite books about writing good software (The Pragmatic Programmer, Writing Solid Code, and The Clean Coder are also on that list). Steve McConnell’s rarely updated blog (titled 10x Software Development, contains the following tagline:

Numerous studies have found 10:1 differences in productivity and quality among individuals and even among teams. This blog contains Steve McConnell’s thoughts about how to move toward the "10" side of that 10:1 ratio.

This article, and this one, are probably the best views from the McConnell side on 10x. They cover a lot of the studies and anecdotal information about the 10x concept. Although the original study cited a 10-fold difference in productivity and quality between different programmers with the same levels of experience, I use the 10x label to describe those software folks who “merely” differentiate themselves in terms of output and quality significantly more than their peers. While I will use the term “10x” throughout this post for conformance with the topic, it’s not an exact multiplication. For me, the term means, significantly higher output and quality.

The Myth?

Recently, there was a bit of buzz about this article about the Myth of the 10x Engineer. The meat of the article includes some valid criticism of the studies citing 10x Engineers, and as someone who is generally a skeptic, I acknowledge that the studies have holes. I think there are a lot of misconceptions about what a 10x engineer actually is, so the controversy doesn’t surprise me.

The article begins with the following statement:

I was a 10x engineer for 7 months and then I was a 0x engineer for a year and a half. You burn the candle at both ends. You end up with alcoholism and depression. You’re talking about a very small subset of people. And they might end up in divorce and financial ruin. When people think you’re a 10x engineer, they think you have skills that you don’t. You invariably let people down.

The full article (which, by the way, is very nicely written and worth the read) makes a very good case against the validity of the studies about 10x, and includes several statements from the author’s twitter followers supporting the quote above.

Not a Myth?

But I interpret 10x much differently, and think a lot of commenters miss the point. This, in my opinion, is at least partially due to the “10x” label.

But more importantly, 10x isn’t about working 10x as hard. It’s not even about working twice as hard. It’s not about effort. Being 10x (or significantly more impactful, or whatever you want to call it) is about making smart choices and taking care in your work. I’m sure if I were to put fifty similarly proficient developers in a room and ask them each to implement a known set of algorithms or implement well defined functionality into an existing app, or any other task where the problem and solution are largely understood, that there will be some variance in the time it takes each of them to finish the tasks, but the best in the group would maybe be twice as fast as the average – if that.

Where 10x software engineers excel is in adaptive challenges – where the problem may be understood, but the solution is an unknown (and where the problem may change as the solution emerges). 10x engineers recognize patterns, they know when they’ve hit a dead end, and they can zoom from the 10,000 foot big picture down to minutiae and back again in an instant. They aren’t significantly more productive than their peers because they work eighteen hours a day or even because they type at a whirlwind pace. They are more productive because they solve problems 10x faster than their average peer. They are more productive because there’s less waste in their work – they are careful enough to do things right the first time, but have enough breadth of knowledge that they find the correct choice sooner. You can’t make yourself into a 10x engineer by working harder or longer – you make yourself a 10x engineer by studying and practicing your craft, by investing in learning, and by challenging yourself to continuously make better decisions about how you work.

All that said, not everyone needs to be – or can be a 10x – and that’s ok. But I, for one, want (and love) to work with 10x developers so I can learn from them, learn how they learn, and perhaps discover a few tips to improve my own output and value.

Plus ça change..

In early January, I’ll hit my 19 year anniversary of working at Microsoft (I’ve worked for Microsoft 18.5 years, and as a vendor at Microsoft for the first 5 months or so). There’s been a lot of change over the years, but perhaps never as much as is going on right now.

We’re getting a new CEO, the review system has been paved, there’s a major re-org underway, and Xbox One ships in 6 days. I can honestly say that the two years I’ve spent on Xbox has been the most challenging, fun, and eye-opening experience of my career. I’ve learned a lot – I’ve had an impact – I’ve worked with incredibly smart people – I’ve made friends. I can’t rave enough about how great it’s been to be part of this team.

But it won’t be the same anymore. Sure, a lot of the people on the team will still be here, but you only launch a console once every 5-7 years. The Xbox software will continue to improve and games will get even better, but you only get to ship the console once. Of course, there’s so much more I want to do here, that there’s a reasonable chance I’ll continue to work on Xbox, but I can’t say for sure yet. I have other opportunities to weigh – and I’m in much need of a vacation and some rest (and some quality time with my family), and this is no time to make big decisions. I’ve managed to change my mind at least once a day for the past few weeks when thinking about what’s next…and just when I think I have it figured out, a new opportunity shows up.

I’m sure the rest and family time will lead me in the right direction.

In the meantime, I have a zillion things I’ve been meaning to write about, and no marathon debugging sessions to get in the way, so I expect to barf some random ideas onto the internet in the coming days and weeks. I may spend some more time on twitter (heck, I even posted to Facebook last night!).

I can’t wait to see what happens next.

Mobile Application Quality

I forgot to mention this before, but on Thursday, Jason Arbon from applause and uTest will be giving a practically free ($99) course on mobile application quality. Jason is a great teacher, and really knows his stuff in this area.

More information at the SASQAG web site (scroll down a bit on the home page)

Home Again

I implied at the end of my last post that I’d follow up after my keynote (I failed – sorry). This was a weird conference for me. While I attended nearly all of the keynotes, I only made it to a few other sessions, and didn’t have as much time to hang out with folks as I would have liked. For better or for worse, I spent the majority of the week in my hotel room working (internet access was much better than in the conference area). Even in hindsight, taking care of the day job was the right thing to do.

But I had a great time at STAR. I’m mostly happy with my keynote and think I delivered everything the way I wanted (incidentally, the keynote is online here). I thought Friday’s panel discussion with Jon Bach and Dawn Haynes was a lot of fun (although I probably couldn’t have been more annoyed with the content and style of Friday’s keynote speaker). Over all, it was another great STAR conference, and I can’t wait to attend another one.

And if you missed me, now that Xbox One is almost out the door, I’m planning to be back at STAR for STAR East this spring in Orlando. I hope to see some of you there.

One down, two to go…

it’s 6:30-ish pm, and I’m killing time waiting for my sound check for tomorrow’s keynote, and thought I’d do a quick brain dump of today’s tutorial session.

Today’s session was “Alan Page: On Testing” – which is a pretty wide open topic. For the slide handouts, I slapped together slides from a bunch of things I could talk about, but my plan all along was different. In a perhaps risky move, I decided that I’d take the first 10 minutes of the session to collect as many questions from the audience as I could, then I loosely grouped the questions and put together a few impromptu talks to cover the answers. I took questions as I went, plus a few ad-hoc questions at the end, and filled the 3.5 hour session.

The problem with this sort of thing is that it exhausts me. I’m wiped out, and I’ve lost half of my voice, but I should be good to go for my keynote in the morning.

The other drawback of this sort of session (and the few pieces of feedback I glanced at reflect this) is that this sort of session is polarizing, Attendees either got a ton of value, or little value – comments like “Love the unstructured format – tons of great information” were contrasted with, “Didn’t like the unstructured format – too much information”. I’m not too concerned, since the conference circuit isn’t really my thing, but I feel a little bad I didn’t set up the people in the “don’t like unstructured” group a little better with expectations.

More tomorrow after my (structured-ish) keynote.

Silos, Walls, Teams and TV

Between Netflix, Amazon Prime, and a busy schedule, I’ve gone without cable television for the last five or so years…up until a month or so ago when I bit the bullet (for a variety of reasons), and added a television package to our existing internet service. It’s working great so far, but the story about how we got everything working is worth sharing and pondering.

The Picture

On a Wednesday evening, I called Comcast to add a television package. I knew what I wanted, so ordering was easy. The sales person told me I need to schedule an installation, so we set something up for Sunday. There was no record of our house every having cable television before, but three years ago, I had service for a short time so I could watch the 2010 world cup. So – I had a hunch that I could take care of it myself, so I made arrangements to pick up a box and try it myself.

Thursday morning I grabbed a set top box from the retail store – where the sales person confirmed that I didn’t need an installation – just a “switch flipped” on the box at the end of our driveway.

On Friday night after work, I plugged in the cable box and watched to see what would happen. I half-way expected it not to work, and I was half-right. I was getting audio for all of the channels, but no picture. I was pretty sure things on my end were correct, so I gave support a call.

I’m pretty polar on my customer service experiences. When I have a good experience, I’m elated. When I have a poor experience, I’m annoyed at best. I called support, answered some questions, pushed some buttons, and eventually found a real person to talk to. I clearly explained my situation (new box, previous cable in the house, audio is loud and clear, no picture) to the support person. As I expected, they used a script, asking me if my box was plugged in and if the cables were connected (despite that I had already explained that I had audio and was connected via HDMI). After only a minute or two, I was able to get transferred to someone else. They tried rebooting my cable box a few times before putting me on hold to “talk to a colleague”. Soon after, I was disconnected, and when I called back, the support line was closed for the evening.

On Saturday morning, I called back, and went through the same process. This time, someone eventually figured out that “ I had the wrong account codes”. But – they couldn’t change them. They had to transfer me to someone in sales who could apply the correct account codes. The sales guys did their thing. They tried to sell me a bunch of stuff I didn’t want, but eventually “applied my codes” and sent me back to support – because I still had no picture.

I spent over 30 minutes with the next support person. I still had no picture, and she had me double check all of my connections, and insisted on rebooting my cable box a few times (remember folks, reboot-is-always-a-valid-solution), but no dice. Finally, I chimed in and said, “Hey – to remind you, I ended up here because my account codes or something like that weren’t applied properly – does that help?”. After an awkward silence plus about 3 seconds, a picture appeared on my television. Problem solved! She closed by asking (certainly a Comcast standard) if there was anything else she could do for me. As a matter of fact, there was. I asked her to verify the services I was signed up for and the price I was paying. Sure enough, the guy in sales screwed it up, and I was getting services I didn’t want for more than I planned on paying. So…she transferred me back to accounts.

I explained the situation to the person in accounts, but was told that the type of account I signed up for was an account outside of her department. Her department, apparently only handled the “standard” packages, and I needed to talk to someone in “specials” or something like that. She transferred me again, and within a minute or two, my service remained up and running, and I was getting the services I wanted for the price I planned to pay.

To be clear, the television service (on top of my internet service) has been flawless. But the path to get there was nothing but.

Silos

I could go back and count everyone I had to talk to, but in reality, the problem with my experience above is that I talked to way too many people. In fact, I’d say that I talked to too many people the moment I talked to the second person. In nearly all of the great support experiences I have experienced (and have read about), I’ve been taken care of my one person (sometime a few) who were empowered to help. At Comcast, employees apparently work in silos. They have a single activity they are trained in, and allowed to perform. I’m sure that makes sense on paper (to someone), but in practice, it’s a poor experience.

Making Software

Believe it or not, this post isn’t about my support complaints. It’s about making software – because I fear that many organizations are making software the same way that my cable company handles support. When you have a team of programmers who only program, testers who only test, analysts that only analyze, and managers who only manage, you have an organization that works slowly, and likely produces crap.

Not everyone, of course, has to be able to do everything, but everyone should feel empowered to do whatever is needed (within their capabilities). You should be able to write a spec, fix a bug, perform a test, or lead the team regardless of what your title says.

Generalizing Specialists

There’s a reasonable number of talks and articles amongst the agile community on Generalizing Specialists

By staffing a team with people who have an area of expertise, but can do anything, you can maximize the value of each delivery cycle.  (reference)

It’s worth noting that the article quoted above refers to Specializing Generalists – and although it appears that many folks use the terms interchangeably, I think there’s an important distinction.

A generalizing specialist is more than just a generalist. A generalist is a jack-of-all-trades but a master of none, whereas a generalizing specialist is a jack-of-all-trades and master of a few. (reference)

Again (because for some of you, I’ll have to say it again), I’m not saying that everyone has to do everything. Your “generalist” skills don’t need to span every software activity. But I am saying that you will be more valuable to your team (and your team will work better and make better software) if everyone in your organization can do more than specialize in just one thing. This is true regardless of the methodologies and approaches used on your team. Silos and walls create waste (wasted time, wasted efforts, wasted energy, etc.).

I really don’t understand why some software teams insist on having specific roles for specific team members and offer little to no encouragement to reach beyond their silos. Great results come from great teams – and great teams (whether it’s a sports team, a sales team, or a software team) work together and compliment each others skills.

See also: T-Shaped Personas (and E-Shaped)

The Professional Attribute Game

I chuckle a bit every time I see a tweet or a blog post talking about how some attribute is uniquely important for anyone wanting to be successful in a software role – when in reality, there are many professions where these attributes help lead to success. I’m not saying the attributes aren’t important, but I am saying that it’s wrong to assume that proficiency in one of these attributes immediately qualifies one to be successful in software.

So – in a 5-minute spout of Alan-being-annoying-on-a-Monday, I give you the “professional attribute game”. Pick one line each from column A, B, and C, and you will have your own profound statement about what it takes to be successful in the 21st century.

image

 

 

 

 

 

 

 

Back to less snarkiness soon – but feel free to add your own attributes, actions, and professions in the meantime.

Perspective

While cleaning out some boxes my Mom had packed away, I came across a yearbook from my freshmen year of high school. I hated my freshmen photo. I had skull surgery a few months earlier (long story for another post), and needed to have my head shaved. As I remember it, by the time school started, my hair was nothing but stubble.

I cracked the yearbook open to show my wife the ugliness of my head, and was a bit surprised to see that my hair actually wasn’t much shorter than my hair is now – but a glance around the rest of the page showed that my classmates from 1979 all had hair covering at least half of their head. My hair was short compared to my peers, but in hindsight, not that short at all.

It’s that time of year at Microsoft when people get uneasy (or freaked out, or hysterical, or angry, etc.). It’s review time. What’s worse, is that it’s review time at a company that has a forced curve of performance rankings (note: there is a bit of leeway this year, but it’s still a curve). Now, you’d think that in a company full of tech geeks, people could figure out that no matter how much leeway there is, that you can’t get 75% of the company into the top-20% bucket – or that in a company crammed full of smart people, that half of them are below average.

The Hairball

To be clear, I’m not defending the review system; it is what it is. To me, the review system is the tax I pay to get to do what I do. I have a choice to work where I want to work. If I don’t like the system, I can go pay the tax of another company’s system. Everyone has that same choice. Live in the system, change the system, or leave the system. Marlena Compton once recommended a book imageto me, which I, in turn, have recommended at least a dozen times. Orbiting The Giant Hairball is the story of an artist at Hallmark, and how he learned to deal with corporate life, and his sanity, at the same time. If you love your work, but struggle with the bureaucracy and politics – or even if you just want to figure out how work fits in with life, this is a great book. Also – as Marlena told me, don’t buy the e-book. For full effect, this book needs to be read in dead-tree form.

A “Bad” review

Let me tell you a story about my first review at Microsoft. I was hired full-time in June of 1995 as a level 9 (equivalent to a level 57 – our minimum hiring level today for software folks is 59). Reviews back then were in August, so I didn’t have my first annual review until August, 1996. In those 14 months, I helped ship all of the Asian versions of Windows 95, tested the crap out of IE2 and IE3 (including writing ISAPI server extensions, and what was probably among the first web automation in the industry), got rave reviews from external offices for a web translation tool I wrote, and maintained servers for our entire test team. I awaited my accolades… My reward? A $1000 dollar bonus and an $800 dollar raise.

The world was unfair, and I was a victim.

I remember talking to a friend of mine who was an old-timer at the company (she started fours years ahead of me in 1991). She was sympathetic, but wise. She told me that she knew I would do well in the long run, and not to worry about it. This wise women of 26 told me that careers will have ups and downs, but in the end, everything evens out.

Perspective

I didn’t believe her, but she was right. My career has had its ups and downs, but overall, it has gone pretty well, and as I’ve grown, I’ve learned how to take control of what kind of work I want to do, and what kind of worker I want to be.

What I needed, was perspective. And I’ve echoed my friend’s advice to dozens of others over the years (and have already done so many times in recent weeks).

The next time you’re upset with how you’re being treated at work, ask yourself if it’s a glitch in the road, or a trend you need to avoid. If it’s a trend, don’t whine. Fix it, or find a new job. If it’s a glitch, sulk for a moment, if needed, and then move on. Your career isn’t defined in a moment – or even a year. Have some perspective.

Blog + Leanpub + Scrivener = “A”

Depending on how you look at it, I wrote a book.

Except that I already wrote it (it’s taken almost entirely from previous blog posts. And to be fair, it’s not really long enough to be a book (the good news is that you can easily read it in an hour or two, and that it’s available in three different electronic formats).

When I wrote the Last Word on the A Word post some time back, I felt an urge to revisit all of my various posts on GUI automation…and after pondering those for a while, I thought I’d consider compiling those posts into a one-stop-shop of what I think about test automation and test design.

And I ended up with The “A” Word. And I’m happy with how it came out.

When I began compiling the book, I was planning to give it away for free. But – after working with the leanpub tools for the last few weeks (and being impressed time after time), I felt bad not giving them any money for their tools. As a result, I decided to make the minimum price free, but allow people to pay if they wanted (as I’m already overpaid for a job I love, I’m donating all of the profits to the American Cancer Society).

I also found that Scrivener was a perfect ally in this little project. I bought a copy a while back, but haven’t done much “serious” writing recently. After struggling a bit to figure out what should go where, I decided to give Scrivener a full test run, and it worked perfectly. My colleagues in Office won’t like me saying this, but my next book will also be written entirely in Scrivener.

So, if you haven’t checked out The “A” Word already, what’s stopping you? Check it out and let me know what you think.

My Toolbox – 2013

On my bike ride to work today, I was thinking about my current toolbox – the tools I use on a daily basis to get my job done (or to help me get my job done). Or, to be perfectly honest, I’ve been thinking about my toolbox for a while – I just thought about writing about it on my commute today.

This isn’t going to be a typical list – that’s for two reasons. One is that I’m not typical. The second is that I use some internal tools that may be helpful…but since nobody outside of the Borg can get to them, aren’t that interesting to share. But – what’s listed below covers most of what I use on a day to day basis.

Stuff I use for Testing

This list could go on for a while, but I’ll stick to tools that I use every day, are free to anyone, and find great bugs.

  • Application Verifier – AppVerif is a dynamic analysis tool (a lot like the old boundschecker tool). It’s easy to set up, the bugs are easy to debug, and its false positive rate is near zero. If you test a windows app, you should use it.
  • Driver Verifier – DV is (IMO) the biggest blue-screen remover I know of, or can imagine. It finds driver faults way, way before they ever manifest in a system crash. If you test drivers, you have to use this tool (literally, as I think the driver certs require that you run it).
  • Static Analysis Tools – we use an internal version of the Code Analysis tools from Visual Studio. I’ve never actually used the VS versions of the tools, but from what I can tell, what I use daily to help guide me to product issues is almost exactly the same as what we ship to developers.
  • Kernel Debuggers – When you work on an operating system, you need a kernel debugger, and the debuggers from MS are great (I could just be used to them, having used them for years). Windbg (I pronounce it wind-bag) looks a bit like a throwback (IOW, it’s not a pretty debugger), but it’s a powerful debugger.

Command Line Goo

I spend a lot of time at the command line (our build system uses a lot of command line tools, and I’m comfortable there). Many years ago, I used NDos/4Dos, but I still prefer the standard cmd.exe shell to the currently available Windows shell alternatives.

But the command line is much more than a terminal – it’s the way you use it that makes it useful.

  • Macros – I don’t know about you, but I always forget complex command lines – especially for commands I don’t use often, , so I use a lot of doskey macros. I have a network accessible power supply hooked up to my consoles, so I have a macro that reminds me of the commands to reboot, and connects to the ip address (that I always forget) -doskey netpower=echo Run rb num to reboot console num$Tsleep 2$Ttelnet %powerip%
    I have 40 or so of these, and scanning through the list, I use nearly every single one on a daily basis.
  • Grep / Findstr – I’m always looking for stuff, and findstr is my partner. Need to find every instance of a file containing the text ‘f’’ that does not have the text ‘bar’ on the same line: findstr /sip foo * |findstr /vi bar.

Other Tools

Tools I use every day include:

  • Notepad++ – This is my primary editor. Since I build from the command line, I don’t need anything except an editor that launches quickly and makes it easy for me to read and write code quickly. Notepad++ also has macro support which is great for those times when you need to make the same change across hundreds of lines.
  • Notepad2 – This is my backup editor. Sometimes, I want a file to load in a single window (notepad++ loads multiple documents). For example, I have a bunch of output files I need to look at every few weeks, and I never got around to writing something to get the output I need from the file. So, when I’m ready to look at the files, I run for %f in (*.txt) do start /w notepad2.exe –g –1 %f
    That launches notepad2 for each text file (waiting until I close it before launching the next one), and automatically puts the cursor on the last line of the file.
  • Visual Studio – I do a little bit of coding in VS, but I mainly use it for work item tracking in TFS
  • Leankit – I keep my life in order (including my work life) using personal kanban, and leankit is my tool of choice. It keeps me sane.
  • Others – I use Excel, a few different mind-mapping tools, scripting languages, and terminal server frequently as well, but the use cases are probably less interesting.  Other Office apps (Outlook, OneNote, Word, etc.) also get extensive usage, although less directly related to software development or testing.

[Preemptive comment: yes – I know that the brain is your most important tool as a tester (or programmer) – but this is true for all knowledge work. You need to use your brain to know when to use tools like these, and recognize when they will help you. Consider brain power noted.]