Software Engineering

Summarized using AI

To Code Is Human

Don Werve • April 25, 2017 • Phoenix, AZ

In the talk 'To Code Is Human' by Don Werve at RailsConf 2017, the speaker emphasizes the importance of understanding the programmer's brain as a critical tool in software development. He argues that while programmers often focus on computational efficiency and the latest languages or frameworks, they tend to neglect the human aspects of coding which can significantly affect productivity and the quality of software production.

Key Points Discussed:

  • The Hardware and Software Connection: Werve outlines that just as companies invest in hardware for their teams, programmers should invest in understanding and maintaining their own cognitive functioning and mental health.
  • Ante Work Concept: He introduces the notion of 'ante work,' explaining how working while tired leads to poor coding practices, which ultimately create more problems than they solve.
  • Quality Over Quantity: The speaker stresses the need for quality hours rather than just more hours, asserting that good sleep and consistent energy levels are crucial.
  • Nutrition and Exercise: Suggested that diet impacts mental performance, recommending avoidance of fast carbohydrates and promoting regular exercise as essential for maintaining high energy levels throughout the day.
  • Understanding Cognitive Limits: Werve highlights how our brains process information and how the working memory is limited. He advises structuring code for readability to accommodate these human limitations, improving long-term retention and understanding.
  • Decision Fatigue: He discusses how decision-making can drain cognitive resources and suggests building habits instead of relying solely on self-discipline to help manage everyday tasks and choices effectively.
  • Pair Programming and Open Workspaces: The usefulness of pair programming is mentioned as a solution to distraction in open-plan offices, making work more engaging and less isolating.

Significant Examples:

  • Werve shares personal anecdotes from his professional experience in a company transition, illustrating the consequences of poor coding practices amid exhaustion.
  • He references studies on decision fatigue, particularly in the context of judges granting parole, showing how timing affects important decision outcomes.

Conclusions and Takeaways:

Werve’s key conclusion is that by investing in our cognitive health, understanding our limitations, and creating environments conducive to productivity, programmers can enhance their effectiveness. Ultimately, he posits that fostering these practices leads not only to better coding but also to a more fulfilled and happier life as a software engineer.

To Code Is Human
Don Werve • April 25, 2017 • Phoenix, AZ

RailsConf 2017: To Code Is Human by Don Werve

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.

RailsConf 2017

