The Rogues discuss rhetoric with Joseph Wilk.

Special Guest: Joseph Wilk.

 
JOSEPH:

Arguing with an Engineer is like wrestling with a pig in mud. After a while, you realize the pig is enjoying it.

Hello everybody, and welcome to Ruby Rogues. This is Episode 102. And I will be your host today. I'm James Edward Gray II. With me today are, Katrina Owen.

Hello.

David Brady.

Hello and welcome!

Avid Grimm.

Hello, hello!

And today, we have a special guest, Joseph Wilk. Joseph, since this is your first time on here, why don’t you introduce your self?

Yeah. Hi, as you said, my name is Joseph Wilk. I've been messing around with Ruby the last ten years or so. And I've been doing a lot of work and looking into Rhetoric and how that helps us in development.

So, I guess we’ll start with the super obvious question. Rhetoric is a new programming language that we’re all going to be using soon? [Laughter]

I thought it was a gem. [Crosstalk]

It’s a new programming language.

It’s actually the hedoric gem so that you can do ruby-r herotic so that it’s -rhetoric.

It’s this crazy programming language called English.

Uh-oh! This episode just got complicated. [Laughter]

Yeah.

Your talk is excellent. And we will definitely put a link to it in the show notes. And that’s what made us want to talk to you. Can you give us like the rough outline? What did you talk about and why?

Sure. I guess the motivation was that something’s kind of been lurking in my head about companies I’ve worked in and just seeing how people interact and I haven’t been able to really kind of connect it. I started doing some research into Rhetoric and reading around that sort of stuff. And it all started to kind of connect how I think Rhetoric plays an important part in writing code and discussing code, and trying to decide about which ideas to apply. And in fact, the key part of development is communication and talking about ideas, and deciding what to do. And this is, to me, like a huge kind of take on a Rhetoric which unfortunately, has kind of died as a thing because I don’t think many people are taught Rhetoric anymore. So, it’s kind of a danger sometimes, it being used against you or you're not really being able to utilize it for your self. My goal is to make help developers communicate better, I guess.

So, where does Rhetoric come from? What's the history? Like, who made it up?

Yeah. So, the Greek’s are the Fathers of Rhetoric, I guess. They simply sat around all day, and did a lot of talking and philosophy. Through this, they started to kind of come up with these ideas about, I guess, discussion, a lot of discussion in Greek society. From this, they started to write theory. Socrates wrote theory about how to have a discussion. And what’s interesting, it was generic enough so that can be applied throughout the ages. The initial book that was written on rhetoric by the Greek’s is actually kind of very much still applicable to lots of different fields and lots of people have added onto this and added additional theory to it. It’s actually a couple of very simple ideas mixed in some Greek names.

So, is it true that the Amphora was invented just so that these guys standing around talking would have a water cooler to stand around talking? [Laughter]

Yeah, the water cooler’s a good analogy and definitely -- I think it’s kind of weird but I always reference this that the Greeks always used to read out loud, not in their heads. And this is because they valued -- that they were scared if they didn’t speak, they would lose their ability to argue in discourse and it was that important to them. It was like one of the ideals.

So, everybody thinks Socrates is smart but he totally moves his lips when he reads?

[Chuckles] Yes, exactly. He reads out loud, he can't do it in his head. And he’s probably a better communicator than any of us will ever be.

So, I keep throwing Rhetoric at my computer but it doesn’t seem to be improving my code.

Ah…that’s…yeah.

No, I guess what I mean is, seriously, why is this so important to us as programmers?

Right. So, when you write, there’s different levels to this but when you write code as we kind of know, code is actually more read than written. So, what does it mean for someone to read your code? What does it mean for someone to read your tests? To me, there is an aspect of not just expressing a solution to a problem but explaining, making a code readable, making it possible for someone to understand not just the solution, but why you’ve chosen that solution. So, when someone comes to that code, you’re almost persuading them that this code is a good way to solve this problem at this time. So, I think that’s actually like really just a low level thing to writing code that can be persuasive I think is actually just a core property of being a good developer. Going less kind of into code level, obviously, communication is a massive aspect of development. I don’t know any developers who don’t speak to any other developers in their entire day. Even if remotely, people are talking, people are pairing, there’s a lot of communication back and forth. The thing I love about pairing is that it often brings about discourse, and to me, again, an aspect of persuasion. We often have discussions around like, “Is that a good abstraction?” “No, that’s not very good. We should do it like this.” “Oh, I hadn’t thought about that.” You have a back and forth which is ultimately one person trying to dissuade the other about a different way of approaching the problem. And then, that’s not even going into the level of like, we build for the real world and the real world often will have lots of people like customers, and Project Managers, and all these various people. And the only way we get things done is by taking to them and discussing about the things we should build and how we should build them. So, it’s communication.

You’ve used the word ‘persuasion’ a couple of times. How is persuasion different from winning, I

guess?

Winning is definitely the wrong frame of mind because that implies that when you go into a discussion, you won’t lose and you’re willing to do anything to win. So, I think there’s one aspect of persuasion, you’re trying to persuade someone’s idea but it doesn’t imply that you’re closed mind to alternatives, while winning kind of implies that you don’t really care about the going back and forth and actually accepting you’re wrong. So, I think persuasion is slightly softer but it is definitely in some ways akin to people will see it as, “I want to win.” I guess, there’s a higher level of realizing why you’re doing things and the environment that you’re working in because if you go in with the attitude to win, it’s going to produce a pretty uncomfortable environment for everyone else and won’t give people who are kind of maybe junior a chance to really feel like they’re engaged in the process.

