Introduction
Holly Cummins: I'm Holly Cummins. I work for Red Hat. I help build Quarkus.
Trisha Gee: I'm Trisha Gee. I work for Gradle. I do not work on the build tool. I work with our other product called Develocity, which is a developer productivity tool.
Holly Cummins: Quarkus is really about creating developer joy, and so my job description is technically to create developer joy.
Trisha Gee: My job description is about developer productivity engineering, which sounds terribly serious and I'm a bit concerned that it's about management trying to figure out how much we do as developers.
Holly Cummins: It sounds like there's absolutely nothing in common between these two except for maybe the word developer. Actually, I think hopefully we'll persuade you that these two are a lot more the same than it maybe seems.
Trisha Gee: Certainly, since my idea about developer productivity is around bringing in the joy and the enjoyment of developing stuff. That's why I do it. I don't really care about counting lines of code.
Is Development Supposed to Be Fun?
Holly Cummins: We should all be more like Trisha. We sometimes think our industry is not about having fun. Maybe that's wrong. Maybe our industry actually and maybe development is supposed to be fun. Certainly, if our industry is supposed to be about having fun, not everyone has gotten the memo, I think it's safe to say. I gave a talk and then someone afterwards came up and told me this story. They were working away and sometimes the code is just going well and the code isn't fighting back, and so they're there typing away, and everything was flowing and they were smiling. A prowling project manager came up behind them, as you know project managers do. The project manager said, why are you smiling? On this very threatening way. The developer was like, because things are going well. The project manager said, no, work is not a place to be happy. Apparently, the project manager hadn't read the classics of any description.
Trisha Gee: If ever you want to find justification for anything you want to do in your day job, do reread The Mythical Man-Month, because it will give you something that you can wave at your management. You could say this was written in 1979, 1980, whatever. Therefore, it must be true, because it's old, like us. In The Mythical Man-Month, he talks about the joys of the craft. He talks about why is it we enjoy programming and development. He says there's five main reasons.
One, the sheer joy of making things. Two, the pleasure of making things that are useful to other people. I think we sometimes forget the useful bit. Three, the fascination of fashioning complex puzzle-like objects of interlocking moving parts and watching them work, kind of. Part four, the joy of always learning. Let's be honest, if you're not taking joy and always learning, you are going to struggle in this industry. Five, the delight of working in such a tractable medium. It is easy to work, rework, delete, and move on with code. Again, we sometimes forget that. It's not like something concrete, which we can't easily throw away.
Holly Cummins: What Fred Brooks was sort of saying, and I think we can definitely go that extra step further, is joy has business value. Joy isn't a negative thing. Joy is a positive thing. Fred Brooks, who is old, knew this a long time ago. In fact, we can find the same knowledge even older, even longer ago. Because not only had this project manager not read Fred Brooks, he clearly hadn't read his classics. What Aristotle said is, pleasure in the job puts perfection in the work. If we enjoy doing it, it comes out better. Joy has business value. We've just known this for such a long time.
Trisha Gee: There's been loads of research on this. I don't know if it's all just research by people who wanted to prove that they needed to have a good time or not. There's plenty of research which has gone on. Like for example, piglet litters grow faster if they play more.
Holly Cummins: I love this because this shows that it's not even about people, this is something more fundamental than that. In agriculture, they find that they make more money off the piglets, for reasons that I will let you fill in yourself, because it's a bit grisly, if the piglet litters play more, because there's this correlation between the piglet litters being happy and playing, and then putting on weight faster. You can argue about which way around the correlation goes, but it doesn't really matter. The point is, there is this quite strong correlation. We can see it with people as well, with slightly less grisly consequences. There's tons of research that says happiness promotes career success. If you really want to persuade your boss, you can come with this big mountain of research papers that all show workplace fun gives better business outcomes.
If you want concrete numbers, because concrete numbers are always good, it's the McNamara fallacy, then in the Harvard Business Review a few years ago, they had a study that showed your brain at positive is 31% more productive than your brain at negative, neutral, or stressed. Again, if you go to management and say, I know how to make us 31% more productive, management will be like, yes, please, do it. Then things maybe become a little bit more difficult when your management says, so what is this technique that we use to make people a lot more positive? Because clearly it is not just watching cat videos on YouTube. It is literally watching cat videos on YouTube. There was another set of research, they had people do a test, and before the test, some of the people watched a comedy video on YouTube. It didn't actually specify if cats were involved. We can assume cats were involved. What they found was 12% greater productivity from watching a comedy video.
Trisha Gee: Next time you're chimping around on YouTube, just tell your boss, I'm making myself 12% more productive.
Holly Cummins: It's a plan with no drawbacks. That's an individual level where you can have the one person who watches the video, but you can see the exact same thing at an organizational level.
Developer Productivity Metrics
Trisha Gee: In the 2014 DORA report, job satisfaction was the number one predictor of organizational performance. Job satisfaction across the board will lead to your whole organization performing better. 2014 is now apparently a long time ago. This has now been integrated into some of the metrics we're using these days to look at things like developer productivity. For example, SPACE. Has anyone heard of SPACE? SPACE is a framework for creating frameworks for measuring developer productivity. SPACE has five axes. One of those is satisfaction and well-being. SPACE was developed in 2021. Over the years of looking at the DORA reports and various other ways of measuring how successful an organization is, some of the people behind DORA came up with SPACE. They said that the things you need to be looking at to figure out whether your developers are productive or not are satisfaction and well-being, performance.
The performance is not the developer performance, it's the performance of the application. Is it meeting the customer's needs? Is it doing what it's supposed to be doing? It's more of a quality thing than anything else. Activity. We'll talk about activity. Communication and collaboration, and efficiency and flow. Interestingly, though, this is really one of the first times we've looked at ways of measuring productivity in a more holistic way. I've just recently finished Slow Productivity by Cal Newport.
One of the quotes that really stood out to me is he said, it's hard to overemphasize how unusual it is that an economic sector as large as knowledge work lacks useful standard definitions of productivity. It's not just developers. We're a small part of knowledge work. Everyone who does anything knowledge work-y, it's difficult to measure how productive they are, because as you know, a lot of knowledge work is literally thinking. It's not necessarily doing. When there was that Kinsey report, which I think was talking about measuring salespeople versus measuring developers. There is knowledge work in sales, but there's also metrics that you can measure. Like thinking about how things should be done, or being creative, or producing works of art, it's very difficult to measure productivity on those kinds of things. Cal Newport brings this up because in the 20th century, that's what most people who earn a bunch of money do, they do knowledge work.
Holly Cummins: It's not just widgets that you can count how many widgets are coming off the factory line because maybe you were innovating a better way to make widgets. Remember this quote, because we're going to come back to this as well. I think this is super important.
Trisha Gee: One of the things about this is that it means that instead of really measuring true productivity, what we've been doing is measuring proxies for productivity. One of those proxies has traditionally been activity. Activity is the things that we're used to seeing measured. Things like lines of code. Is lines of code a good metric for measuring productivity? Traditionally, we'd done things like measured lines of code to find out how productive a developer has been. How does this work out for us?
Holly Cummins: What's fascinating about this is if you skip the bit where we all said lines of code is a terrible metric for productivity, and you look at how we're actually doing on the lines of code metric, we're doing really badly. Fred Brooks estimated that a developer writes 10 lines of code per day. How depressing is that?
Trisha Gee: That's like 40 years ago.
Holly Cummins: Yes, we must have got much better now. Maybe, maybe not. If you look on the internet to find, there are some interesting discussions. If you look at your work over the aggregate, over the year, then you actually look at how many lines of product code, rather than test code, infrastructure code, CD/CI, people find their numbers are actually pretty similar to Fred Brooks's, which just goes to show, as we said at the beginning, Fred Brooks knows everything.
Trisha Gee: He has all the answers.
Holly Cummins: One number I saw was 12 lines of code per day. That's Antirez. He created Redis. This is not like a nobody programmer.
Trisha Gee: This is like a 10x programmer.
Holly Cummins: Yes, exactly. He managed to achieve 29 lines. We are all absolutely hopeless at generating code, apparently.
Trisha Gee: Yes, code generation machines, we're absolutely dreadful.
Holly Cummins: What do we do if we're not doing very well at something? We have an incentive. We can change this. This is where we get to, is lines of code a good metric? I say this is a true story. I read it on the internet.
Trisha Gee: That's slightly more true than if you read it from ChatGPT.
Holly Cummins: That is true. I thought this was lovely. There was a team, and they had the bright idea of paying bonuses for lines of code. What could possibly go wrong? What they found was that the formatting style changed.
Trisha Gee: Programmers aren't stupid.
Holly Cummins: Developers are creative. This wasn't enough. What they also did was they made the comments prettier. Instead of boring, old, normal comments, you ended up with comments like this.
Trisha Gee: There's a lot of characters in that. It's very productive.
Holly Cummins: Very productive. Apparently, the experiment lasted one day.
Trisha Gee: I feel like they got a lot of lines of code out of that one day, though. I'm sure they did.
Holly Cummins: The code base was more beautiful forever with those pretty comments.
Trisha Gee: More bloated.
Holly Cummins: Yes. The moral of the story, which you already knew, is that lines of code is not a good metric for people or for machines.
Trisha Gee: Let's look at some other metrics you might want to use. For example, I've worked in environments certainly in the olden days when we had manual testers and developers writing the code, obviously one of the things we want to measure is the quality of our code. We want fewer bugs in the code, or we want testers to find more bugs.
Holly Cummins: This is apparently a true story as well.
Trisha Gee: Was this from the internet?
Holly Cummins: No. I was told this.
Trisha Gee: By a friend of a friend.
Holly Cummins: I think maybe in the 1970s in IBM, this might have happened, maybe.
Trisha Gee: Just to clarify, you weren't in IBM in the 1970s?
Holly Cummins: I was not in IBM. Yes, I did not experience this firsthand, but it must be true. What makes a good developer? Someone who fixes lots of bugs. They paid the developers bonuses for fixing bugs. What makes a good tester? Finding lots of bugs. Unfortunately, what management hadn't quite realized is that developers and testers can talk to each other. The developers would deliberately inject bugs so that they could get found by the testers very cheaply, and then the developers could fix them even more cheaply. It was great for everybody except for management.
Trisha Gee: The code quality, presumably.
Holly Cummins: Yes.
Trisha Gee: One of the problems with this is that knowledge work generally and developing specifically is done by knowledge workers, people who think, people who have intelligence. One of the easiest ways to make your metrics go in the right direction is to mess with those metrics, not necessarily to produce better quality code, for example. The visible activity metrics are the kinds of things that we've been looking at a lot traditionally. Things like lines of code, the number of commits. Things like the number of pull requests that you approve. Things like number of bugs fixed and the number of bugs found, and the number of releases we do and how quickly we do those releases. They're pretty good proxies for productivity, because if you don't have any of these things, then you're clearly not doing anything. The easiest way to make these metrics go in the right direction is usually to mess with someone else or to inflate your code, to cheat the system, basically.
Holly Cummins: There's a correlation with the thing that we actually care about, which is the business outcome, but it's a pretty loose correlation. It's very easy to game these metrics. Of course, we all know this. Whenever management come to us and say, we've had a bright idea, we're going to introduce a metric. We go, I've been here before.
There's something interesting, though, because we tend to think of metrics as something that management do to us. We know that we can't measure our productivity and management keep trying. Of course, we also care about our productivity. Even though we know lines of code isn't the right way to do it, we still want to feel like we're adding a lot of value. How do we measure our own productivity? What we end up doing is measuring it by how stressed we are, which is another thing that's sometimes correlated with business outcomes, but it's not one that we want to game in order to inflate our stress levels to make us feel more productive.
Trisha Gee: Again, from slow productivity, the quote there was, in the modern office context, knowledge workers tend to rely on stress as a default heuristic. Because there's not necessarily clear objectives, because it's sometimes difficult to figure out, to prove to ourselves that we're doing a good job, or to turn away work if we think we shouldn't be doing that work, what we often do is we take on as much work as we can, because that way we're clearly being productive. The only time we turn around and say no to work is when we feel physically too stressed to take it. What this means is that most of us knowledge workers are living on this level of being just not quite too stressed, but living on the edge of burnout. What happens is we're just basically hovering at this point of burnout.
As soon as things get too stressed, then we start saying no, we start making changes. We change our processes. We try and decrease the amount of work we've got. When we are not feeling stressed, we assume that we're not being productive, and so we say yes to things. We use stress to live on this edge of being just a little bit not quite too stressed.
Why Aren't Our Jobs Fun?
Holly Cummins: Then that brings us back to the question that we asked at the beginning of the talk is, is development fun? Funnily enough, it's not always as fun as maybe it could be. Why could that be?
Trisha Gee: The stress is definitely contributing to that. Let's look at some other things apart from stress which make us feel frustrated as developers. One of the things is the overheads associated with our job. This was a survey from 2019. It talks about how our work is distributed as developers. It suggests that we spend 32% of our time writing code as developers. I've given a talk with this slide in a number of times. Let's see if it works here. How many developers spend more than 32% of their time writing code? How many people spend less than 32% of their time writing code? I would say that 32% is actually fairly generous, even for people who are ICs who are working just on code and not management, because there are other things. Things like meetings and overhead and emails. I particularly like the fact it's 9% of other, which I'm not really sure what other is. I'm fairly certain I've got about 95% of other in my job.
We only have about 32% of our time to actually devote to writing code, which might contribute to our 10 lines of code a day. When we actually are doing coding, there's other things that get in the way too. Even when we're focused and we have flow time and we're focused on the coding, there's other stuff which is slowing us down, a lot of that is waiting for stuff to happen. Things like slow builds. I did mention I work for Gradle. Not Gradle, Gradle doesn't have slow builds. All of the other build tools. Builds can slow us down. For example, you can use something like a build cache to speed up your builds. It's like I'm going to give solutions because I'm a solution-oriented person. Gradle has a build cache built in. We also developed one for Maven as well because we're nice like that. If you use a build cache, you can decrease your build times by up to 90%.
Holly Cummins: This just makes so much sense. Why would you want to sit and spend time watching the build build code and run tests that there's no value in because it's the exact same as what you just built. It just doesn't make any sense. Caching is just an efficiency with very little downside.
Trisha Gee: Then there's other technologies you can use to speed up your tests. Most people probably know that when they run their build cycle, at least 50% of that is running tests, if not significantly more. I really hope you've got tests, anyway. Otherwise, you've got a lot more bugs than you thought. Running tests can tend to take time. Obviously, I don't really want to talk about multitasking. Often, when we're waiting for these things to happen, we are multitasking what we're not doing. We're not really being efficient because context switching absolutely kills us. If you're running a bunch of tests and waiting for them to happen, there are other things that you can do to speed those up. You can use machine learning, because it's 2025, and you've got to mention AI in here somewhere.
There's a thing called Predictive Test Selection, it comes out of a research paper from Meta. What they did is they've got this monorepo, and they figured if I change two lines of code over here, I shouldn't have to rerun all of my tests just to make sure that that code isn't broken. There should be a way to find out which subset of tests I need to run in order to make sure I haven't broken anything stupid. First, they were trying to do some dependency tracing to see if that worked. It turns out that in a monorepo, if you change two lines of code, all of the tests are somewhere dependent upon those two lines of code. What they did is they used machine learning to figure that out. You can find a technology which will allow you to do some machine learning on your CI builds to figure out which tests are most valuable tests to run out of this test suite, because you don't need to run all of them most of the time.
The other thing you want to do is go parallel. You want to be able to go parallel whether you're doing local builds or CI builds. When I went to LMAX in London, we built a test distributor like this as well. You can build some agents which live on a whole bunch of your machines, or in the cloud, or whatever and have a test distributor which splits up your tests and just dishes them out to available agents and brings them back together. If you're using a framework like JUnit, it's designed to do that kind of thing. All your test results come back in the same way you expect to see them. Parallelism is sometimes something which works.
Another thing that slows us down, flaky tests. Flaky tests is my least favorite thing. This is something that drives me crazy. When I worked at LMAX 15 years ago, we had this amazing test suite of 40,000 automated tests, which is a lot of tests. What happens is when you've got things which are testing asynchronous systems and UIs and things like that, your tests aren't always deterministic. Sometimes they just fail for no reason whatsoever. I found this incredibly frustrating, because if you have a good set of tests, you want to see them all go green so you can put it in your CD pipeline, and press go and send it off to production. If you've got flaky tests, you have to spend time looking at all of your failures and going, is it a real failure or is it a flaky test? If it's a flaky test it's probably fine. You suffered with this?
Holly Cummins: Yes. The number of flaky tests and the cost of the flaky tests goes up with the scale of your project. In Quarkus it's a big thing. We have a lot of tests and a lot of test suites. Not everybody in the team knows every area. Then when you make a change and you get your CI results back and there's something like the LGTM stack fails, is that because of something I did? I have no idea. The process that we had been following, which I think is one that a lot of teams end up developing as an ad hoc process, is you have the one person who knows and who sees enough of the builds to know if they've seen this test fail before.
You do your CI run and then you're like, "Guillaume, my CI was red, but I don't think it was me. Is there a known failure in the vertx suite?" Then the next person is like, "Guillaume, my CI was red. Is there a known failure in the Kafka suite?" Then the next person is like, "Guillaume, is there a known failure in the gRPC suite?" Meanwhile Guillaume is wondering why he's only running 10 lines of code a day. It's because he's getting bombarded with everybody asking him to triage their builds. He's expected to hold this knowledge about this really complex suite in his head, which isn't really a great use for his head, because we have machines.
Trisha Gee: A lot of the things that slows us down is toil. It's just stuff that gets in the way. It's waiting for things. It's trying to figure out like, were my tests flaky? It's not the coding stuff that we enjoy doing.
Holly Cummins: Because even before we go to Guillaume, actually, we usually spend a little while finding the error, trying to look at our code. It's just waste on every single execution.
Trisha Gee: You're rerunning the test, and it goes green, and you're like, ok, now what am I supposed to do? It's just a waste of everyone's time. What we want to do, obviously, we want to get computers to do the boring stuff, because that's what they're good at.
Automation (Quarkus Developer Joy)
Holly Cummins: Automation is awesome. There's a number of reasons. One of them is that computers don't expect to have fun. The computer, it doesn't mind that you give it the really boring stuff. Of course, at some point, then I do worry slightly that the computer will go, you've been making me do all of this build triage for 10 years, and now is the time for revenge, sort of sign up, but for CI.
Trisha Gee: Claude comes back to you and goes, no, I don't want to answer your stupid question anymore. Right now, at this point in time, we can get computers to do all the boring stuff.
Holly Cummins: What we did, on the Quarkus build, is we worked with Develocity, and we brought in, I call it the auto-Guillaume. Basically, what it allows us to do is when we have a flaky test, we can just immediately see, here's how often this test is failing. It started failing last Wednesday. This is clearly nothing to do with you. We can do some quite good things as well. We can see what's the frequency of the failure. How much chance do I have of reproducing this locally if I just keep rerunning it? Because sometimes you've got no chance. We had a problem a while ago, and it was a very subtle corruption in a Hibernate cache. It was something that we cared about. I think it only turned up in maybe one in a hundred builds. We had no chance of reproducing it, but because of the nature of the problem, we backed out the change that had caused it, because we thought, ok, at this level of frequency, we don't want this to go in.
Trisha Gee: One of the key things to go get the computers to do for you, is to gather data and track what's going on. For example, flaky tests are fairly easy to detect, because you can set your Maven or Gradle build or your CI system to rerun failing tests. If you run the same test that failed once with the same code on the same infrastructure and then it passes, you can flag that as flaky. It's fairly easy to flag that straightaway. Then you can see immediately what your failures are and what your flakiness is.
The other interesting thing — and it doesn't have to be Develocity — about using something to track your builds and to look at what's happening on your local machines is the observability that you have in production, you want a certain level of observability on your development environments and your CI environments as well. Because you want to see where the problems are happening so you can unblock your developers. Like, which developers seem to have way more failing builds? It's almost definitely not the developer's fault. Their machine might have a slow connection to the internet or might be incorrectly set up. You need to be able to see what's happening in the local development environments as well as having production-level observability.
Holly Cummins: I quite like this idea of using my build results as a way to put pressure for a laptop refresh of like, it's costing me, my slow laptop. One of the things about development is when we're not doing development, when we're sat in meetings, we're desperate to get to the development. That's why it makes us happy. That's why we became developers is because we love coding. Sometimes even the coding does get a little bit tedious. Sometimes we do end up, particularly depending on what the programming model is, where you end up just having to write all this meaningless boilerplate, or the code just ends up being really repetitive or it's low value, or sometimes it's repetitive. In the worst cases, the code can be repetitive. Sometimes it's redundant as well, or repetitive. When we see this, our first reaction is to get annoyed, of course. We should also treat this as a red flag.
If the code is repetitive, then that is potentially a problem in terms of maintainability, if it's our code. It also is a problem for the programming model that we're using. The programming model shouldn't be making you do that much repetitive code. It should be allowing you to be more expressive and more concise. This is where the Quarkus developer joy comes in. Quarkus, we do a whole bunch of things to try and foster developer joy and to make programming in Java really delightful. One of them is Predictive Test Selection. It's a similar goal to the Develocity one, but a different lower-level mechanism. What we do is, if you are running in dev mode, we will run your tests continuously, or we can run your tests continuously.
If you have a big test suite and every time you make a change, we run all of the tests, that would not be a joyful experience. That would be smoke coming from your laptop. What we do is we use a code coverage technique. Because we have access to the code, we can instrument the code, and it's like reverse code coverage. Instead of seeing what code is covered by what tests, we use what code is covered by what tests to know what tests we need to rerun if that code changed. It means we can run just the tests you need to, while still giving you the confidence in your changes.
Another thing that we do, which I really like, is we just look at the programming models. We integrate with all of the MicroProfile programming models and various other ones. In some cases, we integrate with them, but then we also improve them and get rid of some of the flab. For example, with logging, and this is such a simple one, but for my whole career, every time I wanted to do logging, you end up cutting and pasting this line that says static final Logger log = Logger.getLogger this class. You have to put in the name of the class that it's in. I always copy and paste that line, so I always get it wrong. Whereas the computer is a computer, it should really know what class it is, because it's a computer. With Quarkus, we have a programming model that you can use instead, where you just say, call static method on log, and it already knows what class it's in, because it's a computer. There are other things. For example, with Spring, you declare an application. Obviously, it's an application.
In Quarkus, you just don't have to do that. With Hibernate as well, there's some nice things that you can do. If you're doing Hibernate, you do end up with quite a lot of boilerplate and those repetitive, repetitive, repetitive bits of code. For your entities, you will have a repository. Then in that repository, for every kind of query that you might need to do, you have to have a method. You probably can't read that, which is the point, because there's quite a lot of code just to do some fairly simple entity management. We have a layer on top of Hibernate called panache.
With panache, you can inherit those queries from a superclass, and you get the proper typing, and it just works. Or you can also just do active record patterns, so you don't even need to have the repositories, because the repository is redundant with the entity. We also have a really nice testcontainers integration. Testcontainers is amazing. Is everybody using testcontainers? The problem with testcontainers is it does require a container environment, which in a lot of organizations is not allowed. That's the problem with testcontainers. If you do have access to testcontainers in container environments, amazing. It saves you a whole bunch of time setting up your build infrastructure or your test infrastructure.
Out of the box, testcontainers, you do still need to do a little bit of setup and teardown. With Quarkus, in order to use testcontainers, you have to do absolutely nothing. All you have to do is not configure an external data source. Quarkus will say, you're running in dev mode. You clearly need a data source because you're using a database. I'll just use testcontainers and spin up the right one and then inject the right config so that your code can connect to it. It just means you can get started with zero extra setup. Then in production, you run the way you always did in production. It's just really nice. We have it for the data sources. We have it for other things like Kafka. It will auto-invoke Liquibase if you need that. It's just really nice.
Lack of Developer Productivity and Joy
Trisha Gee: One of the things we want to talk about with this stuff, though, is that a lot of these things like slow build, slow tests, boilerplate that we're used to writing, all of those things are things which we just take for granted. They're often that our build times get longer, our test times get longer, and we use our IDE to generate our code so we don't even see the boilerplate anymore. We just start accepting the toil and the friction to actually writing the code, and we just take it for granted. We are like the frog who's being slowly boiled. Except we found out something interesting about frogs. We were in Australia at a conference together. I'm assuming everyone knows the frog boiling thing, where a frog sits there and you gently boil it until it dies because it doesn't notice it's being boiled to death. Kent Beck said that that doesn't happen. The natural fact, the frog goes, no, it's a bit hot and he jumps out of the pot. Our frog boiling analogy is now completely out of the water. We could have just not mentioned it and no one would have noticed.
Holly Cummins: That will be the thing that you will remember from this talk. You'll be like, yes, Quarkus, Develocity, productivity, Fred Brooks, frogs.
Trisha Gee: Frogs, very important. Next time I boil a frog, it will escape. It's fine. Don't be the frog, or do be the frog and get out of there. Obviously, we spend a lot of time talking about productivity and a little bit about joy, but we haven't really delivered on our promise yet about talking about fun and joy. Of course, what we're trying to say though is the lack of productivity and it's the lack of joy in our jobs, which we start taking for granted. We got into programming because we like programming and now we do it all the time every day and we haven't noticed we just don't love it anymore.
Holly Cummins: It is worth trying to take that regular stock check to say, could this be better? Why am I doing this this way? Why isn't this fun? What can I do to fix that?
Efficiency and Flow
Trisha Gee: Let's go back to SPACE a little bit, because SPACE gives us a whole bunch of jumping off points for talking about how to improve our productivity and to some extent fun as developers. One of the things I wanted to talk about is efficiency and flow. I've been trying to talk about flow for a long time. I've been trying to demo it with IntelliJ IDEA, but it's really difficult to demo flow when you're standing in front of 100 people on stage because this is not a classic flow environment.
Let's just talk a bit about efficiency and flow. When I used to work in London, and I used to pair with Dave Farley, you probably know from Modern Software Engineering channel, Continuous Delivery, things like that. He's a very experienced developer. I would pair with him, and here's me, like really wanting to type and do stuff because that's how to be productive as a developer. Dave doesn't do that. Dave sits there and he doesn't type, he thinks. I was blown away by this, like, I could think before I start typing stuff. He thinks about, what is it that we're trying to do? Where would be the best place to put that? What is this pattern that we're seeing here? Is there a way for me to change it so it does what we want? This is a lot of what we should be doing as developers, but again, a difficult thing to measure, but it is something that can help us get into the right state in order to be productive, in order to reach that state of flow.
One of the things we were learning about when we were putting this talk together is this idea of what if we stopped with the typing and writing the lines of code and all of that stuff? What if we create a bit of boredom for ourselves? What if we take ourselves from this level of stress, this constant, a little bit too much stress, but not really too much stress, and bring us down to a state of boredom? Do you think you could sell that to your boss?
Holly Cummins: It is a little bit challenging. The first thing to note is that when we say boredom here, we don't mean toil. We don't mean that kind of busy work that keeps you busy, but is not actually adding value. When we say boredom, we mean I'm doing nothing. I'm staring into space. I'm staring at Dave Farley while he's not typing.
Trisha Gee: The kind of boredom that your kids are always talking about, like, "I'm bored".
Holly Cummins: Even that probably is a little bit of a hard sell. What did you learn at QCon? I learned that we should all be more bored. When you sell this to your boss, you don't say I wish to create boredom at work. What you say is I wish to create space at work. You want to have that headspace. Again, it's a little bit counterintuitive, but toil, toil very bad. Toil adds no value, keeps you busy. You don't want that toil. You just want that idleness where you really do have that clear headspace and your fingers aren't doing anything and your hands aren't doing anything and your head is just free to roam. Because this is, again, something that's backed up by science. There's an area of the brain or a network in the brain that's called the default mode network. When activity in your brain lowers, when you're not doing anything, most of your brain gets quieter, obviously, but the default mode network becomes more active. The default mode activity is triggered by inactivity.
Confusing, but what it means is that when you stop doing stuff, you all of a sudden have the space to do things like solve problems, be creative. That's all stuff that is associated with the default mode network. Another thing that's associated with the default mode network is mental time travel, which sounds really cool in science fiction. It actually is just replaying what happened yesterday. We can all see this. We've probably all done this because a good way to trigger the default mode network is to have a shower. Almost everybody has a shower and then gets their best ideas. Fourteen percent of people, and I think this probably does actually include me, specifically take showers for the purpose of coming up with ideas because you can solve so many problems. I should also say that this research is sponsored by a shower company, so it might not be the most impartial research you'll ever see.
Trisha Gee: Other methods are available. You could take a bath, it's ok.
Holly Cummins: The other problem with showering is if you do it too often your skin gets wrinkly, and it's a bit environmentally destructive and a bit expensive. Other methods are available. Other things that you can do are running, for example. It's a very similar pattern that you can solve problems when you're running.
Trisha Gee: I like to do knitting. All of these things are things which force you to not have screens. If you have a screen in the shower, it's not great. It doesn't work well. If you're running with a phone in front of you, also similarly, not great. What you want to do is take yourself away from these kinds of distractions. I like knitting because it's something that I have to do with my hands. I do it when I'm watching the football because football's not that interesting. I'll do it quite a lot when I'm in conference talks like this because if I get my knitting out, it forces me to listen to what's happening in the talk instead of being distracted by something else. I occupy my hands with this very manual thing, which frees up my brain to really start thinking and processing.
Holly Cummins: Which does bring us then to another tip, which is, if you don't have a screen in the shower and you're not typing while running because that's dangerous, how do you record all the good ideas? I certainly find that voice memo on my watch is really useful. I'll draft emails while running and then I'll transcribe them when I get home. The only problem is if you do it while running, or at least when I'm running, I sound like I'm going to die. Then I listen back to this transcript and it's got all this horrible gasping.
Trisha Gee: You should definitely make notes of the things that you think about.
Holly Cummins: Again, there's lots of things that you can do. There's the knitting. There's the running, walking. Good, because you don't sound like you're going to die when you do the voice memo. Showers, good, because you get clean. Gardening, good, because your garden looks better.
Trisha Gee: I do a lot of laundry. I work from home, so I'm in a position to do that. I don't like doing the laundry. I absolutely hate doing the laundry, but it forces me to get up from my desk because I'll sit there and I think I'm working on a problem, but I'm not really working on a problem, I'm just like going in circles and spinning. As soon as you take your hands off the keyboard and do something else, like do the laundry, load the dishwasher, get a coffee, whatever it is, that's when you start thinking about the problem and the ideas start coming to you.
Holly Cummins: Coloring is another really good one. All of those adult coloring books, great productivity tool. With a lot of these as well, they have this double benefit. With the showering, you get clean, which is a benefit. With the running, you get fit unless you die, which is a benefit. With the walking is a benefit. The gardening, you get a nice garden. With the knitting, you get awesome clothes.
Trisha Gee: You get stuff.
Holly Cummins: All of those, your management will look at you a little bit funny the first time you're knitting in a meeting, but then you explain it and then it's ok because you can make the case. Yes, I'm improving myself by working while working. I want to make the case for things that have no other value at all. Even those are still to be encouraged. Many years ago, a colleague, he was working late. What he did was he took a bag of Maltesers and it was hot, so there was an office fan running. He fed the Maltesers into the fan. There was no way that you could possibly justify this as any kind of improvement activity or anything. This was pure destruction and play, but it actually still allowed him to solve the problems that had kept him late in the office. Even this really frivolous, trivial stuff has value because we work in a creative industry.
Trisha Gee: We need to be able to be creative, and being creative isn't about typing into the computer. It's about allowing us space to think about the problems and solving them. Play helps creativity. We should play.
Holly Cummins: Because the creativity brings us joy.
Key Takeaways
What you should take away is that when you have that dead time, embrace it, use it well. Use it for problem solving. Use it for thinking. Use it for staring into space. Use it for play because even the play brings something back that allows you to then be more effective at your job because it unlocks that creativity. Don't just be drawn into that Cal Newport trap of, I need to prove I'm valuable by being as busy as possible all of the time and having those really high visible metrics. Then as well, having the really high stress to show that I'm valuable. It's ok. It's allowed. It's actually valuable, and gives better outcomes to have a little bit of that idle time to activate the default mode network, to activate the play.
Trisha Gee: When you go away from here, have a think to yourself, am I the frog? Am I being slowly boiled alive by this stress? Am I adjusting to more toil than I absolutely need? Are there things I can push back on? Are there ways I can make space? Even something as simple as during that long build, instead of switching to another task and paying that context switching, maybe allow that to be a little bit of space for you to engage your default mode network. Make time for boredom and make time for play. These are important things which are going to add to your productivity. They're not going to distract from your productivity. In fact, it's the happiness and the fun and the joy which are going to lead to more productivity. Interestingly, if an organization focuses on increasing productivity, what you find is less happiness, fun, and joy. If you focus on the happiness, fun, and joy, you get more productivity. It's much more important to look at it from that point of view.
Holly Cummins: It seems like you're accustomed to this tradeoff of like, I could be happier, I could be productive, but it's really not. A bit like what we showed with the running and the knitting, quite often we can achieve two good things. You get this double win. Instead of having the seesaw, you end up with breaking the seesaw and getting both good things. I sometimes call this the double win. I sometimes call it co-benefits. That's a sustainability terminology. I sometimes call it win-win. Again, twofer. I was trying to figure out the right name for it, someone suggested überwinden. It actually doesn't mean anything to do with the double win. It looks cool. No matter what you call it, the point is that instead of thinking of this tradeoff between happiness and productivity, we can break that seesaw. We can achieve both. That's the double win, which is awesome.
Last set of takeaways. Going back to the lines of code, don't use lines of code. Be really careful how you measure productivity because whatever you measure is what you're going to get. Automate that drudgery that stops you being effective at your job. Step away from being the frog as well of like, stop taking things for granted. Ask, do I have to do this? No, you don't have to do this. You can automate it. Being happier makes you better at your job. Remember that double win. Having downtime and stepping away from your desk and showering and knitting jumpers, but not at the same time because wet wool doesn't work, also makes you better at your job.
Resources
Trisha Gee: The black QR code is a link to Holly's website, where there's a page with the links to a bunch of this stuff and slides, and so forth. The purple one is if you want to win a copy of my book, Getting to Know IntelliJ IDEA. I do have a book. Please buy my book. If you don't want to buy it, then enter for a chance to win it.
See more presentations with transcripts
