How To Get Into Software Without A Degree | Max Mumford

Introduction

Claudia: Welcome to the Waddyado podcast, where I sit down and speak with professionals, having honest conversations about their careers, how they got into them, and advice for those looking to follow a similar path. But most of all, telling you, the listeners, what it's really like to do that job. In this episode, we speak with Max Mumford, lead software engineer at the Fintech startup, Flow. Max talks about his unconventional entrance into software engineering, the importance of collaboration and and communication in software engineering, and key resources that helped him gain the experience needed to succeed in his career. There's some great advice in this podcast if you're looking to get into a software engineering career through non conventional routes. I hope you enjoy. Well, Max, welcome to the What Are You Do podcast. It's an absolute pleasure to have you today.

Max: Thank you. Nice to be here.

Claudia: So let's get us started with the very simple question of how would you describe what you do for a living to someone who isn't in your profession, perhaps a grandparent or someone who may maybe just not in your field?

Max: Good question. So I am a lead software engineer, and what that means is I'm kind of halfway between team manager and halfway between coder. And what coder means is I basically write code in order to create, business software. So, some coders make websites, some coders make software that you install on your computer. I make software that helps businesses run better, basically. Love it. Brilliant.

Getting Into Software Engineering Without A Degree

Claudia: So you had a little bit of a nontraditional route into the sector, and I would love to dive into it a little bit more. So, obviously, you did a degree in business administration at Reading. Is that right?

Max: Mhmm. That is right. Yeah. I don't know how you got the info, but it's bang on.

Claudia: LinkedIn is a great resource, guys. You know? You're lucky you're lucky to actually have it up to date ish. Good stuff. So how did you go from wanting to do a degree in business administration to pivoting into the world of software and coding?

Max: Tell us the story. Yeah. So quite an interesting route. I actually it started more when when I was around 16. Believe it or not, I was actually quite artistic when I was a kid.

I used to do, like, antique artwork and some oil painting, stuff like that. When I reached the age of around 14, 15 I think 15, I thought, okay. Let's try and sell some of this stuff. And at the time, the Internet was kind of new ish. And I thought, well, obviously, you're gonna sell it on the Internet.

Right? So I just started building websites, taught myself how to build websites, and very quickly, the art just kind of died. I just I got addicted to, the the coding side of things. I loved how you could, just sort of tap away on the computer and then just magic into existence this whole product, and pretty much anything that you wanted to make, you could make. So, I I got addicted to that very quickly and, kind of kept it going all the way through college, and then all the way through university as well.

In university, it was a really great source of income. I found a little software com software company sort of half an hour drive away from my student digs. And I was working with them for pretty much, I think, two and a half years. Managed to clear my overdraft, came out of university in quite a good financial position. And, yeah, it just went from there, really.

I think the job opportunities were good after university. I thought, you know, I can either go down the route of sort of graduate programs in business management, or I can do this thing that I really love doing. I can get a job easily. At the time, I got an opportunity to move to Brussels, so I did that for a couple of years and went from there, really. Awesome.

What Resources Are Best For Self Taught Software Engineers?

Claudia: I love that. So I'm guessing so pretty much you're self taught. Right? So what resources did you use in order to gain the skills to become a software engineer?

Max: I'm gonna be honest with you. Google. Like, this is this is one of the great things about this industry. It's, you really can't just jump in with 2 feet if you want to. If you're interested, you can you can just get going on your own. All you need is a computer.

So, you know, there's just so many resources out there to teach you pretty much everything you need to know in this industry and get you up to a good standard, so you can go and start looking for jobs. A lot of people go a slightly more structured route. Everyone's different, you know, that that works for a lot of people. So, you know, people do, what's called a boot camp course. So that might be like a 3 month course.

Maybe it's intensive, you know, full time, and I'll take you through all the practicalities right from the beginning to becoming a sort of, you know, someone who who knows more or less what they're doing at an entry level. So, yeah, boot camp courses are getting more and more popular nowadays. You can go the route of, just online courses. So there's lots of, very structured courses online, which will take you through a particular syllabus that you can choose. Myself, the route I took was a bit more haphazard.