So, by persuasion, do you then mean, in terms of code, this concept of persuasive code has just made this the most interesting episode of the year. And if you look at our episode’s list, that’s a statement where we’ve had a fantastic run this year. Can you give me an idea of what it means to write persuasive code or to persuade? Is it just persuading them that your naming an architecture is correct? Or is it more to do with having code that can communicate its intent well or is it something entirely different?

I think intent is a large part. I think tests provide contexts so people can understand the context with which you made the decisions about how you wrote the code. Because obviously, the most challenging aspect in writing persuasive code is that the context when someone comes to it has changed. So, understanding kind of the context you are operating in, I think, is done though examples which are tests. I think like good naming conventions, those sorts of things are really great at explaining why you’re doing something. I guess there’s also the accessibility. If something is contained in huge layers of abstraction, it’s very hard for someone to get a cohesive view of why you did something. So there’s, I guess, arguments against complexity there. There’s also something I kind of got inspired by for this. I think it was Alistair Cockburn who defined this thing called the Rhetorical Programming Language. And he actually wanted to create a new programming language where we get to capture all the emotions and feelings that go into when we write a bit of code. His argument was…

Then, that would be a bad idea for me. [Laughter]

Yeah. I'm not sure it’s a good idea but it’s an interesting idea that’s, when I wrote a piece of code, how much of that when I'm writing that method does the person realize I was screaming, and going like, “This is horrible, I hate this infrastructure! I really don’t want to do it like this!” Because I’ve seen enough codes to see where people have written methods called like, “Oh my God, I don’t want to do this. I hate this but I have to do it anyway.”

And so, it does bleed through but I think that’s an interesting thing. I don’t know the answer to that or how important it is to capture those emotions. But I do feel that that’s something that goes missed when you try to be persuasive about some piece of code.

You have a part in your talk that I really liked where you said [inaudible] meeting or something or discussing some big change and everybody’s arguing for their way that we should do it. And who wins? And it was interesting you said it may just be the loudest or most passionate person. It may not have anything to do with who has the better idea. That’s a little scary.

Yes, very, very scary. It’s that, I think someone gave a quote, something like, “It’s not actually the idea that matters, it’s the words that are used to express that idea. And having the idea is only one part of it.” That exact thing, this was the thing I was kind of saying that was boiling away in my mind that I've seen again and again where it’s really depressing just kind of like to have a meeting and just feel like you have all these smart people in the room and you’ve spoken to them, they have great ideas and you end up doing something that half the room thinks is completely a bad idea but it’s kind of that loud voice. And that kind of, I guess, was one of the things that inspired me to start kind of talking about it, because I really wanted to see what I can do in the kind of companies that I worked in and where I was working to just empower and help. See if I could just help those people who had great ideas but didn’t feel very confident and weren’t getting very good at expressing them.

It’s interesting when you look at personalities like DHH or Ryan Davis. These are very confident people who are very certain of their ideas.

Yeah.

And I’ll have a pick related for that. Rather than getting into another one of Uncle Dave’s interminable stories, I’ll have a pick related to that at the end of the show.

I read a blog post a few years ago, I think by Kathy Sierra called something like ‘When the glib win, we all lose’. And it wasn’t necessarily about confidence but about the choice of words. Sometimes, people are onto something but are unable to articulate it. And they might sound clueless but they're not. And then, other people have all the right words, all the buzz words and it seems like they have this logical progression of thought in a very like forceful, not necessarily in their confidence and in their presentation, but it all sounds so good but might not really be so smart. And that’s stuck with me.

Yeah. Something I’ve wondered about that is like how much in our work do we get to practice speaking and expressing ideas. I’ve been spending the last three or four months writing nothing but Clojure which is like a Lisp language. And I’ve actually found my communication skills and my ability to express my ideas deteriorate…

Because it’s less literal. It doesn’t read very effectively and it’s in prefix notation. It’s actually made my communication skills worse. And that, I find interesting that the language that we use to write in might actually -- is kind of our main practice at communicating. And that affects the way we communicate when we talk about ideas.

That is astonishing!

That is really interesting. I just got done watching Josh Susser picked it awhile back that this Guy Steele talk from OOPSLA.

I just watched that!

Yeah. And it’s this amazing talk about -- I don’t want to spoil it but it’s about how we build languages. And it’s very interesting. It’s about how you take the language and you change the language into basically, the language of your problem and then you solve the problem. And it’s kind of, I think, what you're talking to, Ruby really lends itself to that, the way that we can manipulate Ruby to make it look like our problem and then solve the problem in its own terms. And that is a powerful form of communication.

I hate to dig against the language, especially Clojure, because it’s next up on my list of languages to learn. I think I can't take credit for this idea. I think it was Giles Bowkett who said this originally. But he referred to Lisp as an ‘Autistic Language’. And now, I'm using autistic as a value-neutral term here. I'm not saying it’s retarded or whatever. I'm sorry for using the ‘R’ word if that’s offensive. But autism is a brain organization structure in which it is very difficult to communicate your internal state to those around you. And Lisp, very much so, is often considered an autistic language. It is brilliant, it is beautiful, it is intelligent. And it cannot communicate to the reader. What the heck is it trying to do? It is very hard for people to understand it unless they immerse themselves in it and completely enter its state.

It’s kind of ironic because the one thing that Lispers, including Guy Steele, have been talking about since forever is the idea of building up the language to address the problem at hand.

Yeah.

It’s interesting just what you say about sort of losing your ability to speak about problems as a result of the programming language you're using. And that kind of relates right back to the Greeks and their reading aloud. Something that I've always found and I don’t know whether I'm in a minority on this or not, is I cannot learn a programming language effectively until I know how to speak a line of code in it. And this is actually one reason that I've always had a very difficult time with Mathematics, proper Mathematics, is not having a decent background in it. Not having actually taken a lot of Math classes, I never knew how to say any of the symbols that were used. So like, I would see -- it was like ‘E’ and then ‘E’ with a little tick mark next to it. And it couldn’t say that in my head. And so, I just could not comprehend what that meant and it’s so hard to look at stuff up. And eventually, somehow, I managed to find out that that little tick mark is usually called Prime. And you say that ‘E Prime’. And then, I could reason about what I was seeing.

