Good reads

Some books I’ve read that I found useful in my career and my life.

The Logic of Failure: Recognizing And Avoiding Error In Complex Situations (Dietrich Dörner)

logic of failure

One of my pet hates is when people try to oversimplify a complex problem in order to make it solvable. For example, “we’ll just automate everything through Webdriver and won’t have to do any more manual testing”. This book follows the results of a study where subjects were given several computer simulations of complex environments, and were asked to control certain variables in order to affect a desirable long-term outcome. It explores the strategies used by successful and unsuccessful participants and gives recommendations for successful strategy in complex situations.

What Every BODY is Saying: An Ex-FBI Agent’s Guide to Speed-Reading People (Joe Navarro)

what every body

I read a couple of body language books before this one and they weren’t nearly as in-depth. The perspective of an ex-FBI agent made for compelling reading too. Navarro talks about the physical and chemical reasons behind body language, what is automatic and what is controlled, and how to read body language in different contexts.

I bought this book to help me read other people better, but what I didn’t expect was how it helped me to notice my own body language more. It made me very aware of the subconscious message I was sending to others with my posture, my tone of voice, and more. This helped me in everyday situations and in public speaking.

Later it even helped me in my artwork, as it helped me understand  how character emotion affects posture, stance and muscle tension in different parts of the body.

Getting to Yes: Negotiating Agreement Without Giving In (Fisher, Ury, Patton)

getting to yes

I’m not the kind of person who likes to get the best deal at the expense of somebody else, and I don’t like using manipulation or lies to get what I want. So negotiating always made me feel uncomfortable, as I felt it was difficult to achieve a fair outcome for myself if the other person wasn’t willing to be fair to me.

This was a required textbook for my friend’s Law degree, and she recommended it highly. It describes the strategy behind principled negotiation – coming to an agreement with all parties through empathy and creating options for mutual gain. It does also go into what to do if the other party is not entirely moral in their negotiation tactics.

It’s served me well and should really be required reading for life.

How to Stop Worrying and Start Living (Dale Carnegie)

stop worrying

I’ve met some people who have unflattering opinions of Dale Carnegie, but whatever you think of his reputation I still think his books have a lot of value. I’ve always suffered from worry and anxiety and this book actually helped me a great deal. The case studies used are interesting and useful.

Surprisingly, I found it related well to software testing too. If you think about it, testing is a response to risk and risk is, well, worrying. I’ve worked with many software development teams that want someone to “test everything” because they’re worried something bad will happen. Worrying isn’t necessarily needless – something bad COULD happen – but having a sound mitigation plan and accepting necessarily risks after analysis of the situation is a way to address this.

How to Deliver a TED Talk: Secrets of the World’s Most Inspiring Presentations (Jeremey Donovan)

ted talk

When I was first asked to deliver a keynote, I was excited but pretty intimidated. I knew my talk had to be compelling and memorable, and this book helped give me some ideas what makes great presentations great.

This is tailored advice for 10 minute TED talks though, so it wasn’t all applicable to my 40 minute keynote. But the principles are sound, and it’s not a bad resource. There’s still a lot more study to be done beyond this in order to give a great talk!

Interview by Fog Creek Software blog

I was recently interviewed by Fog Creek Software’s blog about embedded testers in development teams. Check it out here to listen to me rant about how software testing needs to be a core competency of the software engineering discipline.

Note: I mentioned a book in this interview “Driven by tests” but I got the name horrifically wrong. The name of the book is “Growing Object Oriented Software, Guided by Tests” by Steve Freeman and Nat Pryce.

Introducing Speak Easy

I’m delighted to announce that I have agreed to be a regional patron for Speak Easy – a program designed to increase diversity in tech conferences through dedicated conference spots, mentoring and events.

Speaking at your first tech conference can be intimidating, but it’s very rewarding. I’ve written about my experiences before.

If you would like to get better at public speaking at tech conferences, or would like to mentor others, do have a look at where you will find a supportive speaking community.


Start spreading the news: CAST keynote in NYC

