Think Twice, Code Once

Bill Chapman

Bill Chapman

1 talk

#cognitive-psychology

#software-development

Think Twice, Code Once

by Bill Chapman

In the presentation "Think Twice, Code Once" by Bill Chapman at MountainWest RubyConf 2013, the speaker emphasizes the importance of dedicating more time to thinking rather than simply coding. He introduces the idea that effective problem-solving in software development requires a shift in mindset, where programmers must understand the value of thoughtful contemplation in addition to active coding. Chapman discusses various thought processes and cognitive models to argue that most individuals remain stuck in the 'advanced beginner' phase of problem-solving, often overlooking the depth of thought required to excel at software development.

Key points include:

- Cognitive Awareness: Chapman highlights that productivity is affected by how much time is dedicated to thinking, rather than just coding. He references the Dreyfus model of skill acquisition and the Dunning-Kruger effect, asserting that most developers may not realize their limitations in expertise.

- Miscommunication in Work Environments: He points out that programmers often encounter misunderstandings with non-programming colleagues about their work processes, including time spent away from the computer as an essential thinking activity.

- Examples of Programmers:

- The Freshman: Typically inexperienced programmers who fail to think through problems, producing code that may pass tests but lacks depth.

- Mrs. Roberts: Developers who patch problems without understanding the larger context, leading to repeating the same mistakes.

- Bob Ross Fan: Coders who create layers upon layers that obfuscate actual functionality due to an intuitive approach rather than structured thinking.

- The Mercenary: Those who work for profit without genuine investment in their craft, often producing mediocre results.

- Pointy-Haired Boss: Managers who focus on quantifying productivity without understanding the complexities of the thought processes behind programming.

- Research Insights: Chapman cites studies showing the importance of cognitive breaks and varied work environments to foster higher productivity and creativity, emphasizing that maintaining mental agility is as crucial as technical expertise.

- Practical Takeaways: He encourages developers to evaluate their environments and approaches to problem-solving, suggesting they stop overcommitting, understand their mental states, and allow breaks to foster organic idea development.

In conclusion, Chapman asserts that developers are indeed professional thinkers and must prioritize thoughtful consideration over hasty coding to enhance effectiveness and innovation in software development.

00:00:20.600 Okay, so, I'm not a cognitive scientist, so I'm working in kind of unfamiliar territory here. But even if I don't know anything about what I'm about to say, I have to share the stage with Ward, so I'm already in good shape. The right side of my brain helps me make things rhyme, the left side keeps it all in time, and what's in between helps me learn and perceive. I believe I have the answers I need. Ours is a culture of logic and reason, but do the ones and zeros truly have meaning? Does your software have feelings? Stay tuned; you may find this revealing.

00:00:37.800 "Work harder," they said. "You can rest when you're dead." What is the opportunity cost of this lack of mental floss? So many questions and no time for thought. Maybe you should sleep on it. Let rapid eye movements give way to improvements as solutions are reduced to abstract illusions, fast asleep and hard at work, generating painless solutions.

00:00:56.000 So we've chosen our tools. We've lined our minds with patterns of design. Muscle memory translates brain waves to square braces and a faint blue glow on end users' faces. But blue glows become blue screens, sad Macs, bombs, and disasters. Did we fail to think or fail to see, or were we just told to work faster? Five times we ask why when things went awry. Why? Because the computer does what you tell it to. Why? Because the analysis was done by fools. Why? This solution doesn't follow the rules. Why? Well, we missed an opportunity for code reuse. Why? Maybe the end user was just confused.

00:01:40.560 Relax; your mind is hard at work maintaining focus. A puzzle piece is placed precisely with you unaware of its locus. But the joke is, a computer walks into a bar—or crashes into the surface of Mars—because you told it to think twice, code once, and you'll go far.

00:02:34.490 I consider myself a professional thinker. Currently, my most important role, I think, is as a team mentor. As a team lead, I spend most of my days as a co-pilot.

