 Oh good, this thing still works, that's excellent, I love it when that happens. So yeah, anyway, it's about 2.30 p.m., or as we say in Japan, good morning, because it's right about that time for me right now, I absolutely love jet lag, yay. And everybody in here is probably feeling nice and energized, you know, because now's that special time of the day where you're just raring to go. So anyhow, I kinda wanna riff a little bit off of DHH from earlier today, in that I think as both Rubyists and as Rails programmers, we have kind of this maybe sub-conscious tendency, Matt's actually talked about this once, where we're always looking at other languages saying like go Lang, you know, maybe I should go there it's so much faster and more efficient, or maybe I should use Elixir, maybe I should just skip all this stuff and just write my web code and see your assembly. And I think that's because we have this push to focus on computational efficiency, we want really fast algorithms, we want great data structures so that we are optimally using these amazing tools, computers that we have. And because of this sort of obsession that I think a lot of programmers, I certainly am guilty of this, in focusing on the machine to use that efficiently, we tend to neglect the human side, you know, the most important tool that we have in our toolbox. And so this is a talk on software engineering, but we're not gonna talk about solid, which is great, and we're not gonna talk about hexagonal architecture, we're not gonna talk about data structures and algorithms, and we're gonna focus on the human infrastructure of code, sort of DevOps for the developer, if you will. So anyhow, to lead into this, my academic background is mathematics, I'm one of those people that is crazy and got a math degree. And there's an old joke, I tend to have a lot of old bad jokes in my talks, that a mathematician is a machine that turns coffee into theorems. So you put coffee into a mathematician and you get a chalkboard out full of things that nobody understands, yay. Programmers are kind of similar in that respect. A programmer you could think of as a machine, you put coffee in and you get out mostly working software. And the reason I bring this up is because not to say that programmers are machines, like I think that that's not the statement, but that you can think of your mind as being a machine, as most importantly being the most important tool in your toolbox. And to get the most out of it as a programmer, it's very important to learn both how the mind works as well as how to maintain it. And this is a very crucial investment as a working programmer. So in just as the same way that a good company will invest in great hardware for their engineers. As a great engineer, investing in your own human infrastructure is probably one of the best things that you can do. And so to talk about that, we're gonna first start with the hardware. So hardware matters because without really taking care of your hardware, your software is going to suffer. A good example I like to bring up of this is one of my first gigs as a CTO in Japan. I worked at a company that was part of the Great Coupon Rush. I think of about 2009 or so when everybody was focusing on daily deals and daily coupons, Groupon and the like. And during the course of working at this, we had to do a transition from the old system, which was based on the CMS and didn't cope with scale to the new system, which we had rewritten using Rails. And in doing this, we had worked a lot of hours, myself, the team put in a ton of extra time to make sure that this thing was done by the deadline. I'm sure nobody in here knows what that's like. And in doing this, we worked extra time, we set up a schedule so that we had a fresh team coming in, so that we had half the team coming in fresh for the launch day, and then the launch team would go home early and get some sleep. All of this was set up, the transition went really, really smoothly, much more smoothly than I would have anticipated. And so myself as being part of the launch team went home and got some much needed KIP. Maybe about, I don't know, five hours later, I got a very, very panicked call from one of the senior engineers on the team saying like, hey, we found a bug and it's kind of bad. It's really bad actually. The database for some reason is just locking itself up consistently. We have no idea why. Like we're not really able to identify the source of the database locking. And because I had had five hours of sleep, I realized, oh, I did a little bit of digging and I looked at the database locks and I realized, oh, I know exactly what the bug is. I know exactly where it is because I wrote it. So as it turns out, cash expiry is a hard problem. And I had kind of mucked it up. And I know better than this. I absolutely know better than to have handled cash expiry in that way, but I wrote that bit of code when I was exhausted. And this leads into something that I like to call anti-work. Like you think of matter and anti-matter, right? If you combine the two, you get this huge explosion. Well, anti-work and work are kind of the same thing. Where if you write your code when you're exhausted, if you're working when you're tired and you're forcing yourself to just crank out those lines, you tend to write things which later on will absolutely sabotage the code based on sabotage of the team. And so although it feels like you're getting stuff done and it feels like you're generating real value, you're actually sandbagging things for the future. And so that's anti-work because when you write that code, the destroys productivity. And the reason for this is because our bodies don't have infinite capacity for getting stuff done. We don't. We have limits. And so when we think about our hardware, which drives our minds, what do we really want to optimize for? We're probably not trying to optimize it for things like strength or speed. Like as a programmer, being able to lift a lot of weight or being as fast as the flash, isn't that useful to us. It's not a bad thing, but it's not that useful. And so what we probably really want to focus on is having really consistent energy delivery. And I think this is something that it's really easy to ignore because we focus so much. It's so easy to focus on getting more hours. We obsess about having more time and so we don't sleep enough. We pull an all nighter. We use caffeine to get more hours in the day. Newtropic drugs are not exactly an uncommon thing. And by doing that, yes, you can get more hours, but here's another one of those old jokes. Alcohol is a magical thing that enables you to steal happiness from tomorrow. That's exactly what it does, right? Like it's like, hey, you're having a great time tonight and then you wake up and exporting and maybe not so great of a time. Especially for me, the hangovers are epic. They last about a day. So rather than trying to get more time in the day, I think our focus should be to make sure that the hours that we do have are of the highest possible quality. And I'd like to really illustrate this. Everybody in here knows what the zone is. We know what the zone is like. That's when you sit down and you're working and you're like hacker typer. It's great. You're cranking out code. Everything is flowing nicely. It's beautiful. I think it's why we're programmers because that time is when programming is happy. That is when everything is wonderful because it is pure creation. It is that pure connection between the mind and the machine. And rather than having a 12 hour day or a 14 hour day with only maybe one or two hours in the zone, what if we could have seven to eight hours of really focused work where most of those things are in that happy zone? And that's why we wanna focus about consistent energy. And the most fundamental thing to this, the foundation, one of the foundations of consistent energy is sleep. Sleep is so important. Sleep is that time where not only your brain takes care of itself but where your body heals and all of those other wonderful things. Remember, the focus is on better hours and not more hours. And so cutting sleep to get more time is self-sabotage. That's anti-work. One of the best ways to ensure that you get good sleep is to set your alarm clock and you wake up at a regular time every single day. Our bodies are actually fairly rhythmic. And so if you have that consistent wake up time and you go to bed when you start feeling tired, not at the same time necessarily every day, when you listen to your body, it tells you what it needs. And you do that on a consistent basis. You will get this really, really nice sleep rhythm and it will help level out your energy levels during the day. And this was a hard thing for me to do, by the way. It was a very difficult thing for me to do. Especially because on the weekends, you have this urge like, oh, I wanna go out and party. I wanna have a good time. I'm gonna go do stuff. And by breaking that cycle on the weekends, you literally give yourself jet lag every single weekend and you have to recover from that at the beginning of the week. Something else that as far as consistent sleep goes and good sleep. And I hate to say this because I love a whiskey and I love a beer as much as the next person. But alcohol really kills your REM sleep quality. If you've ever had a night of drinking and you come home and maybe you sleep a lot, you sleep 10 hours or 12 hours, but you don't really feel rested, it's because alcohol has sabotaged your REM sleep cycle. And so on the weekends are great, but during the weekday, at least for me personally, I avoid alcohol like the plague because it really, really hurts me the next morning. And sleep, like I said, is part of maintenance, but it's also important because it sets this sort of daily rhythm for us and this is really critical for people because we're very rhythmic creatures. We have two main cycles, actually. One of them is daylight, that's our sleep cycle. And the other one is a food cycle. So when we take our meal times, I think there's a water cycle in there somewhere as well too. So the combination of those two cycles is to regulate what we do and regulate how our body deals with energy during the course of the day. It's one of the reasons, for example, when you have to deal with jet lag, living in Japan, I travel internationally quite a lot, that when you land at your destination, you immediately adopt the food cycle of that destination because you can't really reset your sleep clock very easily but you can reset your food clock with just a couple of meals. And you can leverage this during the course of your normal day as a working programmer by having your meals at consistent times because your body will adapt to that and it will grow to expect that at maybe 7 a.m., that's when you have breakfast, and maybe at 12.30, that's when you have lunch, and 7 maybe is when you have dinner. And your body will adapt to this and you won't, number one, only become hungry at those times, which is kind of nice. But number two, it will smooth out your energy delivery and reduces stress, physiological stress on your system. This, of course, also boosts focus, which is wonderful. And to get into this, the first thing that I did to kind of fix that problem is I used a calendar. I actually set up calendar reminders that said like, okay, now you need to eat. I apparently needed that. Some people can get away with other things, but by making that a regular rhythm through the day, it helped me stabilize my energy. Speaking of food, food is really important. It's the thing that powers your mind. It's the thing that fuels your brain. And I'm not going to try and dictate diet because people obviously, you know, should make their own choices and let their body tell them what they want to eat. But the one thing that I can say that has been really useful in food is to avoid fast carbohydrates. So when you take carbohydrates as sort of the energy, the thing that power your body and power your mind, and when you take in fast carbohydrates, they get processed really quickly. This then causes an insulin spike. Your pancreas has to just ramp up insulin production really, really, really quickly and you get the spike of insulin. You've probably noticed that if you have really sugary foods, like you have a pop tart for breakfast, you get a lot of really nice energy from that pop tart and then maybe about 10 or 15 minutes later, you're hungry again, you want another one. And that's because of that insulin spike. You get the spike of energy and then it goes away again and you end up in this sort of a dip. And then so you'll eat something else. So you'll have some caffeine to kind of make up for that energy loss and you end up in this sort of like really wavy cycle of energy during the day with all of these high rises and these really low troughs. So by just avoiding those simple carbohydrates, that sugars, that's things for example, like you know, honestly wheat breads and focusing on things like rice and pasta is assuming that that works for you. You can help level out your energy during the day which is nice. And actually one of the other nice things about rice is that they tend to be gluten free. Exercise, motion is life. It's one of the things that, I don't remember where I heard it, but it was something that really struck a chord with me and that living things move. You know, even plants, plants move. You can see them, if you watch a time lapse of a flower chasing the sun over the day, it's a really beautiful thing. The roots of the plants slowly kind of creep into the ground looking for nutrients and our bodies really want to move. They want to do stuff. There's a huge number of documented benefits to this and I think that as software engineers we tend to miss on the exercise a lot because we get so focused on working. And so it's not about going to the gym or doing CrossFit or doing what other people say that you should do. It's about finding something that you love to do that is exercise that you can enjoy. I for example, I hate running. I cannot stand running. But I found that I really liked lifting weights and so I was a power lifter for many years. Other people enjoy dance. Dance is fantastic exercise. Dance is amazingly good for you. Hiking is wonderful. There's got to be something out there for almost everybody that they can do that they enjoy. And by having exercise on a consistent schedule it's one of those things that really helps you with that consistent energy because it's great for your cardiovascular system which means it's great for your brain. And a couple of tools that I use to make sure that I keep my exercise schedule consistent. The first one is that I follow the rule of I have to show up. So in the morning I really don't want to work out. I really, really, really don't want to work out. And my rule is that I have to show up and I have to do one push-up because I'm doing body weight stuff right now, just one. And if I get done with that one push-up and I want to stop, I can stop. That's completely fine. Usually I don't want to stop. Something else that's really helped me is setting incremental but very achievable goals. And in software this is really critical too. Like you don't try and build a gigantic feature that takes two or three months in one shot. You do it little bit by little bit. Exercise works the same way. Where my goal is to do one more push-up than I did the previous day. And last but not least, tracking your progress. Once again a great tool in software as well, seeing how you're coming along, seeing how the feature's going along. Continuously being able to see that feature as it's building. Exercise works the same way. Where if you can look at your progress over time, it's very, very motivational. And so these three things are kind of what I look at is the pillars of having consistent energy throughout the day. And I cannot stress how important that consistent energy is because that's what puts people at the top of their game. That's what helps you optimize whatever hardware you have. It helps you get the most out of that hardware. And while great hardware is one thing, great hardware means that we need great software. And so that's the next thing that we're gonna touch on is caring for our software, e.g. our minds. Now we're rubious, and it's a good rubious. You know the quirks of Ruby. You know the quirks of the language. Really any good programmer knows the quirks of their language, right? Things like in Python, an empty string, correct me if I'm wrong, is false. Or in Ruby an empty string is true. Yay, little quirk there. So if you switch between the two, man that gets really annoying sometimes and that's been the source more than a couple of bugs for me in the past. And so like any tool, our minds have quirks. They have weird things, right? They have limitations. And so by being aware of those limitations and by understanding how they work, we can leverage our minds to get the most out of them. And there's probably a lot that you might not know about your brain, like this. So for sighted people, we're actually blind for 40 minutes every single day. We don't even realize it. We don't know that we're blind for 40 minutes every single day. One of the reason that we're blind is because of how our eyes work. We have this really narrow focus area. If you hold your hand out like this and you look at it, if you look at sort of the center of your palm, your actual focus area really only extends out to sort of the kind of the bait, like the webbing of your fingers really is probably about as far out as you'll go. Maybe to the first knuckle there. And that's all you get. That's the only place that you can focus on. Everything outside of that is blurry and you can't read, you can't see anything in that. It's that your peripheral vision. But yet when you look at me standing up here, when I look at everybody here in the room, you're all clear to me courtesy of these, of course. And this is because what my eye is doing is it's moving around consistently without me knowing it at all. These are called saccades and they are the fastest motion in the human body. And my brain is taking all of those saccades and it's stitching it together in one consistent picture. Now, saccades are interesting because they have a limited range of motion. So if you were to hold out your arm like this and you move it out to maybe a little bit past shoulder width, that's about as far as your saccade can go. And you can actually demonstrate this by if you hold it out and then you move your arm out a little bit further and you want to look at it, your head will turn naturally to follow where your hand is because that's a really, really stressful motion for your eye right at the edge of the range and so your head will naturally turn to look at it unless you force it to not. And this is one of the reasons why in novels, when you buy a novel, you get these really short lines. They're a maximum of between 60 and 72 characters because if you start going beyond that, you're going outside the scope of what you can read in a single saccade. You're having to turn your head and that takes a lot more energy. It's a much more exhausting motion and this is something that was discovered by agent typographers. There's another interesting thing about the way that our brains work and that is your memory. You have a working memory that holds seven give or take two items somewhere in there and the way that what happens when you overflow that memory is very different from a computer. Computer just dumps core, right? Like if you have a stack overflow or if you overflow your allocated memory, your brain does this kind of really interesting fuzzy compaction where it will try and make sense of the data you've stuffed into that short-term working set and it will compact it down based on what your brain thinks, the gist of things is based on what's important. So you'll remember maybe, if you look at a long list of things, for example, you'll remember the first two items and probably the last one but the stuff in the middle will get really, really mixed up. And so your brain focuses on remembering things that are almost right. So if you've ever been working in a really big function in Ruby and you get kind of lost with what's going on in there, what's really happening is your short-term memory has overrun and it's compacted down. And we don't know this is happening. Like we don't get this sort of flag that our brain raises up and says like, oh hey, I've run out of working memory. I'm gonna throw out that thing that I was just working on because I think that it was less important than something else. And the question probably is okay, how does this apply to software? Like what connection does this possibly have to software engineering? Well, there's a lot of things that you've probably heard before that directly correlate to these two cognitive and physiological limits. So when you look at a long line of code, when something that takes over like a long section of screen, you're nominally breaking that cicada limit and you're forcing your neck to start moving. It becomes exhausting. When you have more than five to seven lines in a function, it's not about the number of lines. It's more about keeping the number of things that are in your working memory small to fit within what your brain can actually cope without dropping things and becoming fuzzy. The same goes for the three levels of indentation. These roles feel arbitrary but if you understand the limits behind them, the physiological and the cognitive limits, all of a sudden they start to make a lot more sense. And this why I think really matters because without the why, it's really easy to craft things that follow all the rules but that still fail to achieve the purpose. For example, this. This is a little snippet of code from some production thing many, many years ago. And I think every single one of us, Ruby enables us to write this really concise language and code golf is not uncommon, I think, in Ruby in production, Ruby code. And so you do see a lot of things like this where the goal is to write small code, right? Because in small code, there are fewer places for bugs to hide except for the fact that there are three bugs hidden in this. So readability really matters not just because of the last couple of rules that we talked about but because also of how our memory works. In this case, we're not gonna talk just about short-term memory, we're going to talk about long-term memory because our long-term memory has evolved to remember stories. So human writing, the ability to write things down and convey things through it in information has only existed for about 10,000 years or so, thereabouts. We had some cave paintings and primitive paintings before that but talking, the conveying information through speech is millions of years old and so we have deep structures in our brains built to remember stories. Back in ancient Rome, there was a guy named Cicero and he was once part of a very large dinner and there was a fire at this dinner and sadly, tragically, many people died. He managed to escape and the afterwards, of course, people wanted to be able to identify the victims at this particular fire, the people that didn't get out and Cicero realized he was able to recall the names and the places of every single person at the dinner table and he was able to do that because previously in the evening, he had told the story, a comedy, involving all of the people that are sitting around and enjoying dinner and that's called the method of loci and so by telling a story, we get this amazing sort of fast track that loads things into our long-term memory and the same thing goes for readable code. When you write code like Wallwritten Pros, as Uncle Bob recommends, it's not just because it's easy to read but because you get this cognitive fast track for that code into your long-term memory and so the next time that you step back to look at it, both A, it's easy to read, which is wonderful but you also get this sort of spring-up of context that you had at that period of time because this sort of nebulous ball of information can pop back into your memory because you have built code that optimizes for long-term storage and so if we refactor that last snippet that we looked at into something that maybe looks, maybe not perfect but a little bit more readable, number one, a couple of the bugs fall out. Two of them just disappeared immediately. One of them was a case identification bug and the other two were brackets and two, this is something that now makes a lot more obvious that's like, okay, we have a short color and a long hex color and we want to actually transform those to an RGB value because the code is readable and more importantly, the context becomes obvious. After refactoring this, I remember that this was code that was part of, I was normalizing brightness values for color. That was the thing. So it was taking in a color, taking in multiple colors and normalizing them for human visible brightness. So another interesting aspect of our physiology is that decisions are really, really, really hard. It's one of the reasons why if you walk into, if you go into a Carl's Jr., if you go into one of those drive-throughs where you have all of those different things to choose from, it's kind of hard. You just kind of sit there and go like, hmm, chicken sandwich, I'm not really sure. Whereas if you walk into an in and out for anybody else who's from California. And then you can have a burger or you can have a cheeseburger. And that's pretty, and you can have a drink and fries and those are kind of your options. You don't really have this huge number of options and as it turns out, we only get a limited number of decisions that you can make during the day. They use energy and that's something that we're trying to conserve. Really to illustrate how powerful this is, there was a study that was done, I believe by Stanford University, maybe about 10, 20 years ago, about inmates going up for parole. So if you're an inmate in a prison and you've exhibited good behavior, you can get released early, you can get released on parole. And to do this, you have to go through an interview where you have a panel of people that will make the decision as to whether or not you get to get released early. And if you have a choice on setting that time, you beg and plead to go as early in the morning as you possibly can. Because what this study showed is that if you went early in the morning when the judges were fresh, they would actually listen to what you had to say and they would consider your petition for release and were more likely to grant it. Whereas if you went in the end of the day after they exhausted their decision potential, you were probably just going to be stuck in prison because they would fall into the default of no. The same thing, by the way, applies for job interviews. So if you have a chance to set up a screening for a job interview, you wanna set it up as early in the morning for the person on the other end as possible because they're going to give you the best possible shake. Now, this is kind of important because it relates to discipline because what really is self-discipline, right? Self-discipline is choosing when we don't want to to do the right thing. It is me choosing to come here and actually do the talk that I promised to do rather than staying in my hotel room and taking a big long nap because, man, am I jet lagged. And the thing about discipline is I think discipline is really overrated because discipline is decisions. You're having to continuously make decisions. And so rather than doing that during the course of the day, building effective habits, focusing on habit formation over self-discipline will get you a lot more mileage and will help you conserve energy more. And all we're really doing is we're just teaching our brain to do the right thing automatically. This can actually save your life, too, by the way. So we're all at a conference and I'm willing to bet that everybody who is out of town is probably staying in a hotel. Now, in a hotel fire, most people, like hotel fires are really, really tragic and most people tend to die in their bathrooms. They go into the bathroom or they go towards the window and that's where they end up getting trapped. And the way that you can prevent this is that when you stay in a hotel room, the first thing that you do is you say, okay, you make a habit of this. It's like, okay, I'm staying in this particular room. Where's the exit? Where's the emergency exit? And you count the number of doors to where the exit is. And by just doing that simple step, you now know how to get out. Your brain will actually remember that even when you're panicking. So by making that a habit, you can actually save your own life. Another really, yeah, and really, this kind of works out with a lot of programming best practices, right? Like, you know, the idea behind habit, the idea behind leveraging those aspects of your brain. One really good example of a programming best practice that is driven by cognitive science is using the reward cycle. So the reward cycle is a really critical part of things. It's actually what forms addiction in that when you want to accomplish something, you have a goal, something that you want to do. You establish that goal and then your brain consistently gives you this little bit of boost of energy, this little bit of boost of basically dopamine and serotonin to actually get towards that thing that you want to accomplish. And it just feeds it out little bit by little bit, little bit by little bit until you actually reach the goal and then you get a nice big burst of reward in your brain. It's a wonderful thing. And then that reward falls off really quickly afterwards. For people that suffer from depression, this is actually broken. So if you have to deal with depression, which is a really horrible thing to deal with, this reward cycle is part of the thing that is broken in your brain. And typically serotonin is the thing that's not being managed correctly. And so you don't get that reward. This reward drives every single thing that we do from writing code, to running a marathon, to brushing our teeth. You brush your teeth and your brain kicks in a little thing saying, yeah, good job, teeth are done. But if you deal with depression or if you deal with any of those conditions, you don't get that. Your brain is just sort of like, okay, great, your teeth are done, so what? And by not having that reward cycle, you don't get motivated to do anything. This underpins all of motivation. This is how people become addicted to things. This is why when you buy a new car, you get a really nice new car, like you get that Mercedes that you've always wanted. A couple of days later, it's really awesome the first couple of days, you're like, yeah, this is great. And then a couple of days later, you're like, yeah, this is just my car. Because that reward, that big push that your brain gave you has just kind of popped off now. Now in programming, this ties directly into something that we know is a really good practice. Tester of involvement. So when you're writing code, the goal is to write the feature, right? Like we're not there to write tests. Like I personally think tests are, they feel a lot like busy work. And so if you, what do you think about it, right? The goal is to write the feature. So if you get that little bit of motivation, you're writing the feature, you're building the code, really great, cool, the feature's done. Now it's time to write the tests. And there's a reason why in that structure, when you do the test later development, it's not that you won't write tests, but it takes a lot more discipline to actually get good testing done. And so by putting the busy work first, by putting the testing as part of actually achieving the goal, you're leveraging that reward cycle to actually push you in the right direction of software engineering. Another absolutely excellent example of this, and one of my favorites, if you're working in an office, like an open office, we all love open plan offices, don't we? They're just fantastic. They're so focused, it promotes, let's see, I'm gonna put my management on, it promotes synergy. And I think it's fair to say that this is a problem because human speech is really distracting. We have, there's a special part of our brain that's called Vanica's area. It's located right about here, obviously inside a little bit. And Vanica's area is connected basically directly to our auditory nerve. It runs through that. And so when we hear people talking, especially when we hear certain things like our name, it gets a shortcut to immediately taking our attention. So when you're asleep, if somebody just is talking around you, you're more likely to remain asleep. But if somebody says your name, or if they say something that you are particularly attuned to, you will snap awake. And that's because of Vanica's area. It also means that if you're in an open plan office, you're hearing all of this speech and other people and all that talking all the time. And that part of your brain is engaged with all of this stuff going around you that isn't related to the work that you're doing. So it's distracting, you can use headphones, but they don't block out all the noise. And our hearing is generally pretty good. So you're still getting enough sound in there to be distracting. And the question is like, okay, well this is a problem. And if we're working in an open plan office, how can we fix this? How can we deal with this problem? And the answer is to engage Vanica's area productively and you do that with pair programming. So when you're pairing in an open plan office, I'm an ex-pivot, I worked at Pivotal for a while. When you're pairing in an open plan office, all of that speech going around, because everybody's talking, like I mean there's tons of conversations going on, there's conversations next to you, conversations right across, but you don't feel distracted by it because you're talking to your pair about the things that you're doing. You've engaged that part of your brain. And that part of your brain is engaged in actually doing the work that you're trying to get accomplished. And so you don't get the distraction effect because you've managed to leverage that part of your physiology. Pairing of course has a lot of other things that I love about it. It's a real-time code review. Once again, busy work. I've done a lot of code review. I've never really loved code review, but it's a necessary evil. But if you're pairing, it happens in real time. You don't need to go do it as a separate step because you always have another person there saying, like whoa, Don, what does this thing do? How does this work? What does that variable mean? So you're getting that review in real time, which is absolutely wonderful. And it's also really great when it comes to energy because as a pair, you have two different people and they're gonna have two different kind of like energy levels during the course of the day. You're not gonna move and lock step like this. You're gonna kind of go up and down. And so when you're feeling a little bit less motivated, your pair is probably feeling a little more, has a bit more energy. And so you can say, hey, would you mind driving for a little bit? And that can go the other way around where it's if your pair is feeling a little bit low, you're like I'll drive for a bit, no worries. And if you're both feeling a little bit low, step away and do some ping pong for 15 minutes. That exercise will get your blood flowing and you can actually get back to doing something productive. Really, this is all about one thing. And that is rather than trying to force everything through will and self-discipline and trying to push yourself through absolutely everything, it is that for yourself, you can create an environment where personal excellence is the path of least resistance, where excellence for yourself becomes the default. And that is an amazingly happy place to be. And you do this through establishing that consistent energy, by having stable energy throughout the day, by keeping yourself healthy, which also means taking vacation, taking breaks is appropriate. Those are very important things. You do it by getting regular sleep and by leveraging all of those bits of cognitive annoyance that our memories are limited. We can only make a small number of decisions. The way that reward works in our brain is just bizarre, but when you can leverage all of those things, you can use that to drive yourself towards that absolute excellence as a software engineer that I think a lot of us want to be at and want to maintain. And this isn't really just about being a successful software engineer, this is really about being happy because at the end of the day, that's really what we all want, is to lead a happy life and not just have a successful career. So that pretty much concludes this bit. I always forget to do this part. I'm really, really bad about this. So I write articles on software engineering, so on the worvy.net, and I occasionally try and tweet out interesting articles on Twitter. So are there any questions? I saved about a 10 minute block towards the end if people had questions that they wanted to ask. Okay, so let me repeat the question, both to get along here and to make sure I understood it. So in terms of individual techniques for maximizing happiness, things like, for example, Pomodoro avoiding meetings, working in the afternoon, what works best for me? So there's a combination of things. I've maybe diving into when I've worked as part of a distributed team, so I'm working alone. When you're on a distributed team or a virtual team where you work at home, it really pushes your limits for motivation because you don't have that structure around you to force you to show up to work and do things at those times. One of those things is building that structure. So when I work remotely, I actually have a really rigid schedule. Like I wake up at the same time, I start work at the same time. I have a calendar reminder and I'm half tempted to even write a little app for my Mac that will play like a factory steam whistle. You're like, so that I remember it's like, hey, it's time to cut code. And I make sure my breaks also happen at those consistent times during the day. Those are in the calendar and I get a reminder like, hey, now's the time to take a break. It takes a couple of weeks to get really into the cycle for that because your body takes between one to two weeks to adapt to a new cycle. That's why Jetlag takes between one to two weeks to really kind of wrap itself up. But that's one technique that has really helped me, is rigidly enforcing that cycle. And the nice thing about this is this forces my productivity actually into those times. Once those couple of weeks are up, I'm actually productive at 9 a.m. Like I start working at 9 a.m. and I'm good and I'm motivated. Pomodoro is useful, although for me personally, I have to cut my first session down to five minutes. So I said sometimes even one minute, if I'm having a really bad day, I will set a one minute timer, not a really loud annoying timer, just does a little ding on my machine. And the rule is that doesn't matter if I'm not motivated, if I don't want to code, I just have to do one minute of work. That one minute will usually turn itself into 15 or 20 or 30. Because that's leveraging that mental momentum. Just all I need to do is get over the getting started part. Let's see. Number three, meetings are actually really good things. So meetings, I'm actually writing an article on this right now. It's got kind of timely that you mentioned it. Meetings, I restrict to certain time boxes during the day. I try and pack them nominally at the end of the day. I'll put interviews at the beginning of the day because I want to give every candidate the most fair shake that I can. But meetings in general go at the end of the day and they are rigidly time box. So that I know that towards the end of the day, I'm probably running low on decision power anyway. And most meetings are usually to convey information. I will pre-do my decisions at the beginning of the day. I'll review the content of the meeting and I'll figure out like, okay, I'll make a decision for you, but like if this is what happens, this is where I'd like to go. If this is what happens, I'll go here. And if we fall outside of that, I probably need more information and that's why I'm going to be asking questions. Here are the things I don't understand. And then I'll get to the meeting at the end of the day and I've got that prepared sheet that enables me to get through the meeting without having to spend too much time on decisions or too much energy. So those are a couple of techniques that have really helped me. Have I answered your question, by the way? This is a fantastic question, by the way. So the question is like, as a developer, how do you control your emotions? And I mean, the solution isn't like, well, you should have been born on Vulcan. I mean, be Spock. I mean, that's not the answer, obviously. But this is a great question because like, what was the line in Wreck-It Ralph? Like, you know, my passion bubble is, shall we say close to the surface? It definitely is. And I've had to learn this very, very hard because I would, many, many years ago, I would do things like I would see code and it would be like, oh, well, what idiot wrote this? And I do get blamed and I discovered, oh, I know that idiot. It's me. And so, but like that response is like, what idiot wrote this is actually a really bad thing to say, especially if you're part of a team. You know, because the person that wrote that is now probably feeling pretty awful and you don't want to encourage that sort of behavior. So learning to not do those things and to control my emotions has been quite a journey. A couple of things. One is that I very specifically, if I'm working with other people, when it comes to stuff like that, like that sort of response of like, well, what idiot wrote this, is I ask them to tell me if I'm not being kind. Like, if kindness I think is one of the most fundamental values that you can have on a team. And so it's an open offer of like, anybody who works with me, I really want to know if I'm doing something that's taking me off the rails of kindness. And so like, just grabbing off to the side, let's talk for a second and I promise you, I will not get angry from any of that feedback ever. That is another promise that I make and I keep. Is that if you give me feedback, regardless of what it is, I will accept it and I will listen to it and I will not get angry based on that. When working with code, let's see a couple of things. One, stepping away. Stepping away is really important. You see something, you have that spike, it's like, okay, break time. You know, I need to take a couple of minutes and I need to distract myself or I need to calm down. Maybe I need to talk to somebody. So that's one. Two is stepping back and acknowledging what you're feeling. So this is also a technique, by the way, for overcoming stage fright. So if you, I don't know how much experience everybody has in giving talks or presentations, but I think getting up and giving a presentation and being frightened, having that sort of fear, that trepidation is very normal. And what a lot of people do is they push it down. They go, ooh, I'm not gonna be afraid, I'm gonna be strong about this. And the best thing to do is actually to acknowledge that, to step up and say, okay, you know, I'm feeling nervous. I'm feeling jittery. In the case of code, I'm feeling angry. I'm feeling really stressed or panicked about this. I'm really worried. And to break into why? Why am I panicked about this? I will actually sometimes even write that down. I'll break open a text editor and I'll write down why am I feeling this way? Like, am I stressed about this because I'm worried that I'm gonna have to work late? Am I stressed because I'm worried I'm gonna get blamed for something? And really breaking down the reason why you feel that strong emotion the way that you do. By doing that, by the way, you can bring that up during retrospectives. And you can say, like, hey, I, you know, I felt really stressed about this because I was really worried that, like, I was gonna get yelled at. And so like, why did I feel that way? Maybe we've got something in our culture that we need to fix. And this is a really good indication for that. So I think that that's kind of my breakdown is that stepping back, acknowledging how you feel, and analyzing it, like actually breaking down, like why those emotions are where they are, really kind of helps you get past that sort of panic hump. And it'll only cost you maybe about five or 10 minutes. You can even time box it. You might still feel a little bit of vestigial emotion, but you're not gonna be feeling the sort of like, grrr, kind of a thing. So does that answer your question? Cool. I think I have time for one more brief question before running over my time box. Yes. Yes, so let me repeat this. So this is, so when you get into that flow, and I do, by the way, exactly the same thing. So when you get into that flow, right, you get into your day and you get that four hour section of time where you're just hammering out code and you look at them and you're like, oh, ha, ha, ha. It's 2 p.m. So I think number one is you really have to work with your body, like this is very important. You have to work with your body. Everybody has a different body, right? Like they're different, they have different limitations. And so paying attention, that's really important. When it comes to flow, if you get a really good flow going in, I would actually say keep it, leverage that and ride that wave. But when you kind of like get to the end of that and you're feeling like, okay, I'm a little bit done, that's when you take it a point to step back and you're like, okay, I'm gonna take a break and maybe I'm just gonna stand up, maybe I'm gonna go around for a walk. I've got, what I'll do when I'm working from home is I'll literally just go out and I'll kind of walk around my apartment building or I'll go walk down, I live right by the ocean so I'll maybe walk a little bit past that. So that's one way of doing things. Maybe something I've done in an office before is you step up and you're like, okay, it's break time. Other people are here, we have a ping pong table, go find a person to play ping pong with. If you're pairing, by the way, this is really great because you have somebody to play ping pong with, they're right there. And if you can find another pair, you can do doubles. By the way, I suck at ping pong. I am really bad at ping pong. Hacky sack as well. I actually, I realized that I'm probably showing off the fact that when I graduated high school and the fact that I mostly hung out with donors. But I keep a hacky sack in my backpack and I'll bring that with team sometimes. So it's like, hey, break time, let's go and just, kick the hacky sack around a little bit. Things like that. And the other thing is that rather than trying to fit that as part of your working day, like little bits of activity where you get up and you move around are great. Standing desks, by the way, also help with that. Like so if you have a desk that can be variable, you can stand up and as you're standing up you'll kind of move around a little bit. So that can help. But by, really it's setting a consistent time during your day or during your week. You have a regular schedule of like, hi, after work or before work, this is gonna be my time to do something I enjoy. Some sort of exercise. And so between the two of those things, by having a regular, I hesitate to say the workout schedule, by having a regular activity schedule, because it could be things like dance. You know, it could be badminton, it could be any number of things that just get you moving. So by having, it could be that you walk to the office. That's really enough. Like, you know, if you get 30 minutes of walking in a day, that's really kind of your minimum exercise quotient. And if that's all you need to be happy, then that's great, do that. And so by combining that, that regular activity schedule with, when you do take, like when you hit that point where you wanna take a break, acknowledging like, hey, it's break time. Like, I've come out of the zone, I'm gonna step away from the machine, I'm gonna do something else. Hackey sack, ping pong, walking around. Changing my position, any of those things. By doing that, you get more motion in your day. Have I answered your question? Yes, three for three, answered questions. So I think I'm out of time for today. Okay, that's too bad. Our time here is limited. Thank you very much.