197 RR The Social Coding Contract with Justin Searls

00:00 4280
Download MP3

Check out RailsClips on Kickstarter!!


02:23 - Justin Searls Introduction

03:02 - Justin Searls: The Social Coding Contract

04:58 - Transitive Dependences and Understanding Technical Debt

15:21 - Learning Outside Work Hours

21:21 - Understanding Transitive Dependencies (Cont’d)

23:00 - Use Someone Else’s Framework or Write Your Own?

  • “It Depends.”
  • “A dirty code base is the sign of a well-monetized application.” - Matt Scantland

31:25 - When Does it Hurt to Use Tools You Don’t Completely Understand?

34:14 - Leaving Code Behind

36:26 - Be a Responsible Open Source User

47:22 - Reacting to Change

Royalty Free Music by Kevin MacLeod (David)Rebif (David)Ruby Rogues Episode #188: Community Building with Pieter Hintjens (Jessica)Commercial Users of Functional Programming 2015: Call for Presentations (Jessica)James Clear: Forget About Setting Goals. Focus on This Instead. (Jessica)Screw motivation, what you need is discipline. (Jessica)A Wizard of Earthsea by Ursula K. Le Guin (Chuck)Conform: Exposing the Truth About Common Core and Public Education by Glenn Beck (Chuck)Sony NEX-5T Compact Interchangeable Lens Digital Camera (Justin)Justin’s Talk at RailsConf 2015: Boring Code (Sometimes a Controller is Just a Controller) (Justin)Alpine iLX-007 7-Inch In-Dash Receiver with Apple CarPlay (Justin)


