Logo

Software Developers Journey Podcast

#267 Steve Upton from adversarial relationships with devs to QA in high performing teams

Resources

Highlights

1. Initial Steps in Quality Assurance (11:30)

Steve Upton began his career in **quality assurance**, which proved to be invaluable to his later work in software development. The process of **building things well** from the start, with an emphasis on the **end user**, resonated deeply with Steve. He mentioned the importance of understanding the need for **software to work for the user** rather than just technically functioning. A valuable lesson for junior developers is the focus on the **end result and usability** instead of just meeting technical specifications.

2. Agile Methodology and Whole Team Approach (17:28)

Steve shared insights into the **Agile methodology**, emphasizing the **whole team approach**. This implies everyone, from testers to developers, understanding the entire product and each one's role in it. Steve highlighted that there is a **strong interdependency** between development and testing; neither exists in a vacuum. Junior developers can learn the significance of **communication and collaboration** within teams, ensuring that everyone is on the same page and understands the bigger picture.

3. The Continuous Pursuit of Improvement (21:14)

There are always new and better ways of doing things in the world of software development. Steve stressed the importance of always looking for **improvements and optimizations**. He mentioned how a slight change in database design improved the product by **reducing the number of bugs and improving performance**. Developers, especially juniors, should always **remain curious** and open to feedback, always striving to enhance and evolve their skill set.

4. Importance of Testing (25:58)

Steve dived deep into the realm of testing, indicating its essential role in ensuring software quality. He elaborated on the **agile testing quadrants**, a framework that allows developers and testers to understand **what kind of testing** is required and when. For junior developers, understanding the significance and methodologies of testing can be crucial. It’s not just about writing code but ensuring that the code **serves its purpose without defects**.

5. Overcoming Challenges with Teamwork (30:49)

Working in a team can bring forth several challenges, especially with **communication gaps and misunderstandings**. Steve recounted an incident where his team had different understandings of a product feature, leading to avoidable issues. He underscored the **value of regular team check-ins and open dialogue** to preemptively address potential problems. For newcomers to the field, grasping the art of effective communication and the importance of **shared understanding** can be pivotal.

6. Recommendations for Aspiring Developers (44:08)

Towards the latter part of the discussion, Steve provided some invaluable resources for those looking to delve deeper into software development and testing. He recommended seminal books such as "Continuous Delivery" by Jess Humble and Dave Farley, and "eXtreme Programming" by Kent Beck – emphasizing not just on code quality but also on **team collaboration**. Furthermore, he highlighted "Agile Testing" by Lisa Crispin and Janet Gregory, which takes a deep dive into the agile testing quadrants. For junior developers, these readings can offer foundational knowledge and **practical insights** into the world of development and quality assurance.

Enjoyed the Podcast?

If you did, make sure to subscribe and share it with your friends!

Post a review and share it! If you enjoyed tuning in, leave us a review. You can also share this podcast with your friends and family and share lessons on software development.

Become a supporter of the show. Head over to Patreon or on Buzzsprout.

Got any questions? You can connect with me, Timothée (Tim) Bourguignon, on LinkedIn, per email, or via my homepage.

Thank you for tuning in!

Transcript

⚠ The following transcript was automatically generated.
❤ Help us out, Submit a pull-request to correct potential mistakes

Steve Upton 0:00
A couple of books I can I can I can usually recommend to basically anyone, not just people kind of looking to get into sort of testing and quality, continuous delivery by Jess humble and Dave Foley is is a classic, I think just a really, really foundational book for a lot of things. Extreme Programming is a fantastic book that really, I can also look, it's not just here's how you write good code. But here's how you work together as a team, the book, agile testing by Lisa Crispin and Janet Gregory. That's where the agile testing quadrants are explored. I don't necessarily agree with everything in the book. But I do think there's a lot of good stuff in there because it focuses on the whole team approach. And, and and, again, just things can be better. It's about understanding that there is a better way, there is another way.

Tim Bourguignon 0:49
Hello, and welcome to developer's journey podcast, bringing you the making up stories of successful software developers to help you on your upcoming journey. I'm your host team building on this episode I received Steve Upton. Steve is a principal quality analyst at ThoughtWorks. He works to build empowered teams capable of delivering and taking ownership of quality. He's particularly interested in complex socio technical systems, and how we work with them, but also in complexity theory, building quality into culture, and testing as part of continuous delivery in modern distributed architectures. That's a hell of a program. Steve. Welcome.

Steve Upton 1:32
Hello, thank you very much for that lovely intro.

