248: What is Programming with Edaqa Mortoray

Hit it.

Welcome to the Test Talks podcast, the place to go to geek out on software testing. And now your host whose mission is to help you succeed with test automation, Joe Colantonio.

Hey, it's Joe. And welcome to another episode of Test Talks. Have you ever wondered what really is programming? I mean, at a deeper level than the obvious answer. That's what we'll be test talking all about today with Etokua Mordore, author of the new book what is Programming? A harmony of people, code that runs the world, and the individual behind the keyboard. If you remember from our previous test talk with Etaqua, he is the inventor of the programming language Leaf, so he knows a thing or two about programming. So listen up and discover what programming really is.

Test Talks is sponsored by the fantastic folks at Sauce Labs, the cloud based automated testing platform that eliminates the need to maintain your own selenium grid and test infrastructure. Try it for free today. Visit testtalks.com and click on the sign up now link under the homepage sponsor section.

Hey Ericwa, welcome back to Test Talks.

Hi, I'm glad to be back.

Awesome. So today I'd like to talk about your new book, what is Programming? Since I think automation testing is a development activity, I thought it'd be fun to dive into your book. But before we get into it, what have you been up to since last time we spoke? I think it was in episode 153, almost two years ago.

Oh yeah, two years. I mean, two years is a long time. How much I've been doing, I've been doing for most of the time I was working on the cross platform development up at a company in Oslo, in Norway, doing a company called Fuse. And since then I've been. I wrote this book, obviously. In between I started a food blog. I've done other writing and I've worked on various other projects that don't come to my mind right now. So I've been keeping busy. But the main work has been that programming and this book and now I'm focusing more on freelance things and hopefully I have a course coming out this month too.

Oh cool. Where's the course? Is it going to be on Pluralsight or on your own?

I'm going to do it on Skillshare initially and I'm going to try something a little bit more generic than some of my programming talks. I want to say generic but larger audience. I'm going to go for writing user stories as my first test.

Oh, nice. So why did you choose that topic? Do you find that a big Issue when you do consulting.

I chose a topic because I think a lot of it has to do with in the book and my experiences. If I look at a lot of things that have failed over time, a big part of it was always came back to, you know what? We really didn't know who we were writing for. And so I think it's very important that people know they have this way to communicate. And I don't think a lot of people understand how you actually create an image of a user and how you deal with them. And from a practical standpoint, it's also one that in terms of setup and technical difficulty, is not too challenging for the first course.

Very cool. So I noticed, like, you know, you worked in France, I think Canada, Norway, you mentioned. Do you actually travel to these places? Do you work remotely?

I mainly work remotely. I do travel to the places, of course, to work with the teams for a while, but I mainly work remotely.

So based on that information, what made you write? What is programming? Is it based on all your experience dealing working with different cultures and different companies, or is it just a fundamental. You love programming languages since you created one and therefore you created what is programming?

No, this one actually comes a lot from my work with interviewing and meeting a lot of new junior programmers, people coming into the industry and people that are uncertain of what there is to be an offer. Because I've been doing programming for a long time. The type of people I work with, we've been doing a long time. We know everything there is to do with the experience. But I see a lot of people coming in and they're uncertain of really what the profession is. People see the coding, they think, oh, it's all about coding. And I want to give the perception, it's like, well, that's not really true. That's like, part of it. But there's so much more to programming. And even in the coding part, there's so much more to it. And I really wanted to give this overview, this guide to sort of the people. Like, look, I know you had your job to do and you've been doing it, and you may not have had the chance to see everything that's available, but look at all this stuff that you could be doing as part of your profession. That'll make you better at it.

Very nice. And I think you bring that out in the book. There's three different categories you break the book into. One is people, code, and you. So only one of them is code. The other two is people and you. So I thought we maybe can dive into all three. But are those the categories you're thinking of when you say there's more to coding than coding?

Yes, those are the three main categories. And people code and you.

Nice. So let's jump into people first. What are some misconceptions or some things you think people don't realize, as a junior developer, that people come into play?

One of the things I think a lot of people miss is that programming is a very social activity. And the way I've been phrasing this lately is that if our technology, if our computers, our smartphones and stuff, could actually do everything we wanted them to do, you wouldn't actually have to talk with people too much, because you could just do whatever somebody wanted. But since they never do what we want, it's an endless world of compromise. And this involves talking with people, because when you're programming something, it's really a matter of picking the right features, the right way to implement those features. And this involves talking to everybody involved, from the original stakeholders, from any of the graphic designers, even including the testers, what they need from it, what the users do and how they do it. And I think there's this misconception that programming is not a social activity, but I think it's a. It's one of the primary aspects of programming is actually the social communication to get the right product out.