00:03:01.680 So who is Janie? Well, Janie's at home with my wife watching this presentation. She appears to run on intuition, and trust me, Janie thinks she's an expert in everything. I'm probably going to get a lot of feedback from her when I get home tomorrow. One thing is that experts tend to have a hard time resisting the urge to always work on intuition. In "Pragmatic Thinking and Learning," Andy Hunt talks a lot about the Dreyfus model, which is a model of how individuals acquire skill.

00:03:30.680 It lists certain levels such as novice, advanced beginner, competent, proficient, and expert. What's interesting about this model is they assert that most people never get beyond the advanced beginner state. In this model, novice, advanced beginner, competent; most people are sub-competent at most things. If you couple this with the Dunning-Kruger effect—where inexperienced people tend to think they are better at something than they actually are—you get an interesting situation. Consider that for any given problem, most of the people in this room, for most things, are probably just advanced beginners.

00:04:13.200 For any given problem that you have not yet solved, you're not an expert yet; otherwise, you already would have solved it.

00:04:49.800 There are a couple of reasons I proposed this talk. One is that often, as a founder for many of the projects that I work on, as someone who's written a lot of the original code, I've often thought about many of the solutions that I'm delegating today. I find it hard to delegate when I've got possibly two years of thinking already going into the problem, and now I have to let one of my other developers catch up to this.

00:05:16.800 I notice that this may be something I worked on for an hour two years ago. Why do I all of a sudden have clarity when I haven't actually thought about it?

00:05:42.800 I also find that I get frustrated when working in a capacity as a manager. How many of us have said, "Oh, that'll take me 15 minutes"? You delegate this role, ask somebody else to get some coding done for you, and it takes three or four days. You may remember when you did it recently, and it took you five minutes to do it. It took you three hours to do it, but what you're neglecting is the fact that you probably thought about it for a long time. I have things where I will sit down and completely forget about the four months I spent thinking about a problem and then implement it in two days.

00:06:10.080 And oh yeah, it took me two days, did it not? So who might benefit from this discussion? This is the master gaming race, if anybody's familiar with them. Well, programmers, people other than programmers, our managers, our co-workers. I think that there's a lot of miscommunication about what we do for a living and how we get things done.

00:06:42.520 There's also a small group of programmers that I'd like to call the Freshman. We've probably all worked with the Freshman or we've been the Freshman. An example from an interview we did recently: the code worked great, and I couldn't figure out what was wrong with it. I realized it looked like a Freshman CS 101 project; you can just tell when somebody doesn't think through a problem completely.

00:07:07.800 So we had a perspective new hire, and we give this Ruby code quiz where we give them a test suite, but the test suite doesn't necessarily ask all the questions you need to ask to get that thing done. We really want to see if they think through the problem.

00:07:29.720 Just assuming that, well, we passed all the tests; this must be good software—that's the kind of thing the Freshman might do.

00:08:01.240 Here's some code that the Freshman might write, and what's interesting about this is that it's actually C. I wrote it as a Freshman in the '90s. I had to retrieve it from a floppy. Has anyone here never had to save anything to a floppy? What's interesting about this is it doesn't look like horrible code, but I have this big block of ASCII art. It turned out that the whole project looked like that.

00:08:29.520 I probably spent more time writing these ridiculous interfaces than I did actually making the code work. It was like a bug light for my professor—pay no attention to the code over here, but look at this. I think one of the deficiencies that the Freshman has is they have not yet really learned to think through a problem. They don't see what's important.

00:08:51.760 Here's another programmer type that might benefit from this: Mrs. Roberts. Mrs. Roberts often patches a problem because they think the bigger issue is too complex or potentially unsolvable. This approach tends to create Gremlins in the codebase.

00:09:01.440 These developers look productive to management because they're always working, and they're always solving problems. But nobody really realizes that they're always solving the same problem.

00:09:29.720 Here's some code that this individual might write. It looks like they had some method missing errors, and they just decided to sweep them under the rug. The Bob Ross fan—I love Bob Ross. I used to fashion my entire development style after Bob Ross. You just keep throwing code at the page, and eventually, you end up with something that works.

