CORALINE:  Hello and welcome to Episode 5. I want to apologize. We seem to be trying to get our stuff together over here and we keep mixing up the name of the podcast. I wrote it down today so I won’t forget. Welcome to Episode 5 of PodcasTRON. I’m really happy to be here with Sam Livingston-Gray.

SAM:  Hi. And you know, Coraline, I really hate to break it to you but I’m pretty sure the name of the podcast is Greater Than Code.

CORALINE:  Don’t fuck with me.

SAM:  So without further ado, welcome Jay to the show.

JAY:  I’m glad to be back and see everyone’s beautiful faces. That actually doesn’t work for podcasts, so I probably shouldn’t say that.

SAM:  Don’t tell them we have video.

JAY:  Let me pass this off to Dave.

DAVID:  Good morning, and no, we don’t have video.

SAM:  This is not the podcast you’re looking for.

DAVID:  Coraline, do we have a guest today?

CORALINE:  We do in fact have a guest today and this guest is going to save us from ourselves, I hope. There’s actually a very good chance you already know our guest today. He is James Edward Gray II, also known by his initials, JEG2. James is an expert in Sucko, a veteran in love, an outlaw in Peru. Sorry, my notes are all confused over here. Oh, here we go.

He’s a reformed Java and Perl developer, and James started the Ruby Quiz site back in 2004. He authored the faster CSV library in Ruby 1.8, which I’ve used in approximately 100% of my interviews, which became the real CSV library in Ruby 2. James was also an inaugural Ruby hero when the awards began in 2008. Then bunch of other stuff happened. Currently, he’s live streaming, blogging, and posting lots of great stuff at GraySoftInc.com and you can follow him on Twitter @JEG2.

Hi, James.

JAMES:  Am I on the right podcast?

SAM:  Yes. Absolutely, you’re on the right podcast. There is no other podcast but this one.

JAMES:  I just wanted to know if I can have you guys introduce me like forever now.

CORALINE:  James, there’s so much we want to talk about. Most of that roll over about your house. Can you give us an introduction to exactly what you’re doing over there?

JAMES:  That’s exactly what I’m going to talk about here. So yeah, I’m building a house for the first time ever, which is kind of an interesting process. It’s a little bit like software development in some ways only the mistakes cost more.

CORALINE:  Are you a software as well as a building architect now?

JAMES:  No. I definitely have a builder and I’m not doing it myself. For people who do it themselves, they’re very, very brave people because doing it with a builder is pretty hard enough for me.

CORALINE:  So what you’re saying is you have a tremendous amount of respect for the Amish. I got it.

JAMES:  Exactly that. Yes.

DAVID:  I actually have an image of you, your builder turning to you and saying, “What the hell is a massively concurrent building?”

JAMES:  Right.

SAM:  It is here all around us, even as we speak.

CORALINE:  What are some of the things that you’re building with your house? I can’t imagine you’re just building a bungalow.

JAMES:  It’s kind of interesting. When you build a house, you do some things because you like the look of them and some things because for functionality. One of the interesting things about my new house is there are no steps in the house, anywhere. Period. Not on the back porch. Not into the garage or anything like that, in which, if you’re in a wheelchair like me, is super cool. But it is surprisingly complex in some ways like for example, garages are typically lower and this affects the slope of the driveway up to the garage and things like that. So you have to do things differently. If you don’t want to step onto the front porch, then your whole front sidewalk has to be sort of a ramp going up to the front porch.

There’s a lot of things like that. As far as fun to look things, I spent a month in Europe several years ago running around touring castles in five different countries and so a lot of the things in my house are inspired by things I loved in those castles that I saw.

CORALINE:  So we are a bunch of programmers here and as you know, programmers are great at naming things. I thought it would be fun if maybe we’ll try to name your house for you, unless you’ve already had come up with something.

JAMES:  Since I just found out I’m an outlaw in Peru, I look very forward to these names. Let’s do it.

CORALINE:  [Laughs] Oh no, you put us on the spot.

SAM:  I vote for ‘Abandon hope all you who enter here’.

JAMES:  [Laughs] Whenever my daughter asks what my name is, I always tell her, “I’m he who strikes fear into the hearts of children.”

SAM & DAVID:  Nice.

[Laughter]

CORALINE:  So that was a leading question, James. I know you named your project. What is the project’s name?

JAMES:  It’s actually just a big gag. I call it Castle GraySkull because my last name is Gray, it makes for a pretty good Twitter hashtag, I think. So, I hashtag all of my tweets about it as #CastleGraySkull but it has become a bit of a running gag when we went to pick out the stone that goes on the side of the house. Our builder pulled out his phone and said he wants it to look like this and I was super curious. When he was showing the stone, it was actually a picture of Castle Grayskull from He-Man.

DAVID:  Right on.

SAM: Fantastic. We were talking about what you’ve been doing with the house. But none of us have had the presence of mind to ask you why on Earth would you do such a thing?

JAMES:  I needed extra stress in my life and more gray hair.

SAM:  Well done.

JAMES:  Yeah, success! Total success! No, my mother-in-law had became quite ill in March and we decided that it was time to change some living arrangements so that we could help out a little bit. I needed a house that was both wheelchair accessible but had a mother-in-law’s corridors or apartments, as they’re sometimes called.

It’s difficult to find those criteria, to begin with. Also, I have Summer in good school districts where she’s studying. Summer is my daughter. So kind of a bunch of constraints there to get the right thing and I decided it would probably just be easier to build exactly what I needed.

I didn’t actually think it was going to be possible at first. I lived in the middle of a town and I didn’t suspect there were going to be lots available where I wanted to be. It turns out there were two and I bought one of them.

DAVID:  Nice. It’s hard to find a castle in a good school district.

JAMES:  Yeah, it is.

CORALINE:  I’m thinking of Edward Scissorhands now where he was like, “Oh, he lives in the castle at the end of the cul-de-sac.

[Laughter]

JAMES:  It’s pretty much where it is.

