Owning Your Craft

Owning Your Craft Mike Smith Twitter: @mikesmith_sh Website: mikesmith.sh

So… This was going to be my first time on stage until I did a 99 second talk on Wednesday. But I wanted to point out that I didn’t get here on my own… I’d like to recognise a few of people who have helped make this dream a reality for me. In 2017 I attended a workshop by Marianna Duijst (D-OUST) and Rick Tracy about Roadmapping your Testing Future. It’s because of that talk that I went home from Testbash Manchester that year and proclaimed to my wife ‘I’m going to be a public speaker’ And as any amazing, supportive partner does she hugged me and told me that I was going to do fantastic. In 2018 I changed roles in my job. I met my new manager Kim; a man with 20+ years experience in both training and public speaking and more notably; Code on the surface of Mars. I forced my way under his wing and he started to teach me the ropes. Sadly Kim passed away quite suddenly in late 2018 Along with the tireless efforts of the Ministry of Testing and it’s volunteers I’d like to personally dedicate my first talk to Marianna and Rick for sparking this fire within me, my wonderful wife Cheryl for helping it grow and never letting it go out and for Kim who showed me what I could do with it. Thank you.

Who am I? •R&D Architect for Ideagen Plc’s Research and Innovation Division •Became a software tester in 2011 •Team Leader, Principal Tester Twitter: @mikesmith_sh Website: mikesmith.sh By now you’re probably all wondering who I actually am. My name is Mike Smith, I work in Ideagen’s Research and Development Department. I became a software tester in 2011 and quickly found that it was the job that renewed my passion for technology and also the industry and community that has given me so much over the years; knowledge, experience and friends along the way. Through my career I’ve been a Junior Tester, a Test Team Lead and a Principal Test Engineer

Before I advise you on how to Own your Craft or what that even means in my context I need to give you some backstory. I’d like to take you back in time to the golden age of 2016. Don’t actually Google 2016, according to the internet it was a pretty horrendous year for everyone involved. But it was an interesting year for me. I was Ideagens Test Team Lead in Nottingham. I had a team of 7 amazing testers alongside me. I was also the primary tester on a couple of major projects and occasionally I would hear things like ‘you’re our more experienced tester’ One day, my then manager asked me to be part of a new project…

The microservice project I was introduced to my soon-to-be teammates who explained that this was a simple Microservice project utilising containerised linux instances for service tier architecture coupled with non relational databases which would mainly be driven by back end APIs, I would just be responsible for testing it. There was only one problem…

I had literally no idea what 90% of that meant. I sat there listening to the team talk about what they had found so far and best practices moving forwards and a niggling little voice started up in my head. “I’m the most experienced tester, I have to step up, set a good example for my team” And here I was; for the first time in my career, my name had come up when the company needed an experienced tester. So I did what any uncertain person would do in that situation - and then go on to immediately regret it.

I said ‘Sure, no problem, when do we start?’

THINGS I DIDN’T KNOW BUT THOUGHT I SHOULD AND PEOPLE NOW ASSUMED I DID SWAGGER MESSAGE QUEUES YAML So here I was with all this brand new stuff on my plate. I needed to try and thumb my way through things like… - the Linux Command Line; I’d never touched Linux in my life. - Non relational databases; I thought SQL was pretty much the only database out there - Docker and the very concept of containerisation; whatever that all meant - even API’s in general; I had never truly tested one in anger before, only as an API testing tourist And this was just the headline items. People kept talking about things called Message Queues and Swagger and Yaml and lots of other made up words I’d never heard of

I started to get really stressed out about it. Within days of working on the project I was lost. I had this indecipherable project in front of me and I was still a tester on other projects and also a Team Lead.

Suddenly I felt like my workload had gone from this…

To this, and I had no idea how to deal with it. But never fear. I got paid a visit by an old friend who would put things in perspective for me…

Enter Imposter syndrome. Thanks Brain I wouldn’t really understand what this feeling was until the following year when I saw the excellent talk by Claire Reckless covering imposter syndrome within Testing. But it was there. Neil Gaiman famously wrote that he always feels like he was expecting a visit from a man with a clipboard (he didn’t know why he had a clipboard) from the Fraud Police to tell me that it was all over, they had finally caught him and he’d now need to get a proper job now instead of writing books. I suddenly felt the same about testing

I’d need to move back to my hometown and get my old job making Blackpool Rock. It would turn out that I’d been blagging my way through my day job for the last few years and they actually meant to hire the Other Mike Smith after the interview - it’s a common enough name; it could happen.

