"Cheating" Is Necessary

I love doing research. It's like cheating, but with permission.
Read more at: https://www.brainyquote.com/quotes/greg_rucka_744747
 "I love doing research, it's like cheating with permission"
 - Greg Rucka


I had something happen during my talk at TestBash Essentials that I wish I had been a little quicker, maybe even a little more clever about how I responded to it. I've had a couple of days to chew on it, and realized this needed a blog.

I was walking folks through how to research their domains. The talk was going really well. I was getting a lot of focus and engagement from the crowd. I was pumped to present this information as I think it's the very key to how testers can bring more value into their work, and into the meetings we have which helps that work evolve.

The Moment Of Truth

When it came time to do the first Kata/exercise of the talk, I showed examples, and said that we were going to take 30 seconds to write up a similar examples I showed based on everyone's own experiences with their current jobs. Someone from the crowd asked to see the examples again. I said sure, and backed up the slides to one of the examples, someone called out and said 'That's Cheating' - I responded immediately that 'Cheating was OK, we look up things all the time' - or something to that effect. (I honestly vaguely remember because the moment was so completely unscripted, and I've only had something like that whole exchange happen in a workshop or a meetup talk). I moved forward.

My Formulated Thoughts

This has been nagging at me though. I thought asking to see the example was perfectly fair. I was asking folks to make a mind map, to figure out how to map their domain based on seeing a slide for what was probably less than 15 seconds at best. It was fair to ask. I'm glad someone did ask. I know the "cheating" comment was a bit of a joke as well.

What I wish I had said was:

It's not cheating to look something up. It's not cheating to ask a question. It's absolutely not cheating to try to understand or ask someone to clarify what they want you to accomplish as a task.

The Bigger Issue

I'm sure folks let it go as the joke that it probably was, but the underlying implication of the exchange made me think there was a much bigger issue here that I missed the opportunity to address. I'm hoping here I can address it and let it go, let it get out of my brain. Because my brain is burning with frustration about it.

I don't like the idea that having someone ask to see a resource is considered cheating. It wasn't a test after all, and I wanted people to succeed at this task. That's what I was there to do; to help people figure out how to find information.

If asking questions and looking things up is cheating then CHEAT ALL THE TIME! We need to know how to find things. Having someone know, absolutely, some fact, or some idea, or some process 15 seconds after they see it is ridiculous. Life is not a quiz show. We shouldn't assume that we know everything and have perfect memories about anything. I know I don't, and if that means I cheat, then I cheat. I look things up. I ask questions. I absolutely ask to look at resources again. I also use search engines A LOT! Stack Overflow was invented to ask questions and look things up.

What Is An Engineer Made Of, O' Reader

This sub-context of cheating plays into a couple of things. Assumptions about assumptions or ideas of what a "good engineer" is:

1) That you have to know something stone-cold to understand it, or write it, or perform it.

2) That you can do something from memory regardless of what that task is and how complicated it might be.

3) That asking about references or looking at references are considered activities associated with cheating which in that context implies the engineer is cheating or not really an engineer.

These are just the ones I can think of off the top of my head. It plays into why folks think white board exercises are perfectly acceptable, because folks should know something completely without looking it up. I can write something on a board, but it's going to be crap and it's going to continue to be crap until I research it and/or pair with someone else to learn about that technique or idea.

The argument I can hear for this is if you claim to be a professional, you need to be able to take a white board or an oral exam and prove that you know things. I get that I don't want folks working in fields that might kill people because of a mistake and I would like them to be relatively good at their jobs, and I would like them to know things based on common understanding of the area of expertise.

For example, I would expect a doctor to know that elevated heart rates and other risk factors could lead to a heart attack, and they know this because they study a long time, learn through experience and route knowledge that these risk factors can lead to consequences of an undesired outcome. Would they be able to recognize a rare genetic disorder or infection on sight? No. That takes research, time and understanding. Medicine is full of these moments where people have seen scores of doctors, only to find out that in the end, the one doctor that figured it out had some life experience that let them understand what they were looking at and how to treat it.

Where I Am And What I Know

I know basics about coding. I know what if/else statements are; I know loops; I know a basic query for a SQL database. I know these things because I've taken classes and I've studied them. Am I absolutely good at writing them? No. I'm not. I'm not focused on writing good code all the time. I'm focused on learning how to put good products together, and only sometimes do I focus on the code to do that. I don't practice coding every day, so that's not where my skill focus is all that often. Do I keep learning, sure. I want to know what something should look like, and how it should function, that function of learning lets me do my job.

I wish we could leave the tests in college and universities and let the fact that someone can learn something be the reason we hire folks. But since it's not, I'll encourage folks to "cheat" and find the things they need to do the job correctly, whether that's resources from Stack Overflow, or talking to someone to get an idea about how to approach a problem.

Walking on water and developing software from a specification are easy if both are frozen.
Twitter-verse strikes again!


Comments

  1. Robert DayApril 9, 2019 at 3:19 AM

    "Genius is just an infinite capacity for stealing the best bits." (attributed to Oscar Wilde)

    ReplyDelete

Post a Comment

Most Read Posts

Ready, Tester One? *GO!*

"I handed my passport to the immigration officer, and he looked at it and looked at me and said, 'What are you?'" - Grace Hopper (60 Minutes Interview) The Grace Hopper quote above always makes me think about my job as a tester. Companies that develop software know they need testers, but they generally have hard time figuring out what testers are and what skills they need in the role. There have many discussions about how testers can be more technical and at some point, coding comes up in the conversation. My response on twitter contained a few things on a list I have, which I created for a client, so they could have a checklist of skills. This checklist was a guideline to determine the skill level of the tester applicant. This is by no means a complete list and I would be open to additions to the list. Feel free to add those to the comments or tweet them to me. For clarity, I took the list of skills I had and broke them into levels. I like games and I lik...
Read more

Learning From Failure: The Tricky iOS Environment

"You build on failure. You use it as a stepping stone. Close the door on the past. You don't try to forget the mistakes, but you don't dwell on it. You don't let it have any of your energy, or any of your time, or any of your space."  - Johnny Cash There are times when our work, as a team, as testers on a team can give us insight into how we can improve things for the overall success of the product. Often those things are issues or defects which can present themselves at the most inconvenient times, in the most inconsistent ways. When we can learn from them and improve things for everyone on the team, the team benefits. When the team owns the defects and the testing strategy, not only the testers, then customers benefit as well. I was working remotely verifying a release and only had simulators and emulators to work with as I was testing mobile builds. Often folks mistrust builds which only use emulated software and not real devices for fairly good reasons...
Read more

Postman In The Pipeline: Newman Delivers

Image
  It's not me, it's the songs.  I'm just the postman,  I deliver the songs....  - Bob Dylan Recently, I've had the chance to work on a project with some other awesome folks which has involved creating a BFF - A back end for front end service. This allows the app to access several API and aggregate calls into something the app can use, or lets the app send information to the BFF for several APIs to receive. Part of the code coverage for the BFF was creating some simple tests with Postman around the business logic and interactions. Learning About Postman I did lots of reading. Lots of reading how others has done things (Danny Danton - big props for being a super help!). Eventually, I came down to a small set of tests which could give us some accuracy about our BFF pipeline and the APIs we were accessing with it. Postman has a couple of options for this, global variables, environmental variables, and plain variables. One of the first problems I came acros...
Read more