This is really interesting. It’s the same thing when I'm pairing, like I find myself tongue-tied often when I'm trying to pair with something because I'm not sure how to express ‘seven of the array of foods’. It’s really hard to some…

One of the first things that I have to do in my pairing sessions is establish some language. I don’t like do this upfront but I do it as soon as I run into the need for it. And there are certain constructs that I have heard from other people but that I try to establish so people know what I'm saying so I can say these things fluently. Like, if somebody is dereferencing an array or really any kind of -- a hash, anything where you use the square brackets, I'm going to say foo subscript 7.

Interesting. I call that ‘index into’.

But how do you fit -- so, that seems like that goes backwards from the order of the tokens that you're seeing.

Yeah, you're right. You're right.

And that really throws me off when I have to say it differently than the order of the tokens especially if I'm trying to tell somebody how to write something.

So Avdi, you’ve just confessed that you move your lips when you read code.

Yeah, basically. That’s exactly what I'm doing. Sometimes, I’ll abbreviate that to like ‘foo sub seven’.

That’s what I do. I use ‘sub’.

Yeah. And I communicate that to people and then, they get it and then we can move on. And there are probably a few other things that we could talk about. There might be interesting to have a whole episode just talking about how we talk about code. But I cannot reason about the stuff until I

know how to speak a line of the code.

I find with anything billion, I can never ever understand it without reading it out loud. It makes no sense to my brain whenever I see some billion conditions, I have to read it.

That’s interesting. So, I'm an extremely visually-oriented person like some people internally represent the world kinesthetically like these feelings or sensations, other people represent them auditorily, and some people visually. I actually represent the world as moving picture. I meant like movies. And so, for me when I read code, it is really, really critical that the layout of the code communicate to me the intent of the code. And this is actually why I left Python because the enforced whitespace meant that if you had small idea that was actually a little bit complicated, you could not make it small on the page. If you had to do five steps, you needed five lines of code to do it. Even though it was really one operation, okay yeah, you could wrap it up into a method call and call that then, you’d have one line. But you see the problem, right? It’s that the language couldn’t shrink the way I needed it to visually. And that is really, really interesting.

Something that I’ve been looking and writing about a little bit is, I’ve kind of vary into the literate programming, like a code reading. But then, looking at something like Clojure and where Clojure values density of expression. And I always thought this was a bad thing but somebody gave me the example of how in Mathematics, we have an incredibly dense symbolic language which we think in. And there’s this idea that some people would say, I’m not sure if I’m sold yet, but with something like Clojure where you have very dense expressions, you start to think in the syntax and form your constructs and your thoughts around the syntax which requires a lot of immersion and requires you to be fluent in the language. But it’s possible you could have thoughts, thinking in Clojure that you might not have if you were to think them high level in English which is kind of crazy.

Doesn’t that recur back into Rhetoric almost like a fundamental level, like a fundamental disconnect of axia? Like in Python, there shall not be magic. It takes you five different steps to do this thing. It should take you five lines of code. That’s the Python way of thinking. I disagree with it, I fought, I lost, I went to Ruby. The Clojure values this extremely high density. In Ruby, we see a lot of people that are like say things what they are, name things for what they are. And so, yeah, you would take those five lines of code and you either string them out together in one very long line of code which visually tells people, “Hey, this is complicated. It’s only one line of code, but it’s five separate steps and it’s very complicated.” You can skim over it because it’s only one line. But if you're going to look at it, you’ve got to stop and really think or you extract it to a method. I mean, these are explicit. These are proper Ruby idioms that you should use when you're programming in Ruby. And in Clojure, there's no value for that. Just use the expressions, just convince it down. And in Python, it’s the other way. You must expand it out. Is that a difference in fundamental, is it axia or axioms? And just say I was wrong whether the word is right or not.

Say it again. Sorry, I didn’t understand the question? [Laughter]

Is there a fundamental disconnect? Let me simplify the question. Is there a fundamental disconnect in the way Python people think where explicit is always better and the way Clojure people think where very dense, possibly implicit expressions are valued to achieve high symbolic density that will then result in languages that can't really -- they're going to fight with each other, no matter what, because their fundamental axioms are different.

Yeah. I guess it comes down to everyone’s brain works slightly differently. And some people, I guess, find different ways of expressing things more natural. So ultimately, the language creator dictates how they think everyone else should think. And people align themselves to what fits naturally for them or sometimes, forcing themselves to discover some new way of expressing themselves. I don’t think any way is necessarily better or worse. I think everyone can benefit from trying all of those languages and just understanding how that might fit to the way they think about ideas because like you said, I’ve done Python, I’ve done Ruby and I’ve done all these languages and have thoughts in Clojure that I’m like, “Oh, that’s a Ruby thing I would quite like to do here.” Like I think learning all of those languages is ultimately the best way to discover which one fits in your head and to try and take some analogies from some into others.

I may also explain a little bit why some languages seem to fit into certain issues like Ruby, obviously, web programming and stuff like that, whereas a lot of times, the functional languages, Erlang and such are often used for server code or things like that. It may be just because the app language makes it easier to express those ideas. I'm not saying I know that for sure, but it’s possible.

Yeah, definitely. If you focus on something that deals massively with concurrency, Clojure becomes very natural to express those ideas and concurrency can often cost readability. So, there are some compromises there, I guess.