Yeah, it's a good point, because I think you even mentioned that we're not writing software for software in general unless it's Iot or something. We're generally writing software for people. So what skills you think may help us be able to extract or communicate better with people in order to create better software?

I think one of the biggest skills is basically listening. You just have to be willing to actually listen to other teams and other people on those teams, and those other teams have to have that willingness to talk as well. And so I think that's sort of the biggest skill. If you just listen, you just make the attempt. Because I think the biggest thing is a lot of people just forget to make the attempt. I don't think you have to go out and receive really advanced training to do this. I mean, okay, great, I got to sell a course, do this stuff. But I'm going to be honest and say, look, you can get to the basics just by talking to people and just listening to what they have to say and just taking all viewpoints of the technology.

Nice. So after you talk to someone, how does that influence how you actually write a requirement? Do you write the requirement or how would someone take, take what they learned from listening and then transform that into a piece of code that really is going to meet that user's expectation?

We think this is where the user stories come from. Then once you understand the user, you're going to write down, I would say write down with exactly what the person wanted, say exactly what they wanted and then look at it. You have to use some common sense here and start thinking like can I actually provide this exactly as is? And then you could do negotiations. You can say, well look, I can't do this, but I can provide these other options. And this is where I say, as a programmer, it's your job to translate what's technically possible into language that this person can actually make a decision on. Say okay, I never thought of that, that might be an option, let's go with that. And so the actual use cases and requirements that come out are kind of a result of a negotiation saying, oh, this is what we agreed, we can, we can both implement and do and verify that it works altogether and we're going to go with this for now.

Very cool. I'm just thinking of an automation framework. A lot of times people say, well, we don't have customers, it's used in house, but people are going to use that to do testing. So I assume that that also would be considered communication. You'd have to communicate with someone that's going to use your product.

Absolutely. And this is why I always say it is always about the end users what you want, but there's a lot of people involved is that when you have like the automation and you have the quality control teams as well, it's useless to produce a product that they can't verify works. You actually have to talk with that team as well and figure out what requirements do they need, how would it help them? And again it's two way communication because as a tester comes in and says, well you know, I would really like to have this set up here and the programmer can look at it and go, okay, maybe I can't do that, but I have some other options. Would these be of help? And again, it's that exact same negotiation happening. What be really good. But the key thing is that it actually has to happen. And that's unfortunately doesn't happen in a lot of places where sometimes you even see that sometimes testers don't even talk to programmers. And that's kind of scary big time.

And that's where I usually get the biggest benefit, is actually talking to a developer. For us, I do Something crazy in code where they can expose an API or a hook to make automation easier.

Yes, and exactly that. There's a lot of things that testing can be made a lot easier. And I think we talked about the last show and I've written articles about it, like even writing specialized testing programs, different interfaces for them. A lot of these things. If you take the overall workload, sure it's added work for the programming, but if you can reduce their workload of testing, a significant factor, it's like a huge gain for the quality and for the company.

So another cool point you brought up in the people section was you mentioned non functional requirements and the one that you brought up was maintenance, which is a significant non functional requirement. How do we find these non functional requirements is the first question. The second one is like, how can we design our software to be easy to maintain?

This was. Well, many sections of the book. I was going through this when I was thinking, like, I started listing and I was like, oh boy, I bought a second list here because I could probably write a whole book on the non functional requirements bit here. There's so many of them. I think these ones honestly won. You can actually just go online and get lists of them. But they're going to look scary. Like I actually looked at Wikipedia for them and there's like this massive list of like 50 of them split in the subcategories with more links. I'm going like, oh yeah, if you had to start with this at the beginning of your project, you just get scared. So I think a lot of it is from the experience trying to learn which ones come first. There are some big ones. Maintenance is one that comes up a lot. Unless you work in a startup where maintenance is like, hey, look, if we get to the maintenance stage, we've won. And.

As you get those programmers that had to deal with it though, they're going to look back at you and think, I really wish they would have worried about maintenance just a little bit.

