Programming for pleasure | Daniele Procida

Speaker 1: Morning, everybody. Um hi, I'm Daniele. Um I'd like to say thank you, of course, first of all, to the organizers who really are the most um valiant crew in the circumstances. I'm honestly a little bit moved by the commitment and dedication that's been shown. So As you probably know, the pandemic scuppered last year's plans to host DjangoCon Europe at home in Portugal. And now for the second time they're holding it online for us. And during this period, I personally have felt all the energy and capacity to do things drain out of me. And I don't think I'm alone. But meanwhile the DjangoCon Europe organizers have kept everything going for us.

Speaker 1: So Thank you. I appreciate appreciate it such a lot that you found the will and the energy to do that on our behalf. I think it's really quite something. I hope you get lots of thank yous from people on that. Let's dive straight in. I'm really um It's great. This is my tenth. No, this is my 11th Django Con Europe because the first one was was 10 2011 in Amsterdam. So I I love these events and um I'm really honored to be the warm-up man for everybody. So let's get straight in because you know you have these jokes where There's the the the doctrine says the doctor

Speaker 1: has some good news and some bad news. Well, I've got good news, bad news, and really ugly news for you. So the good news is that programming that The stuff that we do for our living is intrinsically enjoyable. It's pleasurable in itself. The bad news is that most software, i. e. the stuff we create, isn't that great. It 's substandard. We make software that doesn't solve the problems it should. We make software that irritates people, inconveniences, can waste time and money. And in some case cases even kills people. And then the ugly news is that most software is substandard Because

Speaker 1: programming is intrinsically enjoyable. In other words, why is software bad? Software is bad because programming is fun. So I expect I've spoiled your day a little bit. So let's try to find out what's um going on here. So Let's go back to the good. Um let's go back to this idea that programming is intrinsically enjoyable and unpack it a little bit. We'll start Start by trying to understand programmers. So here's a programmer busy at work programming. But that's work. It doesn't tell us what the programmer likes doing. What do programmers like to do in their free time when they don't have to work, when

Speaker 1: there are no constraints on them? What do they look forward to doing when they finish their day's work of programming The answer is more programming, and this is really quite unusual amongst professions. Partly it's just because it's kind of considered acceptable to enjoy programming at home after work in a way that, for example, dentistry is not. So even if a dentist really loves being a dentist, the scope for doing dentistry at home is a little bit more limited. You'd have to have Let's say quite accommodating friends and family. Maybe you've seen the film Marathon Man with um Dustin Hoffman and Lawrence Olivier, but uh it doesn't make anybody feel

Speaker 1: very good about the idea of dentistry for pleasure. And I I think there's often a problem that many people are very quick to Cast negative judgments on other people's hobbies and pastimes. I think really everybody should be allowed to enjoy the hobby that they're that that fulfills them. But if somebody said to me that they were into hobby dentistry , I find that a little bit odd, I think, without trying to be judgmental. But there are many other things that We don't do for pleasure that we do for work. These are professional activities. Some of them you cannot practice at home for pleasure I mean some you could

Speaker 1: reasonably um enjoy at home in your spare time and you wouldn't be causing a danger to your family or the neighborhood, but they still remain professional and not leisure activities. They don't become fun activities So when we think about what people do for pleasure and which professions people bring home with them to do in their spare time, you realize that programmers are really unusual in how much programming they do when they're not at work for their own enjoyment at home. Why? Well, I think there's a perfect um constellation of factors that make programming a kind of thing that programmers want to do for fun. So it's not just possible, it's easy. You open up your um

Speaker 1: uh your laptop after dinner to look something up and then you realize some time later that you somehow started programming without even realizing that you were taking the steps to get there. You don't have to change your clothes to do it. You can do it in the same shoes. You don't have to leave the house. You don't have to get cleaned up before or afterwards. You can do it while having a drink on the sofa in bed. There's pretty much nothing To stop you from programming at any minute when you feel like doing it. And it's meaningful The results you can achieve when you're programming at home, they're just as real and significant as the ones that you can do at work. You can do things on equal impact. It's not idle. And finally, I think this is the most important thing, the process is intrinsically enjoyable.