So, I want to take this in a slightly different direction for a bit. You had another part I really liked when I was watching your talk and that was, you talked about how when someone comes at you with an argument or some form of persuasion, they're actually speaking from a lot of different places. Can you tell us more about that?

Yeah. It’s been awhile since I did that talk so, I may not reference directly to the presentation. But when someone comes to you with an idea, there’s, I guess, a lot of layers in how they’ve come to that idea, how they express that idea. It’s hard sometimes to not get caught up in the emotion aspect of having an idea. Having an idea is very exciting. And I think everyone has kind of burst out and said like, “Oh, that’s an amazing idea!” And you say it out loud and then, you kind of embarrassingly look at yourself and realize that actually that what you just said was complete rubbish. In terms of expressing an idea, there’s lots of different ways. I guess, people find more comfortable to explain an idea or how they go about talking about it. That can be cultural, different cultures may have different ways of expressing it. Some cultures might be more forthright, some might be more reserved. And I guess, there’s lots of different layers that come to someone just presenting an idea to themselves that’s going on not just consciously but subconsciously as well which is the really hard part. We can’t actually control what we’re actually doing.

Yeah. I find that a little troubling too because then you start thinking, “Well, did I go for this idea because it was a great idea or did I go for this idea just because that person was really passionate. And they sold me on their passion, not their idea.”

That’s the thing is that emotions always beat words. If you get caught up in emotion, it’s actually shown scientifically that emotion overpowers aspects of the brain that suppress logical thinking. So, if you get very emotional about something, you really may not think it through very logically which scares me massively but it’s also the acceptance. I don’t know. I think we have this idealistic view that we’re intellectual beings that are purely based on reason and logic when there’s a lot of layers going on that I think the best you can do is at least try and understand the various layers so you’re aware of the emotional aspects such that you might come back later and think, “Okay. I’m just going to look through this again.” Or, “Let’s discuss this.” This is something that really bugs me is that often decisions are made at a single point in time, you have a meeting, you have a discussion, a decision is made. So, you’re much more likely to get punished by getting caught up in emotions or someone’s rhetoric. While if you have a discussion and come back to it in two or three days with like, “Okay, let’s come to a conclusion,” you’ve removed a large part of that emotional thing and enabled people just to process in their own time, in their own thoughts, some of those ideas.

Are you familiar with the book, ‘Thank You for Arguing’?

Yes.

Okay. So, you're also familiar then with the difference between forensic debate, ethical debate, and deliberative debate.

Yes. I mainly know those by the tenses, but yes.

Yes, yes. So, to rephrase what you just said, if we’re in a conversation where we are trying to deliberate and choose something, a direction that we should go in the future, slipping into present tense and getting tribal and emotional and saying, “Not in my backyard,” it poisons the conversation, right?

Yeah. I was an absolutely awful arguer. I was a totally stubborn and it never occurred to me that I always got stuck in the past of like ranting about all the past events.

Yeah.

And this beautiful idea as you’re kind of saying is like actually changing the tense, changes the outcome of the discussion. And just that very little powerful idea of rather than getting too caught up in the past about what went wrong, rather than, what did we do wrong? It’s like, well, how next time could we do better, is a much more productive path for a conversation to go down. And if you look at most rants, it’s all about the past and very rarely about the future.

Or if you look at politics and drama, it’s all present tense.

Yes, all present tense and very caught up in the moment and hence, emotion is much stronger. Yeah, that’s unfortunately where rhetoric has a very bad name from the horrific use of it by politicians and such.

Katrina and James, do you want to call us out? Are we speaking a secret language here? Or is that something that people will be able to follow along, what we just said?

I actually was going to ask if you could go through each tense, give it a name. Say, like how it’s used and what the consequences are.

Joe, do you want to do that one?

Sure, okay. I tend to just use, like past, present, and future. So, the past would be a coding example of -- let’s use a coding example, let’s use a real example. So, talking about the past would be, we were having a discussion about how slow our tests were. And everything was focused in, “Oh, we shouldn’t have done that. It was so wrong.” And, “Why did we do that? Why did we make that decision?” And we got very much caught up in a cycle of what I guess is blame. You’re looking to kind of punish someone or…

So, blame is in the present tense, right? [Crosstalk]

Blame is in the past. [Crosstalk]

You're right. Forensic has determined when why something happened. Yes.

And it’s discussions of values which are about the present. So, the present, it doesn’t usually indicate an outcome of such, it’s usually about discussing the immediate moment. Again, let’s think of the good example. [Crosstalk]

It’s ethical, tribal. Anything you hear that’s political speech is ethical. Anything or pretty much, anytime somebody gets angry when talking about say, diversity, is ethical debate. The point of ethical debate is to identify tribes and say, “We are minitests. We value small, simple, and short.” Or, “We are cucumber. We value a robust DSL that can do everything we need.”

Yeah. And the problem is these often end to like binary like, you’re either with me or against me, which is why that can be dangerous as well. Like I believe in testing all the time, if you say ‘no’, you'll be separate. There’s no compromise, no way of actually coming to some joint conclusion which nicely brings us onto the choice in the future. So, discussing the future tense is where we make decisions. And often in these sorts of discussions, you can get kind of balled down, and caught down, and it’s almost sometimes important just to make a decision rather than debate for too long. So at some point, you have to transition to, what are we going to do next which is often like -- this is where actually, it’s a really great way for things to end up positively where if you were to go away feeling like you can actually do something.

It sounds like whenever I want to quit the Internet, it’s always some debate that has piled into some sort of just horrible morass of, I guess it’s both blaming and sort of the tribal ‘this is who I am, that’s not who you are, so we don’t belong in the same camp’ or something. So, it sounds like by using the future tense, just kind of technically choosing to use the future tense, you might be able to change the spiral.

Yes.