00:00:11 Oh good, this thing still works. That's excellent! I love it when that happens. So, 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 jetlag. Yay!
00:00:19 And everybody in here is probably feeling nice and energized. You know, it has that special time of the day where you're just raring to go. So anyhow, I want to riff a little bit off of DHH from earlier today. I think real Rubyists and Rails programmers have this subconscious tendency, and maybe you’ve noticed this as well.
00:00:38 We're always looking at other languages. Saying things like: 'In Go, 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 and write my web code in assembly.
00:01:03 I think this is 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 computing tools that we have. And because of this sort of obsession—I'm certainly guilty of this focused on the machine and how to use it efficiently—we tend to neglect the human side.
00:01:15 You know, the most important tool that we have in our toolbox. So this talk is about software engineering, but we’re not going to talk about SOLID principles, which is great. We’re not going to discuss hexagonal architecture, nor data structures and algorithms; we're going to focus on the human infrastructure of code, sort of DevOps for the developer, if you will.
00:01:40 To lead into this, my academic background is in mathematics. I'm one of those people who has a math degree. And there's an old joke: 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!
00:02:06 Programmers are kind of similar in that respect. You could think of a programmer as a machine: you put coffee in, and you get out mostly working software. The reason I bring this up is not to say that programmers are machines, but rather to illustrate that your mind is your most important tool in your toolbox. To get the most out of it as a programmer, it’s very important to learn both how the mind works and how to maintain it. This is a crucial investment for a working programmer.
00:02:26 In 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. So, to talk about that, we’re going to start with the hardware.
00:02:55 Hardware matters because, without taking care of your hardware, your software is going to suffer. A good example I like to bring up is from one of my first gigs as a CTO in Japan. I worked at a company that was part of the great coupon rush around 2009, when everybody was focusing on daily deals and coupons, like Groupon and the like.
00:03:09 During the course of working there, we had to transition from an old system based on a CMS that couldn't cope with scale to a new system that we had rewritten using Rails. We worked a lot of hours; the team put in a ton of extra time to meet the deadline. I’m sure nobody in here knows what that's like. We set up a schedule so that we had a fresh team coming in for launch day, and then the launch team would go home early and get some sleep.
00:03:39 All of this was set up, and the transition went really smoothly, much more smoothly than I anticipated. I was part of the launch team and went home to get some much-needed sleep—about five hours later, I got a very panicked call from one of the senior engineers on the team saying, 'Hey, we found a bug. It's pretty bad; the database is locking itself up consistently, and we have no idea why. We can’t identify the source.'
00:04:11 Because I had only five hours of sleep, I realized I needed to do a bit of digging into this database locking. I said, 'Oh, I know exactly what the bug is. I wrote it!' Cash expert is indeed a hard problem, and I had kind of screwed it up. I know better than this; I absolutely know better than to handle cache expiration this way, but I wrote that bit of code when I was exhausted.
00:04:38 This leads to what I like to call 'ante work.' It's like matter and antimatter: you combine the two, and you get a huge explosion. Ante work and work are kind of the same thing. If you write your code when you are exhausted, if you push yourself to crank out those lines, you tend to produce things that will later sabotage the codebase and the team.
00:05:18 Although it feels like you're getting stuff done, you’re actually sandbagging things for the future. Ante work is writing code that destroys productivity. The reason is our bodies don’t have infinite capacity for getting stuff done. We have limits, and so when we think about our hardware, which drives our minds, what do we really want to optimize for?
00:05:41 We're probably not trying to optimize for things like strength or speed like being able to lift a lot of weight or being as fast as the Flash because that isn’t very useful to us. It’s not a bad thing, but it's not useful. What we want to focus on is having really consistent energy delivery. This is easy to ignore because we focus so much on getting more hours.
00:06:01 We obsess about having more time; we don't sleep enough, pull all-nighters, and we use caffeine to get more hours in the day. Nootropic drugs are not uncommon, and yes, you can get more hours. But alcohol is like a magical thing that enables you to steal happiness from tomorrow. It seems great tonight, but then you wake up the next morning, and it’s not so great—especially for me; the hangovers last about a day.
00:06:26 Rather than trying to get more hours in the day, we should ensure that the hours we do have are of the highest possible quality. Everybody here knows what the 'zone' is. We know what it’s like to sit down, work, and be in the zone. That’s when we sit down, and it’s like hacker typer. Everything is flowing nicely; it’s beautiful. I think that’s why we are programmers.
00:06:49 Programming is happy during that time because we are into pure creation—it's the pure connection between the mind and the machine. Rather than having a 12-hour day with maybe one or two hours in the zone, what if we could have seven to eight hours of really focused work, where most of that time is in that happy zone? That’s why we want to focus on consistent energy.
00:07:20 The most fundamental aspect of consistent energy is sleep. Sleep is so important. It's the time when not only your brain takes care of itself but also where your body heals and manages all of those other wonderful things. The focus should be on better hours, not more hours. Cutting sleep to get more time is self-sabotage, and that’s ante work.
00:07:47 One of the best ways to ensure that you get good sleep is to set your alarm clock so you wake up at the same time every day. Our bodies are fairly rhythmic, and if you have a consistent wakeup time and you go to bed when you start feeling tired, listening to your body gives you that really nice sleep. It will help level out your energy levels during the day.
00:08:18 This was a hard thing for me to do, especially on the weekends. You have this urge like, 'Oh, I party; I’m going to go do stuff.' By breaking that sleep cycle on the weekends, you literally give yourself jetlag every single weekend. You have to recover from that at the beginning of the week.
00:08:49 As for consistent sleep, I hate to say this because I love whiskey and I love a beer just as much as the next person, but alcohol really kills your REM sleep quality. If you ever had a night of drinking and sleep for 10 or 12 hours, you don’t really feel rested. It’s because alcohol sabotages your REM sleep cycle. I avoid alcohol like the plague during the weekdays because it really affects me the next morning.
00:09:22 So in terms of maintenance, sleep is important because it sets a daily rhythm for us. This is critical because we are very rhythmic creatures. We have two main cycles: daylight, which is our sleep cycle, and a food cycle. When we take our meal times, I think there’s a water cycle in there somewhere as well.
00:09:55 The combination of those two cycles regulates how our body deals with energy during the day. For example, when living in Japan, when you travel internationally, as soon as you land at your destination, you should try to adopt the food cycle of that destination. You can’t reset your sleep clock easily, but you can reset your food clock with just a couple of meals.
00:10:27 You can leverage this during your normal day as a working programmer by having your meals at consistent times. For instance, if at 7:00 a.m. that’s when you have breakfast, at 12:30 is when you have lunch, and 7:00 again is when you have dinner, and your body will adapt to these times. You will only become hungry at those times, which is nice, smoothing out your energy delivery.
00:10:56 It reduces physiological stress on your system, which, of course, boosts focus—all wonderful things. The first thing I did to solve that problem was to use a calendar I set up with reminders. And apparently, I needed that. Some people can get away with other things, but making that irregular rhythm throughout the day helped me stabilize my energy.
00:11:29 Speaking of food, food is essential. It powers your mind; it fuels your brain. I’m not going to dictate diets because people will obviously make their own choices. One thing that really helped me with food is to avoid fast carbohydrates. When you take carbohydrates, they are energy sources that power your body and mind.
00:11:56 When you consume fast carbohydrates, they get processed quickly, causing your pancreas to ramp up insulin production very quickly. You've probably noticed that if you have sugary foods like pop-tarts for breakfast, you feel a spike of energy, then about 10 or 15 minutes later, you're hungry again.
00:12:25 That’s because of the insulin spike you get, which creates a spike of energy followed by a sudden drop. You will eat something else or have some caffeine to compensate for that energy loss, ending up on this rollercoaster energy cycle throughout the day.
00:12:56 By avoiding simple carbohydrates and sugars—things like wheat bread—and focusing on foods like rice or pasta, assuming that works for you, you can help to level out your energy throughout the day. Additionally, exercise is vital for overall well-being. Motion is life! Living things move, including plants.
00:13:32 If you watch a time-lapse of a flower chasing the sun during the day, you notice that even plants are active—they are seeking out nutrients. Our bodies want to move. There are numerous documented benefits to exercise, yet as software engineers, we tend to skip it due to focusing too much on work.
00:14:00 It's not about going to the gym or engaging in routines others suggest; it’s about finding something you love that keeps you active. Personally, I hate running, but I found that I love lifting weights and was a powerlifter for many years. Others may enjoy dancing or hiking. There’s something out there for almost everyone.
00:14:30 Having exercise on a regular basis really helps with consistent energy because it’s great for your cardiovascular system, which means it’s great for your brain too. One of the tools I use to ensure I keep my exercise schedule consistent is following the rule of 'I have to show up.' In the morning, I really struggle to work out, but my rule is to do one push-up.
00:15:02 If I can get through that one push-up and want to stop, that’s fine—but typically, it leads me into more exercise. Another thing that’s helped is setting incremental yet achievable goals. In software, this is critical; you don’t try to build a gigantic feature that takes two or three months in one shot; you do it little by little.
00:15:31 Exercise is the same way; you can aim to do one more push-up each day. Lastly, tracking your progress is a great motivational tool. Seeing how you are progressing over time is very encouraging, just as it is in software—seeing your features develop over time is motivating.
00:16:05 These three things are the pillars of having consistent energy throughout the day, and I cannot stress how important consistent energy is because that's what puts people at the top of their game. It helps you optimize whatever hardware you have so that you can get the most out of it.
00:16:31 Great hardware means that we need great software, so the next topic I’m going to touch on is caring for our software—i.e., our minds. We’re Rubyists, and there are quirks in Ruby. A good Rubyist knows the nuances of their language. For instance, in Python, an empty string is false, while in Ruby it is true.
00:16:56 Such quirks can lead to frustration and can cause bugs if you're switching between the two languages. Just like any tool, our minds have their limitations, so being aware of them and understanding how they work can help us maximize their potential.
00:17:20 For sighted people, we are actually blind for 40 minutes every single day and don’t even realize it. One reason we’re blind is due to the way our eyes function. We have a narrow focus area, extending only to the webbing of our fingers while everything outside that is blurry.
00:17:45 When looking at an object, our eyes are constantly moving in a process called saccades, stitching together a consistent picture. These saccades have limited range, and if you extend your arm, your head will naturally move to follow your hand since it's a strenuous motion for your eyes.
00:18:05 This means that when you buy a novel, they tend to have shorter lines, typically 60 to 72 characters, so you don’t exhaust your eyes by looking too far. Our brains have weird limitations too, like our working memory, which can hold seven items, more or less.
00:18:34 When this memory overflows, our brain compacts that information based on what it thinks is important. This is different from a computer that simply dumps the score. When working on a lengthy function in Ruby, if you get lost, it may be because your memory is overwhelmed, and you’re not even aware of it.
00:19:03 Being aware of this phenomenon improves software engineering practices. For instance, when looking at long lines of code, it’s not just about the number of lines; it’s also about keeping those lines manageable within working memory. The same applies to indentation rules; these may seem arbitrary, but understanding the cognitive limits behind them makes sense.
00:19:31 This really matters because without this understanding, it’s easy to craft things that comply with rules but fail to achieve their purpose. Take this little snippet of code from a production scenario many years ago. In Ruby, the language allows for concise coding, and code golf isn’t uncommon.
00:20:01 The idea is to write smaller code because, in smaller code, there are fewer places for bugs to hide. However, there were a few bugs hidden within this code. Readability matters, not only because of previous rules discussed but also because of how our memory functions.
00:20:28 Our long-term memory evolved to remember stories. Humans have conveyed stories for millions of years, while written communication only developed about 10,000 years ago. In ancient Rome, Cicero managed to remember the names of everyone at a large dinner after a tragic event because he had previously told a story involving all the attendees. This is called the method of loci.
00:20:54 Telling such stories provides a cognitive fast-track into long-term memory, similar to well-written code. When you write clear, understandable code, it becomes easier to recall. If we refactor the last snippet into something more readable, not only do some bugs vanish, but the context of that code becomes clearer.
00:21:24 Another interesting aspect of our physiology is that making decisions is immensely challenging. If you walk into a fast-food place with numerous options, it can be overwhelming. Conversely, at places like In-N-Out, with limited options, it’s much easier to make a choice. Our brain can only manage a limited number of decisions daily, which requires conserving energy.
00:21:56 A study done by Stanford University investigated inmates going up for parole. Inmates learned that they should try to schedule their interviews for early morning, as judges would be more receptive and granting paroles than at the end of a long day when their decision capacity waned.
00:22:29 This principle also applies to job interviews. If you can set your interview at an early hour, the interviewer will be more alert and engaged. This ties into self-discipline; discipline involves making continuous decisions. Instead, building effective habits can be more effective than self-discipline.
00:22:57 When forming habits, you teach your brain to do the right thing automatically. This can even save your life! In hotel fires, most casualties occur in bathrooms due to a lack of awareness of the quickest escape route. If, when staying in a hotel, you identify the emergency exit upon check-in, your brain will retain this information even during an emergency.
00:23:27 Focusing on long-term practices is hugely important when it comes to programming best practices. One great example is the reward cycle, a crucial aspect of how we motivate ourselves. When you want to accomplish something, you establish a goal, and your brain rewards you with a boost of energy, dopamine, and serotonin as you make progress.
00:23:58 But these rewards fall off quickly. For individuals suffering from depression, this cycle can be broken, as serotonin management falters, leading to a lack of motivation. This cycle drives all action we take—from writing code to running marathons to brushing our teeth. You perform a task, and your brain gives you recognition.
00:24:25 In programming, this can be related to test-driven development. The goal should be to write the feature, as the reward cycle is most active in achieving that. If you delay writing tests until later, it’s easier to get off track and avoid that necessary discipline.
00:24:55 When testing comes before the feature becomes inherent to the process, motivation aligns with productive output. Office environments, particularly open-plan offices, can be distracting.
00:25:25 Our brains are highly attuned to auditory stimuli. If there’s background talking and noise, you can be pulled from focus. Engaging with a partner in pair programming counters these distractions. You might hear conversations around you, but when you're engaged in a focused discussion about your work, that part of your brain is now effectively engaged.
00:25:55 Pair programming also serves as a real-time code review mechanism. I've done a lot of code reviews, and while necessary, they're often tedious. When pairing, you receive immediate feedback and collaboration. Additionally, working with a partner can help manage energy levels throughout a project.
00:26:25 One person might feel up while the other might feel low, allowing you to negotiate who's driving. If both you and your partner feel down, taking a quick break—perhaps by playing ping pong—can rejuvenate your productivity.
00:27:00 This approach is about facilitating an environment where personal excellence is the path of least resistance. By establishing consistent energy with healthy habits, both physically and mentally, we can reach such a point. This isn’t just about being a successful software engineer; it’s about being happy.
00:27:36 At the end of the day, isn’t this what we all want? To lead a happy life while contributing to the world of tech? That concludes this segment of my talk. I often forget to mention this part, but I write articles related to software engineering on my blog.
00:28:01 I also try to tweet out interesting articles, so feel free to check that out. Now, are there any questions? I saved a 10-minute block towards the end for any questions you may have.
00:28:35 Let me repeat the question for clarity. In terms of techniques for maximizing happiness, such as the Pomodoro technique or avoiding meetings, what works best for me? There are a combination of strategies I might dive into.
00:29:02 When I’ve worked as part of a distributed team, where I’m working alone, it can push your limits of motivation because you lack structure. One thing that helps me is building a rigid schedule. I wake up at the same time, start work at the same time, and even have calendar reminders to keep me on track.
00:29:35 I need this structure because it reinforces productivity. Once my body adapts to this routine, I find myself productive by 9 a.m. Pomodoro can be effective; I often start with very short concentrates of five minutes, which can lead to a longer productive session.
00:30:05 Meetings can be good for productivity, so I try to limit them to specific time blocks. I generally schedule them earlier in the day to ensure greater focus and attentiveness from everyone involved.
00:30:34 I hope I answered your question. I think I'm out of time for today, but thank you all. I appreciate your attention!
Explore all talks recorded at RailsConf 2017
+109