I think you just have to do a lot of projects and you have to read the lists, look out what's out there. Security and privacy are the really big non functional requirements now and they come up a lot. Whether what level you have to achieve them is a bit difficult, but understanding their implication, and this is again talking to a lot of people, particularly in the area of security is this one is one in the people. You can't actually determine what the security requirements are on your own because from a programming standpoint there's no like ideal security. You can just Keep adding more and more security measures. This is one of the rare cases where you actually need to involve some legal advice and business aspect of the company to come and tell you what do we actually need? How much effort do we have to spend on security based on our exposure level?

Now you know, that's a great point. A lot of times we have as requirements security and developers like we don't know what that means. So yeah, is that like OWASP or is that.

Like something you can use as a code sniffer to say, hey, there's a security issue in your code?

I think a lot of people approach it that way. A lot of people approach security as they're features you add to the code and they miss the fact that security is about exposure and value. How much do you expose yourself and how much is your stuff worth? If your stuff is not worth anything yet, security is not an issue. If you're not exposed, it's not an issue. But this exposure and value comes from a lot of different things. And the code is not actually the first place to tackle that. You really have to understand where the issue is. And we still see that in a lot of breaches that come out today. We have companies where people don't understand the value of the stuff that's being leaked out. They just haven't protected correctly even though their system seems secure. They've got the passwords, they've got the encryption and stuff and it's like yeah, but you fundamentally missed some of the aspects that you're supposed to watch.

Absolutely. And along the same lines of exposure and value, you also talk about risk and value. So like how to prioritize. So they may have a list of security and all this other things. So how does someone know? I guess you mentioned one thing is risk is how to prioritize. All these definitions of done teams need to get to do while they're coding.

You know, Yeah, I, I did the quality assurance for like seven years. I was working on that and the, the impact. So risk and they have the counterpart value. Risk and value, we both call them impact. We don't want to just have the negative risk side. Coming up with this value is one of the very difficult things to do in software development. But this is the one you actually, you need more input. For example, the value side's easy to say if you, if you're working and you're trying to sell new software, you can literally ask salespeople and you basically say how much is this actually going to sell us in the next months? And if you can get a dollar value, that's really great because it's like this absolute value. Whereas risk is something like you kind of have to go like you ask some of the admins and you can ask sort of like the management. It's like, okay, we have this issue, we might expose data. Yeah, it's unlikely. But how bad would this be if it actually happened? And trying to calculate that's difficult. But these are kind of the extremes. At the lower level you can roughly calculate a lot of things, like a new feature. Well, this has positive value for the customer. And you can just use simple levels like low, medium and high. And risk, you can have like, well, the user might lose one record out of a million. Fine, that's like a low risk. And if they lose half a million records, okay, this is a very high risk. And so it's. I don't have a definite way to do this and I think it's. I think you would actually go wrong if you had like specific steps. But I think you have to consider all the aspects, the actual dollar value, the actual PR value, the actual value to the users to get both, to get the impact score, both the risk and the value.

And I guess it goes back to your main point, communication. You really can't find this about communicating with a bunch of different people or stakeholders on your team.

Yes, it is all about communication. And as I say, I want to point it out in the book a lot is because I think it's an aspect a lot of people miss. And this isn't just from the programming side. I think a lot of the other teams kind of miss. This too is like how important this is. And the reason why prioritization comes up is because there's like an infinite list of things to do on any project and it's always going to be the case. And you actually see animosity develop sometimes in a company when people aren't working on ones that other teams are waiting for. And I think the problem there is that people don't understand that there is this infinite list. It's not like there's some programmer just picking and choosing at his whims. If there is a prioritization system in place, somebody is trying to kind of give an idea of like, well, these things that have good impact and motivation is part of that impact. Right? You can't deny actual human quality there you have a team that's fundamentally waiting on something really, really, really wants a feature and they're all going to go home sad if they don't have it, that's actually significant risk not to have it. And so I think there's a lot of things to consider there.

Absolutely. I work in a large company. A lot of times a team is waiting for another team to create something or deliver their version of something that we need to interact with.

Yes. And I think people ignore that as well. Sometimes it's like people are waiting, people want feedback and you have to actually cater to the people, even if it's not always directly in the favor of the end user. But having demotivated people is also terrible.

Yeah. And a lot of times what feeds into that issue also is estimates. So a lot of times people aggressive, yeah, we're going to be finished. And they don't realize they have these dependencies on these other teams. So any, any feedback or tips on how to. I'm terrible at estimates. I've been, you know, doing automation for 20 years and I still can't do it. So any ways to get better?