00:09:52.880 No one else really knows what they're up to, and they just keep throwing layers of code at the page. It's difficult for anybody else to see the big picture, and here's some code that Bob Ross might write. There are all these happy little methods, and what's interesting here is it's hard to find example of this style of code because the end result is often deceptive. It has some weird bugs in it because of all the layers. In this case, there are some silly stuff going on here.

00:10:34.320 But the most telling thing would probably be to sit behind them for about an hour and then press control or command Z and undo all of the changes and just watch all the code go back and forth. Their deficiency is that they don't spend too much time thinking about their solution as much as they just chase their intuitive vision.

00:10:59.720 This guy I talk about all the time is the developer mercenary. They somehow shut their brain off at 5:00 p.m. They don't really care about what language they're using; whatever pays well really works for them.

00:11:22.960 And here's some code that the mercenary might write. You probably can't see that, but what's interesting is that it sort of resembles Ruby but mostly looks like PHP or Java. The thing about the mercenary is they care more about doing the job than using the right tool or really learning the tools they're using.

00:11:50.560 The mercenary might actually list Ruby expert on their resume and still write code that looks like this. And finally, this is dangerous territory for me as a development manager because sometimes I might fall into this mode, but the pointy-haired boss doesn't always understand what you're doing.

00:12:21.500 If he's like me and has lots of experience, he might think, "Why can't you get that done faster?" because he's neglecting all the thinking that went into it when he did it the first time. The pointy-haired boss also thinks he knows what working looks like.

00:12:58.600 They want to quantify what you do. The last code the pointy-haired boss wrote.

00:13:22.160 Their deficiency is that they often focus on irrelevant metrics, and they don't really know that we think for a living. It's hard to put a dollar value on your thoughts.

00:13:46.600 So let's get to the point already: we're professional thinkers. I don't think that's a stretch, and thinking happens everywhere. It follows us home, it invades us in the shower, it interrupts us in conversations, and it comes to dinner, much to the chagrin of our significant others. Thinking is really what we are getting paid to do, and personally, I think coding is the easy part.

00:14:27.040 We spend a lot of time honing our craft. We learn new programming languages, we discuss esoteric points of frameworks, and we do code katas. But are we spending enough time keeping all the right tools sharp? Are we keeping our minds healthy?

00:15:07.760 Also, the best place for thinking is not necessarily the best place for coding, and I kind of want to get into that too. Have you ever tried to code in the shower? I do a lot of really good thinking there, but I'm not bringing my MacBook in there.

00:15:34.960 So are we providing ourselves with the best environment for getting the job done? Do our employers or our clients understand this? I think it might be a little clearer now that I'm not talking about waterfall. This has nothing to do with agile or waterfall development or big upfront design.

00:16:04.200 My team, I actually think, is a pretty good agile team. I don't even know what agile means, but I think my team is pretty good at the important parts of it, and that's what matters. This is more about giving ourselves time to think, doing our thinking at the right time, understanding that unconscious thought has value, and factoring it into our plans and specifications.

00:16:46.240 The end result of both active and passive thought is not necessarily going to be some kind of waterfall solution.

00:17:25.680 So how do I get you to agree with me? You know, I totally forgot to put a sombrero on this. I think there's plenty of kind of odd precedent in the industry that we're thinkers. You think about architecture roles for our best thinkers.

00:17:53.080 We're starting to realize that you get to a point where you just can't push everybody into management just because they're in my case 35. Companies are realizing this. Think about TDD style; this is a great example. You can think of TDD as thought-driven development, right? You're focusing on solutions and outcomes and kind of directing the development before you actually write your system code.

00:18:27.520 This one's kind of evil, but employment agreements; I don't know if anyone's ever signed one. I personally haven't, but there are employment agreements that are pretty pervasive in some areas of the industry where employers actually say they own—you have to sign over—that they own any code you've written at any time, day or night, it doesn't matter.

00:19:02.080 What they're really saying is that we are paying for your thoughts— all of your thoughts—whenever they occur, as soon as they manifest as code on the page, we own them.