Speaker 1: That's what drives the activity along, what fires up you know, your the motivation to open up the laptop and start going and keeps you at it. This is um it's this pleasure, the pleasure of the activity itself. So programming is a craft, it's a skill. Um, and a craft is a power. Uh uh that's literally where the English word comes from. So and programming is an inventive creative craft. It's one that makes new things exist that didn't before. And It's that it directs creativity and power at problem solving. And an activity that Combines those three things of problem solving, creativity, and exercise of skill,

Speaker 1: answers really deep human needs and provides an almost endless source of satisfaction. And it generates a cycle in which a problem is answered with creativity. And the solution is realized through the exercise of skill, and that's a cycle that can keep renewing itself. And this is the intrinsic pleasure of programming. It's why programming is enjoyable by itself independently of its results or outcomes. And it's a deep pleasure. It's not one that comes and goes quickly. It requires us to dig deeply into ourselves. So all of this make programming quite a powerful uh um um uh give it quite a powerful hold over us.

Speaker 1: I think that if it were a, you know, if programming was some kind of drug, the authorities would have to um control it. But anyway, look, lucky us that what we get paid to do for our work is so powerfully enjoyable that we can choose it for our leisure time as well. But let's go back to that bad news. Most software is substandard. And it's a blight on our industry. The whole world runs on software. And so much of it is so bad. So it's a real problem for the whole world. And this shouldn't be news to you, honestly, because you use software a lot as well. And this kind of pain is like misery that spreads outwards to haunt as many people as possible. Now, here's a pyramid of harm.

Speaker 1: Now I don't want people to start boasting about how high they managed to get up that pyramid, but I'm pretty sure I've wasted other people's time and money through the programming I've done. possibly some serious financial, if not material, damage. If you want to boast about how much damage or worse you've done, then feel free to do that. But most of us haven't actually killed anyone with our software. And most of us probably haven't done any really serious harm through the software that we've made. But we're all involved in the creation of products that waste people's time and money very effectively and cause a lot of inconvenience. We're responsible

Speaker 1: for a worldwide permanent state of irrestrendal and frustration. And it's probably quite low-level frustration and irritation mainly, but it's everywhere all the time. It's like a background noise. Industrial pollution literally billions of times a day, the software created by our industry fails to solve the problems people were expecting it to solve and instead creates new ones for them. Why? Why is so much software so bad? It doesn't happen in other professions. Other professions don't routinely make substandard products. And it's really odd because programmers spend such a lot of time trying to do things in the right way as well. Well, as I said, I think it's because programming is intrinsically

Speaker 1: Pleasurable, that software is bad because programming is fun. And I think it gets even uglier than that. I think that the more fun we have in our work, the worse we make our products. And I think this is what I want to persuade you of, that programmers are condemned , condemned programming itself, to make bad software. So that's what I think is happening. Let's um look at this. I said that pro pleasure arises out of programming itself, out of its nature, because it's this activity of problem-solving, creativity, and exercise of skill. And that makes programming its own reward, which should be a sign of trouble. Because when something is its own reward, when it's intrinsically enjoyable, we tend to do it

Speaker 1: independently of any extrinsic benefits. Even if there are no benefits, even if there are disbenefits So in programming the pleasure lies in the activity rather than the outcome. And that's why it's daily dangerous. You know, imagine the surgeon who enjoyed being a surgeon because they enjoyed cutting into other people's flesh rather than the outcome. And that's a little bit like what programmers are. We spend all our time in the process and little time with the product. Even when we use our products. uh which many of us do, we use them in different ways from the, let's say, the real users, our victims. We don't often know how our victim