I think that's the general consensus. You cannot estimate. It's never going to happen. I mean by mean estimate is that somebody says, hey, can you do this? I'm sure you can give a ballpark estimate. You could say, yeah, this is going to take a week or two weeks and you're going to be plus or minus a week on that. As you get more experience, you can get more estimates. But fundamentally, unless you have very concrete little specifications, you cannot estimate how long high level features you're going to take. And I think that's why the trend has always gone towards this sort of continuous development. Let's just make sure we always have a product that's usable. Because we can't reach arbitrary goals in a fixed period of time. That's just not going to happen. And I'm still surprised that some people still want that. I get that in freelancing. Sometimes some of the guys come up and say, hey, can we get, we have this list of features. Can you tell us how many days each one are going to take? And you really have to communicate with them. It's like, no, I can't. But the goal is to always provide something of value. And I think part of estimates come from this is actually, I think from the freelance world is people are working with freelancers and they're missing the communication thing. So people run off for two weeks and they come back and the people are totally dissatisfied. And whereas if you actually communicated the whole time and continually showed that there's a product here, continually showed something of value, then people are actually okay with it. But it's this sort of hurdle to get over that's like, well, I don't really know what's going to come out, but you know something good is going to come out.

If someone had a really deep knowledge of algorithms, would that be able to help them better in estimates? To say, I know the problem, I know what algorithm could probably fix can solve this problem. Therefore I'm able to estimate better if.

The problem actually involves that algorithm. And I say that because programming. I get that question. I actually got it last night at a presentation too. It was like, yeah, but I really know algorithms. What algorithm should I know? And let me honest, when we talk about algorithm, as I talk in the book, 99% of programming problems are not algorithmic problems. They're higher level than that. If you do have a problem that involves an algorithm, if you have a chance, you have to know the algorithm and how to use it. If you want to have a chance of estimating it at all, your estimate's still going to be bad. But if you don't know the algorithm, your estimate is going to be even worse than a guess.

So, so it's interesting, a lot of people I speak with, they spend literally a year or so in boot camps learning all kinds of algorithms so they can pass a test at Google or Facebook. And you said only 99% of the time do you actually would apply an algorithm. So how useful is knowing that type of information? Is it more just showing off or is it really practical all the time?

I'm going to put a slight sort of disclaimer what I said. I think there's classes of algorithms and I think at boot camps and stuff, if you're learning basic algorithms, and this include things like loops and how to use searching and how basic sorting and stuff works, I think these types of things are essential. You may not ever implement searching, but I think you have to have an idea of how some of it works. But as you get to the more complex algorithms, as you get to things like pathfinding and document categorization, like actual analysis type algorithms, these ones come up very rarely. I've been fortunate in my career to actually work with many of them, but I've always had to learn specific ones for the field. It's been very rare that I said, hey, look, oh, I already know an algorithm. It's always like, no, you're going to learn something more. The more you know in the past, the easier it is to learn new ones just because they are similar. But there is, I Think a fairly clear line between like the basics and then like the things we're calling algorithms in a day to day practice.

So there any resources or books you recommend someone to learn those basic algorithms that they can apply to say their automation architecture or test code frameworks?

I haven't seen comprehension lists recently.

I'm trying to think of and I actually have a hard time putting the basic list together. I actually, I wrote an article last week about basic list operations you should know and in a sense that's algorithms, but they're the basics and that's a fundamental list you should have. And that list is online, but that doesn't really go into any algorithms in terms of actual algorithms for sorting and searching. I actually wouldn't recommend spending time on that. I think a big area right now is more about system design and I think I find more people struggle with that than worrying about algorithms because I think system design is a bit, bit more like open. Whereas algorithms, I think there are books, you can pick them up, you can learn them. Actually there's a lot of websites, I think this is probably the best one. There's a lot of websites where you can just code algorithms for fun. There's the game sites where they've gamified everything. There's lots of those. You can get levels and I think for learning random algorithms that's the best way to do it. It's fun and you get to check yourself and there's just a whole random assortment.

So this question's out of left field, it's not covered in your book. Just curious to know. Just popped in my head. A big discussion in automation lately is AI and how AI can help create more robust automation tests because it's able dynamically to help identify elements and things like that at runtime. Do you see this type of trend also within the coding aspect of normal development with AI? So maybe you don't have to know all these algorithms because pretty soon we'll have AI that'll be able to handle that type of lower level information automatically.

