Learn to Code, It Can Only Help

This post is in response to Alan Page’s post Tear Down The Wall and Phil Kirkham’s response The Wall Is Still There.

EDIT: Some points in the comments made me want to clarify some of what I’ve said here. A follow-up post is here.

I’m a tester, and I’m learning to code. Why? Do I intend to apply for a developer position?

I get that question all the time. It’s a tough one to answer. Since I don’t intend to apply for a developer job, my profession does not expect or demand that I go outside of work, buy a bunch of books, read a bunch of websites, and code long into the night learning how developers do what they do. Why would I do that?

Two Videos That Inspired Me

I saw two videos around the tail end of 2011 that opened my eyes to who I was in my industry. These videos made me want to change my job, to change how I work:

The first one was meant to be provocative. James Whittaker’s STARWest keynote All That Testing Is Getting In The Way of Quality was quite an eye-opener, as it was meant to be. If you’re a tester and you haven’t seen it, now is the time, watch it today. I admit, I remember walking away from watching it and telling somebody that the short version was “People at Google forget that a world exists outside Google,” but still, two ideas stuck:

  1. At Google, all developers can test, and all testers can code.
  2. A bug report is a waste of time. If you understand a problem why wouldn’t you just fix it?

The 2nd video was not meant to be provocative, and was not even a communication meant for testers. I recommend Erik Wolpaw’s Portal 2 discussion at NYU to anyone in the software industry, just for entertainment value and to see how Wolpaw’s passion and vision translated into an actual fun product. But from the testing perspective, Wolpaw had a comment I found really interesting: Somebody asked him if he had one piece of advice for game designers, and it was “learn to code, it can only help.”

Learn to code. It can only help. Really?

Two Things That Aren’t True

“It’s better if testers don’t have knowledge of the code.”

This is just bullshit. It’s the most delicious kind of bullshit, though! It’s self-serving to those that say it *and* to those that hear it. I’ve heard it from the mouths of lead devs, lead QAs, build engineers, executives, everyone. The value QA adds is that they don’t know how the code works.

I wonder whether, deep down, anyone really believes that.

Devs like this idea because they hate context-switching; testing isn’t coding and they’d rather just keep coding. They’d rather have somebody else do it, and they can rationalize it by saying that, hey, if we’re paying this guy to do testing he must be some kind of testing expert.

QAers like that idea because it’s like they magically got a skill when they got the job. Here you are, working in a technical discipline with little or no prior training, and your lack of a technical background is something that your organization… values…?

Nope. No. I refuse to work in a discipline where the thought is that I would become less valuable to my organization if I learned more about what my coworkers are doing. Ain’t nobody got time for that. And I don’t believe that any of my coworkers would consciously agree with that sentiment, either… not realizing that the sentiment is implicit in the statement “It’s better if testers don’t have knowledge of the code.”

“Devs just don’t know how to test well.”

I can forgive people for thinking this. As above: if you’ve got a room full of software engineers and two guys whose job it is to test their software, it’s natural to assume that those QA guys know something the devs don’t. Especially because those QA guys find bugs. The devs missed the bugs. QA found the bugs. Ergo, QA is better than Dev at finding bugs.

It’s not the case. Some people are naturally good at testing and some people are not, and everyone can get better through learning and practicing. This is equally true for testers and developers.

I say this without judgement, as I am a deeply lazy person myself: people are fundamentally lazy and tend not to do things they don’t enjoy. If devs are satisfied that someone else is going to find their bugs, they will not work hard to find them themselves. But here’s a funny thing: an average developer that devotes all of his or her attention to testing for an afternoon is more likely to find an important bug than an average tester on the same team.

That’s a bold statement, but I know it to be true. The reason I know it is that I’ve coordinated a lot of coordinated testing activities (“bug bashes”) company-wide over the past several years. These are usually laid out as competitions where people get points for finding good bugs. Devs KILL testers at these things, 100% of the time. So does UX. So does Docs. WTF?

How is this possible? Isn’t there some “testing body of knowledge” that QA knows but devs don’t? No, not really. At least, I haven’t witnessed such an animal. Sure, there are some cool techniques that we employ on my team (SBTM, soap opera testing, mindmapping etc) which QA brought into the organization, but I can explain all of them to you in an hour and then you can use them or not at your own discretion, be you a tester or a dev. There’s nothing magical about them, they’re just a couple of sometimes-effective things that people should try.