00:19:39.320 So, I'm a programmer, right? So, I'm really good at getting up and talking about what I think, or at least what I think I think. Let's assume that I've won you over. Let's assume that you believe me and we're thinkers, and that's what we need to focus on. Let's see what other thinkers have to say about this.

00:20:15.120 This is Poincaré, who was a pretty decent mathematician. The Poincaré conjecture was one of the Millennium prizes. He was thinking about some pretty difficult stuff, and it's often written that Poincaré would work from 10 to 12 in the late morning and then work again from 5 to 7 in the evening, never working more than 4 hours a day.

00:20:56.440 He said that he found it just wasn't useful to work any more than that; he couldn't do the type of thinking he had to do and continue these long work days.

00:21:26.560 U, that's anecdotal at best, but recent research from Florida State University studied people who excel in their fields—mathematicians, musicians, elite chess players, actors. It found that generally, the people who tended to excel, the elites, had different patterns of work.

00:21:41.520 It seemed like they worked in 90-minute bursts at a time with nice long breaks, rarely working more than four and a half hours a day. This is interesting because it has ramifications for how we work in the office.

00:22:05.920 If this research asserts that every 90 minutes we hit a point where we experience mental fatigue and really need to reboot, what does reboot mean? It means having a conversation, doing something else other than intense thought or intense focus.

00:22:57.760 Our co-workers may not understand why we have our Nerf guns in the office at the ready or why we occasionally fly a small blimp around the office, because we need to take a break every 90 minutes. We also know that, under some circumstances, there's research that shows conscious thought deteriorates in quality over long periods.

00:23:34.080 So I want to kind of get to my first question: are you working too much?

00:24:15.520 So four and a half hours a day doesn't really seem like much time to get any work done, does it? Not with our lives, right? There's been a great deal of research in unconscious cognition, and I'm sure we've all experienced this: have you ever fallen asleep trying to figure out who that actor on Doctor Who was, and then you wake up the next morning and go, "Oh yeah, I remember their name"? It's because your brain was working on the problem when you were asleep.

00:24:47.480 There was a study about this—using apartments, they took listings of apartments, and one was significantly better than the rest. But it was subtle; it wasn't in ways that would jump out at you. The subjects were asked to either choose immediately which was the best apartment or choose after some period of goofing off. It turns out that the subjects who chose after goofing off chose the right apartment almost twice as much as those that guessed right away.

00:25:27.520 This is interesting because it tells us your brain was working on the problem even though you were engaged in other activities. You know how do you explain that to your other co-workers or to your clients? How do you even bill for that if you're a consultant?

00:25:59.280 So my next question is: we're always working on some problems, whether we like it or not.

00:26:26.640 There's another study with subjects who were asked to recall a list of words. The subjects who were asked to recall after eight hours of waking relaxation did significantly worse than the subjects asked to recall after eight hours of sleep. So, wait: here's our new question—does that mean even when we're asleep, we are still working and possibly harder on some problems?

00:26:49.360 So we're talking about thinking and how your brain's working when you're not actively engaged in something. What about when you're actually getting things done? Other research implies that there is a divide between the thinking mindset and the doing mindset, and that you can really only be in one state at a time. Furthermore, some individuals spend more time in one state than the other.

00:27:29.600 If this is true, maybe we shouldn't try to fight our current state and instead choose our tasks that fit whatever our mental mode is right now. A question here would be: how do we optimize our mental state for the task at hand? Pair programming, for example, where one is maybe the doer and one is the thinker—things like that; how do we integrate this into an environment and allocate our teams based on the state of mind they're currently in.

00:28:05.440 So what about when we're actively working? Many of you have probably heard of Miller's Law. It says we can put seven things plus or minus two in working memory at any given time, but programmers routinely solve problems with hundreds or even thousands of variables. So the question here is, if we can only have a finite working memory space, how can we possibly keep track of hundreds or thousands of variables?

00:28:42.800 What we're really talking about is problem-solving. Problem-solving could be thought of as a feedback loop of think, learn, and then apply.

00:29:19.280 Learning is a pretty important part of thinking in what we do. Since we're problem solvers, I started this assertion that for any given unsolved problem, you're unlikely to be an expert in that problem. If that's true, you need to realize that you need to learn something before you can get to the solution you're looking for.