Tim Bourguignon 1:35
Who wrote this? Who could possibly say, yeah, it isn't a lovely intro. I know. I'm glad we're gonna get into this authentic part of this other evenings. But before we come to your story, I want to thank the terrific listeners who support the show every month, you are keeping the Debjani lights up. If you would like to join this fine crew, and help them spend more time on finding phenomenal guests, then editing audio tracks, please go to our website, Dev journey dot info, and click on the Support me on Patreon button. Even the smallest contributions are giant steps toward a sustainable dev journey. journey. Thank you. And now back to today's guest. Steve, as you know, the show exists to help the listeners understand what your history looked like, and imagine how to shape their own future. So as is customary on the show, let's go back to your beginnings. Where would you place the start of your debt journey.

Steve Upton 2:38
So the very first line of code I ever wrote was on a Sony PlayStation two. So a lot of I know a lot of people kind of start their careers on things like Commodores and some of those old you know, home computing and and, and games consoles. But the, in Europe, the PlayStation two was shipped with a demo disc, and it had some couple of little games on it some short video clips, you know, showing off the PlayStation two. But if you scroll down to the very bottom, there was a an option called your basic, which was yet another basic. It was a little BASIC interpreter had some a few tutorials in there. And I discovered later that the reason that this existed was so Sony could get around import taxes in Europe, because if they sold the PlayStation two as a general purpose computing device, then they paid less tax than if then if they had sold it purely as a games console. So technically, I think I owe my my my first my first step in my journey to becoming a developer to tax loophole. It's fun.

Tim Bourguignon 4:00
That one on the show.

Steve Upton 4:03
Hopefully that is a new one. Yeah, I I have never met anyone else who's whose first line of code was that. I've I've talked to a few

Tim Bourguignon 4:11
that didn't even know you could do that. I mean, spend some time with PSU but never even look there. Yeah, I

Steve Upton 4:18
think I think I when I when I when when when me my brother first got our our PlayStation two, we obviously got a game with him. We played a lot of that. I think at some point I had finished that game when I decided to see what this little demo disc had on it. And I didn't really have any prior exposure to programming to software engineering, and I just went in that's I did the obvious thing that hello world. I found that pretty interesting. And then I actually remember the very first program I could say that I wrote it was it was a little purely purely text based. It asked you for your name. So I invited my brother in obviously to test this program for me he wrote in his name, my name is Ben. And then it replied, with a random insult, including your name. And it's like, Hi, Ben, you smell or Hi, Ben. There's something something something right. And it was called insult, or this is why I called it the insult or was it wasn't particularly advanced. But, but I remember this, this just this incredible feeling of empowerment. In doing that, right. Even though I had typed out that whole thing using literally a PlayStation two controller. I didn't have a USB keyboard at that point. Yeah, I know, right. So the whole day, it took me like an afternoon to write this thing out. But I just I just remember this incredible sense of empowerment that it wasn't just that I was using this, this, this this this system, this computer, and obviously, I used computers and systems before I was telling it what to do in a way that I just I never experienced, and it was, yeah, I think that really started my, my dev journey.

Tim Bourguignon 6:00
Wow, that's a thrilling one. And being able to insult someone with a button, that is always good. So do you have any idea that developing could be something for professional career at that time? At that

Steve Upton 6:17
point? I don't think so. No, to be to be very blunt, I, if I if I if I look back, I'm trying to remember, I tried to figure out like, exactly when was this? I must have been about 11 or 12. So I wasn't really thinking super actively about careers in programming at that point. And it didn't really go much further than that, if I'm gonna be honest, I, there are a few other demos with some slight kind of 3d graphics and things like that. But I kind of I mean, I had a PlayStation two and I was a teenager. So like, I went back to playing games, of course. But when I, when I got a little bit later in school, and I saw a programming course come up, shortly before I had the option to go to uni. I jumped on that. I was like, Oh, I remember that. I've done that before. I'm I'm an expert on that now. And that led to obviously, going well, after that I went to university studied computer science, and ultimately got my I got my first job. So it Petered out. But it was I think, still an important first step.

Tim Bourguignon 7:27
Indeed, and in any in this empowerment and realizing you can make this or you can make this machine do something for you. It's something you never forget, the first time you have it, it's really