CORALINE:  It’s really great that you have the privilege of being able to build something to spec that serves your family’s needs, your static needs, your medical needs, and your mother-in-law’s needs. That’s really wonderful.

JAMES:  It’s great. It turns out if you’re in a wheelchair, it’s not a big deal because you can solve all of your problems with massive amounts of money.

CORALINE:  I’m going to try that. How do I get this money stuff that you keep talking about? Is it readily available at [inaudible] store? Reckon trade exposure for money, maybe.

JAMES:  Sort of like that. Just before this call, I was at the money store where I find 90 pieces of paper agreeing to pay all this money back someday, you know?

CORALINE:  Jokes on them, right?

SAM:  I listed a temp job at the money store. I didn’t realize they were still around.

JAMES:  [Laughs]

CORALINE:  This is all really great and we have a ton of stuff we want to talk about James. But I do need to pause for a second because we are PodcasTRON today. We want to thank another one of our ten level patreons — Natron. Nate Vick is from Vancouver, Washington and @Natron99 on Twitter. Thank you, Nate and thank you to all of our awesome contributors.

Just a reminder, if you’d like to support us, we are currently 100% listener supported. Please visit Patreon.com/GreaterThanCode and that link will be in the show notes. Thank you everyone.

JAMES:  Thanks, Nate.

CORALINE:  So James, beside the house, what’s keeping you busy these days? I saw you at a conference talk last year, which I was delighted to see you because you hadn’t spoken in a while. You’re talking about interviewing. What are the things you’re thinking about these days?

JAMES:  Yeah, interviewing is definitely something that keeps me busy. I do some interviewing for No Red Ink, where I work. A little bit of a plug there; we’re hiring. I’ve had to learn a lot about how interviewing works and how to get good at it. I don’t think I was very good at it in the beginning. I practiced a lot of that. I’m still around in conferences but you may not have seen me because I’ve been going to Elixir Conferences.

CORALINE:  I don’t want you to rehash your entire talk but I find your interview and talk really interesting because you really focused on the hard skills that a lot of people struggle with in a lot of tech interviews. As I recall, you gave sort of a, “Here are the things you need to really have nailed down to pass your technical interview.” Do you want to talk about what these were?

JAMES:  Yeah sure. If I do this, I want to preface it by saying, “I wrote the talk for interviewing as it exists today, not interviewing as I wish it existed.”

CORALINE:  That is definitely something important, yeah.

SAM:  Yeah.

JAMES:  Yeah, and it’s a little bit sad. But there are just things that you need to know going into an interview, things like algorithms. That one, I would say that companies are backing off of a little bit, like you’re probably not going to be asked to roll a binary search from memory, hopefully. But it does still happen sometimes.

But I do think, in general, no matter what, you want to be familiar with certain data structures and things like that. You know, you want to be good with a hash, especially using it for things like reading through a document and counting the unique occurrences of words or something like that is a great example of where a hash can just turn something that sounds a little bit scary into a trivial exercise. But yeah, I covered several things like that. The slides are online. You can definitely go look at the kinds of things I recommended.

I will say though, that more important than all of those things, the knowledge you should have going in, I believe is just avoiding basic kind of – I guess I don’t want to use the term ‘common sense’ but let me say it this way. The advice I’ve always heard about interviewing is, “Just be yourself and everything will be fine.” That’s pretty terrible advice. You’re trying to sell yourself to someone. You want to put your best foot forward. You don’t want them to see you just being yourself. If you’re in an interview and things like your computer environment that you’re using is all wonky and you’re having to fight with it, you’re not showing yourself in your best light and that ends up kind of against you, either as a check mark on some sheet or even just as a bias in the interviewer’s head. I think you want to try to avoid those things.

DAVID:  On those kinds of interviews, I like pushing back on the interviewer and kind of check to see if they have a pulse. If they’re giving you a checklist of questions and they’re just looking to check off answers, I will ask clarifying questions and if the only thing they can clarify is, “Well, that’s the question I have on my interview sheet,” then I know I don’t have a live one. I kind of mentally write the interview off. It may not be the best strategy but I think it’s fair to push both ways.

JAMES:  I like the idea of asking questions. I mean, really your whole goal in the interview, you have to get the interviewer on your side. That’s what you’re trying to do. You’re trying to sell them to your cause, basically. You’ve got to start the conversation. You got to get it back and forth going. You got to give them the best within you.

CORALINE:  I’m wondering how that’s good or bad if the interviewer has a rubric that their judging you by. If they have a rubric, it makes sense that maybe they will give you some detail that would help you arrive at their ‘correct answer’, if they have a rubric. But I’m wondering if that could actually hurt you if they don’t have a rubric and they expect an answer and if you ask questions, they might take that as a sign of uncertainty.

JAMES:  That’s a good question that I don’t know the answer to. This is probably another point to say, one of the things about my interviewing talk is that it was incredibly biased to the kinds of interviews I’ve done and been involved in. I sometimes have people write me and say, “You didn’t mention anything like this strange interview I just ran into.” And it’s like, “Oh, yes. I’m sorry. I’ve never run into that.” There are lots of different kinds of interviews out there.

I can say there is kind of a recent trend with a lot of companies to publish their interviewing rubrics online. Medium did this recently and it’s an amazing read. If you have not read Medium’s interviewing rubric, I definitely recommend it. It’s super thorough. It explains like what a strong no and a strong yes is for every single question. It’s really thorough.

I will say that a lot of them I’ve seen, including the one that we use, does have things in it like, “Can we teach you stuff? Are you open to learning?” Things from the interview and then [inaudible]. I think asking questions falls well into that category.

DAVID:  I think I was a little unfair when I said that I would write the interviewer off. It’s actually not true. To answer the question that you pose, Coraline, about what do we do if we run into a rubric. Can we realize we’re being graded on something different than what we thought we were?