I think this is key when you can’t see each other. And in these examples, you are talking about people who are communicating by typing because you can’t read the emotions that are in people’s texts. If you were sitting in front of someone, you can read so much in their face, you can read so many emotions, you can instinctively know what they’re about to say, like their emotive state which enables you to communicate so much more effectively. When we’re talking about blog post like comments, you lose that context. So, it’s even more important not to get caught up in a spiral and focus on more positive outcomes.

Yeah. There's a beautiful judo move that I think everybody should know. It’s in opening section of the book, ‘Thank You for Arguing’ which Joe, if you don’t pick it, I will, at the end of the episode. [Chuckles] The dad walks into the bathroom and he goes to brush his teeth and there's no toothpaste. And he screamed through the whole house, “Who used all the toothpaste and didn’t put out a new tube?!” And from downstairs, his high school aged son replies, “That’s not the point, Dad! The point is, what are we going to do about it?!” [Laughter]

And he stopped and just started laughing. And he’s like, “I just totally got judoed out of forensic past tense into future deliberative.” And the important thing about deliberative is you cannot fix blame. You can't be there fixing blame. You have to be seeking a solution.

What are you talking about? That kid is so grounded for talking back. [Laughter]

Oh, totally! And at one point, the dad ends the debate by switching to ethical by basically saying, “Because I'm your father and I said so.”

Yeah. Kids with the best education are rhetoric definitely but the best users of emotion because when they’re young, they haven’t fully developed the concept of morals, it’s like, “If you love me Daddy, you’ll do that,” is the classic rhetoric.

That’s awesome. So, what else from your talk should we hit on? What were the other important parts?

Gosh, I’m kind of interested in something that I think was the reason that a large part of Rails was successful and that bombards us with every technical choice we make about the rhetoric of tools that we use and the way they sell themselves to us. I don’t believe there isn’t a single framework that doesn’t use some form of rhetoric to convince you it’s a good idea. If you go and look at the Rails home page, all the words used are all the positive things. It’s like, “Don’t make web development painful.” All this is so rhetoric and I wonder how much of which tactual we use is affected by how convincing something is about persuading us through its website, for the way it talks about it all, for showing us screen casts. Because I definitely feel like my choice to use Rails and Ruby was probably being persuaded by some of the stuff I saw in DHH’s original website. And that was rhetoric being used.

That’s a really good point.

That sometimes always makes me a little bit mad because I know that I'm swayed by really good copy and particularly really good web design on like a project home page. And it kind of makes me mad that I am because as a programmer, I really want to be swayed entirely by technical concerns.

Yeah, definitely. But this is the danger of, if you don’t try to understand and accept the fact that there’s a lot going on in your subconscious and about emotion then you’re actually far more susceptible to it. If you actually understand what’s going on, you might be better at reasoning.

Yeah.

So, I think it’s an important thing to -- I know it’s this horrible thing of, I want us to be intellectual beings based purely on logic. I’d love that. But I recognize that I’m not and I recognize that I get angry and that I get kind of convinced by a website having a really nice layout. It makes me feel slightly more warm emotions towards it all and I think at least understanding those things. In a large part, it’s helped me maybe deal with it better.

Yeah. I mean, I've seen sciences says that will -- explaining the biases to someone will help them avoid them but I've also seen sciences says that but that’s also not completely effective. You still have to correct for it even if you understand the bias like understanding the bias is not a total proof against it.

Completely. I think it’s thinking fast, thinking slow where they have tests where they found out that knowing that you were biased didn’t help you prevent your self from being biased. And that was just the nature of not really understanding your subconscious really.

There are kind of some tools that can help with this a little. One of them [inaudible] recently is the Six Thinking Hats which is from Edward de Bono, I think. And it’s this idea that if we’re all together say, in a meeting and we’re talking about some idea, we can analyze it from these known angles using these different hats. I won't give them all but like the white hat is the data and logic. So, we can look at what does the data say. And the red hat is emotion, intuition, the reaction kind of stuff. So, what do our instincts tell us? Is this a good idea? And then, black hat is the problems with the idea. And the green hat is the creative side. Let’s forget about all the problems and just, say we went with all these idea, what are all the things we could do off of it. So, by controlling the meeting this way, you can narrow help people focus in on just this one area where we’re not trying to use emotion right now or it’s okay that we’re bringing up problems right now because that’s the hat we’re wearing, the black hat which is where we bring up all the problems with the idea and so, by just kind of focusing in. But even in like, I think it’s a tool for meeting/brainstorming kind of thing, but even just in one on one communication, have you seen it a couple of times recently saying something like, “Well, from a white hat point of view, I would think…But from a red hat point of view…” It’s kind of a shorthand to separate out where we talked about earlier how you make your idea, your argument is bundled up with all these different things - your passion, the data you have, your context, basically. And it helps you separate out those various contexts for someone else.

Whereas speaking emotionally, I feel bad about this one. But looking at your data seems good.

Yeah, that’s very interesting. I wonder what happens when people wear different hats. And the main way I’ve used de Bono’s hats is also that everyone is wearing the same hat at the same time. So, when everyone is being critical, it’s okay to be critical because everyone is being critical, people are only allowed to say critical things. So, it would be interesting if you have a situation and you have two people. One is wearing the emotive hat and one is wearing the critical or logical hat, it would be interesting how that might play out.

Exactly. Or even just having them tell you, “This is my opinion while wearing my logical hat.” I feel like that gives me so much information that I didn’t otherwise have. They're saying, “Oh, data pushes them this way.”

Yeah, that’s interesting. I guess, we -- how would you think about always knowing what state you were in, I guess? Would you always know?

I almost never know. Like, I am so confused about how I'm feeling about things. I often feel like I have some idea of what I think the data is, but then, I have all of these like, feelings -- I can't even tell if I'm happy or depressed sometimes. [Chuckles] It’s just so confusing.