I kind of just when I when I encountered a problem, I just googled it and found articles. The kinds of people who make software, I don't know why, but they tend to like to write articles that share their solutions. So, you know, anytime you you come up against something that you can't solve, 9 times out of 10, someone else has been there before, and you can we'll share this share their information with you. So that's really nice. There's quite a good community community of sharing knowledge, in the software engineering industry.

Claudia: Love that. So it sounds like there's a real community for people to share all of their issues, and people document it, which is pretty cool, to be honest. And so can you recommend any of these communities or any specific places to go to?

Max: Yeah. The big one, is a website called stackoverflow.com. Every developer will know it. Literally, every single developer will know. It's kinda like a question answer message board. So you encounter a problem, you type up your problem, people submit their answers. So yeah.

Pretty much every developer will have a login stack overflow. But there are you know, it's the Internet. Right? There's communities for everything. There are forums for every language under the sun.

Every sorry. Every every, coding language under the sun. There's forums for different frameworks, you know, everything you could you could push forward. Awesome. And so you've obviously been in the software engineering world for about 10 years or so now.

Is that right? Something like that? Yeah. Maybe even a bit longer. So I don't really wanna count.

So what would you say are the best parts of the job? Best parts of the job, it has to be being able to be creative. The feeling of solving a problem is really quite addictive. So, I think there's a big, like, there's a big crossover between people who code and people who are into online gaming. Online gaming is notorious for, like, hijacking that dopamine section of your brain.

And I'm I'm pretty sure coding does the exact same thing. You know? You encounter a problem. You tackle it head on. You figure it out, and then you get this hit of dopamine when you fixed it at the end.

So it's very rewarding. On the technical side of things, it's very rewarding. You get to be creative as well because with software engineering, there there often is no single right answer. You know, there's a 1,000 different ways to solve a problem, and each one has its positives and negatives. So you get to be quite creative from that respect.

You can if you're sort of looking at it from a more holistic perspective, you can take the user into account. So maybe you know a bit of psychology, you can put that to work and apply those concepts, in a way that gets a better user experience. If you are more interested in graphic design or the sort of aesthetic side of things, you can work in that capacity as well. You know, you can work some branding in there if you if you're interested in that. So, yeah, you can be creative.

And then, of course, on the sort of people side of things, it's very collaborative. If you, depending on your company size and your organization, it can be very collaborative. So if you're working with a in a team, you get to work with different people, leverage their skill sets. If you get to a management or leadership position, you know, you get to teach people, which is really rewarding. And so what would you say are the most challenging elements of being a software engineer?

Probably the first couple of years. I it's a bit like banging your head against a brick wall for for 2 years or so, at least 2 years. Sometimes I really don't know why I started and and, like, followed through. But, well, I do know it's it's the it's the joy you get when you finally solve that problem. So one of the weird things about software engineering is that you have to almost change the way you think, and you come at things in a in a much more methodical, structured way.

And that crosses over into a lot of other areas of your life, which can be really useful. But it's it takes a while to get to that point, and can be painful. So I guess the tip here is to persevere through the really difficult time because you'll come out the other end, and you'll hopefully find that solution. Yeah. Absolutely.

Brilliant. And so can you talk us through maybe a particular moment in your career where you felt something was particularly pivotal? Yeah. I had a few, I would say. So, after I lived in Brussels for a couple of years, I came back to the UK, and I started freelancing.

And it was hard work. You know, it's very difficult to build yourself up in a freelance perspective because, you know, people have to trust you with a lot of money. There's a lot riding on the projects. Particularly if you're relatively inexperienced like I was, you're making quite big decisions, which have pretty big ramifications on your life. And if they don't go well, then it can really hit you quite hard.

So I actually I did that for a couple of years, and then I had an opportunity to switch to contracting. And it was completely the ball game. You know, you're going into an existing business. You're coming in as somebody who has a very, particular skill set, and the business is often already running. They have their proven business model, so you don't have to deal with any any of that, uncertainty or risk.

You just deal with the technical side of things. And that was nice. You know? It was nice to have that change, a bit of, you know, more regular income, more money, obviously, if, you know, from the start because to get to a similar position on a freelance side of things, it would just take a long time and a lot of effort to get there. So I think switching to to contracting was a big change for me, and it was, yeah, financially very good decision.

