02:42 - Evaluating Yourself 03:13 - Figuring Out Your Momentum Life Balance

• NoSQL
• Tournament Chess 08:09 - Learning New Things 09:42 - How To Learn
• James Edward Gray: Are We Teaching the Best Things? 10:20 - Other Types of Thinking
• Social Skills
• Pair Programming 12:57 - “Thinking Like a Computer”
• Measuring Success with Numbers 19:56 - Measuring Progress
• James Edward Gray Youtube Channel
• MUDs
• Shipping
• Barriers
• Saron’s Blog - Archives 27:14 - Areas of Interest
• Intrinsic Motivation
• Rust
  • Rust IRC Channel 29:33 - Other Metrics or Stats for Evaluation
• Typing Tutor
• Dreyfus Model of Skill Acquisition
• User Story
• Programming Pearls (2nd Edition) by Jon Bentley 34:22 - Getting Over Self-Doubt
• Social Coding
• Steve Klabnik
• Illusory Superiority 38:51 - Feedback
• Qualitative Feedback
• RSpec
• Binary Tree
• Inject 42:54 - Measuring Perspective
• Social Skills 47:27 - The Rogues Evaluate Themselves
• Swift
• Riak
  • 139 RR - Riak with Sean Cribbs and Bryce Kerley
• Verse
• Kindle 53:39 - Evaluating Non-Technical Skills
• Communication
• Keeping Journals
• zenspider
  • Ryan Davis

Book Club

Refactoring: Ruby Edition: Ruby Edition (Addison-Wesley Professional Ruby Series) by Jay Fields, Shane Harvie, Martin Fowler, and Kent Beck

Refactoring in Ruby by William C. Wake and Kevin Rutherford

Next Week

Extreme Deployment with Badri Janakiraman and Florian Motlik

Transcript

