We're sorry but this page doesn't work properly without JavaScript enabled. Please enable it to continue.
Feedback

To Code is Human

00:00

Formal Metadata

Title
To Code is Human
Title of Series
Part Number
23
Number of Parts
86
Author
License
CC Attribution - ShareAlike 3.0 Unported:
You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal and non-commercial purpose as long as the work is attributed to the author in the manner specified by the author or licensor and the work or content is shared also in adapted form only under the conditions of this
Identifiers
Publisher
Release Date
Language

Content Metadata

Subject Area
Genre
Abstract
Programming is a deeply mental art. As programmers, we invest large amounts of time in mastering new languages, new techniques, and new tools. But all too often, we neglect our understanding of the most important tool in the developer's toolbox: the programmer's brain itself. In this talk, we will combine the art of programming with the science of cognitive psychology, and emerge with a deeper understanding of how to leverage the limits of the human mind to sustainably craft software that is less buggy, easier to understand, and more adaptive in the face of change.
35
Goodness of fitLevel (video gaming)Virtual machineSoftwareComputer programMathematicianData structureQuicksortCodeFormal languageTheoremMultiplication signComputational complexity theoryMathematicsBitComputer hardwareSimilarity (geometry)Computer clusterWeb 2.0NeuroinformatikFocus (optics)Computer architecture1 (number)Process (computing)Cellular automatonComputer programmingAlgorithmSoftware engineeringSoftware developerOperator (mathematics)Degree (graph theory)Ring (mathematics)XMLComputer animation
CodePhysical systemConsistencyMultiplication signGroup actionComputer hardwareState of matterSystem callChannel capacityFocus (optics)Product (business)Food energyString (computer science)Open sourceMathematical optimizationCanadian Mathematical SocietyDatabaseComputer programWeightCache (computing)Flash memorySoftware bugMereologyAntimatterLine (geometry)SoftwareBitError message
Multiplication signSpeech synthesisFood energyLevel (video gaming)Focus (optics)Daylight saving timePower (physics)Cycle (graph theory)RankingCombinational logicHacker (term)Energy levelComputer programmingVirtual machineAxiom of choiceConnected spaceConsistencyQuicksortComputer programInstance (computer science)NumberBasis <Mathematik>Product (business)Stress (mechanics)Real-time operating systemInsertion lossSoftware maintenancePhysical systemMereologyInfinityCodeTime zone
Food energyArithmetic progressionMultiplication signComputer hardwareNumberOpen sourceConsistencySoftwareRootRule of inferenceString (computer science)Chord (peer-to-peer)Software bugComputer programScheduling (computing)Power (physics)Special unitary groupLimit (category theory)Arithmetic meanWordStress (mechanics)Reading (process)VideoconferencingPhysical systemGame theoryBitPresentation of a groupTrailTouch typingComputer programming
Semiconductor memoryBitClique-widthRight angleBuffer overflowArmAreaDisk read-and-write headCompact spaceFunctional (mathematics)Focus (optics)Single-precision floating-point formatNeuroinformatikSoftwareElectronic mailing listQuicksortSoftware engineeringFood energyCore dumpConnected spaceConsistencyLine (geometry)Limit (category theory)Range (statistics)Power (physics)Machine visionSet (mathematics)Digital electronicsStress (mechanics)FlagComputer animation
Limit (category theory)Functional (mathematics)Semiconductor memoryLine (geometry)Rule of inferenceNumberLevel (video gaming)Sheaf (mathematics)Point (geometry)CodeTouchscreenComputer animation
CodeSemiconductor memoryProduct (business)Right angleTerm (mathematics)CASE <Informatik>Software bugWritingFormal languageGoodness of fitComputer animation
QuicksortMereologyTable (information)InformationImplementationData structureSpeech synthesisTrailPersonal identification numberComputer animation
Mathematical optimizationMultiplication signTerm (mathematics)TrailStructural loadCodeQuicksortSemiconductor memorySpring (hydrology)Data storage deviceFrequencyInformationContext awareness
HexagonMultiplication signNumberComputer configurationGraph coloringProcess (computing)Food energyMoment <Mathematik>Axiom of choiceSoftware bugDecision theoryRight angleObservational studyLimit (category theory)CASE <Informatik>Term (mathematics)Context awarenessContent (media)WordMereologySystem identificationPrisoner's dilemmaCodeVector potentialBitPoisson-KlammerSqueeze theoremAmsterdam Ordnance DatumMetropolitan area networkHidden Markov modelDefault (computer science)Universe (mathematics)
Direction (geometry)Office suiteKeyboard shortcutPlanningMereologyRight angleAreaFood energyBookmark (World Wide Web)Decision theoryComputer programmingBitOpen setCodeFile formatBuildingMultiplication signSpeech synthesisSound effectSoftware engineeringIntegrated development environmentDefault (computer science)Video gameBlock (periodic table)Control flowGoodness of fitProcess (computing)Semiconductor memoryWindowData managementNoise (electronics)Software testingData conversionNumberCondition numberCycle (graph theory)Data structureForm (programming)WordCognitionEnergy levelSoftware developerSoftware design patternKognitionswissenschaftExpert systemDifferent (Kate Ryan album)Graph coloringExecution unitReal-time operating system
Scheduling (computing)Multiplication signCombinational logicRight angleLattice (order)FeedbackMatching (graph theory)Control flowLevel (video gaming)MereologyFrequencyNumberQuicksortExecution unitError messageRule of inferenceTwitterVirtualizationPresentation of a groupWritingOffice suiteData structureFamilyMoment (mathematics)Maxima and minimaBlock (periodic table)Network topologyCodeCycle (graph theory)MomentumGame controllerBitDecision theoryOpen setForcing (mathematics)Parameter (computer programming)Product (business)InformationVirtual machineLimit (category theory)Software engineeringNumbering schemeFilm editingSoftware developerGroup actionPrice indexDifferent (Kate Ryan album)Position operatorOnline helpComputer clusterArithmetic meanSurfaceDependent and independent variablesWaveDataflowRing (mathematics)Point (geometry)BuildingExtension (kinesiology)Normal (geometry)Term (mathematics)Sheaf (mathematics)CASE <Informatik>Factory (trading post)Time zoneFigurate numberLine (geometry)CuboidMobile appConsistencyPower (physics)Content (media)QuotientLecture/Conference
XML
Transcript: English(auto-generated)
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 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 kind of want to riff a little bit off of DHH from earlier today in that, you know, I think as both Rubyists and as Rails programmers we have
kind of this maybe subconscious 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 programs, I certainly am guilty of this, in focusing on the
machine, on how 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 going to talk about solid, which is great, and we're not going to talk about hexagonal architecture, we're not going to talk about data structures and algorithms, and we're going to 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 can 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'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. 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 going to 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 placed, 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 get 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. 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, cache 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 cache 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 antimatter, 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 base and sabotage 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 to the future. And so that's anti-work, because when you write that code, that 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, 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'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.
Neutropic 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 the next morning, 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 want to 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, but 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 know, you have this urge like, oh, you know, I want to go out and party. I want to have a good time. I'm going to 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 well, 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. You know, 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 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 reset your sleep clock very easily, but you can reset your food clock with just a couple
of meals. 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 7am, that's when you have breakfast, and maybe at 1230, that's when you have lunch, and 7 maybe is when you have dinner, and your body will adapt to this and you will, 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 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 are 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 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 honestly wheat breads, and focusing on things like rices and pastas, 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 rices 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 in 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 plant 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, you know, going to the gym or doing CrossFit or, you know, 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 pushup because I'm doing body weight stuff right now, just one. And if I get done with that one pushup 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 fits. Exercise works the same way, where my goal is to do one more pushup 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 is 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
that's what helps you optimize whatever hardware you have that helps you get the most out of that hardware. while great hardware is one thing, great hardware means that we need great software. And so that's the next thing we're going to touch on is caring for our software, e.g. our minds.
Now, we're Rubyist and as a good Rubyist, you know the quirks of Ruby. know the quirks of the language. Really, any good programmer knows the quirks of their language, 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 that we don't know that we're blind for 40 minutes every single day. And 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 like
like
bit past shoulder width. That's about as far as your cicade 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 if you start going beyond that you're going outside the scope of what you can read in a single cicade 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 ancient typographers
there's another interesting thing about the way that our our brains work and that is your memory yeah 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 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 you know the the data you've stuffed 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 your brain focuses on remembering things that are almost right so if you've ever been working in a really big function right in Ruby and you get kind of lost with with what's going
on I'm going to 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 line and 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 and the same goes for the the three levels of indentation these rules feel arbitrary but if you understand the the limits behind them the physiological and the cognitive limits all the sudden they start to make a lot more sense and this why i think really matters because without the why is really easy to craft things that are that follow all
the rules but that still fail to achieve the the purpose for example this this is a little snippet of code from some production thing many many years ago and i i think every single one of us we Ruby enables us to write this really concise language and code golf is not uncommon i think in in Ruby and 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 the about but because also of how our memory works in this case we're not going to talk just about long term 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 the ability to write things down and convey things through written information has only existed for about ten thousand years or so there
abouts we to remember stories back in ancient rome there was a guy named cicero and he was once part of a very large dinner 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 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 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 in your memory because you have built code that optimizes for long term storage and so if we refactor that 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 it's like okay we have a short color and a long hex color and and want 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 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 of our physiology is that decisions are really
if you go into a Carl's Jr or 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 like hmm chicken sandwich sounds going I'm not really sure whereas if you walk into an in and out for anybody else who's from California you know and and in you have you can burger or you can have a cheeseburger
and that's pretty and you can have a drink and fries and those are 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 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 a panel of people that will make the decision as to whether or not you get to get released early and if
you 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 refresh they would actually listen to what you had to say and they would consider your 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 thing by the way applies for job interviews so if you have a chance to set up a screening for a job interview you want
to set because you know what really is self discipline right self discipline is choosing when we don't want to to do the right thing you know 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 in my jet lacked and the 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 we're all at a conference and uh i'm willing to bet that everybody who's out of town is probably staying in a hotel now in a hotel fire most people like it hotel fires are really really tragic and most people tend to die in their bathrooms they 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 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 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 uh science is using the reward cycle so the reward cycle is uh is a really critical
part of things it's actually what forms addiction in that your when you want to accomplish something you have a goal something that you want to do um you establish that goal and then your brain consistently gives you this 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 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 uh you know for people that suffer from depression this
is and so you don't get that reward like this reward drives every single thing that we do from writing code to running a marathon to brushing our teeth you know you brush your teeth and your brain kicks in a little thing saying yeah good job teeth are done okay but if you're if you're dep if you deal with depression or if you deal with any of those conditions
you don't
like I personally think tests or 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 motivations you know you're writing the feature you're building the code really great cool the features done now it's time to write the test and there's a reason why in that structure when you do
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 you know you know it promotes let's see I'm gonna put my management on it promotes synergy you and this I think it's fair to say this is a problem because human speech is really distracting
we have there's a special part of our brain it's called Vanica's area it's located right about here well 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 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 this this speech and other people and all that talking all the time and your
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 if we're working in an open plan office how can we
how can we fix this how can we deal with this problem and the answer is to engage vernica's area productively and you do that with pair programming so when you're pairing in an open plan office i'm i'm an expit but i worked a pivotal for a while when plan office all of that speech growing around because everybody's talking like i mean there's tons of conversations going on 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 now and and that part of your brain is engaged in actually doing the work that you're trying to get
busy 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 has a bit more energy and so you can take 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 like i'll drive for a bit no worries and if you're
you're both 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 those are very important things you know you it's a cognitive annoyance that you know our memories are limited you know we can only make a small number of decisions you know 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 that absolute excellence as a software engineer that I think a lot of us want to want to be at and want
to
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 i wake up at the same time i start work at the same time i have i have a a calendar reminder and i'm half tempted to even write a little app for my mac that will play like a factory steam whistling like so that i
between one to two weeks to adapt to a new a new cycle that's why jet lag takes between one to two weeks to really uh to really kind of wrap itself up but that's one technique that has really helped me is 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 at one minute if i'm having a really bad day i will set a one minute timer uh not a really loud annoying timer just does a little thing on my machine and uh
the rule is that it doesn't matter if i'm not motivated if i don't want to code i just have to 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 um 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 uh i i restrict to certain time boxes during the day i try and pack them nominally at the the end of 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 you know i'll make a decision tree 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
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 the question is like as a developer how do you control your emotions and i mean the solution isn't like like well
you should have been born on vulcan uh i mean be spock i mean that's that's not the answer obviously but this is a great question because like um uh what what was the line in wreck it ralph like you know my passion bubble is shall we say close to the surface uh it definitely is and i've had to learn this very very hard because i would uh many many years ago um i would do things
like i would see code it would be like like what idiot wrote this and i do get blame and i discovered learning to not do those things and to control
my emotions has been quite a journey a couple of things um one yeah is that i very specifically if i'm working with other people when it comes to stuff like that like that that that's sort of responsible like what idiot wrote this is uh i ask them to tell me if i'm not being kind like like if if kindness I think is is one most fundamental values that you can have on a team and
so it's 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
you have that spike it's like okay break time you know i need i need to take a couple of minutes and i need to distract myself or i need to 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 um so this is also a technique by the way for overcoming stage fright so if you uh i push it down they they go you know i'm 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 you know 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
you feel that 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 um 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 really kind of helps you get past that sort of panic hump and it'll only cost you maybe about five or ten minutes you can even time
box it uh you might still feel a little bit of vestigial emotion but you're not going to be feeling the sort of like kind of a thing so so does that answer your question yay cool uh 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 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 you you get into your day and you get that four hour section of time where you're just hammering out code and you look and you're like oh ha haha ha it's it's two pm so i think number one is 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 they're different they have different limitations and so paying attention that's really important when it comes to flow if if you get a really good flow going in i would actually say
stand up maybe i'm gonna go around for a walk you know 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 right by the ocean so i'll maybe walk a little bit past that um so that's one way of doing things uh maybe uh something i've done in an office before is you step up and you're like okay it's break time um
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 to play ping-pong with they're right there um and when i graduated
high school and the fact that i mostly hung out with stoners but i have i keep a hacky sack in my backpack and i'll bring that with teams sometimes so it's like hey break time let's let's go and just you know kick the hacky sack around a little bit things like that and the other thing is that rather than trying to fit that in as part your working day like little bits of activity where you get up and you move around a great standing
desks by the way also help without like so you can if you have a desk that can can be variable you can stand up and as you're as you're standing up you'll kind of move around a little bit so that can help but by really it's it's setting a consistent time during
things like dance you know could be badminton could be any number of things that just get you moving so by having you 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 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 else hacky sack ping pong walking around uh
changing my position any of those things by doing that you get more emotion in your day have i answered your question yes three four three answered questions so um i think i'm out of time for today okay that's too bad aw our time here's limited thank you very much