And so what practical steps would you advise to those looking to follow a similar path to go contracting in software engineering? I'd say with if you're contracting, one of the biggest things you need to do is become a specialist in something. Generally, when you're hiring a contractor, you're going for someone who really knows their stuff. You know, they they have to be top of their game, come in straight to the business, and straightaway be able to, answer the really difficult questions, hit the ground running, and get things moving. So pick a pick a niche, I would say, and become really hot on that niche.

Nice. And what is your niche? Oh, so what was my niche? Because I I'm not contacting anyone. My niche was I I specialize in a particular, front end web framework called Angular.

So a web framework is effectively like a package of codes that you can use that someone else builds and maintains and makes your work a lot easier, but you still have to learn how to use it. And so, yeah, I moved into my my current position via contracting, as a specialist in Angular. I see. So did you go freelance to permanent within your current business through that route? I went so I went freelance to contracting and then contracting.

Gotcha. Okay. Great. So what is one common myth that you would like to dispel about the industry? Common myth.

I would say, probably the biggest myth is that in order to be the best possible software engineer, you have to be incredibly technical and nothing else. And I think sort of soft skills, communication skills, ability to collaborate is really, really valuable. And I think they're kind of rare to come by, particularly people who are very technical often are not so good on this sort of communication collaboration side of things. So I think, you know, working on your ability to to to, collaborate together, share ideas, have a debate that's constructive, you know, take and give criticism constructively is super important. Particularly if you're working within a team, it's so much easier to get the most out of somebody if they're also able to do all those things as opposed to just off in a silo on their own coding with no contact with anyone else.

Well, they'll often end up building the wrong thing or, you know, not communicating to somebody that they're doing this, and then someone else will do the similar kind of work, and there'll be overlap and wastage or, you know, that sort of thing. Do you know what? It's funny you say this because the there's another episode that I recorded with Ben Gorman, who is actually a lecturer of computer science from Bournemouth University. And he said the biggest and most challenging frustration that they have with graduates from their, degrees is that they are lacking in their communication skills, which are vital in today's workplaces. So what would you recommend to those who are a little bit more technical to develop their communication skills?

You know, it's funny because there's actually a lot of overlap with just the ways you have a relationship with a friend or a partner, I think. You have to be good at giving and receiving criticism in a way that's productive. You have to be, supportive to people. You have to be positive. You have to be, open to valuing everybody's, contribution.

And that I think that's actually really, really important because people sometimes people have a tendency to kind of bulldoze their way in or force their own viewpoint. But the reason you're in this creative industry is because it was the reason each of your colleagues is in this creative industry is because they have a unique perspective and unique skill set that has served you well. And the more people you you get involved, the more sort of viewpoints and different skill sets you can bring to that on the problem. And I really, really love that. I tried to, I tried to implement that in my management style.

So, while some industries management styles that work might be quite top down, I think particularly creative industries like software engineering, you try to bring everyone to the table, let everyone have their viewpoint. And then through that process of dialogue, you actually arrive at the best solution to the problem. So and that that just applies to so many areas of life. You know? You don't want a friend or a partner who's gonna just railroad you in a caught in conflict.

So so many of the skills that you learn are transferable in either direction. If you learn them in your relationships with your partner, you can also bring them to work and vice versa. Definitely. I worked with a company called Cargo 1 who essentially are a, like, a cargo, Skyscanner, in a way. So, essentially, they partner with airlines to help utilize space and car for cargo and shipping, etcetera.

And their one of their values was radical candor, and it's all about continuous improvement, which essentially was talking all around having continuous feedback loops from bottom to the top. And, you know, and I then implemented that into my business as well with my employees to ensure that there's that continuous cycle of improvement and communication. And I think, overall, it just helps with everything. You know? It opens up that communication so people can feel comfortable to talk to you and give you feedback, and then equally, you can give them feedback too.

So that's, yeah, one thing that I learned from working with them. Yeah. It's funny actually because my my my current workplace, we do the same thing. And I know that they do this. Like, they do this all over the all over the world, and it's just it just has different names and different forms.