That’s right. It’s like our instinct. If you program for a long time, you have instincts that steer your way from things that are generally harmful.

Yeah.

And those just pop up and we have trouble articulating them or explaining why we’re thinking that way. But it’s that instinct we have that protects us a little bit. But of course, it could be wrong.

Yeah, it’s the, someone talks about the phases of learning and the problem with the expertise has reached the sub-conscious level. So, you can’t actually explain sometimes why you’re doing the ideas which came from that experiment they did with the pilots where pilots had to write down for their juniors exactly how to do their job. And all the people just following those instructions did absolutely terribly because there was stuff running in the subconscious of the pilot that they just couldn’t explain or write down.

I believe you're talking about the Dreyfus model of skill acquisition.

Yes, exactly.

Yeah.

Actually, we have one version of that pilot experiment where expert pilots, by writing down all of the steps, were able to improve the output of more junior pilots. But when other experts followed the directions precisely, they did a lot worse than if they hadn’t been following instructions.

This is something that, again, I’m still torn on, we’ve kind of come down to this, I guess, persuasion by authority is the nice term and it’s in rhetoric. But when you’re learning and you’re learning from someone who is more experienced than you, sometimes you need to just do what they tell you to do, to just discover for yourself all the various context and how that works. But the difficult thing is comes that the transition point where you’ve actually got to start questioning and say, “Maybe I know this well enough now that I can not just assume that you’re right.” And actually start to question it. And when you have like a development environment of junior developers, like more experienced developers, there’s a really interesting interplay and when can you just trust that someone knows more than you and you should just do what they say versus always questioning what they say and trying to come up with your own ideas.

I think there's a huge danger with very, very smart people who know very little about something. I

think a lot of people will tend to not trust people. Like, they’ll tend to want to ask all the questions even though they don’t have enough context available to them to even ask the questions or understand the hedges and understand like the reservations that someone might have in the explanation.

There's a great talk -- I will try to find it for the show notes. But the point that he ended up with was he basically stood up and said, “Some smart people should not have opinions about certain things. My opinion on Quantum Physics should not ever matter because I don’t know enough about Quantum Physics to have an authority of opinion on Quantum Physics.” He was arguing a fairly controversial social point and he was using Quantum Physics as his example. But yeah, there's that type of, if I can't reason through it in my head, then it must not be true. And that’s provably false right there because there's other people that are smarter than you at everything. On the other hand, there's this notion of the smartest people in the room are the ones who are always asking questions. And I wonder if there's a distinction there in the type of questions you ask. There's challenging questions like, “Prove this to me.” And then, there's like learning questions like, “Oh, my God! That’s fascinating. Can you tell me how this interplays with that?”

Yeah, that’s interesting especially when you think about presentations at conferences and that often -- and I find this as well, when the time when questions are allowed, I often feel compelled to ask questions just to show that I was paying attention and not actually in any way to, as you said, any of those reasons about learning or anything. Well, I kind of like it, it’s difficult for a presenter. But when people are asking questions throughout the presentation, it’s genuinely because they either want to challenge or they either want to learn. So, kind of there’s something artificial about kind of limiting it all to the very end where suddenly everyone just wants to either show that they were paying attention or kind of refer to something that was in the past.

It’s a really great point and it’s one the reasons why questions at the end are almost always terrible.

Yeah, because you're asking questions from the first three minutes of the talk, right?

Yeah. Or just something that’s so specific, it doesn’t apply to the other 200 people sitting in the room.

Yeah.

Alright. Well, we’ve been at this for a while. Anything else we need to touch on before we get to picks?

Yeah. I want to throw this one back to Joe and -- I'm sorry, is it Joe or Joseph?

Joseph is good.

I'm sorry, Joseph. I've been calling you Joe this whole time. I want to throw this back to Joseph in terms of coding. Out of all that we’ve talked about, rhetoric and persuasion, and certainly we’ve talked about the community and persuading people in the community, do you think there's a place for rhetoric and persuasion in code when literally, the only way in which I can communicate with you is in the source code that I have written in the past that you are now reading in the present?

Yeah. I definitely think rhetoric plays a key part in that. There’s a lot of other aspects. There’s a lot of logic and analysis and domain knowledge and all these things. But often, I see a bit of code and sometimes, code will invoke an emotion in me. Sometimes, I’ll see some beautiful code, I consider beauty to be an emotion and I would be like, “Wow!” That gives me an overwhelming sense of like, I’m happy, emotional input which is going to change the way that I think about that code. Beautiful code is an emotion that is positive and more likely to keep. I always aim to try and produce beautiful code, it’s incredibly hard. I think recognizing rhetoric as a part of writing code helps you just get a little bit more Meta, about being more literal, about writing for others not writing for your self. And I think understanding rhetoric, as you read code, might help you. And when you see a bit of code and you’re like, “God! That’s horrible. I hate that. That’s so horrific,” sort of thing. And it’s like, well what context were they operating in. And again, what we’re talking about, emotions, not let emotions get carried away and various other kind of aspects that overwhelm our subconscious, just knowing at least to get a little bit more meta about it I think is a good step to help you write better code.

Yeah, awesome. Thank you.

Good.

[Inaudible] of method definition is rhetoric. [Laughter]

It absolutely takes a stance, doesn’t it?

[Laughs] It would be a lot funnier had Aaron been on the show and I said that.