Speaker 1: about how our users use our products. If our products really mattered to us, we'd spend as much time testing the products and living with them, doing things with them as we do creating them. But we don't, either as individuals or as teams, or as companies. or as an industry as a whole. So everything starts with problems with someone's pain. A problem is a gap between what exists and what needs or should exist The product, the solution that the programmer is supposed to invent is something to close the gap. But the thing that drives us, that moves us as we work, is not the pain of the person who faces the gap.

Speaker 1: It's the pleasure of engaging ourselves to do it. And why not? I find it more satisfying to concentrate on my pleasure than to face someone else's pain But the product, what we create, has to be judged on how well it answers other people's pain. And that's something that we systematically exclude. from the picture through this cycle of pleasure. So when everything uh oh when all you have is a hammer everything looks like a nail. Maybe that's true But when you are talented, creative, and a skilled problem solver, everything looks like a really tasty problem. We programmers that we're problem solvers. We love solving problems and we're good at it. So everything to us looks like a tasty

Speaker 1: problem. But unless the problems that we solve are other people's problems, we will never make good Products because other people's problems are not tasty or pleasurable. Other people's problems are pain, which is not interesting to us, and it's also harder to understand. And one of the problems here is that there isn't just one problem. There are there are two kind, you know, there are two problems. There is the problem as pleasure, the one that makes the programming activity that we love this enjoyable and satisfying thing that we get lost in, that's a pleasure where we use our invention and imagination to solve things. And then there's the other problem. This is the problem as pain.

Speaker 1: This is the pain of the gap between what exists and what's needed. And it doesn't exist in the activity of programming. It exists out there in the world. It's somebody else's. uh pain, somebody else's problem. And it's not interesting to us. One because it's somebody else's, and secondly because it's not Interesting, it's it's not glorious, it's pitiful, it's miserable, because the other person who's got that pain is not a programmer. They're just a user, a passive victim of unfavorable circumstances. And who wants to get involved with other people's pitifulness? Not me. It's just how it is. We're more interested in Dwelling on our own pleasure than we are on other people's misery as normal human beings.

Speaker 1: Sometimes There's an overlap and uh in the there's an intersection. That's great. That's where the programmer can draw upon the nature of programming as this motivating engine. And direct all their power and creativity at somebody else's pain. That does happen. But when it happens, it's pure blind luck. It's just chance. There's nothing holding these things together at all. And Any product that comes to exist through the creative exercise of skill includes the problem as pain of the victims, the end users. And the problem is pleasure for the creators. And Okay.

Speaker 1: Maybe you've seen The Seventh Samurai by Kursava, night 1954. There are seven samurai and there's a village. And the villagers have a serious problem as pain. The pain is that their village is being raided by bandits all the time. And the seven samurai are persuaded to do something to help them. Now the samurai, they're not actually interested in the villagers, but they do get interested in the problem because it's a technical problem as pleasure, and that's the problem that we, the audience, also become interested in. How will the samura samurai who are outnumbered overcome the dreadful fearsome bandits, that's what we want to know. And of course they do it by being resourceful and skilled and inventive and cunning, just like programmers do. I I tried to find an an image from the film representing the villagers and I couldn't

Speaker 1: because nobody cares about the Nobody cares about them. Nobody cares about the users, the victims, the villagers, not even web search engines, because they represent problem as pain. And the film is about how to defeat the bandits, about the problem as pleasure. The villagers, they are pathetic, snivelling, helpless, and they hang around in the mud. waiting to be harassed and humiliated by bandits. They're not even very honest or likable. I mean I I know some programmers think of users in mostly in in that kind of terms. So it in the film, the samurai don't care about the villagers very much, and neither do we, the audience. And whether you're a samurai or programmer, it's sometimes hard to tell the difference when we're really