So I know they do it in in the in the army, for example. And so we call them one of the one of the things one of the tools we use for this is called retrospectives. So, we batch up our work in 2 week sprints, we call them. And at the end of each sprint, we do a retrospective on, how things went. And one of the main one of the most important things, actually, I think, in running a team, period, is to have an an atmosphere where people feel secure to actually share their their genuine thoughts, because that it's through that dialogue process that you get to address these issues.

So in these retrospective meetings, we'll go through, and we'll talk about things that went well, things that, could be improved for next time and things that should not be done again. And like you say, it's that continuous feedback loop, right, where you gradually, fortnight by fortnight, get a little bit better, a little bit better, a little bit better, and that compound effect is massive very quickly. Indeed. Yeah. Cargo 1 again.

I'm just gonna drop it in there. We did start, stop, continue. It's Yeah. That's true. I think it's very much a similar thing across the tech industry that Yeah.

Is rolled out. And and it's a great culture thing, I think, in order to obviously have that continuous improvement. Fab. So just on that, so you obviously mentioned going through 2 week sprints. So could you talk us through what a day to day would look like for a software engineer with a couple of years experience.

Talk us through that day. Do you want an individual day, or do you want a a 2 week block? You can give me whatever you like. I don't think it's gonna be the most appropriate. Okay.

I'll give you a day. And if you wanna zoom out, do it to be blocked with you. I think Let's do it. So day in the life of a developer with a couple of years experience. Typically, you will be say you're working within a team.

You'll be working on some kind of long term project. And, typically, these projects are cut up into smaller deliverables. That process is is generally done by other people in your company. So you might have someone called a product owner or a business analyst. You might have a designer who's involved in that, someone from the tech side who come together.

They discuss what needs to be done, what needs to be built. They do the planning. They do the the design side of things. And then, I often do that collaboratively with developers as well and then hand that over to developers to be built. So typical day in the life, you will say you pick up a new piece of work.

It will be already, spec'd out, documented out, what you need to be building, what it should look like, how it should function. Often, you will already be familiar with this because you'll know all the work that's coming down the line in the next couple of weeks or even more, ideally. So, yeah, you pick it up. It's the morning. You know, often teams have something called a daily stand up.

So ideally, 10, 15 minutes a day. You chat with your team. They tell you what they're working on. They you tell them what you're working on. How is this thing progressing?

How is that thing progressing? Is there anything blocking you from making progress? What did you do on the weekend? Whatever. Then open up your laptop, open up your coding software, and, hopefully, you'll have everything you need to do to start typing away.

Usually, you'll have a version of the thing you're working on will be running on your laptop on your computer, and the changes that you make will be applied to that piece of software. So make some changes in the code, start the software, give it a test, see if it works. Gradually, you know, you work through your your piece of work. And when you're done, you, push that into the sort of collaborative version of the software so everyone has the the latest version of your work. And then maybe you will hand that over to a tester whose job it is to basically make sure that you've built what we've asked you to build.

It's good to have someone else doing that because, testers have a very unique skill set and that they're very good at understanding the software, good at thinking, from different perspectives how to break it, which is really important because if they break it, you can fix that vulnerability before someone else does. And then, yeah, if the tester gives the a okay, you can push it forwards to ship, to to send to production. So that's a very, brief, summary. There's lots of ways that that can vary. So lots of companies run their processes differently.

Obviously, if you're building a large feature that can span days or sometimes even weeks, you may be working collaboratively with your fellow developers and, you know, you might be you might be working on a small portion here, which then slots into the work that they're doing, which is quite nice. And, also, obviously, there's there's, the less happy path, which is, I don't know, you come across some big problem where you can't use this package because it doesn't do this thing that you wanted. So then you have to go back to your tech lead maybe or the or your product owner and and flag up these issues and have ad hoc meetings and go back and forth and communicate with stakeholders and things like that. So it's not always linear like that. You have to kind of think on your feet and figure out problems as you go.

But, yeah, that's generally generally what they would look like. Great stuff. Lovely. So it would be silly without me asking this question, so I've got to ask it. And I'm sure you've probably seen lots of webinars, etcetera, about it.

But how is AI going to affect your profession? I knew that was the question that was coming up. Yeah. I mean It's a really good question. If I knew, I would probably be able to make an awful lot of money right now.