I have actually had this happen that did not work out negatively for me, where somebody was just working through a list and I pushed back on it a little bit and I said, “Why are we going through a checklist,” and I found out that their technical people were overloaded and really busy and had to get through like 40 candidates. I realized that my objective in this interview is not to get hired. My objective is to convince you that I have enough tick marks to get through this interview. The interview became very efficient because suddenly, it became less about how can I you know optimize this back end engine, blah-blah-blah, and became more of what are you looking for here and how can I back that up with my experience? So, it changes the tone of the interview.

SAM:  I had one very early in my career where I was interviewing for an Access developer position. I was being interviewed by a third party HR person. The hiring manager had given them an Access database that you were supposed to put your answers into, or you were supposed to write some code in it.

I realized as this person had given it to me that they had given me the original, which included some answers and that they were not prepared to save my copy somewhere else. So after I finished the test itself, I made a pristine copy and I walked with the interviewer through like how to proceed through it with the next several candidates that I assumed that they had.

I got the job and it was a lot of fun. But it was really nice to be able to help the interviewer out too.

DAVID:  Nice.

JAMES:  That’s awesome.

JAY:  That level of transparency, as you mention with Medium, is something that should be commonplace. I know there has been like that move recently, as far as I’ve seen within the last year. But do you think that level of transparency should be there upfront? Then also, to add a second question, if we did not choose a candidate, giving them really sort of actual information about why we did not choose them, what are your thoughts on that?

JAMES:  Yes. I’m a pretty big fan of transparency. I actually saw a really good talk and I think it might have been Rails Conf last year. I’m not sure now. But I saw a really good talk about various challenges with choosing the right problems for interviewing and stuff like that. They recommended giving the candidate the rubric — what you’re going to grade them on. Why wouldn’t you? You know, you shouldn’t be ashamed of what you’re going to be grading them on.

Obviously, Medium is not ashamed. They put it online and is there any reason it’s a secret? Is there any reason the candidate can’t know it? Can I trick them into doing something? Probably not, hopefully, not. If it is, you should probably change your rubric. Transparency at that level, I think is super valuable.

Refresh my memory. What was the second part of the question?

JAY:  Whether or not companies should be providing sort of actionable feedback of why a candidate wasn’t chosen.

JAMES:  Yeah, that’s another great consideration. Our policy is we don’t just do it by default but if you ask, we certainly do it. When you ask, we go back to the particular interviewers you interacted with then ask them exactly what their thoughts are and we tell you that. So yes, I think it’s very valuable.

CORALINE:  I was sort of remembering an interview situation I had a few years ago. I have feelings about inheritance and I could tell that the interviewer was leading me down a path to see if I could model something using inheritance and I got really annoyed with it because I’m like, “Dude, I’ve been doing this for 20 years. I understand inheritance.”

So I decided to be a contrarian and done a solution using dependency injection and composition. The interviewer actually got really, really mad and he kept asking me questions to try and lead me back to inheritance. He’s gotten increasingly flustered because I was basically off the rails, as far as what he was prepared to talk about was.

Finally, at some point, he’s like, “Why won’t you just use inheritance?” So I gave him like a list of reasons that I don’t like inheritance very much, including readability and he’s like, “Well, aside from readability, why is inheritance bad?” And I said, “Aside from readability, I write code for people first and computer second.” He’s like, “What do you mean you write code for people?” At that point I knew this is not the place for me.

JAMES:  No kidding. Wow.

DAVID:  Wow.

SAM:  I had an interview once that was on the flipside of that, where the person that I was interviewing with had a bug that they had run into some months prior. They decided to make that their standard technical pair programming interview question, where they would just lead everybody through this bug. It went in, I think, a different direction than the interviewer was expecting and it was really, really neat to get the feedback at the end that, “Well, that’s really neat. I think I might actually put this into production,” and I thought that was a really nice touch on the part of the interviewer to have that grace to be willing to be open to different ideas.

JAMES:  Our current take home — we do a take home as part of our interview process — and the take home challenge is based on a real problem that we’ve had with the production app. I know that some of our technical interviews also are occasionally based on things we’ve seen in the past.

Interestingly though, you said it when you described it, Sam, you said the session was a pair programming, to use your words, a session over a bug they already knew. That’s exactly pair programming when one person has a whole bunch of contexts and the other person has less and usually you’re expected to show off more on some level. But it always surprises me when we use that language in interviewing.

SAM:  I don’t know, I think there are lots of different pair programming matches, right? Junior-senior is one of those ones where one pair partner can be assumed to have a lot more context about a lot of things.

JAMES:  Yeah, that’s totally fair. I guess, what I meant to say is that it’s not usually a traditional trade back and forth the keyboard. You’re both trying to solve the problem together. It’s more like they’re trying to see how you would solve a problem they are already familiar with which is a little bit different.

SAM:  Yeah, that’s fair.

CORALINE:  I call it ‘screen sharing’.

[Laughter]

JAMES:  Screen sharing, right.

CORALINE:  James, you mentioned that you’ve been going to more Elixir Conferences than Ruby Conferences and that makes me very sad. But I understand that Elixir is kind of I’ve seen you’re interested in these days.

JAMES:  Does that mean I have to leave the call now?

SAM:  No, this is a non-partisan podcast.

CORALINE:  Yeah, exactly.

JAMES:  Yeah, I’ve been playing with Elixir. I’ve been having a lot of fun with it. It’s a super neat language. Interestingly, I think the learning curve of Elixir is kind of unusual because if you’re anything like me, you go to it and you see the syntax and you’re like, “Oh, it’s Ruby-like.” So, that kind of sucks you in a little bit in that it looks a little like Ruby. Then once you get all into it, you realize, “This is nothing like Ruby,” and you kind have to learn things all over again. Super fun language to play around.

DAVID:  James, we have a guest questions channel that we have people come and ask questions and you did something amazing which is you joined the channel before you came on the show and you basically answered everybody’s questions in there.