Speaker 1: proud of ourselves. It's easy to forget that problem, the problemless pain that gave you a job to do in the first place. And sometimes you can forget about the problemless pain a bit if there's enough overlap, but there's no guarantee of overlap And if we fail to address the problem as pain, one problem for us is that we won't get paid by the villagers or or by our users because our products will stop being successful. So it's the problem of pain that actually matters. And that would be okay If we were only or the samurai were only doing it for fun, but we have jobs to do, and we have, you know, we need to put food on the table We had better be successful at solving the users or the villagers

Speaker 1: problem as pain, even if we don't like those helpless, pitiable, weak victims of circumstance and don't find them interesting. And it's just the same for programmers and samurai. You can solve what you like if you're only doing it for fun But if your product needs to succeed, it had damn well better be successful as solving the problem as pain of the users, even if you don't find them interesting. So we have to tear ourselves away from the pleasure of the process to the outcome and pay attention to evaluation of the not so interesting pain of the user. And my contention is that every creative craft

Speaker 1: faces this risk and tends to fold into the same comes victim to the same tendency, it falls into its intrinsic pleasures and neglects the pain that it should be solving. Every creative activity has a product and it's the product that matters. I'll give you an example. Here's a programming example. This is my Brachiograph project It's the world's cheapest, simplest pen plotter. You can build it for about 15 euros, including the cost of the Raspberry Pi to drive it. It's not a commercial product, but it's still a product. And it exists to solve a real world problem, even as a hobby problem, as a hobby product. The problems are how can we do something fun and meaningful with with a Raspberry Pi and some cheap servo motors? How can we take really basic um hardware resources

Speaker 1: and do something creative. How can we make this project cheaper and easier for beginners to be successful with Those are problems as pain, gaps in the world. And I think honestly this project addresses them quite well. And I had a lot of fun thinking it up, coming up with solutions, testing my creativity, putting my skills to work, and so on. So sometimes, yes, there is this overlap here between the problem as pleasure and the problem as pain, but not always. And when I dived into the problem as Pleasure, when I started chasing the pleasure of programming, instead of trying to solve the problems of pain, I dived into rabbit holes of cleverness and achieved nothing. Every single improvement in the project has come when I face problems as pain.

Speaker 1: The problems of pain in this project are things like, let's say somebody decides that building this with his 11-year-old niece will be a nice experience for them both. What can I do? Not to make the plotter more elegant or the code more clever, but to give those two unknown users a better experience. When I've got tangled up in the pleasure part of problem solving, I've added nothing of value. And that's the trap that we face as. Programmers as professional programmers, as teams of programmers, as companies that make products by programming, that's the trap we face. Because we I speak as programmers, we were made. We were born to solve problems. We're the best solving problem solvers

Speaker 1: on the planet. And we face tasty problems, technical, interesting, challenging ones. And when we'll overcome them in creative and imaginative ways because we're so great. And that's how we fall into the grip of our deep pleasure drives. As I said, if programming were a pharmacological product, the authorities would have to make it a controlled substance. If it were up to me. I'd ensure that you are only allowed, you were only allowed to do programming under tightly controlled uh conditions And this kind of danger is dangerous because it creeps up on you. You know, when the danger jumps out of the shadows and gives you a fright. You know what to do and you realize that you're in danger. But this one, um, it comes creeping up on you out of the pleasure.

Speaker 1: You don't even notice. You know, one day you are solving you are programming to solve a problem of pain And one day, a little bit later, you realize that the pain has moved completely out of the picture and you haven't even noticed. And now the problems you're solving are the ones of your own self-satisfaction. You're engrossed in being a good programmer, making a bad product who got sucked in by pleasure. And mostly, eventually, we realize and stop. But not before we spent a lot of energy in the pursuit and added some more stones or climbed up some more steps on programming's global pyramid of harm. So that's why I believe that programmers are condemned by the nature of programming itself

