JOSH:
Okay, don’t tell the world, but I’m having headset issues today.
JAMES:
I’m having Skype issues; like, my mute button has apparently…
[Laughter]
KATRINA:
That was beautiful.
ARLEN:
Poetic.
[Hosting and bandwidth provided by the Blue Box Group. Check them out atBlueBox.net.]
[This episode is sponsored by Jet Brains, makers of Ruby Mine. If you like having an IDE that provides great inline debugging tools, built-in version control, and intelligent code insight and refactorings, check out Ruby Mine by going toJetBrains.com/ruby]
[This podcast is sponsored by New Relic. To track and optimize your application performance, go toRubyRogues.com/NewRelic]
JAMES:
Hey everybody and welcome to the Ruby Rouges podcast. Chuck is off this week, so I’ll be your host. With me today, I have David Brady.
DAVID:
404 Poop metaphor not found.
JAMES:
Josh Susser.
JOSH:
Good Morning!
JAMES:
Katrina Owen.
KATRINA:
Good afternoon or evening from the Arctic!
JAMES:
And we havea guest Rogue this week, Arlen Walker.
ARLEN:
The button today is, “Mr. Garibaldi, get that police box out of my office, now!”
JOSH:
Very nice. James, I know you don’t run the show very often, but you forgot to mention yourself in the introductions.
JAMES:
Oh yeah. I am James Edward Gray, the second, who doesn’t run the show often enough to remember how to do an intro.
DAVID:
Today, we’re talking about ‘off by one errors’.
JAMES:
But today, the good news is I reclaim my tie for most episodes of Ruby Rogues recordings, so it’s a very special day. We have some announcements to make before we get into the show proper. Actually before we do that, Arlen, why don’t you introduce yourself since you haven’t been on the show before?
ARLEN:
Okay. My name is Arlen, that’s the Twitter handle as well. I do some freelance work but right now, I’m doing a full-time gig at the company called PKWare. The old guys in the crowd will remember PKZip back from the IBM/PC days. The current focus of the company is data encryption and compression.
DAVID:
Are they still in Dearborn, Michigan?
ARLEN:
No. They’re in Dayton, Ohio and Milwaukee, Wisconsin.
DAVID:
The old, my college days were spent compressing stuff onto floppies and every time you ran PKZip, it would say, “Copyright…blah…blah…blah…PKWare, Dearborn Michigan,” on it. And yes, I ran at that many times.
JAMES:
That’s awesome. So Arlen, you’re cleaning up their websites with Ruby or no?
ARLEN:
Not yet, I’ve only been there a week.
JAMES:
Good answer. Okay. So, as I said, we do have some announcements. First of all, we need to announce some support from listener Dave Newton who has signed up for our unofficial Rogue Status on Parley, which means he is contributing the most to help support the show and keep us doing this since we’re all recording the day after Christmas and skipping out on family time and stuff. We really appreciate that. So, thank you Dave. We just wanted to mention that we appreciate you on the air. We have some more announcements:
DAVID:
It’s Dave ‘We Freaking Love You’ Newton.
JAMES:
That’s right. Henceforth known as Dave ‘You are Amazing’ Newton, right. Okay. And we have some more announcements, so let’s go to Josh Susser for the Best of Parley.
JOSH:
Okay. If you are living under a rock and don’t know what Rogue’s Parley is, it’s a listener Email list. It’s private. You have to pay us money to be on the list as a great way to support the show which Dave Newton has done in spades. So the best Email thread on Parley in the last week was entitled “DHH episode”. I don’t know, we had about 80 Emails in that thread, which I think is pretty much a record except for the introduction thread. This was -- people had been talking about some of the topics that we addressed on what was it? Episode 56, James?
JAMES:
Yes.
JOSH:
Episode 56 with David Heinemeier Hansson and it split off into a thread and was chunking away and a lot of people were saying what they think DHH meant on occasions. So we poked David and he hopped into the Email thread on the list. And we had a pretty spirited conversation about objectoriented design and maintainability of software and various other bugaboos. And it’s still going strong. That was one of the more awesome threads we’ve had on Parley in a long time.
JAMES:
That is the thread how us geeks spent our Christmas vacation.
JOSH:
Yes it was great; sure beats dealing with relatives. [Laughter]
JAMES:
We have one more announcement about a survey which David Brady will tell us about.
DAVID:
So, what was the best Ruby Rogues episode this year? Was it the ‘Rails Bridge’ episode with Sarah Mei? Or one of the book club episodes like, ‘Land of Lisp’ with Conrad Barski? Was it the ‘SOLID’ episode with Jim Weirich? Was it the ‘DHH’ episode with DHH? Go toRubyRogues.com/surveyand let us know. We’ll tell you why later.
JAMES:
Alright. And I think that concludes our announcements, so let’s get into the show. This week’s episode is called ‘Learning from the Past’. And we decided to do this episode because Arlen wrote a concerned blog post/Email to us. So Arlen, why don’t you tell us what that was about?
ARLEN:
Well, the basic sentiment that set me off was the idea that a developer, or I suppose he can be extrapolated to be anybody, could not possibly learn, in this specific instance, software development patterns, and could not possibly begin to understand software development patterns, until they have felt the pain of not using them. And that notion that kind of went unchallenged, struck me as being completely anti-scientific not just unscientific, because the whole premise of education is that we learn from mistakes other people make. We don’t learn only from our own mistakes; and to require somebody to learn only from their own mistakes means that the state of the art will never advance, because eventually you’ll get to the point where you don’t have enough time in your life to make all of the mistakes in order for you to learn from them.
DAVID:
This sounds like someone who does not understand ‘pain does not have fire’. [Laughter]
JOSH:
I think that’s a pretty good, solid theoretical foundation for learning from others via reading or language, in some form. But that’s up against learning from experience.
ARLEN:
Yeah, but there’s vicarious experience, as well as direct experience. And I think one of the examples I used was a person from a major open-source project told me once about a new paradigm or a new approach they had just read about and they’d just discovered essentially called ‘Model View Controller’ and this conversation happened in 2005. If you go back and look at the history of software development, you see in the 1950’s, you see Agile programming, in the 1970’s you see Agile programming and then in the 1990’s, all of a sudden, you see it again. We, as an industry, it seems have Anterograde Amnesia. We have an ability and inability to form long term memory.
JAMES:
That’s awesome.
JOSH:
Yeah, I believe it was at OOPSLA a few years ago. Alan Kay did a keynote presentation where he basically showed a bunch of videos of stuff people had done in the '50’s on computers that just blew everybody away with what they were able to do 50 years in the past that is actually hard to do these days. It’s not like the guys 50 years ago were slouches or anything.
DAVID:
So, Arlen it sounds like you framed both sides, both your argument and its own rebuttal depending on context, right? I mean, on the one hand, you can’t learn unless you experience it but on the other hand, we’ve got the Eternal September going on, right? Where it’s like, every year the new group of freshmen comes in and everybody makes the same mistakes again. You can’t learn unless you learn from experience but we’re obviously not learning from anybody else’s experience anyway.
ARLEN:
And I wonder why that is. It’s frustrating to me because I’ve been around since the days of SDM-70 and some of the serious Waterfall software development ideas and it just seems to me that we’re repeating mistakes that we shouldn’t repeat. And it bothers me and I don’t have an answer necessarily. What really bothered me about, that set this off, is that you guys didn’t challenge the notion that we can learn from somebody else’s mistakes.
JAMES:
That’s a good point. [Crosstalk]
DAVID:
And now, we’re actually going to show you that we can’t even learn even when we’re called on it. [Laughter]
JAMES:
At one point in our past, we had a conversation about learning from the rules. And I brought up how, obviously, we follow the rules most of the time. But learning when to break the rules is a very valuable skill to get the hang of. Then the counterpoint was made that maybe it’s backwards. Maybe we need to learn when to follow the rules, which I don’t hold that idea because to me, we put those “rules” more like guidelines. But we put those in place, because, more often than not, they lead to saner solutions or better solutions. There’s always going to be edge cases where, “If I go off the map this time, I can actually do better than our typical usual plan.” And I think that’s always going to be the case which is why we have to never follow them absolutely. But I think programmers, we’re kind of anarchists. We don’t like the rules, right? We like to have as few rules as possible, or something like that, and we don’t like to be chained down and so we resist that.
JOSH:
James, I think the word you’re looking for is ‘rules are for other people’.
JAMES:
Right. Don’t we all have that attitude?
DAVID:
I have the sign from the 1980’s that says ‘Managing programmers is like herding cats’.
JAMES:
Exactly. I don’t know what it is about our particular profession but we seem to have that disease more than most people, I think.
ARLEN:
In the original, James had brought up chess in that context and that actually worked well for me because in chess, we’ve had that discussion over the past 10 years between John Watson and Jacob Apagard in a series of books, but the idea of having rules and when to follow them. C.J. Purdy, a great chess writer once wrote, “There are those who do not know the rules. There are those chess players who do not know the rules and thus are weak. There are those who know the rules and thus are less weak. And there are those who know how weak the rules are and they are strong.”
JAMES:
Yeah, it really comes up in chess, as a big chess player myself, because in chess, at any given time, there are so many criteria that can be playing in to individual position that you find yourself in. If you don’t have a good, fundamental knowledge of those rules, you don’t even know what you’re supposed to be paying attention to. Even if you’re going to choose to deviate or violate some rule, you don’t know which criteria to analyze to determine which way to go. Does that make sense? So you have to have that fundamental understanding to be able to correctly assess what’s happening.
ARLEN:
In a nutshell, you break the rules, because you know why you’re breaking the rules.
JOSH:
Can we bring that back home to software development?
KATRINA:
Yeah, sure. So when I learned TDD, I followed the rules of TDD to the point. Like no deviations whatsoever. And there were a lot of people who said, “You shouldn’t always use TDD.” I’m like, “Okay but I don’t know how to do TDD so I need to do it until I know how to do it.” A lot of people will ask, “Well, when do you not use TDD?” The thing is, until you’ve used it so many times in situations where you maybe don’t need to use it, it’s really hard to say. It’s really hard to have enough contexts about a rule to know when to break it without really knowing the rule without really having overused it and used it in situations that are correct and situations that are probably incorrect.
JOSH:
So you’re saying something like if you have a hammer and everything looks like a nail, that means that you don’t really know who used that hammer well enough.
KATRINA:
Yeah.
DAVID:
A morphism of that, “If the only tool you have is a hammer, every problem looks like a smashed thumb.” [Laughter]
JOSH:
I’ll laugh for you, David.
DAVID:
Thank you.
JAMES:
One of our old episodes that I think is underappreciated is the episode where we interviewed Dan Kubb. Do you guys remember that one?
JOSH:
That was like science.
JAMES:
Yeah. That episode was like super eye-opening for me. And Dan is so good about making his learning purposeful. He’ll adopt some rule. I’m not sure I remember exact examples. Actually, I think I do. One of them was replacing constants with methods, like never using a constant just defining a method that returns that value and doing that. And he would do that for like a long period of time and then assess, “Is my code getting better or is it getting worse? Is this doing something for me or not doing something for me?” But it’s so purposeful, right? It’s such a great way to learn. You know, we’re programmers and we appreciate these facts, right? Think about when we’re optimizing something. We profile it and see how much time it’s running in. Then we make some change and then run it again because we all know that we can guess where the speed block is and we’re probably wrong most of the time. We keep doing that until we find it but we don’t always do that to ourselves. I read a great article the other day about a champion Star Craft player. Yeah, those actually exist. It was amazing how much attention he had paid to his playing ability under separate circumstances. So he would come in and make it ridiculously cold in the room and then play Star Craft over a period of time. Then make it ridiculously hot in the room and play Star Craft over a period of time. Then analyze, “What are the conditions under which I play Star Craft better?” It’s very interesting.
JOSH:
I think it’s interesting to know also that Katrina touched on this notion of internalizing the ability that you get, the ‘I’m going to do this until I’m good at it’. And I was having a conversation with a coworker recently about the value of testing and I love testing. My hack will start to go up anytime somebody wants to question the value of testing. The reality is that we have a full QA staff and there are some things that we shouldn’t be testing because we’re already paying money to have somebody else test this. So unless the test has a different way of generating ROI for the team, just finding bugs, that’s QA’s job. So we have to find ways to speed things up. I was only nervous about the part of the conversation where I could see somebody, this person wasn’t doing his part. I was talking to other people and they hear this conversation about -- there’s a trade off, so maybe there’s a time when testing isn’t great. There are people who will go, “Let’s just not learn testing and not bother to ever do it. We don’t need testing.” And then they sail on merrily down their way thinking there’s a straight off, we’ve avoided it, now I don’t have to learn this. And they’ve missed the fact that it’s more like the habit. You have to go there and come back again so that you kind of understand the trade off and then you can decide. Like Arlen said, when you understand that the rules are weak then you’re strong but you have to have learned the rules and internalize that before you can make that call.
KATRINA:
This brings up a really interesting question about various practices, best or not, in computer science or in development and whether or not you could take a beginner and lead them to learn these practices without necessarily them having felt the pain of trying to maintain a million line code base where these practices weren’t actually implemented.
ARLEN:
I’d like to take your experience with TDD and extrapolate it a little bit because if you’ve done a lot of work with TDD and found out where it works and where it doesn’t and where it’s useful to use it and where it isn’t useful to use it, if you publish that, then the next person coming along can look at what you’ve published and say, “Well maybe I shouldn’t do that here.”
KATRINA:
Yeah. [Crosstalk]
DAVID:
Right, but if they don’t ever do it, and then they decide that they should do it, they’re going to have a harder time. Does that make sense?
ARLEN:
Right, they should learn the principles of it but they can, at the same time, learn from Katrina’s experience that it doesn’t work in this area.
DAVID:
I think we’re in violent agreement. I mean, you have to develop the habit and there’s no way to do that except to spend some time in the trenches. But I certainly agree that it’s absolutely a disservice to the newbie’s coming up in the field to just throw them in the deep end and hope that they can figure out how to untie the sack from inside. We could be giving them a much more sophisticated uninformed opinion going in by saying, “Here are some nuances to look out for.”
KATRINA:
There’s another way of doing this. Have any of you ever tried reading some of the Head First books?
JAMES:
Yeah.
KATRINA:
Depending on your context, they can be really useful or not. One of the things that I think that these books do really well is that they will give you an idea and then they will lead you into making the typical mistakes that following that idea can lead to. And then after you’ve made that mistake in a very small toy program, they’ll tell you a different way of solving it. For example, in their design patterns book, they suggest that you build a program. They’ve introduced inheritance and they suggest that you build a program to do some sort of Starbucks drink price calculator and it turns into a nightmare of parallel hierarchies and then they introduce decorators. It doesn’t take more than four or five pages to really understand the use of the decorator pattern in this context. It’s really interesting.
JAMES:
I think you just nailed it right there. There’s a sense of scale involved here. People, they’d say, “You can’t learn it until you’ve felt the pain.” So, say you start making some mistake. But at a minor scale, you can probably make that mistake a few times without paying a very big penalty, right? But then if we’re talking about big scale, a very large application or something where you’ve made that mistake all over it, then the pain really sets in, right? That’s when you realize, “Oh, I’ve made a huge mistake here. And I need to rethink this!” But if you have an experienced mentor, say, working with a junior programmer and that programmer starts making that mistake, they may not feel the pain yet but there may be opportunities still for the experienced mentor to say, “See how you’re kind of having a hard time doing this,” or whatever. We may recognize the pain quicker because knowing where things are heading or whatever and can show the better way. And then, it still may be possible for that junior programmer to appreciate it on a smaller scale after it’s been pointed out without having to go all the way to where it’s slayed the entire machine.
JOSH:
Right. And I think that some of that has to do with a local maximum versus a global maximum or minimum, depending on your perspective. That a junior programmer or anyone, really, can be in some local trough, local minimum on the overall curve and be really optimized for a particular approach and they are doing the best they can with that way of thinking about the problem. But it turns out that if you cross over one of the local maximum, you can find a much lower minimum right next door. It’s like, “Oh, I switched from using presenters to using a builder pattern.” And suddenly, everything becomes much, much easier. One of the things that I found is really excellent and James, he just mentioned mentors. And I think mentoring is a great way to help educate people and help them learn. But sort of the 100% always on mentorship while developing is another word for para-programming. And I found that educating someone in programming -- once you’re past a certain level of capability, para-programming is such a great way to educate people and to teach the context which is really what you’re talking about James is having the right context to be able to decide which of the rules you want to pay attention to.
JAMES:
A lot of times when you’re para-programming, you’ll see somebody do something and you’re like, “Why are you doing that?” And they’ll say, “I’ve just found that I tend to go wrong here. So, I’ve kind of built this habit that keeps me from falling in that hole.”
JOSH:
I remember Avdi saying that on one episode where he was talking about using parentheses around arguments when you send a message or invoke an operation in Ruby. We all know parentheses are optional. But many of us have learned that if you leave them out, often you have to come back and put them in at the moment when you want to use the return value from that method. Avdi says with new developers he’s pairing with, he’ll just like drop that in and say, “No, put the parentheses in. I know it looks cute without them. But just trust me, you’ll want that later.”
DAVID:
That’s so wrong, so wrong.
JAMES:
What’s awesome is that once you begin to understand that, once somebody’s pointed that out to you, then in cases where you can really safely leave out parentheses become painfully obvious like the PUTS method which never returns anything useful anyway, right? Leave the parentheses out.
JOSH:
It just always returns ‘NIL’, so we’re good.
KATRINA:
So I want to go back to learning vicariously through other people’s mistakes. Are there any ways that we can specifically go out and do that? Like say, I want to learn from other people’s mistakes in this context or this situation. Where would I go? What would I do?
ARLEN:
In chess, we have a saying, “study the classics.” There are classic games, classic sacrifices, classic positions, and classic treatises on the game that you study. I’m not sure if we’ve made that effort to do that in the software development field. There are definitely classics in the software development field in terms of books. But have we identified classic bits of code that people should read and study? I remember a book - can’t remember the name of it now- that studied some of the source code of the UNIX utilities. I think the first version of the book rewrote them in RAT4 and the second version, I think, maybe rewrote them in PASCAL but I don’t remember now the name of the book. I’m drawing a blank on that.
JOSH:
So I just read a blog post a couple days ago, or maybe it was even an article in the New York Times or something, but it was talking about the sad state of most real world software. And if you talk to any professional software developer, they’ll tell you that pretty much all production software out there is crap. It’s just not well built, it’s not well designed, it’s not well structured, it’s hard to maintain, there’s bugs in it, the features don’t work right, et cetera. And we, as professional software developers, just accept that as ‘That’s the way things are because you can never make software perfect’.
DAVID:
It’s because we’re bad people.
JOSH:
No, it’s because you’re bad people. [Crosstalk]
JOSH:
But the way the software gets taught is you’re always looking at the exemplary software, the good software. I was just thinking while we are having this discussion here about what are the examples of bad software that people should be looking at as counter examples?
DAVID:
Actually, I want to respond to the ‘All software is crap’. First of all, I’m bad people. So, what’s your excuse? But the second one is we tend to view everything as true or false. We love that binary dichotomy of computer science. So something is either 100% pure clean and good or it’s bad. And what somebody who’s been in the trenches for five to ten years or more has learned is that you’re going to have to ship some dog poop with the brownies, no matter what. Even if you had a perfect program, all you have to do is change one feature requirement and now the whole thing is optimized for not that requirement. Suddenly, all this wonderful good stuff is bad. I’ve written programs that I was in love with. I thought it was absolutely perfect. And I’ve come back to them a year later - one time, as little as three months later - and said, “Oh my gosh! This is all crap. This all has to be thrown out!” I just wanted to point out that true/false dichotomy. And I think senior developers kind of have this, “Okay, it’s 80% good, 20% crap and the 80% good is covering all the right bases, and the 20% crap is something that we’re willing to suck up. And so, we have to ship it. Go for it.”
JAMES:
I think in the thread Josh mentioned in Best of Parley, DHH did a really good job of arguing YAGNI basically, ‘You Ain’t Gonna Need It’. He basically said and pretty much what David just said is that you can’t plan on the future. You don’t know what’s going to end up being added. So the best thing that you can do is do nothing. Sandy Metts talks about this all the time about how, “You’ll never be dumber than you are right now. Later, you’ll know more and you’ll have more information.” And so when that feature comes around then you can make a much better choice than trying to plan for if you say, “We’re going to need this in the future.” Yeah, maybe you are, maybe you are actually going to need that thing but maybe that thing ends up getting handled at a different level of the software than one you’re even working on now, right? So if you plan for that future, you’re almost always going to be wrong. You’re going to have that [inaudible] and DHH talked about how you’re going to have to yank all that out and then do what needed doing, right? So it’s best to wait and try to find no more.
ARLEN:
I think you’re kind of bucking down in the concrete right now. The idea is what needs to go into a newbie’s head because if it’s not in your head, it doesn’t come out of your fingers onto the keyboard. We need to put as many concepts and as many good ideas as possible into the head of junior developers as quickly as we can. Yes, they’re going to screw them up when they put them out. They’re going to write bad code. That’s the function of a junior developer, they will write bad code. [Crosstalk]
ARLEN:
What I’m getting at is, is it better for them to write bad code based on a good idea or bad code based on a bad idea? That’s where I think the crucial benefit of learning from the past, learning from other people’s code, learning from the classics in the literature of the field. And by literature, I mean both books and code that has been written before. That we extrapolate those ideas and feed as many of those ideas as we can into a junior developer, even though we know they are not going to execute those ideas well. It is better for them to write bad code based on a good idea than it is to write bad code based on a bad idea.
JAMES:
I think you’re right there, Arlen. But I do think that we can go too far in that direction. There’s definitely some hurdles in programming where my answer is, “Oh, after you have about 500 more conversations with the compiler, you’ll figure that out. “ And sadly, I think there’s just certain phases you can’t get past without that. I agree that giving them good information, giving them good plans and stuff like that is very valuable. But in the same way, you could start today and decide to read all of the classic books written about programming and then start programming and you’ll die before you get to the part where you get to start programming.
KATRINA:
Okay. So the way to put ideas into somebody’s head is not necessarily to give them a book about it. I mean, you really do have to get your hands dirty as you’re learning the concepts. And if you give a beginner the Design Patterns book, I bet that the beginner would look at you and say, “This is completely irrelevant. I can’t see why I need to be reading this.” And what they really need is something much much simpler but it might not take very long until they are ready to read something from the Design Pattern book. I think that you can’t just shovel everything in right off the bat. You need to try these ideas out to have some concept of why they’re relevant.
ARLEN:
If you’re speaking of the Gang of Four book, I agree with you Katrina. The intended audience of the Gang of Four book was the experienced developers, not junior developers.
KATRINA:
Yeah, the Gang of Four book.
ARLEN:
The Head First Design Patterns book was more aimed at the beginning developer and it taught a lot of the same concepts but it taught them in a different way. That’s what we need to do with the juniors. We need to see that they get the information in a way that they can understand.
JOSH:
Right, so you have to pick the right material? The Gang of Four book, being for experienced programmers isn’t a problem with the book. The problem there is trying to give that to newbie’s who aren’t ready for internalizing that information. [Crosstalk]
ARLEN:
There’s a phrase that we keep using which I think is really interesting. We keep saying, “You can’t teach,” or “You can’t do.” And I love it when somebody says that because I’ve recently started getting kind of a hardedge. What we used to say when I was growing up is, “You can’t teach self esteem.” And this was used as a weasley dodge or anything targeted towards teaching anything about character, or esteem, or confidence, or anything like this. It was used to basically say, “We are going to teach self esteem very, very badly.” What I’ve pushed back on lately is to say, anytime you say, “You can’t teach,” is to maybe step back and say, “We haven’t figured out how to teach yet.” We’ve got a lot of people with Asperger’s Syndrome, and a lot of the teachers have it and I’m just picking on one social disorder. But the fact is that we’re awkward. And so, we’ve got people who aren’t good at being taught, being taught by people who aren’t good at teaching. So when we say, “We can’t teach this,” I think it’s interesting to say, “We haven’t figured out how to teach this yet.” And some of it’s based on, like the Gang of Four. You’ve got to bring a lot of knowledge to the table for that book to be any good. Head First is not achieving the same thing. It’s starting with a newbie and teaching them the concept that these patterns exist. But it’s not streamlining a whole bunch of information that they have. And so, I think it’s interesting to say, “We haven’t figured out how to teach this.” “Oh well, here’s a new way to maybe teach this.”I’m just throwing that out that some of these things that we have said, “We can’t teach this.” Okay, but you can’t use that as an excuse to never try. Does that make sense?
JAMES:
I think you have a great point there. I was trying to think of a good example of my, “You’ll figure it out with 500more conversations with a compiler.” And the one that comes up in me is stack traces. Looking at a stack trace and figuring out what’s wrong? If you watch experienced developers do that, they go right to the problem. Seemingly quickly and even when the stack trace is real bad and doesn’t well point to the problem, a bad error message or something like that, they tend to know where the problem is or what kind of thing has gone wrong and that is really hard to teach. It’s a series of experience you’ve built up over time in that, “Oh yeah, when it complains about a missing end or whatever, it’s usually because I’ve done this thing.” And it’s a series of instincts that you build over time. But we do teach things to try to help with that. For example, TDD is a great example. If you’re following a good TDD cycle, then when the stack trace pops up, your space of where you have to look is significantly less.
JOSH:
James, what you’re talking about is, it sounds like the process of internalizing the 10,000 things you need to internalize to become an expert. Are people familiar with that concept?
KATRINA:
Actually, let’s run through that concept. There’s a model for skill acquisition called the Dreyfus Model and this is one of the PragProg books covered it in a chapter really well. It talks about five stages for developing a skill. And the first stage is novice, when you really don’t know anything. The second stage is an advanced beginner, where you can kind of follow a recipe, but once you’re outside of that recipe, you’re unable to get back on track without help. There’s the competent stage where you can follow routine procedures and get basic stuff done. Then there’s the advanced and the expert levels. The proficient and the expert levels where you really have a lot of context available to you and it feels like intuition but really what it is, is a lot of really fast processing that’s based on a very large amount of experience.
JAMES:
Pragmatic thinking.
JOSH:
Right. That was a great summary Katrina. But when you get to that expert level and you have those roughly 10,000 things internalized, the amazing thing that happens there is that they become sort of automatic. You don’t have to stop and think about them because when you start working with your sort of generic symbolic processing thought processes, that’s some of the slowest thinking you can do. And if you’ve internalized something to the point where -- it’s like if you’re a musician. You can’t sit there and think about -- you’re looking at the sheet music and trying to, “Well, that’s on the bottom line so that’s an E.” You’ll never be able to play music thinking at that speed.
DAVID:
I once worked with a group of kids that were all straight out of college. They were all brilliant, very, very sharp programmers. And my manager asked, “So what do you think of the team?” And I said, “They’re brilliant. They can figure anything out from first principles.” And he said, “But…” And I said, “The problem is if you want them to do anything, they have to figure it out from first principles.”
JOSH:
Can we shift this a little bit and talk about software pattern or design patterns in particular?
Because that was one of the topics that came up that I guess sparked this whole podcast. Can you teach someone patterns and are they a useful teaching tool for people who don’t have the experience and who haven’t felt the pain yet? [Crosstalk]
JOSH:
I think that’s the whole point of this conversation here.
ARLEN:
That’s the risk of further antagonizing Josh and bringing in chess again. I coach chess and I had a high school player who was rated fairly lowly. And I taught him two chess patterns. The Greek Gift Sacrifice and a Rook Lift which is a pattern for attacking. Then I taught him an opening that promulgates the use of those patterns and his rating doubled in one year. He did not become a master chess player by any stretch of the imagination and yes, he continued to make mistakes. But that gave him a solid footing that he could build his chess game around. I think we can do the same thing in software development with the software design patterns.
KATRINA:
That brings up a good point. If you’re going to choose two or three, which two or three?
JAMES:
TDD will do really high for me.
JOSH:
Well, that’s not a pattern.
JAMES:
That’s true.
JOSH:
So way back when, before injuries, I studied Kung Fu. My Sifu was pretty impressive. For a man in his thirties, he knew heck of a lot of Kung Fu and Thai Chi which is why I went to go see him. But one of the things he taught us was he told us a story of a prince who wasn’t very bright but whose father wanted him to study Kung Fu so. So his Sifu taught him one move which was like the most basic punch move there is and that’s all the guy ever studied. He became very good at that one move and that made him a terribly effective fighter because he had something that he was really, really good at. Now the other side of that, of course, is if you don’t have versatility, you’re stuck in a situation that you don’t have any tools to deal with. But Arlen, it sounds like you taught somebody, who is a beginner, a couple things that you knew from your experience. These were useful things to know. So he got the benefit of your mentorship and your greater understanding of ‘what are useful things to know’. And he got to focus on those couple particular things and polish them up and get good at them and then that let him play in games that were interesting enough that he could learn and become a better player over all.
JAMES:
And that’s one of the real keys, right? Because then you’re hooked, then you have your thing that works for you and you start doing it. And then someday, you run into that chess player or that Kung Fu competitor or that piece of software that is the perfect antithesis to that technique you’ve mastered, right? And it tears you apart. And then you’re like, “Okay I want to know how he did that.” And it hooks you.
ARLEN:
Yeah, but more in the point like in the case of this particular player I was talking about, and yes, Josh, some of it came from me. But a lot of it, like the Greek Gift Sacrifice has been studied in chess circles for the last century and many people better than I am have laid out the requirements for it. All I basically did was point him at them. But it gives you a solid basis, you are now doing something you are accomplishing something, you’re feeling good about what you’re doing and you want to learn more. So, it didn’t stop just with those. I taught him those and that got him on his feet.
And from that point on, he was unstoppable in picking up more things.
JOSH:
So we’re in violent agreement there. [laughs]
JAMES:
It’s that desire to learn more, that hooked thing.
DAVID:
If the only tool you have is nothing, here let me show you this cool hammer.
JAMES:
Right. And for a while, everything’s going to be nails to you but you’re going to do a lot of hammering.
JOSH:
But there are the circumstances of his learning that and that’s what I was trying to focus on was that, he’s getting the benefit of your experience and your perspective telling him, “Here’s a few things that you should study in particular.”
ARLEN:
Yeah, he was learning from mistakes that I had made in the past essentially. It’s a technique, I use it with my kids. I told my daughters - I don’t know how many times - when they were growing up, “No, don’t do that. That was my mistake. I did that. Trust me, you’re not going to like it.”
DAVID:
I’m a bad teacher because I’ll take somebody that doesn’t know any tools and I’ll say, “Let me show you this hammer.” And the last thing you want to do in teaching the hammer is, “Oh, and by the way, you’re going to have to use a thousand other tools later and you will eventually end up hating this hammer.” That’s not how you teach the hammer. It’s like, “Let me show you this hammer. It’s so freaking cool. In three months, you’re going to be roofing like a mad man.” I can’t leave off the -- but eventually, you’re going to hate anybody who uses a hammer. [laughs]
JOSH:
So who has recently ridden as a passenger in a car driven by a teenager?
JAMES:
Not recently.
KATRINA:
Avdi has. [Laughter]
JOSH:
Yeah, where’s Avdi when we need him? When I was younger and in college and had friends who were driving me around who were fairly new to driving, I noticed that there was a distinct difference between the driving when the driver had never been in an accident before and when they had been in an accident. I figured out after a while that the people who had been in accidents before, I felt much safer in the car when they were driving.
DAVID:
That’s interesting.
JAMES:
Yeah, they have developed these skills. “I usually go wrong like this, so if I compensate here...”
JOSH:
I don’t know if it was so much the skills that they leveled up on because they decided they were important after they had an accident or had been in an accident, or just their whole attitude about driving shifted.
DAVID:
Yeah, I’ve never been in an accident. But I, from age 16, drove like a grandma. My friends would tease me or harass me about it. And I’ve had enough near misses in which the buffer zones I had given myself got completely used up and that I did not get in an accident, that I completely have cemented the habits that I have. I have the same thing. I haven’t ridden recently with a teenager but I have recently ridden with a 25-year old who had never been in an accident. And yeah, grabbing for the hand rests, stamping your foot on the floor trying to -- I don’t have a brake, I’m not driving but I’m trying to put my foot on the brake. [Laughter]
JAMES:
Alright, Chuck’s going to kill me if I let this go much longer. So, do we have anything else we need to say about learning from the past?
DAVID:
I think this design pattern discussion, which has very little design patterns but a whole lot of patterns in it, has been very, very interesting.
JAMES:
Yeah, me too.
JOSH:
I think we touched on this a little bit, but what are good introductory patterns? Are there, in fact, any patterns that you can start people off with?
JAMES:
That’s a really good question, Josh. One of the things until recently, all the teaching techniques I’d seen, even in Ruby would start with non-objects and stuff, just teach basic conditionals and things like that. There was that really good video from Steve Regnarok about object-first teaching at [inaudible], right?
JOSH:
Yeah, his Sugar-Free Ruby talk, which I just loved.
JAMES:
I know! And it was a totally -- hearing the beginning of teaching, he’s doing things like using Singleton classes and defining 2S and stuff like that, really seemingly low level details of Ruby. And he doesn’t go deep into how they’re working or why they’re working, but it was really interesting how he was able to totally shift the focus of teaching by doing that, right?
JOSH:
Yeah. And just as a side note, I’ve probably mentioned this before, but the original small talk experiment where they were teaching grade school children how to program in Small Talk, there were like two students in the class who couldn’t get Small Talk programming. They just kept messing it up and were never really able to get their brains around it. When they took a look at what was going on, it turned out that both of the boys in question had fathers who worked for Hewlett Packard, I think it was, and had computers at home, and the fathers had already taught their children how to do some programming in Basic.
DAVID:
They knew how to bit shift and do RPN, yeah. The glass was already half full.
JOSH:
Yeah, the glass was mostly full, and they thought about programming in terms of GOSUBs.
DAVID:
Procedurals, yeah.
JOSH:
Yeah. I was all the mind set. It wasn’t like they didn’t have the same skills to be able to learn things. It’s just their focus was already somewhere different. So what’s the focus that is a great place for people to start, and what are the patterns that are worth people teaching there?
KATRINA:
I wanted to say the composed method but I don’t think that’s a pattern. There’s a template method pattern. But that introduces inheritance and I think that could go wrong pretty quickly, as well.
JOSH:
Well, composed method is Small Talk Best Practice patterns. [Crosstalk]
JAMES:
I do think it’s one of the neatest things you can learn at an early level because it shows you how to build software up by layers.
DAVID:
It’s interesting. I’ve been doing software for so long that somebody -- I’m reading Puder and she talks about single responsibility principle as applied to a method. And I’m like, “Oh, this is so clever and so clear. And why is this so familiar? Oh, this is composed method.” But having it described as ‘a method should have a single responsibility’ is beautiful. It’s a whole new light on composed method.
KATRINA:
Another thing that comes up fairly quickly is Adaptor and Façade. There are so many programs that go badly because you kind of think you have to go with what’s already there.
JAMES:
Yeah, when you’re using something else?
KATRINA:
Yeah.
JOSH:
I guess a lot of these patterns, what’s important and what’s useful and what’s even easy to use, depends on not just the kind of software you’re writing but the language you’re writing in. Like the Factory pattern is something that is really important when you’re in Java. But if you’re in Ruby, you sort of get that for free with classes so you don’t pay too much attention to it at the beginning.
KATRINA:
Yeah, same with Iterator.
DAVID:
Yeah, if you’re in C, Flyweight makes a lot of sense but if you’re in a garbage collected interpreted language, you’re so far away from the Iron that Flyweight probably won’t ever make sense.
JAMES:
And Ruby objects basically are Flyweight, right? They’re just a reference to some other thing.
DAVID:
Yeah, but they’re down below the level of the Matrix, right? You can’t access a Flyweight unless you drop down into C and implement something there yourself.
JAMES:
I think these examples we’re throwing out, in the specific cases, they help enter kind of a great explanation of why mentors and stuff are important. What’s valuable to you at any given time really depends on what you’re working on, what your context is, things like that. And that’s the mentor’s opportunity to jump in there like Arlen does with the chess student and say, “Ah, you know what? You’re looking for composed method. Let me show you this.”
DAVID:
The meta pattern here is that any beginner would do well to sit down with any of us, well, maybe not me. But to sit down with a mentor and say, “Here’s how you carve wood, let’s go.”
JAMES:
Chuck is now yelling at me on a backchannel, so we have to go to picks. It was a good discussion.
Thanks, Arlen, for joining us.
ARLEN:
Yeah, it was awesome.
JAMES:
Alright. Let’s do some picks. David, what do you got?
DAVID:
Lost Treasures of Infocom just came out for IOS. It’s on the iPad. You would not believe that Zork or a pure text adventure is playable well on an iPad device but they have really bent over backwards to make the interface workable and you can just about play without a keyboard. Playing it with an external keyboard on the iPad is like 1983 all over again. It’s just fantastic. The old Infocom games used to come packaged with all kinds of [inaudible] and they called them Feelies back then. So you would have the Letters from the Vampire that did whatever. There would be clues to solving the game in the box, printed on the box. And so, in order to properly ship an Infocom game one these old text adventure games, you really need all of the packaging material that came with it. So what they did with Lost Treasures is, you have a 3D copy of the original box - for Amiga and for Commodore 64 and these ancient boxes. And then you open them up, like you open up Zork and there is a Zorkmid inside. And you can spin it and turn it around and look at both sides of the coin and see that it’s got Dimwit Flathead stamped on the coin. It takes you right back, for those of you old enough to be taken back this far, it takes you right back to the 1980’s and playing these ancient games. I highly recommend it. It’s free but you get to pick which games you want. Just pay them $10 to get all of the games because they’re well worth playing. Remember to play with a map and take notes as you go or you will not even be able to solve the easy ones like in Chanter, which I just finished last night. Lost Treasures of Infocom, that was my only pick for today, and it’s just freaking amazing.
ARLEN:
I get a headache just thinking about Zork.
DAVID:
Oh yeah, yeah.
JAMES:
We basically played Zork I recently. And my wife and I had one of us running the keyboard, the other one mapping and stuff. It was a good time. Katrina, what do you got?
KATRINA:
Okay, no tech picks today. I have a cooking pick. I did a bit of cooking away from home this week and I was reminded of how terrible most peelers are. So, I’m picking the Kyocera Mega Peeler. It has a ceramic blade, it’s very sharp and it stays that way. My other pick is kind of two picks in one. It’s a science fiction novel and a sequel. It’s called ‘Daemon’ by Daniel Suarez and the conclusion is called ‘Freedom’. The book starts out with a series of murders where the victims are software developers and the killer is a demon written by a dead guy. And it gets better from there. So yeah, ‘Daemon’ and ‘Freedom’.
ARLEN:
Was the guy dead before or after he wrote the ‘Daemon’?
KATRINA:
I do believe he was alive when he wrote the ‘Daemon’. Tech Thriller. I do have to warn you that I am not very sophisticated. So I have no idea if this is good literature. It’s just a great fun story.
JAMES:
Awesome. Josh?
JOSH:
Nice. I have a follow-on to that which is the story ‘Press Enter’ by John Varley. So Katrina, if you like ‘Daemon’, there’s a short story by John Varley who’s one of my favorite Sci-Fi writers and it was a short story called ‘Press Enter’. I remember it was also like a locked room murder mystery. There were software energies involved and things like that. I remember the murder victims name was Kluge which I thought was very cute when I read that in the 80’s. Okay. So, my actual picks are, since we’re talking about learning from other people’s mistakes, I want to submit CakeWrecks.com as a pick which is, I think, a really great set of examples of other people’s failures. It’s amazing. You’re going to look at this site and you will see these professionally created cakes for birthdays and other occasions, and how badly they can go wrong. Then I have a software pick for a change, and that’s ‘Middleman’. I’ve only just fiddled around with it but I definitely have my eye on this for building my next static website. I’m probably going to convert the GoGuruGo site to use that in the next year. It’s one of these static site generators. This one is built using Sinatra as a sort of the stitching that keeps it all together. So, you can run a little Sinatra up locally to play around with your site during development and then you push a button and out comes all of the prerendered static pages for the site and then you push that to your server and you’re done. You get to use any other Ruby templating systems for doing the views and you can use a little Ruby code in how you generate everything. It’s pretty cool. And you use Sinatra DSL for routing. Middleman, it looks really cool. I’m looking forward to simplifying the GoGuruGo site using that. That’s it for me.
Thanks.
JAMES:
That’s awesome. I’ve never seen that before and just hearing you describe it, I wonder if in the end, it just turns on Rack-Cache and then goes through and hits every single URL once.
JOSH:
I think that’s close to what it does. It definitely has some Rack Middleware in there. Basically, you throw ‘Middleman’ up. It doesn’t work with a bare web server. You have to have Rack running. But it’s sort of perfect for pushing stuff up to Heroku.
JAMES:
That’s cool. Okay, I’ve got a couple of picks real quick. We talked a lot about patterns today and learning from the patterns that come up over and over again. In how I create my objects, I notice there’s a lot of patterns to that and how I like to handle attributes and stuff like that. So, I’ve been playing with a couple of gems lately that kind of fit my idea of good patterns. One of them is called the ‘Values Gem’ which is sadly not super easily Googled. But it’s a cool thing and that it’s Ruby’s Struct class which I love. And I’m sure Avdi has done a lot of singing of the [inaudible] on the show before. One of the problems with Struct is that it’s really lenient and flexible and you don’t have to pass the constructer args. And then, of course, it’s mutable and you can change things. ‘Values’ is that minus the flexibility. So, you have to pass all the constructor arguments, you can’t change on their mutable values and stuff like that. So, if you like Struct but wish it was a little less flexible, that’s ‘Values’. Another one I’ve been playing with recently is ‘Virtus’, I think that’s how you say it. It’s kind of an extraction of data mappers property API. So you can define attributes that your object has, which types they are and they can be coerced and have default values and then you can have the data mapper/atribugger constructor where you can pass in a hash value and stuff like that. If you find yourself constantly building up these Rails-ish like objects, data objects and stuff, this library can get you a long way there which is pretty interesting. Then my last pick is a video about how to use Evernote and how somebody uses Evernote. By now, I have basically my entire brain in Evernote, so I definitely use it extremely a lot. But the interesting thing about this video was something I hadn’t really gotten before. Stick around to like the last two minutes of the video where he starts showing how he uses all this information in Evernote to draw associations. And basically, it’s about how you can make it where when you search for something on the web, you see the things that are on the web plus the things that are in your Evernote and then you can use those to draw associations to things you already know. So, really interesting stuff there. Those are my picks this week. How about Arlen, what do you have for us?
ARLEN:
Since nobody else is doing it, I volunteer to be David Brady this week. The post that I made that started all of this was called ‘Chess and Software Development’. So it seems only fair that I begin with a chess pick. If you don’t know how to play chess, the best thing I can think of for you is a book entitled ‘Guide to Good Chess’ by C.J. Purdy. If you do know how to play chess and you want to beat the guy in the next cube, you want to search for ‘Chess Perfection’ also by C.J. Purdy. He is one of the finest writers on chess in the English language. However, if your goal is to become a competitive chess player, a master level chess player, there’s a nine volume set by Arthur Yusupov. Three sets of three volumes each, ‘Build Up Your Chess’, ‘Boost Your Chess’, and ‘Chess Evolution’. And the three volumes in each one are the fundamentals beyond the basic and mastery. I feel confident in recommending those, even though the last volume has not yet been published. For a technical pick, I really love the Safari Books service from O’Reilly. I don’t know if you’ve ever seen that. It is all of the O’Reilly books, all of the Pearson books, Addison-Wesley books. Just about every technology publisher of the Pragmatic programmers, for some reason, is represented here. For the cost of six technical books a year, you get access to all of them in an electronic format that you can just pull in and read. It’s just absolutely invaluable. As a matter of fact, one of my books on my shelf right now is Practical Object-Oriented Design. So I guess, indirectly, I’m picking that one too. And finally, for Science Fiction pick, the finest Science Fiction series ever to be made, ‘Babylon 5’ by J. Michael Straczynski and it’s a five year story arch. It’s a fascinating look at interplay among races and just in general, a great piece of Science Fiction.
JAMES:
Awesome. Alright, thank you very much.
DAVID:
You have another four minutes left to even come close to my record.
JOSH:
Arlen, I love Babylon 5. I’ve watched that series over and over. And my favorite thing about that series is the thing that they say in the very first episode which is, “No one here is exactly what they appear to be,” is so true. And he just manages to put all this stuff in the very first episode, first part of the first season. And five years later, it was like, was he really thinking that far ahead?
ARLEN:
It’s amazing the way he weaves these things in and out. The fifth season is kind of weak because they weren’t sure if they were going to get a fifth season. So, he tied up some story lines before he originally planned to.
JAMES:
So, basically what you’re saying is that it’s the opposite of Lost?
JOSH:
It’s a called Found. No. [Laughter]
DAVID:
It’s a story that starts out completely gibberish, and in the end, it all makes sense.
JAMES:
Alright. Arlen, thanks again for joining us and expressing your concerns and coming in and telling us about them.
DAVID:
This was a great call.
JAMES:
And allowing us to have this great conversation. So, thank you very much.
ARLEN:
Thank you for having me.
JAMES:
And that’s it. Sign up for Parley where we have all kinds of great discussions now with DHH.
JOSH:
What’s next week?
JAMES:
Next week? Next week is our book club episode, right? I think.
ALL:
Yes.
JAMES:
‘Practical Object-Oriented Design in Ruby’ by Sandy Metz. It’s an absolutely amazing book and we’re going to have a great chat with Sandy who, if you listen to the show, you’ll know we’re pretty much all fans. So yeah, join us next week for that and thanks everybody!