I can't give you a definitive answer. I can give you my hunch. We have already integrated AI quite thoroughly into our, working processes. I use Chat GPT pretty much every single day. I use Google, like, 97% less than I used to.

You've already got Chat GPT in in some of your tools that you use to code, and it does, yeah, it does have the power to write some some pretty decent code, but it is regularly wrong, very regularly wrong. My view is at least for the short to medium term, it'll be more and more pivotal in the way that you work. And it's a bit like having a personal assistant who has just read all the documentation, but is oh, sorry. I'll run. Say that again.

It's a bit like having a personal assistant sat next to you who's just read all the documentation for the coding language and the frameworks that you're using, but is, like, quite inexperienced and doesn't really know how to apply it into the platform that you're working with. I think one of the good things about AI from a developer's perspective in terms of job security is that the contextual awareness of the platform as a whole is really lacking. It doesn't know, you know, what business use cases you have. It doesn't know what your infrastructure looks like. It doesn't know how this thing should slot in correctly to maximize code reuse.

It doesn't know that you've already got a component that already does this thing that it's trying to do. So there's lots of things it it it's very sort of focused on a very small subset of functionality. So where it's very good is solving a very small particular problem. Maybe you need to write some code using a language that you haven't written in 5 years and have forgotten. It's really good at getting you started on that.

But when it comes to the bigger picture, introducing code that's gonna be actually maintainable and understandable, it's not good at that. So you you're kind of like the steward for it. It's as if you have an assistant except for this one kind of thing. I think a lot of people can say that across a lot of professions. You know, even for example with content, you can get chat gbt to write out a content strategy, let's say.

But without the context of what you're doing and on and the ability to execute, so it doesn't really mean anything. So I think that just goes to show you still need someone behind chat gbt to help guide it ultimately. Otherwise, it's gonna create errors. Great. Yeah.

Thank you for those insights there, Max. So, let's get into the nitty gritty of cash. So how much can you earn as an entry level software engineer? So, this varies a lot, because it depends what you're making. It depends where you're located.

I would say, obviously, you know, if you're in London, you're gonna be earning more than if you're somewhere with a cheaper cost of living. If you're working to build the next disruptive bank like Monzo, you're gonna be earning more than if you're building, marketing sites for, you know, small local businesses. So it really varies. And it also varies on individual aptitude as well and the company you're working for, your ability to negotiate that kind of thing. To give you a rough ballpark, I would say for a junior who has, say, between 0 to 2 years experience, you might be looking at maybe 30 to 45 k.

For a mid level developer, say 2 to 5 years experience roughly, you might be looking at around 45 to 70. And for senior, sort of 5 plus years of experience, you might be looking at, say, 60 to 85, that kind of thing. And then for a lead, 7 years plus experience, I would say, generally. You might be looking at sort of 75, 80 to the low 100 mark. So you mean 10, 19, 25, that kind of thing.

Great stuff. Thank you for those insights. It's very interesting. And what would you say are the pivotal things in order for people to actually move up the ladder in software engineering? What what can people do in order to boost their careers?

So I think like any job nowadays, you you get the biggest pay bump when you change company. So Oh, is there a recruiter? Yeah. Yeah. Right.

Yeah. She didn't pay me to say this, by the way. Yeah. It doesn't I mean, yeah, which loyalty to a company doesn't really pay generally. You know, you may you may be you may be at a company which, I'm quite proactive with their their salary bumps, which is really nice.

So, you know, it's kind of a rule of thumb. So that's one thing I would say. I would also say there are different ways that you measure someone's performance. So, the way we've done it in the past is you have sort of metrics around technical progress. You have metrics around your ability to collaborate.

You might look at their sort of influence within the company, the projects they've taken on, the the causes they've championed. You know? So there's there's lots of different different ways to look at this. And, also, there are different routes you can go. So, a lot of people think after senior so, in terms of career bandings, after senior is team lead.

Well, a lot of people who get to that level don't actually want to manage. So often, it depends on the company, but often they'll have a different route, which is kind of parallel to team lead, but it's more on the technical side of things. So when you get to that point, it would be all about really honing in on a particular specialization and being the go to person to, to to work on this particular niche subject. So, yeah, I think it really depends on your on your particular company. You know?