There was a great thing that you pointed out in there in one of the posts where you talked about how Elixir is actually maybe the best object-oriented programming language. And for anybody who’s looked at this 1970’s era telecom programming language that is absolutely crippled by the worst syntax invented by mankind, how on Earth can you say that about Elixir?

JAMES:  It totally is. I wrote a blog post about this — the idea of what is an object-oriented programming language and we talked a lot about it when I was on Ruby Rogues. Avdi, of course, he’s really into the specifics of object-oriented programming and he would bring up things from time to time.

If you watch his RubyTapas, there’s an old episode — I don’t remember the exact number — where he goes through in and vents basically an Alan Kay version of object-oriented programming inside of Ruby, not using Ruby’s objects at all. Super awesome RubyTapas, like one of those totally mind-bending, you-woke-up-in-the-matrix kind of things. It’s really great but basically, going back to the original principles that Alan Kay was aiming for message passing and things like that. It turns out that this silly little functional programming language with it built in actor model, hits those principles way more strongly than Ruby does. For example, encapsulation is not an option. It’s enforced at the language level. All actors have a separate memory. Period. If you want to send something to something else, that’s a memory copy. You must move it over to the other memory. You can’t not encapsulate things. They are and you have no say in the matter.

Encapsulation isn’t even one of Alan’s principles, to be clear. The idea is that message passing which again is basically enforced at the language level. It’s the only way you can communicate with processes, which are a very key unit of coding Erlang and Elixir, and things like extremely bindable things which leads to pretty much what we often call polymorphism. You very much have that in Elixir and Erlang where pretty much all you have is a process ID, which is basically an object reference in Ruby. All you can do with that process ID is send it some message, literally.

SAM:  That’s really interesting. One thing that Sandi Metz has said repeatedly is that, “You don’t send messages because you have objects. You have objects because you send messages.” Has working with Elixir given you any different insights into that?

JAMES:  I don’t know. I think that’s the first time I’m hearing that quote so now I’m kind of rolling it around in my head. Is it in POODR or something? Maybe I missed it.

SAM:  It might have been in one of her talks.

JAMES:  It’s, “You have objects because you’re sending messages.” That’s interesting. I actually think Sandi Metz would absolutely love Elixir. I’ve even kind of teased her about that at some point. I was like, “You’ve got to try this. It’d be amazing.” But it kind of seems like the whole framework of objects and the things they do is kind of designed around, actually in all modern object-oriented languages, the whole system inheritance, polymorphism, all that is to check all these boxes that we think are what object-oriented programming is. That’s not really what object-oriented programming is. It’s actually about message passing and not knowing what you’re sending the message to more than I’m sending it to this thing and it will handle it. However, it handles it and basically it’s a black box to me. The mechanisms of inheritance and those kinds of things, they don’t really have anything to do with that, which is kind of interesting.

CORALINE:  At my old job at [inaudible] who is kind of a language geek and really in the functional programming. But we didn’t pair in Clojure. We paired in Ruby. A lot of the things that he liked about functional programming, he wanted to follow the same sort of patterns in Ruby so we ended up writing extremely functional Ruby in terms of how the code was designed and how the whole system was architected.

I really found that pairing with him and absorbing his perspective changed the way that I wrote Ruby. Have you done a Ruby lately and maybe found that Elixir has change the way you write it?

JAMES:  Yeah. To be totally clear, I use Ruby all day, every day. I love Ruby. I haven’t defected to the other side.

DAVID:  We’ll be the judge on that.

[Laughter]

JAMES:  Yeah, that’s true. You’re right. I’ll leave it to the panel to decide. But I write Ruby all the time. I do think that functional programming has given me a lot of good ideas to using Ruby. I have used them to certain effect.

I remember there was a situation at one point where I was dealing with a very large data structure that I needed to make super minor changes to here and there and over time and basically know the versions. So, functional programming was basically perfect for that where you keep the old structure, you point the new structure at the old structure minus the one little thing you changed. And I definitely got that idea from functional programming, whereas had I written it in a style before I had figured all of that out, I think I would have been tempted to dupe the giant data structure and then make some small change and eat tons of memory and processing resources and all of that. So yeah, there are ideas that definitely come forward well.

That said, Ruby is not a functional programming language, like it has a lot of elements from them. The iterators and things like that, it has a lot of elements from them. But there are certain levels where if you try to push it in that direction, it will fight back against you pretty hard. Things like immutable data structures and Ruby is not really designed around the idea of immutable data structures. And you can do it to some extent, depending on your level. But if you’re cranking out millions of them in a tight loop or something, then you’re going to pay some pretty hefty garbage collection penalties.

But that said, Ruby’s garbage collection system has improved by leaps and bounds recently. So maybe even that statement, it was old. But you can go pretty far and definitely those ideas are generally applicable, in my opinion, but there is one that’s on – Ruby is not a functional language. If you try to go all in, I think it’s going to cause you a lot of pain.

SAM:  So, one thing that one of my professors said when I was still in school was that, if you step back and sort of squint your eyes and tilt your head to the side, the functional and OO programming kind of look the same. Just as the further I go in my career, it seems like you can sort of transpose one model into another and everything, more or less, has a place. Some things are emphasized, some things are de-emphasized. And what I find interesting these days is how the metaphors that we use and the language design forced your brain into accepting certain metaphors that you can then use to sort of cheat and manage cognitive load.

JAMES:  That’s a great point. I actually didn’t finish my transition story earlier. I said, you can do Elixir and you’ll think, “Oh, it’s just like Ruby.” And then you go so far and you think, “Wow, this is nothing like Ruby. None of my knowledge applies.” And then you learn to squint just right and tilt your head and you’ll realize, “Oh, no. All of my knowledge still applies, it’s fine,” which is great. Yeah, they’re definitely similar and in a lot of ways there’s different mechanism for doing things, different ways to manage things and stuff like that.

