Video details

The Varieties of Development Experience by Andrew Harmel law


For more info on the next Devoxx UK 👉
Have you ever wondered why it feels like it does to write code? Have you ever stopped and thought “if this is supposed to be such an intellectual exercise, why am experiencing so many emotions, from the heights of elation, to the pits of despair?”.
I have.
Since this first occurred to me years ago I’ve pieced together a theory which I believe gives not only an explanation for such mental states, but also offers a new means of evaluating how we work with software, and perhaps even becoming better at it.
In this session I’ll explain the theory, bringing in the latest views from neuro- and cognitive science. I’ll then consider how it can be applied, not only explaining how it feels to write code, but also interrogating why each of us has such wildly different experiences. In doing so you’ll gain a far deeper understanding of this daily activity, and consequently drive significant personal improvements.


Thanks for coming. So when I wrote this talk, I didn't realize that one of the keynotes was going to be about emotions in, well, emotions in like, work generally, and specifically, obviously, because this is a tech conference, how we might better be aware of and take responsibility for our emotions. But I'd already written this talk, and it's something that's been interesting me for a long time, because I think that emotions and how we relate to code and how we experience the active development has something really important to tell us. So hopefully via the media of me telling a bunch of stories about stuff that's happened to me in the past, I can share some of the stuff that I've been worrying about for a long time around, about how we do software, how we feel and think about software, how we react and respond to software, and maybe share some of the explanations which I've come to for the reasons why these things happen and hopefully convince you that there's something worth looking into and kind of using a similar kind of mechanism to introspect yourselves and then use that to learn to become better developers, become better players, and become better team members, et cetera. But it's not about teams. It's about individuals. So we're going to talk about that. So specifically, what I'm going to do, I'm going to tell you to begin with a story of me at Open Spaces Conference, this Open Spaces conference, which I was privileged enough to attend multiple times in a small ski resort in Crested Butte in Colorado, where I met and hung out with awesome people who are super smart and just made me feel not very smart at all. But the way I'm going to describe it is going to sound like a horrific experience because it set me off worrying about how I did development and how I wrote code. I'm then going to tell you five more stories or kind of share five more things that worried me about this, because my kind of big worry about am I doing development rights, then split up into five smaller pieces, and emotion came up in lots of those. So I'm going to talk about those. And hopefully by sharing them with you, I'll convince you that you should be equally worried, if not more worried, than I was about stuff. And then along the way, I'm going to sprinkle in a little bit of cognitive science and cognitive neuroscience, because that was what my degree is in, not in computer science, which I think pulls all this stuff back together and tells us some really interesting stuff about what is going on when we write code. And so this is the first time I've done this talk. I'd love to get people's feedback. I'd love questions. You don't need to agree with me. If I've made you angry, then maybe that would be good, because then we're experiencing emotion. But if it was a different emotion, like happiness. That would be awesome, too. So step one, though, we need to start off somewhere where we all agree with stuff. We all agree with things. Writing code is awesome. I think a lot of the folks here are here because we just really like writing code. Like the act of writing code and the feeling that you get from writing code is pretty much unparalleled. So much so that lots of us do it for free, because open source is a lot of people doing what they probably do in their day job. And then nowadays some of them are paid, but other people are back go back to their houses and their families and rest of their lives. We still write code. So to prove this, I've got a few quotes because it's always good to have some quotes to kind of back up any opinion that I might have. So this is a quote. Does anyone know who said this? It's from the 90s. Does anyone know who this is? Any? Guesses so Steve Jobs in Triumph of the Nerds. So even Steve Jobs, Uber billionaire, kind of Silicon Valley bloke at one point when he was hanging out with Steve, the other Steve, his name was Steve, who helped cocreate the first match with him. They got a buzz from hacking and all this kind of stuff. Right. But it's not just white California billionaires. We've got another quote about the experience and how it feels to code. Does anyone know who said this? Does anybody? Guess. So that's Ada Lovelace. So technically the first person like, she invented coding, right? Well, before there were computers, when she's working with Charles Babbage on the Difference Engine, she's talking about how it feels to write code. And she's right, right. Even immediately at this point, there are two things I want to pull out. Steve Jobs is talking about how exciting it is and how amazing it is to program some instructions into a computer, and then the computer does what you tell it. Age of Lovelace. Meanwhile, possibly slightly more aware of her emotions, is saying, I'm overwhelmed by all of the possibilities. There's so much stuff that's going on. There's a big weight here. It's not just an intellectual activity, and that's what I want to bounce out. That's bad. I should hold on to nothing. So there's one more quote. Does anyone know where this quote comes from? And this is what we're going to take and we're going to use this quote and kind of build up on it. No pun intended. All the way through this one's. Probably the most famous quote. And there's no more quotes after this. Let me recognize this. So it's from IBM. I think it was IBM. Sorry. Yeah, it's too early in the morning. Sorry, I should have. I thought this was going to be later in the afternoon. So apologies if anyone falls asleep. If it falls asleep, I'll summarize at the end that's Fred Brooks in The Mythical Man Month, which is another awesome set of writings about software development, software delivery, human beings, all of the pieces of work in software. And what he's talking about is something that I read this years ago, and it stuck with me for a long time because he's right. It does feel like and the reason why I think software development feels so good is because we are literally building castles in the air. I started off working in hardware. You can build things in hardware, but it's longer and slower and more physical. It's really easy in software to build something spectacular and gigantic and detailed and nuanced and subtle and powerful really quickly in software. Right. And that feels pretty freaking awesome, right. Maybe you do it for the right reason. Maybe you do it for the wrong reasons, but it feels awesome, whichever reason you're doing it for. There's a flip side. It's also really easy to make a complete mess of stuff. Right. And so that's an intellectual activity. It's an intellectual activity to build these complicated things. It's an intellectual activity to kind of screw up building these complicated things. But there's the intellectual aspect, but there's also the emotional aspect. We really, really enjoy doing this thing, I think most people. So that leads me to the first question. This is the thing that started all the panic that kicked in. How do I know if I'm doing development? Right. So what I want you to know, I'm going to leave this whole presentation. I've got very few slides, so I can leave these questions hovering up on the screen to make you panic like I did. I had was sitting asking myself this for years. I still don't know if I know the answer. How do you know if you're doing development? Right. And the thing that kicked it off when I was at this conference, this unconference, and it was self organizing. So in the afternoons in the mornings, we do self organizing sessions. We talk about loads of cool stuff. And I just listened to all these interesting things folks were saying in the afternoon. People would organize hackathons and stuff, and we would sit with whoever it was doing the hackathon, and we would kind of all contribute and work on some code together with no goal, just we were doing stuff. The time this comes from, we were sitting in someone's apartment. This person called Joe Sondale was sitting on one sofa. Twitter Bootstrap had just been released. So you can figure out how old this is. I think it's 2004. Twitter Bootstrap had been released. And Joe basically had his laptop plugged into the TV. And he's working through the Twitter Bootstrap code and writing some code on he's plugging it into his website because he's trying to figure out whether or not he wants to let Twitter Bootstrap onto his website. So he's a front end developer. He's really smart, really bright. He worked for Netflix. And so he is narrating. He's speaking out loud. He's talking about what he's thinking, what he's doing, why he's doing it. He's writing code. He's live coding as we go. And everyone is thinking, this is super awesome and super exciting. And they're all giving me ideas and discussing things and sharing thoughts and opinions. I'm sitting there thinking, this is not how I think about code. This is not how I write code. And this is not how I read code. So I'm having, like, it's super interesting intellectually, I am loving every minute of it. Emotionally, I'm like, this person works for Netflix. I don't work like this at all. So I was like, I'm not sure if this is good. And that question stayed with me, and it still stays with me because I'm still asking myself this question because we talk about all the intellectual stuff about code, but I'm not sure we talk about the other pieces. This question stuck with me, but it was worse than this. So it didn't just stick with one question. Over the years, it split into these five questions that I'm going to talk about now. Quick time checked. First question. And this is one of the things that Joe was doing was I thinking about code. Right? Because, like, how are we supposed to think about code? There's not much out there about how to think about code. You get books that tell you about how the syntax works. You get books about architecture. You get books about methodologies and practices and all these different things. But there's precious little because I've looked and there's very little. You get little glimpses every now and then about how you should be thinking about code and what it feels like to think about code. What's the smart way? What's the not so smart way? So should you, for instance, should you think in, like, abstract concepts, or should you think in the specific concepts of the language? Should you think in the syntax of the code? Right. Because I've worked with people, and it feels like they're thinking in the syntax of the language, and then it just comes out through their fingers. Other times, people are working on this high. You know, when you sit with them, you're like, that's some complicated thing, and they translate it out. All of which I saw with Joe. I was like, how does this work? So we've now got another story which made it even worse, which brings us to our first bit of cognitive science, which is the first life raft that I grab onto. Probably not a life raft. More like one of those life ring things. A few years later, we were back at this conference, and Scala was getting big. And so there was an afternoon hackathon. A bunch of people were trying to figure out how to do Scala, so they picked them. I think they were trying to write a Sudoku self solver. So I understand Sudoku. I can solve Sudoku problems. So the problem space was not complicated, and I knew a little bit about functional programming. But it's me and a bunch of very smart people, some of whom will later in this story go on to write books about Scala, which I didn't know at the time. But they're trying to figure out how, and we're all learning Scarlet. Nobody knows Scala in the room. Some of them are on the dock, some people are trying to figure out, some people are typing into IDs to figure out how stuff works, but all trying to think about how we might break this problem down in a way that we can write it in Scala and then run it, and then we can solve this Sudoku puzzle, and everyone else is there, and they're all contributing and they're all questioning things and asking all the right questions, and it feels like everybody's moving this kind of hackathon forward apart from me. My brain is just overflowing, and I am barely managing to keep up typing along with what's on the screen, and I am barely understanding what I'm doing as I'm going. So some of that you can attribute to the fact that I hate Scarlet syntax, and I've now learned years later I hate Scarlet syntax. But it wasn't just that my brain felt full. And why does my brain feel full? I was like, we're all trying to solve this problem. Nobody knows the answer to this problem. Everybody is new to Scala. Why is this happening? And so the people whose brains weren't full or didn't seem to be full were also experiencing joy. They were loving all this stuff. They were loving the experience of solving this problem. And I was basically kind of struggling under the strain as someone I used to work with at a very early job said, my buffer overfloweth, right? So it was really just like a computer science metaphor. My buffer was full, and all of this information didn't know where to go. So that was not fun. So again, what should have been awesome was basically me just feeling like I was not as good as I could have been at this stuff, and I was failing to learn and learn all the lessons and draw the benefits from this experience. And then years later, based on a book that was recommended to me by someone from this conference because I was trying to learn math, because I didn't understand math, which could have been one of the root causes for not understanding functional programming, they recommended a book to me by Barbara Oxley called and there's a picture of this at the end called A Mind for Numbers. And this Mind for Numbers is basically a cognitive science approach to learning how to do maths. There's tons of stuff in it. As someone who's got a psychology degree, it's a bit fluffy and Wooly, but there are two concepts in it, which are super important, which I realized a few years later, are at play underneath. What's going on here when you're thinking about code, the first concept is a concept that comes from cognitive psychology. It's been around for a long time. You've probably heard about it. It's still there. It's still kind of part of the cognitive science way of looking at things. And that's working memory. So working memory is a space in your head where you do active thinking tasks, right. So active thinking, which might be remembering a phone number. If I tell someone a phone number? No, I haven't nearly said my phone number. That would be bad. If I tell you a phone number, you can use that to rehearse over and over in your head. You keep it in your head by doing active things, and then you write it down and you memorize it and it goes into a different part of your memory. That's working memory, or you can use it for active thinking problem solving tasks. So was the problem that I was experiencing that my working memory was smaller than everyone else's? Because we're solving the same problem, we're looking at the same code on the screen, we're going through the same stuff. Did I just have a smaller working memory? No. Working memory is a fixed give or take. And I've done hundreds of experiments over the time. Working memory is a fixed size. But what I was doing was I was not using my working memory as efficiently as I could have been. So this is the second concept that's in the Oakley book, which I haven't been aware of, but it's super powerful and it's how you learn maths, and it's how I believe lots of software development works as well. Barbara Oakley says what you need to do is you need to form conceptual chunks, because what you manipulate in your working memory are conceptual chunks. There's a building blocks, right? So Brooks was talking about building thought castles. Castles are built out of bricks, right? These bricks could be chunks. Those are the things that you're manipulating in your head. I think that you're moving around. And so these chunks are made up of other chunks. You can combine a bunch of chunks together to kind of get a higher level chunk, or inside each chunk, there's a load of smaller level things. You think about it like when we do Java, we're not thinking about how to manage memory because we're working at a chunk level, which memory allocation and the allocation is done for us. So that's the thing we don't even think about. And then higher level concepts are built up of those things, like the standard libraries. They're just larger level chunks. So we don't need to worry about all the other stuff. So what I wasn't doing was I wasn't using chunks as efficiently because I didn't have lots of these conceptual chunks that these people did. Lots of them had done other types of functional programming. So they had the ideas from functional programming, which they didn't have the Scala chunks to map onto. But they did have these concepts so they can manipulate in this kind of restricted mental space things quite easily. And then they had to use some of the mental space to translate that Scala. But I didn't even have these big chunks. I had loads of tiny little bricks lying around and I couldn't keep track of it. And that's where all of this kind of strain was coming from. So that's it. That's what I think is related to thinking about code. So thinking about code is hard. And I think one of the things, if we're going to move on to the next step, sometimes we only talk about the thinking and code bit. That's when we stop, right? So if we did talk about it, we just think about the intellectual activity of writing code, because that's fun of thinking about code, but we never talk or talk very little about writing code. So that's the next one. How do we know we're writing code? Right. So again, I'd watch Joe with his laptop on the screen with a framework he completely didn't understand. He didn't understand his website, so we understood how he built that. All the CSS and all this kind of stuff. He's a front end developer, so it was proper Posh. But when if you sit down and pair with me and it's a bit of a trial, if you ever pair with me, some people here might have not yet paired with me. But if you do, I do not start at the top of a function and work my way down to the bottom of the function. I like flap around a lot. Sometimes I'll start at the bottom of the function because I'm like the one thing I'm pretty sure is when I know this function needs to return and when I figured out what that is, then they can go back and write the signature of the function. But I don't have a name for the function because I haven't got a clue what it's called yet. Then I'll figure out how to get from what's probably been passed into it down to the bottom, and I'll be zooming up and down this class. It's incredibly frustrating for people. I'll then realize it's three functions. I'll refactor it three different things. I've paired with tons of other people with that. It's probably happening, but it's happening inside their heads. It's not happening out on the screen. And I think some of this is a reflection of the level of granularity or the level of detail or the amount of work you've done in the thinking phase before it comes out onto the screen. So it's not wrong. That one I do kind of my loop. My OAD loop is shorter. I'm doing less thinking then flushing out to buffer less think of flushing out to buffer. In fact, that's what if you read the forward to Kent Beck's TDD by example. Kent says the reason he came up with TDD is because his buffer feels smaller and he feels a strain when he's trying to keep too many things in his head. So he flushes it out. Right. And Kent speaks about emotions. One of the few people that you see openly and honestly speaking about how things feel is Ken Beck, which is really interesting. So are we writing code? Right. I don't again, not sure if there is, but there are definitely other things. Right. So there's just the writing of the code, but that's the mechanical intellectual. I need to take what's in my head and get it out. What we don't talk about is we talk a little bit about but we just allude to it is that sometimes the writing of the code, when we get into flow States and we talk about flow States, which is definitely emotional because it feels good. Right. US free climbers chess, people who play world class chess, and a few other people all seem to be able to get into this state occasionally where we completely lose track of time. That isn't just in our heads. That's when it's in our heads and it's coming out onto the screen, onto the system, the flow state. Right. So we don't talk about this enough. Other things I don't think we talk about enough. And you notice this a lot when you pair program with people. The environment, which I'm in. If I went back in the day when I used to sit next to people to pair, I find it easier when I'm using my tools. Maybe for obvious reasons, I find it easier when I'm in my environment. The thinking flows more easily. And it's not just because the keyboard is in a different position. Right. Some people spend tons of time on their keyboards and all that kind of stuff. But there must be a reason why to maybe just get things flowing, et cetera, to get the mechanical and the movement of your fingers out of the way because people just want to get that going. So writing code. Right. Maybe. I think we need to think about this bit more, number three. So again, software development would probably be more awesome than less awesome if it was thinking about code, which is really good, fun, problem solving and writing code, which is awesome. There's a quote somewhere which I can't remember, we spend far more time reading code than we do writing code, so we moan about it and we complain about it. But again, I'm not sure we actually tackle the things that are behind it. That kind of, you know, what is going on when we're reading code because we're just. Well, we're reading code. We're kind of trying to understand what it's doing, but I think there's a bigger, greater piece of detail behind this. I think we need to kind of engage with this more directly to figure out what exactly is going on when we read code. What I think is because I spent a lot of time wondering about this, if I have some mental models in my head. Right. Which are constructed from these chunks, and I'm communicating these chunks out through the medium of the syntax of the language onto the computer. That is the artifacts of my thought process on the computer, on the system. So when I read code, I'm kind of trying to reverse the process and go back to move my head to the mental state that the person was in when they wrote the code. That person could be me. Right. And it's hard because I sometimes forget what I did before lunch and I'll come back and I won't remember what I did with code, or I've frequently been heard to say that what idiot wrote this code? And it was me three months ago, and I'd forgotten that I wrote it. And that's still me. So technically, all of the kind of psychological apparatus is probably the same. It's probably still me. But then you get other people writing code. Right. And then you get vast arrays of people writing code, and we're all trying to figure out how we can build all of this stuff back up to kind of get to this point where we're getting to this shared mental understanding. So there's a really famous thing again, we don't talk about emotions, but we do make jokes about it. So this is a famous cartoon, which you may or may not have seen. And this gives us the clue as to how I think we can start putting some of these pieces together. So it's the famous WTFs per minute measure of code quality on the left is obviously good code. Few WTFs on the right. Bad code, things that I think aren't commented on enough. The good code still has WTS, right. So it's still not Crystal beautifully, super clear. There are versions of this cartoon with this one here where someone has done some development practice that they advocate for. And there's no WTFs. I think that doesn't exist. But there's another elephant in the room, and the elephant in the room is I think this is written from the perspective of the what you're supposed to do is put yourself in the perspective of the person doing the code review. Right. So you're like, you can laugh at the person who's written bad code because we don't admit we write bad code or this whole talks me admitting I write bad code. But Luckily I've passed the interview before. It works. It's hard for us to sit in this space and go, we write good code, but is it good code for everybody or is it good code for longer term or good code for this overall development practice? So we're sitting there, and I think you read this. I've read this at times where the WTFs are coming from me because I'm like, oh, no, who is this idiot? What's this person done, right? So therefore and then maybe good code is my code, because I write good code right on the left. But when I read this, there's another thing. There's another fear that's in there because I've done lots of code review. And this is what worries me when I do code review, it worries me that the code is good, but I'm not smart enough. I can't load up the stuff from the code into my head in a way, because I don't have the building blocks to reassemble this stuff in my head. That would mean it was good code, but I'm lacking not the code that we don't talk about very much. So I think that's there as well. So we go into one more step and then we'll do this next bit of cognitive psychology where I'm going to start trying to hopefully tie all this stuff together, which is good. We've still got time. So we've still talked a lot. I've talked a little bit about my emotions, but we're not really talking about where the emotions come from. So we could just be having this conversation, although it's me talking quite a lot. We could just be having this conversation about the intellectual act of writing code if I'm writing my code and there's lots of WTFs per minute. That's a metric. So therefore we could say that I've just not made my variables clearly enough or I haven't made my function short enough or whatever. There could be intellectual things that I could do. But it's not just an intellectual task, right? Thinking about code is not just an intellectual task. Writing code is not just an intellectual task. There is this joy in actually physically writing code on computers and running that code and reading code when you read good code, like this book is called beautiful code. Right? And sometimes there's a joy in reading code. So where are these emotions coming from? Because I think we're at the point where we can't deny the fact that we do experience emotions when we're writing code. But what we're lacking is an explanation for and me because I've got a psychology degree, where are these things coming from? Right now? I get to press a button, which I forgot to press earlier. And there's lots of emotions. So there's obviously a theme of emojis on this thing. We need to wait for all the emojis to appear. So we're going to talk about another thing. This story is about Clive, who's kindly sitting at the front to remind me to not lie about the story. I might be glossing over a bit about the story. Clive and I were on a project quite a long time ago, but Clive still didn't have hair at that point. And it was big project, inherited code base, spring code base super abstract, really flipping complicated. And so we were there, we were all consultants, and we were trying to figure out how to fix bits of it, how to refactor bits of it, how to split bits of it up, how to fix a bunch of problems that were existing in the code base. And so lots of us were basically engaged in tackling various parts of this code base, which was gigantic, like all code bases and complicated like all code bases and written over years like all code bases. We were trying to figure out how to do something. I can't remember what Clive probably tells after is what we were trying to do. But Clive had been looking at it for a few days. And then I came over at some point and tried to help. We can find out if I did help, but to help not pair program on it, but kind of basically put two minds on it to try and figure out how we might figure out what the root cause of this weird defect was. And it was a weird spring thing. I think we had two spring contexts were starting up, but they were conflicting with each other. That did happen. So if you ever have two spring contexts starting up and you can't find one of your beans, even though it should be there, that's because you've got two spring contexts and you don't know which one you're attaching to with your debugger. So we didn't know that. But we were like, this is weird. But we had some tests because I've written some tests. So we were like, right, okay, we think this is what the problem is. We'd read a bunch of code which we hadn't written. Clive had taken an existing test, had changed a small part of the existing test with my some form of contribution. And we were about to run that test, and we're doing this will take this test, which is working, it will break it, and it will break it because of this. And Clive then said when we were running the test because the test didn't run very fast, I remember that. Clive said, I think this will fail and it will fail with a one instead of a zero could have been a different value. I thought it would fail with a null. We probably went for lunch. We came back, we looked at what happened, what we've generally predicted had happened. So the test had run the test, had failed in the scenario, and it had failed, as Clive had suggested, with a one, not a null. So Clive was super happy because Clive spent ages trying to figure out this blooming thing. I was like, pretty tough that we'd fixed it. But inside there was a bit of me and I was like, wait a second, how come the fact that I thought it would be a null and it had failed meant that there was still something that wasn't right about. What I was trying to understand was Clive was like, maybe we're on to have got a bit of a toehold on this problem right now. We can start digging into it and stuff. And so what I want to point out is it was the same code base. Neither of us had written it. Clived a little bit longer. We sat next door to each other. So it wasn't like I was in my beautiful, glorious, fully soundproof office at home. And Clive, Meanwhile, was working in the corridor of house with the kids, distracting him and stuff. We were in the same environment with the same pieces of kit on the same code base. Everything was the same. And yet my emotional experience of this thing was different from Clyde's emotional experience. So maybe it was kind of obvious why they had a different experience. But I don't want to get to the kind of the human being rational explanation. What I want to do is get to the kind of what's a psychological way of looking at this. And so this is our second bit of psychology. There's a currently running really interesting set of investigations at the moment in cognitive neuroscience. And I got put onto this by another person who went to this conference, Julie Pitt, who needs to get a shout out. Julie put me onto this thing. And it's really Interestingly summarized in this book called The Predictive Mind by Jacob Howey. So if we go to the next slide quickly, I think I've gone to sleep. So far, when I've talked about things, it feels like we talked about this. You do some thinking, you do some typing and you do some reading. Right. But I was trying really hard not to give the game away because it's not really like this. It's like this, right. We talk about feedback loops all the time in software development. We never talk about the feedback loop that's going on inside the human beings head. We talk about the outside, the external bits of it. This thing, The Predictive Mind, the book by Jacob Howie. Again, there's a picture at the end. You can see it takes this. Basically it summarizes this whole kind of thread in cognitive neuroscience at the moment and what this thread in cognitive neuroscience says, our minds or what we think of as our minds. Right. Might be a side effect. We might not really be conscious, blah, blah, blah. Existential crisis number two. But what we have in our heads is a predictive model of the outside world for everything. Like where the things are. The fact that Sarah sitting over there, my mind is doing that. Right. I've got a predictive model of the outside world. I use that predictive model to guide how I interact with the world. So I know that if I don't hold on to this again and move my hand, this will go fly our senses then give us information based on what is actually perceived and our perception, the raw sense data comes in and what we perceive is the meeting of what our minds predict mapped onto what our senses actually sense. So I'll say that again, we have models in our heads which are predictive models. They basically hypothesize what the world is like and we use that to act. So like, if I move, I think some people will move more because they're closer to me. People further away will not move closer to me. And then the sense things move stuff. That's how optical illusions work. Tons of stuff. Read the book, it's amazing. And they do this at a neural level. They've got models that prove this, right. So this isn't like some weird social psychology thing, it's hardcore. People are building neural nets that do this stuff. So that's how everything works when we write code and this isn't in the book. We're making our mental castles. We're constructing predictions of how things are going to work in our heads. Then we write them on the computer and then we run them and either we watch the output of the program or we run the output of the tests or whatever, or the compiler, right? We get the little red squiggly lines. If that doesn't work, that's bad syntax, that's a loop. We are mapping on what we think we expect in our heads onto what we perceive. So that's one key thing that's still not emotion. What they say is the difference is experienced at a basic level of surprise. They call it surprise because they're cognitive neuroscience, but it's surprise. We feel surprised, but surprise is free energy. And it's like free energy, not in some weird sense, but free energy in a kind of neural excitement thing. So this has to be dissipated. The way we dissipate this, they hypothesize and it makes a lot of sense to me is emotions get involved. So emotions explain away things and kind of get rid of this energy. It's how we deal with stuff. It's how we deal with the happy things and how we deal with the sad things. Because we can't have this mismatch in our heads. It doesn't sit because the world we're in versus what we're predicting is different. So we need to somehow make that fit and work. So in code, what does it come down to in code? It comes down to, I think, five different things that kind of give rise to the emotions that we experience. So the mismatches of these five things, number one, and we can doubt various bits of the process. Number one, we can doubt our typing ability. Frequent go to for me. So I still think the picture of what I think I'm trying to build in my head is correct as a solution to the problem. I think that what I've seen is correct. The program didn't run. What I realized is my hands are unable to type semicolons in the right place. Or I've forgotten that in Python you need to have four spaces, not two, or something annoying, right? So that can be a reason why there's some difference, right? So that's an easy one, right? Sometimes you're just like, oh, I'm an idiot, and then you just come in. But that's an emotion, right? You're like, oh, I'm an idiot. Next one. We can still think everything's correct, including the fact that we Typed it right. But we realize that the model we've got in our heads to solve the problem, we're like, okay, the thing we've got in our heads to solve the Sudoku problem doesn't work because we've misunderstood the Sudoku problem. So the code is right that we've perceived. We wrote it right. Based on what's in our heads. And the thing in our heads is coherent, but it's not right for the problem. Next one. There's something wrong in our heads. So now we're moving into when we start dealing with this, we are having to start dealing with and acknowledging and wrestling with the fact that the mental models we have in our heads, the mental castles we have in our heads, are not as clear or precise or detailed or correct as we think they are. That's getting harder to deal with. Right? I've put a lot of effort into constructing this thing. Clive spent a lot of flipping time trying to get his head around this gigantic Spring code base, right? We didn't know that you could start to Spring contexts in parallel. We found that you could, and then all weird amount of stuff goes wrong. But we'd assumed the Spring context is like a place where you put everything right? This single one version of everything, because it's the single Spring context. We haven't got a complete understanding of Spring and how Spring works, including all the bugs, all the defects, all the weird side effects. And frequently we don't trip up on these things. But when we do, that's our mental model. Our mental model is not detailed enough of how the Java libraries work or how Scarlet syntax works or something. So that's number four as well. The mental models that we constructed is three. The underlying ones. We are not aware of every single weird side case of how Java works, or Ruby works, or Python works, or a library works or Spring works. Right? When we're in control of all of this stuff, we have all of those mental models, all of the levels of chunks. But who has that, right? Nobody has that. We're just lucky we don't trip into them. And number four, this is the most and I think this is one where you see, like, people going crazy and throwing laptops out the window. We can doubt our perception. We're like, I sure I type this correctly. And I spent days, you know, the classic I finally found out what was wrong. We are seeing the missing semicolon, but we are not perceiving the missing semicolon. So we go around doubting every other single thing until we realize that we mistyped the semicolon and we find it right? That is another massive, gigantic source of frustration, anger, desperation, inability to sleep, inability to unload this from our heads, all that kind of stuff. That one's really flipping hard. And I think being aware of these things, this is the thing where I've got to be aware of these things. And now when I'm debugging, I'm like, right? I kind of go through these separate things to figure out where it might be, even though it's super unpalatable. I'm like, Am I really? Because, you know, you do. Sometimes someone will come along. And I think that's what I thought I might be doing with Clive. Surely Clive's missed something really obvious. I'll come along and fix it. That wasn't what it was. But, you know, sometimes someone comes along or you do rubber ducking, right? You explain what's going on to someone without having all of this emotional investment in the fact that it can't possibly be, the fact that I'm just not seeing it properly. We have these techniques. I think that's why this works. Question number five. I was like, this is awesome. But it still doesn't tell us about the religious experience, varieties of development experience. But I think it does because obviously we're human beings. We've got tons of stuff going on, right? So there's variety and difference all over what we're doing all the time. Variety in our education, variety in our background, variety in our home environment or our work environment, variety in the levels of stress that we've got. All of the stuff that makes us be able to bring more or less of ourselves to this act of software development. But there's two things that aren't variable, I think, and those two things are working memory. And the fact that we use chunks, that's there the quality of our chunks can vary and like how efficiently we use them and how we build them up and how we manipulate them. We can practice that. And that's why you get caters and all these things to build up the mental muscles. But that is a proven psychological thing. Everybody has it to a greater or lesser extent, within a very small degree of freedom. The other thing is, until I'm like all good psychological theories, until presented with a better example, I think the predictive mind loop mapped onto what we do with software development. I think that and the fact that we're constantly these three acts and we're mapping back on, we're mapping around. We might start at any point in the circle, but we're constantly doing this circle that is also happening to every single one of us. We might have a less good loop. We might be optimizing for less bits of it. Like I said, I optimize for, like, flushing my buffer to code as much as possible, which is why I love TDD. Other people hate TDD because they don't like trying to have to just think about the test and then go around the loop and then think about the implementation and then go around the loop and think about the refactoring. They'd rather think about it all at once. That's why I think it's hard. Why people don't like TDD, because I'm trying to tell them to do something that they don't like doing. It's not part of their conceptual inner loop. So that tells about the variety. That's where I think the variety comes from. And then the final variety is we're presented with this kind of surprising, this basic thing, which we can then choose to do with as we will, how we react and respond to that will just based on how we are psychologically at the time. Right. Some people love a challenge and they love a really gnarly bug. So they go in and they love doing this stuff. So they go and find those bugs. Other people like, I just want to do the good stuff. I just want to flow and all the things in between. Right. That's where all this stuff comes from. So to now maybe hopefully send everyone off in a slightly worrying tangent. So at the start, I said, how might I know if I'm doing development? Right. What I want to do is ask everybody and you might completely disagree with everything I've said, in which case, that's fine. I spent a long time thinking about this. How might you know if you're doing development rights if you're intrigued by this and you want to go on this mini existential crisis journey, like maybe with a slight because for a long time, like until like a year ago, I really haven't figured out what this meant, and I was just worried about it. How might you go on this journey? So key things are especially number one, just because development, as another ex colleague would remind me, is a team sport. But start focusing on yourself. Right. Because obviously if we bring in social aspects, it gets more complicated. So step one, if you focus on yourself and just focus, like, acknowledge the fact that there's this cycle. Right. And acknowledge the fact out, the fact that there's this kind of working memory buffer and you're using chunks in it and you're manipulating those chunks and just get used to the fact that these things might be there and be aware of them and kind of start watching out for surprising because it's interesting, since I've kind of stole this thing from the predictive mind. I sit on loads of, like, slack channels at this conference. It's really good. Slack channel, Gchat channels at work. And if you look for the word people go, people basically saying, I was surprised. I thought this would happen and this happened instead. The surprise thing is popping up all over the place. People are like, if you, like, cataloged all the time we get surprised by software development. That's why it convinced me that this was real. Right. And people are constantly going, but I thought Java worked like this where it does. But apart from this little thing there in Java 1.8 where it does a weird thing, because there's a weird library, which we can't fix, because if it will break something in Java 1.4 that's there. So watch out for that. That can only get you so far because I think we are comfortable. Lots of us have gone to this because we're comfortable in the intellectual space. Right. It's challenging, but also good fun. So that might be hard. So if you can't lock in because you keep getting sucked into the loop and the act like unconsciously, the act of writing software development, either do something which you hate, which is for lots of people, TDD, which I still love, but do TDD because it will force you to do the steps or pair program, which is terrifying the first few times you do pair programming, because the thing in pair programming is you are trying together as a pair, trying to come up with this shared mental model. So you're forcing this thing outside of one person's head into two people's heads at the very start, from the very beginning, that's ludicrously hard. Plus you might not even like each other, right. Or you get on great with each other. But one of your style is one way, another one of your style is another way. Or today you're trying to match up as much as possible. And that's why it's super powerful, because when you match up, it's ludicrously powerful because you're getting like double reinforcement on all of these things and it magnifies. That's why pair programming is awesome. I think it's also why it's hard if it's not gelling. Right. It's like you're trying to put two gears together and it's not working. That's why it's hard. I think so if you try and do that, I think that's it. Yes. So that's what I reckon what I would love people to do. I would love feedback on this talk. This is the first time I've given this talk. Hopefully it was clear in my head it feels like it was clear, but that's like my prediction of what's going to happen. Maybe it made no sense at all. Those are the books. They're really good. But yeah, what I just really would really love to hear is, like I said, I think the way into this is emotion is not like a weird side effect. Emotion is a clear signal into all of these things. Right. If you're feeling something, acknowledging that and using that as a tool is what I said at the start. Picking up the challenge from Lindsey on the keynote yesterday, this isn't just a thing that you should look after, because if you're angry or frustrated, you should acknowledge it, because it's pretty bad to kind of just push it down. I think it's telling us how to be better developers. I think it's telling us when we're not happy with our ideas, when we're not happy with our work environment, when we're not happy with the code we're working on, et cetera, et cetera. I think if we get that, we can learn better, we can do better tools. We can build better frameworks like surprise. If you're building a framework to minimize surprise and maximize joy, that's got to be good. I'm going to love building with that framework. So that's my call to match. Now got seven minutes for questions, and I couldn't get my phone to work, so I don't know if there's any on the app or maybe W. Just got any questions. Go, Tristan. Hello. I think so, caveat Tristan's question was, what's the best way to share these emotions, especially when you're pairing? Because we pair all the time, because it's part of the cult that you have to join. I think I've been lucky. So I don't write as much code as I used to because I've got promoted one step too far by accident. Sorry. It's privileged that I got promoted one step too far by accident, but I don't get to write. I get to help people like Tristan have the environment to write good code, which is massively awesome. But I do get to write code. On my last gig, we got to write some Power Bi code myself and the other person who is too senior to be doing this kind of stuff. We were lucky. We had a really good relationship. So we could just admit the fact that Date's logic in Power Bi is horrific. And we were both idiots, and we both had, like, 40 plus years of experience of trying to write code, and it shouldn't be this hard. And it was a nightmare. But we were talking about and lots of this came together while I was working with Pete. So shout out to Pete, because I'd be like, dad, what? Sorry, how does this stuff? And then he would be like, oh, that wasn't surprising to me. And then he would explain to me why he didn't think that was surprising. And I would go, all right, I had a completely different concept of this thing, so it had to be a bit safe because I had to basically go because they were paying me to be there for the stuff that I knew. So for me to then go, I really don't know how this stuff works. That could be a bit risky or just emotionally risky to just kind of say, I really am a bit stuck on this, but the fact that we could do that, we could iterate. And two old idiots built a four key metrics. Come and see the talk when I write that talk, four key metrics dashboard in Power Bi in our spare time. And it was good, fun. Flipping hard work, but it was good fun. It could have been a flipping nightmare. But we were talking about this kind of stuff. So, yeah, I think ideally, if we can and then we're talking about emotion strike. We're talking about when we're frustrated, we're taking breaks because we need to take breaks, et cetera, et cetera. We're writing code because it's minimizing surprise and things. Any other questions? I'm assuming there's none on there. Go, do you think that you learn how to deal with kind of promotions related to the writing code with the experience, you know better because, for example, you know, okay, first of all, complicated. You have to have that special mental model to understand. Yeah. And then from experience, you know, okay, I struggle now. But I will find the solution. So a lot is coming on from experience at the Union, you will always say, okay, this is harder. So I think you're right. So the question is kind of how does being aware of the journey on your awareness of your emotions, but also the things that is causing the emotions, like how much you know and what your levels of experience are, how much that impacts things. Right. I guess. And you kind of answered your own questions, though. So I completely agree. I love learning. So I like going into places where I haven't got a flipping clue. But I think that's got me really comfortable with admitting to myself that I really haven't got a clue what's going on, and I enjoy it. And then that's what so Pete and I, both of us didn't have a clue what was going on. So we were enjoying not having not understanding and discovering things and Googling every second line of code that we wrote, maybe every line of code we wrote all of that cool stuff and trying to figure stuff out. And then we could bring that into other things we were working on. And also when we were aware of it, as leaders, we were trying to build a we were trying to celebrate and make it clear when someone discovered something that they learned we were making. And it goes to all of the cultural stuff. Right. When a team struggled and failed, we were trying to celebrate that as much as everything else, because otherwise it would associate that with negative feelings. But it should be with positive feelings. Right. We've learned a bunch of stuff. We've learned that we definitely shouldn't have chosen Kafka. We didn't choose Kafka. But you know what I mean? Pick something which could be super complicated and might not give you what you want. We wanted to celebrate that because we wanted to set we wanted it to be fun. We wanted people to enjoy themselves, and we wanted people to do stuff. I think it's interesting. It's interesting to me that things that take off seem to have good libraries or good languages or good tools. Right. The tools are, again, important. But also I think good communities. I think if you can go somewhere and put your hand up and say I really don't understand this and the barrier to having an emotion of to be vulnerable is low. I think that's super key be welcoming and help people learn and stuff, because otherwise it's the problem with lots of functional programming. There's this thing where you're like you can't do FP unless you understand math, which is why I read the book. So now I kind of understand math, but I didn't. And they were like, well come back later when you've understood math. And that feels bad because functional programs got so many cool things in it. And this isn't all functional communities, but it's some functional communities. And that's like it's not great, but I think it could be. I think we could build I want to build functional stuff we asked about DDD is inherently functional when you read parts of the book, but it doesn't say it just is any other. I've got 1 minute left. Go is the lesser, please, because the reason I thought this after I had the panic, I think a week later I read the Ken Beck book which should be up here, which is test room development by example. The forward to that book. He talks about his fear, his discomfort. He talks about the fact that he feels uncomfortable when he writes the test and all this kind of stuff. There are patterns in that book where he explicitly calls out you have to run the test to see the red because you need to feel the discomfort that there's something that's not implemented. You don't just go I've written a failing test, now I'm going to implement it. You run it and see the red because you're supposed to feel discomfort. He talks about if you've got tons of stuff in your head, write all of them down apart from one thing and you implement one thing and you offload all the other stuff, right? What's in your mental? It should have been obvious if I read the book a bit more closely, he's like you're now going to do just enough to implement this test to make it pass. You will feel ugly and like a lesser class of developer because you haven't built this beautiful thing. Don't worry, that's step three when you're going to do refactoring. It's super built into it, right? All of that stuff. Kent was on it. The XP people basically had it figured out. We've just been rediscovering what the XP people figured out how many years ago it was. I'll be around for the rest of today until I need to disappear for appearance evening. So if anybody's got any comments or feedback and that's my Twitter handle, which is not very memorable Al 94781 because I got on Twitter to very early for it was a big thing. So yeah, if you've got any comments please just share them really cool to hear thanks everyone.