No, I don't see AI as putting a big impact on programming. I'd be curious as to how much it actually does in testing as well. Because the types of things that AI can do are things that are very repetitive, very sort of following a very basic template. And these are things that often, at least in testing don't give you the highest sort of value. You want the highest value of people that are thinking outside of the box, thinking like a user. And so far we've seen absolutely no AI that can think like a user. I've seen no indication of AI being able to do any level of programming. Like even the ones like if we take like AlphaGo, an impressive piece of technology for playing Go, but if you look at the way it worked, it basically watched millions of Go games and played millions of Go games. It's like, well that's great. But it's such a well defined set of criteria. You can just go to any freelancing site for programming and we don't even have any AI could make sense of like a two line description of what the guy would want.

That's a good point. So once again, communication AI really can't communicate to know what a user really wants? Maybe yes.

And I mean, and I always say these caveats with the AI is like, I don't think it's there and I don't think it's going to be there for a while, but I would absolutely welcome it because there are a lot of tasks and programming where it's really like, oh boy, I get to do another database record entry. It's like, I really wish something would do that for me. I don't think anybody will lament the loss of some of that boring work. And I think we're just waiting for it because then we can focus on the higher level stuff that's more important stuff.

So another thing I've seen so you know, we talked about people, code. You have a bunch of things on code. The other thing is you the piece of the category of you. And one thing you brought up is imposter syndrome. For some reason a lot of developers have imposter syndrome. Can you talk a little bit about why that is or what do you mean by imposter syndrome in the you section of your book?

Okay, so imposter syndrome first is this idea. Somebody comes to a job and suddenly they're overwhelmed with the feeling that they can't actually do the job. They've been given something and they suddenly doubt themselves to the point like whoa, why did this person give me this? I can't do this. I'm not right, I can't do this. I'm just not going to be able to do this. And they get started this panicking mode. The effects are very different in different people. And when I wrote the book I wanted to come up with a stat and I was actually shocked by the fact that 70% of people actually experienced this to some degree. And I think it's important even people that don't experience to understand that people go through this, there's. I tried to find. I really tried to find explanations of why this happens. And I couldn't find any sort of psychological studies saying exactly why. So I can only kind of speculate as to some of the reasons. And I think the one is basically experience. You just haven't done it before. And I think everybody does it. The first time you do anything, you get. You get nervous. And in the programming area, it's really like you're supposed to be producing something of value very fast. So there's this massive expectation placed on you as well. And it's like, oh, I don't know how to do it. And this guy's expecting something and this all seems complicated. And you're also sitting in a room where everybody else is diligently working away, producing stuff. And so there's all this pressure building up on you. And I think that's the pressure and the inexperience about doing this and the new environment as well. And also, as we talked about the algorithms, you learned all these algorithms, suddenly all that stuff you learned, you're like, hey, I can't apply any of this, but so what am I doing here? And I think all this comes together to give one this imposter syndrome, making you doubt yourself.

Have you seen that interfere with someone on an interview? I know you have interview tips in your book as well, where maybe in the back of the head they're like, I'm a fraud. I don't know when they're being interviewed.

I think it would definitely play a role in interviewing. And when I do interviews, I really try to make an atmosphere such that they don't have to worry about small things. I'm one of the people that says, look, I don't care if the syntax wrong, we're not actually going to compile the code. So just don't worry about small things.

But it's still very hard. You'll still see that. But I think that's part of the purpose of just doing lots of interviews as a biggest form of practice, to get to the point where you are confident that you actually do know this stuff. And interviewing does have a tendency to create stress, especially in person, in the office, all these people watching you. It's a very similar situation.

And I think it's one of those things you just have to get over. And some people, I know I said in the book is like their interviewing skills, and some people say it's like, oh, I just have to get past the interview. But the reality is we're going to get back to that people section I talk about too, is that it doesn't actually end with the interview. There's pressure and people watching you. It doesn't actually end there. So I don't actually think it's unfair the way interviews are done. I think you actually have to deal with this pressure to some degree to be successful at the job after the interview.

Interesting. So is that one reason why you think people do whiteboarding during interviews, to add some sort of stress, to see maybe how you. How you deal with stress?