Ok, Debbie Downer, thanks a lot. *kicks dirt*

Ok, testers, this seems bad. Pretty dire. But it’s not a problem, it’s an opportunity. The software-making profession has a need, and you are the one to fill it! Because, with all that I’ve written, here’s something else: Making great software is extremely difficult. It is next-to-impossible to get it right. There isn’t time for people to worry about artificial, useless distinctions between roles like “developer,” “designer,” “tester,” etc. Everyone should be firing all of their neurons at this extremely difficult problem, and contributing everything they can in the smartest way they can think of.

Let’s say your team isn’t building an app, it’s building a house. You, the tester, are in charge of making sure that the house is right when it’s done. Do you wait until the house is mostly done, then walk in and start telling people to fix things, that they missed a spot? No. Don’t be an inspector. Inspectors are antagonists, they’re not on the team. Whose job is it to make sure that the inspection passes the first time? It’s one of the builders. One of the builders understands what it takes to make the house pass inspection, and is there every minute helping people do what they need to do to get it right. That’s you. You are that guy. Be that guy.

On a software team, that guy can code. The people around you want to make great software and they need your help to do it. You can contribute a lot more by pitching in than you can by telling them that they missed a spot. The more you understand about how software is built, the more you can contribute. Learn to code, it can only help.

Advertisements

9 thoughts on “Learn to Code, It Can Only Help

  1. I love this article! I am someone you are talking to. I have told myself for years that I don’t need to know how to code to be Tester…and I finally admitted to myself that I was wrong. If I want to continue to be a better Tester, a more informed Tester, a more technical Tester, and a more valuable Tester, I was going to need to challenge myself and take the plunge. So, a little over a week ago I started on a journey to learn Python. Coding does NOT come easy to me (which is why all the other times I’ve tried to learn a language ended with the book flying across the room and me giving up). But it feels different this time. Or I feel different this time. I am determined to not give up this time. Thank you for this timely and encouraging article.

    Teri
    @booksrg8

  2. Well, I guess testers might as well learn to code seeing as you can teach people how to test in an hour so testers might as well do something else with their time…

    As an ex-dev and someone who is still actively learning code I was more interested in your assertion that testers are being killed by Joe Schmoe and Derek Dev when you do bug bashes. Seems pretty pointless to be a tester – techniques can be taught in an hour and when non-specialists testers have a go they find more bugs. Really?
    And on that depressing note I’ll sign off and find myself a new career

    • Hi Phil!
      Yeah, I had more in there that kind of ended up on the editing room floor. I guess I want to emphasize that we’re talking about the *average* dev and the *average* tester.

      I’ve spent a lot of time wondering why it is that QA always gets crushed in these events, and I think it has a lot to do with outmoded models of the way testing is supposed to work: testers feel like they shouldn’t submit a bug unless they have an expected result to compare it to, so they spend their time wondering how the product is supposed to work and not really “testing” it.

      The reason that devs always win these things is that they understand how to cyber up and find lots of bugs quickly using automation. For example: one time a guy won by pointing an automatic link checker at a web site, and found a ton of dead links. Another time, a dev used Firebug to disable client-side validation of forms and submitted orders that should have been impossible. It’s a stretch to even call those “developer” techniques; an expert QA should have the technical wherewithal to try those things, but typical “black box testers” never try them. That’s what I mean when I say that learning to code can help you. I guess I didn’t do a great job of conveying that.

  3. Where I’d make a distinction about the separation between dev and test is that one role of test is to explore the edges & assumptions built into the code. Developers often will write code that fixes one issue, but doesn’t consider another – and when they’re looking at their code for bugs they are still in the same mindset & using the same assumptions as when they wrote the code. A tester by being less focused on the specifics of the code path might be more likely to spot an error of omission or another use case where the code is suboptimal.

    • Hi Heidi!
      Thanks for your comment! A question for you: is there something that’s specific to the testing profession that enables testers to do that where others can’t? Is that a skill that people acquire somehow, or is it something that some people do naturally?

      Or – and this is an intriguing possibility – is it because testers are typically more knowledgeable about the system in its entirety? To me, that sounds like an important contribution that might be hard for others on the project: focusing on the forest in addition to the trees…?

  4. Pingback: How Coding Can Help You | Tester Vs Computer

  5. Pingback: The SpecFlow Chronicles – Volume 2: In Defense of ATDD | Tester Vs Computer

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s