Speaker 1: to make bad software. And I hinted at one reason why it's easy to fall into. I think it gets worse because there's a there are there's a lack of natural checks on this tendency that that could mitigate it You know, we're not the only ones that with problem-solving skills, creativity, and so on, these things provide the same kind of pleasure in every activity where they're found for in other kinds of engineering, you know, the proper engineering, the ones, the ones who um get annoyed when programmers call themselves software engineers. They have these same pleasures too, but you don't find civil engineers building bridges or dams that fail to meet the expectations of a bridge or a dam. And you never find an aeronautical engineer adding features to an aircraft that nobody needed

Speaker 1: just because it was a really interesting technical challenge to do that. They don't get carried away, they don't get seduced by problem as pleasure, as programmers do. Those things just don't happen. So why are they not seduced by the pleasures of their craft when we are? Why are they better facing up to the problems as pain? of their users. One reason is quite obvious, you know, if if um if you make a bad bridge or a dam Or an or a bad aircraft, that's a disaster at the top of the pyramid of harm. Whereas our failures mostly take place at the bottom where they irritate continuously and inconvenience often, but rarely cause catastrophes. So we we cause a lot of pollution but not catastrophes. And you can get away with pollution.

Speaker 1: Just as after 200 years of industrial revolution, only now we're starting to understand that industries need to be held to account for low-level pollution just as much as for catastrophic failures. I think it's going to take a while for society to decide that programmers need to be held to account for software pollution too. But I think it might take less than two centuries for that to happen In the meantime, if we look inside to our industry, I'd like to ask, is fun a cultural problem for the software industry? I think one reason why we so easily take our eye off the problem as

Speaker 1: pain is that since the 1970s, along with this spirit of invention and creativity. Um programming culture has become colonized. Um By an ethos of fun. It's colonized the industry. Nobody on the planet, not even five-year-old children Seems uh at a birthday party, seem to expect to have as much fun as the programmer does in their day job in their 21st century. And the language, the practice, the imagery, the tone of programming culture, they're relentlessly um ludic, they're playful. Even our language, you know, Python is named after a comedy group uh troupe. It's no coincidence. You think of the most sinister

Speaker 1: corporations in the world. They provide their offices with the look like playgrounds. Fun has taken charge. And in this kind of culture, it becomes really hard. To see, never mind, dwell upon, the problem of pain of other people. So everything in programming, from its culture to the nature of the activity itself, has a tendency to bend the programmer's attention. Away from solving problems in the world towards the pleasurable solving of technical problems. And if I'm right, then at least we've got something to think about. For example, I don't think it would hurt us as an industry to dial down our expectations of fun a little bit. We're grown adults and we don't need to work in chocolate factories. I'm not saying that work needs to be less enjoyable.

Speaker 1: Play is not the only kind of pleasure. Fun is not the only kind of satisfaction. And maybe it would be a benefit to separate our work and personal lives more clearly so that we understand more. better, what kind of rewards we expect in each sphere, in the personal and the work sphere, and experience the pleasure of play and the pleasure of work and understand them better in each context for what they ought to be. If we want to be a little bit critical, maybe we can think about what kind of employer wants to make wants to make the workplace seem like a funhouse that you never need to leave. And we can try to learn as individuals to become more pain-seeking, to become more pain-listening, to hear things that we don't want to hear.

Speaker 1: Unlike Major Vaughan in Jaws, not wanting to hear that the beaches should be closed and not listening to the painful bad news from Police Chief Brody that could have saved the day. Maybe we can put people in positions where their job is to amplify the pain of the user and bring it back to the product team. So the developer advocate doesn't just develop develop deliver good news to the community, they bring back bad news right home for the product team and force their company and colleagues to face up to other people's disappointment and pain and do do something about it? Or the product manager, you know, are are they in charge of great new features

Speaker 1: features or they're in in charge of minimizing low-level industrial pain and inconvenience and pollution? Can those can those be turned into can those be turned into targets the way features are? So I think it's going to have to be forced upon us somehow. We need to be dragged forward to face the pain that our users need to have solved. We need to have that pain pushed right in front of us where we don't want to see it. or hear about it because it's pain, because it's someone else's pain. And we'll never do this to ourselves. I don't think we will. Someone has to do it for us, and we're never going to thank them for it. So If we are to make better products in software, I think our work needs to become less fun. And I

