Transcription
Accepted. All right, um, hello and welcome to Coding Fast and Slow. Um, afternoon, Friday. Last day. You almost made it. Just more sessions and then we can all go drink, I guess. Uh, yeah, so we're going to talk about applying Dr. Professor Kahneman's insights to improve developer productivity, practices, and efficiency.
So, how many of you heard about Professor Kahneman? Um, not enough. A lot, not enough. So, uh, Professor Daniel Kahneman, who unfortunately passed away just a couple of months ago, um, was one of the most profound figures in behavioral psychology. He, he is a Nobel Prize winner, um, in the field of economy. Uh, which by itself is fascinating. So, if you ever took any economy class, the first thing they teach you is that humans are rational and behave in a rational way. Basically, if the price of a commodity goes up, people will buy less of it, and if the price goes down, people will buy more of it. Supply, demand, all the modern economy theory is based on the concept that people make rational decisions when it comes to money and buying. Um, Professor Kahneman received a Nobel Prize in economics for proving that people are not rational.
Um, a lot of his work is summarized in, um, lots of his books, but I think that the best book, at least in my perspective, is Thinking, Fast and Slow. It kind of the essence of everything he learned and discovered throughout many years. And this is the book that we're going to talk about in this, um, in this talk. So, um, let's do an experiment. We'll do a lot of behavioral experiments. Well, not as much as Professor Kahneman, but some of them. Let's start with the first one. So, here is a very simple riddle for you. And feel free to just shout the answers when you figure it out, okay? That will be the easiest. I'm not testing each and one of you in particular. It's just going to be fun when everybody participates. So, here we go.
A ball and a bat, like a baseball bat, and a ball cost $1.10 in total. A bat costs $1 more than the ball. How much does the ball cost? You know this, right? Ah, okay. You ruined it. Yeah. No, but it's, it's obviously whoever knows, um, knows not to stay away from the trap. But if you are, um, as the majority of people, and you never heard about this riddle, the first answer will be 10 cents. The first answer that pops into your mind. And and that's because you recognize the pattern. You're like, okay, there was like a $1.10 and there is something that should be $1 less. So, $1.10 minus $1 is 10 cents. You recognize the pattern and you jumped on it to provide a reasonable answer very, very fast. But obviously, that's not the correct answer. Because if you would answer 10 cents, then the total of $1 and $1.10 is actually $1.20. But we needed $1.10. So, actually, 5 cents is the correct answer, as many of you who heard this riddle before correctly noticed. And this is how you get to one. But I have to say that I fell for it the first time I heard it, and the majority of people who didn't know the answer already did. And it's fine because this is who we are. I think this is something that Venkat spoke about, right? We are very good in thinking and thinking fast and jumping to conclusions, which sometimes wrong, but most of the time actually right. This whole thing of pattern recognition is awesome. And if it wasn't a tricky question, probably your first answer would be the right one.
So, my name is Bar Sedurski. I'm Bar on Twitter and everywhere else, whatever X, Bluesky. A developer productivity advocate with Gradle. Um, and my background is, I started in Java development many years ago. Then we went all DevOps with a company called Jfrog that you might have heard about. And now doing developer productivity engineering, um, with with Gradle. I wrote a couple of books, um, DevOps Tools for Java Developers, right in this, um, combination of Dev and and DevOps, and Liquid Software about how to better release software.
The most important slide of this presentation is this one. If you go to speaking.barj.com, you will find there the slides, which I've already uploaded, the video that I'm currently recording, and all the links for everything that we spoke about and going to speak about. Obviously, then Kahneman and his work, the riddle about the bat, my books, and everything else. And for you to easily remember where to go, it's conveniently in the bottom of every slide. There is, um, the, the Twitter handle because you're going to praise this talk. Obviously, the #DP for Developer Productivity Engineering, #DevOpsPL because DevOpsPL because that's DevOpsPL, and the URL that, um, I'm talking about. So, yeah.
Daniel Kahneman, Thinking, Fast and Slow. Professor Kahneman is talking about two systems that exist in our brain. He called them System 1 and System 2. System 1 is the one that we use when we first answered the riddle about the bat and the ball. It's very, very fast, as you notice. It's intuitive. You don't need to make any effort to answer $1 or 10 cents. Um, it's automatic. You, you, you want to say 10 cents, 10 cents, even before you think about it. Um, it's emotional. You feel satisfaction that you knew the answer really, really fast. Um, and it's cheap and eager to operate, right? You didn't put any effort into this answer, and it was like, very, the first thing that that pops out. So, it's very eager to work. It doesn't require any effort, and it's pretty awesome because it is correct most of the times. This pattern recognition, this intuitive answers, this thing that we know most of the things out of the box, most of the simple things that we come up as a challenge in our lives is, is very, very awesome. This is why humans succeed as a species, and this is a very powerful evolutionary driver that actually made this species a success. So, it's absolutely amazing. It's great. The problem is that sometimes it makes mistakes.
Now, there is System 2, which is quite opposite of System 1. It is slow, it is deliberate and analytical. It is controlled, logical, and it's expensive and lazy. When you need to think about something, this is System 2. You obviously think with System 1 as well, but the, the cautious effort of, "Hey, I need to think about it." This is where you engage System 2. It's going to be much slower. It's going to be like, "Hey, I'm making an effort to understand if that's correct." And obviously, it is very, very expensive. And this is why our brain actually tries to avoid using it as much as possible, relying on on on System 1. We're going to get back to that a lot.
But let's do an experiment. Tell me, what's wrong with this code, real quick? Or not real quick. It's not a tricky question. There is a bug there that you should see. The comment. What about it? Yeah, uh, well, the comment is not necessary, yes. But there is something fishy here with the comments. What's going on? Yeah, uh, the OR should be at, well, the OR shouldn't be. Exactly. And but you, you get to it. One more step. You don't want to employ your System 2 because it's Friday. You are tired. It's been a long conference. It's really, you really don't want to start thinking about it. I, I get it. That System 2 that is kind of hard to put in motion for no good reason. Actually, who am I to ask you to actually work for me? All right, I just need one answer. Yeah. Huh? Regex? Ah, no, the regex is, is fine. I wouldn't be that mean. All right. No, but, but the answer was there. So, basically, the NOT OR actually fine. But this is a lazy OR. The other part won't be evaluated if this expression is true. And it shouldn't be that way. It should be instead of NOT OR, it should be AND. And then it would be just fine. But, you know what? It took you an effort. I hope you put an effort into it because now I need you to do a completely different task. What I need you to do now is to tell me the color of the letters. And you just shout it. The color of the letters, okay?
So, I heard some of you actually doing what I wanted you to do and say orange. Here, and not a lot of you, but, but there was. And, and again, if you, if you, as most of us, that would be absolutely natural thing to do because we all have mental fuel. And what we did just now is the first exercise depleted some of your mental fuel. You put attention to the Java code, you try to debug it, you worked hard on it. And generally, the fact that we are now almost the last session of this conference helps because you employed your mental fuel all week when attending the sessions and listened and tried to understand what's going on. And all of us have mental fuel, and this mental fuel is getting depleted. And then you are actually less good at simplest tasks like reading the color instead of saying the color. And this kind of stuff.
Now, um, mental fuel concept is found by Professor Kahneman and his colleagues by observation, like what we did now. It was like, "Okay, people are tired, they are less attentive, they make more mistakes." But there are today actually studies that prove that this mental fuel exists as an essence. So, attention and capacity limits and perception, a cellular metabolism account. Um, I have no idea what this study is about. It, it all looks like this, which obviously you know. And, and then what we do. ChatGPT, explain the attention and capacity limits in perception, a cellular metabolism account to me, Barney style, in our paragraph or less. Barney style. It's a very American expression. There was a, a TV show for kids with the Barney the dinosaur that explained concepts to kids, Barney style. So, it's basically, explain to me as I'm five years old. Imagine your brain is like a smartphone battery that drains as you use apps. The paper says that our, that our brain has a fixed amount of energy for tasks. Like a phone battery has limited juice. When you do something that requires a lot of focus, like solving the Java puzzler that we did, it's like running a power-hungry app. It uses more of your brain energy. It's exactly what happened. And just like closing the battery saver to save battery, your brain tries to save energy by paying less attention to less important stuff, right? And this, the amazing part here is that this is a physical concept in your brain. It's not an analogy. It actually happens. There is stuff like BNRs and OxCo, which I have no idea what it means. But in essence, you have cellular metabolism which serves as a mental fuel. You get tired, you deplete it, you rest, you refuel it. You have a finite energy supply, which is a really cool concept. And then your mind can operate in a high load mode and a low load mode, like a battery saver mode that gets automatically turned on when you are tired. And this is very, very cool.
Now, this proves on the physical level all the body of work that Professor Kahneman proved empirically, like, "Hey, we see that when people are tired, they make worse decisions." This is like, "Okay, this is why they have less mental fuel," which is pretty cool.
Now, getting back to System 1 and System 2, which system do we use for coding? Who thinks we use System 1? Um, some hands. I would say 20%. Who thinks we use System 2? Uh, yeah, the rest. Who thinks it's a little bit of both? Uh, yep. Yeah, it is. But mostly System 2. I, I'm with you. It's, it's mostly System 2. Some System 1, mostly System 2. Analytical, controlled, logical. This is how we solve those algorithms and those challenges. Yes, of course, we do a lot of like stuff which is, um, intuitive and automatic. But the heavy lifting in coding is System 2, right?
So, another book, another scientist. And this is, um, Mihaly Csikszentmihalyi, who invented the concept of flow. And you obviously, all of us as developers experience flow. Um, I hope for your sake more than less, but you definitely know what it is. And just to kind of formalize it, state of effortless concentration, so deep that people lose their sense of time, themselves, and their problems, right? When we are in the zone or in flow, we're coding and nothing else matters, and we produce a lot of code of a very high quality effortlessly. Now, we just spoke about how System 2 requires a lot of effort and a lot of mental fuel. It looks like flow is the amazing exception. We are doing heavy System 2 lifting without spending a lot of mental fuel. And this is the, the holy grail of our mental fuel, um, usage. We are doing work that requires a lot of energy without spending a lot of energy. That's pretty cool.
Now, the problem that we have when we are not in the flow is attention control. And attention control is very expensive. And it actually becomes more and more expensive every day. Another great scientist, Gloria Mark, Professor Gloria Mark, studied for, um, I think, tens of years, attention, how human attention works. And just recently, um, less than a year ago, she published a great book called Attention Span, that she summarizes her findings of her entire professional career. Couple of amazing highlights from this book that took me by surprise, and I'm sure will take you by surprise. Average person checks their email 77 times a day. Who thought you check an email 77 times a day? A couple of people are that self-aware. I had no idea. I would say 20. Oh, that's a lot. But gosh, 77. Our attention span is reduced to about 47 seconds on any screen we look at. We look at the screen for 47, less than a minute, and then we switch to the next screen. And this is all amazing by itself. But the most important piece of, um, enlightenment here is, it takes 25 minutes to return focus to a task after an interruption. 25 minutes. We were writing code, notification, we read an email for 47 seconds, and then it will take us 25 minutes to get back to the context of what we, uh, what we did.
Let's try and see that in action. Yay, more Java code that you need to stare and find bugs. That's fun. Okay, how about this one? What's wrong with that? Huh? Double for money? Jeez, you're good. Yeah, don't use double for money. Um, it's not a bug per se. You can use double for money, but it, the rounding will be all weird. And obviously, just here, the output will be probably ridiculous, right? You don't want to do that. But yeah, double for money. This is great. Uh, okay, let's count triangles. How many triangles? Just shout. 18. Uh, 24. 4. 4. 40. Okay, I see what you're doing. Yeah. 64. More. Seven. It depends. That's a nice answer. How many do I want? You know what? It doesn't really matter. What I just needed you is to lose focus from the code and switch to something else. The correct answer was one of the first ones because someone already knew this particular one, and it's 18. Doesn't really matter.
Back to Java. Another bug. The same? Well, yes, but, uh, not really. This is something else going on here. No, division by 100. We are actually calculating Y, right, right? So, this was much easier than the previous one, and yet it took you a little bit longer to understand and find because you were distracted by the stupid triangles. And that was just evil of me. The problem is we deplete our fuel by context switching. And we also cannot concentrate and get to the flow because of context switching. So, this is a lose-lose because we need more fuel if we are not in the flow, but we actually have less fuel because we're context switching.
Okay, more awesome, uh, research papers. This one I love the most: "Characterizing and Predicting Mental Fatigue During Programming Tasks." Very different, very dear to our heart. Well, the big reveal here is that developers are cutting corners on quality when they are tired. Who could guess, really, right? But it's, it's a scientific paper, so I guess it's true. But, but obviously, you, you all know that, right? You all know that your quality of code degrades when you get tired. And, um, and you kind of think that you would stop when you are tired and you produce shitty code. You just don't do it anymore. The problem is we don't know where to stop.
Getting back to, according to Thinking, Fast and Thinking Slow, and Professor Kahneman, he provides another example of parole judges that were that review parole cases. And the default parole decision for those judges is to deny parole. They need to be convinced to grant parole for, um, for a convicted, um, criminal. And the interesting observation is that fewer parols were given when judges are tired or hungry, namely before lunch and after 4:00 PM. Granting parole requires System 2 thinking. They need to evaluate the case based on merits and think about it and reason whether this person should get parole or not. And judges were unaware that they stopped reasoning with System 2 and fell back to the default of System 1 of just denying parole.
Now, this is extraordinary. Not only because, you know, what, like, it's a big deal. People are getting out of prison or not based on whether the judge is hungry or or tired. This is mind-blowing by itself. But for us, the bigger kind of takeaway from that is that even judges who are dealing with very important stuff, I, I would assume more important than whatever we're coding most of the time, they were unaware that they should stop. And this is true for us as well. By the time we realize that we need to stop writing code because we are tired, there was a long period that we are running on System 1 and coding on System 1 is only, it's definitely not a great idea because our code will be what System 1 produces: cheap and eager and automatic and definitely not the best code we can write. It's an "okay code." Eventually, it works, especially if you have tests and you verify that it works. But it's definitely not the most elegant, the most effective, the best code you can write. It's an okay code. It's not great, and it's not terrible.
And I want to hear your opinion. Who thinks that bad code is worse than okay code? Some hands. Who thinks that okay code is worse than bad code? Uh, even less. But that would be me. And I will explain my thinking why I think that okay code is actually worse than bad code. Because the problem with the okay code is that it looks okay to us, us because we're tired. So, it's fine because we do it on System 1. It looks okay to our PR reviewers. Why? Because it's okay. No, but why? They will let it go. They because they're also tired and they have other things in mind and they have their own code to concentrate and they really don't give a about the quality of our code. No, really. I mean, not because they're evil, just because they're busy with other stuff. So, it looks okay to the PR code. And it also looks okay to our pipelines because our pipelines just validate naive and easy stuff to implement. And then we end up with an okay product. And okay product is not the best product we can do. Bad code is bad, out right. We catch it. PR reviewer will catch it. Our pipelines will catch it. Bad code is easy to shut down. Okay code flies under the radar. And then we end up with an okay product. And we definitely don't want that.
So, what we need, what we want to do is to invest in fuel-saving techniques with the goal in mind of running on System 2 as long as possible until we have time to rest. So, theoretically, all day, the longer we can run on System 2, the better the results are. And there are a lot of techniques, and most of them I'll just mention. And this is not the place to talk about them. So, for example, time management techniques, stuff like time blocking, when you work without interruptions and you have a chance to get into the flow. Pomodoro Technique, when you allocate time which you won't be interrupted, no matter what. And task batching. Don't do Java code, counting triangles, Java code. Do the important stuff, counting triangles first, and then do all the Java code later when you are tired or the other, whatever. So, didn't land well. Um, time batching is important.
Now, I will recommend you to look at one tool that I personally enjoy a lot. They don't pay me to promote it, which is the same. They really should. It's called Reclaim.ai. Reclaim.ai does a lot with your calendar to low time management. And it does it smart. It blocks time, it batches tasks, but it still keeps you available for other people. So, they will be able to interact with you. Because just blocking time in the calendar for all the week from 9 to 5 and saying, "You know what? I'm not available. I'm in the zone. I'm in the flow. You cannot talk to me." Want work because people need to talk to you. And what they're going to do is they are going to override your blocks. And then you do, you achieve nothing. Instead, if you block time smart, and you batch tasks smart, and you still allow access to your time, this is how you can do this win-win. And look at Reclaim. They are doing amazing stuff.
Mindfulness and cognitive practices that will help you develop this muscle of System 2 and concentration. Stuff like meditation, reflective practices, single-tasking, which is a little bit like the, um, blocking time, but now it's about blocking time in our mind, not in our calendar. How do we force ourselves to concentrate instead of being all over the place? Workspace and interruption management. Stuff like, you know, workspace organization, notification management, cancellation, headphones, working from a quiet office, all this kind of stuff. Prioritization techniques, saying no to stuff which is not urgent, and all this kind of stuff. This is all very important and probably deserves each and every one of them deserves a conference talk of its own.
Physical and mental, uh, well-being. Go to the gym. I don't have Victor Gamov here to shout it, but, you know, what I'm talking about. Physical exercise, breaks, and downtime. And now the interesting part for the technical conference is developer productivity engineering. When engineering is the exciting part here. So, developer productivity engineering is a discipline that focuses on our productivity from an engineering point of view. While everything else, blocking your calendar and meditating, is very important. How can we imply our employ our engineering skills to make our production? The tenant of developer engineering is eliminate toil for developers. For example, what I'm talking about, stuff that you shouldn't do when you are coding in terms of bureaucracy and red tape, really should be eliminated. Collaborate through effective tooling instead of, "Hey, this is my build failure log, and it's like 20,000 lines of, um, stack traces. Here is what didn't work. Help me fix it." Effective tooling can help with that. Prioritize automation and eliminate bottlenecks. This is something from DevOps, and it's been done with our production pipelines. But what about our development environment? Do we prioritize automation for the development environment and eliminate bottlenecks? Rigorous observability. Same idea. All our production code is now observable. We have observability all over. What about the production that makes the production? What about our development environment and our builds and our CI and our CD? Are they observable as well? Outcomes over output. I mentioned those huge stack traces, absolutely useless. Where is the outcomes of what happened into all this sheer noise of output? Organizational mindset. We're talking about not the production environment, we're talking about the development environment. And as I just mentioned, everybody are obsessed with, "Hey, how well our production is doing? Is it scalable enough? Is it observable enough? Is it, like, do we run all the right tools?" But we need to force ourselves as the organization to think about about our development environment as well. And this is where organizational mindset is important.
And one thing that I really want to talk about for the last 15 minutes is foster faster feedback. And why it is important and how it relates to everything that we spoke about. So, when you think about feedback efficiency, how Fe, how fast the feedback is, you have examples. You, you write code, it immediately marks if you type something wrong. This is sub-second, um, feedback. Build, build, local build. You run it, it produces results. It takes a couple of seconds, and boom, you have your build outcome. And then CI, it might take minutes, it might take tens of minutes, it might take half an hour. And obviously, production. You've done coding, it goes to production. It's also very important feedback, right? You learn from the user that you did something wrong. But it's obviously much longer hours, days, or whatever it takes to get the feedback from production. So, it's a reverse dependency on the distance from developers. The closer to developers, the faster feedback is. And that's exactly what we just described. And it almost looks like this in reality, except of one particular point here, and this is the build.
So, we'll run another show of hands for this question. When I'm talking about the build, I'm talking about the build and the tests and everything that local environment checks, basically everything you can check before you commit the code and it goes to CI. How many of you have a build which is longer than 10 minutes? Uh, I would say 20%. Longer than five minutes? Um, another kind of, um, longer than two minutes? Uh, shorter than two minutes? Yeah, okay. So, I would say the majority of you is somewhere between these two minutes and 10 minutes mark, which is, which is on the money, which is pretty awesome, um, in terms of my, my experience with that. Um, and it's a problem. We have two types of feedback: asynchronous feedback and synchronous feedback. Asynchronous feedback is your CI/CD and your production environment. We don't wait for it, right? So, we, we committed our code, it will go through PR, merge, and then build, and eventually it will get to production. If something is wrong there, we will be really annoyed because we need to get out of our zone and our flow, go fix whatever, whatever failed. But we don't wait for it. Synchronous is what we wait for. For example, our build. We want to run a local build, we want to get the result while we're in the flow. And then we are very, very annoyed when it is slow. Why are we annoyed when it's slow? Because we wait for it, and we sit there like idiots and wait for it. And the, um, the, the break between synchronous and asynchronous is commit. Everything that we do before we commit our code, we wait for it, or should wait, or want to wait for it. And everything is after. We don't.
Now, this faster, foster feedback thing saves mental fuel. Because speeding up local builds minimizes your contact switch. Less contact switch saves mental fuel. And then you run on System 2. What I just said now, I'll put the same question about the build in a different way. When you run a full build without skipping tests, how many of you wait for this build? Uh, definitely maybe 10%. Now, you remember how we said that most of your build is between two and 10 minutes? Now, except of those 10 people here that said that they are waiting for their build, for the rest of you, I have bad news. Your build is 25 minutes. You get why? Remember Dr. Mark's, when you context-switched, it will take you 25 minutes to go back. It doesn't matter that the build already finished 20 minutes ago. You will get to what you are doing only 25 minutes later, as your build took 25 minutes. And this is obviously, obviously a huge killer of your productivity and kills your mental fuel. So, you won't be able to run on System 2. So, speeding up your local build minimizes the contact switch, and this is how you win.
Now, how can we engineer less context switches? How can we do it? First of all, we need to know if we have a problem. We need to know how long our builds are and whether we're waiting for them or not, by observation. And then there are techniques of speeding up this thing. For example, avoid building and testing what didn't change. Speed up what cannot be avoided. And flaky tests. Fight the evil flaky tests. Now, after you did that for the first time, you need to observe it that it didn't happen again.
A lot of it, you can do today for free without asking permission from anyone. For example, you can run parallel local builds. I have an example that I don't have time now to show that turning on parallel build speeds up a local build from from two minutes, just like a demo build, from two minutes to six seconds, just by using all the available cores on my awesome, whatever it is, Mac Pro M2 machine. Now, this is also, by the way, why your boss should buy you the best hardware there is. Because this is how you save mental fuel. You run all day on System 2. You're writing better product just because you have a better Mac. Awesome, right?
Code that the video is there. Just send them this video. They will buy you top-of-the-line hardware starting today. Local caching. We spoke about it. Don't build what didn't change. Turn on every possible caching on your build tool. It's Gradle, Maven, SBT, Bazel, whatever you run. Turn on the caching. It's there. Might be off by default. Turn it on. Remote caching. There is an option for free. Because for remote caching, you need a caching server that your team will share for the caches. It's just like a server with an HTTP server on it. You take a Docker image from Gradle website and you run it. And it still, it will take you whatever it will take you to host this Docker, Docker image. Build scans. This is where the observation and knowing what's going on comes into play. Gradle provides a free service called Gradle Build Scan. You basically upload your builds there continuously, all the time, always. And you can not only see what went wrong. This is the collaboration through effective tooling. You can send it to your colleague and say, "Hey, this is exactly what doesn't work," instead of waving your hands and trying to describe whatever doesn't work. And you can win prizes, including awesome t-shirts for free, as well, when you do something that is called a speed challenge. It's basically plugging your build into build scan and seeing how you speed it up using all those techniques. And you know where to find the link. Speaking.barj.com. Basically, right here.
Okay, so what your company should pay for? All the books, because those are awesome books that you really need to read. Top development hardware. We just spoke about why. And tools that do developer productivity engineering even better than the free options. The Velocity by Gradle. Sends me here, pays for, uh, my travel. So, here is a shameless plug. The Velocity by Gradle is one great option. But feel free to look at the alternatives as well. With that, learn more and try today. If you scan it, it goes to speaking.barj.com. No surprises there. And then you do the speed challenge. You see how much faster you can get your feedback and win some awesome swag. Um, you should to be an agent of change for developer productivity engineering in your organization. DP Handbook is there, free for you to read. And DP Summit. The videos from last year are published. The DP Summit of this year is coming up in September. Um, if you needed a reason to go to, uh, California in September, that's your reason. Um, talk to me. I will hook you up with a nice discount. And, um, it's, it's really a very, very good conference to, to attend.
With that, we have five minutes for questions. And Bar J everywhere on the internet. #DP for Developer Productivity Engineering. #DevOpsPoland for praising this talk. And speaking.barj for everything that we spoke about. Thank you.