[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.
Test driven development is a well known but still underused software crafting technique. Geepaw Hill has been practising and teaching test driven development for 20 years, so he is the perfect person to talk to about it. On 17th August 2021, I did.
Clare: Hello Geepaw!
Geepaw: Hello Clare, how are you today?
Clare: I’m good, thank you! Let’s leap straight in and tell me about that name of yours. Where does Geepaw come from?
Geepaw: My name is Geepaw, my birthname was Michael. Geepaw is the initial G and the word paw. It’s short for grandfather. If you were to look at a picture of me today, you would see that I am, after all, of the grandfatherly age at this time. The name is actually not meant to be a reference to my extreme seniority and wisdom. It’s actually affectionate teasing because I became a grandfather when I was just 31 years old. My wife is older than me and her kids were nearly grown. I was presented with my first grandson 30 years ago last week.
As you can imagine, my friends and family thought that was the most hilarious thing that they had ever heard. They started calling me Grandpa, Old Man, The Patriarch, on and on it went. It eventually got shortened to Grandpa and then Geepaw. So Geepaw is actually what many of my friends and family have been calling me for a very long time.
Nowadays, most of the people who know me in the business call me Geepaw. That’s the backstory on that weird name.
Clare: Brilliant, I love it. What would you say your job is?
Geepaw: What is my job?
Clare: Yes.
Geepaw: Well, the best job I’ve ever had is being a grandfather. The second best job I’ve ever had is the one I have now. I’m a geek. For the last 20 years or so I have split my time between being a programmer of various sorts and a teacher, then eventually what I now call a Software Development Coach.
What I do is travel around and hang with various teams. I work on helping them become more like who or how they wish they were. I call that coaching and that’s what I am, I’m a coach.
Clare: Fantastic. What we’re going to be talking about today is test driven development, which people often shorten to TDD. That’s one particular aspect of how you might be helping people to do software development.
Before we get to talking about that, I’m going to ask you a question that I ask everybody, which is who in this industry are you inspired by?
Geepaw: Wow. That would be a very long list. I pull inspiration from all sorts of places. I’m going to limit myself to two. My very old friend and mentor Ron Jeffries inspires me by his persistent, annoying questioning of whether things are working and what we should do if they are not working. I find that incredibly inspiring.
Someone who is less well-known perhaps to our audience is Nyari Samushonga. Nyari runs an organisation called We Think Code in South Africa. It is an organisation that seeks to take the very poor, disadvantaged population of South Africa and train them up to be geeks. Over the last few years, I’ve known Nyari, and we work with We Think Code sometimes as a curriculum consultant.
She consistently gives me hope that I can do better. That it’s okay to mess up, and it’s okay to adjust and realise you are headed in the wrong direction and change directions. It’s more than just okay. It is, in fact, our personal responsibility to do that.
Clare: Fantastic. We’re going to be talking about test driven development. There may well be people in our audience who don’t even know what it is or aren’t entirely sure. What is test driven development?
Geepaw: Test driven development is an attitude, an approach. It’s a style of software development, not an add-on that we paste onto the old school. It’s not an after-market. It actually reaches deep inside how you approach software development to begin with. The basic idea is this: I assemble large collections of objects or of functions in order to create a shipping application. The first prima facie evidence that I’m creating the application correctly is if every one of those pieces does exactly what I want it to do.
Test driven development is an approach that says rather than make those pieces and then test them, what if you tested them – of course, the tests fail because the pieces aren’t there or they don’t work yet – and then step-by-step, add a test and change the code to make all the tests pass. Add a test, change the code to make all the tests pass.
That’s the fundamental approach. A lot of people try to algorithmize that. They say red, green, refactor. That’s good, that’s fine. That’s a very, very loose skeleton. What we actually do is try to make pieces by confirming absolutely that every piece does exactly what we wanted it to do.
Clare: Yes, so the test always comes first. First the test and then the code, to make the test pass.
Geepaw: Yes, except when I screw up, which I do.
Clare: Okay, what happens when you screw up?
Geepaw: Ah. This is such a common event that we have a name for it, ‘Over coding’, which is when you solve more problems than you have tests for.
Clare: Okay.
Geepaw: It’s perfectly natural, it happens to everybody. I’ve been doing this for 20 years; it happens to me all the time. I look at that and I’m like, ah yes, I didn’t have a test for that, and I wrote some code for it anyway. So, when I see that code, I immediately go back and backfill the test I should have written.
Often what happens is there’s seven more tests I’ve forgotten to write too. You just take your lumps and go back and make it right.
Clare: Why use test driven development? What’s it for?
Geepaw: Not to put too fine a point on it, I’m in this for the money. I mean, I do derive tremendous joy from writing software, but a lot of that joy derives from whether or not I am shipping more value, faster. This is one of what I call five underplayed premises in test driven development. The first of these is the value premise. It says if our value depends on us changing our branching logic, then test driven development will get us there faster.
Since almost all changing code is indeed changing our branching logic, that’s why I use test driven development. There’s a lot of stuff out there that suggests that you should use test driven development because you are a good person in one form or another. Either because you are a patriot or a good citizen or an artists or a craftsperson or this, that and the other. I don’t sign up for any of that.
I test drive because when I test drive, I get to ship more value faster and make my clients happier.
Clare: That’s an interesting one. I know a lot of people think that test driven development is slower, not faster. Why is it faster? Do you understand why some people think that it’s slower? Can you make the argument to convince them that actually, it’s the other way around?
Geepaw: In one sense, the objection is that if I write 100 lines of code today, in order to test drive, I’m going to need at least that many lines of code. So now I’m going to write 200 lines of code and you’re asking me to write it in a day. Have you completely lost your mind?
We call this the Lump of Coding Fallacy. It’s not looking closely enough at what you do during the day when you are ‘coding’. Really, we do three things. We do the design and typing in of the code, we do studying of code that already exists, and we do what we call ‘gak’ testing. ‘Gak’ meaning Geek at Keyboard.
We run the application and we try it and see if it works. We do those three things, and the thing is, they are intermingled during the day. We flip back and forth between them at a split second of notice. That’s why it seems like what we are doing is coding but the coding part of that is actually between 10 and 15% of that time.
That coding part is going to double under test driven development. Horror! One thinks oh my god, they are just wanting me to do more work. This isn’t going to go faster!
The other two activities however – first of all, the studying is cut in about half. Test driven development creates for us a kind of executable documentation for our code. We spend dramatically less time having to study. Then we have all of this gak activity, the manual testing, the bouncing of the server, the refreshing of the browser. We spend all of this time on these gak activities, not to mention the debugging. It’s hugely expensive, yet for most programmers half their time is probably spent in that activity.
When I adopt test driven development, I cut that down to a tenth of the amount that it was before I used test driven development.
So, the Lump of Coding Fallacy says it’s all one thing. No, it’s not all one thing, it’s a bunch of different things all intermingled through the day. It is true that test driven development increases one of those things. The benefit we get is that it dramatically reduces the time we spend on the other parts of those things.
Clare: Yes, I absolutely agree with you, but it can be something that can be surprisingly difficult to persuade people. Particularly if you move from code that hasn’t been tested and hasn’t been written in that way to code that is. It can definitely feel as though you are slowing down. It feels like you are doing more work, particularly if you are having to backfill. If you are dealing with code that hasn’t yet been tested, you quite often end up having to retrofit, which can feel like a very time-consuming activity.
Do you have any tips for helping people to feel the benefit of that, quickly?
Geepaw: Take many more much smaller steps. I find pieces that I find particularly interesting. Typically, I have to learn how to get them to a place where I can test them. Often in modern software development they are buried nine levels up the inheritance hierarchy or they are hidden behind some massive interface, all privatised and everything else. I just take them and put them some place I can test them. Then I do the backfilling against those tests.
The reason I said that test driven development isn’t a bolt on, it isn’t something I add to everything I’ve learned so far… it is a different beast. The thing I try to remind people is I don’t know the last time you learned something that was hard to learn, that was a challenge for you. Maybe you learned to cook, maybe the last time you did it was when you learned to ride a bicycle, I don’t know. But yes, you got slower, you got slower for a little bit. People are often surprised at how quickly test driven development applied delicately to an existing code base can actually help them find problems.
I tell these teams, you don’t have to test driven development, I don’t care. Whatever is right. But every time a bug gets out of the house, come to me and let’s see if we could have written a test that would have caught that bug before it got outside the house.
Over time, they tend to realise that they could have saved a lot of time and stress and brush fire if they had actually simply written that test to begin with.
Clare: Yes.
Geepaw: Test driven development is a big body of learning. One of my angry things about the trade is how we tend to oversimplify it and rule-ise everything we do. Test driven development is tricky. It takes judgement, a lot of nuance. There’s a lot of judgement calls you have to make. You’re not going to learn that in a three-day class or a three-week class or three months of experience.
I would say that to get to approximately my current level of test driven development took me about five years. Basically, I ran into a brick wall, I said to hell with this, this is killing me, I’m not shipping anything because I’m trying this thing. Then over time, I realised there would have been a way to do that, I just didn’t think of it at the time.
You get stronger and stronger, and you get to a place where it’s just not daunting for you.
Clare: Yes. I was thinking about how for some people, one of the reasons that test driven development can feel difficult is if they haven’t yet learned all of the many skills that go into being able to write a good test suite. For instance, if your classes aren’t well-designed, then you will find yourself using a lot of mocking. Your tests end up having this giant set up.
For the benefit of the less technical users, if you have a lot of bits of code that depend on a lot of other bits of code, you don’t want to be calling every single bit of code. So, you create something like a mock or a fake, that just creates a pretend version of the bits that you don’t care about. If you end up with a lot of these mocks and fakes, that makes the test harder to write, harder to read, harder to maintain.
That’s one of many skills that as you say, come with time. The ability to write code that will be testable with tests that are quick and easy to write and read.
Geepaw: Absolutely. We are absolutely in complete agreement about that. Another underplayed premise is what I call the steerability premise, which says that tests and testability are first-class participants in design. What is means is that if your design was not built to be testable, cheaply, and easily, it won’t be testable cheaply and easily. Cheap tests pay off. They pay off well.
Very expensive tests don’t pay off very well. The answer? Change the design so that I can get cheap tests, is one that is very hard for people to understand if you are not a coder. Think about the parts of your car and imagine that I had to test all the parts of my car. There’s an electronic ignition system in my car that has 40 inputs. How am I ever going to test it unless I hook it up to a live car? That’s a real question. The answer is the same answer they use in the trade. They actually have a fixture in which they set that module with a bunch of knobs and switches and various things that they can use to control those 40 inputs, to set up specific situations and prove that the electronic ignition actually fires at the right rate, at the right time.
Clare: I have heard people argue that is one of the reasons they don’t like test driven development, that there are lots of parts of modern code design practise that are there really to facilitate testing, rather than to facilitate efficient code. Therefore, they say, they find that test driven development impacts the design of your code negatively. Because then it can make your code harder to understand, and more unwieldy because it’s been built purely for the sake of tests. What would you say to that?
Geepaw: Really? Because I don’t believe that. I simply don’t believe it. I’ve never seen it. I’ve never seen a testable design that was less easy to understand than a non-testable design. First of all, right out of the box, I’m going to say yes, I don’t believe that. But let’s say it were true. Am I getting anything else from those tests that is worthwhile? If I am, then I’ve got a cost benefit analysis I have to do. If I’m not, then to hell with it.
In point of fact, I can demonstrate that cost benefit analysis to you pretty easily. The first time I keep you from shipping something that brings down the entire mid-Atlantic power grid. The first time I prevent you from having to wake up at 3.00am in the morning because your beeper went off. You’re going to see that actually, that investment was a pretty sound investment.
Clare: Yes. One of the really simple things that I noticed that you’ve already touched on, is that when I am testing every tiny bit of my code, and when I’m writing those tests in advance, I can very quickly think okay, this is how I am going to know whether this works or not. This is how I’m going to check if it is working. I can check every tiny little bit of logic and I don’t have to wait until everything has been put together.
When I’m doing test driven development, I can find out straight away, does that logic do what I think it was going to do? Yes, it does, tick. In milliseconds I can discover the answer to that question.
Geepaw: Absolutely. Although it is commonplace to believe that most software problems are some sort of incredibly obscure, multi-threaded rocket science, most of them are dumb little mistakes. Places where you thought you told the computer to do x, but what the computer heard was to do y. Very often, they are one-liner fails. Everything else in the code base works except that one line. It’s too bad we didn’t have a test around that one line.
Experts suggest – and this is old data as of 2005 or so – they were suggesting that a third of all shipping errors are off by one. You were meant to count to two, but you actually counted to three, or you counted to one. Test driven development never lets an off by one error get away from you.
Clare: That’s really nice. Okay. So, let’s say I’m thinking I would like to learn how to do test driven development, maybe you don’t even have a job as a software engineer yet, or barely. How can you start to learn how to do test driven development?
Geepaw: The stock answer will get you through Chapter Zero, which is: go find some of these kata videos and do the kata. Walk through some cases that were prepared precisely to get you to learn some of these things. But that doesn’t get you very far. If you took what you learned from that kata and tried to take it into your code base, you would create a nightmare. I’ve seen that.
What’s next? Well, there are people out there like Liz Keogh and people like Emily Bayes. There is Joe Rainsberger, James Grinning, Jim Shaw. All of these people have long, extended conversations in their material about serious, real-world programming using test driven development. So, there’s a constellation of stars out there. That’s your next step. Go find somebody who is going to be a North Star for you, to help you orient. Just get sucked into it. You would be amazed at what hardcore professionals will throw out casually, as if everybody already knew that. You’ll be like, Oh my god! That never occurred to me. That’s the next level.
If you want to get serious with an organisation, changing your team and stuff like that, to be honest with you, you should do something that very few organisations do, which is go find a mentor and pay them to come mentor you.
I’m sorry that the state of our trade is such that that is a forbidden thing, but that is the next step.
Clare: I think that gets close to what I was thinking recently when somebody asked me this same question. I was suggesting that they look at videos and do pretty much the things that you have described. Then I realised that there was one missing piece from all of that advice, which is do it with somebody else. Do some pairing.
Yes, watching a video is great but inevitably you will have questions. There will be things that if you had been there, you might have done slightly different. Which wouldn’t necessarily even have been wrong. If you have somebody there with you who is experienced and can also allow for the fact that it is not black and white, there aren’t always right answers and wrong answers… When you’ve got somebody live there with you that can have conversations with you as you go, while you do it, that makes an enormous difference.
Geepaw: It does. It’s a game changer. Then there’s even a level beyond that, which is if that person is expressly there for that purpose, skilled. Knowing the ten different ways that you can say a thing, the ten different ways you can draw the picture of it as well as the ten different ways you could actually make it work. And is actually more invested in you learning than in you hitting your deadline. Those people are gold.
Clare: Yes.
Geepaw: Without those people, I certainly would not have come to this place in the industry. It’s too bad that it’s still regarded as an unusual thing to actually go out of your way and find a mentor to help you learn this extremely difficult thing.
Clare: Yes.
[Music sting]
Clare: While I’ve got your attention, let me tell you a bit about Made Tech. After 21 years in the industry, I am quite choosy about who I will work for. Made 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. We are 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.
A quick reminder that before the break, we were talking about how one of the best ways to learn test driven development is by pairing with someone else.
Clare: What problems do you encounter when trying to encourage or persuade people to adopt test driven development?
Geepaw: Well, nowadays the biggest problem I have is simply that they… I’m going to get in trouble, aren’t I?
Clare: I don’t know what you’re going to say.
Geepaw: They don’t know how to programme. It’s hardly surprising if they don’t know how to test driven development. In the 40 years I’ve been in the trade, since 1982, incredible revolutions have happened that have increased the demand beyond anything anybody has ever conceived of as occurring in a 40-year period.
Revolution number one is the price of physical computing. From 1980 to 2000 it dropped so low; you got a computer on your watch. You got a dozen computers inside your computer. You’ve got computers in your light switch, computers in your TV, computers everywhere. The cost of physical computing has dropped so low during that stretch.
It gets even worse, because from 2000 to 2020 the cost of distributing software has also gone. It has skydived. The two things have created a marketplace that is in such incredibly desperate need for people to programme, that it brings them in, it gives them a three day orientation, typically making them watch some stupid videos that have nothing to do with the day job. Then it shows them where the pointy end of the compiler is and sends them over the wall to fight the bosh. That doesn’t work. That’s the first thing.
The second thing – that same demand has created a marketplace of crap. People who can print four-colour brochures and give you rules and have great PowerPoint and sweettalk people who actually don’t understand software at all. It’s the demand that has pulled these people in. I’m not saying they are all hucksters, a lot of them are just incompetent. In general, the pedagogical aspect of the software trade makes PT Barnum look like a man of upright integrity.
Clare: Okay, interesting.
Geepaw: I told you I was going to get in trouble.
Clare: I think one of the things is that there is always just this rush, rush, rush to meet deadlines. This idea that the quicker you do things, the more effective you will be, the more money you will make. It’s very hard for people to acknowledge that actually, you will go faster if you go slower. You’ll go better if you go slower, you’ll have fewer bugs and that makes it worth it.
It’s hard for the people holding the purse strings to acknowledge that, and it’s hard for the people whose job it is to do the work to find the confidence to say you know what? We’ll do this better if we move more slowly.
Geepaw: The truth is that of course, geeks love to hate on managers. But look at the next two or three layers of manager above the floor, and what you’re going to find is that they have actually been cared for and mentored and trained almost exactly as much as you have. Which is to say, not at all. It’s hardly surprising that they don’t know how to help you. They take the simple speed map for granted.
Most of that reasoning is based on a model that what you do is lay bricks, but in fact, what we do when we write software is more like juggling bricks. People who say that of course have to have a lot of weight and authority in order to convince anyone to accept that reality. I happen to be one of those people, so I’m lucky in that respect.
People say it’s very hard when you’re at the bottom of an organisation. Let me tell you, it’s very hard at the third level, too. It’s hard up and down the game, the whole trade is suffused with a bunch of broken models and half-understood bad, physical world metaphors. It’s inch by inch, step by step, that’s all you can do.
Clare: Yes. Okay, talking a little bit more about the actual practices, the nuts and bolts of how you do good test driven development. I know one of the things you like to do is push code frequently. Can you talk about why that is, what the benefit is of that?
Geepaw: Absolutely. I’m a trunk based developer. I do not advocate using branches at all.
Clare: I’m so glad to hear that. I agree one hundred percent. I quite often have to have that argument.
Geepaw: Yes, I’m big on that. I push from head, I test from head, I do everything from head. One of the challenges that we see is that we try to take on steps that are too large. When I say too large, if we are talking about programming, I’m talking about three days. Three days is too large. Typical cycle time for a push, I’m working in Kotlin, that’s obviously part of that, it’s very expressive and compact as a programming language. I’m good at it, I’ve been doing this for a long time, so that is part of it too.
My cycle time varies between 10 minutes and half an hour. Once I get past half an hour, my stomach hurts. I get panicky. If I make it all the way to 45 minutes, I just revert. That’s the kind of cycle times that I’m talking about.
Why do I do that? Because it keeps me from breaking everything else in the universe, which is incredibly important. Our model of programming has this idea that there is a finished jigsaw puzzle with all the pieces in perfect shape. That you first get a problem description and then you create that puzzle with all the jigsaw pieces. That’s not actually true. What is actually true is that most work in software development is not adding new pieces but changing the pieces you’ve already got.
Because you’re afraid to make that change, what you do is create a branch, you take a bunch of big steps out on that branch and then you try to bring that branch back in to the main body of code. The reason that doesn’t work is because although all of you out there are extremely lovely and attractive individuals, you are not that bright.
This problem is extraordinarily difficult, and you cannot possibly hold it all in your head.
When I use small steps like this, I create for myself interruptability, for when a dog starts barking or the spouse comes out, or my colleague has a question, or my boss calls a meeting. I create steerability, because if I’m all green and you change the subject entirely to go in a different direction, I don’t care. I’m all green. We can go anywhere you want. I give myself repeated, frequent doses of dopamine. People love to talk about how it’s human. This is dopamine, I’m talking about drugs, I’m talking about abusing substances in the workplace. Every time I get to the green bar, I’m like a rat pressing the food pellet lever. I got a pellet! I got a pellet! It’s enormously motivating and energising.
The fourth thing it gives you is grockability. The smaller my step, the less I have to think. Again, people want to talk about humans, but they don’t want to actually look at the reality of human bodies and human biology. Bandwidth, the number of intellectual balls you can juggle, is for most of us between four and six at a time. Our performance doesn’t degrade steadily when we go to seven, eight, nine, it dives to the ground. We get extremely slow and make it very much harder for ourselves.
When we take smaller steps, we can understand what it is that we’re changing. That is of spectacular benefit for us in terms of productivity.
The catch for those four huge benefits is this: You’ve got to plan for that. That is to say, the collision between limiting the size of the stride and getting a whole new screen up on your app, you can’t do it. It can’t be done. You are going to have to take it in little, tiny steps. I can just keep pounding steps all day long, get my dopamine all day long. I will actually improve your application faster than if I took larger steps that were more in line with the direct, immediate increase of user value. This is really hard to get across to people.
The problem is that old reasoning that is so common is based on a silly model of the world that exists in exactly one place, which is two-dimensional plane geometry.
Clare: So, if we talk about a vertical slice of functionality that might ultimately be the reason that you’re making your tiny step, because you’re moving towards as small as possible, but something that is going to be visible to the user, that’s going to make a difference to the user experience. Are you still happy to package up your tiny steps into something a bit larger, that might be the thing that you’re delivering, if you see what I mean?
Geepaw: I certainly carry around an idea of what is on the horizon, of what that faraway step actually would have been trying to achieve but I can’t get there in a straight line, and I won’t try to get there in a straight line. I get there by taking little, tiny steps, each of which gives me a dose, and doesn’t send the user experience backwards. Now we’re moving out of code and actually more into the story level when I say this. When you actually get this across to people, it turns out to be pretty easy to solve the sorts of problems that they encounter. They weren’t looking for those solutions before. Now that they look for them it’s like, ah, they’re everywhere.
So, we talked about cycle time being very short. I would advise a team to have a story cycle time of one team day and a half. No story should take us more than a day and a half to implement. Again, by our modern standards, that’s an extremely tight, limited stride for a step.
The trick is not to try to add all the value at once because when you add all the value at once, you’re also going to be adding all the risk at once. Must better to distribute the risk and the value in slow accretion of the ultimate desired functionality.
Clare: Yes, fantastic, thank you. There’s one question which I really want to ask you, which I’ve noticed from following you on Twitter and from looking at your website. I don’t know how long this has been true, that you preface everything you say with Black Lives Matter, which I love. Can you tell me a little bit more about that?
Geepaw: I started doing that about three and a half years ago. Every one of my major Twitter muses has a statement at the beginning, right after the header, introduction Tweet, and another one at the end about that.
One of the things that we see is how easy it is to focus all of our attention inside the monitor. Believe me, I love geekery so much, but for me there are more important things than code going on around us. My friend Ron will often introduce such a session with a similar Tweet to mine. Except he casts around about the things that are upsetting him this week. I think that’s great; I have no problem with that.
For me, I live in the US, the most horrific thing I see in the US today is how we treat our co-equal citizens. I know that there are other, extremely bad things that we do. Things I would also like to change. But I decided that the thing that I was going to try to draw people’s attention to and get them to pay attention to… Look, Clare, you’re looking at me, your listeners are listening to an old white guy. You’re looking at an old, white, American computer geek born in 1960. I live better than most kings and queens you’ve ever read about. So, I have a place of position and privilege from which I can maybe point out that there are more important things in the world than me.
For me, the issue that has struck most fully in my consciousness is the extraordinary rationalisations we use to justify what is frankly, oppression. Right here in my country, right here in my neighbourhood. That’s why I do that.
Now, I should say, that’s not enough. I should also say that I do other things too, that are in support of that exact thing, more than just a couple of Tweets. I should thirdly also say that’s not enough either. I’m aware of all those things. Any time I can get somebody to say you know what? This guy is supposedly a programming expert, and he actually cares about the world, I call that a win.
Clare: Brilliant. Brilliant. Okay, I’m going to move on to the questions that I ask everybody. The first one, and this is just a little game really, I’m going to ask you to tell me one thing about you that’s true, and one thing about you that is untrue. If listeners want to know which one is the true one, then they have to subscribe to our newsletter. The details will be published in the show notes.
Geepaw: Okay. I have no formal education in programming computers, and I do not have a college degree at all. That would be one. Another one is that I take a four mile hike every day.
Clare: So, you’re a fit old white man, healthy, well-exercised. One of the interesting things is that the autodidacts are often the best educated people, the people who teach themselves. Partly because they often have this feeling that everybody else is ahead of them and they need to catch up. I listened to a lovely podcast with Alice Goldfuss. Have you come across Alice Goldfuss?
Geepaw: Yes, absolutely.
Clare: She was on a podcast that interviews people about their careers, and how they got to where they’ve got to, specifically developers. She didn’t have a degree and was self-taught. She describes a scenario where in one job, she was trying to decode stack traces and she was looking right down at the machine code level. She was trying to work out what this error was telling her. She went off and taught herself how to read machine code level stack traces in order to understand what the error was and to debug something.
The reason she did that was because she assumed without asking anybody that everybody else must already know how to do this because that’s probably what they got taught at university, right? She felt behind, she felt on the back foot, she wanted to not look stupid. So off she went and taught herself this thing and then discovered that nobody else could do that!
Geepaw: Right.
Clare: So, she was teaching everyone else how to do it. But that feeling that everybody else is ahead of you can actually make you push yourself harder than anybody else ever had.
Geepaw: Yes.
Clare: So, to end on a high, what is the best thing that happened to you in the last month or so? It can be work-related or non-work-related, it doesn’t matter.
Geepaw: I’ve had an awful month. Just this morning, someone Tweeted me, someone DM’d me to tell me that they had started a geek friendship thing. I wrote about this the other day. One way to get really strong at programming is just to get a bunch of friends together who are all geeks and who are all actual friends. Hang out once a week and talk. Show code, don’t show code. Debug, don’t debug. Show something you are really proud of, show something you are really disgusted by, whatever. Just associate.
He was telling me that he had done so and that he was having an absolutely fantastic time with his group. He found it really motivating and exciting, and he said it was only because I told everybody to do that that he decided to try it. I wrote him back and said first of all, that’s terrific, and aw, that just really makes my day. That just really makes me so happy to hear that. Any time I actually manage to touch somebody and get them to try a thing and they like it, that makes the whole game worth the candle.
Clare: Brilliant. Where can people find you, and do you have anything coming up that you would like to plug?
Geepaw: I don’t have anything to promote right now. You can find me in two places. Geepawhill.org, G E E P A W H I L L dot O R G is my blog. It has tons and tons, about 300 blogs about topics as varied as test driven development and refactoring and how do I slice stories, and what I call the subject of harvesting the value of change. Which has everything to do with code, but also everything to do with process and everything to do with changing the world and all of that stuff.
Most of those blogs were written live action, improvised on Twitter, where I am again @geepawhill. I Tweet virtually every day. I talk about lots and lots of things which don’t have anything to do with our trade in any simple, direct way. I talk about music, I talk about art, I talk about politics. It is not safe for work. I also do what in effect are the blog and podcasts that you will find at geepawhill.org.
You can always reach out to me at either location. I love hearing from people. I guess that’s it, I guess I’ve run out of steam then. That’s how you get me.
Clare: Fantastic, thank you so much.
[Music Sting]
Clare: As always, to help you digest what you’ve just heard, I’m going to attempt to summarise it.
Test driven development is about writing tests and then writing the code that’s needed to make those tests pass. It allows you to ship more value faster. It’s important to understand that coding isn’t just about writing code, it’s also about designing code, reading code, and testing code. Test driven development increases the amount of code written, but dramatically reduces the amount of time reading code and the amount of time manually testing code.
Applied to an existing code base, it helps you to find problems. In general, it allows you to catch bugs before they get out into the world.
It forces you to build code that can be tested cheaply and easily. But test driven development isn’t simple. It took Geepaw about five years to reach his current level of proficiency.
If you want to learn test driven development, you can learn by watching videos, by reading about real world problems solved by test driven development, by practising with katas, but most of all by pairing with an experienced practitioner.
Test driven development is more effective when you push code frequently, ideally every ten to thirty minutes.
Trunk-based development allows you to work in small chunks and merge frequently. Larger chunks and less frequent merges increase risk.
Finally, Black Lives Matter. Don’t focus all of your attention inside the monitor.
That’s not all, stick around for extra content.
Clare: Every other episode, this last short segment will be devoted to story time. Storytelling is useful for teaching, for unlocking empathy, and for creating a sense of shared connection and trust in your teams. I love telling stories to both children and adults. I’m actually a lapsed member of the UK Society for Storytelling. So, the plan is that I’m going to be using stories to illustrate various points about effective software development.
This story is about a sneaky, two-faced coward. It might be a conspiracy, it’s probably a miscarriage of justice. The victim was an unfortunate boy called Robin Gray. I was 12 years old, and Robin Gray was a boy at my school. I had a massive crush on him. He lived on the same street as my friend Kirsty, so I was really excited to get invited to her house for a sleepover. The most exciting thing of all was that Robin Gray posted a letter through Kirsty’s door, for me!
I was so happy. I started following him around. I started waiting for him outside his piano lessons. Then disaster struck. He told my friend Sariah to tell me to please leave him alone. I was devasted and furious. How could he lead me on like that, only to dash me cruelly on the rocks?
I started carving ‘Robin Gray is a sneaky two-faced coward’, into every desk I sat at. It was a big school. I didn’t think he would ever see it. Then I got hauled out of my math’s lesson by an irate Head of Year. Why was I bullying poor Robin Gray? It was impossible for me to explain. So, where was the miscarriage of justice?
Well, at least a decade later, I told this story to some friends. They asked me about the letter, which wasn’t signed, it was just a piece of paper headed, ‘For Clare’, with a big heart in the middle. Kirsty insisted it was from Robin.
Now, H J Burlingame, who was a magician a hundred years ago once said, ‘We easily believe what we ardently desire to be true.’ My friends worked it out instantly. It wasn’t from Robin; it was a joke played on me by Kirsty. Sigh.
So, what can we learn from this? Well, first of all, don’t believe everything you are told. Also, never assume that people are impervious to insult, no matter how much you’ve believed they’ve harmed you. And insults shared in public will generally find their way back to the recipients, even if they are not present when you share them.
If you are out there, Robin Gray, I am so sorry.
Jack: Hi, I’m Jack, Made Tech’s Event Coordinator. Working in the public sector means that at Made Tech, we really care about making a difference. 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.
Today’s advice comes from Chris Wilson, one of our Client Principals, who has some advice on how to be kinder to the planet. That means using your bike more. Chris, do you want to tell us a little bit more about that?
Chris: Sure. We used to be a two-car household. Having three children and a dog meant that we were always dropping off at nursery or school, after school clubs. Since lockdown, one of our cars has just sat on the drive gathering dust. Some of those horrible green algae that attacks your car if it’s parked for two long without a good clean.
We’ve made the decision now to just have one car. On occasion though, we’ve needed to be in two different locations at the same time. This is where my bicycle has come in handy. So, I bought a trailer for the children to sit on and be able to be towed by my bike. It comes in handy to use sometimes to use for nursery and school drop offs. However, my four-year old has since outgrown the trailer, so the dog goes in there with my youngest if he needs to. I bought this thing called a tailgater, which is like a metal pole that connects a small bike to my bike. I can now tow my four-year-old along on his bike.
Not only have we reduced our carbon footprint, but it’s also doubled up as being good for my health and wellbeing, being able to get out on the bike. But towing somebody else does mean you have to make that little bit more effort up hills.
Jack: How do the little ones find it being on the back of the bike?
Chris: They love it. Sometimes my youngest falls asleep in the trailer, which makes for interesting viewing for anybody walking past us, his head slumped into the trailer.
Jack: He’s fine, I swear!
Chris: Exactly.
Jack: Lovely stuff. Thank you very much, Chris, for taking the time.
Chris: No problem, thank you.
[Music Sting]
Clare: And that’s the end of another episode. If you are 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. Speaking of which, thank you to C J Wilson, who particularly recommends the podcast for people working in the public sector.
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. 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 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, Carson Rob 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