I think one of my favorite aspects of functional programming that kind of relates to your idea of managing cognitive load, the thing that seems to trip us up most in object-oriented programming is managing state. In functional programming, they force you to manage state. You have to decide where the state is, where it’s going, how you’re changing it, how you’re moving it forward. So it’s always like a front-level concern in functional programming. You can’t just be like, “Ah, Ruby is in charge of that.” You’re in charge of that. You’re in charge of state and that’s a shift that puts one of the big problems right there, front and center, and I like that aspect.

CORALINE:  It’s really interesting, Sam, that you mentioned the metaphors. I was just talking to someone who does Swift programming and she actually tweeted out that what Swift seemed to do was take a lot really big hairy scary concepts and give them familiar names. “Oh, it was just a struct,” or, “No, it’s just this.” It’s a sort of make programmers not be scared of the programming constructs that were built in the language. So she started to wonder aloud, like was that on purpose and she actually got a tweet reply from one of the language designers that said, “Yeah, it’s absolutely on purpose. We wanted to make the language more approachable so we paid very close attention to the vocabulary into naming things.”

DAVID:  Cool.

JAMES:  I think that’s so true. I had a friend of mine come to me recently and he was building what I would call a simple app. It had a few actions that this app did, just a very small number of things. They said they were stuck and started describing the problem. But in describing the problem, actually all they were doing was describing the abstractions involved. So, I had this abstraction and I had that abstraction and the problem came when I tried to put those two abstractions together. I started asking questions like, “But what we’re trying to do?” I was like, “What was the actual thing?” Sometimes, it’s hard for us to even talk about that because it’s layered in so many levels of abstraction.

SAM:  Was that useful in that conversation?

JAMES:  Yes, absolutely. It’s very useful to peel back those abstractions. Actually, we did an exercise. We had kind of a get together a few friends and we played an exercise where we had that person be the owner and the product developer and they named features. Two of us, myself and one other programmer, we built the app minus the abstractions. So it’s just, “What do you want to do?” And we did that. “What do you want to do?” And we did that. And we built the whole app in an evening, super simple thing using tiny libraries. Once we stripped away all the abstractions, it wasn’t a complicated problem at all.

CORALINE:  I do want to mention really quickly that we have a sponsorship page on our site. You can visit GreaterThanCode.com/Sponsors and help us spread the word. We’re looking for awesome sponsors that can be individuals or companies, or conferences. Anyone who wants to give a message out there and we will give you about 30 seconds of air time on the show. So please, consider talking to your company about sponsoring.

James, you were talking about the fact that you think that and it’s been said before that people should constantly be learning new languages. Do you want to talk about that a bit?

JAMES:  Yeah, I do think it’s really good to learn new languages. This idea is definitely not mine. I got it from The Pragmatic Programmer by Dave Thomas and Andy Hunt. They recommend learning one new language a year, I believe, something like that.

One of the things I will say about learning new languages, I think sometimes people think that it has to be a full-blown programming language that you can use to do anything and that’s just not the case at all. Go all in on regular expression, really learn everything about regular expression. That totally counts. Figure out how to actually use your shell. Can you roll a bash for loop from memory? If not, then you could learn more about bash for sure.

It’s really useful to do so like you probably interact with bash a lot, maybe during your day-to-day development, when you’re talking to company servers, anything like that. I use the term ‘language’ pretty freely as far as what counts and I think there’s a lot of benefit on digging into side languages and stuff. Learn Emacs wisp or VIM scriptor or whatever your particular text editor programs and mess around with that a whole bunch. That definitely counts.

JAY:  Do you think that holds true for beginners as well? Or do you think that they should spend more time in developing a depth of knowledge, as opposed to kind of playing in different stuff, when they first start off?

JAMES:  Yeah, it’s a good question. In the beginning of programming, you’re facing a lot of things. I think probably one of the worst things that I remember from early programming is I have no idea what the compiler is trying to tell me. It’s always just throwing tons of errors about this thing that I don’t understand or that thing that I don’t understand.

So, a lot of that comes from just experience and doing it over and over again, until you’ve seen that error message a million times and you have a rough idea what it probably means. And that, you would actually make worse by switching languages a lot probably because you wouldn’t get that familiarity with the particular errors. Although that said, nowadays, if you’re a beginner and you’re switching languages, you might land on something like Elm or Rust which have amazing error messages.

If you’ve never experienced this, you need to go play with one of these languages. It’s super unbelievable to have the compiler say, “Hey, you got this wrong. You know what? You were probably trying to do this. Here, why don’t you go read this page,” that explains exactly how to do what you were trying to do. It’s great, like it’s programming in easy mode or something.

I definitely understand that as a beginner, you probably want to get a fairly good foothold in one language and maybe even one school of thought. It is a fairly big jump from object-oriented programming to functional programming. If you’re at the Sandi Metz level stage of ‘I understand what I’m going for in these kinds of objects or why I am designing this way’. When you take your first steps into functional programming, it’s going to feel pretty painful because you don’t understand what you’re trying to accomplish anymore. The good news is you’re still trying to accomplish the same things and all of that knowledge does apply after you refocus to understand kind of the functional way of doing things.

As a beginner, I could see trying to get to at least, an intermediate level of skill with a particular language before making a shift and maybe my first shift wouldn’t be the most radically different language I could find. I might try it some similar or really good, not necessarily similar, but have a complementary.

For example, I said regular expression counts. No matter which language you’re using, odds are good. You’re dealing with regular expressions on some level. That can be a good complementary language that you can learn and pick up and use regularly in your Ruby or Elixir or whatever. Probably, you shouldn’t try to learn 10 languages at once when you’re new to programming. That would be painful.

CORALINE:  So I had a question in the Patreon-only slack from Nate Vick who said he wanted to hear about your process for learning Elixir. It’s great to say you should learn a language every year but like how do you actually go out doing that? What’s the best way to approach that?