I was in a bad place. I felt like I was failing, I couldn’t get my head around the concepts that my teammates seemed to understand so effortlessly, I couldn’t find the answers I sought and I never seemed to have the time to discover them whist work continued At my lowest point I did something that I would have never considered before…

I came clean. I told my project team that I knew nothing about these concepts or the technology. And I admitted that I was struggling with the workload. I waited for the man with the clipboard to arrive.

But he never showed up. My team told me that they only had a few weeks head start on me and in fact; a lot of this was new to them too. We sat for a long time and discussed how best to move forwards.

They even gave me a choice. Option A: I could wait, they would finish developing the api’s and the backend. Then they would start work on the front end and the gui. Then I could start testing how I would normally test. Or Option B: I could start from the ground up, learn as I went and test from the first line of code. They explained that they wouldn’t be able to hold my hand through it but they also wouldn’t abandon me. If I were truly stuck; they would be there.

It was here that I had a bit of a lightbulb moment. Here I was, given the choice to either do ‘just enough’ work OR to put myself through more hardship and stress than I needed to so I could produce better work. The problem was I couldn’t see myself doing anything other than trying my absolute best at this.

Which was equally weird, right? We all spend most of our formative years being told that we should get a job and when we do that we end up surrounded by miserable people who hate their jobs, we learn to hate our job through osmosis. What are we supposed to really think?

Here I was - wanting to do my best. Not for my manager, my company or even my supportive team. It wasn’t because I felt I had to because I was ‘the most experienced tester’ or anything like that. I was doing this because I wanted to. Testing was no longer JUST my Day Job; it was my Craft. It was something that now fed my soul and made me happy. I wanted to be better at it for my own sake. It gave me Joy and that was something I would chase no matter what.

So I chose Option B; I dove into the work. I ended up speaking to my manager and even his manager about my workload. They agreed that this project needed priority so I could shift my workload around a bit to give me more time. I asked if the other team members could recommend any learning material that I could draw from. They pointed me in some good directions. I did whatever I could to help my current situation - I tried to be kind to myself and, for one of the first times in my life, started cutting myself some slack. I didn’t need to already know all of this.

Little changes can make a big difference in times like this. It took more confidence than I thought I had at that time to answer some of the questions I was being asked ’Why do you want to move desks to sit with the team?’ ‘Why do you need dedicated time for studying at work?’ ‘Why are you using the stand up desk today?’ ‘Why do you need more RAM in your PC?’ ‘Why do you always wear headphones?’ (probably because of all the questions) But the answer I always ended up giving them was; because it helps.

You see, as much passion and drive as you can throw into your work it’s a two way street. The place of work needs to recognise this and, where possible, help you, even in little ways. All of the little changes that I would ask for made it possible for me to be the best Tester I could be on that project. Not perfect, just the best version of myself I could be at that point in my career. Within about a couple of weeks we started to talk about the testability of the project. I admitted something that I had been floating about in my head for a few days already.

I wanted to own every aspect of the Testing on this project. Complete responsibility would be mine, for better or worse. I wanted to own every bit; from the second that code is committed to the minute I’m finished testing it. I wanted to understand everything in-between better than I ever had before. I had never fully understood Continuous Integration or Continuous Deployment, I knew the terms but I didn’t know what they really meant. I wanted all that to change with this project

I would also challenge myself, if I needed to perform an action more than a handful of times I would teach myself how to automate it. Not just selenium but other automation tools as well. I had several scripts that I needed to copy-paste to clear out my environment. I taught myself how to make that a single script that would run all of those commands whenever I pressed a specific button using something called Bash Scripting which I had never heard of before that point. So now at the touch of a button I could nuke my testing environment, awesome!

So after pressing it accidentally one day mid-sprint I did indeed nuke my environment. I then realised I needed a similar solution for creating my testing environment how it was just before I nuked it. That was my next challenge.

Then I needed something to auto populate my databases after my environment was back up, that was my next mini-challenge.

Eventually I started to automate my testing, I even had some free time to start asking questions like ‘what happens if I destroy this service, how do the others react?’ My development team assured me that the container would gracefully shut down and the start back up, giving eventual consistency ‘No no no’ I said, what if I destroyed it, like, nuked it using a script. The micro service version of ripping the power out of the wall mid process.

No one knew. So I started to investigate, I made a script that just asked me ‘what service should we kill today?’ I typed in the name, hit enter and all hell broke loose. Well, relative hell.