You can be try to be as well rounded as possible. Maybe you, try to go and focus in on one particular specialization. I think, yeah, I think the criteria are different based on where you work, really. I think that was a good answer, to be honest. It's quite holistic and brings into account lots of different elements that you can level up into your role.

So Yeah. Okay. That. So what three actionable steps would you recommend to those looking to get into the industry then? Oh, honestly, best thing you can do is just just jump in with 2 feet.

It's such an accessible industry. You know, just just start googling. Get get a course which will take you from, in a couple of weeks, will take you from knowing absolutely nothing to putting together a very basic website. I think that's the best thing you can do because then if it's not for you, you know quite quickly that it's not for you and you can move on. But if you enjoy it, then you can start putting more more effort and more, more investment into it.

There there definitely is value in having a structured, introduction to software development. The route I went was quite haphazard and ad hoc. I kind of learned a little bit here and learned a little bit there. And I did suffer from that a little bit. You know, a few years later when I was working with people who had a computer science degree, they might be talking about compilers, and I I had no idea what they're talking about.

And it takes quite a long time to sort of get up to speed on, the bits of knowledge that I that I missed. So I think once you have confirmed you actually enjoy coding, step 2 would be getting yourself some kind of structured, introduction to the industry, and spend some time doing that. And step 3, you know, you can always, in fact, what would step 3 be? And I think step 3 would be just make something. Make something, put it online with the focus of having this as an example of something you have made for when you go and look for jobs.

I think one of the best proofs that you can give someone if you're trying to get a job as a software engineer is just show them something you built. And it doesn't have to be perfect. You know? If you say to them, look. I'm new to this.

I've taught myself. I've jumped in. I've got my hands dirty. This is what I've made. I've really enjoyed it.

I'm open to learning. I'm curious. I love the process, and I'm easy to work with and and easy to get on with them. I learn quickly, and I work hard. I think they're much more likely to, want to take you on and and invest in you and train you up than someone who maybe you might know a bit more, but could be a little difficult to work with, you know, not so good at collaborating, that kind of thing.

I think willingness to learn is, you know, overlooked sometimes from a candidate perspective, from their from their own perspective. But, actually, from a hiring manager's perspective, the willingness to learn and being adaptable and yeah. Ultimately, it will just demonstrate that you're willing to give things a go and try and you're moldable, which is exactly what people wanna see as an entrant into, software engineering or any role, really. And so Yeah. With regards to the oh, go ahead.

Yeah. No. I was just gonna say, I think, if you you can also look at things from the perspective of the person who's interviewing you. No manager wants to hire someone who they think is gonna be a real pain to work with. Right?

Yeah. You want someone who is gonna take on board your feedback, remember it, and be adaptable and be easy to work with and flexible. And I think that counts for so much. Absolutely. It does indeed.

And so with regards to portfolios, could you recommend anyone or any site that people could host their portfolios or their products that they've been playing with or building on? Yeah. So, I mean, the go to place for hosting code is a site called GitHub.com. There'll be plenty of guides on how to use it. Yeah.

That will be the place where you wanna put your code up. In terms of hosting websites, there's lots of free solutions. So, Google has one called Firebase, which is, one of the one of the services I've used in the past, which just gives you totally free website hosting. You know, I mean, you with the combination of those two services, you can get a website online for £5 a year. It's really a a cheap and affordable, and approachable industry to get in involved in.

Love that. Great. So let's get on to back on to you. Talk me through someone who's really inspired you in your career and why they've inspired you. Yeah.

So there's a chap I used to work with called, Nick Wakefield. He's a, scrum master. So not even my job position could be a different role. For those for those who don't know what a scrum master is, could you just fill us in? Yeah.

A scrum master is basically somebody who tries to get the team to work better together. So they guide you to implement processes that are effective. They, might give people coaching to figure out how they can get the most out of them. They help people, enjoy their job more, you know, make the right decisions better, that kind of thing. So, yeah, worked with worked with a colleague called Nick Wakefield, scrum master in my company.

And I think he had a really big effect on the way we worked. Before he joined, we were before he joined, we were an effective team, but there were ways in which we weren't effective. And so, he just kind of put in iterative processes going back to our discussion about doing retros, he puts in iterative processes that gradually improved every week. Every week just improved the way it works here and little bit, little too little bit. And after a while, the difference in people's day to day lives is huge.