00:29:48.960 Considering that learning is a key part of problem-solving, what can we do to provide ourselves with a good learning environment?

00:30:25.520 Several studies assert that activating more of the brain while engaged in an activity increases mental productivity. Even if the extra activity is something like drumming on a desk or thumping your foot, it shows that it actually helps.

00:30:56.400 Music is an excellent multisensory stimulant, and research shows that surgeons perform better when listening to music they enjoy. A friend of mine is involved in a program called Fresh Prep, where he wrote a bunch of hip-hop style lyrics to global studies classes.

00:31:24.720 They took a selection of students who had failed the Global Studies Regents exam five or more times. They gave them a 12-day course where they learned global studies through hip-hop, and 79% of them passed, including 100% of those with special needs.

00:31:58.480 In "Pragmatic Thinking and Learning," Andy Hunt talks about a situation with a team struggling to speck out a system. They literally acted the system out; everyone picked a role and said, "Oh, you're this object, you're this object," and they were running across the hallway.

00:32:31.360 What can we do to augment our approach to problem-solving?

00:32:58.480 There's a wild card here—neurogenesis is the ability to regrow brain cells. We always think that as we age, our brains decline and we don't regrow cells. But recent studies with lab mice have shown that it's not age-related.

00:33:29.280 These studies showed that the environment the mice were in matters. Mice in active, enriching environments were actually able to grow brain cells and regenerate them, leading to healthier minds as they aged.

00:33:57.440 The question here is: does constant exposure to dull, repetitive environments sound anything like your workplace?

00:34:29.120 I'm sorry Mario, the answers are in another castle. I don't have any answers for you; all I have is a bunch of questions. And that's kind of the point, right? We're talking about thinking, but I have a few points that could help you along the way.

00:35:00.000 There's a technique called "the five whys". When you have a question or a problem you're trying to solve, research shows that if you ask yourself "why" and give iterative answers, usually about five iterations is enough to get to the bottom of the problem.

00:35:27.360 In this case, I noticed that I often stop too soon, or I guess it would say Mrs. Roberts from Bobby Tables' example often stops too soon. Also, returning to the Poincaré example, his four hours of work were probably four hours of fairly intense thought.

00:35:59.520 If we're in a working mode, it doesn't mean we're ready to code. So try to be aware of your current mental modes, and assign your tasks appropriately. I personally know that I'm much better at coding from 8 until midnight than I am at 9:00 in the morning.

00:36:30.160 So in my capacity as a manager, 9 to 5 kind of works because I'm thinking, I'm pair programming, I'm co-piloting, I'm doing more of the thought work. But when I was a programmer—well, I'm still a programmer—but when I was always coding, it was frustrating if I had to go into an office all day because I wanted to work at night.

00:37:03.000 My belief is that it had to settle down a bit. I had to be ready to stop thinking before I could actually code.

00:37:37.520 Stop taking on too much. This one should be obvious, right? Just because you can finish one project in one month does not mean you can finish six projects concurrently in six months.

00:38:00.520 Recognize environmental constructs. If mental health has a lot to do with the environment you're in, we may need to take better consideration of the environments we're working in.

00:38:29.680 Also, 'sleep on it.' This doesn't mean taking a nap; it means taking a walk, talking about the last episode of Eureka, staring at the window blankly, doing something that is not active coding—do it all the time. Give your brain a chance to catch up to your code.

00:39:00.680 So we have a lot of decisions to make every day, like which restroom to use. I think you'll see that a little careful analysis can go a long way.

00:39:27.440 These are some of the books I used for this talk. Actually, they're all pretty good. Eric Evans is a friend of mine, and he did a great talk at RubyConf a few years back called Effective and Creative Coding.

00:40:07.680 Most of all, my images were from Wikipedia Commons and XKCD. I don't have any answers, which means you probably shouldn't ask me any questions. I have time for a couple of questions if anybody has any.

00:40:41.760 Alright, thank you.

MountainWest RubyConf 2013