DAVID:  Your marginally improved microphone comes with a gorgeous display, however. [Laughter] JUSTIN:  Oh, yeah. I mean, I’m watching a full… JESSICA:  It’s a retina mic.[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/RubyRogues.]**[This episode is sponsored by Codeship.com. 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.com, continuous delivery made simple.]**[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.]**[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 197 of the Ruby Rogues Podcast. This week on our panel, we have David Brady. DAVID:  Hello from Saratoga Springs. CHUCK:  Jessica Kerr. JESSICA: Good morning. CHUCK:  I’m Charles Max Wood from DevChat.tv. I just want to give you a quick reminder to go check out the Kickstarter campaign for the Rails videos, DevChat.tv/Kickstarter. We also have a special guest this week and that’s Justin Searls. JUSTIN:  Hello, everyone. CHUCK:  Do you want to introduce yourself, Justin? JUSTIN:  I can try. I’m a developer. I live in Columbus, Ohio. I help run a distributed/virtual software agency called Test Double. We’re about 20 people or so at this point. And we’re just doing great work for clients all around the country building custom software. I like to write open source. I talk at a lot of conferences. I love engaging with the community. I tweet a lot about how awful I am at writing code and other things, like bad flight itineraries. Yeah, and that’s pretty much 80% of my life. CHUCK:  Awesome. Well, we brought you on today to talk about ‘The Social Coding Contract’, which is a talk that you gave at RubyConf, was it RubyConf? JUSTIN:  Mmhmm, mmhmm. CHUCK:  Last year. I watched the talk but I didn’t pay attention to where it came from. JUSTIN:  Oh, like why I put it together? CHUCK:  No, I didn’t pay attention to which conference you gave it at. JUSTIN:  Ah, right. CHUCK:  Yeah, I am curious about where it came from as far as what prompted you to put that talk together in particular. JUSTIN:  I think two things. One, a lot of people… I’d attempted, in the pre-GitHub era I’d attempted to participate in open source, submit patches or maybe gain some notoriety by putting out some open source. But it was just so difficult to break through one by one in each community’s mailing list to get repos set up and get commit bit, or whatever was necessary, or sending patch files and stuff. It was just really difficult. But then GitHub so dramatically lowered the barrier of entry that a lot of us who had that kind of itch just started pushing stuff. And some of that stuff, we just got lucky. And we never went through a proper series of tutorials and trainings on how to be a proper open source maintainer. And making it up as we go along was fine for a while. But once you’ve seen the same kind of patterns emerge over the course of maintaining several projects, like you get really excited, you’re on the up and up, things are getting more and more popular, you’re getting some attention, that stuff is all easy to manage. But what’s harder to manage is when a project does what it needs to do and you still get peppered with all these issues and distractions and stuff on the slow descent into, maybe you don’t even use this project anymore but it still occupies a massive amount of your nights and your weekends because other people do, expecting your help for free. So, reflecting on all of that I just felt like there was a lot there that we could talk about culturally. And then combine it with the fact that all of these tools have made it so easy to slurp in hundreds and hundreds and hundreds of dependencies, direct and transitive, that we sometimes have lost sight of the cost of that convenience.. JESSICA:  Justin, one thing that you said in your talk, you mentioned all these transitive dependencies going down and down and down. You said that the application that we are required to support and understand is not just the code we wrote. It’s everything we push into production. It’s all of those dependencies and their transitive dependencies. And you use the phrase understanding debt for any open source thing that you pull in, any technology that you bring in and you don’t know exactly what it’s doing and you don’t know exactly what it works or how to use it properly. I love that phrase. It’s no technical debt in the sense that we could refactor and reorganize some stuff and fix it. It’s understanding debt. It’s something in our head that is going to bite us. JUSTIN:  Yeah, yeah. You can think of it from the perspective of pre-Rails, right? Before Rails I had to keep so much minutia about a project in my head when I was doing a web application, like configuration details, like the one-off build stuff that I had going on, all of the way that I happened to organize models, views, controllers or whatever. All of that cruft was just a carrying cost of every project. When I had Rails, I had this new privilege to outsource my understanding of a lot of those machinations. I don’t need to know how Rails’ configuration works in order to just use Rails, or how its Rake tasks are written and so forth. So, that’s not necessarily to say it’s a good thing or a bad thing. It’s just a fact that we’re so much more productive now because we have all of these awesome dependencies that do so much work for us. And we’re shipping bigger and more complex stuff that does more and more quickly with smaller teams. But I think that we sometimes fail to acknowledge that taking in 50 dependencies that does 50 different things for s, each one of those represents something that we probably could do ourselves. And if we were to do it ourselves we’d understand it a lot better. And what are we losing by not understanding either how it’s doing its job or what exactly it’s doing. JESSICA:  That’s really interesting. You bring up the part that you were in this before Rails and you did all those things that Rails does for you. So, you have that understanding of many of the things that you’re not doing anymore. But you do understand how the work. I’ve experienced that. I started in C and then moved to Java. And I can tell the difference between people who started in Java. Pass by value, pass by reference is a hard concept. But when you come from C it’s totally not. And Java does the garbage collection for me. And Ruby does that, too. But if you’ve ever had to allocate your own memory, then you appreciate that. JUSTIN:  Yeah, yeah, totally. JESSICA:  And it’s totally helpful. JUSTIN:  I think that, I like to visualize it like a Jenga tower, almost. I think Yehuda, in his RailsConf talk last yeah talked about this like it was a skyscraper. And every subsequent generation of developers are building on a firmer foundation than came before it. JESSICA:  Or just taller. JUSTIN:  Yeah, or just taller. [Laughter] JUSTIN:  And it is taller regardless of whether or not it’s better. But I like to think of it as a Jenga tower just because of how shaky it becomes as we lose that understanding beneath us, because it’s not something that just was ever intentionally built. We’re standing on top of all this stuff. And each subsequent generation only really knows its own experience. So, when I see people starting brand new today with no prior software development experience, my temptation is to teach them all the stuff that I had to learn along the way. But that would take them years and years and years and would be totally unfair to them. At a certain part, we just have to acknowledge, I didn’t know the stuff underneath me when I started and somehow things worked out okay. And maybe that’s just one aspect of why it’s so easy to lose the beginner’s mindset in software, because everything’s moving so quickly that it’s hard to even empathize with the point in that tower where beginners who are starting in 2015 are standing so much higher than you were at the same level in your journey. JESSICA:  Exactly. I feel like I was really lucky to get into software development before there was GitHub and before there was NoSQL, and before there were all these different things to start at that higher level. And I got the opportunity to, at work, build up to that slowly. And today, that background is way harder to get. CHUCK:  Yeah. JUSTIN:  Do you feel though that that would have been true with somebody 10 years prior? Being grateful that they got to stand just a little bit earlier than you did? Is it something that every subsequent generation will say? Like, “Oh man, I’m glad I started so low on this totem pole relative to the people after me.” JESSICA:  Somewhat. But there’s a matter of degree. And there’s that whole open source movement really changed the game. And I got in there before that. So, I got paid to learn C. and I got paid to learn Java when it was only Java and not a zillion libraries on top of it. It really, the exponential growth in the software that we’re expected to use, and there’s no flipping way we can understand all the software we’re expected to use in order to put together an application these days, that really took off after I started and I’m grateful for that. In ’99 when I started programming, I didn’t have a cellphone. I resisted for a couple of years. And the internet was pretty new. [Inaudible]. CHUCK:  I think there are some tradeoffs, though. It’s definitely nice to understand the stuff that everything else is built on. So for example, I came up, I started programming in Pascal and whatever version of BASIC was on my TI calculator when I was in junior high or high school. I don’t remember. But then in college we did Java, C++, and C. Of course, the C was all in my engineering classes, not my computer science classes. But coming up through there in some ways it was nice when we were learning some of the higher level concepts with Java because you didn’t have to worry about all of the extra things. So, you could just focus on specific areas of programming. And then the flipside was that when you got into C and you started to understand, okay, these are the building blocks that go into this, C and C++, you pick up, “Okay, these are the tricks that are going on. There are the things that the system is doing for me that I don’t have to do when I’m in a higher level language.” And so, learning Java first or learning C first, I don’t know. It seems like there is the tradeoff. But the tradeoff is, does it get enough out of my way to where I can learn these concepts in a little bit safer environment, versus the other way where I get a deep understanding of the system because if not, I’m going to cause myself problems. DAVID:  I think it’s, we have to be careful about certain things that have been solved for us and certain things that have just been papered over and passed forward as if they had been solved. And… JESSICA:  Mm. DAVID:  That’s when you get into leaky abstractions. And it’s always fun… JESSICA:  [Laughs] DAVID:  I remember back in 2009 discovering the SICP lectures. And listening to people talk in 1986 about things in computer science that are still problems today, and they were still problems in 2009, and nobody knew about them. And I was very angry that I had been programming, I started programming in the mid 80’s, and I had gotten all the way to almost 2010 without hearing about the concepts that these guys were teaching in an entry-level programming class at MIT in 1986. And I was very, very angry about this. And I went through the, we all go through the moment where you think that all of programming is just a racket. And that was my moment. I was Hulk smash on the keyboard that, “Why are we…?” that sort of thing. And so, I do think there’s stuff that we come into, like Java has so many libraries now, right? It has so many now that you just can’t be a depth first programmer in Java. It’s like if you need to do something in Java, you have to be a breadth-first programmer, because somebody’s almost certainly written a library already to do mostly what you need. And you should go find that and repurpose it for what you need. But then there’s also stuff that you run into, like the CAP theorem ain’t going away, people. You can’t write a library that’s going to make that go away, that’s going to make that tradeoff vanish. And so, we have people that are building stuff that are trying to scratch their itch when what they’re… it’s like instead of drilling down a layer in this, or 20 layers in the skyscraper, we’ve knocked a hole in the wall and plummeted to our deaths just for fun, because we decided, “Oh, I’m going to write this thing that’s going to solve this problem. And oh yeah, it turns out that in order to solve this problem, I have to prove that P equals NP or whatever,” which we can’t do yet. JUSTIN:  I think that you really get at what I was about to say too, which is that I’m always very careful of framing things as dichotomies when they don’t necessarily need to be. I think it’s totally okay or a beginner to start now with practical stuff, fast feedback loops, make progress, get a little bit of experience with application development. Just make some forward progress, maybe even get to the point of shipping some open source libraries and understanding the craft as it exists for most developers today. But what I think would be a shame is if they lived exclusively at the top of that skyscraper for decades of their career. DAVID:  Right. JUSTIN:  Without spending time diving down and starting to understand the layers beneath them. And the longer that you hold off on that, I think the greater sense of shock and frustration, like you experienced, David. DAVID:  Mmhmm. JESSICA:  That’s a great point. And Chuck, I completely agree. I feel lucky that I got to learn this stuff while getting paid for it when I was just a 9 to 5 developer. I never put in any extra time. You do not need to learn that stuff in order. It is totally reasonable. Like for instance David, I bet that if you had had that introductory programming course as an introduction to programming, you would not have appreciated those problems the way you do now. DAVID:  This is true. This is true. JUSTIN:  I literally did. I learned most… I had a little bit of programming experience before my computer science major. But most of what I learned, that was when I was focused on it. And it was right over my head because of how not practical it was, how the theory just did not map to any sort of concrete concept from my own experience. I am totally a hundred percent certain that if I had started my computer science program when I was in my late 20s, I would have actually gotten a lot out of it. So, if I had started with SICP I probably would have washed out at MIT. DAVID:  [Chuckles] Yeah. JESSICA:  Related question. Justin, you have 20-something developers working for you at Test Double. How much time did they spend outside of work on learning about programming? JUSTIN:  That is a great question, one that I am also curious to know the answer about. I think that part of the story of Test Double is that we started the company, a lot of us have previous consulting experience. And Test Double is about three years old now. And we started the company primarily as a reaction to what we saw as a failure of other consultancies to just trust expert developers to figure out the how to do what they do instead of controlling a lot of those constraints, like you’re going to use this technology, work in this place on these hours with these libraries and this approach and this process. Get rid of a lot of those arbitrary constraints, naturally the conversation with our clients will focus on the actual constraints, like what’s their budget? What do they want to build? What do the users need? And that’s been hugely successful. And the way that we frame that a lot is in terms of developer autonomy. So, we don’t micromanage people very much at all, which means that I don’t have a lot of insight into how people spend their time on a granular basis. My sense is, and my hope is that we’re constantly reinforcing to people, we bill on a weekly rate but that doesn’t necessarily mean our clients get every hour of every day. A lot of our time should be spent improving ourselves, helping each other out, learning, contributing to open source, engaging with the community. And I think that our people just, after a couple of months of feeling a little weary [chuckles] about managing their own schedule, they just fall into whatever rhythm they think suits them at that time. And I go through all sorts of seasons with this. I spend a couple of months a year just heads down on talks. I spend a couple of months a year really passionate about learning stuff, and I spend probably six months a year where I’m just like, wake up every day so thirsty to do awesome client work. There’s a different cadence I think for everybody just based on where they’re at. JESSICA:  You said you bill at a weekly rate, not an hourly rate. JUSTIN:  Yeah. We found that forcing people to log really, really… because you want to be accurate and honest, just basic ethics, with every bit of time that you bill at whatever granularity. But what we continually found is, well what happens if my best ideas are in the shower or in the car or between things or late at night outside the office? We wanted to allow people to not have to micromanage the 15-minute increments throughout their day. And then additionally, we decided that, let’s say you want to spike out some code at work. You have an idea like, maybe if I spent three hours researching this I could save two weeks later. But I still have to invest that three hours now and maybe nothing will com e of it. If you’re on an hourly rate, I feel like the right thing to do is to ask permission for that from your client. But your client’s like, in the least, like the worst position possible to make that ‘assertation’ for you. They don’t have the technical knowledge to make that decision. And it just [leads] to all this awkward local optimizations where it’s like, “Well, I’ll keep my head down and just keep on cranking.” But on a weekly rate, what we’ve found is it’s a lot more friendly, a lot more collaborative. People act as if they’re on just one team together. And a lot of those micro-negotiations fade away. JESSICA:  That is fantastic. Yeah, I’ve been thinking lately that tracking how much time we spend on stuff is possibly a distraction that really, I certainly feel this at work, that the limit is more about my [inaudible] of time and of attention, rather, like brainpower. That’s what I run out of. It’s not hours. So, I think that’s fantastic. JUSTIN:  It’s working really well for us. CHUCK:  The other thing that I found, so I’m doing a weekly billing project right now. And I’ve done a couple of fixed bids. And it’s much easier to align the value that you’re giving your client with things when it’s not hourly, when it’s weekly or fixed bid. Because ultimately then, they can look at it and they can say, “Okay, well given this time table or given this particular arrangement, I’m going to get the value and I know approximately what I’m going to pay for it. And I’m happy with that.” And so, they don’t feel like you’re nickel and diming them over any hours. It’s just, “Okay, I got a reasonable amount of work done for what I’m paying for the week.” JUSTIN:  I think that I’m just generally cautious whenever a business person asks me for a metric, or is interested in one, because it’s so easy for, using hours for example as a metric of something, or a popular [inaudible] estimations. Or if you’re on a scrum team, your sprint points velocity. Because it’s so easy once you have a lot of metrics to use those indicators as decision makers arbitrarily. Ours I think just go hand in hand with estimates in my perspective of you really ought to be asking, “By doing this activity and logging this and transmitting this information, what decisions am I enabling you to make?” And if the answer is none, then maybe that information isn’t actually useful. Maybe it’s even a distraction. DAVID:  One of the best ways I’ve found to expose the distrust as distrust inherent in micro-logging of time and that sort of thing, is to ask upfront for an estimate and a budget for time tracking. As in, what time code do you want me to put filling out timesheets under? And invariably, the person in charge of the budget will go, “Well, I just want that to get done.” “Ah, okay. So, this is inherently based on mistrust or a disbelief of the metrics that we have here? You want us to track stuff and spend time doing this, but you don’t want to track the time spent doing this. Do you see the problem?” JUSTIN:  Yeah, but you don’t value it enough to measure it. DAVID:  Right. And bringing it up is often met with suspicion and distrust of, “Why would we pay you to track your time?” or “Why would you punish us for having you track your time?” “Well, what do you mean punish us?” “Well, you’re making us pay for your time entry.” “Yes, yes I am, because you’re asking for a metric.” And I like your version better where you basically say, what decision does this enable you to make? And [chuckles] because it’s a lot less confrontational, which is probably a better idea. [Chuckles] CHUCK:  One of the things that you brought up in your talk, I want to go back to that, was the idea that you didn’t have to understand everything underneath you, but there was a tradeoff there. And we kind of talked about this before. But the thing is that in a lot of cases, it’s way more convenient to not have to understand that stuff. And so, I’m curious. At what point does it really hurt you to not understand the stuff that you’re building on top of, those transitive dependencies that you have? JUSTIN:  I think you raise a really good point, because ultimately I don’t know if I want to call him out by name. Yeah, I will. Okay, so I look up to Gary Bernhardt a lot. I think he’s done a lot of just unbelievably fantastic work. And his talks and what he’s published has opened my eyes to a lot of the systemic problems that we face. But sometimes in my mind’s eye version of Gary, I don’t think this is real Gary, I wonder whether or not, if you could just perfectly see that entire depth and that entire web of complexity, and sometimes as I approach that or as I get closer to that as I investigate introspective stuff more, it can be crippling, right? Sometimes I spend so much time talking about the systemic issues facing this bit of code that I’m looking at. And I can’t actually write the code. I can’t actually focus anymore. And it’s completely counterproductive. And that’s being an armchair analyst [chuckles] of the broader situation is not typically what people are paying us for. And it can be counterproductive. So, I think that there’s a really important balance. And budgeting both the time that we spend just trying to be productive and trying to better understand the world that we live in is something that everyone just has to find a way to strike on their own. DAVID:  So, there’s a good follow-up question to that, which is I hear this argument frequently. In fact there’s an interview question that I used to use a lot which is, would you rather use somebody else’s framework or write your own and why? And I remember years ago, back when Chuck and I worked at CrimeReports together, we passed on a candidate because he was very senior. He was very, he absolutely could do the job, but his answer was absolutely no compromise, “I have to write the framework.” And I said, “Why?” And he said, “Because you never really understand something until you write it.” And I’m like, “Okay, that’s a pretty fair argument.” But as we talked about it more and more, this person had no concept, I finally just asked him pointblank, “Once you write the framework, why should I use your framework instead of somebody else’s? Now that I’m not you, why should anybody else on the team not write their own framework in order to understand it?” And he didn’t have a good answer. He got kind of angry about it and that’s actually why we flunked him in the interview. It was more of a psych eval than a skillset thing. JUSTIN:  Huh. DAVID:  But there’s a time when reusing stuff to me is absolutely the smartest thing to do. And there’s also a time when ripping the hood off this sucker and grabbing your toolkit and just tearing apart the guts of this thing and going all the way to the bottom, maybe rewriting but certainly tearing the engine apart, is absolutely the right thing to do, right? JUSTIN:  The correct answer to your interview question is of course, “It depends,” right? DAVID:  It depends, sure. And I’m setting you up to answer the same kind of question, right? There’s this need to understand the skyscraper. And sometimes you have to go all the way down to the bedrock, right? You have to go all the way freaking down to registers at the CPU, or even to transistors. Blew my mind the first time an electrical engineer showed me how electrons could turn into 1’s and 0’s. It just absolutely opened my eyes to things. But some days you don’t need to do that. And I would as you as we talked about things like ‘The Social Coding Contract’, when do we pop the hood and tear the engine apart? And when do we pop the hood and build our own engine? And when do we just leave the hood on and use the engine that somebody else has written for us? JUSTIN:  Yeah, that’s a great question. And I think that there’s a little bit of nuance here, because… DAVID:  Oh, absolutely. JUSTIN:  When I’m in that interview with that candidate and he says he wants to build his own framework, I’m not necessarily thinking about the technical merits of when it’s worthwhile to go down to the transistor level. DAVID:  Yeah. JUSTIN:  What I’m thinking, or even the… I am thinking about the team dynamic. But what I’m fundamentally thinking about as a business consultant is like, so what’s the business case?  Presuming you’re going to build this framework on somebody else’s dime, for them to be completely blocked and unproductive until you can go from 0 to 60 on building your own engine all over again. And that’s led me to, and maybe it’s because our particular brand of consulting is we view ourselves first as business consultants. It’s like working outside in on a technical problem, only we pop the stack another level and we really ask, “What’s the business value that you’re trying to get?” or “What real world constraints are you under?” because those tend to drive more. Two different business situations could completely steer you towards, “Man, for your budget and your timeline, what you are best served by is us re-permuting your vision a little bit so that it can fit a cookie cutter CRUD Rails app with traditional views.” Whereas maybe we can have another business client who’s got just a slightly different set of requirements where it’s like, “Man, if we can just make this one very special, different, unusual thing that isn’t served well by a library that solves a very common problem, if we could just write a custom thing that meets your needs narrowly but really well, then you could really succeed in this market where somebody with just the Rails CRUD app couldn’t.” DAVID:  Right. JUSTIN:  You know, that’s almost always, it’s not a technical problem that should be steering that. It’s a… DAVID:  It’s a business one. JUSTIN:  At least insofar as we’re doing it for our profession, yeah. I think it’s the business realities that drive that. DAVID:  Yeah. And I’m going to lob you a softball here. Have you ever had a client where you’ve gone in and in the early game, they’ve got to get to market fast but in the long game, they absolutely need a custom framework? And so, you say, “Okay, we’re going to stand this up on Rails. We’re going to throw a lot of iron at it, a whole lot of CPUs and a whole lot of stuff, and that’s going to get you revenue. But in the next 12 months you have to rewrite the entire Rails stack for what you need”? JUSTIN:  You call that a softball, but man, each… some of those conversations can just be excruciating, upfront in process and later. Because… DAVID:  I didn’t say I was going to throw the soft… I wasn’t going to throw the softball at your head. [Laughter] JUSTIN:  Well you know, you’re right. We’ve had several clients who’ve come to us looking for what they might call a prototype or an MVP. Lots of our clients come in for that. And we are more than happy to abide by the constraints they’re under. Not gold plate stuff. Maybe not test as rigorously as we would because it’s got zero users and if it breaks, it’s not the end of the world. That kind of thing for an MVP can be really appropriate. And if you’re really gifted, I think that there is a path by which you can go from that MVP and typically refactor your way into a successful long-term system. But we’ve had one or two occasions where we have just, I’ve literally sat down with the director of a company and just said, “Please give me permission to delete this repository on this date,” which was about a year out. “And we’ll keep working on it for you up until that date, but you’re going to, not literally assign but maybe should have, promise me I can delete it at this point. Because it’s just not sustainable and I promise you it’s not in your best interest to keep on trying to tack stuff onto this thing. Because it’s changed so often as you revalidated your business.” It needs to be rewritten at that point. If we see that coming, we just try to be as upfront about that as possible. DAVID:  Mmhmm. I think that’s fantastic. There’s a quote that our CEO likes to throw around, Matt Scantland. He likes to say that, “A dirty codebase is a sign of a well-monetized application.” And… JUSTIN:  [Laughs] DAVID:  When you see people just scrambling to get that next feature out, that next feature out, that next feature out, you’re like, “Okay, somebody’s making money here. Or somebody’s desperate to [chuckles] to not burn through their startup capital.” But I like that. Sometimes the right answer is just to keep the goose that’s laying the golden eggs, keep that goose alive, and just refactor and refactor. Refactor that ugly duckling into a swan to stay with the avian metaphor. But sometimes the right thing to do is to just slash and burn and start over, or replace it side by side as you go. These are all fun nuances and it comes back to… let me rephrase the original question. When yo don’t know the framework that you’re going into, should you pick up an existing one or should you write one from scratch, when you understand all the principles behind it? JESSICA:  Justin said something a minute ago that I think relates to this. He mentioned that directs clients sometimes in two different ways. One was for a standard app on a standard framework, and the other one was for a narrow custom app, one that meets your needs and exactly your needs. DAVID:  Yeah. JESSICA:  And I’m wondering. My impression from that is that, maybe the phrase ‘custom framework’ should be an oxymoron? JUSTIN:  Yeah, yeah. And actually, you answered my sentiment when I was going ‘ugh’ to David’s question really, really well. [Laughter] JUSTIN:  And I think that’s exactly it. Only every decade an Ember comes along or a Rails comes along that tries to solve a very broad set of problems that are so common that that broad framework is warranted, right? If there were only 10 projects out in the world that needed to be written in a manner like Ember enables, then Ember itself wouldn’t be worth it. 10 one-off frameworks by 10 one-off engineering teams would be preferable to having all of this community and all of this hullabaloo and an annual conference. But if it’s something that we feel like the web is moving this way and tons and tons of applications are going to be built with the concept of the browser as the runtime, and we need a UI kit for that, suddenly that big framework makes a lot of sense. I don’t think there are very many individual corporations at this point. I think you have to be like Facebook, Google, Apple big to really need your own application framework, anything that’s worthy of the title, capital F framework. JESSICA:  Right. At that point you’ve got so many developers working for you on this framework that it’s approximately public. JUSTIN:  But what does every startup come in and say, get some funding? Like, “We want a platform. We want to be totally different and distinct.” And I think it’s just important to separate the technical aspect and the implementation detail of that from maybe the business reality. JESSICA:  There was a question earlier of when does that understanding that come back to bite you, when does it hurt you to use tools that you don’t completely understand? And there are some obvious answers to that, like as soon as your ORM starts doing n+1 queries and your performance tanks, that’s… JUSTIN:  Sure, yeah. JESSICA:  Yeah, that’s bitten you. Or in our case, it’s when Elasticsearch runs out of memory because we’re querying it in the wrong way, ways it’s not suited for and was never designed to do. You don’t know when it’s going to bite you, which is exactly the problem because that understanding debt represents a huge chunk of uncertainty. JUSTIN:  Well, there are two vectors by which we don’t understand our dependencies, maybe three. One is what are our dependencies? [Chuckles] Part of the talk is really trying to make the case that we understand direct dependencies super-duper well. And we never spend any time visualizing our transitive dependencies. That is to say if you’re not familiar with the term, our dependencies of our dependencies. And so, as soon as we don’t know they exist, of course we don’t know how they work or what they’re doing. But even once you get over the first hurdle of understanding ‘What’s out there? What’s underneath me? What am I standing on?’ the second question of what it’s doing is separate from ‘How does it work?’ And I think that it’s easier to research. And maybe the responsible thing to do is be pretty thorough in vetting what is it doing? How does Elasticsearch work? How does our ORM boil down all of its cool Ruby syntax into SQL statements? Or not how or that it does, as opposed to understanding the exact minutia of how it does its job, right, which is a much deeper, harder question. JESSICA:  Yeah, that’s what you want to abstract away, right? JUSTIN:  Right. JESSICA:  But you do need to know what it’s good at, and please, please, please know what it’s not good at. That was our mistake with Elasticsearch. JUSTIN:  Yeah. CHUCK:  Yeah, unfortunately a lot of times you do wind up learning those lessons as you go. JESSICA:  And I think a lot of the times you can’t know what’s going to bite you when, so you just wait ‘til something does and then dig in, then actually spend some time learning it. Don’t just paper over it. JUSTIN:  Well, and unfortunately, people usually take the easy route. The hard route is diving in deep and learning it. And the easy route is use the phrase, ‘once spitting, twice shy’. Like, look at that thing and be like, “Well, that sucks. I’m going to go switch over to this other NoSQL thing,” and just continually flip-flop across almost partisan lines of whether it’s the language or the ecosystem or the framework or a particular library. How often has a gem let you down or something and then you decided, “Well, I’m going to go google the other gems that do the same thing”? And you find yourself just grass is always greener effecting [laughs] to different dependencies. JESSICA:  Blame the pool? JUSTIN:  Right yeah, exactly. JESSICA:  Or even better, blame the open source maintainer. JUSTIN:  Yeah, I get a little bit of that. [Laughs] CHUCK:  I like that solution. No, I’m just kidding. But anyway, it is a pretty common thing, right, where somebody comes in and leaves an issue on GitHub or something like that and does put the burden back on the maintainer, where in reality, they just didn’t use it correctly. JESSICA:  Do you see a lot of that, Justin? JUSTIN:  A little bit. I think I would be very careful to… I don’t want to discourage anyone from engaging on something like GitHub. CHUCK:  Right. JUSTIN:  Because it takes a lot of effort to put yourself out there, put your own code out there. Even just to, if the maintainer of a certain thing is disproportionately well-known in the community to you, it can take some courage to put yourself out there. I think the most important thing is we check ourselves against a sense of entitlement, like we’re customers when we’re not when we’re posting an issue. And if we just act with kindness and an appropriate level of deference in terms of, “Hey, this is just a question. Maybe it’s a stupid question. Could you help me out and refocus me?” I think that’s a hundred percent valid and I love those emails. The issues that worry me are when somebody makes immediate demands on my time as if their urgency is now my responsibility. And it’s a weekend and I’m in the park with my wife and now I’m sweating bullets because I feel like I just let somebody down on the internet. [Chuckles] JESSICA:  That’s a great point. And it’s really important that part of being a responsible open source user is when we have a problem, put that information out there as a GitHub issue, on the mailing list. Let people know that you had the problem. Best case, you get a solution out of it. Worst case, that’s information that people can use. JUSTIN:  Yeah. Most of our documentation in, Lineman’s the one coming to mind. Jasmine-rails is another project where people will open the same issue 10 times, or somebody will open the issue first and then I’ll get 10 +1’s. And it’s not an issue with the software necessarily. But there’s an easy workaround that we just failed to document. And so, I’ve had times where I’ve literally just moved the advice from the bottom of a readme progressively higher up the readme [laughs] to decrease the number of people, because I can’t expect everyone to read the entire readme even. I don’t think even that’s fair. Just to understand, as that data comes in, how we can better serve the users. JESSICA:  And at that point it’s not bothersome. It’s helpful. JUSTIN:  Yeah, absolutely. JESSICA:  What else can people do to be responsible users of open source software? JUSTIN:  Oh, that’s a great question. You know, I’ll tell you a story and maybe we can link to this in the show notes. Last week, I had a very kind gentleman send me a pull request out of the blue to add a significant new feature to a gem that I’ve got. And effectively what it would do is a totally different mode of operation. So, the 80% main chunk of work this thing does, it would have just branched at that point with an optional configuration to something totally different. But still, completely from a user’s perspective, just as valid. And A, we didn’t have an issue. B, we hadn’t discussed it already. C, it just, it was long and it changed a lot of little style points and other unrelated things like readme and attributions and stuff. And when it came over the fence, I was immediately offended by its very existence because I didn’t expect it. And then by virtue of, now I’m going to have to maintain this branched code forever because I have to test for it, I as a maintainer have seen this show before. And I know how it ends [chuckles] where I have a whole bunch of PRs accepted for this one-op optional stuff. That yeah, I end up maintaining code that’s no longer used by anybody anymore, because I don’t know. And so, what I ended up doing was to try to give him, in the gentlest possible way, the feedback about what it’s like to receive a PR like that. And he responded with utmost grace and understood my point and decided he would just fork and create his own gem with a different theme and host that himself. And I couldn’t have been happier with the outcome. How often does a comment thread leave you feeling really great [laughs] about that type of interaction? JESSICA:  So, by that story, one thing I got out of that story was that you would have been happier initially if the interactions had started smaller? JUSTIN:  Right, because think of it in terms of amount of investment. If somebody spends a ton of time invested in building this pull request, meticulously making every line of code perfect, it doesn’t matter if it was the best, the most well-built thing ever. If it’s the wrong thing, or if it’s unexpected and undesired by the person who’s going to receive it, that just makes it even harder to reject it, right? So, when I got a large pull request that I didn’t expect it made it even harder for me to break the bad news that I didn’t think it was a good fit. Because now I felt like I was just not valuing his level of investment, if that makes any sense. CHUCK:  It does make sense. If somebody sent a pull request to one of my projects and it was a large pull request, my issue would mostly be that I don’t have a lot of time to go and review it, not necessarily even whether or not it fit well. I want to spend my time adding value and doing good stuff for the community and things like that. And it’s hard to take the time out to do that, to go review a pull request when A, I don’t know if it’s even going to be accepted or essentially worth the time to do. And the second thing is, is that I don’t know if I have enough hours to string together to really understand the code. JUSTIN:  Under the surface, it’s a social problem, right? Two people who don’t know each other, who aren’t talking to each other, who have no sense of community or collective ownership of something, slinging code over the fence and expecting a good result seems like a ridiculous notion. And yet, that’s exactly how GitHub is set up to operate from a technical perspective. I think that if we’re good at inviting collaborators early in a project when it’s still on the up and up, it’s still small, it’s still growing, and establishing a broad net of people who are familiar with the implementation levels of our libraries, the downstream, the descent is much less painful as a result. Because on Lineman for example, several of our people at Test Double know it really, really well. And every issue that comes in, there’s five or six people who could very well respond to that. We can share the burden of that kind of stuff. It’s not all on one person. JESSICA:  A library isn’t just code. It’s a community. JUSTIN:  Right. But a lot of developers aren’t necessarily signing up for that when they just push a one-off thing that they need onto the internet. Because who knows whether or not anyone’s going to use it other than you? And I think it’s just, there’s a certain pattern where certain folks, like somebody like TJ Holowaychuk will go and make a bajillion very useful node modules. And there’s no way that he could even act as a commander at the very top over atop all of the other little sub-communities that form. You’re just like a Johnny Appleseed of all these different libraries out there. And that’s certainly one pattern of engagement. But it’s a double-edged sword because there’s no way that you’re going to be able to, at a certain point you have so much baggage in the form of code out there that you could never possibly do a new thing. You’re so beholden to helping and supporting others using you existing stuff. JESSICA:  So, what can you do at that point that’s short of disappearing? JUSTIN:  If you’re trying to build a little bit of community early, obviously you can seek out a new maintainer, broaden it out, and notify people. Even, “Hey, this is unmaintained, maybe stop adopting it,” [laughs] stem the tide a little bit. A lot of times, putting out scary phrases like, “This is an unmaintained thing now,” will itself be a good call to action. I’m not exactly, an example that I’m not exactly sure maps directly to this, but cancan, when Ryan Bates decided to not maintain it anymore I’m not sure what level of communication occurred. But it was clear at some point he wasn’t going to maintain it anymore. Cancancan emerged. And I don’t think that anything like that groundswell of community involvement would have happened had it not been abundantly clear that the maintainers… JESSICA:  And there it is again. It’s communication. JUSTIN:  Funny how that works. CHUCK:  [Laughs] Well, it’s interesting too, because I’ve seen projects where somebody blessed somebody else or anointed them the new maintainer. And then there’s the other project where the maintainer basically just stops maintaining it. And so, then somebody else forks it and starts maintaining it. And then you wind up with three or four unofficial forks until one of them eventually wins out. I’ve also seen it though where somebody forks it because it’s been unmaintained for six months or a year, and then the maintainer comes back and updates it. JUSTIN:  [Chuckles] Yeah. And again, it just all comes back to communication. I personally think that when you end up with 10 forks that are all divergent from each other of the same project, one that comes to mind is GitX, a GUI for using Git on the Mac. And it does a disservice. It’s a failure state to me, because to the end user it’s completely confusing what the right way to use it is. What’s the best fork? I guess I have to read all of these divergent forks. There’s no summary of the differences. If I had fork 8 out of all of these other forks, I’d be talking to the other people who wrote the forks and be like, “I’m going to merge in your stuff so we can make one new meta thing.” Or I’m at least going to write a summary of the difference and the different focuses of all these things. But in general, what we see is just there are all these forks out there and they all have a random smattering of commits on them. And we’re now pushing the cost of understanding the unmaintained state of this thing onto each and every single user, which seems to me incredibly inefficient. DAVID:  GitX actually solves a really interesting problem in a really evil way. [Chuckles] I had a coworker who, we were switching away from Subversion and we were investigating all the various things out there. And I proposed Git. And he put his foot down and he said, “I can use anything as long as I don’t have to learn a command line client,” because he was very UI-centric. He was a designer. And actually, he was a developer but he was very Mac OS X and never opened a terminal for anything. He had GUI clients for everything. And I said, “Okay, sure. Here’s GitX. Go for it.” Or I think, yeah, I gave him GitX. And he opened up GitX and went, “This is awful.” And I said, “Well, there’s also Gitk,” which is even worse. And it solved the problem, because it gave him a GUI. And six months later, we were pairing and he needed to something like fiddle around with the ref log or something like that. And he was doing it all from… fiddling around with the ref log, you already know this person has mastered the command line client, right, and Git internals. JUSTIN:  Yeah. DAVID:  And I hate to say it, but GitX’s purpose I think is to drive people away from GUI clients and into the arms of, the loving arms of the command line client. And I just realized I totally just slammed the GitX project and everybody that’s on it. And guys, I’m sorry. We love you, because we need more things to make Git simpler and more user-friendly. Yeah, at that particular time, this was back in 2010, 2009 or so, and it served the purpose very well, which was to drive somebody to the command line client. JUSTIN:  I still use GitX all the time, now that we’re talking about GitX. [Laughs] DAVID:  Mmhmm. JUSTIN:  But as a user, I have to figure out which fork I’m on, on each and every one of my machines. It’s like… DAVID:  Sure. JUSTIN:  I like the rowanj one, I found to be the best maintained. [Chuckles] It’s got Sparkle updates and it seems to work really well. I love visual. I’m just a very visual person. I like being able to individually use my mouse and stage this line and not that line. DAVID:  Yeah, yes. JUSTIN:  And so, for the very basic workflow I like GitX a lot. But obviously you can’t escape the command line. DAVID:  Staging by hunks is freaking awesome with a GUI client and freaking painful with a command line client. And that’s absolutely true. JUSTIN:  Right. DAVID:  We talked earlier in the show about using something and then it breaks. And then we just drunkenly reel to the other party and say, “This sucks. This rules. And now we’re just going to switch.” And I just realized that I’m unfairly doing that to GitX because my, like a lot of developers who came up through the Microsoft way, my introduction was source control was Visual SourceSafe. And if you used it distributed back in 1996 or so, there was an error message, I’m going to make five people, five of our listeners actually have a convulsion right now. When you walk in and there’s a dialog box that says, “Corrupted file in AAAAAAAB.dat”. When that pops up on your VSS server, what it means is you have lost your repository. There is no repair tool I sure hope you have a backup. And all GUI tools became evil at that point. And I drunkenly reeled to the command line. That didn’t help with Visual SourceSafe. But as soon as I got out of Windows and into, oh, Subversion. Or wait a minute. And Subversion was new at the time. Before that it was CVS. And oh, CVS is so great because it’s all just text. It’s all just plain. And then it’s Subversion. And then Git was so hard and so user unfriendly back in version 0. But I came up through that. So, I came up through Git when it was really hard to use. So of course, all GUI clients are still evil. And I’m content to remain in my command line is best. And maybe that’s not the most productive strategy. JUSTIN:  Maybe not. JESSICA:  But it is the most curmudgeonly. DAVID:  Yes. And that has value socially. Well, it has a value attached to it socially. [Laughs] Jessica, you were talking earlier about trying to predict change. And I like how what you settled on was it’s almost more important how we react to change, because we can’t predict these dependencies and we can’t predict these problems. The GitHub thing, GitHub is very low ceremony, which is great if you have solved the social problem. If everybody knows each other, there’s no ceremony. But if people don’t know each other, you are abandoned. You have no ceremony to support you. And this harks back a little bit to Justin. Because the community I think adapts. And are there ways when, I’m trying not to just retread how to be a good open source user. But specifically, I want to address this issue of the new person, the new developer coming in, especially a junior developer coming into a project. They want to help out or they want to rewrite the whole thing and reinvent the CAP theorem. And they don’t know whether, this guy that dumped this huge thing on you, versus ‘Can I go through and make documentation?’ How do we react to that in a way? How can we improve our reactions, I guess is what I’m saying, so that junior people and newer people, more afraid people, things that ceremony would help with, things that the social problem makes hard, how do we react to that to make those easier? JUSTIN:  Well, I think that one of the big themes of my career up to this point has been that whenever you’re faced with a problem, there’s fundamentally two ways to act. That gets back to Deming’s Common Cause versus Special Cause. Either you can react to everything, every problem that happens, as being like, “Never again. This is terrible. We’re going to implement a process or a procedure or a ceremony and we’re going to prevent this problem from recurring.” Or you can take the complete opposite approach and say, whenever a problem happens it’s like, “Whoa, we can’t predict the future guys. We just have to react really, really well,” which leads to its own problems of being just too reactive and not strategic. I try to do a little bit of analysis to understand, was the thing that caused this problem a special case, a special cause? Is it just this particular person is a problem on the team, wanting to reinvent all the wheels everywhere? Or is it a common cause? Is this systemic? Like, beginners don’t know what to do when they hit our team. DAVID:  Mmhmm. JUSTIN:  And once we get past that level, so assuming it’s a common cause issue, then we have to decide, how do we address this? Do we address…? And in terms of the best prescriptions, I still try to travel really light in terms of process and ceremony. Because the needs of today may differ dramatically from the needs in the future, but also the processes and tools, like something like GitHub (we’ve been talking about GitHub a lot), I think that GitHub is a very lightweight flow. It’s a bidirectional feedback loop. It being so easy makes me treat other people in a more flippant and lightweight manner, because I can just hammer something off to them so quickly. DAVID:  Mmhmm. JUSTIN:  And I have to pause myself, because the tools coaxed me into this very casual tone. So, if I’m going to try to solve a common problem like beginners  can’t work on the team, the first step I probably look for is, what can we do to not just work around or ignore or deal with the “social problem”? It’s probably just to meet them where they are and do a better job empathizing. And the best way that I found to do that is spend a lot of time with somebody. And that’s why I think a lot of teams just immediately go to, let’s pair program with that junior developer a lot, for a long time, over a long stretch of time, until they get their sea legs. And whether it’s a confidence issue or a competency issue, I think pairing is a great way to just level up. I had a fun experience on Sunday. Tenderlove and I paired on just vim for two hours. [Chuckles] And I have tried to adopt vim 20 times. And I’m so visual and my approach to just thinking and visualizing code is so inconsistent with how vim is popularly used that him sitting down with me, me knowing he’d spent 15 years in vi and vim. And him having his own, quirky, interesting approach to everything was just absolutely eye-opening and fantastic. Using his editor more like a browser, really. And pairing with him did more for me in those two hours than five years of angst and social anxiety watching Vimcasts. DAVID:  Yeah. JUSTIN:  And reading and trying to look at cheat sheets and stuff. DAVID:  I like that you basically went to the E word. I’m so sick of empathy. But it’s really the right answer here, right, because you can’t just take a prescription and just apply it. Because if we took all the seniors and made them pair with the junior people for two hours, 9 times out or 10 or maybe 99 out of 100, or maybe just 2 out of 3 it would be a complete impedance mismatch. And it would be a total waste of time. But where you had invested so much time trying to get your teeth into vim, trying to get… you had scattered bits of knowledge I will wager, about how vim works. JUSTIN:  Sure. DAVID:  And you could probably cut and paste and insert a file into an existing buffer and that kind of stuff, but not a good feel. And yeah, that first time you sit down and pair with somebody who really uses vi and you’re hopping in and out of vim, back to the command line, back into vim, back into the command line. You see them start using visual mode and start using nerd tree and you realize, “Okay, there’s a lot more than just H, K, K, L to vim.” And you start to see it. But you can’t, my point, and I’m sorry I’m so rambly, but my point is that you can’t just do that with a prescription. If you take a new programmer and sit them down and say, “Okay kid, I’m going to show you how to edit code,” and fire vim for two hours with them, they’re going to walk away from that with hopefully at most a sheet full of notes. But it’s largely going to be useless to them, because they weren’t ready for that. And you were. And so, that was the right prescription at that time. And given that Aaron was involved, it surprises me not at all to see that some empathy was probably involved of, “You know what? Let’s just sit down and pair on this.” JUSTIN:  Yeah, yeah, absolutely. And I think that to the point earlier about where we stand on this Jenga tower, what class where we in when we started? Were we on floor 47 and people starting now are on floor 63? DAVID:  Yeah. JUSTIN:  What I try to do just to make the very same point is understand that I require empathy to even get, to even remember what it’s like to be at beginner at anything technical. And so, part of the reason I decided to randomly chew off an afternoon to work on vim stuff is because having somebody that’s my senior in a particular category and feeling the experience of what it’s like to receive instruction even at a very elementary level is critical to me understanding when the tables are turned and I’m the more senior person the effect that my words and my tone and the things that I’m trying to convey have on the individual who’s in a learning position. DAVID:  That’s awesome. JUSTIN:  Right on. JESSICA:  Speaking of learning, something you said earlier Justin, I wanted to highlight. You were talking about the eight different forks and how you’re supposed to figure it out. And one of the things you mentioned was at least write up the differences between different forks. And that’s something else that we as open source contributors can do and it’s a small thing that can make a big difference, is when you do that research, when you hit one of those problems, just blog it. Blog what you found. It’ll take an extra hour but you never know. Google will magically find it and direct people to it. You don’t even have to mark it. And then, when you forget what you did and a year later you need that again, Google will find it for you. JUSTIN:  Totally. I think that there’s a theme here which is that when communication is the problem, or social relationships are the problem, it’s best to err on the side of over-communicating. And I think that the people that I see who struggle the most with these issues as users, they tend to be also kind of sheepish about, how often is it the case that somebody’s working on some library but they’re “not ready to open source it yet” or “It’s not ready yet to be public”? Blogging is the exact same thing. You’re putting yourself out there in a way, but no one’s every going to see you until you do. And so, figuring out when that moment is to start pushing stuff out publicly is an impossible to answer question. That confidence is probably never going to come on its own. And so, I think the people that I’ve seen around me that I try to surround myself with are people who at least buy into the idea that defaulting to open and transparency and over-communicating when things are tough. Whether that means shoot from the hip blogging like you described, pushing up a library, opening a question, as long as we’re kind to each other I think that’s always the better default state than holding it into ourselves [chuckles] and developing curmudgeonly status about the state of things. JESSICA:  That kind of blogging is something that you can do to contribute to the community without spending a lot of time outside work. JUSTIN:  Totally, oh absolutely. So, this has been just great. Is there anything else we want to talk about, topic of open sources, before we get to picks? DAVID:  I’m good. This has been an awesome show. CHUCK:  Yeah, absolutely. JESSICA:  Yeah, great discussion. CHUCK:  Alright. Let’s go ahead and do some picks. David, do you want to start us off with picks? DAVID:  Sure. I have two very awesome picks today. The first one is royalty-free music by Kevin MacLeod. We’ve all heard snippets of Kevin’s music. He started years ago just writing music and then just giving it away, public domain give away. He’s got a library out now. His website’s at incompetech.com. And there’s a fun little bit in there. If you go to incompetech.com there’s a section in there on make some graph paper. And that’s actually how I found out about Kevin way back in the day, years and years ago, is you can go there. You can make graph paper of any density. Or you can make hexagonal paper. Whatever you want, and then just print it out on the laser printer. And you’ve got graph paper and you’re good to go. It’s freaking awesome. But he also started making music. And his only requirement is that you give him credit. So, you can see a lot of game demos and a lot of demo movies and little animations on YouTube and whatnot. And they end with this music by Kevin MacLeod. Ze Frank uses some of Kevin’s music in some of his, the show, and True Facts YouTube videos and that sort of thing. So, the reason I’m picking Kevin MacLeod is because, and Kevin MacLeod’s music specifically, is he’s been doing this for free for gosh, a decade? And he finally has put together just a zip file, just a big old tarball of all of his mp3s. And you can get every single one of his mp3s by sifting through his website and downloading the mp3 for free. But you can go to his website and get the zip file and you can give him $49. And you notice I’m not saying that it’s going to cost you this. I’m saying you now have the opportunity to give him money for what he is doing. I paid him for it. He wrote me a nice little thank you note. And I wrote him back and said, “My gosh. I’ve been using your music for so long. I’m absolutely thrilled that I now have a chance to pay it forward. And I’m totally picking you on our podcast next week.” So, he wants to know when it’s going to go live and he’s going to be listening to the podcast. Not that anybody cares, but hi Kevin. So, my tech picks for today is just royalty-free music by Kevin Macleod. Go out. Get it. Listen to it. You can search the site. There’s great stuff. Most of it’s loopable. If you have musical OCD when you’re programming like I do, you can put on a three-minute song just on loop and it will loop back to itself. And you can just play it until your coworkers go crazy, which is a feature in and all by itself. It’s awesome. My second pick is something that hits a lot closer to home. I’m now working at CoverMyMeds which unfortunately does not pay for your medication. But what we do, do is we sort out prior authorization so that if your insurance is supposed to be paying for your medication, we sort out all the paperwork, because a lot of things don’t get paid for. And the founder of our company was a pharmacist who specifically did this because of multiple sclerosis medications. If you have multiple sclerosis you probably have an idea of how much the medications cost. But my wife is on a medication that costs $5400 a month. And when we were on one set of insurance it was a medical benefit and we get it for $60 if we had prior authorization. And then we switched insurance and it became a prescription benefit. And it’s a tier 4 medication. Those of you in the health industry know that what that means is that you have to pay 25% of the cost of the medication. Her medication went from $60 a month to more than our mortgage. And that was just 25%. And my pick today is Rebif.com. Rebif is one of the best medications available. I’m not a doctor. Don’t take this as medical advice. But Rebif is one of the best medications for relapsing multiple sclerosis, which is the kind that my wife has. It’s also extremely expensive. And Rebif does not want you to not be on their medication just because you can’t pay for it. So, I’m going to put a link in the show notes to the Rebif co-pay. If you don’t have insurance, they will give you the medication free for a year. If you have any insurance, they will manage your co-pay. If you’ve got a 25% co-insurance, they will pay it for more than a year. They basically, they want to get your insurance paying for this and get it covered. And they want it taken care of. They want you on this medication. My wife’s been off medication for two months and it has been absolutely tearing me up inside. And we just found this site and she’s now back on her medications. And I am very, very happy to pick Rebif. I don’t know. I didn’t think when I came on this podcast that I would shill for big pharma. But I’m absolutely in love with Rebif as a company, not just as a medication. So, Rebif.com/rebif-co-pay is the site and I’ll put that in the show notes. And those are my picks. CHUCK:  Alright. Jessica, what are your picks? JESSICA:  I have four picks. But I swear it’ll take half the time of David’s. [Laughter] DAVID:  That’s not hard. In fact, I apologize to everybody that Jessica’s going to take 10 freaking minutes. [Laughter] JESSICA:  Alright. First one is for Justin. If you haven’t listened to it yet, Ruby Rogues number 88 with Peter Hintjens talks a lot about how to engage people in the community and make them into contributors and develop that so that it’s not all on you. My second pick is a bit of a shill. So, the Commercial Users of Functional Programming conference is in Vancouver in early September, beginning of September. And the call for presentations isn’t over. So, if you have a 25-minute technical talk on something functional program-y or an experience report, you should submit. It’ll be cool. My third and fourth picks go together. One of the things that I thought a lot about while I was watching RubyConf talk was the difference between aiming for goals, aiming for a specific feature set, versus systems, aiming for good code in a codebase to which we can add new features and delete useless features on an ongoing basis and learn where the success lies. So, there’s a good blogpost on that about how aiming for something in particular can be limiting compared to aiming for a good process of getting to good places. Similarly to go along with that, there’s one on discipline versus motivation that I’ll also put in the show notes. And both of these really boil down to the same thing of it’s not passion, doing what your passionate about brings success. It’s having success makes you passionate about it. So at first, you just do the work and then you experience success. And if you experience success then the passion comes along and you can keep going. So, it’s really about starting with something that you don’t hate and working at it, and then experiencing the success and then you get the positive snowball of work, which I think also ties in with what Chuck said about, have early success. As a learner, do what makes you successful and then come back and fill in the details after you’ve acquired the passion. The end. CHUCK:  Yeah, I think that ties directly into how people got into Ruby through Rails, is that it was easy to get a win. And then they learned and fell in love with Ruby later on. JESSICA:  Yeah. CHUCK:  Alright. I’ve got a couple of picks. I’ve got a couple of books that I’m going to pick. The first one has actually been picked on the show before, but not for quite a long time. It’s called the ‘Wizard of Earthsea’ by Ursula Le Guin. I listened to it on Audible. I’d actually tried to read the book a couple of times in the past and I just couldn’t get into it for some reason. But listening to it worked. And I really enjoyed it. So, I’m going to pick that. And another book, and this one I hesitate a little bit because I know that we have varied political, within the US backgrounds. But I thought it was really interesting. I don’t know if I buy into all of the premises in the book. But I think there are definitely some things that are worth looking into and finding out how true they are and whether or not, and how we want them to change. The book is called ‘Conform’. It’s by Glenn Beck. And so, like I said, a lot of people don’t like his particular brand of conservatism. DAVID:  I can’t imagine Glenn Beck being a controversial figure at all.1 CHUCK:  So anyway, so if you’re interested in that it’s about the education system in the US and points out some of the problems that are out there, which I think are legitimate. And some of them which I need to explore a little bit further before I completely buy into them. So, those are my two picks. Justin, what are your picks? JUSTIN:  Hey, I’ve got three picks and only one is a shill, if you guys allow it. So, first pick. I am not a photographer. But I have a ton of family pictures. And you can basically guess what year a particular picture was taken in based on what model iPhone was currently out throughout my entire, since 2007. And I’m continually frustrated that I just don’t have very many good shots at a wide angle of my life as I experience it, especially when you travel. So, I’ve been in the market for an entry-level amateurish, maybe not DSLR but something of that kind of quality. And thanks to The Wirecutter’s awesome review I landed on the Sony NEX-5T mirrorless camera. If you’re not familiar with the latest in camera gizmos, apparently a mirrorless camera is essentially a DSLR but it doesn’t have the internal mirror inside that enables an optical viewfinder, which if you’re old-school is probably really important to you, or if you’re a proper photographer is probably really important to you. But from my perspective, it just makes it so the thing is so bulky. It couldn’t possibly fit a pocket. They’re also cheaper. So, I picked it up for I think $370 on Amazon. So, significant investment but the picture is especially of landscapes and bigger scenes have been night and day versus my otherwise trusty iPhone 6. My second pick is that there’s this conference you guys. It’s new, up and coming conference called RailsConf that is in April. DAVID:  Wait, what conf? JUSTIN:  It’s the word rails and then the word sconf, rail plus sconf. [Laughter] CHUCK:  Never heard of that. JUSTIN:  Yeah, well you know, this guy named DHH is keynoting along with some [also rands] like Kent Beck. DAVID:  His name is initials? That’s like… JUSTIN:  Yeah. Right. CHUCK:  That’s a funny name. JUSTIN:  [Laughs] So, I am very, very fortunate to share. I just found out that I’ve been accepted to speak at RailsConf. Last year was my very first one. This year I’m doing a quasi-parallel sequel to ‘Social Coding Contract’, the talk that we discussed today. But this one’s a little bit more technical. It’s focused on code. The title is ‘Sometimes a Controller is Just a Controller’. And it’s focused on the virtues of boring code. So, last year DHH talked a lot about software writing, the anti-… TDD is dead, and then a lot of backlash of the pro-craftsmanship people coming at the other extreme. And I felt like there was just no nuance in the m idle for like we were talking about today, like context is everything. And so, my goal is to talk about some of the pitfalls of going overboard and listening to talking heads like me saying, “This design is good and this design is bad.” And it’s that sometimes the right thing to do is just to put things in the right MVC bucket. So, I’m really excited to start developing that talk now. And I hope that if you’re listening and you come to RailsConf, I’d love to meet you and see you there. My third pick is if you like working on cars, I don’t, but if you really like Apple gadgets, I do, the Alpine iLX-007 model aftermarket radio thing is a standalone CarPlay unit for your vehicle dashboard. And I have a friend who works at Ford who was kind enough to drive down and spend a long night with me in the cold tinkering with my car to rip out the factory radio and put in this nice, beautiful touchscreen display and microphone and hook it all up with steering wheel controls and stuff. So now, every time I get in my car I’m really excited because I’ve got a competent device there where I can run my podcasts out of. And what I really like is Siri and the microphone quality is a lot better than my Bluetooth audio had been for calls while I’m on the road. And then most importantly I’m not texting constantly and distracted by twiddling around with my phone while I’m driving, because the device is actually competent enough to let me communicate with others just by voice. So, those are my picks. CHUCK:  Awesome. Well, thanks for coming and talking to us. It was really fun and interesting conversation. JUSTIN:  Yeah, totally. I’m just thrilled to have been invited by you guys. And I really look up to all of you and what this podcast has done for the community over time. And so, to everyone listening, just thanks very much for having me today. CHUCK:  You are most welcome. Well, we’ll wrap up the show on that note and we’ll catch you all next week.[This episode is sponsored by WatchMeCode. Ruby and JavaScript go together like peanut butter and jelly. Have you been looking for regular high-quality video screencasts on building JavaScript done by someone who really understands JavaScript? Derick Bailey’s videos cover many of the topics we talk about on JavaScript Jabber and Ruby Rogues and are up on the latest tools and tricks you’ll need to write great JavaScript. He covers language fundamentals so there’s plenty for everyone. Looking over the catalogue, I got really excited and can’t wait to watch them all. Go check them out at RubyRogues.com/WatchMeCode.]**[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 Blubox.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.]

Sign up for the Newsletter

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