And I think that's why I value it so much because it's not all about just, you know, can we make the company work more effectively? There's people and there's actually their day to day lives and their experience there every day that you're having effect in this way. And I think managers have that effect as well. They do have a contribution towards the lives of their team members. But one of the things I really appreciated about Nick is that he had a very pragmatic way of getting everyone to work better together and getting people to just enjoy their job already.

And how did he do that? Have to remember that. You gotta tell us now. You can't just say that he was great. We need to know the details.

Otherwise, how else are you how are people gonna learn from it? So hold on. Let me just get my notes. One second. Well, I can get I can refer back to, James Clear with Atomic Habits, which is all around, obviously, identifying small habits that you can make in order to make build build upon them each day, each week, each month, each year, which will ultimately have a positive impact on your life.

And I think that's probably a little bit maybe what you're talking about. Am I right on that? That's certainly part of it. Yeah. For sure.

But I guess that's a kind of structure that you can use in order to make those little improvements. But I think a lot of the things that Nick put in, they were very practical day to day lessons. So for example, there's a difference between the the conditions that are optimum for a manager to work in, and there are conditions different conditions that are optimum for a software engineer to work in. So for example, a manager gets the bulk of their work done during meetings, which is why their day is just meeting after meeting after meeting, and they're making decisions throughout the day. Whereas someone like a software engineer gets the bulk of their work done in between meetings.

And, actually, the meetings are really disruptive. So pretty much one of the one of the first things that that Nick brought in when he joined the company was we tried to make all of our meetings in the morning, which gave developers the whole afternoon to just get their head down and focus and have an uninterrupted block of work. Because that context switching is actually really damaging. When you're switching from one thing to the other, constantly, you lose your train of thought. And particularly in software, when you're dealing with so much complexity already, you just can't be being distracted constantly.

So a lot of things like that. He was good at helping us question the processes that were in place. I think one of the things that Nick was very keen on was don't follow processes just for the sake of following the process. If it doesn't serve you, get rid of it. You know, you can be pragmatic.

And kind of in the same vein, everybody works differently. You know? There is no one size fits all way for people to work. I personally have 2 external monitors and my laptop in the middle and a separate keyboard and a mouse, and that's how I work best. I've got a I've got a colleague who works just on his laptop with one screen and the laptop keyboard, and I just I could not imagine working like that, but it works for him, and that's how he gets the most out of himself.

So try to be flexible, try to be adaptable. Let give people the freedom, to figure out how they want to work and how they want to be most effective. And I think that also comes back to this point around everyone has their own contribution to make, and your job as the manager is to sort of set the stage in such a way that you're able to get the most out of each each individual with their own needs and specialties. Great. So what I got from that was make sure that your employees are in a state of flow or the software engineers are in a state of flow.

Challenge the status quo. If it doesn't work, then you should always be challenging and maybe coming up with a solution as well rather than just being negative and criticizing. And then, obviously, promoting autonomy as well, I think, goes hand in hand with your last point now, which is great. Okay. Yeah.

I've got one more if you want. Yeah. Go for it. We are here. Yeah.

So so something else. One of the other things that he was quite good at is I think there's often this, like, this tension between the software development team and external stakeholders. And one of the most important things to learn as a software developer, as a product owner, as a designer, as a tester, is to be able to say no constructively to your stakeholders. One of the best things you can do is just teach yourself canned phrases in order to say no to these people. Such as?

Such as. So imagine you've got, 5 things on your on your road map that you need to do within the next 2 weeks, and you don't have enough time and you're at capacity and you're stressed out. And then someone comes and then says, okay. Do this other thing as well, please. What you need to not do is say, fine.

Because something's not gonna get done. You know, you're gonna snap. You're gonna you're gonna burn out. You're not gonna you're not gonna deliver it. The best thing for everybody involved is to say is to is to learn how to say no and use one of these kind of phrases.

So, for example, you might say, that's great. I can see the value in that. I've currently got these 5 things that I'm working on. Which one would you like me to drop so I can take on this new thing? By doing that, you're you're sort of validating their viewpoint.