Steve Upton 7:39
well, I think, I think I think it really, really planted a few seeds that you know, took took a while to really, you know, germinate and grow. But for me just just getting my brother in to type out his name and be insulted by the PlayStation two was was was my system, my application going live right now, it was not obviously posted on the Internet, and everyone could use it. But that was as close as you could get to going live on a PlayStation two demo disc. And I just remember this feeling that? Well, if I can do this, everything else is details. Right? Like once it's live once, it wasn't once I have got the computer obeying me, everything else, everything else I can do kind of incrementally. And that's and that's something that I've seen a lot with, with my more recent work with in the sort of continuous integration, continuous delivery space, getting things live the value of going live, not six months down, down the road, not right before your, your your product is done. But going live. I've, I've I've I've I've to read. And that that that I think really shaped how I thought about not just how to write code, but but the whole development process.

Tim Bourguignon 8:58
That's a jump far ahead. But it definitely makes sense. Let's go a little bit to to your, the end of your studies, maybe so you have your degree in your hand. Where did you go from there? How did you decide where to go?

Steve Upton 9:15
So I in between my second and third year at university? I did, I did an internship at at IBM. Right. So just just a summer internship, which was kind of not the most let's say let's say engaging or exciting experience. I think someone just got an email one day saying hey, you have an intern like find something for them to do. And I had just a couple of little odd jobs here and there and like, Oh, could you write some code that does this? Just a little script? A few things there. And despite the fact that wasn't maybe those have the most well structured kind of kind of learning experience, I did meet some, some some good people there. I enjoyed, I enjoyed the place, I saw there was a very big company, you know, everyone knows IBM, of course. And I, so So during my final year of university, I applied for the graduate scheme at IBM. Think I applied for a few other jobs got a few got a few other got a few other offers. But to get the sort of cowardly answer here, I think I went with with IBM kind of as the safe bet there. It's a very big company, everyone knows it. And it was also a graduate scheme, which which does have a little bit more structure. That's how that's a, you know, that was a compelling thing. For me coming out of university, I wasn't super confident in my own skills, I didn't think I was a rockstar, Rockstar programmer or anything. But the idea of a graduate is gonna say they help you take those first steps. And yeah, I turned up on the first, the first day, I got given the job title, I think it was a Systems Integration Tester. So I'm officially my job title now is a QA consultants. So in that sort of quality testing space. And people have asked me a few times like, Well, how did you get into quality and having you into testing? And the answer is entirely by accident. It was, that was a decision that was made for me. And, yeah, the first the first I was I was a little bit I was a little bit off, not off put as such, but a confused by the whole field of testing, because I think in my entire university in my entire degree, that whole course, I had had maybe one hour on the subject of testing. Now, this was my full time job. So I didn't really know what I was doing. And there was some automated testing in there. So I got to kind of practice my programming skills. But I think that that that journey sort of led me to really understand testing and development in very different way. And I'm really pretty happy for that, that sort of experience that I had there.

Tim Bourguignon 12:09
Do you know or have an idea if it was entirely random you going there? Or if somebody had seen something in the way you think and say, this would be the right place?

Steve Upton 12:23
I so I asked. I, I've asked myself that question. In the in the interview process, and it was sort of a multistage interview process for the for the IBM graduate scheme. There were a lot of lot of exercises about kind of kind of thinking and how do you write emails, that was actually an interesting little exercise. They said, Okay, you have two minutes to write this email go. Which I thought was like what hanging on on you like hiring software engineers, why easy to write emails, but actually realized that they were sort of testing our ability to prioritize and kind of communicate, which was, which was, which was pretty good. They didn't really have anything in there about testing or stuff that at least what jumped out at me as Oh, that that's why they picked me out. My my, to hire? And there's two possibilities. One is it was it was entirely random. And the other is maybe I didn't score so high. And they decided to put me in some testing role rather than a full developer role. That was something that I think, you know, hung around in the back of my head for a couple of years. Yeah, I saw I don't know, I never I never. I never validated that. Okay,

Tim Bourguignon 13:29
there was some value attached to the last comment you made full roll of developer versus lower rank tester. Is that how you saw it? Like them?