I’m excited to announce that I’ll be giving a keynote at CAST 2014 this August in New York City! The title of my talk is “Scaling up with Embedded Testing”.

The theme of CAST this year is “The Art and Science of testing” and the speaker lineup looks fantastic. I’m really looking forward to spending several days in the company of some amazing and inspiring people.

If you’d like to join us in for CAST in New York City this August, register here. See you there!


Interview at Hack and Heckle – Rise of the “devster”

I’ve been interviewed by my buddy Ben Morgan on his podcast Hack and Heckle. Ben was a pal of mine at university. One of my first memories of Ben was when he confronted my friend Jo and I at the uni pub for running out of his databases tutorial when his back was turned. In our defence, his tutorial wasn’t at all boring – we were just very hungry!

In this episode, we discuss what happens when software developers level up their testing skills. Listen to it here!


Actually moving to San Francisco

For reals this time!

Yes in June I’ll be moving from London to San Francisco. I’ll still be working at Google in much the same role, I’m just moving desks across the pond. I’m excited for the new opportunities that await. And happily, I’ll be about 10 hours’ flying time closer to my family in Australia, with a much nicer timezone overlap.

Thanks London for high tea at Forbes & Burton, drinks in the Science Museum, ducks and geese on every menu, Rebel f**king Bingo, the Tube when it’s working right, the grand scale ping pong bar, the overwhelming temptations of Borough market, daffodils in the springtime, being classed as a “morning person” for being chipper at midday and for doing Christmas season the right way – by being too cold to do anything but stay in drinking mulled wine and eating Yorkshire puddings. And for teaching me the importance of orderly queueing and a good cup of tea. I’ll be sure to visit.

Hey again San Francisco. We both knew this was inevitable. See you soon.


Female technologists, let’s be heard

As I do a lot of public speaking these days, I’m often amused to hear the feedback that I’m a “very natural speaker”. People are always surprised when I tell them that I used to be very shy. Actually “shy” doesn’t even cover it. Two years ago I reunited with my friend Masami, who is like a sister to me. I hadn’t seen her since I was a teenager, when she came from Japan to live with my family for a few years. I told her how I started the Sydney Testers Meetup and how much I loved meeting new people there. She looked surprised and said “What! But you HATE people!” Yes that was me as a child and a teenager – the shy, quiet girl who hated meeting new people.

So how did I get from there to here? At some point in my life, I just found that I was passionate about software and testing, to the point that when I spoke about it the words just flowed out of me. Sometimes partway through speaking I’d realise I was talking and people were listening to me and I’d get self-conscious and trail off. But then it occurred to me that I’d been speaking and people were listening, so I should try it again. And I just kept on doing it.

I was talking to a female scientist at the Google Women Techmakers event last week and she commented on how very few technical women speak at technology events like I do. At events like these, we still have a lot of business women in the tech industry who are speaking, and that’s fantastic, but there aren’t very many women programmers who want to speak publicly. I think there’s a simple reason for this – there just aren’t that many programmers of either gender that are comfortable with public speaking. If maybe 10% for instance are okay with public speaking, then 10% of women programmers is a much smaller number than 10% of male programmers because there are simply more male programmers.

“Maybe we just have to suck it up,” she posited. “Maybe we’re the ones on the front lines.”

She has a point. If we want more female engineers as role models then more of us are going to have to get used to being in the spotlight. And hey, I’ll be the first to admit that’s not easy. I still get nervous every time I go up on stage, and for at least the entire month beforehand. But it does get easier with practice. And every time I’ve done it, it’s proof to myself that I can do it.

And if your excuse is that you just don’t have the same self-confidence as me, well I’ve got that one well covered too. I’ve suffered through clinical depression, been to therapy for low self-esteem and I still get anxiety attacks that paralyse me. Several times in my career I’ve thought I can’t do this, I should just quit and do something completely different. But in my heart I’m a scientist, and if the hypothesis is that I can’t do it, then I need some evidence before I’ll let myself completely believe it. So I set myself a challenge and make myself prove it – can I do this or not? Can I get up in front of 400 people and talk about something I believe in? Or will I back down?