The services didn’t really expect this to happen so what did happen was called a cascading failure, that’s where one failure in isolation causes the next service to die and then the next service to die and so on. Even after that original service came back to life the other services were still in a bad state. So I wrote my bug report, hit the magic reset button and respawned my environment

Has anyone here heard the term Chaos Engineering before? For those who haven’t think of it as unplugging parts of a widely distributed system, like an application hosted on Amazon Web Services - it’s to see if that application will recover from that failure. I didn’t realise it but by asking the questions ‘what if this service just doesn’t exist anymore’ I had also started to practice Chaos Engineering. My new mindset and curiosity meant that this suddenly wasn’t a monolithic subject to tackle, but something I had started almost by accident.

It was at about this point that Business Things happened and the project was put on pause. The developers were needed somewhere else and I went back to my Test Team which I’d been running as an almost autonomous task in the back of my mind; fortunately they were incredibly self sufficient and kinda managed themselves during this time.

So I went back. We were the Testing Team again, kicking softwares ass and taking bug reports. That first week something happened that always used to happen. A Testing server was not responding and someones test environment was down. This happened a few times in the past and each time I would log in, see that either there was a windows update that had rebooted the server or the hard disk was full, fix that and then tell the tester that it was fixed.

But god, why was I doing that manually everytime? I fixed the issue and them immediately setup passive monitoring on the server, I would at the very least find out a few days before the hard drive filled up and then got a script from Stack Overflow (where I get the backbone for most of my scripts) that would remote onto the server and force a reset, without me having to open any other app or remote desktop. Lots of other things happened where I was just like ‘nope, not doing that manually anymore’ or ‘these must be a better way of doing that, let’s put our heads together and find one’ I had changed, a lot, during that project. I had gone beyond that was expected of me and also what I expected of myself.

Suddenly I was rolling around in new technology like a dog in muddy water and I loved it. It had given me fresh perspective on what I could do from a testing position and how I could add value to the project and the team.

I was also suddenly being easier on myself. When a bug was found, I no longer immediately thought ‘why didn’t I catch that?’ I thought ‘that’s really interesting, let’s make it do it again, let’s poke it this way and that’ I was experimenting alongside my testing with new and different ideas. Managers would have that stern manager face on when a bug would be found after testing and I’d just smile and remind that that ‘we’re humans checking other humans, we’re bound to miss some stuff’

Since that project a lot has happened - actually since submitting the abstract for the talk a lot has happened…

• • • •

Became Principal Test Engineer Joined R&D Team Became LinkedIn Learning Author Started coding / livecoding for pleasure I became a Principal Test Engineer, mentoring and evangelising testing and software quality Shortly after that I left Testing; that’s a pretty big one. I got recruited into our R&D department I applied for and got accepted to be a LinkedIn Learning Author, publishing my first course on Load Testing with JMeter earlier this year I told myself that I was going to finish that book I’d been writing for the last couple of years, it’s almost there. I started coding in my spare time, not super intense, but the stuff I understood. I started to publish stuff to my github, passion projects without fear of judgement anymore. And this is absolutely self promotion and I can’t apologise for that, because you should all be proud of the achievements you earn in your career. Don’t grandstand but certainly don’t hide your accomplishments either. You earn these moments.

• • • • It’s okay to love your craft Geek out! You don’t need to know everything This too shall pass Now, something that I’ve really struggled with this talk is that it’s super easy for me to stand here and tell you a story but I want you to take something away from this. Something that will help you. So here goes… It took me a very long time to realise this be it’s okay to love your craft - that makes sense, right. Don’t let other peoples negativity for their jobs stop you from loving what you do. If you love it, love it. Geek out, you’re allowed. You want to celebrate that your script finally runs that you’ve been working on all day or that you’ve just learnt something new that has blown your mind. Be excited, tell your team, tell your peers - hell, post it on Twitter, tag me in it, I’ll be excited with you! You don’t have to know everything it’s fine to say ‘I don’t know what X means’ in a meeting, it’s better to be honest with people than to have them assume you already know that they mean. I figured out that I work visually to learn stuff so I would always boil our explanation meetings down to doodles on whiteboards. Do what helps. And finally if you’re in the same position that I was in, surrounded by the unknown with no real certainty if it’ll get any better. Trust me it does, and remember that you’re never alone in this. Talk to your team, talk to your community. It does get better. This too shall pass.

Thank you! @mikesmith_sh mikesmithsh Thank you! screamingjoypad