Steve Upton 13:43
I think that is how I saw it. I think that was how a lot of people saw it. It's not hard to I think there is a, there is a Joel Spolsky blog post, I've I forget exactly what it is. And I remember reading it, this was around the time that I was in a that I was in just a testing role. Where he explicitly says like, you know, use your testers to do this. They are cheaper. Right? Which, yeah, so So I think I had some, some, maybe some sort of self doubt, and maybe some self confidence issues around that. But it was also my, my, my time in that role helped me understand that. Testing. Isn't that at all? One of my first Well, my first team lead in in IBM he, he taught me two really, really useful things. Same as rich cop and hate bridge if you're listening. On the very first day when I when I introduced me to the team and he sat me down and he said, Okay, everyone in this team has been here for multiple years. They're all way older and more experienced than you do. But if anything here looks stupid. Tell us tell us immediately, right? Because you have this fresh perspective. And I thought that was just incredible, right? It's something that I've been telling everyone to who's who's new to a team, right? Bring that different perspective. That was that was the first thing but also he, he helped me understand this the, the role of testing he, there was a there was a concept he introduced me to from his technique. It was originally Brian Merrick and then later adapted by Lisa Crispin, and Jeff Janet Gregory, the idea of the agile testing quadrants, that you can sort of divide tests into different types, right? Are they are they business facing? Or are they more technology facing? Are they critiquing the products? Or are they just supporting the team? And that was that was a really important distinction that I started to understand. I absolutely had no, no idea about the four before kind of working with this guy. I saw testing as it well as part of the process, you write the code, and then you test it. And that was how, at least at the start my job looked, the developers wrote the code, they gave me the the finished product or the compiled product and said, Now, test it. This was an adversarial relationship, right? If I find the bugs, I win, if I don't, if I don't find any bugs, the devs win. And this this, this distinguishing between different roles of tests like doing doing some some some exploratory testing, really clicking around trying to understand is this the right thing is this actually meeting someone's user needs is one end of the scale. But running a unit test is really there about supporting the team giving the team fast feedback. So they know that that last line of code they wrote didn't break anything. And they have very different those, those different tests have different shapes. They're, they're written in a different order, or they're written and executed at different points in the process. And that whole, I think, epiphany, and understanding, not just, oh, here's a lovely taxonomy of tests. But how does that change how we as a team need to work to ultimately deliver value and deliver quality?

Tim Bourguignon 17:21
That makes a lot of sense. When did you manage to shake off this adversarial relationship, like you mentioned,

Steve Upton 17:31
I think ultimately, I had to leave IBM for that. To be fair, there's a lot of good people in IBM, and I don't, I don't want to don't want to sort of say, say too many negative things. I had a lot of really good, really good experiences. They're fantastic learnings. But it was only after I joined the next company, after after IBM i moved to Berlin and I worked for here, the pm apps, the former former Nokia Maps. And I worked in a team that I would describe as really, genuinely high performing team. The whole team collaborated together, they they understood that the testing and quality and security and all of these things are everyone's responsibility. It's a it's a, something that we that we build and share together. And that shifted how I worked with, I was no longer the guy writing the tests at the end the sort of, you know, giving the thumbs up or the thumbs down, does it go to prod I was helping the team build in quality. And I think that was, and it was it was I think you could have had some elements of that in in IBM, but it was also tied up with very long release processes, right? You release twice a year, when I was in when I was at IBM i, I was I was involved in a release process that took almost three months, three months of of manual regression testing of integration testing of merge hell of all of this, we we borrowed people from other departments, right, just because of the sheer amount of manual process in this. And some of that is just kind of inherent to IBM's business model of releasing a big update once or twice a year. But when I was working for heroes, building a live service, we were doing continuous delivery and continuous deployment, every commit was going to production and that forced us to work in a very different way. And just yeah, that that experience was was incredibly eye opening for me.

Tim Bourguignon 19:34
Can tell us more about that. And then I'm interested in the internal monologue, the internal Steve in his mind, going through this process going from IBM, I have a release in the next six months and I know I'm going to make three months of testing and then I'll be probably preparing the next one for three months and etc. And then moving to here and realizing oh no, it's gonna be way different now. How did that go?

Steve Upton 19:57
I think so. making the move away from IBM was one of the one of the bigger jumps in my career, probably the biggest single jump because IBM was this, I think, for me a relatively safe place. It was somewhere where I had some experience, I knew some people. It because of this six month release process, while there were definitely spikes of stress around these, you know, horrible, horrible release periods. There were it was It wasn't always that high pressure. And I had started going near the end of my sort of tenure at IBM i, I started going out to conferences a lot more. I was I was based down in Winchester, in the in the south of England, I would take the train up to London for meetups and conferences and things like that. And I was starting to hear about these things, continuous delivery and micro services and all at work. So I was reading the books I was I was I was getting the theory, the big. So I kind of knew the shape of what this would look like. And I was able to talk about it. The big fear for me is whether I would actually be able to walk the walk, right? Theory and Practice are not the same thing.

Tim Bourguignon 21:15
So how did you manage to walk?