Speaker 1: don't know how I feel about saying that. Well, I I I'm quite glad to challenge you with that thought. So, but I don't know what we're going to do about that. And I think I'm right about it. And I think the consequences are profound for the industry. But What we're going to do, I'm not so sure, but you're all programmers and clever at solving problems, so maybe you can propose something yourself. Thank you very much. Um happy to answer any questions. Hi, everyone

Speaker 1: And I hope you see me and hear me here.

Speaker 1: Okay, so um uh questions. I I didn't see any questions, but I'll just shall I just pick some out from uh the uh uh the chat here. So what what's my idea on offices that look like playgrounds? Do they really contribute or are people still looking with a Queer eye on it. Well, you know, I I've um yeah, I think they're really there's something really sinister about playground type offices without naming necessarily the names of any particular companies. I've I've been in a couple and they seem like a a

Speaker 1: a a device to isolate the programmer from the real world. outside and I don't think that's a really safe thing to have Um Yes, um Johannes says, interestingly the movie ends with the samurai losing the battle, but losing most of their people while the villagers live in peace in the end. What does that mean for us programmers? Well, that's that's true of course. I didn't I didn't um mention that in in the talk i i itself. That that's part of the reason why the samurai are so dismissive of the

Speaker 1: Villagers because the villagers just as I say they just sit around, they're passive, they're not terribly likable or honest. And um It's true that in the end it's better for the villagers, whereas the samurai are sacrificed, but If it hadn't been for the samurai, the villagers wouldn't have lived happily ever after, and plenty of them got uh uh troubled beforehand. I think you can only take the metaphor so far. Uh Yan, if writers enjoy writing. Will their writing be terrible too? If movie producers produce movies for pleasure, will those movies be substandard?

Speaker 1: Actually this is I I took out some slides about that because I've got a couple of friends. Um one loves to be a poet and the other loves to be a trade union representative. But they both get really tangled up in the pleasure of writing, one writing poems and the other writing snotty letters to uh school governors boards and so on. And they're always showing me their work. And when the more proud they are of their work. The more I want to grab the paper from their hands and edit it down so that it's more effective. Because they get seduced by their pleasure too. The poems that The poet thinks are the best, are usually the ones where he's fallen in love with his uh his

Speaker 1: skills, his talent. And they're the worst ones. The ones where They work are the ones where he's stopped thinking about that and has stopped indulging himself. And the same for the the professional letter writer. So yes, I think writing is a very good analogy of this, that the writer who loves the sound of his or her voice, a bit like I do sometimes, is in danger of falling into that trap I don't know if you all have sound, but I'd be happy to answer any questions from you directly from the the floor, as it were.

Speaker 1: Shy has a story to tell about a project to build a fighter jet. Well I know that's not a question, but that sounds quite intriguing, so feel free to tell us a quick story, Shy.

Speaker 2: I had the same problem with uh enabling my microphone. Uh you hear me now

Speaker 1: Yes we do.

Speaker 2: Okay. So yeah, um no the the story is about the uh jet airplane that um Israel tried to build um some um 40 years ago. And it it started all nice. This was in in response to a comment you made in the presentation about um uh other engineers not um starting to add needless features just for fun And the the project finally just failed and a big part of it was essentially feature creep. It started out as a project to build some pretty simple uh

Speaker 2: and cheap aircraft to replace the old um mirages that we were using like back in the 70s or 60s even. And bit by bit uh people added more features and more features and it became more and more expensive. uh until the project imploded and and the the the aircraft which had already gotten to uh Point of a uh uh prototype that could fly. Um the project was uh eventually cancelled Um so yeah.

Speaker 1: Yeah

Speaker 2: that yeah.

Speaker 1: I I think it