JAMES:  I think that differs a lot, depending on the person. I’m a little bit old school in that respect. I like to start by reading some giant tome of knowledge, like the Pickaxe in Ruby or whatever the equivalent is in whatever language I’m playing with. Some people don’t like to do that. Some people are more into like the video slice stuff, more like Ruby Tapas and you pick up little bits as you go. Others like to just start playing with the language and kind of dig into the deeper side of it as they run into things, so get more of a cursory knowledge and then dig into individual segments as they come up.

That’s cool, like I think all of those are valid and it has more to do with how you learn best. But one thing I would say is you got to get the language a little bit under your belt before taking on like ancillary stuff. In Ruby, I would recommend getting a little bit of Ruby and understanding before you go all the way to building Rails applications, where you’ve got those extra layers of abstraction involved.

Again, it’s like managing cognitive load. Am I doing this because it’s required by the language, because it’s required by the protocol I’m talking over right now, because it’s required by the framework that’s managing all the stuff, or whatever? I think it helps to get the base language then move into things at Rails. In Ruby’s case, the OTP. In the case of Elixir, Nerves if you want to put Elixir on robots which is extremely fun, by the way.

Then after you get there, I like to try some small problems, maybe exercism.io style problems. Katrina has got an amazing thing going on at exercism and you should totally try those, if you haven’t. That said, exercism excels at that early phase learning where you’re just trying to figure out the basics of the language. It will not help you figure out the concurrency model. In Elixir or Erlang, it doesn’t go that deep. At that point, you’ve got to go somewhere else.

At that point, I recommend that you try building some substantial thing with that particular language you’re learning. I got asked in the Slack, “What is the substantial thing?” It just means something that (1) you care about and you invested in but also, (2) it needs to be of a certain size. Not that it’s a daunting project but that it will cover several aspects.

One example that was given in the chat, not by me is an IRC bot. I think that’s almost perfect level of difficulty, like you have to do some things like person commands as they’re coming in, and respond to events and things like that. It covers a few different areas and is a good bit of knowledge. But an IRC bot is something most programmers can write in a couple of days until you have the five million commands to [inaudible], put mustaches on cat pictures or whatever.

SAM:  For people who are a little bit newer to programming, for whom an IRC bot seems a little daunting, one thing I also suggest to people is writing a recipe database because you can start off with recipes and ingredients and maybe add categories, and then maybe add stores that sell those ingredients to build your shopping list and you can expand on it but you have like a small core that you can start from.

JAMES:  Yeah, try not to bite off something you couldn’t do in a week’s worth of time. You know, give it in scope. Programming is hard enough on its own. Don’t make it any tougher than it needs to be.

CORALINE:  That’s a good advice. Okay, James. We got a question from one of our Slack patreons, Trevor Bramble who asked, “What’s going on with Codalyzed? Are there any new videos on the way? Related: the first video discussed “less code”; has your focus on it changes as you’ve moved into new languages and their ecosystems?”

JAMES:  I think we need definitions there because there were a lot of new terms thrown out. Codalyzed was a video service that I kind of started up for a while, where I made videos. It never really went anywhere and it’s gone and not around anymore. But one of those videos, I did talk about the ‘less code movement’ and that is a little bit controversial of a name, I guess. But the idea that we should build software with a minimum amount of [inaudible] required, just that. Like we should figure out, “This problem needs just this so I’m going to apply just this much of fix and just eke over that line and that’s all I need in this particular case.”

So what Trevor is asking is how do I still feel about the ideas of ‘less code’ and using the minimal amount. I have to say that I believe in them more strongly today than I did when I made that video. It’s really important to use the minimum level of machinery.

For example, that example I was given earlier where we were talking about abstractions. I was trying to steer the conversation to what we were actually trying to accomplish. It turns out that the less abstractions involved, the easier the process is. If you’re making a literally three-page web app and the first thing you do is Rails new, is that a good decision? If you have three pages in your app and you do Rails new and you inherit that giant dependency tree, is that a great move? I don’t know. It seems like your tool complexities way out pays your needs. I think we should consider that.

At one point when we were building the app to show how we could remove all the abstractions from this app, we decided that we needed an auth system. But then after asking a few more questions, we realized that only one user would ever log in. So we’re like, “Okay, let’s put it over HTTPS and use basic auth,” and we don’t need users or anything like that.  Then we grabbed the tiny library, and when I say tiny, I think it was under 20 lines of code for handling basic auth. That way, we barely had one particular assumption that didn’t work in our case. I can’t remember what it was now.

I looked up how basic auth works. If you’ve never done this, you should do it. Basic auth is not some complex system. It’s a magic status code in a header that your browser gets and then it’s like, “I should show a dialog, asking for a username and password.” And it happens and that comes in with your request. You can understand all this stuff.

But imagine trying to understand how basic auth works, if step one is dig through the hierarchy of middlewares that Rails added to the call stack, then it’s a very complicated thing. But if step one is crack open, this 20 line library and look at what it’s doing, then you’re a lot closer to what’s actually going on and you can figure it out.

I worry that my answers have been very like a negative Rails here. So I just want to stop and say I have absolutely nothing against Rails. It’s an amazing tool. I use it every day and there are a lot of cases where you need a lot of those layers of abstraction which is why they [inaudible] obviously. But you don’t always need those layers of abstraction and I don’t think we’re good at judging when we do and when we don’t.

CORALINE:  Talking about like cracking open the library and looking at this 20 lines of code to see how it works, kind of made me think about whether we relied too much on black boxes to say, “Oh, I have this need and there’s this thing. I read the ReadMe and I know it will do what I need it to do and I don’t really need to understand the underlying problem.” Do you think there’s a balance to be struck between taking the time to understand the underlying problem versus just solving the problem with an available tool?

JAMES:  Yeah absolutely, like going back to Jay’s thoughts about what about when you’re a beginner. When you’re a beginner, it’s so tough because every rock you pick up in the programming world has an Alice in Wonderland style hole under it. Yet you pick up all the rocks because you get overwhelmed and lost way too quickly. So you have to take a lot of things going at kind of the black box behavior. When I do this, this happens. And I’m just going to accept that as the way things are and I’m going to accept that I don’t know what basic auth is because I’m still trying to figure out the difference between get and post or whatever. That’s totally fine. But at the same time, there’s a flipside to that. If everything is always handled for you, then you can only do the things that are on that list.

