[Intro Music]
Clare: Hello and welcome to Making Tech Better, Made Tech’s fortnightly podcast bringing you content from all over the world on how to improve your software delivery. My name is Clare Sudbery, my pronouns are she and her and I am a lead engineer at Made Tech.
We’re devoting this episode to our academy program, which is Made Tech’s fantastic way of teaching software development skills to fledgling IT professionals. We’re relaunching the academy at the end of January, 2022. So on the 4th of November, 2021, I spoke to Craig Bass. Craig is one of our principal technologists and he curated and delivered our academy program up to 2020, which is when I took it over. Craig has successfully set a lot of software engineers up on their journeys in this industry. He’s an expert technologist and he has the huge respect of his peers. So it’s great to have the opportunity to talk to him about our academy. Hello Craig.
Craig: Hi Clare.
Clare: Hello. So the reason I’m speaking to Craig is that Craig ran our academy program before I did. So I should also say that I am currently running our academy program, but it made sense for me to have a conversation with somebody else about it, rather than having a conversation with myself. Craig basically set up our academy and was very strongly involved and is still involved. But I am going to start Craig with the question that I ask everybody, which is: Who in this industry are you inspired by?
Craig: This is an interesting question because for me it doesn’t have an immediate answer, but when I thought about it more there’s one person that has really inspired me over my career because they were pretty close to me. And that’s Frank Amankwah. He essentially helped mentor me in practices that help teams be higher performing; so Agile, ran two London meetups before he left London, and yeah, lots of experience shared with me over the years. And the other person is Hillel Wayne. Hillel wrote a book about formal verification methods and how you can do that pragmatically in the context of software delivery. Really interesting ideas around how you can think about concurrency and how to avoid some of those defects that can crop up in systems. Really inspired by a lot of his blogs.
Clare: The last time I heard his name, he was actually mentioned by our very first guest Jessica Kerr. She also said that she was inspired by him, so that’s interesting. Fantastic, thank you. So I was just looking at the questions I was going to ask you, and I realized that there is actually one missing because I’m just kind of taking it as read that we both know what the academy is, but our listeners won’t necessarily know. Can you describe what our academy is?
Craig: So originally it was a 12 week, fully paid for, training program for individuals new to software engineering. So the idea is that we hire people with no or little experience in the industry and we train them in skills and tooling practices necessary for them to be successful in software delivery teams. The way that the academy is going is it’s used as like a headline for that kind of idea, but spread across many different disciplines. So not just software engineering now.
Clare: Yeah. Great. Okay. So what are the main benefits of running this kind of academy program?
Craig: I mean, it’s, it’s the right thing to do, right? So Maine is a kind of leading word here. But when you look at the software industry and you look at a lot of junior engineering or junior development jobs, a lot of them asked for significant experience in specific tooling or, you know, quite a bit of experience. Like the joke is that there’s so many jobs out there that are junior or entry level and they ask for like 10 years’ experience in JavaScript or tooling, that hasn’t even been around for 10 years. And that’s kind of like a symptom of a broken industry. Like there’s a problem here. Right? And I think that the biggest problem is that employers aren’t investing in training people to join the industry from having no knowledge whatsoever. They expect people to join the industry, having already known something. That’s going to favor a certain type of individual and not necessarily give you the kind of diversity that we want to see in the industry.
Clare: Yeah, yeah. And it’s interesting because I don’t think that if you’re looking for somebody who’s going to be an effective software engineer working in teams, particularly working for a consultancy, such as ourselves, that having five years of experience using a particular language or technology is not actually going to tell me whether they can do the job effectively.
Craig: Yeah. I think the idea that knowing Ruby on Rails or Node.js or React is a good indicator of being able to be effective in a software delivery team. It’s like a paradigm of thought around hiring there that I disagree with. I think that the things which are most likely indicators of success of an individual in a software delivery team are, you know, knowledge and ability to practice things like test driven development, the ability to de-risk a big project into small incremental slices. And these are skills that you don’t learn by learning a technology stack, right? You don’t learn it by learning Rails. You learn it by learning some other skills that are kind of adjacent to those tools and frameworks.
Clare: Yeah, absolutely. And you mentioned diversity and I know that for us, diversity is a really big part of why we think an academy is a valuable thing to have, and obviously that starts with recruitment. So how can we ensure right at the very beginning that the intake, the people that we’re getting into the academy, how can we structure our recruitment so that they are diverse?
Craig: So I think you can think about how you’re investing when you go to the hiring market. Do you spend your efforts advertising in all the usual places, or do you spend your time working with organizations that specifically target underrepresented groups? So physically investing in organizations that do that really well. The assumption here, right, is that if a white male wants to find the academy, they will, that will be easy for them. It’s less easy for individuals that don’t even know they want to get into software engineering or any of the adjacent skills or roles that exist in a digital team. What’s the kind of percentage of people that don’t even know that these jobs exist? And can we raise the profile by investing in organizations that focus on doing that?
Clare: For clarity we should say that when we say diversity, we mean everything. So we mean race, gender, disability, neurodivergence, experience, age, all of it. We want people who are different from one another and different from us. But it’s quite interesting because you talked about investing in those organizations that help underrepresented groups to get a footing in tech and to even find out that tech is a possibility. And I think that’s quite important because you also mentioned the idea of people who don’t know even that they want to work in software engineering. And I suppose we should say that for our academy, we do need people to have already been able to have some exposure so that they’re able to say, “Yes, I definitely am interested”, but that’s not to say that we can’t work with those organizations who are helping people to discover it for the first time.
So by using those organizations to help spread the word, then we are helping to support those organizations. And we’re helping then to help people get that first foot, because we’re not quite positioning ourselves to give people the very first foot on the ladder. We are asking them to have had exposure, but it is important that we’re not asking people to have degrees or to even have any formal qualifications, in fact. We just want to know that they have some experience of coding and they’ve had some opportunity to identify whether this is something they want to do.
Craig: And in fact, I think for the group of people that haven’t yet worked it out, many of the people that Made Tech have spent their evenings helping, like mentor these people, you know, spending time, teaching them how to write code from scratch. And some of those people have come in through the academy when they spent a couple of years mentoring. Which is kind of interesting to see, because that suggests that there’s like a step before the academy that’s also needed.
Clare: Yeah. That’s a really important point. And that’s also something that we do is that if people apply for the academy and are unsuccessful, we offer them opportunities for mentoring. And to try again and to learn a little bit more before they have another go applying. So we talked about maximizing diversity by partnering with organizations to specifically target underrepresented groups. But then of course we still have to be thinking about diversity as we go through our filtering process because we all know that we have unconscious biases and without even realizing it, a white man might be more drawn to another white man because they look like them, they feel like them. And for me, I probably may well be drawn to other white women. You know, I have to acknowledge that I probably do have unconscious biases and there’s no point pretending that they’re not there. So how can we make sure that we do the best we can to mitigate those factors while we’re filtering and going through the recruitment process?
Craig: Having a diverse group of individuals involved in the hiring the screening. So it’s not just a single person having conversations with individuals, it’s a diverse committee of individuals. I think also trying to look at people from the perspective of not necessarily the skills, but the behaviors that those people demonstrate, the ability to kind of learn over other aspects, trying to remove that unconscious bias from the pipeline. But it’s a hard, it’s a hard thing to do and it’s not easy.
Clare: It’s really hard. And one of the things that we did for the last academy is while we were going through the recruitment process was that we just kept challenging one another. So if one of us had a really strong opinion, either for, or against an individual, then we would say, but what is it, what actually is it, you know, is there a possibility that you’ve got some prejudice going on here? And can we point to evidence for why they are particularly strong or why we think they’re particularly weak? And we also, we’re going to do better on this next time actually, we only partially managed this last time, of having blind filtering so that we don’t know the names and the genders of the people that are applying. So we don’t have any identifying characteristics that might play into any unconscious biases we have. Also, while we were speaking, I was thinking through the list of ways in which people can be diverse that I said before, and now I’m bothered that I didn’t mention gender and sexuality, and there are probably other things that I missed out too. But can we please take it as read that just everything, everything is important.
Craig: Yeah, yup.
Clare: So there’s blind filtering. Um, there’s an interesting one. So we are currently in conversation with an agency who will be helping us to recruit for the next academy, and they mentioned a concept and I’ve forgotten what they called it. I can explain the concept though, and that’s, what’s important. The idea is that if you have more than one example of an underrepresented group in your pool of candidates, then both of them will stand a much better chance. If you have somebody from an underrepresented group in the pool of candidates and they are the only one then that will play into people’s biases and that will make them stand out and potentially prejudice is more likely to come into play. And so these people are saying that they consciously try to give you several examples of people from underrepresented groups. And I imagine that it’s impossible to do that completely a hundred percent, but that’s a really interesting principle that you’re effectively trying to make people, not be underrepresented even within your pool of candidates.
Craig: Yeah, that’s nice, I like that.
Clare: Yeah. I think that’s a really interesting idea and just, you know, constantly, constantly thinking about it and looking at who you have, and it’s difficult because when you’re just looking at the candidates, particularly if you’re doing blind filtering, it’s hard to know. So it does mean that you have to gather some statistics and then you have to treat those statistics quite sensitively. So you have to separate the statistics from the individuals so that you can look across your group as a whole, because you’ve got the data and you can look at the representation, but not be looking at the individuals through that lens. Okay. So we’ve talked about recruiting to the academy, but like, you know, the really big thing, uh, one of the many big things there’s a lot involved, is how do you decide what content to teach?
Craig: Our first cohort was only two people and we made a lot mistakes in trying to put together the content for that. And I learned from Ryan’s original curriculum and the retrospectives that those two people had together to kind of figure out what was wrong with the content. And essentially it comes down to the guiding principle, being the concept of constructivism instead of directivism.
Clare: You’ll need to explain those terms.
Craig: So there are two different styles of teaching. One of them assumes that you can go straight to the really hard thing and the student will essentially work to fill in the blanks because they can see it’s really hard. And so we’ll do the research to fill in the blanks and the teacher can help them out with that. The concept of constructivism is that you sort of, you build on foundational concepts. So you start with something that is going to be a core concept that other things can then be built on top of. So for example, if you don’t understand the concept of coding at all, it’s very hard to construct the knowledge of how to do test driven development or how to do refactoring, right? So you’ve got to start with more simple foundational blocks before you can actually move on to that kind of high-level understanding.
And so the academy content is kind of structured in that way. We start with like simpler concepts and then the later kind of aspects is really about trying to put all of those things together into a more advanced application of those concepts, which really to come back to kind of like normal speak, I guess it’s really about providing the experiences. It’s not about classroom teaching, like a lecture at the front with a bunch of slides and going, oh, this is this, this is a class, this is testing and development. It’s really about really minimizing those front-of-the-classroom lectures. The majority of the time is focused on helping these individuals get experience in a controlled setting. So like isolating the thing that you’re trying to help them learn and isolating it in a way that they can understand it and play around with that and really get experience with it. Because obviously later on, when they’re in a delivery team, they’re going to have all of the noise and complexity of the ecosystem around them and they’re going to be having to apply that thing in a much more advanced context. So really just trying to isolate those things and give them the awareness that that thing exists.
Clare: Yeah. Yeah. I love that. Okay. So there are a couple of things that I want to dig into. One of them was that you talked about making mistakes and as you mentioned, we learn from our mistakes. So now I’m really interested what were the mistakes that were made?
Craig: Yeah, so we, we tried to go to with a model, which was effectively understanding the idea that we needed to give people experience before they can join a software delivery team. There’s a lot of moving parts in just a single week in a software delivery team. And even trying to do that in a controlled setting is really difficult. So the mistake that we made was to try and just like create a safer software delivery team that was delivering something that was of value, but it wasn’t to any clients. So there was no real pressure that we were going to support them, but it was still too much going on. And it was very hard for those people to understand what was happening and we need to give them much, much more support. And that’s what the kind of constructivist model led us to, which is you start off with isolated things and then you bring it all together. So the last few weeks of the academy is to run a simulated client delivery where you put all of those skills together. And what we saw was that people were way more successful having spent some time, just kind of like learning some fundamentals first.
Clare: Yeah. So we’re using the concept of constructivism. We’ve decided that we’re not going to try and put them into a simulated project scenario straight away cause that’s too much. So how are we going to build up that knowledge and what are we prioritizing? Let’s say in the first week
Craig: I prioritize test-driven development over pretty much everything else. Because as we mentioned earlier, these people don’t necessarily know how to write a really complicated project, but they can at least write some lines of code and solve small problems. So we get mob programming around code katas designed to help those individuals normalize on a set of words that they use to describe things with each other. So that’s the first step because all of these people are coming from different backgrounds, different ways of learning, how to code and they’ll use different words to describe things. So just communicating with each other is, is hard. The first step is like, we want to normalize around kind of like an industry accepted understanding of what that language is, makes it easier to Google things if you’re using similar language to other people, because that’s what people use on stack overflow. And then also using test driven development as a way to facilitate that because they are learning a skill, they’re learning how to do test driven development, but they’re also learning all of these other things as well.
Clare: Yeah. So that thing about language is really interesting because, you know, I’ve been in the industry for 21 years and I still find myself joining conversations where people are using terminology that I don’t recognize. Sometimes it’s terminology that I actually have learned years ago and then just forgotten. But what’s really interesting is that there isn’t as common a language for software development as people often think. So you can have two different organizations using completely different terminology to describe the same thing. And speaking of language, actually, you mentioned two terms that people don’t necessarily know. So first of all, what is a kata?
Craig: So a code kata is a small exercise that you’re supposed to repeat and you use it to deliberately practice test driven development. Many of the catas are designed to pull out a specific part of test driven development that you need to kind of understand and really get, that will fill your repertoire of all of the different things that you’re likely to encounter when you’re actually writing things for real.
Clare: And then the other one was mob programming.
Craig: Most people think about programming as like a single individual at a computer to take that to the next level you’ve got pair programming. So you’ve got two individuals at the same computer working on the same keyboard or mouse. Then to take that to the next level, you have mob programming, which is essentially a group of individuals working around a single computer. And there’s a set of rules and stuff that you can follow to make it a structured event and not just chaos, right? That’s a skill in itself.
Clare: It really is, and actually I’m now interested because the last academy that I ran and the next one was and will be 12 people. And when I was running mobs with them, I had a specific way of coping with the fact that there were 12 of us because you’d normally have a much smaller number of people working as a mob. So I’m interested in how you structured that, cause I think you might have done it differently to me and I’m intrigued. I
Craig: I think I had it easier cause my cohorts were only six.
Clare: Ah, okay, that makes a massive difference. Yes.
Craig: But yeah, we just rotate at the keyboard on a timer
Clare: But I have seen you within Made Tech, running mob sessions with larger numbers of people. How did you do that?
Craig: So generally the main principle is that you swap the keyboard or mouse every 12 minutes or 15 minutes. It doesn’t really matter. Just pick a time and set the clock. And essentially you only have one driver at any one time that’s using the keyboard and mouse. They cannot have any opinions. So their role is just to type what the navigators tell them to do. Now, when you get into larger mobs, you really need to constrain the number of loud voices, especially on remote calls.
Clare: Yeah, and that actually is what I did with our academy. So I kind of split the 12 into groups of three actors and one driver. And then that was all circulated. So that for each group, one person from the previous group would become the driver for the next group.
Craig: Yeah. I definitely stole that from you because you know, the mobs that I’d run previously were all in person and it definitely makes a big difference. Like you don’t need as much kind of structure when everyone’s sitting around a table in front of a massive projector because all the social cues and body language is very different.
Clare: Yeah, even in person, you will get people who are more confident and louder and it’s never their intention, but they can end up dominating. By using this structure of rotating groups, it makes it easier for the quieter people to have a voice and to get involved, which I know isn’t always the most enjoyable experience for them, but it does give people that opportunity. Actually, funnily enough, talking about that, that is one of the things that is really important to me, to identify the people who have a tendency to dominate and identify the people who have a tendency to take a step back and work with them on an individual basis to look at how they can address that. And particularly with the people who have a tendency to dominate, help them to recognize that that is the case and help them to think about how they can act as allies for the quieter people and how they can help the quieter people to get more involved and to have a voice.
Craig: I used to do the same because it’s the only way to create a cohesive team environment is to get people doing that.
Clare: Absolutely. It’s interesting because what I actually thought you were going to say about mobs, which I think is another technique that you can use when you have a large group of people is to just split them up into separate groups, send them into breakout rooms, just create a set of smaller mobs, which is something I’m considering doing actually for some of the time in the next academy.
Clare: While I’ve got your attention. Let me tell you a bit about Made Tech. After 21 years in the industry, I’m quite choosy about who I work for. Main Tech are software delivery experts with high technical standards. We work almost exclusively with the public sector. We have an open source employee handbook on GitHub, which I love. We have unlimited annual leave. But what I love most about Made Tech is the people. They’ve got such passion for making a difference and they really care for each other. Our Twitter handle is @Madetech that’s M A D E T E C H. We have free books available on our website at madetech.com/resources/books. And we’re currently recruiting in London, Bristol, South Wales, and the north of England via our Manchester office. If you go to madetech.com/careers, you can find out more about that.
Before the break, we were talking about techniques he can use to help even out participation, allowing quiet people to contribute and dominant people to take a step back. Okay. So another thing that we have mentioned, and I’m guessing by now, most people will know what test driven development is, but not everybody. And even if they know what it is, I think it’s worth talking about what it is so that we can highlight why it’s so important or why you say that it’s like the very first thing that you want to make sure is prioritised.
Craig: Goodness, we’re turning into a bit of a sales pitch for TDD. I think coding within the industry can be very much categorized in a way, which essentially as a code base gets bigger and more complicated, it becomes harder to deliver features within that code base. So what test driven development gives a team is the ability to break down a big problem into small incremental steps. And each one of those tests that you write proves that the behavior that you’re building into your system, never regresses, never introduces a defect or at least a defect in a way that you have anticipated. And as you build up a suite of tests written through practicing TDD, you have this ability to change how your code is structured so that it best meets the needs of now. And that’s really key. So that’s refactoring, right? So the ability to change your code while your suite of tests is green and being able to do that really quickly, not like weeks of refactoring. I’m talking like three minutes of refactoring and then you check it in and deploy it. That ability to move quickly is very difficult if you don’t trust your suite of tests. And test room development is just one way to achieve that trustworthy suite of tests that run really quickly, that you can kind of prove that those structural changes are still okay. So mutation testing is another way to achieve that. There’s also TCR, which came back, has been talked about a lot recently. But yeah, it leaves you with, an artifact as like a byproduct, but it also helps you deliver really complicated stuff in a simple way because you never get distracted. You’re always only focused on the thing that you need to achieve to get that test to go green. So it’s almost as well, a way of taking the idea of limiting WIP at the really high-level.
Clare: WIP being?
Craig: Work In Progress, sorry, all of these acronyms. So you’ve got like work in progress at the kind of team level. We know that we should limit WIP because that’s how you increase flow. TDD is a way of limiting WIP at the kind of micro level of writing the code. You’re only doing one thing at a time and you’re laser-focused on getting that done. And then you clean up afterwards. It’s like a perfect way to kind of focus the mind. So that was a big, long ramble.
Clare: No, that was great, thank you. I also wanted something that you mentioned before, which I think is really crucial to the success of the academy you talked about after earlier academies having retros so that you could look at what went well, what didn’t go well and tweak it. Retros are something that we actually use throughout the academy. So do you want to talk a little bit about that and the, the value of retros?
Craig: You can’t form a high-functioning team without doing retrospectives and what you’re effectively building when you put a bunch of people together in an academy is you’re forming a team that is focused on learning. Running retrospectives at the end of every week, involving all of those individuals was super useful from a trainer perspective, but also to help those individuals recognize where people had a need to understand stuff and they weren’t able to understand it, or when people talk about like the struggles that they’re having, it builds trust and that trust enables people to speak candidly with each other about the problems they’re having. If you don’t have a retrospective, when you don’t have a time set aside to have these honest conversations, then what it leads to is effectively, everyone’s individually trying to work out how to learn. And they’re not, they’re not cohesively working as a team to help each other learn.
Craig: It’s like agile learning that has being experimented within the Netherlands. I forget the name actually of the people that are running that, but that was super interesting to me because it’s effectively the same model, the idea that you get students at school, working together in teams to help each other learn. So you’ve got effectively like a diverse set of people in a group, running retrospectives with each other, figuring out what they don’t understand about the content and actually acting as kind of like delegated teachers within those groups. I’d love to see that in practice within a school context.
Clare: That sounds fantastic.
Craig: But it works really well in the academy context.
Clare: Yeah, and also you just briefly touched on the idea of pupils acting as teachers. And that’s something that we also do and that’s actually, I used to be a high school teacher and that’s one of the things that I was taught during my teacher training is that if you’re working with mixed-ability groups of people, then what you do is you take the people who are more advanced and those people can change depending on what the topic is. And you ask them to teach the other people what they know. So it means that they don’t get bored. They continue to be challenged, but also it means that their knowledge and their experience can benefit the other people in the group. And it’s a really, really nice technique to usem and it’s certainly something that we use in the academy as well. Brilliant. Okay. So of course we’re running out of time because that always happens, but something that we haven’t touched on very quickly and I think actually retros partially answered this question. Maybe they totally answer it, but how do you assess progress?
Craig: Well, it’s certainly not within an exam, but maybe it should be, I don’t know. Ultimately what we’re trying to do is get these people to a point where they are able to be effective within a software delivery team. And so the simulated delivery at the end of the academy really does help assess how comfortable individuals are working in that kind of setting, because they’re all working together, and actually they don’t have a tech lead helping them out. They don’t have any senior engineers helping them out. It’s just a group of junior engineers working together to deliver against some goal that we’ve set them. If they can get that over the line, it builds a lot of confidence that they are actually able to do stuff.
Clare: Yeah. I’m with you. I’m not a big fan of exams. I think that what can happen with exams is people get focused on cramming for the exam rather than actually learning the skill. They don’t give anywhere near as much confidence as people think they do, and they can actually have a negative impact. So one of the things that we did was that we asked people to define their own goals and then we had regular one-to-ones to kind of review their progress against those goals. Another thing that we used was there’s an internal concept within Made Tech as a whole, which is the idea that you can get badges. So, you know, we have the giraffe TDD badge. The giraffe is like the most basic badge and then there’s other animals as you go further up and assessment for that is about giving a practical demonstration of the skill and having somebody else in the organization assess your progress. And the great thing about that as well, is that it gets the whole of Made Tech involved. So that will have to be my last question, I think. What’s the best way to maximize the chances of success for our academy graduates after the academy?
Craig: Right, okay. So obviously how you run the academy is hugely influential on this, so the topics that you teach, the way that you go about teaching those topics, and then also how you set them up for expecting that kind of a post academy life, all of that’s really important. But then when you think about software delivery teams, they need to be set up to expect academy engineers and how that changes, how you run a team. Like we’re not running teams of solely Lead Engineers or solely Senior Engineers. We’re running teams of mixed seniorities because our belief is that that helps tackle kind of diversity within the industry. It’s like the best thing that we can do right now. We’d love to do more. And it also helps the teams that are building digital services for citizens in the UK. It helps those digital services be built in a way that is mindful of all of the different kind of walks of life, right? You’ve got digital services that are only built by a single type of person, a non-diverse team, then it’s likely they will miss things and exclude individuals from that service. So running those mixed seniority teams is really important. And in order to run those mix seniority teams, you have to offer opportunities for learning and progress. So people need to be able to be mentored within those teams and potentially even working alongside our civil servant counterparts, having the opportunity to mentor other people as well. So as academy engineers get experience, they will find themselves mentoring others. Like some of the skills that they learned in the academy become really valuable and like a useful thing to go and help others learn. Test driven development is not a very common skill within in the industry. It really should be, but you know, our academy engineers can take that to others and like more of a peer-to-peer relationship and, you know, like a lead engineer coming in and kind of hand-holding someone which is a very different relationship, I think.
Clare: Yeah, that’s really interesting. And also again, on the topic of diversity, one of the things that I really noticed is because we have a lot of career changes, people are bringing all sorts of skills that aren’t traditional software engineering skills, but are extremely useful. It’s important to emphasize that our academy engineers are not all 21 year olds, you know. A lot at the time, they are people who have had whole other careers and have a lot of experience and maturity that is really useful. But also, you know, when you have mixed seniority teams, it’s not just about diversity, it’s about a different kind of diversity, I suppose, which is that if all of your engineers are senior, they will start making assumptions that aren’t necessarily helpful. And they will assume that each other agrees on things and understands things that actually they shouldn’t be. And when you have people who are explicitly junior in your team, you have to be explicit about what you’re doing. You have to explain what you’re doing. And often that results in people realizing that they were making a lot of assumptions that they shouldn’t have been.
Craig: Yeah, absolutely, I’ve seen this so many times.
Clare: And people learn from juniors, like you say, juniors bring in new skills and a fresh perspective and a lack of assumption and everybody benefits from that. Brilliant, ok, so tell me one thing about you that’s true and one thing that’s untrue, which is just a silly little game that we play.
Craig: Oh goodness. So I have a brewery set up in my garage, which enables me to pretty much brew anything I would like to brew like beer-wise. It’s to brew like lagers and pilsners and all sorts of other, other styles of beer. I also have a massive hat collection.
Clare: (laughs) Well, wait a minute. Do you have a collection of massive hats or do you have a lot of hats in your collection?
Craig: A lot of hats in my collection. They’re not, they’re not outsized. Hats.
Clare: (laughing) Okay. And do you brew any real ale in your brewery?
Craig: I think I basically brew beer that tastes nice.
Clare: Ok, that’s good.
Craig: That’s the important part.
Clare: I ask because I like real ale. I’m less of a fan of the lagers and I don’t even know what to call it these days, but I like the beers that taste unusual. And what’s your favorite hat?
Craig: Fedora hat, it’s got to be.
Clare: Okay. I can’t tell which one of those is true. And then almost the last question is what is the best thing that’s happened to you in the last month or so? Just because we like to end on a high.
Craig: So my daughter is starting to walk around the furniture. So she’s like moving around and it’s kind of interesting cause like she’s getting to that age where you look at her face and she’s got some really complex facial expressions, but can’t quite put your finger on what she’s thinking. So yeah, it’s a really exciting time.
Clare: Oh, how old is she?
Craig: She’s now 11 months.
Clare: Wow. It goes so fast, oh brilliant, okay. And then the very last one is where can people find you? And do you have anything that you would like to plug?
Craig: So you can find me on Twitter @craigjbass. And I think the only thing that I would want to plug is the academy, I mean, that’s, that’s coming up. It’s not my thing, but it’s definitely something that I’m invested in. I think you should go and have a look if you’re interested.
Clare: Yeah, we are gearing up for the next academy to start at the end of January, there will be links in the description. You can find out everything on our website. We’re going to be running one in January and then probably another one, not long after atall later in 2022. So if you miss the deadline for the January one, don’t worry there’s more, please do help us to spread the word because obviously the wider we cast the net, the more diverse pool of candidates we get, which is, which is really important to us. Okay, thank you, Craig, that was great.
Clare: As always to help you digest what you’ve just heard, I’m going to attempt to summarize it. Our academy is designed to hire people with little or no experience in the industry and to train them in the skills and the tooling necessary for them to be successful in software delivery teams. There are big problems with hiring in this industry. There’s a tendency to demand significant experience even from juniors, but employers need to invest in getting new people in. So what we do is we focus on attitude and aptitude rather than prior knowledge and a big component of all of this is diversity. We want to widen the diversity of the people that we’re working with. So when recruiting for our academy, we deliberately target organizations that work with underrepresented groups. And when assessing applicants we’re prepared to challenge each other on unconscious biases. We also aim to get diverse people involved in the hiring process and to operate blind filtering where we hide applicants’ characteristics that could feed biases.
Clare: And we also aim to have more than one of each underrepresented group in the pool of filtered candidates. We aim to hire people who have some experience of coding, who’ve had a chance to identify whether they enjoy it or not, but we don’t ask for formal qualifications and work experience in IT is also not necessary. We mentor those who are not ready yet and help them prepare to apply again later. As for the content we aim for constructivism, which is we build content gradually over time, rather than directivism, which would be throwing them in at the deep ends and expecting them to fill the gaps. We don’t aim for classroom teaching, that is lectures led from the front. Instead, what we’re trying to do is give them experience in a controlled setting to remove the noise and isolate the thing that we want them to learn. We don’t throw them straight into a simulated client delivery. We build to that gradually, but we do prioritize test driven development. Using tests, enables our engineers to move quickly. Other useful techniques for this are mutation testing and TCR. We try to normalize shared terminology. We use code catas to practice new skills. We use pair programming and ensemble working also known as mob programming to learn together. And we deliberately structure things so that everyone has a chance to participate. We hold frequent retrospectives. We’re aiming to produce members of high functioning teams focused on learning and we want to enable our delegates to speak candidly about any struggles they face. We encourage them to consolidate what they’re learning by teaching each other. And we assess progress via regularly reviewed goals and demonstrations to colleagues. Finally, there’s the question of ensuring continued success after the academy. We set our teams up to expect to academy engineers to join them and to participate in the ongoing mentoring of those engineers. We celebrate the benefits experienced by teams who have junior members and also those benefits brought to teams by people with such diverse backgrounds. Okay, that’s it. But stick around for extra content
Clare: Every other episode, this last short segment will be devoted to Hack of the Month, where one of our colleagues and in the future, our listeners too, will share a life or a work hack. Because this is an academy-themed episode, I asked our most recent academy graduate to give me academy-related hacks. It’s worth mentioning that we already had some hacks from our academy graduates in previous episodes, so I would encourage you to listen to Bella Cockrell talking in our Paula Paul episode about how to take good notes and also Claire Guest who spoke in our Kevlin Henney episode about not worrying about what you don’t know. But this time I’m going to read out contributions from three of our recent graduates. First of all Derek Baker, who says: “Apply as much as you learn, as much as you can. If you’ve learnt a new concept, can you apply it to any catas?” He also says: “If you can showcase what you’ve learned, do it. Teaching is a great way to reinforce your knowledge and the way you deliver a topic may help someone else’s understanding.” Finally, he says: “Ask as many questions as you want, take advantage of the knowledge around you. There is no such thing as a stupid question”.
Next, we have Zack Adlington, who first of all talks about how to get the most out of training, and he says: “Match the investment in you during the working day with independent learning in your own time. I know this will be controversial as spare time is an unevenly distributed opportunity, but it doesn’t have to be much. Truly the best thing I was able to do after a day’s learning on the academy was to review my notes, try out some code or read a book about software engineering, that Made Tech encouraged me to expense. It really helped me consolidate what had happened during the day and be ready to build on those foundations in the morning”. Zach also talks about supporting one another during training. And what he says is: “If one of your peers is struggling with a particular problem, don’t immediately tell them how to do what they’re trying to do. I know that sounds harsh. Encourage them to take a step back and think through the problem by asking questions, instead of you need to type X, then press Y. Try linking them to the page in the documentation or a tutorial and going through it together. By doing this for me, my course mates on the academy helped me build strong mental models that outlast any code I could have memorized. I also found white boarding, using tools like Miro or Excalibur, or really helpful in getting a common understanding. Frequently, I’d discover how little I really know about a topic by trying to diagram it”.
Finally, I have some advice from Duncan Carter about Imposter Syndrome and positive feedback. And he says: “One of the most important things for getting the most out of the academy and probably software engineering in general, is to get comfortable with not knowing everything. I’m sure everyone had moments in the academy where they felt others knew more than them, but with everyone coming from different backgrounds, each person had their own strengths and weaknesses. It’s important to feel that you can ask any question, and I appreciated the big emphasis on how to cope with Imposter Syndrome, raising awareness of Imposter Syndrome and giving positive feedback regularly really helps people see the value in the good things that they do. It’s easy to take things for granted and getting some positive feedback on something you’ve done can give you a real boost. Having received positive feedback really helped me on the days where I was finding the work challenging.”
Clare: Working in the public sector means that at Made Tech we really care about making a difference, so for this final Making Life Better segment, myself and my colleagues will be sharing suggestions for small things we can do to make the world a better place. Because this is an academy-themed episode, I asked our most recent academy graduates to give me academy-related Making Life Better tips. What’s interesting here is that one of them is slightly in contrast to one of the Hack tips. Which reminds me, first of all, that people are different and diversity is important, but also, when listening to advice, you always need to think about whether that advice makes sense for you, which won’t always be the case. Ok, firstly, Zack Adlington has something to say about diversity and this is what he says: “I come from quite a corporate background where often the loudest, deepest voice wins, cringe. Sorry fellow academians. Charlene and Clare helped me find ways I could amplify others and bring more of myself to work, something I’m truly grateful for. I felt that Made Tech also did a great job of hiring people for the academy with fantastic potential for all walks of life, so we were set up fantastically from the start”.
The next couple of pieces of advice come from Derek Baker, who firstly says: “The academy is very intense. Make time outside of your day for yourself, to look away from the screen and do non-code-related activities. Finding a good academy / life balance will give you a better experience.” And he also says: “Lean on your fellow academy colleagues. They’re going through the same journey as you.”
Finally, our academy graduate Ben Dalton has some wise words on how you can use an academy program to promote diversity, and Ben was able to record this one in his own words:
Ben: Our academy’s a great example of how to increase diversity in tech. I think it gives people from all backgrounds an opportunity to get into the industry. Often boot camps or training courses come with substantial upfront costs, which can exclude a lot of people who may not be able to afford those costs. Even those that are willing to learn and have a real passion for the industry. I mean, at the time of considering my career change, I certainly couldn’t afford to pay for a bootcamp. I think the academy is a great way to learn and get very relevant experience and exposure at an early stage in your tech career.
Clare: And that’s the end of another episode. If you’re enjoying the podcast, please do leave us ratings and reviews because it pushes us up the directories and makes it easier for other people to find us.
I’ve got a few talks coming up. You can see the details on my events page on Medium, which is linked to from my Twitter profile, and you can find that at @claresudbery, which is probably not spelled the way that you think. There is no ‘I’ in Clare, and ‘Sudbery’ is spelt E R Y at the end, the same as surgery or carvery.
You can find Made Tech on Twitter @madetech, M A D E T E C H.
Do come and say hello, we are very interested to hear your feedback and any suggestions you have for any content for future episodes, or just to come and have a chat.
Thank you to Rose, our editor, Gina Cady, our virtual assistant, Viv Andrews, our transcriber, Richard Murray for the music – there’s a link in the description – and to the rest of our internal Made Tech team; Kyle Chapman, Jack Harrison, Karsyn Robb and Laura Plaga. Also in the description is a link for subscribing to our newsletter. We publish new episodes every fortnight on Tuesday mornings. Thank you for listening and goodbye.
[Recording Ends]
Back to the episode