Steve Upton 21:18
Ah, I joke sometimes I just, most of my career just sort of been saying yes to the next opportunity. And I, for a couple of reasons, I wanted to sort of get out of IBM and try something new. I didn't want to be someone who was who was who just spent their entire career in one company, I wanted to get those different perspectives. So I knew I had to, had to had to leave at some point. And I just kind of picked what I also knew I wanted to move to Berlin at that point for various reasons. So I knew I had to do it. theory, theory and practice are not the same thing. But a foundation of theory can really help you with a practice. I went through I went on a blitz of reading and conference talk watching, and just throwing myself bodily at it. When I when I was in this new experience. When I was in this new team context, this new experience, I think really somehow I got through it, I'm not quite sure how keep keep trying keep trying to do the next right thing is as a quote I like.

Tim Bourguignon 22:31
Again, again, interested in how people pick you. You came from a treasure from a traditional background, they had hyper highperformance teams, I assume they had something like a premise of a high performing team. What kind of skills were you looking

Steve Upton 22:52
for? Um, that's, that's a good question. So I think the job I applied for it, here was something like a software engineering test is the is or software developer engineer, test, aesthet, something like that, you know, all sorts of different job titles. I think I, I was quite lucky to have some familiarity with some of their tech stack, which was no JS based at the time, I was quite lucky to have worked on some Node js projects at at IBM, I think I was able to walk them to to talk the talk, at least, I think there was probably one very specific thing that really, that really helped me, which was here's a Maps company right here maps, navigation and mapping and things like that. And a few I think a year or two prior to me applying i i went on a little adventure where I this is a long series of events you have to bear with me here but I had a friend who worked at a company that built GPS trackers like industrial ruggedized GPS trackers for, for like yachts and mountaineering expeditions. And I was just interested in maps, I like maps and data visualization. So I said can I borrow one of these? And to kind of wire it up to a map. Okay, so I so I built this system. So my friends could live track me on this little trip. I took a train trip from London to Marrakech, so without flying so, London to Paris, Paris to Madrid, then down to the very southern tip of, of Spain during the boat across and train to Marrakech. Have fun little adventure. I like backpacking. And I had this I had this GPS tracker in my bag the whole time and I wired it up I've done a bunch of stuff with with with the services this company offered. And so my friends could watch me live. I think I wired up a domain I think it was where.is Steve often to IO So that was fun. And then I wrote a little blog post where I kind of extracted the data, I analyzed it, I compared that track to some stuff I got from Google's location history. I was like comparing, okay, here's where the ruggedized GPS did really well. And here's where Google location history did really well, and kind of did some fun visualizations and some things there. And well, I ended up applying for to work at a mapping company. So I think, I think at some point, someone might have seen my blog post, because I ended up building something very similar to that at here. So that's, I think that might have helped.

Tim Bourguignon 25:35
Yeah, working in the open quite often. Yeah, bring back some some, some some advantages. At some point, I realized

Steve Upton 25:42
I do realize that is probably not a very, like practical and usable bit of advice. Like go, if you're looking for a job, go borrow, borrow a GP, or borrow a ruggedized, GPS tracker and go backpacking across two continents is not the most reusable device, but it works for me. So you know,

Tim Bourguignon 26:03
from the from the interview, where are the higher point of view? That's kind of things not the GPS, one, but kind of projects I'm looking for always in what I see. That's, that brings you a lot of insights about the candidates about how they think about how they think outside the box, what are they passionate about? And how far did it go for for such a passion? Can they take something from very, very beginning point zero and bring it all the way to something usable, and loopback on that, that's a lot of insight. And when you have this, you tend to look at it with scrutiny, because it's interesting, and then give you some some insights versus having somebody Well, you just have information from the discussion you just had. I have to be aware of your biases, but it is it is definitely a bonus.

Steve Upton 26:55
Yeah, I think it is a bonus. There's also there's also, I think, a negative side to that, if I'm gonna be honest, there's the idea that you hire, hire someone based on their GitHub contributions, right? You You've got to that get, it's a pretty standard thing to have your GitHub profile in your in your CV, right? You go there. And you see this big wall of contributions, lots of lots of green boxes. Well, this is someone who writes lots of code, they have lots of lots of personal projects. And as you say, that can be a give you a lot of context, a lot of more than just the conversation you have. But it also biases that that interview towards people who have that free time, a bias it biases it towards young single white guys, as I was at the time, right? It biases heavily against people with childcare responsibilities, and that's, so it's undeniably useful, but I think we do need to be careful with how we use that.

Tim Bourguignon 27:56
But what I've come to do is really, when I have this at hand, then I will use it and and ask people about it. When I don't, I will try to wiggle that in. In the discussion we will have and say, Hey, tell me about something you're passionate about. And and piggyback on that. And if you even if you'd have, as you said, childcare responsibilities and very little free time. There are some stuff you're passionate about. And it's it shows when you talk about it, and that's the hint I'm trying to get at. But you're right, you really have to be a diamond in asking and not trusting just that when there is nothing then that means there is nothing.