This was a question I got asked early on in building a product for a Rails consultancy I worked in, in the early days. And I remember there was a particular requirement to do with file uploads. I don’t remember exactly what it was. And we were in a meeting talking about how we were going to accomplish it. And one of the programmers said, “I don’t think Rails does that,” and I didn’t even fully understand the problem. But my response was, “Rails does whatever I tell it to do.” I wish I could find a way to get around it to bypass Rails or fill as possible to do it with an HTML file upload, then you can do it in Rails, I promise. Whether or not Rails is going to auto-magically handle that for you, that’s a different story.

But part of it is learning to understand these things. I mentioned IRC at one point — making an IRC bot. One of the neat things about working on an IRC bot is you can go read the RFC for the IRC protocol. It’s actually understandable. It’s not very complex. It’s just certain messages that are sent at certain times in response to certain messages.

A lot of programming is documented like that. The basic auth thing I mentioned is just a series of RFCs or documents. RFC means Request for Comment. Is that what it is?

SAM:  I believe so, yeah.

JAMES:  It’s an informal kind of documentation that we kind of use formerly. I don’t know. It’s a little bit strange. It’s basically like people say, “Hey, how about we do it like this,” and that ends up becoming how we do things on the internet and stuff. But they’re usually fairly readable. There are definitely exceptions depending on which ones you’ll go into. But they have pretty good language and you can understand these things. Deep down, we know this at some level. Most code schools teach Sinatra before they teach Rails. Why? Because they want you to understand the HTTP interactions that are going on, on some level. I think that would be my reasoning.

SAM:  It makes sense. One of the things that I kind of like about the idea of less code is this focus on understanding and minimizing your dependencies. But as I find myself writing medium to larger applications, I’m wondering if there’s a way that I can take that ethos and bring it into the app design itself or is less code really more about your dependencies and less about your app itself? Or am I misunderstanding something?

JAMES:  No. So, don’t write bigger apps. [Laughs]

SAM:  But I have users and they have needs. [Chuckles]

JAMES:  Yeah, right. This is totally true. Actually, there is a really good talk on this that I just kind of got into yesterday. And I say ‘really good talk’ a little bit hesitantly. The talk style is not the best. It’s a little bit like the person is talking down to you when you watch the talk and I don’t love that. I want to put that caveat in front of it.

The message is pure gold — the message of the talk, totally pure gold. It’s basically about what we should do is we should design more little things talking to each other and communicating. We’re kind of going full circle on this whole discussion today — these little things that communicate in each other.

For example, in Elixir — ha…ha…ha…I got that there — you have these processes that are running and I mentioned that it forces you to manage state because you have to divide these things up in little processes. All they can do is talk to each other. But that holds true in all of programming. Why do you love UNIX? Because it’s just a bunch of little things that talk to each other. You do this little thing and you hand it off to the next person in the pipeline and they do their little thing and then they hand it off, et cetera, et cetera.

The style of design is big enough to go all the way. We have many names for it. Perhaps you’ve heard of microservices which are super popular nowadays. It’s how you divide a web app up into a bunch of little things. The definition of these things can be recursive. If you build the small thing reliant on small things, and then you can build another small thing reliant on those small things, if you climb up the tree that way, you can go all the way to super complex app, built out of small understandable pieces.

CORALINE:  Which is the promise of OO, isn’t it?

JAMES:  It’s the promise of computing, I think. OO is trying to get their functional programming, it’s trying to get their microservices, it’s trying to get their operating system design. We’re all heading to the same place.

SAM:  So, what’s in their way?

JAMES:  Yeah, that’s a good question. What is in their way? That is a really good question. Why do we struggle with this aspect of design? I don’t know. I think in some ways, our tools encourage us to put that coupling there just naturally. We think it’s easier for us to just put that bit in there and keep growing forward, where is one of the things I said I liked about Elixir is how it kind of forces you to think about state and coupling because you have to put the state in a process and the coupling happens between processes. So you have to kind of design that. You can’t ignore it.

I think that would be my answer is that we have to shift our focus to thinking about the design of things and where the state’s going to be and how those parts are going to get passed around and we need to find ways to move that more, front and center, I think. But it’s hard for us humans. It’s very hard for me, anyway.

CORALINE:  It’s absolutely true.

SAM:  I wonder if maybe taking a stab at answering my own question. So you mentioned Elixir’s design constraints that forced you to confront the problem. I wonder, maybe what’s in the way of all of those noble goals is us and our bad habits.

JAMES:  You know, also I think, a little bit of it is having so many choices. I’ve actually toyed with the idea of going back and making a…I don’t want to call it a fork at Ruby. But like a version of Ruby where I ripped down like…I don’t know, two-thirds of the language?

[Laughter]

JAMES:  I think I could benefit from a lot less choices. Instead of being able to make any kind of object in the world, what if we could make three different kinds of objects. You know, like your pure data object and your transformer object that takes in one kind of data and spits out a different kind of data or whatever.

Sometimes the infinite array of choices leaves us to an infinite array of responses which is big and complex and can go in any direction. Whereas, if you narrow that field down and build small things that are kind of predictable, little programs that take in some data on standard input and put it to standard output, for example like UNIX programs do, then you have less choices about how things can go and those constraints can be very helpful.

CORALINE:  Thank you so much, James. This has been really a fascinating conversation and you’re one of my favorite people on the internet. I’m so happy that you’re on the show with us today. What we like to do as the theme on the show is sort of reflect on what we talked about and talk about what are our personal takeaways and maybe call for action for ourselves or for our listeners. Who would like to start us off today?

DAVID:  This is actually pretty easy for me. James denies this but I swear, I learned this from him. I learned it from watching you, James.

[Laughter]

