016 RR Becoming a Better Developer

Download MP3

Debugging does not stop when you run out of answers, it stops when you run out of questions Josh brought up this article. A few points brought up regarding getting better were:

  • Practice
  • Measuring achievements
  • Learn the Fundamentals
  • Start a hard project
  • Practice builds skills and habits
  • Habit vs instinct
  • Dunning Kruger effect Non-code related qualities that make you a better coder:
  • Empathy
  • Communication Skills

Panel suggestions for being better


  • Become a better communicator
  • Learn from other fields (brain physiology as an example) Avdi:
  • Practice
  • Read
  • Work with other people and read their code David:
  • Never stop playing
  • Never stop learning
  • Never stop failing
  • Never stop until you succeed Josh:
  • Pair program
  • Care about something
  • Tackle hard problems Chuck:
  • Be confident in your skills
  • Tackle hard problems
  • Get to know advanced programmers Problems you can tackle:
  • Language Interpreter


DAVID: [In a high pitched voice] How do I get better at this? How do I learn more things? Are there books I can read? Do I have to do programming to be a good programmer? JAMES: [Chuckles] Can we just use that recording right there, and then go with that? CHUCK: Hey everybody and welcome back to the Ruby Rogues podcast. This is your host, Charles Max Wood. And this week’s panel, we have five awesome Ruby developers. First off, we have David Brady from Shiny Systems. DAVID: Hello! CHUCK: We are going to do the self-introduction thing again. So, go ahead and tell us something about yourself, Dave. DAVID: Hi, I'm Dave. And I've been sober… I mean, I run Shiny Systems, and I've been programming Ruby for 4-5 years. I do the ADDCasts podcast with Pat Maddox, and I can be found blogging on the internet at heartmindcode.com, and saying usually inappropriate things at twitter.com/dbrady. CHUCK: Or on the first ten minutes of this recording. DAVID: Yes. CHUCK: All right. Go ahead, Avdi. AVDI: All right, I am Avdi Grimm, and I am an independent software consultant. I can be found at Avdi.org, and write a lot in… I don’t know, you've probably seen it. CHUCK: All right… AVDI: Can you like edit that out? That is the worst intro ever. I hate these self intros. JAMES: [Chuckles] DAVID: No, keep it, because I'm going to [inaudible] for the fact that Avdi, you could not get avdi.com? How many freaking Avdis are there? AVDI: It's taken by a company, that’s like a… their acronym is a-v-d-i. DAVID: It's a four letter TLD, that’s right. They are all taken. All right. CHUCK: All right. We also have James Edward Gray. JAMES: Yes, I am here, and I'm going to introduce myself somehow. I'm on Twitter at  @JEG2. That’s usually where I do most of my talking. I have a blog, but I haven’t updated it in a while. I have grand plans on it someday, that I'm going to fix it, so I won't pimp it until I do. And that’s about it. CHUCK: All right, and Josh Susser. JOSH: Okay. Hey, good afternoon everyone -- no matter what time zone you are in -- it's after noon here. So, I'm a San Franciscan, and I guess you can call me an ‘entrepreneur’ these days. And things that I've done that you probably don’t care about, include I wrote the first binary object storage system in Smalltalk back in the 80s, I co-op the Java code virtual machine specification, which means that runs in the chip in your iPhone. I'm on 4-5 billion other devices. And I've co-authored a book on Open Doc -- which nobody ever used. AVDI: I remember Open Doc. JAMES: I remember it too, but I agree that I didn’t use it. JOSH: [Chuckles] Okay, so enough about me. What's our topic this week? CHUCK: Actually, I'm going to introduce myself and then we'll get to that. JOSH: No, you need no introduction. CHUCK: Oh, I appreciate that. JOSH: [Chuckles] DAVID: He’s Chuck. CHUCK: [Chuckles] I'm Charles Max Wood, I'm the host at teachmetocode.com and Railscoach.com. And I just put up  a Beginning Ruby on Rails course. You could find it at railscoach.com; you just click on the Ruby on Rails course link, and it will take you there and tell you what it's about, and then you can sign up. All right, so the topic today, we are talking about becoming a better developer -- which I don’t know if there are many other broader topics in software development. And so, to steal Josh’s thunder, can we get a definition? JAMES: Yes, and I like it when Josh defines things, so perhaps we could start there. DAVID: Oh, the tables have been turned. [Laughter] JOSH: You so got me, James. [Chuckles] So what are we talking about? What it means to be programmer? Or a better developer? I don’t know exactly what people care about, I think one way of measuring that is you can get the job that you want more, because a lot of that are developers for work. So I think being a better developer means that you can do the work you like doing. But I think at another way of looking at it, it just means that you are more skillful, you can deal with more kinds of problems and you are more eversible. DAVID: I loved that the first half of the definition you give was entirely sociopolitical and economical. I mean, that's a marketing statement. You know what I mean? We've all worked with programmers, or if you’ve worked with me, who are overpaid and have just gigantic egos and couldn’t cut their way out of a paper bag. CHUCK: I didn’t wanna say anything, Dave but… DAVID: Yeah, yeah. Thank you. JOSH: I think you got to speak to people’s motivations, and people wants to level up, so that they can advanced themselves in some way. And for most of us, that has to do with our careers. DAVID: I already have a fun side tangent already set up for it. I am a strong believer that salary is how you keep score. And if that is seriously… and I’ve had people come to me and say, “We'll give you this title.” And I'm like, “I don’t keep score on that. You can pay me money.” “Well, what if we give you 70,000 shares of options?” And I'm like, “How about if you give 75,000 in dollars?” Because that’s how I keep score. Anyway… CHUCK: I think you are kind of bringing up relevant point in the sense that, dollars is something that you  can measure. DAVID: Yeah. CHUCK: If I stand you up next to… I don’t know, some other developer and say, “Which of you is the better developer?” I mean, that's one metric that you can definitely measure -- provided that you and he are willing to disclose that information. DAVID: Right. JAMES: It's interesting though how accurate do we think that is. I mean, I've definitely known programmers that were making more than me at various periods, and I'm so specced  on whether or not they were deserving of that or not. CHUCK: Well, I think in some cases, it means they are better at selling themselves… That’s going to come out really wrong. DAVID: That is exactly right. CHUCK: But that’s what it is. They are better at selling their abilities than you are, if they have a better salary than you do. DAVID: Yeah. JOSH: Anyway, I don’t want that to be too superbly distracting from the meat of the conversation that everyone is tuning in for, but [inaudible] some context. CHUCK: Yeah, I think though that we idealize it a little bit, and we think that there’s got to be like a better way of measuring it. And so I'm kind of curious as to what methods you guys use, to determine, “That guy is better than me or not as good as me or maybe better than me in this area and could learn something from me in this area.” How do you gauge that? JAMES: So I have kind of a weird view of this. Josh sent a cool article, which was extremely practical and stuff, so I´ll let him talk about that. That’s probably the good answer. And I´ll go ahead and give the bad answer. But I find that when I'm actually comparing programmers --- and maybe this is just me -- but I like to watch and see when you run out of ideas. Because to me, the hard part about programming -- about doing programming all the time -- is just ideas, right? I mean, you wake up and you start having ideas immediately, and you are not usually programming for ten minutes before something unexpected happens, and you need a new idea and then you end up building that big feature and you get about 75% of the way there and realize why your fundamental premise was flawed, and you'll need to redo the whole thing, you know? And it's to me, programming is about how long can you keep the new ideas coming, and how soon do you get flustered or how well can you come it from a totally different angle. So when I'm measuring somebody, I'm actually trying to watch and see how soon do they run out of ideas. DAVID: I'm going to agree with you violently, James. Meaning it's going to sound like I disagree with you, but I think we're on exactly on the same wavelength. When I interview somebody, if I'm really trying to my technical interview, I will run you out of ideas. I will run you all the way up to prove p=np, if I have to, in the thing. And it's not because I'm trying to find out how many ideas you have before you run out of ideas, all though I think that’s a fantastic measure of experience. People ask me what's the difference between programming at 40 and programming at 20, and I basically say, “It's kind of the same thing, except that I forgot seven different ways to do everything.” But going back to the ideas, what's very, very interesting to me – and this is really key about developer skill – is what do you do when you do run out of ideas? Steve McConnell says, “Debugging does not stop when you run out of answers.” He says, “Debugging stops when you run out of questions.” And so I love to run a developer in an interview, up against, “How do you solve this problem?” “I don’t know.” Cool, now we are ready to begin. So, what do you do when you are out of ideas. JAMES: And you know they are guaranteed to be there at some point, right? If you are a programmer and you haven’t run into the spot where you are out of ideas, then you haven't done anything risky enough yet, you know? DAVID: I run out of ideas every single day. And I don’t think it's because I'm dumb; I think it's because I'm particularly well-balanced in a match against the kind of problems I'm trying to solve. CHUCK: That’s an interesting thing to think about, really. DAVID: Yeah. [Chuckles] I'm trying to spell words that have as many as 7 letters in them. I don’t know about you guys, but that’s pretty freakin hard. JAMES: [Chuckles] So should we talk about the practical side? In the article that Josh sent… Josh, do you wanna tell us what it said? JOSH: Yeah, this was actually tweeted around a lot. That’s how I saw it. The post is on JasonRudolf.com. And it's a rather extensive list of very concrete things to do, kind of in the small to level up as a programmer. So this is set up as programming achievements. I´ll put a link in Skype, so you will be able to see it. And you know, it's things like running all these different languages and writing all these different kinds of apps, and various things. But I think that most of the article can be summed up in three words; practice, practice, practice -- which we all know is how you get better at doing something. AVDI: I did like his somewhat empirical way of measuring things. He came up with some measures, with some so called achievements like you might see in like Foursquare or Xbox Live of something, that are all pretty well measurable in terms of like, yes-no. They are not terribly subjective. They are like, “Yes, I have programed this significant system in Haskell,” or “No, I have not programed this significant system in Haskell.” Just as one example. And I kind of like that that was… it's so hard to find objective measures of this kind of thing. JAMES: I think it's also worth pointing out that programming is kind of a big umbrella. And like, for example, the kinds of programming we do really affects what we are expected to know at any given time. And while there are some things come in handy in any level of programming, like being able to measure an algorithm and see what it's slow, and what kind of way you would need to change it in order to give it a reasonable chance of speeding up. But things like that can't become handy in all aspects, but like for example, if you're a web developer, the odds are fairly good that you just don’t need to write a binary search that often. You know what I mean? Probably doesn’t come up in your day to day job. DAVID: You know, as soon as you say, that won't come up. [Laughs] JAMES: Yeah, I will be going there saying going, “God, how did I do binary search again?” JOSH: So James, I think that’s a great lead in to an important point, and that’s that while you probably don’t need to write a binary search or a quick sort or any of those low level things, I do think that familiarity with how those things are generated implemented is quite valuable. And while I doubt any web developers can be writing assembly or machine code anytime soon, it's really valuable to spend some time learning how to program a machine at that level; so that when you run into the unknown frontier somewhere, you have some of those fundamental to fall back on, so that you can at least make some educated guesses about how something may be working or the cost of the implementation, or what have you. DAVID: You know, there's a dichotomy that new programmers have, and it's, “Should I go dive down and learn the really deep stuff or should I say hi at architecture and learn this.” “I got to learn them both.” And there's almost like this trade off like the more low level I've learned, I feel like I'm giving up high level architecture. And I just now realized that those points are not in contention with each other, because good programming is the ability to abstract well. And if you can't tell… if you haven’t done low level programming, you can't tell low level programming from high level programming -- and you'll never be able to abstract well. So you need to learn both. AVDI: I'm always amazed or sort of in awe of programmers who can remember things. CHUCK: [Chuckles] DAVID: I get tired of them sometimes. Like seriously, I mean like, how much RAM are you wasting in your head for architecture, because… JOSH: I have a horrifying example of that. I was once writing a graphics library with a classmate and he typed in an entire font… all the bitmap glyphs just by typing in the hex codes in an editor. AVDI: [Chuckles] JAMES: What? No way. JOSH: Absolutely. I watched him do it. JAMES: That’s not right. CHUCK: So my thinking on that kind of thing though for me, like there are some things that I remember, but I have to build up quite a bit of context around it before I can remember it. AVDI:   I talk to people that… like when I'm doing tutoring and stuff like that, I talk to people that think that sort of what makes someone a great programmer is that they can remember all the stuff, and they like know all API of whatever they are programming. And they are kind of blown away when they realize… when I actually pair program with them and they realize, I basically like when I'm writing Rails apps, I'm sitting there with the documentation open, I can't remember anything.  Like unless I wrote render partial five seconds ago, I can't remember the order or like link to… [Chuckles] link to, let’s say I wrote “link to” somewhere up like two lines, like I can't remember which order the arguments go in and forget it. And like that's me for everything; all I try to do is try to sort of leave a marker in my mind about where I found a certain piece of information. I do that both in my mind, and I also do it with sort of external systems. So I probably had like 10,000 bookmarks all tagged up. And I just try to make sure that I know where to find information that I've seen before, because I can't remember squat. CHUCK: I have to point out one of two things just happen for me; either I just leveled up about 8 levels, because I realize that you guys don’t remember this either, or you just leveled down about 8 levels because I really just don’t remember this either. DAVID: [Chuckles] Yeah, we just leveled down. I'm going to go ahead and confess that 30% of my programming knowledge is just an array of Google keywords. Seriously, if I need to validate something, I open Google and type, “Rails 3 validations” and hit enter. And the first three links are the same first three links every time. And by the way, this is a micro rant. For any of you out there writing documentation that think you are good at writing documentation, you are not. Please stop. Yes, yes, yes we need an example that will show us how something works, and then we can look at one or two examples, and that will show us how to read this new thing. All the Rails 3 validations out there, you can find five lines or ten lines on validations that will show you how to read the new validations. If you’re going to document that ever, document it! Document all of it. Because I actually had to figure out how to do in the new Rails 3 mode, how do I validate color on category, if it's the top category in a tree. In other words, only validate color if it's the root category. And none of the Rails 3 validation documentation that I could find in less than 15 minutes, in the first 15 minutes of searching, none of them documented where you put the colon if in that clause. If you are going to document it, document a few examples, and then write the exhaustive documentation. There's documentation that will show something how to read it, but then -- Avdi, I'm sure you felt this pain as well -- I need you to please, please, please write enough documentation, so that I can turn around and write new code based on what this is, that’s just not a copy of your example. AVDI: Yeah. JAMES: I definitely agree. I handle it pretty much the same way. And in a lot of cases, I'm familiar with something to the level where I can point to you which textbook it's in. CHUCK: Yeah, you can find it quickly. JOSH: So you are saying that Google skills is the best way to level up as a developer? DAVID: I honestly…  I said this a few minutes ago, and I will say it again because it's really, really valid. The difference between  a guy who's been programming for 20 years and a guy who has been programming 2, is how many ways you have forgotten how to do something. People will ask me, “How are you going to sort this date or sift this data?” And I mean, I can think of 17 different sorting algorithms. Well, okay, I can think of three, and there's 14 more that I can dig out of my long term memory, and that kind of thing. And there's tradeoffs between them. And some work really well, and some don’t, and some are really great, but they are not applicable to this situation. And that is how you level up as a developer is go learn something. Go do something crazy. Go do what we did at URUG last month up in Salt Lake, where we tried to write… get through the Ruby colons by monkey patching… and just the crowbar without making any of the tests pass, how badly did we need to lobotomize Ruby and Test::Unit, in order to make the colons pass as written originally without any of the answers filed in. And it took us till about one o'clock in the morning to get it all done. Why would you do that? That’s stupid. That’s crazy. That’s weird. Except, that you come back the next day to your regular work with this whole new crazy, weird insight into good programming. And also there's now this kind of weird, funky lock pick crowbar in your back pocket, that someday I might need to ship some code in a back alley and I've got this to do it now. CHUCK: Yeah, I wanna jump in here too. I've been working on my conference talk. I'm speaking at Rocky Mountain Ruby Conference in about two weeks. I've been working on this stuff with Cassandra, and I basically started building an ORM that just does basic stuff that I want it to do. I later discovered that there are a couple of ORMs out there in Ruby for Cassandra, but I'm going to keep working on mine because I keep learning new stuff. And really, you go out there and you get into something that you know nothing about and start building and working on it, and playing with it; and learning what the problems are and learning why this works this way and why you may want to do this other thing that way. And oh, there's a library out there that makes this easy. And you know, so you start to really learn some of the internals and effects of what's going on. And that kind of a challenge, I think I've leveled up a ton over the last two weeks just working on this project. And I think that’s one of those things. And I think Josh really hit it on the head when he said “practice”, because that’s really what this is. I mean, I'm not practicing anything that I'm directly going to use with any of my clients anytime soon, but it's that challenge; it’s that solving problems and practicing… learning and practicing solving problems really, and building those abstractions that makes the big difference. DAVID: Can I give you a piece of advice, Chuck? CHUCK: Sure. DAVID: When you give your talk, don’t go to the talk and say, “There are a bunch of other ORMs and here's another one. You can take mine and use it. Go have fun.” Don’t do that. Basically say, “I learned all about Cassandra by writing an ORM.” “Here's how you can write an ORM.” And then walk through the exploration of the ORM. And then basically tell people, “Yeah, here it is on GitHub. You can take it, but don’t use it. Use it as a reference manual and write your own, so that the next time you ever have to work with an ORM -- whether it's Active Record or Mongo Mapper or Data Mapper or whatever -- because you had to write one because you had to know how to chain queries together, because you had to learn how to extend the array,” in Ruby, it's really easy, but I mean because you had to work the weird edge cases on that kata, you now know a whole bunch more about how to program in real stuff; not that what you are doing isn’t real, but I mean, it’s... you know what I'm saying? That it's valuable. Don’t cheat them out of the exercise. JOSH: So that sounds cool. I wanna build on the practice thing a bit though, because I think there's two things that you level up on when you practice; one is knowledge and information and skills, but the other is habits. And one of the quotes people like to toss around, is Kent Beck talking about being a great programmer and he says something in the order of, “I'm not a great programmer; I'm a pretty good programmer with really great habits." DAVID: Nice. JOSH: And having spent the last four years or so working at Pivotal, I know that so much of productivity and performance are just related to following good habits rather than bad habits. CHUCK: Right. DAVID: So I'm going to be that guy. Can we reduce programming and good programming to just a set of good habits, that we can just say, “Well, just do it this way: Always write your tests first and down the road you go.” JAMES: No, I don’t think you can. And I was actually thinking about this earlier when you guys were talking about Google. There are definitely two different people that use Google. For example, I will usually know where I'm going or what reference I'm looking for, and I´ll post something out of it and then I´ll modify it to fit what I'm currently doing. And that's the difference between me, and there's another class of people that I see use Google, and they Google it and they copy and paste that solution -- and that’s it. And that’s where their skill level ends. And they are not able to say, “Oh yeah, that’s kind of like what I'm doing, but it's not exactly what I'm doing.” And they are not able to rearrange that code -- remold it to fit in that section. AVDI: I think there's a fine line between “habit” and “instinct.” I think maybe it fits in a bit with what you are saying, James. Habit will sometimes help you, especially it will help you getting through some of the more tedious aspects of work, but instinct is when you see a problem ,and some sub process you’ve just internalized in your mind, spots a pattern and decides how to go forward. Whereas habit is you are in the habit of using singletons everywhere, and so you just do it some more. It's a subtle, but I think a very important difference. DAVID: I thank you for saying that, Avdi. My comment about you need to forget 5 ways to write this sorting algorithm, I would define… this is just in the David Brady name space; I'm not saying everybody else have to take this definition, but I define instinct to be the gestalt of your forgotten habits. Somebody says, “how do we solve this problem?” and your instinct leads you in a certain direction. And it's because you've forgotten 5 different ways to solve this problem. And one of them is really appropriate for this particular solution, but it might not be the first thing that comes to mind. CHUCK: One thing that really stuck out to me, because I just listened to Lonestar Ruby conference version or episode yesterday, and somebody said something about, “I'm a programmer, so I pattern match.” And James stepped in and said, “You are a human, so you pattern match.” And really, that's what we are talking about there with the instinct, is that we are matching up something with what we've experienced. And so we are recognizing a pattern in what we are dealing with. And you know, since we are matching that up, we can then match the solution up -- or at least match something up and then adapt it. And with that habit, you are not making any choice at all; you are just implementing a pattern over and over and over, without paying any attention to whether or not the right answer. DAVID: Well, maybe. It’s kind of like, “Foolish consistency is the hobgoblin of little minds.” I heard an even better version of that recently, which is, “The only truly consistent people are dead.” The “test first” I think is a brilliant habit. I think everybody should be in it. I think you'll write better code, I think you'll write more modular code, it will be more testable, yada, yada, yada. I'm preaching the choir.  But if you sit down and you write… everybody I know that hates Cucumber, writes really lousy Cucumber specs. [Laughter] They write Cucumber specs that say, “I go to this page, I look for this spot, I click for clink on this exact link, which has this exact test.” Their top level feature is a thousand lines long, when their top level feature should be a user story that basically says, “When I add an item to my… when I put an item to my cart, then it should be in my cart.” And that's the whole feature. AVDI: You  have to constantly be mindful of the reason for your habits. DAVID: Yes. And I just realized I went off on  a total Cucumber tangent. So I'm just going to stop there. AVDI: I wanna throw something out. And I'm not sure if there's a good transition from that to this, but there's something that’s been on my mind lately… DAVID: Okay, engage the clutch. [Chuckles] We are going to switch gears. AVDI: [Chuckles] …with regard to this topic of improving as a developer, and that’s the concept of confessional. And where that comes from  is realizing that I think a huge part of improving as a programmer -- or improving as anything, really --  is the ability to introspect, and the ability to honestly evaluate the mistake that you've made, particularly. And I just think it's incredibly important… we do this a little bit in projects in the form of agile retrospective sometimes, but to sort of look back at your history and say, “What are the mistakes that I seem to make over and over and over again?” Like you know, I personally have a bad habit, or I think I'm getting better at it, but in past, I've really over architected things in my mind. I've spent way too much time thinking, “Oh, I'm going to completely generalize this and completely abstract it to a system that can be… that can be adapted to any possible situation.” And that was sort of a consistent sin of mine. And sort of realizing that was a big step forward. So I don’t know. I wanna get you guys’ thoughts on that. JOSH: So there is something called the Dunning Kruger effect, which is in the realm of meta cognitive awareness. And I think the best way of phrasing it is what Bertrand Russell, said which was, “What’s wrong with the world is that the stupid are cocksure, and the intelligent are full of doubt.” JAMES: He does sound kind of cocksure in that [inaudible]. [Laughter] That joke is from Lonestar. It's not mine. JOSH: [Chuckles] CHUCK: Can we talk about cocksure in my clean podcast? JOSH: It's Bertrand Russell. You can always talk about him. [Chuckles] CHUCK: Okay. JOSH: I think what Avdi was saying is spot on; that you need a certain level of self-awareness about your own ability level to know that you are not as good as you could be, and that you wanna level up. DAVID: Yeah. JAMES: I totally agree with that. I mean, if you look back at code you wrote 6 months ago, and it doesn’t bother you in some way, then that's probably a warning sign. DAVID: That are not learning, yeah. JAMES: Right. I mean, obviously you do really go forward… I said in my Lonestar keynote that, “We go forward with the best information we have  at any given time.” And it's all subject to revision, because,  “Oh yeah, I was doing it this way because…”  and I had a reason. But then a lot of times, you'll get down the road and you will be like, “Yeah, that’s nice James, but actually due to certain changes, that reason hasn’t applied for years now, and you can go ahead and let it go.” And that’s right. That's true. You get to a point where you are like, “Oh yeah, the reason I had for doing that doesn’t really matter anymore.” DAVID: Yeah, why do we chop the ends off the pot roast? JAMES: Right, exactly. DAVID: Because it wouldn’t fit in grandmother’s pan, yeah. JAMES: Right. So you kind of have to constantly be checking yourself out. I definitely do that. I mean, and all the time we make mistakes in all kinds of form, I made a huge mistake today in just that some of these awesome piece of the site that wasn’t ready to be seen, and I thought it would be okay. And realizing now after the way it all went down, that their reaction to it was very bad -- and that was my fault for letting them see that when it wasn’t ready. And ironically, everything they listed is trivial; move this button here… stuff that we do in the final cleanup phases of a site. And I was much focused on the overall picture and the core being solid. So that I can [inaudible] those little things, you know? And it's lesson learned, and I don’t need to make that mistake again. But yeah, you always need to be measuring and introspecting, and saying, “Am I improving as a programmer?” I think that’s very true. CHUCK: I wanna jump in here because you kind of touched on another thing that I've been thinking about. You had these situations where you put something out that wasn’t quite ready. And that’s not necessarily a coding mistake. It’s a mistake, but it is not a coding mistake, right? And so I mean, how many of these things that make us better developers have nothing to do with our code? I mean, for example, if I'm working on a team, if I'm not a good communicator, I have a problem; and it has nothing to do with my ability to program. It has everything to do with my ability to interact with my team mates. Or if I'm a jerk, or if I smell bad or if I have some of these other problems, it affects my ability on the team. And are there other abilities or qualities of a programmer or developer that make them a better developer that aren’t directly related to their code? JOSH: Well, of course. And one of the things that Rob Mee, the founder of Pivotal Labs, talks about in hiring is that the number one quality that they select for Pivotal is empathy. DAVID: Interesting. JAMES: That’s very cool. JOSH: That’s because at Pivotal, you spend all day pair programming all the time. And if you don’t have some ability to understand that your actions affect your pair, and how they might do that, you need empathy for that. If you don’t have that, you're not going to be successful in that environment DAVID: If any Pivots are listening, I feel so great about hearing that. I just want you to know that. JOSH: [Chuckles] JAMES: [Chuckles] That’s awesome. I'm so glad Chuck brought this up, because one of the questions -- and I think it's a great question. We probably ought to go around the horn on it -- but we took this topic off of our user suggestions. And one of the questions in there was, “If you can only give a developer a few pieces of advice, what would you give them?” And if I had to pick those, I'm sure I would have a few things to say about programming. We've already been talking about that a lot, but definitely items that would make my list would be, “become a better communicator.” And that I think it's because we often forget this, but people usually say things like, “Oh I work with machines, not humans.” And if you are a programmer and you think you work with machines, then you don’t understand programming. Because you are building software for humans. And if you can't communicate with humans -- even if you can't communicate with other programmers -- then you are not there. And I think some of the things I did that really helps me as a programmer is I wrote a book, and learned how to go through that process; or I have given several speeches conferences, which is very difficult for  me. It takes a lot of time and preparation to say what I wanna say and learn enough to be able to cover a topic, and not feel like I'm going to get up there and sound like an idiot or something like that. And in doing those things, I'm learning about how we teach people, or why people think the things they think or stuff like that. I think that’s very valuable. And the other thing I would put on the list is, “learn from other fields.” Like I really enjoy studying like how the  human brain works, and problems that it commonly runs into. And I find that that’s all totally applicable to my programming every day; that we get in these brain loops where we can’t see past, and that affects our programming. The earlier sample of someone seeing a site that’s not finished, they see a button in a wrong place and they think, “Oh my god, this is a four alarm crisis.” And you are like, it's a button. It’s a copy and paste, and it goes where I want. It's not a big deal. These things that we're programmed to see that as as false. CHUCK: Yeah, in fact, let’s go around the horn and answer that, because I think we all offer a little bit different perspective, and I think there’s some value there. So we'll have Avdi go next and give us just two or three pieces of advice for us to get better as programmers. AVDI: Oh boy, just two or three. CHUCK: Yeah, that’s all. AVDI: [Chuckles] The big one is practice. I mean, if you wanna be good at something, do it. Do it a lot; do it in your free time,  do it for work. Actually, getting paid to do it is… it isn’t just a necessity; it’s also a vital part of understanding, sort of the practical aspect of getting stuff done on time, as opposed to just playing around. And read, obviously. I don’t know if I should just list off books because there's a long list, but read the classics, read Code Complete, read The Pragmatic Programmer, read the Practice of Programming. And work with other people, and read their code. I guess that’s the third thing is put yourself in positions where you’re going to see other people coding or see other people’s code. CHUCK: All right. That’s great advice. I'm a little curious, because practice keeps coming up, so I'm going to tangent just for a second. What ways do you guys practice? Is it just working on personal projects or do you other code katas or code challenges? DAVID: Actually Chuck, if you wanna let me go around the horn next, I'm going to address that exact thing. CHUCK: Okay, go ahead Dave. DAVID: Okay. So the short version is, “Never stop playing, never stop learning and never stop failing -- and never stop until you succeed.” And to expand those out, the playing means, yeah if you just program from 8 to 5 and then go home and don’t program, you are going to get left behind by the programmers who go home who stay up all night hacking and thinking about algorithms. I'm sorry but it's a fact of life, that people who love it and just immerse themselves in it are going to do better at it. There's two specific bits of brain science that have been brought to my attention; one in the past year and one in the past week, and that is, I recommended Learned Optimism before as a pick. If you fail, get back up and try again. Never stop failing. And don’t be afraid to fail because if you… do some weird ass thing where you decide to do a sort, but you are going to sort by random, but you are going to figure out how to see the random number generator, so that the sort still works. Try and figure that out. Try to find some crazy way to do it. Why do that? You are going to fail a lot. It's going to be stupid when you are done, but you would have learned a whole bunch from it. And that’s what will make you better is giving yourself the freedom to fail, to explore. If you are not free to fail, you are not free to be creative, and to brain storm, and to grow. And so that’s failing. And if you have problem with failure, if you are so focused on, “I got to ship, I got to ship, I got to ship,” that you can't do anything any other way than the way you've always done it, please do yourself a favor and go read Learned Optimism. The bit about, “Don’t stop until you find success,” and this is related to play, because when you play, the pressure to ship something perfect is off. You can be playing, and suddenly discover something that, “Oh, wow look at that. That actually works.” You pull out a book like Hackers Delight that will show you all the different ways to do bitwise flip-flops and bitwise ORs or how to do addition and division using bit shifting and those kind of games, and you discover these weird, weird things, and you  can only discover them by playing and not having a directed goal that you are trying to get to. And the last bit about success is this is the reason brain science... MIT discovered that you do not learn from failure -- at least not at the neuronal brain wiring level. And this is the beautiful thing in the human brain; if you screw up, when you are trying to do something and you screw it up, your brain says, “Oh, that didn’t work. Yeah, whatever. Put it in the Hippocampus; store it in long term memory, we'll remember this as hard one experience, but we're not actually going to rewire anything.” But if you do something and you succeed, even it's by accident, because you were playing, and you stumbled across it, the brain goes, “Oh wow, look at this! [unintelligible] for that!” And your neuron suddenly they change. You actually form new synapses based around that bit of success. That is why you have to play. That is why you have to immerse yourself. That is why you have to go do weird ass things, like trying to make the colons pass by breaking Test::Unit, instead of actually making the two colons pass. That is why you have to explore and brainstorm, and why it's okay to not remember the entire API  of a given thing, because you are going to go out there and explore and do… So yeah, that’s my advice. Never stop playing, never stop learning, never stop failing, and never stop succeeding. Chuck, does that answer the specific concerns that you had? CHUCK: Yeah. To a certain degree. JAMES: I thought it was interesting that just to side track here real quick and then we'll actually let Josh go. I usually like to cut Josh off, if nobody’s noticed that yet. I think we are keeping score. Some interested reader can just send that in. CHUCK: You didn’t cut him off at the beginning of the podcast. If not in front of everyone else. JAMES: That's a good point. I've shoved him, under the… that’s right. JOSH: I'm just a punching bag. That’s okay. JAMES: [Chuckles] That’s right. Anyways, I was going to say about the practicing thing, I thought it was very interesting when I was listening to us earlier, when everyone was talking about, “Oh yeah, just go write your own ORM,” or something like that  to learn it. And it's funny how we seem to agree on that, and it was we were recommending something that goes pretty contrary to the well-known computer world, right? Don’t reinvent the wheel. But the point was that we weren’t using it to invent a new ORM; we were using it to fix our mind. We were using it to fix something in our mind. That like, if you go and read about the two ORMs that are available for this system, and one of them says, “has XYZ feature,” on the bullet point list, you may not even know what that is, because you may not understand how the underlying system works and why that feature would be key, until you have been in that situation and been forced up against that, and then you are like, “Oh, that's why that is so smart.” And I would extend it by saying, yes you should definitely try to write a library or something one time. And then after you do, you should go look at the others, and figure out the parts that you got right and the parts where they do better. And you are figuring out how they interacted with that system, given the same canvass you guys painted different pictures, and you have to  figure what parts of mine were superior and what parts of theirs were superior. And what did I internalize from this. So yeah, I think practice was very important. And that’s the reason I'm a massive supporter of code katas and the like -- which would be no surprise. I ran the Ruby Quiz for three years -- I'm a firm believer. Sit down someday and write a recursive parser for JSON. It's not that hard. It's something that we totally mystify. You can do it and you can definitely do it in less than 200 lines of Ruby. It's just not that hard. So you need to do those things, to learn how something like that works. And now back to our previously scheduled program and Josh’s answer. JOSH: [Chuckles] Okay, so I think the number one thing I’d say for learning skills around being a programmer is to pair program. I've talked about pair programming a lot, and I think it's a really great way to transmit information. And there's so much that can be uncovered just sitting side by side with someone or across the table, if you are lucky enough to have a good setup. But just having that back and forth, where somebody is watching what you are doing, and when two people are pairing together and they’ve gotten used to each other and they’ve developed a little trust, you can almost read each other’s minds after a while, and you can see how other people think through problems. And that’s really great when you get to that point, because suddenly you have something to contrast to your own thinking. So I could talk about pair programming a lot. I´ll just leave that out there as a really good technique for practicing and learning skills. AVDI: I totally agree. JOSH: The other thing I´ll say kind of the opposite end of the spectrum, is care about something. That most of the most awesome programming that I've seen, has been in service of solving a problem that the programmer really cared about. JAMES: That’s a great answer. DAVID: Yes. CHUCK: In fact, that's something that you see not just in coding, but in a lot of other things. And Dave actually touched on that a little bit, saying that guys who go home and do it are going to go ahead because they care. And you know, there are a lot of people out there that I've talked to, that just hates their jobs and hate their life and hate whatever. And that’s exactly it, is they wind up spending all their time doing something that they hate -- that they don’t care about. And they go home and they do the thing that they care about. And if you can apply that to your coding, even if coding isn’t your deep passion, but maybe some humanitarian effort or something is, so you can basically become a better programmer by channeling that passion through programming, you become better that way. JOSH: I absolutely agree. It doesn’t have to be all noble stuff like that. Some of the more interesting stuff that I learned early on, was figuring out how to prank people. DAVID: [Chuckles] JOSH: Working in Smalltalk, building a two button dialog confirmation box that would move out of the way whenever you tried to click the okay button. DAVID: [Chuckles] JOSH: I really cared about pranking this guy, and I learned a lot of stuff about how event handling works in Smalltalk. So it doesn’t have to be something noble and outstanding and going to change the world; just find something that you care about, that is going to motivate you to create something awesome. DAVID: There's a beautiful piece of advice that I was given when I was working at a video game company. I was having a really bad day, and one of my coworkers came by… and rewriting a video game wasn’t a very good one, but it was honest to goodness, a video game. And he saw that I was very frustrated, I was very upset, I was writing some kind of tourettsy code. And he stopped me and he said, “Dude, if you are not having fun, you are doing it wrong.” And I realized he wasn’t talking about video games or video game program; he was talking about programming -- the same exact thing. You get into writing a database mapper, and you might think it's boring, but if you are passionate about that, it's fun to write a cacher around the SQL database; trying to figure out how to take an object oriented… that’s the impedance mismatch problem; that's really hard. I've got this relational database that’s very formalistic. I've got this object model that's very hermeneutic, how do I make them talk to each other  effectively and efficiently under most conditions? That's interesting. That's fun. And if you think it's boring, work on something else. Find something that is interesting and fun. JAMES: It's true. And you wouldn’t believe how sometimes the strangest things can matter. I was working in a programming contest one time with a bunch of guys and somebody commented about how we write totally different code in programming contents than we do in our day jobs, for what we get paid money to do -- which is totally right. I mean, I said before, I never need my algorithm knowledge or rarely, in my web programming job. And that’s true, but I need it all the time when I'm programming in programming contests, of course. And somebody made a comment about, yeah, we never put in a comment explaining something or something like that. So it was a long contest, it all wind down, really kind of burn it out. And I took a few minutes to write a stupid script that went and parsed this Firefly quotes website, and then I made  a keyboard where anytime in the code, I can just hit a combination and it will dump a firefly quote in right where I was in the comments, and it will just print out as a comment. So I start littering the code base with Firefly quotes and comments. And it's hilarious. I mean, no practical value whatsoever. It was easy use or I guess we should say “abuse” of my skills. But it really had an effect on morale, that people are reading through it and they give me so much crap with all the Firefly quotes that were stuck in places and stuff. DAVID: And you were motivated, your team gelled, everybody laughed, there was fun to be had. Go back to the part where you said there was no practical value; there was no practical value predictable from that exercise. It wasn’t until you played and discovered. JOSH: Okay. I got one last thing, and that's just in the domain of problem set that you could tackle to level up. And I think that writing a language interpreter or a virtual machine, is going to get you more bang for your buck, in terms of the kind of things that you have to learn than pretty much anything else. DAVID: I call that exact task in programming, I refer that to it as, “building your first light saber.” JOSH: Yeah, [Chuckles] that’s basically it. When you got to the point where you can write a language runtime, you are now a master. JAMES: I agree with that. And just to add to that, I think that will scare a lot of people off in that, you look at that and you think, “Wow, that’s a really scary, hard task.” And it's actually not as ridiculously hard as it sounds. And in fact, there's easy ways to ease into it. For example, I was talking about programming contest before, one of the ones I usually do is the ICFP programming contest, which is the the International Conference for Functional Programming. They let everybody compete, and you can learn lots of interesting stuff. The problems are usually fairly good size. It's easily like 12-15 pages printed and you read it, and you get 72 hours to work on it, etc. If you go back, I can't remember what year it is, but if you go to the ICFP site and go backwards, they always have all the years on there. And if you look back, there was one year that it was an ant problem, to program a colony of ants moving around, and fighting against each other. And the simulator is effectively a virtual machine, and the way the ants communicate is the way is basically assembler. So you are going to have a good time; play a game and learn stuff at the same time. CHUCK: Yeah, awesome. I'm going to go ahead and give my advice, and then we'll probably going to have to get into the picks because I think we're already going to go over. So my advice first off, is just don’t undersell what you can do. I think a lot of people think, “Well, I need to level up. I need to level up.” And they forget that there are a lot of things that they can do, that they do well. And if you are confident with what you can do, then that kind of sets the stage for the things that you want to learn. And so, just getting a clear idea of where you are at and being confident at what you can do. And the other thing is… and this goes along with what Josh said, the second idea that I have is just tackle the hard problems. Just pick something that you really don’t know anything about, and then go learn about it, figure it out and program against it. And finally, the last thing is that go find the developers that are kind of few levels ahead of you, and get to know them. Because I think you'll be surprised both at what they have to offer, and you´ll also be surprised at where they are at in some of the areas and some of the things that you kind of idealize somebody until you get to know them, and then you start to figure out where some of their problems are. So you know, that’s kind of where I think… as I've gotten there, I get a better idea of where you are at. I don’t think that you are geniuses that can do anything, but I know that you really are good at some things. JAMES: Chuck, I can choke you with the force from here. CHUCK: [Chuckles] I'm a little worried about that actually, James. So anyway, let’s go ahead and jump in to the picks, unless there was something else somebody wants to jump in and share real quick. JOSH: Do you want to talk about the book club before the picks or after the picks? JAMES: During the picks. I´ll cover it. JOSH: Okay, great. CHUCK: Yeah, I was going to bring it up at the very end, but if somebody brought it up before hand, we're just going to talk about that. JOSH: Okay, we'll let James do it then. CHUCK: Okay. So the picks again, really briefly, are just things that we liked or have found useful in what we are doing. They can be programming or not programming related, and so I will just go ahead and let James go first since he has some idea he wants to talk about. JAMES: Okay, so I was going to say for my pick this week, I'm sure this is going to come off as cheesy, but I realized how really important it is to me. And I got to recommend the Pragmatic Programmers. And they had a sale last week, so I realized that this recommendation is a little late, sorry. But they had a sale last week; it was like 40% off I think. And I went back, and I saw Avdi and I discussing like we've gone so far down the rabbit hole. I mean they basically are like our crack dealers at this point, and they need to start putting checkmarks on which books we've bought, because we have so many of them. Like, we go into that wall of books and it’s like, “Yeah, I got that one, that one.” You know, and I used to read a ton of Ruby books – and I mean, a ton. Like i would say maybe two years ago, if you ask me about any Ruby book that was released at that time, I have most likely read it. And I kind of got burned down on them for  a while. I think I overdid it myself. There wasn’t anything wrong  with the books, but I kind of got burned down on them for a while, and I went and studied other things I've talked about before, like how the brain works and stuff like that, and communication and those kind of things, that help me get to be a better programmer. And then the other thing I'm going to recommend is, it wasn’t until I was at Lonestar just last weekend, that I really got back into reading Ruby stuff. And I definitely have my fellow Avdi Grimm to thank for that, because I went and saw his Exceptional Ruby talk at Lonestar. And if you haven’t seen that, you need to go see it right now. I mean just look up where Avdi is going to be. I think he'd be at Ruby Midwest, go ahead and get flight, get your ticket and go. Because he does a great job. He takes like a seemingly boring topic, like exceptions in Ruby, and uses them to teach you just some amazingly great Ruby, that people don’t know about or don’t see very often. I learn things sitting in Avdi’s talk. It was great. And he has other things; his blog, which he has been posting to all the time now. And I learned something new from his blog today, so I can't stress enough. And so because of that, we've been talking about it, and we're going to start up a Ruby Rogues book Club and try to see if that going, where we discuss a book on the show very often. And we are going to start with Avdi’s Exceptional Ruby book, which is a great read. It's like a 90-page PDF, so it flies by and I dare you to go read that took and not learn three amazing things about Ruby you never do. So it's a great book, and we're going to read it and discus it on the show on September 8th. So if you wanna follow along, you can pick it up and read. So I'm recommending the Pragmatic Programmer’s, Avdi Grimm in every form, and Exceptional Ruby. DAVID: Should we have the readers that read Exceptional Ruby in advance, have them post questions and comments to the show before we do the show? CHUCK: Yeah, absolutely. JAMES: That's a good idea. That would be good. DAVID: So it's like a global book club. If you wanna be in the book club, get the book. CHUCK: Yeah. In fact, I´ll go ahead and I´ll find a way of putting something out there, so that people have a way of contributing to that. I'm not sure what form that will take, but I´ll put a link to it at the show notes as soon as I have it up. And that way, we can definitely tackle some of those questions as you are reading the book. DAVID: Yeah. CHUCK: All right, well since Avdi was so… I don’t know what the word is. He was “picked,” I guess. [Chuckles] AVDI: [Chuckles] James, first of all, thank you so much for all the kind words. DAVID: “Enshrined,” is I think the word we are looking for there. AVDI: I had some other picks in minds, but I do wanna say, I tried to write and speak about the things… in the kind of style that really inspired me in learning about this stuff. And James, I don’t want this to turn into this giant disgusting love fest, but James’ blog has always been one of the best ones out there on Ruby, because it does the exact kind of thing that I like, which is dive really deeply into a topic. And like I was telling him the other day, I still refer back to his article on Strut. Strut in the Ruby standard library, which is this is just like everything you ever… didn’t realize that you really wanted to know  about Struts, and look that up. So I guess that's become one of my picks for today. The other thing is basically three tightly related things. I've been doing some JavaScript unit testing lately, jumping into doing some Jasmine unit testing. And jasmine is great. That itself is not my pick. You probably already know about Jasmine if you have done any unit testing of JavaScript. But I've been sort of discovering the ecosystem around it, and some handy things related to it. So there's something called Jasmine jQuery, which adds some nice assertions for jQuery stuff, but it also… I think even more usefully adds very handy and very simple way to load fixtures, so you can just have a file full of HTML, that you  can load up into your Jasmine spec using that. There's a thing called Sinon.js, which is a really nice mocking and stubbing and test library for JavaScript. And then there's something called jasmine-sinon, which just helps integrates that with jasmine. And  you put it all together, and you have some really nice unit test support through your JavaScript. And so I've been really enjoying learning all about that lately. CHUCK: All right, that’s awesome. I've been looking for stuff like that. So, definitely cool. Go ahead, Josh. JOSH: Okay. Let’s see. I know this has been talked around a bit lately, or a lot but I wanna put in a pick for Travis CI. Everyone has been talking a lot in the last year about Hudson -- which is now Jenkins -- as a better CI platform than cruise control, which I got to agree with that. But Travis is a project that is creating a Ruby… to CI platform, that just deals with multiple versions of Ruby, and installing gems for you and can deal with RVM setups. And all these good stuff. So it makes just running your application on CI really simple. They have a public site, where you can have your open source projects get run on CI. And the entire project is open source, so you can take it and deploy it on your own internal server, and have all of your private internal projects run there. That’s my pick. I have to put in a disclaimer that I haven't really done much with Travis, except just play around with it, so I can't speak from experience, but some people I really respect have been getting into it.  So, I'm just going to jump on the band wagon that way. CHUCK: All right, cool. JOSH: And then my other pick, which sort of comes out of the better developer conversation; my pick is doing Yoga. And I think that one of the things that makes me a better developer, and actually better at most of the things I do in my life is that I do yoga. And yoga at some level, is best exercise. But most forms of exercise, if you really get into them, become something more than just physical activity. So Yoga is like that as well. I think that it's really important for developers who spend so much time sitting in front of the keyboard all day long, to balance that with some kind of physical activity. And especially, a physical activity that engages you in a lot of different levels, and helps integrate you intellectually, and physically, and emotionally. So Yoga, I've been doing yoga for 20 years or something like that. It's been really important balancing part of my life. It's actually really great to have about some physical reserves to draw on when you got to be up like programming or you got to find… you are sitting on a chair all day, and you need something to keep you back from freaking out – which if you are not 22 years old can be an issue. So I just wanna put a plug for yoga. If you are trying to get in to yoga and you starting out, I would say, start with the Iyengar School of Yoga because it's the best about teaching new alignment and form, and is more accessible to beginners. If you can't find a good Iyengar class around somewhere, a typical Hathor class is pretty good. I’d stay away from Beacon Yoga at all, because I don’t really think it's Yoga. But that's my personal opinion. But I’d also stay away from Power Yoga or Strong Yoga, because it's not really for beginners. You are more likely to injure yourself approaching things at that level. So that’s my pick. CHUCK: All right. Highlighting one other difference between 20-year old programmers and 40-year old programmers. JOSH: [Chuckles] Right. They think of us siting on a chair all day. DAVID: When I was 25, I was a super hero and my super power was I could go for 36 hours without sleep, one night a week with no ill effects. I mean, just pick a night and pull and all-nighter, no problem. And I lost that super power right about by 30th birthday. And now, it's a struggle. Like I started to work on a standing desk and I made a flexible workstation, so that I can just sit my laptop from the shelf down to the desk, and then I can go back up and stand up and type with the thing, in order to do that just because trying to extend my time with a standing desk is difficult. JAMES: I used to be able to drink Dr. Pepper and just keep myself basically going indefinitely. But as of this week, I'm actually going through the giving it up. So if I was extra cranky on this podcast, there you go. That’s why. DAVID: [Chuckles] JOSH: No more than crankier as usual, James. JAMES: Oh, good. Good. CHUCK: All right, David what are your picks? DAVID: So I already started my picks which was I got a standing desk. I'm going to do the same thing as James, so I'm going to pick something old and something new. I'm going pick two picks real quick, because we are over time, but they are both from my top ten books of all-time list. And the reason I'm doing this is because we have a new comer to the list. So probably, in the top three books of all time that I've ever loved and read, is Extreme Programming Explained by Kent Beck. It will not hurt you to go back and re-read that took, especially when he gets in to some of the more… some of the principles that we've kind of forgotten about, like how XP or Agile, I guess, Agile programming takes courage. You have to be able to standup and say, “This is the way this needs to be.” And that book is in my top three of all time books. I think everybody should read it, or all programmers anyway should read it. And the newcomer, it's going to come in probably around 9 or 10. It's not going to be at the top of the programming book list, or of my all-time list, maybe because it's kind of edgy for me as far as skill set, but it's called Business Model Generation. And it is written by 472 people. The two main authors are Alexander Osterwalder and I´ll screw-up his name but Yves Pigneur, is the other author. And they had 470 co-authors. And it's a book about business models. About how a company can have a value proposition, what it's key activities and resources and partners are, and those form what's called the cost structure. And then what your customer segments are, what costumer retentions you were going to use to retain those customers, and those form the revenue streams for the company. And they lay those 8-9 principles out on what they call canvas, and then they break down just about the rest of the book, they spend everything from big Telco companies, down to single person start up bootstrap. Everything from Amazon.com down to the local pottery barn. And they basically say, “Here's how this fits into the business model.” “And this is why this business model works, and this is why this completely different business model also works.” And if you violate the rules, you take something like Amazon, which competes entirely on efficiency and economy of scale, if you try to turn them into providing the absolute best quality product in the universe, they will fail because that will run counter to their economies of scale. But if you go down to the local boutique, and this guy is making hand-crafted pottery, if you try to scale him, it will fail because he'll have to make crappier pottery and he's no longer offering his primary business thing. Business Model Generation breaks down how businesses work. And Brian tweeted a couple of weeks ago. He says, “I don’t get this whole concept of startup. Why don’t we just call them businesses?” And the reason why we don’t call them business, is that because they don’t make money. And they don’t make money because they are not businesses. If you ever had that question, and you wanna know how do I start a business, you need, need, need to go get Business Model Generation. It's the best business book I've ever read. CHUCK: Yeah, I've heard rumors that it's based loosely on “The Four Steps to the Epiphany” by Steven Blank. DAVID: I've read most of Steven Blank’s blog, which is basically got bundled up into The Four Steps to the Epiphany, and I don’t think they are related at all. I think they are compatible, but I don’t… it's definitely not a copy of that at all. Not at all. They are absolutely compatible with each other. They are both all about understanding your market, but The Four Steps to the Epiphany is all about talk to your customer, talk to your customer, understand your customer, understand your customer. And these guys do talk about getting away from saying, “Well, what can we do… what product can we make for the customer?” And turning that into, “What problem does the customer have and what can we do about it?” They do that. They are very compatible, but I'm not getting a Four Steps vibe out of this book at all. I don’t think you can read one and claim that you understand the other. CHUCK: Okay, sounds good. All right, so I've got a couple of picks here really quick. I wanna list a few of the places where you can go to kind of do some of the code challenges. We've had Ruby Quiz brought up, and that’s definitely a great one. Some of the first ones or really the ones that I've played with are ones that James wrote and they are just awesome. Some of them are great mind benders, and just fun to figure out. So that’s one. Another one is Project Euler. And those are all math problems. Anyway, I've done like 30 of those, and those are kind of interesting. Some of them are really, really easy, and some of them were really kind of mind bending tricky; and some of them were easier, like when you get a fixnum that can get more or less as big as you need it to, whereas they are trickier in other languages where you actually have to allocate LongInt to manage that large of a number or split things out, so you can handle it all. Anyway, so it gets kind of interesting there, but anyway, so those are two that I would pick. And one other things that I've run across and I'm actually going to be making a video on for teachmetocode.com this afternoon or this evening, is Active Model. And I'm bringing it up because I didn’t really understand what it was until I needed it. And what it is it is all of the nice stuff that you are used to in Active Record, like validations and observers… and I can't even remember all of it. There's a naming module, so that you can plug your Ruby class into form for and actually have it work, and just stuff like that. So anyway, you include the modules that you need to give you the functionality that you want. There's callbacks, so like before save, before create and all that stuff. And it's just a really nice way of adding the functionality that you need to a non-SQL relational database model, and still having that work. So I've been adding that into my project that I'm working on with Cassandra, so that I can do the model validations, and pass the validation errors back out to the page and have them show up in the form, without actually having to think about it. So really, really handy thing. So that’s another recommendation that I'm going to make. And with that, I'm going to go ahead and cue the music and wrap things up. First off, I wanna thank our panel. In no particular order again, we have Avdi Grimm. AVDI: Happy hacking! CHUCK: Josh Susser. JOSH: That’s all, folks. CHUCK: David Brady. DAVID: I love you all. CHUCK: [Chuckles] James Edward Gray. JAMES: I love you guys, too. Big group hug! Bye! DAVID: Yay! CHUCK: And I'm Charles Max Wood. And just to remind you, we are here every week. You can get the show notes at rubyrogues.com. You can also find us in iTunes. And we do appreciate it if you will leave us a review. Our audience has been growing pretty well. And I really, really appreciate all of the positive and constructive feedback that we've gotten. There have been a few people that point stuff out, so I made a few changes. And a few other people have just told us how much they enjoy it, and I really like getting that too. So thank you all for all of that. You can follow the podcast on Twitter @rubyrogues. And finally, we are doing the book review discussion thing of September 8th is when we will be doing that, so it will probably be out on the 9th or 10th. So go check out Avdi’s book. You can get it at exceptionalruby.com. I think you can get it off from Pragmatic Programmers’ website. And yeah, it's called Exceptional Ruby, and we'll be talking about it here in like three weeks. So that’s it. thank you all and we'll catch you next week! DAVID: Bye!

Sign up for the Newsletter

Join our newsletter and get updates in your inbox. We won’t spam you and we respect your privacy.