Devs are Engineers, Testers are Scientists

My company have recently started calling out some of the different roles that we have to graduate starters.  (Historically we recruited people and helped them develop where they wanted – now we’re large enough to call out various starting places – “Dev”, “Test”, “Support”, etc.)  I’ve been asked by students at recruitment events, “How do I decide where I want to start?”

So I’ve been thinking about this and come up with a few ideas.  I’ll add more ideas/posts as they become clearer in my mind.  As a background here, most of this is based on the belief that people do best when they’re learning and developing, and people develop fastest and enjoy work the most when it’s aligned with their fundamental motivations.  Given that, a good way to pick a starting point (or indeed a moving point!) is to think about what you enjoy.

 

engineer
This Developer plays the guitar and solves problems.

Development roles are ultimately about creating a thing.  People who are fundamentally driven by building things and get their enjoyment from that created thing (Engineers) tend to do better in a Development role.  That doesn’t mean you’re not allowed to enjoy investigating and understanding things – in fact being able to absorb and understand things is pretty much required to be a good developer, but that’s not where the biggest buzz comes from.  If what really drives you is building stuff, try out Dev.

scientist
This tester pairs well with the Researcher to save the world.

Testing roles are ultimately about understanding a thing.  People who are fundamentally driven by understanding things and get their enjoyment from really picking apart and knowing a system (Scientists) tend to do better in a Testing role.  That doesn’t mean you’re not allowed to enjoy making things – in fact being able to build things is pretty much required to be a good tester, but that’s not where the biggest buzz comes from.  If what really drives you is understanding stuff, try out Test.

Great idea, or way-off-beam?  Please let me know what you think!

 

[1] Engineer picture from TF2 (wiki.teamfortress.net)

[2] Scientist from Pandemic (boardgamegeek.com)

 

Advertisements

5 thoughts on “Devs are Engineers, Testers are Scientists

  1. As a long-time developer who currently has one foot temporarily in the ST team, I’ll chip in my 2p:

    I think of it a bit differently from you. One of the things I really like about being a developer is the optimism: seeing the world as it could be, rather than how it is. Of course it’s an essential part of the job to think about how to put a plan into practice, but if that aspect of the job went away I don’t think I’d miss it. To me, the developer mindset starts with how things ought to be and accepts compromise where necessary.

    My guess is that good testers (of which I am not one) are much more interested in how the world actually is than how it could be or ought to be. It seems that testers need a feel for “how things could be” only when they are developing internal tools (which is really a dev task in disguise) and not when they are writing tests.

    This isn’t meant to contradict your classification, though I am a little concerned by the implications of the word “understanding”. To my mind deep understanding of things is fundamental to being a good developer, and I’m a little nervous at any implication otherwise. Perhaps the distinction is that the understanding that is most useful in dev is understanding of the principles of the idealised system (perhaps we could liken this to the Platonic forms).

    Understanding that GCC 2.96 produces code that interacts poorly with objects compiled with other versions of GCC is not the kind of thing I’d expect a developer to get excited about (though they should probably know about it, just in case they fall through a rift in the spacetime continuum and end up using a RedHat system circa 2003). Understanding the Liskov substitution principle or that “a monad is a monoid in the category of endofunctors” is. That is, I don’t expect all developers to understand those things, but I expect all developers to appreciate the value of that kind of knowledge.

    Like

    1. Thanks for the response and thoughts.

      On building and understanding, I’m absolutely not suggesting that developers or testers should only be interested in one or the other. It’s not building vs. understanding. The question I’m asking is where the underlying intrinsic motivation lies. All of the best developers that I’ve met love learning and understanding things, and that tends to be because they love building things. We love building *good* things, and so are keen to understand in order to do a good job of building.

      I’m interested in the optimism vs. realism attitude. I think there’s something there too. In my mind that also fits into the create/understand motivation (Scientists cannot afford to be optimistic about how they observe the world.) but I’m think there might be something else beyond that.

      Like

      1. I think you’re right about the intrinsic motivation. I like to understand things, but only because I want to build better things (i.e. “the world *should* have more well-designed software in it”).

        But from the perspective of a job applicant, this reduces to the problem of knowing which desires are fundamental and which secondary. I had a thought about this: instead of trying to fill in the blank in “I’m motivated to do …”, how about filling in the blank in “It really hacks me off when NOT(…)”. I feel like this gets closer to one’s fundamental drives.

        For example, I like to understand things but I’m not too bothered by the things I don’t understand. I do get angry[1], however, when something has to be done manually that could be trivially automated, or when a system doesn’t expose an extensible API.

        [1] OK, mildly annoyed. But probably angrier than I ought to be.

        Liked by 1 person

  2. I’m attracted to this, but I’m not entirely convinced.
    First, if you asked me at uni if I was a scientist or an engineer, I would certainly have self-identified as a scientist; yet I’m in Dev not Test and I love it.
    Second, there’s both less and more to testing than understanding deeply: less because to test well you don’t (IMHO) need a deep understanding of the implementation and it can sometimes be harmful (unwarranted assumptions), and more because you also need to be “evil”, to actively seek to break things.
    Take the second with a grain of salt, because I’m not in Test.

    Like

  3. Leaving aside whether testers break things (https://testingmanagement.wordpress.com/2015/12/14/testers-dont-break-things/), I don’t think that you must feel that you are a scientist or an engineer to be in dev or test.

    If you enjoy a lot investigating and understanding the world for understanding’s sake, it’s definitely worth a look as to whether you might enjoy a testing role! If the answer is that you enjoy a development role more, what is it about a development role over testing that you enjoy? If you’ve not tried it, I encourage you to give it a go (I did and found I enjoyed it even more!)

    Like

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 )

Google+ photo

You are commenting using your Google+ 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 )

Connecting to %s