I think some people do and some people don't. Some people just do whiteboarding because they want to see code. And it's just. They get. The social aspect is sort of an additional bonus. And some people intentionally do it. And for example, in my requirements, I intentionally give ambiguity my requirements to see how people address them and talk about them. And I think approaching this, there's a lot of research done on the interviews, how you do these things. And I think the social skills do have to be brought in more to see how people deal with it. And the whiteboarding, I think. I don't think that was the intention. I think the whiteboarding intention was just to see, well, let's see them design algorithms and stuff, not necessarily to put them under stress, but to see the code. And I think it has that added sort of benefit. See what happens when they're thinking. Unfortunately for some people, they. The stress gets so high that they just stand there frozen and can't. Can't do the coding then.

So any tips to get over the stress that you have that you've noticed has been just, do you acknowledge it and just work through it, or.

I think you do just acknowledge it. And the one I noticed the most is that people that are the most stressed are the ones that are missing the most basics. And that is. And that's why I wrote this list last week about all these basics you should know about your language and how to work with lists is that I find when you stumble on a basic, it's like if you're speaking English and you've suddenly forgotten how to use the word the you're going to stumble over everything you say, and it's going to just compound and make it really bad. Whereas if you have all the basics of lists or one example in your vocabulary going into the interview, you have this confidence threshold. It's like, look, I'm not going to screw up a basic for loop. Because in an interview, when you screw up a basic for loop, even if the interview doesn't care. The interviewer is like, yeah, shit happens. We'll move on. But you, as the interviewee, you're like, oh, God, I got something so basic, so wrong. It just totally throws you for the rest of the interview.

Absolutely. That's a great point. How do we measure our progress as we're going along to make sure we're not becoming obsolete on an older technology and we're adapting to newer ways of.

Maybe developing how to actually measure that? I think I didn't have a good answer in the book either. How do you actually measure it? And a lot of it has to do with, like, the way you feel yourself is that if you. You don't want to bias it towards people skipping around, like, you have to learn all of this new technology, because that's not helpful. But at the same time, if you stick with one technology forever, it's also not helpful. I think one of the ways to measure progress is that can you keep up with new technology? If you actually sat down and read a new technology, how quickly could you understand that that's a good measure of progress? It's like if you're doing web development and you've done like full stack, for example, just ignoring the technologies, how far advanced you are in that could probably be measured in. If I threw you down in front of a new tech stack, how long would it take you to be able to do something with that? Or would you be overwhelmed? And I found generally that people that are really experienced in the one technology do pick up the next one really well, whereas people that have been stuck to sort of stagnate and become obsolete have a really hard time picking up new things just because they haven't. It's not necessarily been kept up, but they haven't been triggering those neural pathways to make sure they can learn new things if you get stuck in a rhythm. So I think progress is basically if you're not challenging yourself a continuous basis, if it's not like at least a couple times your week going, like, I don't know how to do that, then you're probably not making progress.

No, I've written a book, and a lot of times, you know, I discovered things as I was writing. So as you were writing this book, did you actually, as you were, you know, thinking about, did you have, like, a revelation? Oh, I never thought of that. And if you did, what was that?

Oh, I think I had that at numerous places in the book, because as I was doing the book, I first wrote my experience, and then I said, for all of these things I want to double check, look up research on this stuff. And I think it was virtually for every chapter. It's like, you know, I never actually really thought about that. Or that actually helps me clarify. That brings it together quite nicely. And so specific examples, I don't think I have them because I think it was really like every chapter in the book, I actually looked up something like, oh, that's interesting.

Okay, Erica, before we go, is there one piece of actual advice you can give someone to improve their programming efforts? Let us know the best way to find contact or get our hands on your great new book, what is Programming?

All right, so my biggest point of advice is just keep trying through new things and don't get frustrated. Go out and push your limits. Pick up some new technology and try it. Even if you don't use it, you'll be amazed at how much you can actually learn from it and apply to what you're already doing. If you need to learn a whole new area, I have my book. You can grab this on Amazon. It's where it's offered if you want to get in contact with me or follow me. I'm on Twitter and also on dev2 and I also have my website, which you can subscribe to.

Thank you. Adequate for your programming awesomeness for leaks to have the value we covered in this episode, head on over to Test Talks.

And while you're there, click on that Sign up for a free trial link under the exclusive sponsor section to learn all about Sauce Labs awesome products and services. So that's it for this episode of Test Talks. I'm Joe and my mission is to help you succeed with creating automation awesomeness. As always, test everything and keep the good. Cheers.

Thanks for listening to the Test Talks podcast. Head on over to triple W.TestTalks.com for full show notes, amazing blog articles and other automation awesomeness.