DAVID:  But programming, it’s a dangerous drug. Not even once. But a couple of years ago, I swear I heard this from you, which was a trick for learning the ins and outs of a language and I went and I set my home page on my web browser to the documentation page for Ruby’s Enumerable Module.

Every time I opened the web browser, I got confronted with Enumerable and it’s a big page. There’s a bajillion methods in there. Each time I open my web browser — Okay, honestly, 90% of the time, I had to ignore it and move on. I got really good at ignoring pages. That’s a skill that I learned. But the other 10% of the time, I would start browsing down. I would learn new things. There are lots of great stuff. I found myself then going, “Well, wait a minute. Where’s min_by and max_by? Is that in the Enumerable or is that in –?” And I’d go and I’d look and find something in array, which is a subset of Enumerable.

Now, I couldn’t tell you if min_by and max_by are in there. If you don’t know these two functions, that’s my call to action to you — go look up min_by and max_by in Ruby. They’re freaking awesome. Stop doing max and followed by an index.

JAMES:  There’s also a min_max_by.

DAVID:  Oh, my. Are you kidding me?

JAMES:  I did not make that up. It’s real.

DAVID:  Does it return a pair?

JAMES:  Yes.

DAVID:  Awesome! And if you want to know what that means, go look it up because those are awesome methods.

JAMES:  Actually, that does sound exactly like me. Whatever steps I left out, when I’m learning a new language because I thought others might think it was slightly odd, I love to read through the entire core of documentation of a language. People think like, “What? You’re trying to memorize the whole language?”

No, I’m definitely not doing that. What I’m trying to do is get a feel for what the language provides to me. What is in there? What’s there for me? What’s so important that it was built into the language itself? You can learn a ton about a language by reading the core documentations.

CORALINE:  Jay, do you have any thoughts?

JAY:  I do. I’m kind of thinking through as many things has been said. I’m kind of reminded of a TED Talk or a book on the Paradox of Choice. It’s a position that I get myself in quite a bit. What do I learn? There’s a lot of things to learn? I remember one of our interns one time asked, “Which JavaScript framework should I pick up next?” Because there’s tons of them. So I think one of the things that has been kind of helpful for me in being in a space and being around my Ruby heroes — you folks, is just getting a better understanding of what next step should be for new people, for people who are new to the industry like myself.

I think what I’m getting from this is kind of a general sort of learning. Also I want to throw it in here a quote. I didn’t get to ask about it but one of the things that you mentioned, James, on one of your talks was we can only accomplish so much, so get social. That would be kind of my call to action for people. As you’re figuring this stuff out, what direction to sort of go in, what to pick up next? What to do? A big part of me kind of figuring out next steps has been to surround myself with people who know a whole lot more than I do and it’s been extremely helpful.

SAM:  The primary thing I’m going to take away from this conversation is a profound sense of my own inadequacy. [Chuckles] But seriously, I have been feeling for a couple of years now, like I’ve been sort of stagnating in my professional development as a programmer. I like Ruby a lot and I think I will continue to like Ruby a lot. But I really feel like it’s time to expand my brain again by picking up Elixir or possibly Elm, which is bizarre, especially to be thinking about Elm because I’ve been avoiding JavaScript for as long as I’ve known about it. This has been really motivating to pull on that thread a little bit and maybe step up my own actions a bit.

JAMES:  Elm is totally worth your time, as another person who has avoided JavaScript his whole life.

SAM:  Well, It’s not just JavaScript. I also avoid frontend entirely.

JAMES:  I promise. After playing with Elm, like I really enjoy doing frontend stuff.

SAM:  Wow, okay.

JAMES:  It’s great.

CORALINE:  I feel like I’m kind of in a similar place as Sam. I feel like I’ve been doing a deep dive on Ruby for a number of years now. I’m trying to achieve comfort of mastery of the language and I have been avoiding using other languages. But people around me are so excited about so many new things like Swift and Elixir and Clojure. I think I need to get off my butt and actually learn a new language. So James, you have been inspired me to do that. Thank you.

JAMES:  Yeah, you bet.

CORALINE:  James, do you have any reflections on the show today?

JAMES:  I learned nothing. No, I’m just kidding. Coraline, you said early on in the show that I’m very privileged and you were talking about being able to build a house. But actually, I think my privilege comes from that I have some of the best friends in the world and they do things like invite me to come on podcasts and just talk about these ideas for an hour. I haven’t done that in a long time and I forgot how amazing it is that now I have 400 things I need to go do right now because they’re all in my head, and I totally can’t because my house is being shown in like an hour. So, I have to clean up and get out of here so that it can be shown.

But I’ve forgotten how much I love these conversations and how much it helps me relate all the different things that are of interest to me and that what I’m working on and how in having this back and forth, I realize, “Oh, that’s just like this other thing I was thinking about,” or stuff like that, and how it really gets my brain going. So, all of my favorite people on the internet are in this call right now and I’m super grateful that you invited me to be on here and do this again. I remember how much I love it. So, that’s my takeaway.

CORALINE:  James, it has been an honor and a delight to have you on the show so thank you very, very much for joining us and you’re welcome back any time you have some ideas you want to talk about.

SAM:  Absolutely.

CORALINE:  We’re going to wrap up Episode 5 now. We are on the iTunes music store now, under the podcast directory. If you like our show, which we really, really hope you do, would you please take some time to leave us a review on iTunes. We have sort of unstated goal that we want to make a new [inaudible] list and you can help us do that by leaving us positive reviews. Please think about taking the time out to do that.

Also, we are listener supported and we are fast approaching our goal of being able to sustain the development of two podcasts per month, even though we’ve been coming in more frequently than that right now. That’s sort of just where we’re starting out. We have a goal of $950 a month in Patreon support and we’re getting close to that but we could really, really use your help. Go to Patreon.com/GreaterThanCode if you like the podcast and you want us to keep going. Without having [inaudible], thank you all. It’s been a wonderful experience talking to James today and with my fellow panelists. And I hope you’ll have a great day.