Steve Upton 28:37
Yeah, yeah, absolutely. Absolutely. There was there was there was also one question that I got asked in my, my interview here, which was like it was a multi multi step interview process, there was some some pretty usual, you know, pseudocode and blah, blah, blah. But one of my interviewers walked into the room, and he said, I don't know how to interview testers. If you were interviewing a tester, what would you ask? And that actually sparked a really fun little conversation. We had a really good chat about what is the role of testing and QA and how does this how does this fit? And I I thought it was a really clever question. And, and he was he was he was asking it to for exactly that reason, right to bounce things around and see where you go. He was later ended up being my team lead and, and worked really well with him. He later admitted he just genuinely did not know what to ask. Like someone had told him about this interview about five minutes beforehand. He had no preparation. So yeah, another sort of accidental good thing. There

Tim Bourguignon 29:47
was nothing Mischeif from him. That was really genuine. Very cool. Very cool. So how was it being in this software engineering tester? Software Engineering Test? In this in this team.

Steve Upton 30:02
Yeah, really fun. Like I said it started off as some sort of software engineering test, I ended up taking the role of QA lead for for that team, taking on more responsibilities like, like, defining the whole quality and kind of testing strategy and influencing sort of how the team works working with our Agile coach at the time, or Scrum Master is definitely one of those. And I got to see how everything, how all of these systems come together, right? We we heard we heard shifted from us of sort of, we're taking a scrum approach to more of a kanban approach. And seeing this suddenly how those how those processes, change things, how they, how they, how they, how they influence things, and how I, one of the things I like about having quality in my name is that it means very different things to very different people. I tend to interpret it incredibly broadly. I see quality as as as delivering value for our users, being able to adapt going forward. That's important too, if you deliver something that's valuable, but it's a big mess of spaghetti code, and you can update it. Pretty soon you're your competitors as well. And that covers a lot of things. It covers how we work as a team and how we collaborate, how we how and when and where we write tests, is just one part of that quality is not just testing. And yeah, so I I was somewhere between a QA developer, I, you know, I wrote I wrote code i i was i was on call I wrote about monitoring and alerting. I just ended up getting stuck into everything. That seemed interesting, because I could look at anything and just say, yeah, that's quality related. I should be in there. Which is probably a mistake on my part. I keep getting involved in too many.

Tim Bourguignon 32:06
You could pretty much wiggle yourself in every discussion with

Steve Upton 32:08
this. Yes. Yeah, absolutely. And I, I have been doing this for better or for worse for a while. It's the jury's still out on that one.

Tim Bourguignon 32:19
What is the full worse besides the besides you your days? I've haunt me 24 hours?

Steve Upton 32:24
Yeah, it's it's that one. Limit your work in progress is good advice. Right? If you if you're involved in everything you can't get, you won't get everything done. So so. So being aware of that is, is is incredibly important. And sometimes sometimes you just need to say no and pick your battles. I think that's that's something which I, which I'm getting better at slowly, just looking at things and saying like, Okay, I could make this better. But my time would be better spent somewhere else. Dan North wrote a blog post recently called this the rule of 63 that I really liked. He said, You walk into a problem, walk into a situation you see 63 things wrong, fix three of them. Focus on three of them, right? If 63 Things are already broken, they will continue to be broken for a while just focus on three. Get that get that done?

Tim Bourguignon 33:21
So is this is this easy? Oh, no. What would be your heuristic in choosing the three?

Steve Upton 33:29
I don't think so. That's a good question. I do have some ideas. There's there's there's there's things I think that I'm good at and and better at, right? I if if I dive into a problem that I've solved, or dealt with, you know, 10 times before, I'm probably going to be better, I'm going to have those patterns, those experiences that's going to allow me hopefully to address it here as well. So simply, you know, my how suitable I am to deal with this. Right? There might be a big, interesting problem that I have that I know is important, but I don't have the experience to solve it. Maybe that's what I deprioritize for now. I try to keep it asking the question, you know, what, what actually matters here? Right? How? Who is our user? Is our user happy, right? Are we are we meeting their needs? Because if we're not meeting our users needs, that's probably a pretty big problem. But at the same time, I also don't think I can or I don't think I should be the only person deciding what I'm working on. I think I think feedback is just incredibly important. I always have a list of things I want to do that is longer than the time I have that is that is longer than what I actually can do. So every time I do something, I ask people like, hey, last week I did these things, which of those was helpful to you? Right? Which which of those should I do more of? Which of those should I do less of right? Because I've got this big mental list of things I want to do. And every time someone gives me feedback that allows me to better prioritize that list. So I've got a few heuristics, but I wouldn't trust one person on that, especially.