JAMES:  I’ve been sweating these questions since they arrived. CHUCK:  Good questions. SARON:  [Chuckles] Oh. Are they hard? JAMES:  Scribbling answers, crossing them out, scribbling answers, crossing them out.[This episode is sponsored by Rackspace. Are you looking for a place to host your latest creation? Want terrific support, high performance all backed by the largest open source cloud? What if you could try it for free? Try out Rackspace at RubyRogues.com/Rackspace and get a $300 credit over six months. That’s $50 per month at RubyRogues.com/Rackspace.]**[This episode is sponsored by Codeship.io. Don’t you wish you could simply deploy your code every time your tests pass? Wouldn’t it be nice if it were tied into a nice continuous integration system? That’s Codeship. They run your code. If all your tests pass, they deploy your code automatically. For fuss-free continuous delivery, check them out at Codeship.io, continuous delivery made simple.]**[This episode is sponsored by Hired.com. Every week on Hired, they run an auction where over a thousand tech companies in San Francisco, New York, and L.A. bid on Ruby developers, providing them with salary and equity upfront. The average Ruby developer gets an average of 5 to 15 introductory offers and an average salary offer of $130,000 a year. Users can either accept an offer and go right into interviewing with the company or deny them without any continuing obligations. It’s totally free for users. And when you’re hired, they also give you a $2,000 signing bonus as a thank you for using them. But if you use the Ruby Rogues link, you’ll get a $4,000 bonus instead. Finally, if you’re not looking for a job and know someone who is, you can refer them to Hired and get a $1,337 bonus if they accept a job. Go sign up at Hired.com/RubyRoguesPodcast.]**[Snap is a hosted CI and continuous delivery that is simple and intuitive. Snap’s deployment pipelines deliver fast feedback and can push healthy builds to multiple environments automatically or on demand. Snap integrates deeply with GitHub and has great support for different languages, data stores, and testing frameworks. Snap deploys your application to cloud services like Heroku, Digital Ocean, AWS, and many more. Try Snap for free. Sign up at SnapCI.com/RubyRogues.] **CHUCK:  Hey everybody and welcome to episode 171 of the Ruby Rogues Podcast. This week on our panel, we have James Edward Gray. JAMES:  Hello. CHUCK:  Avdi Grimm. AVDI:  Hello from Pennsylvania. CHUCK:  Saron Yitbarek. SARON:  Hey from New York. CHUCK:  I’m Charles Max Wood and I just want to say eval(self). SARON:  [Laughs] Very nice. JAMES:  That’s dangerous. CHUCK:  [Laughs] Yeah. So, today we’re talking about evaluating yourself. I think it’s interesting because initially when we brought the topic up, I was thinking how do I tell if I’m at the right place? But the more I thought about it, the more I got more along the lines of, we had Saron ask us or give us a bunch of discussion points and questions, and I really wound up where she wound up with her questions, asking about growing and changing and getting better. And so, is there a good place so to speak? Or is evaluating yourself really about figuring out if you got good momentum in the right direction? JAMES:  So Saron, maybe you can tell us why this topic was interesting to you. SARON:  Yeah. It’s interesting to me because my background before programming, or actually in college, was pre-med. And so, in pre-med if you don’t have at least a 3.5 GPA, you can pretty much forget about medical school. And so, I spent a lot of time evaluating myself and thinking about, “Well, how do I know I’m doing well in this class before I get the final grade?” and, “How do I make sure I’m improving consistently?” and, “How am I growing?” And when I started to learn to code, I thought a lot about those same things. Am I learning quickly enough? Am I doing well? Am I beating everyone else? Whatever those metrics were. And I found that it was a lot harder to even find the place you’re supposed to be to then see if you are there or how close you are. And it’s funny because when I talk to a lot of people starting to code, I get a lot of the same questions around, “Well, how do I know I’m doing a good job? I have no sense of where I am or where I need to be.” So, I thought it’d be a really great question and discussion point, since all of you are seasoned and more experienced of, well, how do you measure yourself and how do you know if you’re going in the right direction, and what is that direction? CHUCK:  I should have just let you start it off. [Laughter] CHUCK:  That was really good. JAMES:  Those are great questions. I don’t think I know how to answer any of them, so this is going to be so much fun. CHUCK:  Yeah, but you’re seasoned. [Chuckles] JAMES:  Right, which means I know enough to know that I don’t know how to answer those questions. CHUCK:  [Laughs] That’s so true. SARON:  Well, I [inaudible] that makes a lot of people feel better. So, that’s good. JAMES:  [Chuckles] CHUCK:   Well, it’s hard, right? Because I’ll admit, there have been points in my career where I’ve just gotten comfortable. I knew enough to be able to do my job. And I was still figuring things out when I needed to. But looking back, those weren’t my happiest times. And I was comfortable but I wasn’t necessarily in a great spot. SARON:  That’s interesting. It makes me wonder after a certain point, is it okay to be comfortable? Is the goal to always be growing? Do you switch off from the two? JAMES:  That’s a good question. CHUCK:  I have my answer. JAMES:  Go for it. CHUCK:  It’s going to make some people uncomfortable. But I think life is, people talk about life balance and stuff. And so, sometimes you’re going to sacrifice in areas like career because you have other things going on in other areas like family. And so, if you are holding steady and you’ve got other stuff going on, I think you’re doing fine. However, at the same time, technology moves so fast. Even Rails, talking about Rails now from when I got started programming in Rails seven or eight years ago, it’s a different thing. And we’re programming against a different internet. And even the tools that we’re expected to use and understand have completely changed. Back when I got started, NoSQL wasn’t really a thing. A lot of the JavaScript frontend frameworks weren’t a thing. There were web APIs but not everything had an A-… and most of the interesting sites may or may not have had one. And now it seems like that’s a thing. And so, if you’re sitting still for too long, I think you’re going to wind up being left behind. JAMES:  I think that’s a really interesting point. It makes me think of when I used to play tournament chess. And probably the main reason I don’t play a lot of tournament chess these days is everyone who plays tournament chess spends a really significant portion of time at home in their free time reading books about chess and going through games of the masters and practicing things and stuff. So, you have to almost do a certain amount of work to stay exactly where you were come the next tournament. You have to keep up with that curve, basically. And like Chuck’s talking about, computers, oh they change all the time. And someone like me who’s been in Ruby for so long and is so comfortable in Ruby, I can see the writing on the wall. We’re going through a huge period of new language growth where lots of new languages are coming up. And while I don’t think that means Ruby is dead or going away or anything like that, it does mean probably that I should be looking at some of these and figuring out why all these new languages exist and what problems they are trying to solve, and stuff like that. So, there’s that effort to keep up with that curve again. It’s the minimal amount you have to do to actually stay in the same place you were in. CHUCK:  Yeah. That’s a really good point. And it feels so overwhelming when you’ve not been involved for so long, because then you have this huge log of things that have happened that you need to be up on in order to be able to be competitive in the latest tournament or market or whatever. SARON:  It’s interesting because one of the reasons why people recommend programming is because you’re never going to get bored, precisely for the reasons that you guys stated. And I thought that was really, really exciting at first. But I’m wondering, does that ever get exhausting? JAMES:  [Chuckles] Yeah, I think so. You do always have to be learning new things and growing and perfecting. And I do this because I love that. I, given free time and a stack of books or whatever, I’ll read the nonfiction every time and try to cram more things into my brain and stuff like that. So, I really enjoy that cycle. But even me, I have periods I go through where I’m like, “Ugh, I don’t want to learn new stuff right now.” And I think that’s fine, too. You go through periods where you’re less interested in it and in those times you spend a little more time just staying where you are and refining what you know and stuff. And I think everybody experiences that a little. But if you don’t consider curling up with a good book to mean something like a textbook, you probably are not going to enjoy this as much, I think. CHUCK:  Well, there are more ways to learn than just that, right? JAMES:  Yeah, that’s totally true, yes. CHUCK:  And so, for me, curling up with a coding book, I have to be in the mood for that. But moving ahead in other ways where it’s, “Okay, I’m going to go do this online tutorial, or I’m going to go watch these videos, or listen to these talks,” or different things like that, there are better ways to do it. But I think the more interesting question, the question we’re asking, is how do you know if you’re doing enough? JAMES:  Or if you’re doing the right things? CHUCK:  Right. JAMES:  Maybe that’s a good question. That’s a really good question that I think is hard to nail down. For example, I think a lot of people focus on languages. How well do I know Ruby or whatever language? Or how many languages do I know or things like that. I’ve written about this fairly recently on my blog, but I think that’s actually one of the least interesting aspects of programming. And if I were going to measure things that are important to learn and get better at as a programmer, I would include things like how to solve problems or how to think like a computer, which means how to think algorithmically. Do this step, then this step, then this step, and we’ll be there kind of stuff. Or social skills. I would say a massive part of leveling up as a programmer is learning how to interact well with others, being able to have good conversations, understand what other people are going through, just basic things like how to apologize. Our job is hugely about people, from pair programming to building apps that people use, to interacting with stakeholders, et cetera. All that’s about people and it’s a massive part of what we do. So, I think things like social skills end up being really important to level up to. SARON:  You know, I like those skills that you mentioned a lot because those are the things that don’t change with time. Those are the things that don’t depend on what language or what framework is popular at the time because they’re just a part of you and just developing almost as a person more than anything else. And the last point that you made about it all being about people, I think that’s so easy to forget. I think there was a time where I worked on a project and it was just me and the code. I was pairing with one other person but that was pretty much it. And after I while, I forgot that we had users at the end of it. [Chuckles] Finally when we released it and got user feedback, I was like, “Oh yeah, people are using this, actual people.” And they’re at the core of everything that we do. And so, I think that the social skills get downplayed a lot when people talk about being a good developer. CHUCK:  I’m going to have to always be nice to people, huh? [Chuckles] SARON:  Yes. JAMES:  You’ll always have to play well with others. It’s so sad. SARON:  [Chuckles] JAMES:  I like what you said about how those skills don’t change. And you can see this with experienced programmers. They tend to know more languages, pick up more languages and stuff like that, because that’s not really the hard part. The hard part is learning how to solve problems and think algorithmically, right? If you can do that, sure different languages take that in different approaches, especially if you’re moving from something like a pretty OO language to a pretty functional language or something like that. There’s going to be some twists. But learning how to think like a computer, that’s the really hard part. And it doesn’t really change. SARON:  So, if we focus on that skill for a second, learning to think like a computer. What does that look like? If you were to evaluate someone who does a really good job of that, what does that mean? CHUCK:  Put a chip in the back of their head, right? JAMES:  [Laughs] Yeah, [inaudible]. SARON:  [Chuckles] That’s what I do, yeah. JAMES:  Direct connection to the matrix. It’s a good question. I’ve been trying to figure this out. It’s like in mathematics sort of, and I hate to compare computers to math because I always think that goes awry. But let’s say you have a word problem in math. A massive part of that is being able to read the word problem and realize what question is actually being asked. SARON:  Yeah. JAMES:  And then once you have a question, then you need to be able to go, “Okay, I have all these mathematical concepts. So, perhaps I could construct an equation like this, because that’s the way the problem is modeled.” And then I could apply these set of transforms that I know. And the end result is that I’ll end up at an answer, a correct answer to this problem. And it’s that series of steps, the being able to form the problem, being able to apply each successive step that moves you closer to a right answer, and then recognizing when you have a right answer. That’s thinking algorithmically, I think. And some people look at the problem and they’re just like, and I’m talking about myself here a large portion of the time, “Okay, now what?” [Chuckles] And that’s the unsuccessful side of it. So, the successful side is being able to identify and work through those steps, or even a lot of times in computers, it’s knowing that there are steps for that process and having a good idea of where you could go hunting for them, because you can’t keep all of computers in your head. There’s just too much. It’s too… CHUCK:  Speak for yourself. SARON:  [Chuckles] JAMES:  Okay, well I can’t. And so, you can’t keep all of that in your head. So, most of it is just knowing, “Yeah, I know there’s a data structure that deals primarily with this problem, or I think I’ve seen an algorithm before that people use to attack this kind of thing.” Getting that info, tuning it a bit to what you’re actually doing, and implementing it. I think that process and how well you are at being able to recognize when it’s needed, and then do what’s needed. That measures success. SARON:  That’s a great answer. I really like that. And I feel like how long it takes you probably, it’s factored in as well. So, if you do that process but it takes many hours versus five minutes, then I think that’s a sign of growth, too. CHUCK:  I think that’s true. I think mainly, well I think I lot of reasons for that basically boil down to people want people with skills. And they want people that can deliver. And I also think that that’s a good measure of practice, or a good measure of your competency at that, is how quickly I can do it. SARON:  Mmhmm. Yeah, so do you think that if you do those kinds of problems over and over again, that’s an easy way of getting better at it? CHUCK:  Yes and no. And the reason I say yes and no, I think it is in the sense that if you’re doing a lot of problems like that, you learn how to solve problems and you learn different strategies for doing it. The reason I say yes and no is because if you do the same exercise over and over again or the same type of exercise that test the same skill with the same algorithm, then you’re not going to grow as much as if you were finding ways of testing yourself that involve new problems and new things so that you have to actually really learn something in order to solve the problem. JAMES:  I think one of the things I would say about measuring; you mentioned earlier that you had to have a certain GPA. And I really liked that, because it’s a concrete number that we can all understand. How am I doing? Well, this number clears that up. This is how I’m doing, which may or may not actually be accurate in a lot of ways. But it exists. And in programming, we don’t have that. What would you substitute? Lines of code written a day? All of those are I think silly in hopefully pretty obvious ways. So, one of the things I would stress about measuring is don’t do it. [Chuckles] In some ways, avoid trying to quantify these things that are really hard to quantify as much as you can. Don’t try to bring it down to a single number that expresses, “Right now I’m a 3.1 programmer,” or something like that. I would say that I try to avoid that. Does that make sense? SARON:  It does. But then it makes me wonder, because regardless of how I evaluate myself, people are always going to evaluate me. And people are always going to say, “Oh, well she’s a great coder. He’s a great code.” And if I don’t understand how they’re making that conclusion, then I wouldn’t necessarily know how to improve myself. Does that make sense? JAMES:  Yeah. I think that makes a lot of sense. You were talking about how others perceive you as one thing and then also how can you tell if you’re making progress on some scale as another thing, right? SARON:  Exactly. Regardless of where the evaluation is coming from, I think the evaluation happens. So, if I can at least understand maybe how other people look at my code, then I can do better in their eyes, which means that I’ll get a job, or a gig, or become a better programmer and hopefully have a better career. So, how do you think about it from that perspective? AVDI:  When I worked at an office, I always made those kinds of judgments of other people based on how recently they had brought me cookies. [Laughter] JAMES:  I vote we all adopt Avdi’s system immediately. SARON:  That’s awesome. CHUCK:  [Singing] C is for cookie, that’s good enough for me. SARON:  [Laughs] AVDI:  But seriously, it’s so subjective, isn’t it? I’ve seen people evaluate other people very differently depending on what was important to them. One person might evaluate other programmers mainly on certain aspects of their code. Another one might evaluate them primarily on people skills. And I’ve seen people have very different impressions of programmers based on their subjective ways of judging. CHUCK:  One other thing I want to point out here is that along the same lines of what Saron is pointing out, I like to improve and I like to be able to say I improved X amount. The other thing is that if you’ve ever had to fire somebody, it’s a whole lot easier if you have some concrete metric that you can say, “We only have 10s around here and you’re a 2.” SARON:  Good point. JAMES:  That’s an interesting idea. So, I want to touch on a couple of these things. And I would like to separate them from each other, this idea of how others view us and how we can know if we’re making progress on some scale, because I think they’re two very different things and probably best kept as separate as possible. How others view me just scares me like you can’t imagine. People come up to me and say things to me about programming they’ve seen me do or whatever. And that’s just because I’m a very public programmer. I’m on the Ruby Rogues podcast that a lot of people listen to. Or I do crazy stunts like record YouTube videos or whatever. And so, people see that. And they come up and they have all these ideas in their head about things I am and am not capable of. And I’m pretty sure most of them are all wrong. [Chuckles] So, I don’t know. As far as that being a metric, I think it’s a pretty terrible metric along the lines of one number to rule them all. And I don’t know. So, even if we evaluate two separate programmers, maybe an expert and a novice on one particular thing, which thing we pick matters a lot, a lot, a lot. An expert who’s been writing web apps forever may know that really, really well or something. And then you take the novice and you say, you ask them some networking question, some low level networking question, and there can be scenarios where the novice could survive. Even when I was a novice, I used to write MUDs for fun, the games that people log into and chat and attack monsters and stuff. So, I had a pretty good grasp of low level networking even back then, opening sockets and stuff like that, maybe to the point where I could answer those questions and somebody who spends all day talking HTTP may not have as good a grasp on. So, it really depends which axis you attack on, like Avdi said. AVDI:  One axis I try to look at for myself is just basically whether I’m shipping, because shipping, whether you look at it from a whole product standpoint or just shipping a feature, shipping a bug fix, and you can even take shipping beyond just software features. But it’s one of those things that encompass a lot more than just specific technical knowledge, more than just technical skill. It also encompasses, “Are you working with the people that you need to work with in order to ship? Are you looking up finding the knowledge in order to ship? Are you finding alternatives to writing software that turn out to be cheaper than writing the software in order to ship?” So, that’s one way I look at it. SARON:  That’s a great one. I like that one a lot. JAMES:  Yeah. I like that one, too. And these days, I try to keep track of what I’m doing on a weekly basis and produce some meaningful something each week. Because I’ve found that I can get into a project and just get lost in the project, and then work on it and not realize six months has gone by and I haven’t put anything out there. And like Avdi says, it’s a measure of, “Are you doing stuff?” And I think it’s a really good, concrete measure. AVDI:  And I think it’s also a measure that a lot of managers or people higher up in organizations are using out there. And I think by and large, that’s how I want to be judged, too, rather than based on more specific metrics and stuff like that. It can also be, let’s be fair, it can also be tough when there are barriers in an organization that are keeping you from shipping and you just can’t do anything about it but you’re being judged on that. So, it’s not perfect. CHUCK:  I don’t know if there is a perfect system. But at the same time, I think there are areas that we can definitely evaluate ourselves in. I agree with James that having one number or one metric isn’t enough because it’s misleading or can be misleading. But I think at the same time, if we’re evaluating ourselves, we can give ourselves some leeway and just determine what areas are important and evaluate those. And that’s one thing that I really like about your answer, “Am I shipping?” is that it’s something that I can measure. Did I ship? Yes or no. Did I ship awesome or did I ship something okay? And I can evaluate those things and I can give a concrete answer to it and know, okay, I did what I valued. Are there other areas? Are there other things that we should be evaluating? JAMES:  I think the one thing to remember about the shipping thing, I like it and I think it’s great and stuff, but I think it’s important to remember that a lot of times it’s just what got loaded into my head that’s actually the important part. So, it’s totally reasonable to spend a week working on some idea I think, in many cases, to realize at the end of the week, “That’s a terrible idea and this is why. And we can never ship this and this isn’t going anywhere.” But now we learned this lesson and we won’t have to mess with that again, or whatever. I think that is also a valid form of “progress”. SARON:  Yeah. And I think based on that, one thing that I’ve been trying to do but I haven’t really been very consistent on, is making a “Today I learned” list. So for me, my growth is all about just did I learn something new and useful? And I find that documenting it means that I don’t have to relearn it later, because I forget way more than I’d like to. And so, for me if I can write down three things that I learned that day regarding programming and technical stuff, then I’m winning. It’s really that simple. And I think I’ve blogged it recently, where I just wrote, “Here are three to five things that I learned. Here are the resources that I used to learn them.” And as long as I’m moving forward in some kind of concrete, tangible way, that’s my own personal measure of growth. JAMES:  I like that one, because it speaks to mastery, one of the three pillars of intrinsic motivation, that we all want to feel ourselves getting better at stuff. And to me, it’s a lot like you said, that I want to be learning new things all the time, basically diversifying my mind because my opinion is that the more of these ideas I have around in there, when I run into problems I’m like, “Oh, that’s just like whatever with some twist.” I have more things to connect to and that gives me more confidence in what I’m doing and gives me starting points to jump off from and helps me go forward. So, a lot of times I’m learning things that I’m not even sure how they’re related yet into the things that are the most important to me. But I generally don’t find when I’m learning a lot of new stuff, that I don’t find a use for it someday. CHUCK:  So, what kinds of things, James I’m curious, do you try and learn? So, when you’re trying to make that forward progress, is it just anything that’s interesting or are there certain areas that you… JAMES:  Yeah. I get stuck on things I guess. I will just cast out randomly and latch on to something, but then I’ll get stuck on things for a while. So, right now for me it is intrinsic motivation, is what I’m stuck on. I’m just like, “Ah, I want to read a book about something new,” and I was a new parent and things like that. And so, I was interested in what motivates people to do things. I read a book and that lead me to another book and then that led me to another book. And a year and a half later, [chuckles] I’m still fascinated with intrinsic motivation. And I’ve read a lot about it and played with it in a lot of different ways. So, I get stuck on that. And I feel like that has done a lot for helping my interactions with people and things like that, because I think I do a better job of understanding what other people are trying to get out of our interactions and stuff. So, I’ve [inaudible] on that. Also, I’ve been, so today just before the call I was playing with Rust and fiddling around with that and hanging out in the Rust IRC channel and asking some questions and getting feedback. So, that was what I was learning on the technical side this morning. So yeah, I have things and go through cycles and get fixated on certain things. And I think all kinds of stuff, from social skills to technical oddities. One of the things I would like to learn, probably will play with this weekend, I wrote a program at work the other day where I had a busy loop in it, where I had to sleep for a tenth of a second then wake up and check and see if something’s done. And I thought, “Oh, that’s a terrible model. I’m sure there’s a way to do it without that busy loop.” And I tried a couple of ideas I had real quick and failed. And so, I was like, “Whatever, this works fine for now. And let’s just ship it.” But now I want to go back and figure out how you write that without the busy loop so the computer’s not wasting time. And so, I’ll probably play with that in the next day or two. Short answer, it’s totally random. [Chuckles] AVDI:  Are there any metrics that are meaningful to you? Concrete metrics that maybe you wouldn’t want to be evaluated solely on that but that you find interesting in gauging your progress. I’m racking my brain. As I’m on this call, I’m also practicing on a typing tutor. And it has very nice hard numbers. I’m looking at 44 words per minute and 93% accuracy. And yes, I type really slow because I’m finally learning to touch type. But I’m trying to think. Are there stats that are interesting to look at when it comes to learning programmer-related skills? JAMES:  I racked my brain over that after Saron sent us her questions. And I came up with one that I do respect. And to me, that was where I am on the Dreyfus model of skill acquisition. And I think one of the reasons that I respect that so much is there’s a lot out there about, “So, here’s the things you probably know at this stage. Here’s the things you probably don’t know yet or aren’t thinking about yet,” or really good details like the advanced beginner stage is a dangerous part where you can get stuck and then you tend to way over-evaluate yourself based on how you’re stuck in that stage. And so, I think just knowing where I am in the Dreyfus model of skill acquisition and trying to stay aware of what I would be experiencing in that level maybe helps me avoid some pitfalls or avoid getting stuck or whatever. To me, that was a metric that I do value. SARON:  And from what I know, that’s not a number. You don’t get a score. You look at the qualities that you fulfill and then you’re in that section. Correct? JAMES:  Right. There are five categories. SARON:  Right, categories. JAMES:  And yeah, each category is, these are the kinds of things you know or are experiencing right now, probably. Yeah, so it’s not a hard, fast number. It’s more like I’m probably somewhere around here now. SARON:  Well, I’ll tell you one metric that I’ve been using that has totally failed. And that metric is timing myself. It’s been the worst, most frustrating thing ever. I’ll look at a feature, or a user story, or whatever it is that I’m building and I’ll say, “This should take me one hour because I’ve done this before, or this is similar to this thing I just finished. So, this is what it should take me.” And it never, ever, ever takes that long, because there’s all these things that I either hadn’t considered or hadn’t thought through yet or it actually wasn’t as similar to this other thing as I thought it was or for whatever reason. And so, what it taught me was that timing things for me probably isn’t very fair and isn’t a good metric. But it did teach me that if I’m able to time something well, it’s not so much a reflection of my skill at that thing. It’s more a reflection of me understanding the problem that I’m solving well enough to estimate a time that makes sense. Does that make sense? JAMES:  Yes. SARON:  [Chuckles] JAMES:  And that one, I think it’s ‘Programming Pearls’, the book that goes into that a bit. And it talks about what you’re experiencing right now. And I used to have a real problem with that. My guesses were probably worse than randomly picking a number. I was that far off. And it gets better over time, I think. I’m still not a perfect guesser by any stretch of the imagination. But I think I’m way better at estimating what I can accomplish in a given period of time now. And I think that’s one of those things that you level up on as you go. And in ‘Programming Pearls’, they actually encourage, even though you may be bad at it. They say that’s fine and you should still keep doing it, because it’s something you have to train yourself. Estimating is a skill in and of itself. And it counts for a lot of different factors like about building in some time for things to go wrong, building in some discovery time, building in time for each of the unknowns that you’re currently aware of, whatever. And that is a muscle you can develop as well. And so, they think there’s some value to that. But I definitely in the past felt like you at times where it was like, I obviously have no clue how people estimated stuff. SARON:  Yeah. JAMES:  But I think I’m getting better at it as I get farther along. CHUCK:  One thing that I want to point out with the Dreyfus model and some of these others ways, in fact pretty much every way of self-evaluating is that you have to be able to accurately evaluate yourself. And that’s not always easy. There are some areas of my life where I found that it’s harder for me to be subjective than others. And I want to be good at programming and I want to be good at specific things. And so, it’s tricky for me to say that I’m not as good as I want to be. Or maybe in some ways it’s harder for me to say that I am as good as I am. And so, are there ways to get around those things where you may have some doubts about your skills or you may be overestimating how good you are? SARON:  I think it really helps when you get to work with other people. So for me, I find myself underestimating myself more than overestimating myself. And I find that it’s a lot easier for me to give myself credit for my own growth and learning when I get the opportunity to explain the thing to someone else. And when I get to pair and they say, “Well, how do you do that?” and then I’ll just start talking and I say, “Oh, I actually do know what I’m talking about.” And I think that using social coding is a great way to gauge yourself and either find holes of things you don’t understand or maybe acknowledge that you know more than you think you do. AVDI:  I was just going to agree with that. I’m prone to thinking that I just don’t know anything at all, especially when I haven’t worked with anyone for a while. And I have found that just pairing with someone else is a great way to feel a little bit better about, “Oh, I guess I actually do know things after all.” JAMES:  Yeah. Steve Klabnik has one of my favorite stories about that. He talks about how he was pairing with someone one time and they were doing something and then they ran into some bug and they had to figure out and hunt it down and stuff. And then they were done. And the person Steve was pairing with said, “Aww, man. I’m sorry. I bet that was really boring for you or whatever, that we had to hunt down this bug and stuff, and this is beneath you,” kind of thing. And Steve said, “Uh, what do you think I do all day?” [Laughter] JAMES:  This is programming. This is what I do. [Chuckles] And I thought that was really great, that people think because we’re experienced or something, we don’t hunt down bugs or whatever. That’s not true. We do exactly that. And I think that’s tough. So, it’s appropriately humbling to pair with other people. Or sometimes, even just when you are pairing with someone and they see you do something, and they’re like “Wow, why did you do it like that?” and you’re like, “because that’s the way I’ve done it for ten years and it works” or something. And they’re like, “Yeah, here’s the one-liner that means the same thing,” or whatever. And then you know. You know that you’ve leveled up there and you’ve learned something new and it’s cool. CHUCK:  David pointed out when we were prepping for the show, the flipside is that you get those funky things that are going to help you out later on, too. And so, it’s not just the times when you’ve always done something the weird wrong way, but you pair with somebody who’s always done something the funky right way. SARON:  Yeah, I think that getting to ask the question why and being asked why you do something is just awesome exactly for that reason, because you have to defend your code or your design or your strategy. And you’re forced to think through and realize whether or not you actually thought it through or whether it was just, “Yeah, this is just how I’ve always done it,” or, “This is how one person showed it to me that one time. That’s all I got.” It’s a great, great opportunity for learning. JAMES:  This is a famous problem by the way, the Illusory Superiority. Usually the example given is in the US if you ask drivers whether or not they’re above average, 93% say yes, which can’t be true because 50%, you know. [Chuckles] JAMES:  So, it’s a famous problem, that we have a tendency to over-evaluate our abilities. Or maybe in some weird population of us, under-evaluate, because I feel I fall more on that side. But yeah, it’s a famous thing. You have to have some kind of biases. We just get around the biases, which is why Saron is searching for how can we measure and not have a rough idea at least of where we are. And it’s a great question, because you should want to have some kind of external measure. CHUCK:  I don’t know if we’ve given a good answer though on how to measure, if there is a good answer. SARON:  Well, I think what this conversation has shed light on for me is maybe it’s not so much about finding a metric or a number. I kind of wish there was a number, because that would just make everything a lot easier. But maybe it’s just about feedback. I think it’s hard to learn and move forward if you don’t have feedback and you don’t have some sense of how you’re doing. And maybe that can only be qualitative. Maybe it’s just, “How did you feel when you were pairing?” Did you feel really dumb or really smart? How much code did you ship that week and was it a lot or was it a little? And maybe it’s just more about qualitative feedback and not so much numbers. What do you guys think? JAMES:  I love the idea of feedback. I think that permeates almost all of programming. The very first thing I do when I start any project is set up a feedback loop, even if it’s just RSpec init. That’s what you do to set up a feedback loop. I’m going to start writing these tests and they’re going to be red. And I’m going to switch them to green, and ta-da, feedback loop. So, I can tell what I’m doing. So, I can tell if I’m pushing things in the right direction. CHUCK:  You really like that fad diet, don’t you? JAMES:  Right, yeah, exactly. But yeah, you have to have, I think you’re exactly right, that you have to have some kind of feedback so that you can tell, am I pushing in the right direction? Am I pushing in the wrong direction? Now, there are times when that feedback is particularly hard to set up or get, I think, because of lots of various reasons, just complications. But it’s important. CHUCK:  I’d pile onto that but I just agree. JAMES:  You had a good question, Saron, in what you sent us before the show. One of them was how did you use to measure success? And that question, I spent a lot of time thinking on because I found that I think I used to include many laughable things. I want to call them stupid programmer tricks I knew. CHUCK:  [Laughs] JAMES:  Like I can easily in one line build a binary tree or something like that using inject, therefore I score certain points or whatever. And nowadays, I would consider that knowledge next to useless or something. And so, I think I’ve definitely come a long way in getting past those ideas of measuring. CHUCK:  Yeah, a lot of my metrics were based upon what other people thought, which is both good and bad. And the other metric and I still use this to some degree is, am I more capable of solving the common problems that I see than I was before? But that’s not really a number that I can come up with, because I don’t really track it. JAMES:  I think I have a similar metric to that. When I find myself running into a lot of things, especially at work where I have absolutely no idea how to attack it, then that goes on this list of things I should probably look into at some point. And then I try to push down that list a little bit when I have some time so that next time I run into problems like that I have at least an idea about how to go about solving it. SARON:  I like that a lot. I like the idea of keeping a list of things that you see [inaudible] you should probably focus on and learn. And it’s funny, because I guess I keep a mental list of that. And there are a couple of things that I just thought would be really hard because I didn’t know them. And then I realized that they actually weren’t hard at all and it was fine. [Chuckles] And learning them, I got over this huge barrier that had bothered me for a really long time. JAMES:  That’s a great point too, right? Because when you’ve never looked at anything, then you have no way to assess how hard it is. And so, when you do run into it or whatever for the first time, you’re like, “This is impossible. I’m totally clueless.” And then some things are really hard. Some things are way less hard. And it may be that once you’ve spent ten minutes reading a little bit you’re like, “Oh yeah, this isn’t bad at all.” [Chuckles] AVDI:  I feel like one of the most important things that I strive for in development is just perspective. It seems like that’s one of the things that helps me solve problems more than anything else, is having a bigger perspective, your perspective on what tools are out there, bigger perspective on this problem. How does this problem fit into the universe of problems? What problems is it related to? That kind of thing. And unfortunately here again, I know that I want this. But I cannot for the life of me think of a way of measuring perspective. I can look back and see that I have more perspective now than I did before. But it’s very hard to quantify that. JAMES:  I think you’re right, that it’s hard to quantify. I actually relate that in the social skills category. To me, that’s one of the things you really get out of raising your social skills. Looking into anything like feminism, racism, or just how to talk to people, how to persuade people, or rhetoric or things like that. In my opinion, all of those things severely level up your perspective. AVDI:  I would agree with that. But I think there really isn’t a perspective scale, you know? JAMES:  Yeah, I agree. AVDI:  Which is tough, because the most worrisome thing about gaining perspective, you look back and you realize how little perspective you had before and you think, “Wow. That means I must have really poor perspective now compared to how I’ll feel five years from now.” And you wish you could actually see it on a scale somewhere. At least I do. JAMES:  Ditto that. AVDI:  But all you have is your subjective perspective. CHUCK: Yeah. The one thing I have found is that if I’ve worked for a long time with somebody, a lot of times they can give me some advice on where to go. And they offer [inaudible]. They may have perspective that I don’t. AVDI:  Yeah. I guess that’s sort of, maybe it’s less important that we know where we are on a scale and maybe it’s more important that we have a sense of motion or not motion. JAMES:  That is a great thing. I like what you said there. That’s what I was trying to say with the “Don’t measure it” rant earlier. [Chuckles] It’s that I’m not really concerned with being able to nail myself to a specific number. But I really like what you added there. I’m more just concerned with if I feel like I’m pushing myself in the right direction. AVDI:  I relate this a little bit to physical exercise. Physical exercise is one of these things that are really easy to quantify. And it’s really easy to go absolutely just nuts with quantification of this stuff. The first time I tried to get into running, I remember I got one of those heart monitors and everything. And they have the heart zones that you want to try to stay in, stuff like that. And as I’ve gone on with it, I’ve realized that I’m not sure that stuff really matters that much. Because honestly, if anything it’s making me less in tune with my body. I’m resorting to these numbers instead of focusing on, “How do I feel?” And you want to know whether you’re in a good heart zone, look at whether you’re easily conducting a conversation or gasping for breath, or lying on the ground puking. [Chuckles] AVDI:  Those will tell you. Your body will tell you where you’re at. And if you want to know if you’re making progress, if you pay attention you will realize that you’re making progress with exercise. It’s pretty easy to tell that you’re stronger one day than the day before. Maybe it’s almost good that we don’t have too many, it’s not as easy to quantify this stuff, because I think in exercise as in anywhere else, maybe it’s more important to be aware of motion or lack of motion, movement forward or stagnation. And that’s subjective, but having a sense of it is important. JAMES:  I love that. The physical example is great. The one that popped into my head when you said that is parents do this all the time, this is one that just cracks me up and I’m totally guilty of it. We’ll say to our kids something like, “Eat three more bites.” Where did that number come from? [Laughter] JAMES:  If you don’t, what? You’re going to waste away and die? It’s just this totally arbitrary number that we pulled out of thin air that has no meaning. The kid, if they get hungry, they’ll probably eat a little more. And if they’re not hungry, they’ll probably quit or whatever. But yeah, exactly. It’s hard to quantify. SARON:  So, how do you guys feel about your motion and your growth right now? JAMES:  Pretty good until we did this podcast. [Laughter] JAMES:  Thanks, Saron. SARON:  [Laughs] Any time. JAMES:  [Chuckles] AVDI:  I feel bad. I feel really bad about my forward motion. And it’s weird, because maybe I would be in a worse position if I felt good, because [chuckles] it’s the feeling bad about my forward motion that makes me do more. It’s a weird kind of situation where if I feel good about it, it probably means I should start feeling worse so that I’ll start moving forward more. I don’t know. Maybe I’m just neurotic. SARON:  No, if you’re neurotic, I’m neurotic too. I’m the exact same way. It’s like if I’m happy with myself then I say, “Okay, great. I’m doing well. Let’s go watch 30 Rock.” But if I feel bad, then that’s my motivation to do better. CHUCK:  I’m going to do us all a favor. We all suck. [Laughter] JAMES:  I go through periods where I feel good and bad about it. Last week, I was playing around with Rust in my free time and I felt utterly defeated. Everything I tried, I couldn’t get it to work and I didn’t understand the errors. And I tried asking some really badly formed questions in IRC. And so, that got me nowhere because it was a terrible question and things like that. And so, I just felt like I made no progress last week. So then this week, I sat down and I’m like, “Okay. Got to reduce it to small things I understand, work forward, ask good questions from that,” and I had a discussion in IRC today in Rust that I think got me over one of the biggest humps I’ve run into so far. So, that was the setback that let me go forward this week. So, I have periods where I feel bad about it and periods where I feel good about it. And it waxes and wanes and I hope that’s true for everybody. Otherwise, that’s really going to upset me. So, I think you want to look at the long game, not the short game. And long-term speaking, I feel like this year has been a great year of progress for me. CHUCK:  That’s good to hear, James. I tend to go back and forth, too. Sometimes I feel like I’m doing great. Sometimes I don’t. And sometimes, I’m okay with not feeling like I’m making a lot of forward progress. There have been a few times this year that I just haven’t had time. I’ve had things going on with family. I’ve had things going on with clients. And I just didn’t feel like I had very much time to put into making that forward progress. And the projects I was working on weren’t exactly challenging. So, there’s that. And then the flipside is that sometimes I get really excited. And this is how I usually move forward, is actually in fits of bursts. So, I get really excited about a project and so I’ll go build something out. So for example, I’ve been playing with Swift lately, and so I’m getting ready to start building an app in Swift. Another one that got me really excited was that I’ve started looking at Riak, the database. And I know we did an episode on it a while back, but I just looked at it then. But I’ve been really digging into it and I’ve been getting excited about it. And so, I’m actually considering building out a Twitter clone on Riak and finding out what the limitations are and things like that. And so, I level up because I’ll spend a couple of weeks playing with the project. And then I’ll slide back into not doing a whole lot for a little while. And then I’ll go and run ahead with this stuff. I’m not necessarily happy with the slower periods, but I feel like I make up for it sometimes with the active periods. Does that make sense? SARON:  Yeah, it does. I feel like I work in bursts, too. And mostly my bursts are around what things I’m paying attention to. So, when I think about myself as a programmer, I think about the product that I’m building, the end product, whether or not it’s actually out there. I think about the quality of my code, and then I think about the process, which I pay a lot of attention to. And so, I feel like right now I’m very, or most recently I’ve been very focused on my process for building. And I think that’s improved. That’s my burst of energy. And I haven’t been paying too much attention or as much anyway as optimizing the product and the code. And now I think I’m going to shift gears and focus more on the product. And then it goes in cycles of things that I focus on. JAMES:  I like how you divide up and measure in different categories. I don’t think I do enough of that. SARON:  Yeah. I noticed in the most recent project I worked on. It was just two of us and we did everything. And I realized that when we did retros and we talked about things that we liked, it always fell into those categories. It always fell into the code that we’re actually writing, how we’re writing it, and then how happy users are with it. And so, I feel like now when I’m working on side projects or personal things, thinking about it in those three categories helps me focus on specific skills as a programmer. JAMES:  I think that’s awesome. I like what Chuck said a lot about how sometimes you just have family time. This month for me, my daughter had a big birthday and we had company in from out of town twice because of that. And then she started school just a few days ago, so we’ve been doing lots of extra things at school because of that. And just stuff like that. And I do go on into this month like, “You know, I’m not going to have very much time for programming stuff. And whatever I get done, I get done.” And the truth is I haven’t done very much programming this month. I’ve done a lot of reading when I’m busy and can’t get to the computer. I think, “Well, in that case I’ll read more on the Kindle and try to push forward in other areas and stuff.” And I think accepting that and going into that knowing or just being aware that you’re doing other things right now and that those things are probably good, too. Time you spend with your family and developing that, that adds to your happiness I hope, and makes it better for when you get a chance to come back and attack it again. So, that’s time well spent, too. CHUCK:  Yeah. So, we talked a little bit. I don’t know if it’s just in my head or in general, if we’ve been talking about evaluating yourself on more or less the tech skills or different technologies, learning stuff like that. But is there a good way to evaluate yourself on the non-technical stuff? The stuff that James pointed out that we should probably be learning, like our ability to think like a machine or our ability to communicate with other people. JAMES:  How many fights do you get in on the internet? SARON:  [Chuckles] Nice one. CHUCK:  As many as I want to. [Laughter] JAMES:  I don’t know. It is a good question. It’s hard to know. And social skills are one of those things where I feel like, “Yes, I learned something new. And now it’s so much farther to go now that I’m aware of all these other things.” It makes it tough. But I don’t know. I think in general, that gets reflected hopefully in your interactions with people. I feel like I communicate better these days. And I think people give me some signs that that’s true AVDI:  Does anyone keep a journal? CHUCK:  I do off and on. SARON:  No, but I want to. JAMES:  I keep one for my daughter. I just write down a little something about her each day. But that’s it. AVDI:  I wonder if that would be helpful to getting a sense of, a larger sense of progress on some of this stuff. JAMES:  That’s a good question. CHUCK:  I think it’s good for that as well as related to that, pointing out the things that happened yesterday or the day before or whatever that you want to make better, because it forces you to reflect. And so, then you can say, “Yeah, yesterday this happened. So, I’m going to work on this so that it doesn’t happen like that again.” JAMES:  Good point. SARON:  I like that. JAMES:  A lot of times being on this show teaches me things that I want to get better at. I feel like this show, especially with our random set of guests and our excellent panelists, that you all expose me to ideas all the time. Saron just gave me the idea of dividing up the different ways I’m measuring projects and stuff. And I tend to go forward and be like, “How can I put that to use and what can I learn from that?” And I think it’s important to get yourself some sources of that. It’s a feedback loop, like Saron said. I hear the things you all are doing and I think, “Oh, how can I incorporate the parts that I like?” and it helps me grow and get better, I think. AVDI:  Am I the only one who looks around at all the stuff other people are doing and just feels utterly insignificant because of it? CHUCK:  Mmhmm. No. [Laughter] JAMES:  Yup, that’s just you. CHUCK:  When I said, “Mmhmm,” it was just my initial reaction to say, “Yeah, I feel that way all the time,” not… [Laughter] CHUCK:  Anyway. JAMES:  Have you ever looked at zenspider’s Ruby projects? Whenever I go look at the list of the things Ryan Davis has contributed to, it’s like, “Dear Lord, what have I done with my life? He’s getting it done over there.” [Chuckles] Yes, I definitely feel that. CHUCK:  Any other areas or things that we should talk about before we get to the picks? JAMES:  Saron was… SARON:  I’m good. I feel like we covered pretty much everything I was thinking of and then some. So, I’m good. CHUCK:  Awesome. Alright, well let’s go ahead and do the picks then. Saron, do you want to start us off? SARON:  Sure. So, I have a few. The first one is this beautiful animation that I’m absolutely in love with. It’s called ‘Thought of You’. It’s by Ryan Woodward, I believe is his name. Yup, Ryan Woodward. He’s an animator who specializes in drawing explosions, which I didn’t think was a thing that you could specialize in. But he’s an animator for DreamWorks, Marvel, Pixar, Disney, a bunch of other places. And he did this really beautiful side project. It’s a short 2D animated film called ‘Though of You’ and it’s just really simple and really, really beautiful. So, that’s my first one. My second one is this blog post that I came across I think the other day written by Tess Rinearson. I’m hoping I’m saying her name correctly. She’s an engineer at Medium and it’s called ‘A Hacking Hiatus’. She’s very big in the hackathon space, has done a lot of work to promote them, make them really inclusive and friendly and all this stuff. And she’s taking a break. And she had a really thoughtful blog post on her reasons and her experiences that I think everyone would benefit from if they read. And my last pick is called SMACSS which I recently came across. So, if you follow me on Twitter, you know that CSS and I have a very terrible relationship. Every time that I think we’re going to get along, I feel very betrayed by it. And so, I was complaining and doing my ranting as I usually do and someone suggested this resource that I’m hoping to be able to dig into more in the coming weeks. But it sounds amazing. And the idea is that it’s a style guide. So, it’s not a framework, it’s not a plugin, it’s not a library that you download. It’s more of a way to think about CSS and to think about your design process so that you’re not as frustrated and angry as I usually am. So, those are my three picks. CHUCK:  Awesome. Avdi, what are your picks? AVDI:  For a technical pick, this may have been picked before. I haven’t checked the backlog. But there’s a presentation that I finally got around to watching the other night. It’s Bret Victor’s ‘Inventing on Principle’ video. I know a lot of people have talked about it already but I just, [inaudible] it on my queue all this time. But I will say it was worth the hype. Really, really thought-provoking video, thought-provoking on a couple of levels. On the surface level, he has some really interesting demonstrations of possible new ways of interacting with code. But then on a meta level, he also has some thought-provoking things to say about thinking about why we invent, why we write code, and possibly having an overarching principle behind the stuff that we build. So yeah, Bret Victor, ‘Inventing on Principle’. It’s a good talk. And I have a lot of other stuff, but I’m going to leave it aside for now and I’ll just pick one non-code-y thing. I was looking around for something better to keep the sweat out of my eyes when I was running. Usually I just wear a cotton bandana to keep the sweat out of my eyes and also to keep the hair under control while I’m running. And I asked around to various other runners and I got a bunch of suggestions. But the one that… I ordered a few products, but the one that really worked out for me is something called the Buff Headwear, which is basically just a tube of very stretchy, very wicking fabric. And you can get it in all kinds of styles and you can wear it in a dozen different ways. And it works really, really well. I actually ordered one and then immediately lost it in the Atlantic Ocean and proceeded to order two more, because I really liked it. So, that’s it for me. JAMES:   You go running in the Atlantic Ocean? AVDI:  No, no. CHUCK:  [Laughs] AVDI:  I was foolish enough to… [Laughter] AVDI:  Yeah, that’s hard mode. No, I was foolish enough to… CHUCK:  Hard mode. I like it. AVDI:  [Chuckles] to wear it while I was playing around with the kids in the ocean when we went to the beach. And it turns out it’s not such a good idea for controlling my hair when dealing with large waves. JAMES:  [Chuckles] AVDI:  But for running, it’s good. CHUCK:  Awesome. James, what are your picks? JAMES:  Damn. Everybody else’s picks are so good. Saron’s really right about that hackathon break article. That’s one of those good ones that will level you up socially. And the ‘Inventing on Principle’ talk that Avdi mentioned is just pure gold. So, I just want to plus one both of those. For my own picks, I’ve mentioned that I’m obsessed with intrinsic motivation so I guess I’ll go ahead and do a few picks related to that. If I had to sum it up in two books, it would be ‘Punished by Rewards’ and ‘Drive’. If you’re not aware of why rewards and stuff like that are problematic, you probably want to start with ‘Punished by Rewards’. I wasn’t and I needed this book to make me understand how things like that work and what’s going on. And there’s 50 plus years of research basically condensed into this book, this one book. So, it’s a great place to get that. If you’re already aware of that kind of stuff, you can probably safely skip that step and go straight to ‘Drive’. And ‘Drive’ is more about how does intrinsic motivation work and how can we use that to our advantage. Really good books. And then just for a fun pick, I picked up a Sphero recently. And I’ve been playing with my daughter with it. A Sphero’s a little round robot and it just looks like a ball. And you drive it with your iPhone, iPad, Android, whatever, via Bluetooth. You can drive it around. And it just rolls around. It’s really fast and zippy. It jumps up ramps. And you can change the color of it. And you can even get this little rubber shell you put on it. And it gives it more traction outside, or it lets you drive it in the swimming pool and keep going, just spinning around and around and pushing it forward in the swimming pool. So, lots of fun stuff. We’ve just had some fun playing around with it lately. It’s a cool way to get your kids to see what a simple little robot is like. Very simple but fun. Those are my picks. CHUCK:  Cool. I was at a conference last weekend. And I don’t know if I have any great picks. I did listen to a book while I was out there in a little bit of the spare time I was out there. And it was just of interest to me because the girl that wrote it is from Salt Lake City. It’s ‘My Story’ by Elizabeth Smart. Elizabeth Smart was kidnapped when she was 14. And the guy was nuts. And so, it just talks about what happened to her over the nine months before they found her. They found her in Salt Lake City walking down the street with him and his wife. So anyway, really interesting. She did have some pretty terrible things happen to her. So, if those kinds of things bother you, then I recommend that you don’t read it. But anyway, it was interesting just to see what happened and how she was able to come through it. She was able to come through it and basically go on to be a mostly normal person. So, she went on a Mormon mission. She met her now husband there. They seem to be pretty normal. She’s an anchor or guest anchor or something for the local news station now. And so anyway, I thought it was interesting. And that’s ‘My Story’ by Elizabeth Smart. I don’t have any other great picks. I’ve just been busy doing other things. The conference I was at was Podcast Movement. And it was a terrific conference. So, if you’re looking at doing some content stuff, and this time there was a lot of focus on how to convert and make money with your podcasts. So, if you’re interested in any of that, then it was definitely a good way to go. So anyway, those are my picks. And yeah, we’re still doing the book club book. We’re going to be talking to Martin Fowler about ‘Refactoring: Ruby Edition’. So, if you haven’t read it yet, go get it. We’re going to be talking to him in September or October. I don’t know exactly. But yeah, so that’s it. Go read books. [Chuckles] JAMES:  Thanks everybody. SARON:  Thank you.[A special thanks to Honeybadger.io for sponsoring Ruby Rogues. They do exception monitoring, uptime, and performance metrics and are an active part of the Ruby community.]**[Working and learning from designers at Amazon and Quora, developers at SoundCloud and Heroku, and entrepreneurs like Patrick Ambron from BrandYourself, you can level up your design, dev, and promotion skills at Level Up Con taking place October 8 **^th and 9** ^th ** in downtown Saratoga Springs, New York. Only two hours by train from New York City, this is the perfect place to enjoy early fall and Oktoberfest while you mingle with industry pioneers in a resort town in upstate New York. Get your ticket today at LevelUpCon.com. Space is extremely limited for this premium conference experience. Don’t delay. Check out LevelUpCon.com now.]**[This episode is sponsored by MadGlory. You’ve been building software for a long time and sometimes it’s get a little overwhelming. Work piles up, hiring sucks, and it’s hard to get projects out the door. Check out MadGlory. They’re a small shop with experience shipping big products. They’re smart, dedicated, will augment your team and work as hard as you do. Find them online at MadGlory.com or on Twitter at MadGlory.]**[Hosting and bandwidth provided by the Blue Box Group. Check them out at Bluebox.net.] **[Bandwidth for this segment is provided by CacheFly, the world’s fastest CDN. Deliver your content fast with CacheFly. Visit CacheFly.com to learn more.]**[Would you like to join a conversation with the Rogues and their guests? Want to support the show? We have a forum that allows you to join the conversation and support the show at the same time. You can sign up at RubyRogues.com/Parley.]