You're understanding where they're coming from and their the the pressures that they're feeling. But at the same time, you're also giving the the difficult decision to them, making it real to them that you have this sort of trade off in what you can deliver. And, the nice thing about that is, like, in a in a way, everyone gets to win, and and no one gets sort of too pressured. I love that. I think that could be applicable to many professions, in fact.

For sure. So Yeah. I'm definitely gonna keep that one in my back pocket. Great stuff. So, finally, obviously, you're a hiring manager right now.

So what are your pet peeves with regards to hiring, for example, CV related, when in interviews? Lay it all out on the table. Oh, I mean, oh, pet peeves and hiring. Can you give me an example of maybe something that's happened in a in an interview where you've been a bit like, oh, well, she hadn't said that. Something like that.

I mean, I I've had an interview where someone clearly hadn't written the codes that they claimed to have written. Oh, I bet that happens all the time. How did you find out? Well, I I was I was, you know, I was sort of asking her questions. We were running through, running through the code that she'd sent us, and I was asking her questions.

You know, can you talk about this? Can you talk about this? Can you explain what you did here? And she just said nothing. Like, literally nothing to the point where I thought, is this is this a language issue?

So I said, you know, is your you know, is is there a language barrier here? Wasn't language barrier. Yeah. We just you just, I don't know if she got someone else to do the the coding solution for her. I I don't know what's going on.

I actually, I noticed from her CV that she could speak French. So I I asked her in French, you know, would you rather we split we switch to French? Because I thought if it's a language issue, you'll switch switch to French, and it'll be okay. But, no. That doesn't work either.

So I think there's, you know, there's, there's being a bit ambitious and going for jobs which perhaps are a little bit too little bit, would would stretch you, but you do it anyway because that's how you grow and that's how you learn and, you know, you'll you'll get maybe if you get a job, you just learn on the job a little bit. And then there's outright lying. Yeah. I mean, you give it. You get basically, kids, don't lie.

Just don't lie in case. You will always get found out. Always get found out, especially with competency based questions where people dig in a little bit further, try and get under the hood, and try and peel it back. If you can't answer the questions, you're gonna get found out. So you just look like a tit, so don't do it.

Okay. Great. Okay. Fabulous. So, I'm gonna ask you one final question.

It's a little bit of a curveball one because I'm feeling a bit more of a fun mood today. So if you could have anybody play you in a film, who would it be? Does this have to be related to software engineering? Can it just No. It doesn't have to be a spy.

Who's that? I don't even know who that is. No. No. I Oh, a Loki Flex.

A Loki Flex. Oh, that's embarrassing. That's embarrassing. I'm not down with the kids with the lingo. Sorry.

I know. Okay. Who would be your Loki Flex then? Come on. My my Loki Flex was that I was in Las Vegas once, and I was wearing a very fancy blazer, which I just bought the night before.

And someone said I kinda look like Robert Pattinson. So I would absolutely take that. Okay. Happily take that. I think the I think it's it's reaching.

It's definitely reaching. But I think, yeah, I reckon it's the fact that you are in Vegas and you are British and male and Yeah. That probably, like, nailed it. But, yeah, if anyone want wants to actually see what Max looks like, you can find him on LinkedIn, Max Mumford. So funny, I wanna I wanna maintain the illusion that I actually look like Robert Pattinson.

You just have to to the cut the video for your hair. Well, I'll tell you what. When I was in Vegas in last year as well for a conference, I managed to get into the VIP at Sphere thanks to my wonderful client. And next to me were Ed Sheeran and Tom Hanks, so I'm just gonna drop that in there. And Cool.

Yeah. That was quite cool, and I totally freaked out. And he was really embarrassed by me, so I won't be doing that again. Say hi. You poke him in the back and fangirl.

It was like, oh, okay. I, yeah, went a bit mental. Anyway, we move on. But, look, Max, thank you so much for your time today. You've been an absolute gem and have definitely given some great advice on those looking to get into a software engineering career.

So thank you very much. My pleasure. Nice to catch up. Thank you so much for listening to the What Do You Do podcast. Whether you're looking for a job or ready to find your latest inspired hire, head over to what do you do.comforward/jobs or click the link in the description.

Don't forget to hit that subscribe button and share with anyone you think would love this episode.