Speaker 2: I think it does

Speaker 1: it does happen but much less than uh uh it happens in programming where it happens just All the time. I realized that by the way, there were some questions that I I didn't notice um in um The other chat. Shai, I wonder if I could ask you to mute mute yourself as uh I think there's some echo

Speaker 2: there.

Speaker 1: Uh crit from Chris, you seem to be describing the need for user researchers and empathy for end users. Are there tools and approaches in other fields we can adopt here? Yes, possibly. You know, programming is the field where above all not invented here as a recognized syndrome. So I don't know, but I think programmers are actually quite interesting in interested in talking about programmers. So if you can maybe use that to get over this uh not invented here syndrome to get them to look at the benefits from other uh areas that was probably a good idea uh russell are you calling for tighter regulation of access to programming tools well that's actually quite a good idea You know, and I think it's a good idea just because I like controlling things. I'm a very controlling person, but no, I I mean

Speaker 1: that's that's that's a kind of imaginary joke in a way. I'm not really sure. I think the regulation has to be not on individuals, but I think on an industry and the way it does things and I think probably starting out by measuring the impact of this kind of low-level pollution might be a uh a good way uh forward. It might be a a powerful w way to do it to try and get into the habit of measuring that and um as it were punishing it um When picking uh from Philip, when picking a project uh should not interest which passes for fun also be a factor to consider

Speaker 1: You know, I'd hate anyone to come away thinking that uh I'm I'm uh anti-fun, even if I am. I just still don't want people to think that about me. Um I don't think fun really is a problem. I think it's the way that fun has become the king of our lives that's problematic. The way that fun has been allowed to rule everything. Um and you know it's it's like eating sugar all the time. It's it's quite addictive and uh not not very good for you. But easy to start doing because it is you know sugars like crack cocaine and I think I think programming too. Um Does it affect our efficiency if we

Speaker 1: from Benjamin? If I does it affect our efficiency if we don't enjoy what we're doing as a developer I mean if if you if you hate your job, no, I'm not suggesting that. And I I said there's more than one kind of enjoyment. You know, I'm sure that, say, the surgeon. enjoys their work. But the enjoyment comes from the whole context. For example, in that case of being a medical professional of changing people's lives. They don't the med the the surgeon who got tangled up in in in the business of solving technical problems at the level of what they can do with their hands. I mean, eventually we hear about these people on the news and and they're normally being struck off for gross uh misc medical misconduct because they got carried away with their own powers.

Speaker 1: So I think um Yes, there is pleasure, but it's fun that's the dangerous kind of pleasure. I missed so many questions. I'm sorry about that. Isn't Agile about Agile bringing these bad news from user developer. It should be, yes, but you know, you try speaking the bad news at the stand up and uh see how popular that gets you in the team if when you do it loudly on a on a regular basis. You need a special kind of thick skin to be able to do that well. And I wonder if we're running out of time, but we're still until somebody throws us out, I'm I'm happy to stay here. How do you think programmers could get into more contact with the users? Ah, well, that's a really good one. I don't know, but that's a really good one.

Speaker 1: Spending time with your victims, spending time with your with your users, the passive. consumers of your work. Sitting there and watching them and also shutting up and not showing them what to do but hearing what they do and how they talk about it, the language they use, those are all useful things. Last one. Creativity is an inherent part of programming. Would reducing fun make programmers lose creativity? I don't think so. Honestly, I don't think so. I think that, you know, when Pablo Picasso was being creative or Beethoven. They they weren't having fun. Maybe they had fun sometimes. They didn't need to have fun to be creative today I'm not saying that you need to be deaf and syphilitic like Beethoven or

Speaker 1: or or whatever, I d but you don't need to be seeking fun. And I think it's time for the next thing. So look, it's it's uh we've reached the hour. Thank you so much for listening. Thank you so much for your questions and comments, and um enjoyed the rest of the conference. Thank you so much to the organizers once again. Thank you.