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.