I violently disagreed with basically all of the tenets of minitest until two things happened. I went to Mountain West Ruby Conf and I sat next to Ryan Davis and I found out that while he is very -- I don’t want to get dogged down at defining terms. But he’s a very black and white thinker. And usually when I encounter those people, they are often not as smart as they could be. But he is wicked smart. And he was able to back up everything, not just in terms of like very fast hard debate but also in very open, creative interplay of, “Well, but there's this, and this, and this, and this.” And the second thing that happened was I watched the Guy Steele talk on Growing a Language and I realize something that Ryan had not been communicating, to me at least, is minitest is designed to grow. If there's something that’s missing from it, you should grow it. And that definitely is a rhetorical stance. I mean, he’s very strongly opinioned and when you sit down and talk with him, you could really come back and say, “Wow! He’s really thought this through. And he’s actually got a very good solution. Maybe I should explore this and get more fluent with it.” And I did not have that feeling until I met him and watched Guy’s talk simultaneously.

I see it’s a great point. I think any sufficiently complicated architecture has embedded in it people’s opinions about how it should be used. And often, that is telling you the way you should behave with that code.

Oooh, yes!

That’s a really good point. I feel that with things like Resque and Sidekiq where they tell me to define a class and set up some lurker. And obviously, that works in a large majority of the cases with the Rails app that’s why they do it that way. But sometimes, I feel that I don’t want them to tell me how to do it because for example, I'm breaking off some separate service. I won't have that class in the same class symbols places and I would rather just show off something in the key and watch it pop out the other side. And I sometimes feel the [inaudible] of that, they're telling me how I should write this background code and I don’t want them to. In Sidekiq’s defense, they made some changes after my complaining about this very issue.

It totally fixed the golden path idea of Rails, right? Rails tells you how you should write a web app. And if you deviate from the golden path, the way you should build a Rails app, you often think of your self as being wrong when that’s not necessarily the case. To me, that’s what happened over the last year or two, people are actually understanding some of the problems with Rails.

Alright. Shall we do some picks?

Sure.

Alright. David, go for it.

Okay. I had no picks going into this episode. Now, I have four. I'm going to try to move quickly. [Chuckles] The first one is ‘Thank You for Arguing’ by Jay Heinrichs. This is a book about debate and rhetoric. He goes over these forensic ethical deliberative debate past tense, present tense, future tense. He gives specific rules for detecting what tense somebody is using, how to tell when somebody’s cheating in a rhetoric style. If you listen to Talk Radio, they claim to be doing forensic debate but they are always doing ethical debate. They absolutely are deceptive. All political speech claims to be forensive or deliberative but it’s always ethical. Yeah, I have to keep moving. I could go for hours about that. ‘Thank You for Arguing’ by Jay Heinrichs is my first and most important pick. My second pick is ‘Crucial Conversations: Tools for Talking When Stakes are High’. This is a book about when somebody just hits you square between the eyes, sucker punches you with a huge ethical smack while you're trying to do future or past tense. And also, you get this huge adrenalin rush to your brain and your thought center is shut down. This is an entire book for stopping that in your brain, diffusing it, getting oxygen back to your brain and getting the conversation back on track. It’s a way when somebody withdraws from the pool of meaning, or charges into the pool of meaning or charges in with a bulldozer trying to drive you out of it, how to either bring them back by making them feel safe or push them back by gently asserting your own safety. It’s a fantastic book when you need to argue with somebody about something that’s important to you and you know you're going to get emotional. It’s how to keep a clear head. There's a companion volume to it. This is pick number three, ‘Crucial Confrontations’ is the sequel. This is Tools for Resolving Broken Promises, Violated Expectations, and Bad Behavior. This is the follow up to Crucial Conversations and this is the version of the book when you need to drag somebody kicking and screaming into the pool of meaning and they don’t want to go anywhere near it because they wanted just to avoid the conversation entirely. And the last one which is something that I referenced early on in the show is the Bromeliad Trilogy. This is probably one of the most important set of books that I'm going to read to my kids. They are by Terry Pratchett. It’s a fun little fantasy thing about gnomes, little tiny critters that run around and they're tiny. And the reason that I want to read these to my kids is that the moral of this trilogy is that you have to learn to think because only by learning to think can you learn to think even bigger thoughts. And the reason I thought of it is one of the key morals in the first book is the hero gets some advice as the leader is dying and he’s being handed the mantle of leadership. And he’s the skeptic and the doubter. The leader turns to him and he says, “The most important thing you need to know about being a leader is that it’s more important to be certain than right.” And then he winks at him and he says, “Being right also helps.” And the second book is a fantastic argument of feminism and what to do with boneheaded men in a patriarchal society. And these books are for like six-year olds. So, it’s just some fantastic stuff to lay down on your kids. I can't wait to have kids so that I can read these to them. That was kind a lot of it, it was four books. And those were my picks.

Avdi?

Alright. Let me start with just a quick tool pick. The other day, I was digging through some old videos of mine in order to do some stuff with them. And discovered that I had been apparently fiddling with my screen recording settings at one point and I had a video which was 20 minutes long and 75 Gigabytes.

[Laughs] I don’t know what. It must have been set to like the least compression possible or possibly like add more data just because compression level. But fortunately, I had HandBrake installed on my video editing computer. HandBrake is a great transcoding application that turns videos from one format into videos in another format, mostly optimized towards turning them into smaller videos. And it has like presets for various mobile devices. And I fed it into HandBrake and it tore through the 75 Gigs very quickly and turned into a nice like 40 Megabyte MP4 file or something. So, HandBrake is a handy tool to help around if you ever want to transcode videos. For a less technical pick, funny Dave brought up Terry Pratchett. I'm sure I have mentioned my love for Terry Pratchett a few times on this show. And I just want to say if you have Netflix, there are a number of Terry Pratchett movies or series on Netflix. And the interesting thing about these, so these are all English productions as far as I know and they are all kind of straight to TV things. They weren’t things that went to theaters. They're usually done as serials, just like a few episodes like two or three episodes. And usually, straight to TV version of a fantasy novel is code for ‘My eyes are bleeding, this is so horrible. Please make it stop’. And amazingly, amazingly enough, these films have been really, really lovingly done. They're very high quality productions. The acting is all great, a lot of great actors in them. And the effects are startlingly good. As a Terry Pratchett fan, there's really nothing in there that makes me angry because they just got it all wrong. So really, they're kind of the Lord of the Rings movies of direct to video fantasy adaptation. A couple of examples that you could find on Netflix are Going Postal, Hogfather, and The Colour of Magic. I'm not sure if there are any others yet but they're all quite good.

