The Testing Show: Would Heu-Risk It? What’s In The Cards For You?
This episode goes in some unusual but interesting directions. Lena Wiberg joins Matthew Heusser and Michael Larsen to talk about Lana’s book and card deck, “Would Heu-Risk It?” which is all about heuristics and ways of looking at problems in a different light. Also, Lena talks about her keynote at Agile Testing Day 2022 titled “Living Fearlessly – While Living With Fear”
- Would Heu-Risk It?
- Would Heu-Risk It? (Card Deck)
- Would Heu-Risk it: What’s in the cards for you? (Agile Testing Days 2022 Workshop)
- Living Fearlessly – While Living With Fear (Agile Testing Days 2022 Keynote)
Michael Larsen (Intro):
Hello and welcome to The Testing Show.
Would Heu-Risk It? What’s in the cards for you?
This sow was recorded on Wednesday, August 3, 2022.
Heuristics are rules of thumb that can help people get a quick understanding of situations. To that end, Lena Wiberg joins Matthew Heusser and Michael Larsen to talk about Lana’s book and card deck, “Would Heu-Risk It?” Also, Lena shares some insights about her keynote at Agile Testing Day 2022 titled “Living Fearlessly – While Living With Fear”.
And with that, on with the show.
Matthew Heusser (00:00):
Well, hello and welcome to The Testing Show. I think we’ve got a special episode for you. This week, we have Lena Wiberg, who is an engineering manager in Sweden for NordNet Bank right now, but she’s been around for some time. Experienced member of the community. Came up through testing, test development, and originally programmer test manager into a more broad engineering manager role today. Lena’s giving a talk at Agile Testing Days in Germany in November. She’s giving two of ’em. That’s what really got me interested in having her on the show. Welcome to the testing show. Lena.
Lena Wiberg (00:44):
Thank you, Matt. I’m happy to be here.
Matthew Heusser (00:47):
Did I miss anything in my introduction of you or, or…
Lena Wiberg (00:50):
Maybe my Book? I’m kind of proud of that one.
Matthew Heusser (00:53):
Yeah. Tell us about your book.
Lena Wiberg (00:54):
Yeah. I published a book a year ago called “Would Heu-Risk It?” about things I learned during the 20-something years? I’ve built software.
Matthew Heusser (01:05):
Fantastic. So one of your talks, you’re giving a keynote at Agile Testing Days, but you’re also giving a talk on heuristics, which are fallible ways of solving problems. Americans might be more comfortable with the term “rule of thumb”, which don’t always work, but they can often point you in the right direction. And when I saw that, I didn’t realize you had a book based on the title. You wanna talk about that talk?
Lena Wiberg (01:30):
Actually, it’s not a talk. I have done a bunch of talks around the “Would Heu-Risk It?” concept, but this is actually more of a social activity. There’s also a deck of cards.
Matthew Heusser (01:43):
That’s what I thought. I knew about the cards, but not the book. Tell us more.
Lena Wiberg (01:47):
So what we’re gonna do in the session; people are gonna come on stage with a question, we’re gonna pull a card randomly, and then we’re gonna talk about how that card might or might not help with their problem. So I have no idea how that’s gonna work, but excited to try.
Matthew Heusser (02:03):
Have you done it before?
Lena Wiberg (02:04):
Not exactly that way. I’ve done workshops and they can end up any direction except the one you planned. No, this is something new because there’s no way to prepare because I have no idea what problems people are gonna bring.
Matthew Heusser (02:18):
I would guess at least one of the problem would be “buggy software”. Another one will be “aggressive schedules”, but maybe things are changing in COVID. Another one might be “my boss doesn’t listen to me”.
Lena Wiberg (02:28):
That makes me a bit worried because those are very broad problems. I’m hoping people are gonna come with something more specific, but we’ll see.
Matthew Heusser (02:36):
Do you have your deck in front of you?
Lena Wiberg (02:38):
Matthew Heusser (02:39):
Can you pull some cards out?
Lena Wiberg (02:40):
Michael Larsen (02:41):
We could probably also throw in something to the effect of “our data center is being migrated to the cloud”, which always throws things into chaos.
Lena Wiberg (02:50):
Yeah. I wonder… There’s not many cards that will be perfect for that one, but let’s see. <laugh> Funny enough, the first card I drew was one called “lost in translation”, which is…
Michael Larsen (03:01):
There you go <laugh>
Lena Wiberg (03:01):
So the cards come with a rhyme. So the rhyme on this one is:
“It’s easy to think everyone works the same, that everyone has the same rules to a game. The traveler hailing from way across the sea. His reality completely different might be.”
Michael Larsen (03:16):
Oh, I like that.
Lena Wiberg (03:18):
That would be a cool card to kind of match with a data migration problem, where we have both assumptions about things working the same way, but also translations between different types of… database engines is always fun, never go wrong.
Matthew Heusser (03:35):
So that would kind of reframe the problem then as not they’re wrong, they’re unrealistic. They don’t get it. Just they’re speaking a different language.
Lena Wiberg (03:46):
Matthew Heusser (03:47):
And then how do we communicate between the groups instead of, usually in my experience it’s frequently opposition. No, no. They use different words for different things.
Lena Wiberg (03:57):
Yeah. And I mean, just the fact that the same word can mean completely different things in different parts of the same company makes it almost impossible to not get things wrong at times. But if we just talk about it and bring those assumptions up to the surface, we can solve them.
Matthew Heusser (04:14):
When I was much younger, we brought in some very expensive consultants and I was an employee. They complained about our software, that it was completely untestable. I was like, “oh, it’s totally testable. Watch this.” And I sat down and started typing and it was fine. And of course what they meant was they couldn’t figure out how to write software to drive it, to automate it. And that’s true. It would be incredibly… it was database sort of procedures. It wasn’t even that, it was Oracle reports. So the point being the technology just wasn’t design for you to be able to do that. Well, that’s a different problem.
Lena Wiberg (04:48):
That’s a very big problem I’ve observed. A couple of years ago, most of the people that reported to me were testers, or business analysts, or people working with that part of software. Now, most of them are focusing only on building code and their view of testing (when we talk about testing), we mean totally different things. And it took me a while to not get offended every time and try to correct them, but rather accept that their view of testing was one thing and mine was something else and I could educate them on doing other things as well. And that testing can be so much more.
Matthew Heusser (05:27):
<laugh> You’re saying that we shouldn’t just tell people they’re using the wrong words and correct them on what the words mean. You’re saying that’s not a strategy for success?
Lena Wiberg (05:35):
Yes I do. It’s one of my big pet peeves on Twitter, when people end up discussing whether or not we’re talking about testing or checking or manual testing or whatever, just accept that people have different definitions and talk about what they really mean. Then it doesn’t really matter what word they use, but I know that’s not how everyone feels about it.
Matthew Heusser (05:56):
Well, I mean, on Twitter, that’s not discussion, that’s conversation, so I need to educate you on what the word conversation means… wait. <laugh>
Lena Wiberg (06:03):
Thank you, Matt.
Matthew Heusser (06:04):
Not very helpful, is it? Sorry.
Michael Larsen (06:07):
And we run a handful of things. Maybe we get a little bit creative for a few minutes, but we don’t necessarily go way off the rails. Sometimes it’s not worth it to do that. But every once in a while, it’s, “I’m not sure what I would want to do to be able to address this.” I love the idea of this card. Being able to get you in a different way of thinking to go, “Oh, hold on. Let’s see how we can do this.” So I’m excited to see this card. I’d love to hear more of them. It’s more what I’m saying.
Lena Wiberg (07:31):
<laugh> yeah. Before we go there, I just must say, I’m surprised you can even fit all of her cheat-sheet onto a mug. Do you have to have like super-vision to read it?
Michael Larsen (07:40):
It’s tight and it’s wrapped around in interesting and neat visual ways. But yeah, <laugh> it does fit.
Matthew Heusser (07:48):
I don’t know if it’s just the front. I remember it when it came out. I don’t know if it’s the front and back page. It might just be like the front page or something.
Michael Larsen (07:54):
It may not be the entire cheat sheet, but it’s got enough there. Anytime I pick up the cup, I go, “Oh, here we go. That’s why I always keep this one out.
Lena Wiberg (08:04):
Ah, that’s amazing. So do you want me to pull another card?
Michael Larsen (08:08):
Lena Wiberg (08:09):
I cheated a bit and search for my absolute favorite called “mischievous misconceptions”:
“Did you think for a second, all time is the same? Buildings don’t move. Everyone has a name. Oh, all the falsehoods we learn as we grow, never believe what you know that you know.”
So when we go to school as kids, we learn a lot of things that we are taught as truth, such as there are 24 hours in a day or in Sweden, you need to have a first name and a last name. And then you can have a bunch of middle names, but you always have a first name and a last name. The sky is blue. An address is always static. Things like that that, to us, is a misconception we have that this is truth, when in reality it’s true often or maybe even most of the time, but say like we have summer and winter time here in Sweden, which means that we have one hour that exists twice.
And then we have one hour that doesn’t exist at all. Because when we switched between summer and wintertime, we move the clock. Sweden is kind of still a very homogenous group of people. So when you start working with companies that are more international and you start talking to people from different cultures, you realize that my assumption that a name looks a certain way can be completely wrong. If I would move to, I don’t know, India, or I like my applications to be structured in a way where it’s easy for me to read them from top left to bottom right, but in different cultures, that’s completely wrong. So all of these misconceptions that hurt us when we build software, because we usually build for our own culture and the truths that aren’t necessarily truth in the rest of the world.
Matthew Heusser (10:06):
Yeah. So my favorite one for that is we’re never gonna have to deal with international characters. We’re never gonna have to deal with French Canadians, Spanish…an umlaut. We’re never, ever gonna have to worry about that. And there’s a guy named Markus Gärtner I use for test data. When Michael took over my job, he found his name in some of our tests. <laugh> and he’s got the two dots, the “ae” that’s actually ä”.. it was Socialtext. We’re running conferences. He signed up to use Socialtext. Cause we were using it as a platform to run the mini-conference on. “No! Guess what? We have these people now. <laugh>
Lena Wiberg (10:45):
Matthew Heusser (10:46):
So at the time as a tester, I was like, “Here’s what I can do. I can tell you what happens. And you can decide if you want to take that risk.” That’s really neat. I think you’re right. They’re broad generalizations that are mostly true. But in software, if you code that, you are saying, “it is true”. And then now you can’t get out of that. So then your software’s gonna have a problem. A leap year would be an obvious one, but if you forget to do February 29th or Daylight Savings Time, all those things, I don’t think I’ve heard it presented that way. Thank you.
Michael Larsen (11:22):
Or perhaps more to the point what we have here is we are coding in our biases as to how things look to us versus how other people might use them. A favorite example of this, say you wanted to put together a mail merge and you were sending to people in Japan, for example. While they do have first and last names, unless you are really familiar with somebody, you don’t refer to somebody by their first name, you refer to them by their last name. So addressing them by their first name right off the bat would be like, “Wait, I beg your pardon? What are you doing?!”Just, it’s a different way of looking at it that if you didn’t grow up in that culture, you would say, “Oh!” but yeah, if you write your software with that as a rule, you’re already starting off on the wrong foot
Matthew Heusser (12:19):
Or anytime… I used to frequently hear, “Oh, the customer’s never gonna do that. The customer’s never gonna want that. We’re never gonna have a customer situation like that.” And then as soon as you get to, say, I don’t know, 200,000 customers, someone does. I mean, invariably, it’s probability and statistics. That’s a one-in-a-million chance. Well, guess what? We have 10 million registered users.
Lena Wiberg (12:41):
Yeah. A million users isn’t that much today. Yeah. When everything can be across the globe.
Matthew Heusser (12:47):
So if I had a problem like “I can’t make this deadline” and I drew that card, it might reframe the conversation to be more like, “I can make this deadline, but I’m going to have to hose some small percentage of the user base. Is that okay?” I was just ignorant, but a large part of software development used to just make software that was unaccessible to those that were, say, visually impaired. We found that, by beginning with the end in mind, it doesn’t really add much time at all, as long as you don’t screw it all up and then take all your screw-ups out.
Lena Wiberg (13:23):
Yeah. There’s a lot of work to make software accessible once you’ve built it wrong but if you build it right from the start, it’s typically better for everyone.
Matthew Heusser (13:32):
Do you think that’s true for just software in general now moving to an engineering manager role? I think there’s that we’ve been trying that we shift left/right/test earlier, build the software better. We’ve been talking about that for 15 years now. Some of the companies I work with have had some success there. What’s it like for you?
Lena Wiberg (13:53):
Actually, you touched upon another one of my pet peeves there. So this thing about testing earlier, which people still today do conference talks about as if this was something new. When I took my first ISTQB certification back in the stone age, this was such a big part of testing. The static testing way before code was even written was such a big part of testing. How have we not solved this yet? Why do we still feel like this is something new? That boggles my mind, actually.
Matthew Heusser (14:29):
Well, I have an answer to that that I’d love to explore with your background.
Lena Wiberg (14:32):
Matthew Heusser (14:32):
We might be able to come up with something better together than either one of us could because it seemed to me that in the nineties, a lot of the testing literature, which was test cases and test design, kind of, it was come up with your test ideas with the requirements. That idea was there, but testing was boring and no fun and let’s have somebody else do it. And let’s hire someone maybe a little skilled to do it, to do this cheap repeatable work. It was when Extreme Programming came out, that you could write automated tests and do unit testing and Test-Driven Development. The testing became an exciting thing to do at least as part of the development cycle. And what I found is in the dissemination of those ideas.
Now everybody has a unit test framework. Visual Studio has it. Eclipse has it, your Ruby, your Python, your Rust, all the languages, they have it. But very few people do TDD because the idea is disseminated out now. It’s a very common idea that everybody has, but what we get is spread so thin. It’s like Weinberg’s [Law of Raspberry Jam], where the more you spread it, the thinner it gets. And so these ideas have become a lot weaker. As for developing the tests along with the requirements, we have the same problem but I think that for instance, BDD… the good thing about Agile and XP was we developed the ideas and then told people about them. And BDD seemed much more like, “Let’s come up with some cool ideas.” It was taken on faith as opposed to tried and explored. So if you do BDD, you get a lot of tests that are incredibly verbose that you can kind of read, but they probably aren’t gonna be automated.
And you probably don’t have a method to maintain them. And you’re gonna continue with development and they’re gonna get out of date and it’s gonna be icky. It’s gonna be hard to green the tests. So I would submit to you, there are pockets I can find that really still do XP, that really still do Test-Driven Development, that have high-quality code earlier. And there are pockets that do requirements pretty well, but for the most part, it’s like slap some stuff together in JIRA, write some code, have some non-zero amount of unit tests, usually test after. There’s not a lot of focus on craft. There’s not a lot of focus on patterns or refactoring. Software’s better today than it was 20 years ago, but not by as much as I would like. That’s my thought. What do you think?
Lena Wiberg (17:07):
I think we’re building complex software faster, but we know less about details of the stuff that we build, because reuse is amazing but when so much of your code is using someone else’s code, a library pulled in, you don’t really know what’s going on under the hood. So when you have to change something, it becomes extremely complex. I, for certain, don’t want to go back to the days where it took me a week to implement Easter Day calculations, but I really knew how it worked. So if I had to change it, it would’ve been a two-minute thing. Today, a lot of the developers are extremely amazing at building complex architecture, but some of the things that to me were like my bread and butter, they don’t know how to do. I don’t know. I hope in the future, we could get the best of both worlds and hopefully not the worst of both worlds.
Michael Larsen (18:04):
I see a lot of that as well. I noticed that, especially when we were refactoring and redeveloping Socialtext, which now goes under a different name by the company that I work for now, and we had to do a similar situation where we went from a system that was built in-house by a really strong set of developers, but it got to a point to where it was rather difficult to maintain without them. So we had to make the deal to go to a more established, at least by today’s standards, set of software, where a lot of the framework was already built. And sure you could use wireframes and you could set things up rapidly, and 96 out of a hundred times, everything would work just fine. But it’s those four instances where it doesn’t, that can be the biggest headaches. So I definitely can appreciate how that feels <laugh>
Matthew Heusser (19:05):
Yeah, it’s an interesting comparison. When I started programming, it’s a different century and it was a C program that was a bill for a phone company, C being portable/assembler, I knew it all the way down. And then, when the first GUI applications came out, and you coded in Visual C++, before Visual C++, there was no Drag and Drop. You would define your screen elements in a programming language. Today, you’ve got Drag and Drop mobile app tools, where you just Drag and Drop it, and you tell it what all the things are, and you connect ’em all together. And everything just works, right up until it doesn’t. Then I don’t know how to fix it. It brings me to your other talk, which is a keynote to Agile Testing Days. And that’s “Living Fearlessly While Living With Fear.”
Lena Wiberg (19:56):
Matthew Heusser (19:56):
Tell us that.
Lena Wiberg (19:57):
Isn’t that just an amazing title? I love it.
Matthew Heusser (19:59):
Tell us about that.
Lena Wiberg (20:01):
The basic idea is that to the people who don’t know me, to the people who know me from conferences or Twitter, or watching a video or whatever, I look like a pretty confident, fearless person who’dd do things they think is really scary. Doing talks in front of however many people on topics that maybe I wasn’t an expert on a year earlier, but someone suggested that they wanted to hear a topic about something. And I’m like, “Yeah, I can do that. I can learn and then do a talk on it.” But to the people who know me, I am an extremely anxious person. I am scared of so many things. I like to say, when people ask me, what’s the worst thing that could happen. I smile. And I say, “Do you want that list in chronological order or order of magnitude, if it would happen?” I’ve found strategies and ways of pushing myself to do things anyway, even though I’m scared, even though I’m anxious all the time. This will be a very personal talk with a lot of stories from my life. Things I’ve gained from pushing through this fear and also some funny stories about when it really didn’t help me.
Matthew Heusser (21:17):
Okay. Your abstract talks about imposter syndrome and you joke about not having it.
Lena Wiberg (21:24):
Yes. I can’t think of a time in my life where I didn’t think I could do something.
Matthew Heusser (21:31):
Okay. I don’t connect with imposter syndrome at all. I think I was promoted very slowly and only signed up to do work I could actually do. I think that’s different. You are saying you figure, “Oh, I could go learn it”, which I think is probably healthier. That’s a growth mindset. I was more like, “I’m not gonna sign up for it unless I can do it.” That’s not that different, I guess, because then, if I didn’t know how to do it, I’d read a book or something.
Michael Larsen (21:58):
Here’s an interesting way to think about this. Or at least I think it’s interesting. And these are conversations I’ve actually had. I think this might be something that might be more common with women in the field. And please, I do not want to generalize, but this, this is literal conversations I’ve had with people. Let’s take a job description for example. And let’s say a job description has 10 factors on it that you need to have to be considered a fit for the job. The running joke and the conversations that I’ve heard over the years from this are if a guy, a man like myself, sees a job listing and four out of the 10 are good fits, but the other six are fuzzy or not really there, eh, they’ll throw at it. They’ll figure, “Why not? Let’s give it a shot and let’s see what happens?”
Whereas many of the women that I know have said, “Unless I match all of those, I’m not going to apply for it.” And I think that may be a little bit of a different take on this in the sense that it’s not so much that it’s imposter syndrome, but it’s that some people perhaps decide that unless they can fit something perfectly, they’re not going to try for it. And I confess that I’m more the latter than the former. I don’t really go outta my way to say, “Oh, hey, uh, I can wing it on whatever.” I’m not that confident in my skills to be able to say, “Oh, sure, whatever, I can wing it.” And the few times that I have done that I’ve struggled vitally, and it hasn’t been a lot of fun. So I think that there is a sense of this in both ways. I don’t know that imposter syndrome is necessarily the right word, but I think there is a sense of what can you handle? Do you understand your boundaries? And is there a difference between “I believe in growth and opportunity and being able to take things on and tackle them.” versus the old Dirty Harry line, “A person has to know their limitations.”
Lena Wiberg (24:00):
So when I compare myself with people that I know have imposter syndrome and talk about how they feel when they tackle something that is complicated or hard for them, I would say we both do it. We both might struggle and doubt things. The difference is they could say things like, “But what if I can’t do this? What if my talk won’t be good? Or what if I can’t be a good manager?” I realize this makes me sound a bit like a sociopath, but I’ve never felt that because I’ve always been able to do the things that I’ve taken on in maybe not the best way, but in a good enough way. So I trust my skills. I trust my intelligence. I trust that I can learn. I still don’t apply to ads that maybe I feel like I’m not a perfect fit, but that’s not because I don’t think I could do the job. It’s because I just can’t be bothered to put in work in something where I think I won’t even get through the talent deposition level because they will be looking at matches in a checklist. Did that even answer what you said, Michael?
Michael Larsen (25:16):
Yes, it did. And if I may go on one little tangent here that I think might be helpful for this, again, maybe just dealing with the whole idea of imposter syndrome to begin with. One of the things that helped me tremendously, and I admit I’m not doing it as often as I used to, just because of other opportunities and things that I’m working on. A decade ago, when I started my blog, I started that from the idea that I wanted to learn in public, have some things to talk about, be able to ask questions and hopefully get answers from other people. But what was interesting about that experience of writing that blog and putting those articles out there, it gave people a real indication of what I was comfortable with, what I wasn’t comfortable with, and what I was “complaining about”. One of the things I thought was funny was when I was approached by the company I work with right now, they were looking for somebody to take on certain aspects.
And I was just curious, “Why do you think that I’m the person to do this? What makes you think I have the expertise for this?” And the words I got back were, “I read a bunch of entries from your blog. And I could tell, by the way you were talking about it, the fact that you were sharing those frustrations, the fact that you were sharing the areas where you were beating your head against the wall meant you had actually done it. Many times, we interviewed people who look great on paper and who say that they understand something. And then when you actually work with them, they don’t the fact that you’re going through and documenting the areas that you’re frustrated with proves to us that you do actually understand the assignment. “So to speak. I thought that was an interesting way of looking at that. So by putting yourself out there, which goes to your, when you’re dealing with fear, how to be fearless, I would say, put yourself out there and do the thing that you’re scared of. And yeah, if you’re scared, admit it, say, “Hey, here’s an area where I’m not sure I’m the best fit for this, but I’m gonna try this anyway. And I’m gonna let you know where I end up.” And you might be surprised how many people find that both valuable and then those experiences being what a team needs to be able to succeed.
Matthew Heusser (27:38):
There’s a guy out of Indianapolis. His name is Michael D. Kelly. He used to be heavy in the Indiana QA Association, and this was a while back and they had software and they were worried if it was gonna scale and everybody’s sitting around, what are we gonna do? And he was “just a tester” in his words, just a tester. I don’t like that phrase, but he said, “Well, there’s this free software called (I think it was JMeter at the time)… I’m gonna go write some automated tests. I got time.” Was a while ago back when you used to wait for builds. “And if the dumb tester can do it, then you know, anybody can do it.” And he had that attitude. Last I checked, Michael was co-owner of a company called Developer Town with something like 20 full-time developers, writing software on contract. They did stuff like, “We’ll take equity in startup companies as part of our compensation. So yes, you’re gonna pay us and yes, we’re gonna cover our costs, but it’s not gonna be exorbitant, which is gonna allow your money to go further. And you’re gonna give us some equity of those companies.” A few of them were big megastar successes. He’s my age. My guess is if we try to bring him on the show, he’ll be retired. But somehow he overcame the fear and acted anyway, which I think is what Lena is talking about, or in the same direction. Yours is more public speaking and career opportunities, but it’s in the same direction.
Lena Wiberg (29:00):
Yeah. I mean, totally. There will be 45 minutes of talks. I’m gonna cover a bunch of things like “what is imposter syndrome?” and “what are other types of similar things that are not imposter syndrome?” I’m gonna talk about bravery. I’m gonna talk about pushing yourself versus accepting when something is not healthy for you. But yeah, it is definitely in the same direction.
Matthew Heusser (29:23):
I love how your abstract ends. “This is me being brave and showing the world the worst of myself. It’s terrifying. I can’t wait.” That’s really neat. Thank you. So we’re on the last part of the show where we give the speaker an opportunity to say where we can learn more and also have one closing thought. If there was one idea you wanted to give to people, then let Lena go last. So Michael, is this fired off anything in you?
Michael Larsen (29:49):
Well, I think I already mentioned it in the sense that I love the idea of the cards being that random set of knowledge. Again, it comes back to my cup, the Test Heuristics Cheat Mug”. When you are looking for something that you need to ponder, just grabbing it and twisting it and looking in a certain place will give you a new idea. The idea of taking the cards out, drop five down and read them and ponder them for just a few seconds. You might come up with a new idea that you wouldn’t have had you not done that. I think that’s cool and exciting and fun. And also the whole idea of facing your fears and being willing to just live with them. I think that is comforting to a lot of people. I think there’s a benefit to that. I hope that your talk is recorded. I want to be able to see how that turns out. I think you’ll do great, Lena.
Lena Wiberg (30:43):
Matthew Heusser (30:44):
I was really struck with the difference between… when I entered the job market, we didn’t have indeed.com. We didn’t have monster.com. We didn’t have LinkedIn. The world wasn’t as interconnected. You weren’t competing against anyone working anywhere with internet and power. And one of my professors said, “Consider the job help wanted listing as a wishlist. They’re wishing they find someone like this, but they’re not gonna find someone like that. So go ahead and apply.” Anyway, it was encouraging, but the stack of resumes companies saw was probably smaller back in those days. So what Michael said about blogging, or maybe you have your own GitHub, or maybe you do conference talks, or maybe you just go to meetups and build relationships so that you can be introduced as someone who, “I know Sally can do this job, Matt, you should hire her. I’ll stick my reputation on it.” If you can find a company that actually would hire based on that, if you’re like me, you’d probably have a better experience at that kind of company than the one that is doing the keyword matching algorithm exclusively, cuz they’re gonna get what they’re gonna get, which is people willing to type up that they have the things. That’s what I took from this. Thank you for making me think. What are your closing thoughts, Lena?
Lena Wiberg (32:07):
I take with me the things which I knew, but it made me think about it again. Things that I thought were obvious are not obvious to other people. My view of imposter syndrome or living fearlessly is not the same as yours. And I’m gonna have to bring that into the talk to make sure that people get the best experience. Also, seems I’ve been hiring a lot in the last years. It is incredibly hard to write good ads. It is incredibly hard to interview. And what I’ve learned in the last year is that it’s so hard to teach someone else what you are looking for. Since I’ve typically been managing a large group of people, I don’t have time to read 300 resumes, but it is so hard to explain why one resume would be someone I would bring into an interview. Why another one isn’t and maybe that would/should also be a talk in the future?
Matthew Heusser (33:06):
Yeah. I’d love to do that. Or I’d love to hear about that or be involved in some way. That sounds really, really neat. We have some of the same problems or same challenges, although really it’s not living fearlessly, it’s living unfearfully. So we should talk about that, you know, and have a debate on that. So again, we’ve got Lena Wiberg and her book is “Would Heu-Risk It: Traps and Weapons for Software Testing”, you can get it at Amazon or any fine bookseller. And, of course, we’re gonna have a link in the show notes. Thanks for being on the show. Hope to hear more from you soon.
Lena Wiberg (33:40):
Thank you for having me.
Michael Larsen (33:41):
Thanks for joining us.
Lena Wiberg (33:42):
Michael Larsen (33:43):
Take care, everybody.
Michael Larsen (OUTRO):
That concludes this episode of The Testing Show. We also want to encourage you, our listeners, to give us a rating and a review on Apple podcasts, Google Podcasts, and we are also available on Spotify. Those ratings and reviews, as well as word of mouth and sharing, help raise the visibility of the show and let more people find us. Also, we want to invite you to come join us on The Testing Show Slack channel, as a way to communicate about the show. Talk to us about what you like and what you’d like to hear, and also to help us shape future shows. Please email us at thetestingshow (at) qualitestgroup (dot) com and we will send you an invite to join group. The Testing Show is produced and edited by Michael Larsen, moderated by Matt Heusser, with frequent contributions from our many featured guests who bring the topics and expertise to make the show happen. Additionally, if you have questions you’d like to see addressed on The Testing Show, or if you would like to be a guest on the podcast, please email us at thetestingshow (at) qualitestgroup (dot) com.