Tim Bourguignon 35:14
I usually try not to bring new information in in the discussion, but there is one, you work for ThoughtWorks. Now, so at some point, you may get a jump from a product company. So developing your own products. And I assume that was the same for IBM to going the consultant way or the contractor way. I'm not sure which one which one you you must associate yourself with? What Why did you do that? And how did that go?

Steve Upton 35:39
I think I think I grew a little bit disillusioned with products was one thing, because I think I think I was working on some really over the course of my career, I've worked on some really, really interesting products that I just don't care about deeply. I like yes, this is solving a business problem for the various enterprises across Germany. That's, that's nice. And it's making money, but I don't really care about it. And that was, I think, difficult for me. I don't think you have to care about everything you. You do, right? Like, we do need money to live, unfortunately, for now. So moving to consulting, I think was was an opportunity to focus on just solving problems, right, helping people grow and helping people, helping people see that the world can be different. And I think I think I think the other the other big driver for me was, like I said, when I moved from IBM to here, I saw a new world. And you know, here certainly had problems as well. But the experience of working in a high performing team was absolutely mind blowing. For me, I got to just that collaboration, that speed, just that completely different. And I kind of see myself as privileged to have had that experience. And I want other people to have that experience. And that's part of what I can do as a consultant I can I can I can work with teams and help them experience a high performing team, that's pretty much always my goal.

Tim Bourguignon 37:12
How does it feel to be I assume, maybe the assumption is wrong, but being short terms on such gigs, getting stuff to, to getting the dominoes to start falling into place, but not necessarily seeing the end result and seeing this high performing in place. Probably years later. Well, it's really, really up to speed.

Steve Upton 37:36
So the way thought works, works. And this is this is all public we is we tend to do longer term engagements, right. So so we don't have kind of a short term, like we, we, we try and avoid sort of helicopter consultancy, right? You you hang around a team for a few weeks, present some slides and then off you go, right? Most of my engagements with with ThoughtWorks have been working with one clients over the course of usually a year, a year plus, right, okay, that's long enough to to actually start to see some impact. Not Not so long that that's just the only thing you ever know. And you still get to see those still get to have those different experiences, which was another big another big driver for for me picking consultancy. But at the same time, what you said there are still true right, some problems or some some some impacts, you only see multiple years if not decades after, after you after the choice has been made, or the choice has been made repeatedly. And that's maybe just a trade off. I can see I can see the the the impact of my decisions over one or two years, maybe not 10 In this in this line of work. And that's something has to be traded off. I had one story often tell from from from early on in my my career was was there was a there was a particular codebase I was working on at IBM and the regression test suite took over a weekend to run. Like like two to three days. And that's not a great developer experience. Okay, if you write a line of code, now, it's three days to find out if you broke anything. And what I saw that like that, that product when I was working on it was older than I was and and I got to see that sort of sort of accumulated bad decisions. So those are those learnings in that context is is is always there if you're willing to look for it, isn't it? Even if it's not your personal mistakes?

Tim Bourguignon 39:40
Sorry, you throw me off in my in my back back experiences working for giant German engineering companies kind of have exactly the same experience so

Steve Upton 39:55
shall remain. Exactly. client confidentiality is key.

Tim Bourguignon 39:59
have absolutely absolutely no. And I was I was thinking as well, I pretty much did the opposite. I only worked in contracting and consulting for almost 15 years. And then at some point went to a product shop. And one of the reasons for that was because I realized I was constantly on this on the search for betterment of my of my customers, always in this, in this tragedy, put it adversarial play kind of adversarial play against the status quo, saying, This is just impossible. And always fighting for more. And this This was on one side tiring, but it was also starting to, to change the way I see the world, we always there is a better way. And the way we do it right now is shitty. And and I say no, this, this is not not the case, like you said, at one step after the other 163 problems, just pick three. And that will be fine already to fix the three and then you will consider the next ones. And this is what I tried to find by going to a product company and say, Okay, now I care about what we're doing. I care about the people inside, I care about everything. And I care about the pace as well. And so if it's all nice freedom, it's always free. And let's go from one place to the next. But I think it's exactly what you were saying just differently. Good. No, no,

