A few glasses of fizzy were consumed during the JetBrains party at Devoxx Belgium last year:
Holly: You do presentations about productivity, and about developer happiness, and I do presentations about developer joy. We should do a presentation together!
Me: Yes! What a fantastic idea! Two titans of the London Java Community co-presenting on a topic that excites us both!
This is the story of how that went
And there you have it. That's how presentations are born. We planned to give it at DevoxxUK, scheduled to be in May, so we had loooooads of time to prepare it1.
We wanted to explore this idea of how coding is (generally) fun for developers, or was at the start, and that's why we got into the game. We wanted to explore why coding is NOT fun at work, and the impact that has on our productivity. Or, more accurately, how the friction and productivity blockers are part of the reason we don't have fun at work.
What surprised and pleased me the most about creating this presentation is how it brought back my own sense of fun. Holly has loads of fun drawings in her presentations, and I was a bit jealous. I used to do hand drawn pictures in my presentations, but I stopped doing them because "that's an inefficient use of my preparation time". I started creating one or two drawings for the slides for this presentation, and I remembered, "I like this! This is fun!". I also found that while I was thinking of what to draw and while I was drawing, I was unlocking a different part of my brain, so I was able to ruminate on the talk and its topics without being able to re-write any slides, and it let me come up with new ideas or have a clearer idea of the topics we were covering.
I also found it helpful that Holly effectively owned the slide deck so I didn't have full control over it. My process is usually to create two or three draft slide decks completely independently, and then I might finally be able to create (from scratch, again) the slide deck that starts to tell the story I want to tell. When I tried that with this presentation, Holly very clearly reminded me that we had already decided on a structure, we knew what story we wanted to tell, and all we had to do was fill out the missing content. It was true. And it saved me a lot of faffing around thinking and rethinking things3. I mentioned this in my post on Working Smarter Not Harder.
So, if you're interested in what makes our jobs fun, and how we can embrace joy at work, including some examples of how play makes us more creative, watch the video:
Slides, further reading and more information.
Transcript
Trisha: Hi, I'm Trisha. I work for Gradle Inc.
Holly: And I'm Holly, and I work for Red Hat. I help build Quarkus. And when we started to think about doing this talk, and what we each did, it seemed like maybe we had nothing to talk about because there was no resemblance between our jobs. I work on Quarkus, and one of the things that we really try and do with Quarkus is developer joy. Whereas Trisha works on Gradle and what they're doing is developer productivity engineering, which sounds like the exact opposite
Trisha: Of joy, right? Right, exactly. So developer productivity and especially developer productivity engineering, it's all about measuring stuff and being productive, and producing things. But actually, what we really want to talk about from an engineering point of view when we talk about developer productivity is joy and happiness and how engineering away these problems makes us happier in our jobs.Holly: This comes back to a bigger question: is our job supposed to be fun? Kevlin yesterday mentioned this idea of like, if we go to work, are we allowed to have fun? Is that a goal? Is that a defect? Is it a feature?
Trisha: I do feel like asking management for more time to have fun is not a conversation that's going to go down very well.
Holly: Career tip, avoid the word fun when you talk to your management.
Trisha: Well, that's why we've been talking about different things. DPE, Developer Productivity Engineering: it's fun, but don't tell anyone because it is the same thing, effectively. I was looking for a quote a little bit further on in this presentation and I came across a Fred Brooks article called the tar pits, about how work can become like, tedious and difficult. But in this, he talks about the joys of the craft. Why is it that programmers enjoy the job that they do? A lot of us got into programming because we enjoy it. And he was talking about this in 1970, 80 something.
Holly: It just goes to show any thought you've had, Fred Brooks had it first and probably said it better.
Trisha: So we should all just read the book and quote him instead of coming up with anything else. So he says there are five things which contribute to why we enjoy our jobs as programmers.
The first is the sheer joy of making things, which I think a lot of us can kind of relate to. Every time I think about making, I think about you with a hat in that presentation where you did like, you made a hat and you coded it. Never worked, but it was very fun.
Holly: Yeah, I made the world's first cuddly throwable application server.
It was a very misguided demo.
Trisha: But it was an awesome talk. So we love making stuff. And I think that particularly with coding, we're making stuff in, in a much lower maintenance way than, than making an application server. And something else that we like is the pleasure of making things that are useful to other people.
A lot of what we're doing when we're coding is something that hopefully users will use and say great my life is easier now that I'm using this thing and that's quite satisfying. The fascination of fascinating, of fashioning complex puzzle-like objects of interlocking moving parts and watching them work.
Certainly there's a certain subset. I mean, this was mentioned in the other keynote yesterday about how many gamers and puzzle solvers get into programming, because we kind of like to figure out how things work and how to get things to work together or how to fix things that aren't working together.
And so that's another part of why we enjoy doing what we do. The joy of always learning. I wasn't sure about this because I think that in the job of a developer, I think we have a bit too much learning sometimes and it can be very overwhelming and intimidating. But I think those of us who succeed in this role are the types of people who do enjoy learning. Because if you don't, you don't learn. You're in trouble.
Holly: And there's another, sorry, I'm just going to interrupt you because we're going to interrupt each other all the way through the talk because there's another career tip there too that you didn't even ask for, which is if you're in a job and you find you've stopped learning, that is your indication that you should move job because we love learning.
Trisha: Every time I came to update my CV and if I hadn't added something new to my CV, it was time to leave that job because I hadn't learned anything new. So yes, top tip. Number five, the delight of working in such a tractable medium.
And this to me ties into number one, the sheer joy of making things, but in a medium which is relatively low cost. We don't need to buy materials. We don't need to plug stuff together. I'm reminded of when I did a clay pot making workshop with my husband's uncle, and we actually have to buy clay to make stuff.
And one of the things that he taught us is that you actually have to throw things away. You do stuff as practice and throw it away. And the exercise is the doing, not the end product. And we can do that in IT really easily. We can just produce code and throw it away. We don't do that. We should do that more.
Holly: Yeah. Whereas when I made the cuddly throwable application server, the application server part of it was easy. The cuddly throwable part, it made me appreciate code so much because every time I would make a mistake, I really would almost have to, you know, undo everything and start all over again.
Whereas with code, you can just make a small change and it. It does what you want or it does something that isn't what you want, but at least it's different from what it was doing before.
Trisha: Right. So, and then I asked the internet and said, why do you enjoy your jobs? And they all agreed with me. So that's, that's the point about this slide.
Holly: And so, so then we have, uh, you know, a little bit of a paradox, right? Because Fred Brooks said coding is fun. We all know coding is fun. And yet probably, you know, some of us when it gets to Monday morning, don't think, oh, amazing. So what, why is there this gap between this job that in theory should be really fun and the reality?
Trisha: So one of the things we talk about with DPE is the toil and friction of our jobs.
So we like the coding and that's fine, but that's not what we spend a lot of our time doing. Certainly it doesn't feel like we spend our time doing the stuff that we want to do. We spend a lot of time doing. other stuff. We spend time waiting for builds or waiting for tests or waiting for Bob to get back to us from accounting to tell us we can buy the IntelliJ IDEA license or deploying or largely waiting and context switching.
Holly: And one of the things about this kind of drudgery is it's a little bit like frog boiling because we don't really notice it creep up. So like, you know, the build takes two minutes when we start the project and it's amazing, then it takes three minutes, and then it takes four minutes, and then two years later you're still on the same project and the build takes 24 hours and nobody has really questioned it because each little worsening was a little bit more.
Trisha: And so our jobs start off perhaps something which is fun, but they incrementally get worse and we don't even notice that we have a job that we don't really enjoy anymore. So can we fix this?
Holly: Well, it seems like maybe one easy fix, the fix that we all want to do. Let's write more code, right?
That solves the problem. We get back to the Fred Brooks bit.
Another thing that Fred Brooks found was he, he looked at projects and over the lifetime of a project, he found that each developer on the project had written 10 lines of code a day, which is pretty terrible, right? Because if we're developers we want to write code and we're only writing 10 lines, that's bad.
As we may have mentioned, Fred Brooks was writing a long time ago. And so when you look at that 10 lines of code figure, you probably think, well yeah, but he was writing in like PL1 or COBOL or something, of course. Punch cards or something like that.Of course they were only writing 10 lines of code a day.
But, very anecdotally, people still discuss this figure, and people come up with numbers, even in 2024, when we have all of the advantages that we have in 2024, like not working in PL1, and people get sort of similar numbers. One recent number was 12 lines of code a day.
Trisha: That's like 20 percent more.
Holly: Well, it's a huge improvement in productivity. And they were working in a sort of a regulated industry. So that did slow them down a bit. And it's sort of spiky. So on a good day, you may still write 400 lines of code, but then, on another day, you may write zero or throw out those 400 lines of code.
And so then when you average it over the whole life of the project, it's not very much at all. Here's another one where they worked it out, this was 29 lines of code a day. I think that one might've been the guy who wrote NPM, he was looking at one of the projects he did. So it's not that he is an incompetent developer and that's why he's only achieving 29 lines of code a day. It's because stuff. So we say, okay, we're solution oriented. Let's try and fix that.
Trisha: Did your boss ever say to you, bring me solutions, not problems?
Holly: Yeah. No, that's why you're a manager is you're supposed to fix my problems.
So. People respond to incentives. So what if we try incentivizing producing lines of code? Will that get the developers past that 12, 29, 10 lines of code a day? Well, I found another anecdote on the internet, so this is a true story that I found on the internet. It was a team where they decided to up the team's productivity. They were going to pay the team for lines of code. They were going to give them bonuses. So anybody want to guess what happened?
Trisha: Everyone guessed what happened.
Holly: Everyone guessed what happened. What they did, the first thing that they did was some refactoring.
So. Instead of something like this, they said we can make this more profitable. We can do that. Same code, more money. But then they looked, they said "we feel comments are very important, but we don't want too much noise in the code. So, let's work on the appearance of our comments." And what they did is this. They put their comments through an ASCII art generator to make pretty comments. Incidentally, very profitable comments. And so you won't be surprised to hear that this experiment at this company lasted one day. And then people looked at what was happening to the code base and said, Oh no, we need to try something else.
So let's try a different solution to get us writing more code.
Trisha: AI. It's 2024. We have to mention AI. Obviously AI can help us write lines of code. That's what they keep telling us, right?
Holly: This is a recent example. I wanted to get a piece of Quarkus code and so I gave it a little description and the first thing that came out was pretty correct code and it saved me typing. You probably can't see that very well, but you'll see why it's so small in a moment. I was pretty pleased at this point and you know, the AI was doing its thing where the lines come out one by one and then it kept going. And it started adding getters and setters. How many of you are using Quarkus? A few hands maybe. So those of you who are using Quarkus will know that one of the things we really try and do with Quarkus is not have too much code.
How many are using Panache? Same hands. Cool. So with Panache, the whole idea is to minimize the lines of code. So these getters and setters, you do not need. It put them in anyway. And then it kept going and it gave me more getters and setters and then it gave me more getters and setters. So when I first looked at this, I thought this is amazing.
This has saved me so much typing. It would have taken me ages to type all that out. And then I realized that I shouldn't have typed all that out. And if I had pasted this into the code base, I would have just created a liability because code is a liability. And so in this example, It was 70 percent unnecessary code.
Trisha: Maybe Copilot is also rewarded based on lines of code.
Holly: I have a feeling that's exactly it, actually. I think because of the way that these algorithms work, they want you to predict the next thing and saying there is no next thing is a very boring thing. So I don't think the algorithms, the machine learning algorithms are rewarded for stopping early. I think they're rewarded for keeping going.
So you have this sort of tendency to verbosity because they're copying and pasting from the internet and there's a lot of internet to copy and paste from. And so I think fundamentally, it looks like it was really productive, but if you think about it, it's the equivalent of ASCII art comments. And this is bad, right?
It's not just that it's annoying, it's actually putting downward pressure on quality.
So it's easy to laugh at AI and, you know, say, ah, well, all of our problems started in 2023 when we started using AI to generate code, but if you look at old generated code, like probably what all of our IDEs do for us.
You know, how many of you have had your IDE generate code like this for you?
All of us. All of us. Right. And it's like, I have Javadoc. If I have a method that says it returns a thing, the Javadoc helpfully says it it returns a thing.
Trisha: I worked on a library where those were the published Javadocs for the library code. And as a developer reading this, I'm like, I know that's the XYZ, but what is it for? What does it do? Why do I need one of those? It's not at all helpful. But we had 100 percent Javadoc coverage on that.
Holly: Yeah, I mean, that's the really problematic thing about this kind of thing is it makes it very difficult to know whether you have a problem or not. Because if you use an automated tool, it says, "you guys, amazing, look, you've got so much Javadoc".
Whereas if there was no Javadoc, you could more easily go through and say, "okay, there's no Javadoc. I think this one should have a Javadoc. As a human, I will write some Javadoc". Because what you really want from your Javadoc is a little bit of why, a little bit of the subtlety, not just tell me what is completely obvious
Trisha: I think this is why people talk about self documenting code, because if the method name is useful, you don't need the javadoc comments. But like Peter Hilton said in the 97 things talk today, he said the method name can never really encompass the why, like why do we do these things? What are the side effects? What happens if I call it wrong? And that's what the comments are for. However, that sort of thing requires someone to think about it. And that's the time that's spent. It's not the typing that's the problem. It's the thinking about it that's the problem.
JetBrains AI Assistant has the ability to generate your commit message so that you don't even need to type your commit message. Which sounds awesome, right? Because nobody likes typing commit messages. It's like even worse than comments because it just has to be so long.
I fundamentally disagree with this [generating commit messages]. I think that this is going to make developers think, well, not think, basically. For me, a commit message has always been a way of thinking, okay, what are the files that I've changed?
Did I really mean to change all those files? In this commit in particular, I've changed IntelliJ IDEA settings files and a test and the application file. And I should already be thinking, Ooh, that feels like at least two different commits because we're talking about configuration and testing and production code, but the AI system says "updated project configuration amd increased the language level and reformatted this test", and it just chucks on the end "to improve consistency and readability", just kind of assumed that's why I'd want to reformat a file.
But it might not be that. It might be something else. And, and as a developer, I need to be looking at the commit and thinking, are these the files I really wanted to change? Is it really a single commit? And what was I trying to do? And when someone comes in later and does git blame, what do I want them to see on that changed line?
I want them to see, I changed this because customer XYZ now has a different requirement and the behavior is different.
Holly: Really it should be something that you couldn't work out just by looking at the code. Cause if you could work it out just by looking at the code, why would you even need the commit message?
And I think with all of these, with the Javadoc generation, with the commit message generation, with the ASCII comments, with all of it, it's this sort of idea that if we have a greater volume of code, we have a greater quality of code and we have a greater quality of developer. And that greater productivity.
Trisha: We have produced more code. Therefore we are more productive. That's the assumption.
Holly: And this assumption is still baked into our tools, even though, as an industry, I think probably all of us worked out quite a long time ago, that lines of code really is not a good productivity measurement for people, and so if it's not a good productivity measurement for people, it shouldn't be the productivity measurement that we use for machines, for tools.
And, and in fact, I think There's sort of a bigger question here too, which is what even is our job? Like, does being good at our job mean writing a lot of code? Is our job to produce?
Trisha: Are we typists? Is that what we do? What is our job? Is our job to produce code? Because if so, then surely AI will be able to do, be able to do that in the future and IDEs and things like that. And so this is the problem with measuring our productivity as developers is that. We fall into this trap of thinking the job is to produce code or commits or releases or whatever.
And this is because we don't really know what developers are for or what they're good at or what we should be spending the time on. And we fall into this trap of thinking it's all about writing code, producing code and AI can do that for you. Sure it can, but even with AI, actually, you still need to tell it what to do, why it needs to work that way. You still need to critique the code. You still need to say, is this stable or going to do something absolutely crazy with our deployment or whatever it is.
Holly: It's a little bit bad if we think our job is to write code, but it's really bad if our management think our job is to write code. And it's really, really bad if at the executive level, they think our job is just to produce code because that's what leads to this kind of statement - this was the CEO of Stability AI, and he said within five years, there's not going to be any human developers. And I think what this fundamentally shows is he has no idea what a developer does.
If you dig into his statement a little bit, he did actually give a little bit of evidence for it. He said 41% of all code right now is AI generated. And I read that and I went, wow, really? That seems like a lot. What he actually meant, but didn't say, is 41% of the code that is being written by Copilot currently is AI generated, but even that you can dig into that a little bit. That statement was based on this research from Copilot and they found that Copilot users accepted 30% of its suggestions, which sounds kind of good until you flip it. What this means is 70% of what Copilot suggested was complete crap that nobody wanted. But of that 30% that Copilot produced, it made up 40% of the code base.
So you can kind of do the math and you can see that what Copilot is producing is more verbose than what the human is producing, just in the code. That's maybe a problem because when we think about lines of code as a productivity metric, if you're a developer and you produce negative lines of code, does that mean that you're a terrible developer?
Trisha: Well, I love deleting code. It is the best thing.
Holly: It is the best thing. It is usually really increasing maintainability. And I heard Martijn Verburg say once: you pay your junior developers by how much code they write. For the senior developers, what's their job? Their job is to delete code. And so that's how you really know you've reached that level in your career. You're doing what Trisha's doing. It's like going into the code base and going, rip, rip, delete, delete,
Trisha: What can I delete? And yet the test still pass, the users still get everything they want. The developers have to read less in order to get what they want. I was just reading this right now thinking though, the idea is not to have the senior developers just delete everything that the juniors wrote.
Yeah, you could game the system really easily. Sure, but it's much more difficult to figure out which lines of code you can delete and still retain exactly the same functionality. And we're also not going full crazy in terms of like the Perl regular expressions or collapsing stuff down into unreadable blobs either.
We're talking about retaining readability and functionality and so forth.
Holly: And the problem with a lot of the stuff that AI is typing for us is that if code is so boring and predictable and boilerplatey that a machine can generate it for us, why is it even in our code base at all? Why does anybody need to be typing this?
And this is something that, that we think about a lot with Quarkus. So with Quarkus, because Quarkus does a lot of bytecode inspection at build time, that means it can do a lot of things that were only possible before if you did horrible things or accepted a really big performance penalty. So it means that we can have this really concise expressive programming model. For example, with logging: One of the things that I always hate is initializing the logger because you have to say, if the class is MyService, you have to say "I would like a logger for MyService". Why do I have to tell you what class it is? You are the computer. You know better than me what class you're working in. Because what happens then is I take this statement and I can paste it into a different class, and I forget to change the static initializer, and then I've just put rubbish into my code base. One of the things that you can do with Quarkus, is you can just get rid of that, and you can just do log.info and it will have the right information. Or, for example, if you're using Spring, you may be familiar with this, you need to declare your Application. There is nothing very interesting in this code, so we can just get rid of it in Quarkus. And we can do the same thing with things like Hibernate.
When you're using Hibernate, you usually end up having to do a lot of boilerplate of queries that tend to be the same across all classes, except for a few little variations, but you can't inherit them from a superclass because it needs some knowledge of the class.
What we can do with Quarkus is, instead of having to have all of that, you can just do that, which you still can't read because I kept the font size the same. But you can see that there is a lot less of it and everything else is inherited from the superclass. Or with test containers, if you're going to use test containers, I mean, everybody should be using test containers, but there's quite a lot of stuff that you have to put in every test to say, okay, now I would like you to start test containers. Now I would like you to stop test containers. With Quarkus, all of that goes away. The only thing you need to do to make test containers work in Quarkus is not configure an external data source, and then it'll go, hey, I can see you're trying to test something and you don't have a data source and I can see you're using Postgres or whatever.
I'll just start a test containers instance for you. So, it's really nice. And I think independent of Quarkus, this is the direction that we should be demanding our tools go is non invasive, non clippy, non bloaty boilerplate reduction.
Trisha: The whole thing about measuring lines of code as productivity was just your way of like telling them the managers shouldn't freak out if they use Quarkus and there's less lines of code. It's okay. It's still productive.
Holly: But there is a little bit of a problem, which is, if you go from that and Quarkus is great, so if Fred Brooks had had Quarkus, would they have written more than 10 lines of code a day? And then actually, no, they would have written like even less than 10 lines of code a day. So we'd be worse off.
Well, not worse off, but we wouldn't have fixed the Fred Brooks problem.
Trisha: So lines of code are a terrible metric and if the machines can generate them, then we should just not bother with them at all. Okay, so if we can start being more productive in terms of using frameworks that don't need us to write so much, and if we're not spending all of our time writing code, what is it that we are doing as developers?
And it's things like spending time building code. Obviously I work at Gradle. So we talk a lot about building, building and testing. Testing generally takes longer than building. Like I really hope it does because otherwise you don't have any tests. Maybe deploying or other things that you're going to be doing.
This is kind of part of our job too. When we talk about what is a developer's job and we get fixated on this idea of writing code. It is a good idea to test that code too, and probably to deploy it somewhere where someone would use it. I recognize there's DevOps and pipelines and so on and so forth.
But the fact is that in order to write the code, there's a whole bunch of other activities that happen as well at the same time. There was a survey done in 2019 about what developers spend their time doing. And this survey suggests that you probably only spend about 32 percent of your time writing new code or improving existing code.
The rest of it is other stuff. So really only 32 percent of our time is actually spent writing code. So perhaps if we want to optimise this, we, A, should understand if that's true for us, and B, figure out how much time we're spending doing the various things we're doing when we're supposedly writing code.
So as with any performance optimization problem, you need to measure, don't guess. And I heard you say this a bunch at the Devoxx Belgium talk, and I love it because like, our old boss used to say this all the time too. So we have gut feelings on how long we spend doing stuff or where the performance bottleneck is and all the rest of it.
And sometimes those gut feelings are correct, but more often than not, that's not necessarily the case. So what you really want to be doing is you want to be measuring the amount of time that you're spending doing stuff. This is kind of what we talk about in terms of DPE, Developer Productivity Engineering, taking an engineering approach to developer productivity.
So the first thing we should be doing is measuring how long you spend doing stuff. For example, Develocity, Gradle's other tool... who knows that Gradle has two tools? Probably the Gradle employees in the room. So Gradle build tool and another tool called Develocity, which is a developer productivity tool, which works with Gradle, Maven, Bazel, and sbt.
What it does is it can do things like measure how long you're spending on your build times and on your test cycles, and not just in CI, because we can probably get that information in CI, but also on your local machine. And until I started working at Gradle, I didn't even think about measuring how much time I'm wasting on things like running local builds, and I certainly never would have thought of measuring that across the whole team and thinking, you know what, we've got a team of 20 developers, the build time, even if it's in my mind, something low, like six minutes... for Quarkus, I don't know, is it shorter or longer?
Holly: It is very long. With Quarkus, we completely got frog boiled on our builds. So our builds, if you include the tests, our build was about 40 hours of build time. So we had to massively parallelize it, but then we kept running out of machines. And then we started using Develocity and everything has got better.
Trisha: Happily ever after. But the fact is that you don't know you have a problem until you start measuring. So you can use a tool like, for example, Develocity, to figure out how much time people are spending on things. Of course, if your build times, your local build times are only like, you know, 90 seconds or 20 seconds or whatever, and I speak to a bunch of people whose local build times are well under five minutes, then you know that's not necessarily the area you're going to optimize.
Even if you do end up optimizing things like the build and test cycle time, you're still only optimizing, let's say you can chop 30% off that. Let's say you can really optimize that. But this is the coding time still. We're still talking about the time when we write code, whether we're writing code or building it or whatever.
How do we get some visibility over all the rest of the stuff that you're doing, particularly things like meetings? My favorite one is "Other". Okay, I would really like to see what "other" looks like. So, a lot of the productivity metrics that we look at have been focused around the writing new code and improving code side of things, like how many issues do you fix?
How many lines of code do you write? How long does your build take? Because it's easy to measure. And actually we're not necessarily looking at the holistic view of what is really taking developers' time. And of course, what gets measured gets optimized. So if you're measuring build times, then you're going to optimize build times.
If you measure lines of code, you're going to optimize lines of code. If you measure meeting times, you can start reducing meetings, but really you need to have a much bigger view. So there's a fairly new framework for looking at developer productivity, the SPACE framework.
And so the space framework talks about five different areas to look at in terms of your developers' productivity, and those areas are: satisfaction and well being, which is obviously one of these fluffy things, we know how we feel and how do you measure that by using a tool?
I'll tell you what, let's just put a heat sensor in here to figure out how satisfied I'm feeling today. Satisfaction and well being. Performance, performance in this case specifically means around quality and does the application do what the users want? So kind of the performance and quality of the application.
Activity, which covers a lot of the things that we've been talking about. Lines of code, commits, pushes, merges, those sorts of things. Communication and collaboration. Again, a bit more difficult to measure. Efficiency and flow. And I think flow is impossible to measure. And yet in my mind, the most important thing is how easy is it for us to get into the state of flow?
How often are we feeling flow? Because flow is where we're really able to actually get that work done and be really productive.
Holly: And if you're a fan of DORA, Space is a natural successor to DORA. The lead author is the same.
Trisha:: SPACE is a much, much bigger set of things to measure and includes things like asking developers how they feel, do you feel productive? Are you satisfied? Which a lot of companies I think are uncomfortable with because they're like, well, that's just feelings, right?
That's not so important as metrics. But anyway, go away and have a look at this because there's a lot of interesting information in there. Other thing I wanted to talk about around this area, you'll see at the end it talks about efficiency and flow, but I really wanted to talk about what efficiency means and why efficiency is or is not important.
So in organizational physics, which I read fairly recently, this was in the context of different parts of an organization. So you have a efficiency parts of the organization like accounting, and effectiveness things like R&D and stuff like that. So efficiency means to do things in the right way, repeatable, controllable, scalable.
This is things like QA and accounting and finance and things like that. Effectiveness means to do the right thing. Trial and error, risk taking and adaptability. So this is actually at least 50 percent of what we do as developers. Are we building the right thing? Are we solving the customer problems?
Are we taking risks and trying new stuff? Are we being innovative and creative? And the other interesting thing about this is in the book it says, unless you design against it, efficiency will tend to overpower and snuff out effectiveness. And I think we've already seen this when we're talking about lines of code.
If our metric is lines of code, we can really efficiently write lots of lines of code. We could do hundreds in a day. Then we have to think about the effectiveness. So whenever we're talking about developer productivity, particularly measuring it, we need to understand there are at least these two ends of the spectrum on what we want to balance.
Are we, again, we've heard this before in other presentations, are we building the right thing and are we building it right? And we need to understand that those two things need to be held in balance. Back when I used to work in London, I used to work with Dave Farley. When I used to pair with Dave Farley, I would be like trying desperately to write lots of lines of code, because that's what we do as developers.
Write, tappity, tappity, tappity. But Dave, he would sit there and he would think about the problem. And I was like, Dave, you're not typing. Are you working? And he's like, his eyes closed. And he was thinking "the shape of the code is like this. And if we put it over here, and what sort of test do we need?"
And he would be asking questions and, but he wouldn't be typing. And Dave is one of the most effective developers I've ever worked with. But it's not because he writes loads of code. It's because before he writes loads of code, he thinks very carefully about what he's writing and is he doing the right thing?
In contrast, I worked with another boss soon after that who wrote lots of lines of code and three months later rewrote all the lines of code. So let's talk about space to think. Let's talk about not typing. Let's talk about not doing the activity. And if we're not doing activity, then we're bored, right? Especially as developers, we have a tendency to hate boredom, don't we?
Holly: Yeah. Another tip, if you're talking to your manager about this and you go to your manager and you say, I would really like to create boredom among the team, they tend to not respond well to that.
But the word you can use is space. You can say, I would like to create more space, mental space in the team. And that goes down better.
Trisha: And the reason we need mental space is so that we can do the thinking. I've been thinking about this more and more recently. It's not about the doing, it's about the thinking.
And it's so hard to measure the thinking, and yet so much more important.
Toil is bad. Toil being the building, and the testing, and the frustration, and the friction, and the things that get in the way of us doing our job. And I think we could all agree with that. Toil, bad. That's good. I mean, yes, it's good that it's bad.
Yes, definitely. But idleness and sitting around and not typing is, is good.
Holly: Yeah, it's a little bit of a harder sell to explain why doing nothing is good. But there is solid science to back this up. Kevlin mentioned this yesterday as well. There is a part of the brain or areas of the brain that make up the default mode network.
And the most parts of the brain, if you're not doing anything, your brain activity is lower, but the default mode network, when you're not doing anything, the brain activity there gets higher. So suppressing, sort of doing nothing with the rest of your brain then means that this area has an opportunity to do stuff.
And this area, the default mode network, is what's involved in things like creativity, in problem solving in sort of digesting the events of the day. So it's really important that you allow your default mode network time to do stuff. By doing nothing. A classic way to do this is to have a shower.
Showers are a wonderful debugging tool. I always think all offices should have showers just for the purposes of debugging. And I'm not alone. There was research. This research was by a shower company, so it was slightly biased research, but they found that 14% of people, which includes me, took showers specifically for the purpose of coming up with ideas.
It's not very environmentally responsible to spend all of your time in the shower, and it's bad for your skin as well. So there are other things that you can do. I find running really effective for problem solving. And in fact, I wrote this slide while I was running. I was like, hey, I know what the slide should look like.
Trisha: I brought my knitting to prove that I really do do knitting. That's the thing that I do. And one of the reasons why I do knitting is that it frees up my mind, but it ties up my fingers and frees up my mind. Cause if your fingers are free, you're just going to check your phone or you're just going to eat something or you'll do something else with your hands.
And if you tie up your fingers, you kind of force your brain to be like, Oh my God, I don't have any stimulation right now. I'm going to have to think. It's a crazy thought.
Holly: One challenge I did have with running was I would have so many ideas and then by the time I would get back to my desk, I'd get distracted and the ideas would all leak away.
So now if you are also running for work, voice memos on your phone save everything. You sound ridiculous when you listen back to it because you're sort of gasping. But if you can live with that, it's okay. If you don't want to run or shower, there are many other options. Um, so walking very good, gardening very good. Kevlin mentioned unloading the dishwasher.
Trisha: I added laundry on the back of that because I do a lot of laundry. Because I work from home and do a lot of laundry, I'll be like, I don't want to do the laundry, I want to fix this thing. And I'm like, yeah, but you're not fixing that thing. Get up, do the laundry, hang out the laundry and your brain will go bing.
Holly: Oh yeah, that's the answer. And with all of these, they sort of have a bonus, which is that at the end of it, The dishwasher is empty and the laundry is done, or in the case of knitting, you have clothes.
Trisha: I have actual clothes, which my children do wear!
Holly: I'm a very small digression into knitting, because knitting seems very girly, but knitting can actually be used for very scientific purposes.
So if you are doing mathematical topology, you can knit shapes that cannot be visualized otherwise. and If you are into knot theory, then you can also do interesting things with, with knitting and knot theory.
Trisha: I love the fact that I didn't even know there was such a thing as a knot theory until I read this slide.
Holly: Knot theorists also use their special scientific skills to uncover, to discover new necktie knots.
Trisha: Why do you need that? You don't.
Holly: Who says science is useless?
Trisha: That's true. I saw while we were coming up with the idea for this talk, apart from the fact that obviously we just wanted to draw a lot of stuff on the slides, I was watching a Moongirl and Devil Dinosaur episode with my children. And there was an episode in that where she tried to fast forward through scrubbing the floors and cleaning the this and doing the that because it's really boring and who wants to do that stuff.
And at the end of the episode, she realized that the things that what was really happening during those exercises is that she was spending time with her dad and she was hearing stories and they were talking to each other about stuff and she was saying the interesting stuff happens in that dead time. It's not about scrubbing the floor. It's about all the other stuff that goes on at the same time, the conversations and the learning and the brain activity.
Holly: Also linked in the resources, should you wish to watch the episode. So really, you know, embrace that dead time. Use it for problem solving, use it for thinking, use it for staring into space, cause that is problem solving.
And also you are totally allowed to use the dead time for play, but whatever you do, don't just move efficiently from task to task cause you're not going to be effective. You've got to make that time for boredom and you've also got to make time for play. And if boredom is a hard sell to management, play is probably an even harder sell, but play actually has a lot of business value and it has business value in really weird domains where you wouldn't expect it.
So for example, piglet litters grow faster if they play more. And then in business, you know, we see really strong correlations between people's happiness and their boredom. and their state of mind and, and how much work they do, how productive they are. And then the question is, okay, well, I would love to be happy at work, but how do I get happy at work?
It's not just as simple as watching cat videos. It needs something bigger to change.
It can actually be as simple as watching cat videos. research found that people who had watched a cat video had 12% greater productivity than people who hadn't. Obviously, you need the balance if you watch all cat videos, you'll never get anything done.
But fundamentally, what this is showing is that fun is good for business. There is a ton of research for this. DORA found it many years ago. We work in a creative industry. People don't call it a creative industry. It is totally creative and play helps innovation, play helps creativity, and that makes us happy.
Trisha: We even measure this in the new framework. So for example, SPACE, one of the key things to measure is developer satisfaction. In order to be productive developers, generally developers who are more satisfied are more productive. And so we're measuring those things as well.
In short, writing code makes you happy and makes the company profit. By all means, use this slide anytime you want to sell that to management. They'll be 100 percent behind you on that.
Holly: And I mentioned we've known this for a long time since the early DORA research. We've actually known this for a much longer time.
How many of you speak ancient Greek? There's always one. So I know the ancient Greek is a little bit challenging. What Aristotle said was pleasure in the job puts perfection in the work. And so we tend to think of it as a trade off between happiness and productivity, but it is not a trade off.
They're actually on the same side. It's a double win. This by the way is a see saw folded in half. Before I drew it, I tried to find some reference images. And actually, I did find reference images of see-saws folded in half. It is a thing. Really the point here is that it is a double win.
It is not a trade off. Sometimes we talk about co benefits or, win win. Or if you're American, you call it a twofer. If you're not German, you call it an Uberwinden. But if you are German, you know that doesn't mean anything to do with a double win. But it still sounds cool, so I include it in the slides.
With all of these, you know, really the, Yeah. And the idea is that, you know, it's not a zero sum thing. We've, the way to improve performance is also to fix the other things or it's, you're just not there.
Trisha: Exactly. There's a quote from The Goal and it says, "the only initiatives that will positively impact performance are ones which increase throughput while simultaneously decreasing cost". So you have to look at not just one thing or the other. It's not cutting costs. It's not forcing people to do more. It's both things, reduce the friction, reduce the toil, improve morale, improve the fun, and you get more productivity.
Holly: And as a counterexample, of course, we have the double win when we're happier and more productive. We also have the double lose when we use AI to generate a completely bloated code base and at the same time manage to destroy the planet. So fail, fail, lose, lose. So we're out of time, but what we really hope you'll, you'll take away from this is that be careful how you measure your lines, your productivity.
Don't use lines of code. Do try and get rid of that drudgery, because it stops you being effective. When you get rid of the drudgery, you will be happier. So it is a double win. And really, that downtime that seems like it's waste is not waste. It is actually making you better at your job.
Holly: And with that, thank you all very much.
Trisha: Thank you.
1 Note to aspiring speakers: that's NOT how presentation are born. An abstract is produced in a rush about 24 hours before the CFP closes which is specific enough to indicate what the talk is about, and vague enough to allow wiggle-room if, during the course of creating the talk, you realise that your original idea isn't as interesting as the direction the talk is now taking. You spend the next 3 months thinking about the talk occasionally in the shower, emailing your co-presenter to apologise for doing nothing on the talk so far, and generally getting on with other stuff. Then, one week before the talk (two weeks if you're really organised), you panic and start throwing slides together, spending every minute thinking about the talk, re-writing it at least three times, and maybe, if you're lucky, running through it in your head once the day before you give it2.
2 This is not the best way to create talks. It creates stress, provides very little time for practice, feedback and improvement, and often leads to panic attacks the morning of your presentation. 1 out of 10, Do Not Recommend.
3 Incidentally, I'm working my way through Brandon Sanderson's lectures on how to do fantasy writing, and I'm seeing some techniques that I use for creating presentations and videos, discovering a lot more, and, more importantly, learning about traps that writers fall into that can be avoided. Writing, re-writing, and infinite revisions is something I'm guilty of, and it prevents me from Just Getting Something Out. So I'm using my new-found passion for my blog to encourage me to Just Write.