I place bets on myself and so far I haven’t lost. And each time I’m amazed at this, so it still feels like a gamble. But it’s exhilarating. I’ve never been into extreme sports; this is all the adrenaline rush I need.

My cousin Shiloh has absolutely crippling chronic fatigue syndrome. Most days she’s lucky if she can even sit up for a few hours, let alone stand and at one point she was confined to a wheelchair. She’s in constant physical pain. But throughout it all she’s positive, and good, and perhaps the purest spirit I know in this world. Last time I visited her in Brisbane, I bought this artwork from her (above) that reminds me of her strength and her spirit. If I ever need a reminder that I have opportunities and I’m capable of so much in this world, this is it. I can walk, I can even run. I can sit up for hours, I can use those hours to learn so many new things. I can speak, I can even speak to hundreds of people at once. It’s not easy but my god, it’s completely achievable. And it feels so good to do it.

So to women engineers, I urge you to speak. I encourage you to get up on that stage and tell the world how much you love technology. I push you to shatter the stereotype of the white male nerd programmer. I’m not saying you have an obligation just because you’re a woman. I’m saying that you have an opportunity to join us on the front lines and be part of our revolution.

Trust me, it feels great.


Forget developers in test, we need testers in development

Last year I started working on a small team with developers that really value testing and treat it as in integral part of the development cycle. I’ll never forget one of our first planning meetings when we were discussing a feature that we were about to build and a developer frowned and said “Yeah, but how are we going to test it?”. As a result they changed the whole design.

I think I just about fainted with shock, having never heard that in my career. The key part of this was that it wasn’t the team asking me, the tester, how *I* was going to test it. It was a question asked of the whole team – how are we as a team going to test it? How can we build this so that we have confidence that it will work as we build it?

As we built features, the developers would always write tests – everything from unit tests to browser level tests – and have another developer do some manual testing before it was passed to me for testing in a fully integrated environment. By the time it was handed to me this way, I rarely found bugs that were due to carelessness. Most of the bugs I found were due to user scenarios or system scenarios that hadn’t been thought of earlier.

So you might think, as a tester, did I really have much to do on a team like this? My most valuable asset in this process was still the way I thought about the product – from a testing standpoint, from a user standpoint. What I found was that my testing expertise became less valuable at the end of the cycle and much more valuable at the start. The more effort I put into testing the product conceptually at the start of the process, the less I effort I had to put into manually testing the product at the end because less bugs would emerge as a result.

I just want to break that last bit out into a big fancy font quote here because I think it’s quite important.

The more effort I put into testing the product conceptually at the start of the process, the less I effort I had to put into manually testing the product at the end

But the key part of this was that I knew that the development team was testing the product effectively by thinking about testing, writing tests and manually testing as the product was being developed. I could trust that if we had thought of a scenario during planning, it would be effectively developed and tested with automated regression tests in place by the end of the process.

I’ve had a lot of discussions this year around the role of the tester. Let’s put that aside from now and start thinking about the role of a software developer. A software developer needs to be able build a product with confidence that it does what it’s expected to do. Knowing how to do that at a basic level should be critical to the role of a good software developer. For that reason, we need more testing in software development. And it needs to be done by the people building the product.

Having a testing specialist on the team is a valuable asset, but the role of a specialist isn’t to restrict that responsibility to a single person. You might also have a database specialist on your team, but it doesn’t mean that they’re the only person working with databases. The same goes for testing. The specialist can help with the really difficult testing problems, knowing that the rest of the team is capable of dealing with the simple testing problems.

Then it’s shorter feedback loops, greater confidence and faster quality releases for all. Who doesn’t love that?

Special thanks to Chris, Bram, Tom and the rest of the Wildfire team at Google – you guys rock.

Special shout out to Alan Page who’s made me punch the air and yell “hell yes!” every time I’ve read his blog this year. 

Trish Khoo's tech blog