Steve Upton 41:22
absolutely I that really resonates with me, right? You're going to keep doing to keep doing the next right thing, which I think is a quote from frozen from a song in frozen. I have not seen the movie, but I've had it reference to me a few times. And yeah, change can take time. I was too. I was I was I was talking to Martin Fowler. Last year. And he we were talking about a particular kind of kind of kind of change project that we were that we were involved in not not me and mine specifically, I just happened to be talking to him about that. And I think there's a little bit of frustration on on on our side on the on the on the people kind of working on this on this, this change in this transformation, that we hadn't seen these like huge revolutionary changes yet. We'd had a few product teams, we've had a few successes. But the world fundamentally hadn't changed. This was a very big company obviously can't can't name them. And Martin just sort of turned to us and said, like, how long have you been there a year and a half, and that's fine, like change takes time. Find it, don't worry about it. And it was Yeah. It's simple advice. But it's, but it's important.

Tim Bourguignon 42:44
It isn't easy, especially when the company has been there for 20 3040 years doing stuff always the same way. pushing against the green, when after that. And

Steve Upton 42:54
it's and it's also important to remember that that things. Things might be, as you say, pretty shitty at the moment. But they're that they are that way for a reason. So understanding that history in that context is important to it, that also takes time, all things all of these things take time. Cultural change can happen incredibly quickly, if there's a disposition for it. But most changes do take time. I think understanding and and accepting that is

Tim Bourguignon 43:22
really important. Amen to that. For the advice piece, I want to go back to one of the things you said you say when you when you join here, you went through a streak of freedom books, watching talks, and really getting up to speed with this other way of doing testing. And I'd like to generalize that a little bit and say, well, somebody who hasn't been so versed in into the quality assurance, with all the facets you mentioned, and would like to get up to speed with this nowadays. There being a developer being somebody who's doing testing, whatever, but really getting to speed with what you mentioned, or what you actually started to describe of your experience at here. What would be your advice to get started?

Steve Upton 44:08
A couple of books I can I can I can usually recommend to basically anyone, not just people kind of looking to get into sort of testing and quality, continuous delivery by Jess humble and Dave Foley is is a classic, I think, just a really, really foundational book for a lot of things. Extreme Programming is a fantastic book that really, I can also look it's not just here's how you write good code, but here's how you work together as a team. The book agile testing by Lisa Crispin and Janet Gregory, that's where the agile testing quadrants are explored. I don't necessarily agree with everything in the book. But I do think there's a lot of good stuff in there because it focuses on the whole team approach and and, again, just things can be done matter, it's about understanding that there is a better way, there is another way.

Tim Bourguignon 45:07
Amen to that CD XP and agile testing. And by the way, at the time of this recording, this is the current show with Lisa Crispin. That's less than we are we just released. So this is a fantastic discussion I had linked to that as well. Steve, it's been fantastic. And it's been 45 minutes already. Oh, perfect. Indeed. So where would be the best place to find you online and continue the discussion with you.

Steve Upton 45:35
So I am on for now at least I am on Twitter at Steve underscore Upton, I mostly just occasionally tweet about politics and my upcoming talks. I probably wouldn't recommend following me on Twitter. You can find me on LinkedIn. I think it's Steve dot j dot opt in again, I pretty much only ever tweet or post about my my upcoming talks. I just in general wouldn't recommend using LinkedIn. I intend to get a mastodon at some point. I just haven't done that yet. So that can't really help you there. I've got a few talks coming up. I think there will be I think I'll be speaking at test comm EU in Vilnius, Lithuania, and big data conference, Europe, also in Vilnius, Lithuania, and probably a few others, but we sort of just finished the summer conference season. So I'm figuring out which ones I'll be Yeah, I'll be out for the end of year conference season.

Tim Bourguignon 46:36
And now people know they can follow you on Twitter and get the updates. Yeah,

Steve Upton 46:39
that's, that's, that's why you'll find the updates.

Tim Bourguignon 46:44
Awesome. Anything else you want to plug in before we call it today?

Steve Upton 46:48
I think that is all good for me. Thank you very much.

Tim Bourguignon 46:51
Likewise, fillable is wonderful. And this has been another episode of Davis's journey. We'll see each other next week. Bye. Thanks a lot for tuning in. I hope you have enjoyed this week's episode. If you liked the show, please share rate and review. It helps more listeners discover those stories. You can find the links to all the platforms the show appears on on our website, Dev journey dot info, slash subscribe. Creating the show every week takes a lot of time, energy, and of course money. Will you please help me continue bringing out those inspiring stories every week by pledging a small monthly donation, you'll find our patreon link at Dev journey dot info slash donate. And finally, don't hesitate to reach out and tell me how this week story is shaping your future. You can find me on Twitter at @timothep ti m OTHEP. corporate email info at Dev journey dot info talk to you soon