So, I had the actual opposite experience because I read all of them in ‘A Voice in My Head’ and when I watched the movies, they got everything wrong! I would love for a listener who has not read Pratchett to go watch one or two of these and then, come back and say, “Now, I can't wait to read the books.” Or, “Oh my, gosh! I'm never going to read them.”

That sounds like a job for me.

You're up, Katrina. [Laughter]

It’s your turn, go for it.

Christopher Lee is Death.

Which is wonderful.

Yes, he is wonderful.

Katrina, your picks.

I have two today. One is called ‘The Gentle Art of Verbal Self Defense’ written by Suzette Haden Elgin. She’s a Sci-fi author and also wrote a whole series of books. But I think just one would be enough. It seems like every book is the same book over and over again. But ‘The Gentle Art of Verbal Self Defense’ goes through a series of patterns of typical verbal violence and then picks it apart and tells you why -- I guess the bottom line is why you're not supposed to respond to debate but respond to the underlying accusation that is unstated. And it shows you a lot of different patterns of how to do that. And it can be really helpful if you do experience that type of verbal violence on a regular basis. The other pick is an article I came across recently. It’s called ‘Procrastination is Not Laziness’. And this is where in which Katrina has an epiphany. So basically, I realized that I'm neurotic and this explains it. [Laughter]

And it was such a relief. It’s a really well-written article. And the [inaudible] for me was that a neurotic procrastinator perceives error as being a reflection of their character. So anyway, my picks.

Very cool. I've got a couple. We’ve been kind of light on code recently. So, here’s some awesome code heavy blog post, super heavy. First is this awesome one from Aaron Patterson, who’s on again recently, about class eval versus define method. And this is awesome because it’s one of those things I've believed forever and ever and ever. And I was basically wrong. So, if you, like me, thought that Rails uses class eval all over the place because it’s better, it ends up performing better, you're pretty much wrong too. There is a tiny bit of speed burst in one case that goes away as soon as you apply any amount of real work and you pay a whole bunch of penalties for that little speed burst. So, if this kind of thing interests you, it’s a really great read, kind of eye-opening. And then, another article along similar lines came out just a couple of days ago and Josh Susser showed me this one. So, it seems fitting to pick it while he’s not here. This is about MRI’s Method Cache and how it works. And it basically explains how the method cache works and what that means for your code. For example, any time you type ‘OpenStruct.new’, you blew MRI’s entire method cache.

Wow! JAMES: So, it’s very fascinating, interesting read. And it actually ends in some patches that would improve MRI’s method cache. So hopefully, those will get applied and we’ll see some good changes in there in the future. But it’s interesting because you can learn how this stuff works. So, two kind of deep down, under the hood, neat posts. And those are my picks. Joseph, what have you got?

So, my first one, I guess, would be the contempt page which is a collection of user net conversations about some of the most respected leading lights in programming, shouting and ranting about the evils of programming languages, OS, XML, Computing, everything. It’s a fascinating insight into how smart people could be so wrong. My second one would be the ‘Your Logical Fallacy Is’. There’s a free poster you can print out which lists all the logical fallacies. I love putting these up in the wall in the office just so people can read through them and browse. And again, it’s one of those things of just seeing what the fallacies are can be really helpful in improving and helping discussion be more productive. My final two, I guess, it’s a similar book, but it’s called ‘Winning Arguments: From Aristotle to Obama’, everything you need to know about the art of persuasion. This means, I guess, my epiphany of understanding rhetoric and it’s a really good introduction to a lot of the ideas and it takes a lot of the Greek ideas and explains them in far more accessible ways. My final pick, again, thinking more about how we work as machines, it’s an old one but I think it’s probably the book that’s changed me as a developer the most, is ‘Refactoring Your Wetware’. It’s an old Pragmatic one but thinking about rhetoric and thinking about how your brain works. I think it’s one of the most important books in getting how you work as a machine. And by understanding that, you can actually improve the effectiveness of that machine and I think that’s pretty awesome. And that’s my picks.

That’s awesome.

Those are awesome. Thank you, Joseph for coming and talking to us. What a great discussion.

Yes. Thank you.

Thank you.

Thanks a lot.

Can I throw, not really a pick, but a little bit of homework for the listeners?

Sure.

Go back to Josh’s pick of Guy Steele’s talk ‘Growing a Language’. Your homework is to watch the first ten minutes.

Yeah.

The bomb drops in the first ten minutes. You will end up watching the entire rest of the talk. I watched it twice. And the second time I watched it so that I could syntax check his entire talk. I thought I had caught him in a syntax error and was going to brag about it. And I watched it the second time, and I'm like, “Oh, darn it! He caught it.”

Yeah. I have to second that one. Josh way undersold that pick.

Yes!

And he really sold it well when he made it. But I did not get how eye-opening it was. And you start off watching that talk and you're like, “What's going on here? Something is strange.”

He’s talking funny.

Yeah.

We can't say any more or we’ll give it away.

Just keep going. It is a really great talk.

Yeah. Just ten minutes and then, you'll lose an hour.

So, yes. Well, awesome. This has been our episode on Rhetoric. You can, of course, find us on iTunes, leave a review. And that’s it. We will see you next week. Goodbye everybody.