02:25 - Kyle Simpson Introduction
- Front End Masters 16:20 - Inheritance and Delegation29:40 - Evolving a Language36:23 - Cohersion
- Weak Typing, Dynamic Typing
- The Width Keyword 54:33 - Developer Education Programs and The Skill of Teaching Picks
- Adam Tornhill: Code, Crime, Complexity: Analyzing software with forensic psychology @ TEDxTrondheim (Aimee)
- Your Code as a Crime Scene: Use Forensic Techniques to Arrest Defects, Bottlenecks, and Bad Design in Your Programs by Adam Tornhill (Aimee)
- Planet Money Episode 704: Open Office (Jamison)
- Zooko's Triangle (Jamison)
- The Barkley Marathons (Jamison)
- React Rally (Jamison)
- X-Men: Apocalypse (Joe)
- America's Got Talent (Joe)
- Overwatch (Joe)
- Stack (Kyle)
- Jeremy Keith: A web for everyone (Kyle)
- Jeremy Keith: Regressive Web Apps (Kyle)
JOE: Let's roll.
JOE: And Jamison Dance.
JAMISON: Hello, friends.
JOE: And I'm your host, Joe Eames. And we have a special guest, Kyle Simpson.
KYLE: Hello everyone.
JOE: Kyle, we always like to start off with a little bit of an introduction to our guests, so could you take a minute and introduce who you are and what you do and why we would care?
JAMISON: Where does the name getify come from?
KYLE: [Chuckles] Yeah, I get asked that frequently. I wish it was a more interesting answer. But back in 2006, late 2006 or early 2007 the Ask.com search engine, I don't even know if anybody remembers that, but Ask.com…
JAMISON: Oh, yeah.
KYLE: [Chuckles] They for whatever crazy reason decided to do a series of TV commercials. And the theme of that TV commercial was the word 'getifaction', like getting things and being satisfied with them. And the very first time I saw that I was immediately inspired with the verb form of that word, getify. And I started thinking about how that can kind of describe what I see myself doing which is going out and getting information, bringing it back, and making it useful and acceptable and accessible to people. So, getify became my company name and when you're just a one person company, the company name becomes your personal brand, too. So, that's where getify comes from.
JOE: Very interesting.
JAMISON: Well, it worked out really well for Ask.com. So…
KYLE: It's worked out alright for me, too. [Chuckles]
JAMISON: Glad to hear it.
JOE: Yeah. Jamison, you still use Ask.com, right?
JAMISON: Yeah, yeah. A couple of times…
JOE: Big fan. [Chuckles]
JAMISON: A couple of times a day. Yeah.
So, I'm interested in what made you… I guess you touched on it a little bit but were you kind of getting bored of development or were you just excited about the idea of teaching? What made you decide to make that change?
JOE: And as a ride-along to Jamison's question I'm not sure if you specifically said this but do you teach full-time now? What do you do active development wise?
So, how did I get into teaching? Well, I had actually been a developer for quite a long time as I said. And I noticed that I was not a very good employee to be honest. I had a bunch of different jobs that I switched, I kept moving from job to job to job and I wasn't happy at them. And I don't think they were as happy with me as I would have liked, which just meant I wasn't a really good fit. And I kept thinking, “Well, it's their fault.” They interview me, they say this is great. And then six months in I'm not a good fit and I leave. And I kept trying to blame that on the employer but after the 20th or so job jumping around it started to occur to me that maybe there were some things that I was missing. It should have occurred to me a lot earlier, probably. But it occurred to me that when I look back there were several things that I was trying to do with where I was working. I had a strong desire to give back to those companies and to try to push them forward with different ways of thinking about things.
So, I was actually an independent consultant and out of the blue, this guy named Mark contacted me. He had started a company called Frontend Masters. And he said, “I've seen you do some conference talking. And you're pretty good at that. Would you ever consider teaching? I actually had some experience, quite a bit of experience teaching but entirely in a different realm of my life, not in the tech industry. And so I said, “Well, I've never really thought about it or given it much serious thought. I don't know if I'd have enough to teach an entire day. But maybe.” And he said, “Well, I want you to come up and teach a one-day workshop because I think you can do it. So, I flew up to Minnesota and the night before I was terrified that I wasn't going to have enough slides. I was very paranoid about running out material after only a couple of hours. And I stayed up really late and worked on everything.
And then the next day as I was presenting, sometime around the middle of the day I looked out while the students were working on one of the exercises. And I took stock of where the slides were and where we were in terms of progress. And we were right on track. We were exactly where we needed to be. And I knew at that point that we were going to table or continue and finish out the whole day. I saw the students working on the stuff that I was presenting and I saw those light bulb moments happening with the questions that they would ask. And I realized, this is what I've been looking for, is that opportunity to give back in a way that would be well-received. And that's what clicked. And I said, “I want to do that from here on.” So, I've been teaching ever since.
JAMISON: What did you teach before?
KYLE: Ah. I actually was a volunteer youth pastor in my church for a number of years. So, I taught junior high students. And I think if you can talk to junior high students and keep their attention for 15 minutes and them not try to shave your head then you can probably talk to just about anybody in the world.
AIMEE: You are really talented at teaching. I think there's, you could say you are a teacher and you're just sharing knowledge. But I feel like from reading your material, you're not just sharing knowledge. You have figured out ways to break down complicated topics in a way where they're very easy to understand. So, I don't know. I just thank you for that. And [laughs] I don't really have a question there. Just like, a statement for people who haven't looked at your material yet. I frequently get questions from junior developers about what they should learn and what are some good resources. And every single time I point them to your stuff, because I feel like there are a million different blog posts about closure and things like that and reading your stuff, hoisting, reading all of your material makes it crystal clear. [Chuckles]
KYLE: That's very kind of you to say. I appreciate that. I would expound on that a little bit just to give a little bit of background here. I was growing up, my dad, he still does this, he's a financial planner, investment sort of person. So, he works with people's taxes and businesses and stuff. So, I grew up around that. My sister went into that same line of work. So, I grew up around people talking about money my entire life. And money is one of those areas that my dad always used to say people don't know enough about how to manage their money. And they don't just want to walk into an office and give a bunch of their money to somebody and not know what's happening. They don't understand it but they can't go to school to become an accountant or something. They need somebody to break it down for them.
So, he had that heart of a teacher and that was his way of treating his clients with respect was to say, “I believe that you deserve to understand how we're going to manage your money and how we're going to it well.” So, he always taught me that the best way to share with someone, the best way to be useful to that person is to teach them, not to condescend them, or not to believe they can't possibly get it so just skip by it like, “Okay, I'm the money guy. You let me do it and don't ask questions.” He did the exact opposite. So, from a very young, early age I felt like teaching other people was part of an ethic that was built into me, to give back, to share what I know.
And then when I got into college I further learned the value of teaching. And I enrolled in a class, an engineering physics 3 class in my freshman year which was a really dumb idea because I wasn't ready for it. But the AP test said that I was ready so I took it. And the professor walked in the first day and he was like, “I've been asked by the CS department to weed out 80% of you and I intend to do my job.” He sort of set the expectation…
KYLE: That this was going to be a really difficult class, and it was. He was being honest. And most of us in the class were probably destined to get really bad grades or not pass at all. But I saw that as an opportunity, as a challenge. And so, I went and hired one of his former teaching assistants to be my tutor. And every week on Tuesday I'd get together with that tutor for an hour and a half and that tutor would sit there and show me how to solve problems from that professor's previous tests. He would explain the principle and how to think about the problem and how to solve the problem. So, that tutor would teach me for an hour and a half. And then every Wednesday night at 8:30 we got together for two hours and I ran a study group of other students in my physics class. And I shared with them the same thing that the tutor had taught me just the day before.
So, what that taught me was that I was really learning it not because of what the tutor was doing but because of my experience teaching other people. That's how I really learned it. And it turns out that it was pretty successful. I didn't know what I was doing really at the time. But it was successful because I ended up being the only student to get an A in that class. But that is not because I knew this stuff ahead of time or I was somehow innately a genius or anything like that. It's just because I decided to make sure I really learned it. And one of the most effective tools for that was teaching other people. So, when people say that old adage like you don't really know something until you can explain it to somebody else, I deeply believe that. I really, really deeply believe that that's the most effective way to learn. And if you can't do that, then you should be looking for opportunities.
So, even though someone like me might have the job title of teacher and it may seem easy for me to teach, I actually maintain that everybody can teach as a matter of practice of the way that you conduct yourself. Whether that is the code that you're putting out on GitHub, whether it's at your job running a brown bag lunch because you spent some time learning or reading a blog and then you want to teach other of your coworkers, whether it's using code review in the culture of your company as a way to teach and help everybody learn and all boats rise with the tide sort of thing, and half a dozen other ways. There are all different kinds of ways for us to go outside of ourselves and to explain to others the journey that we're on.
AIMEE: That's awesome. You're making a difference in my journey as a developer. And I know first-hand some of my friends as well. So, that brings me to another question I have. I think the very first time that you really came up on my radar was actually a friend of mine, Sarah [inaudible] who lives in New York. And her and I were doing some stuff together on Saturday morning. And she said, “Oh, you need to check out these books by Kyle Simpson.” And at that point I had already, I felt like I had really understood the prototype chain from the process of going through a million blog posts and finally finding one that clicked. But as I was reading through your material on it I was like, “Oh my gosh. If I had read this the first time around instead of the trillion other things that I had read beforehand, I would have saved myself six months, something like that.
And what's different about me, whether this is a good thing or a bad thing is debatable, what's different about me is that those things don't really fit with me. I don't just read something and say, “Oh, well that automatically fits with the way I think.” I have to digest that, break that apart into a whole bunch of pieces, reassemble those pieces, those basic principle and concepts and I have to reconstruct it. And many times when I reconstruct it, it's going to end up looking quite a bit different than just the way that it's always presented to everyone.
So, then we fast-forward to what's happening with ES6. Because you can model something similar to classes on that delegation system and just hold your nose or squint at it when there's weirdness or behaviors that don't make a lot of sense. But then you start laying other syntax on top of it because you want to get rid of all those syntactic weirdnesses. So, now we have the class keyword being added as of ES6. And I see that as a doubling down on the misrepresentation that this mechanism is a class. And my evidence for that is that there's, if you actually dig in, if you don't just take classes at face value but if you dig into them, there's a whole bunch of weird corner cases that are totally inexplicable unless you understand the fact that we're really just trying to put some nice pretty makeup on top of something that's just fundamentally not a class system. They really are opposite.
JOE: Are any of those corner cases things you could talk about now?
KYLE: Sure, yeah. Absolutely.
JOE: It sounds super interesting.
KYLE: Yeah, so again this is getting really nerdy. But in classical inheritance one of the most important principles of classical inheritance, the way we design software, is to do what's called polymorphism which is to take a method and define it in A and then in B define a method of the same name and override that behavior in B and perhaps even access the behavior in A. And the way we access relatively up the class chain is to use the super keyword. That's how we make what's called a relative polymorphic reference. We take whatever level of the class inheritance chain [inaudible] and we just simply go up one level and ask for the version of that behavior, that method, at that level. So, you've certainly seen, if you know class [inaudible] code, you've certainly seen the use of the word super either in the constructor or in one of the class methods to refer to the parent version of that constructor method.
JAMISON: Yeah, I have so many questions off of that. One is that almost seems like the natural evolution of long-living technologies. C++ is kind of incomprehensible, right? Like if you just wanted to sit down and learn C++ today it would be a difficult task because of so many things that have been added. And do you see a way around that? How do you evolve a language and add new things and grow what it can do without just running into these weird edge cases or just the additional complexity?
KYLE: Yeah, exactly.
JAMISON: It's kind of a book that…
KYLE: It is very biased, right?
JAMISON: A little bit of judgment there. [Chuckles]
So, if we're coming back to feature evolution of the language, the question before I get too far afield, there's a whole bunch of stuff that was added to ES6 that I'm a huge fan of. And I'm out teaching it and promoting it and talking about it. For example destructuring. That's a complex feature. It takes a lot of time to learn. But the payoff is huge. Because we move many of the more noisy and confusing parts of our code into a much more declarative form. It makes code easier to understand. So, I'm a huge fan of things like destructuring and other declarative mechanisms. I'm a big fan of some of the capabilities that were added, like for example generators and things like that, to give us declarative state machines instead of the imperative form. So, there's a whole bunch of stuff that was added.
And I would love to be coming on this podcast and saying the class keyword fixed all of our problems and now we can understand it. But what class did as I said just a moment ago is it doubled down on a set of misconceptions. And it essentially comes with the premise, you ought to just use this thing and not really try to understand it because all the things that you need to make it work, we're going to do a bunch of ugly plumbing underneath the covers. But don't worry about any of that stuff. Just use it at face value. So, there are a lot of people that that works perfectly fine for.
So, I don't think that the language has to stagnate. But I think we should be bringing to the discussion table, and this isn't meant as a criticism of TC39 at all because I know many people on there. I'm a big fan of many people. I don't want their job. I wouldn't want it at all because it's very hard. But I do sometimes feel like the teachability and learnability aspect of the language is the last thing that gets considered in the design of the language. And that bothers me. I wish that were more front and center. If I had my way, that would be the most important design feature.
JAMISON: That makes sense.
JOE: Yeah, what an interesting perspective though. I'm sure you're right. Who when you're designing a language really considers, “How teachable is this?”
KYLE: Yeah. Again, I'm not meaning at all to cast aspersions on the people that are on TC39 and that are running the design of the language. I see some things that they come out with and I'm like, 'That's brilliant. That's awesome. That's going to be much more helpful. There'll be ways to teach that.” And I see other stuff that comes out and I'm like, “That's just, that's more like confusion. That's more duct-taping over the problems instead of fixing them.” And those are the things that kind of keep me up at night, if you will.
AIMEE: So, another topic that I think that you do a really good job talking about that a lot of people shy away from is, if I can even say it correctly, coercion. Am I saying it correctly?
KYLE: Coercion, yeah. That's [inaudible]
AIMEE: Coercion. Thank you. Okay. [Laughs] Embarrassing. Anyway, I am curious if you'd be willing to talk about that a little bit. Because I feel like for the longest time until I started digging into your material, I just thought, “Don't use this part of the language. Always use triple equals, no questions asked.” But you kind of advocate for knowing the power of it and actually using it as a feature of the language.
JAMISON: Snark always sells.
So, let me fill in the blanks a little bit to help listeners understand what I'm talking about. What does coercion mean? Coercion is the, for the class of languages that are what we call dynamically typed, so it's important to understand dynamic typing. There's actually a difference between weak typing and dynamic typing so you might want to do a little bit of Wikipedia page reading if you're interested. But just briefly there's this notion of weakly typed which is that a value can be changed into another, same representation of that value in a different type, that that can happen implicitly. That's what weak typing means. So for example, if we have the number 42 and it was used in the context where we needed a string like if we were printing it out to the console, that it can be automatically converted to its string representation. That's called weak typing. And in a weakly-typed language, the way that type conversions happen, that is given the label coercion.
Now, coercion actually comes in two forms. There's the explicit kind and the implicit kind. Most people when they talk bad about coercion, what they mean in the back of their heads is they don't like implicit coercion. They tend to prefer things that are more explicit. To give you an example, if you were to make the case that there should be no coercion at all which I've heard people say, it's kind of nonsensical. If I hear somebody say that, I really just think to myself that person hasn't thought critically about the problem. Because to remove all coercion would be to see there is no type conversion at all. And you cannot make a program without type conversion, period. You have to have a number that you can print out to the screen. A conversion has to occur from number to string. You have a string input on a web page and then you need to do some math with it. You're going to have to convert from the string form to the number form. There are other, boolean is another example.
Now that would be great except for the fact that the most vocal of those proponents, for example the Doug Crockfords of the world, they will say until they're blue in the face, “Don't use coercion,” meaning don't use implicit type coercions. But then if you open up Doug Crockford's code, guess what you find? You find examples of them using implicit type coercions. Because the fact of the matter is, that's a powerful mechanism that used in the right way actually makes code easier to write, easier to understand. If you have to go always through the explicit path and never through the implicit path, you can make it work. But the code is harder to understand. So, there's not such a clear dividing line between explicit and implicit. And I think that people should think critically about it instead of having a linter that simply tells you always use triple equals and never thinking about it. I think you ought to think about the cases where coercion can be helpful and places where it might get you into trouble.
So, let me just briefly give an example of a place where coercion would be useful. If you have a piece of your code that you need to decide whether or not somebody shows option three for whatever that means. There are three options available and you need to do something if somebody chose option three. There's potentially two possible ways that they chose option three. One would be that they picked a drop-down or they typed three into a text box or something. And so, you have option three represented as the string representation of the value three. So, you have literally “3” in some variable. Another possibility is that that was from some saved preference in a JSON object that came from the backend database. And now it's represented as the number 3.
So, what we ought to have is a mechanism where we could just simply say, ”Is option three picked?” and abstract away the implementation detail of whether or not it's a number or a string. One way you could do that is to write yourself a function called 'is option three' and you could pass that value in. And inside of that function you could do that double checking thing, that 'option === 3' thing. And then your if statement now says 'if is option three' and they pass in the value then I do this logic. That's one way of abstracting away the unnecessary implementation detail. What I simply argue is the double equals operator does this for us. It's built into the language, the ability to abstract that type difference. The double equals operator will allow us to compare the string 3 and the number 3 to be coercively equal to each other. So, I can simply say ‘if option double equal to the number three’ and either the number three will match it or the string three will match it. But null is not going to match it and an array is not going to match it and nothing else is going to match it. But the number three and the string three are coercively equal to each other.
And furthermore, you've heard me say this a bunch of times now, I think we ought to have as one of our most important design decisions about the way we write our code, we ought to embrace the idea that code is communication. Code is how we communicate with humans. It's not about instructing the computer nearly as much as it is about communicating effectively with other humans. So, we should be looking for every opportunity that we can to make the code make more sense, have it be more understandable and more readable.
And in the case of saying 'if option triple equal three or option triple equal string three' what we've done is clutter up that where anybody that reads that in the future has to then think about all those cases. Like “Hmm, I wonder where it could come as a string. I wonder how could it ever be a number?” And then they're completely distracted from the whole point of that code. I don't want us to write code that is overly verbose and then distracting. I want us to write code that is as clear in its communication as possible. And this is an example of using a built-in mechanism of the language to hide implementation details so that the code speaks for itself.
So, what that means is your code is going to run necessarily a little bit slower just simply as a result of having that presence in your program. I don't think that's a good idea to opt into mechanisms that are going to make your code run slower. So, the negative of that far outweighs any possible potential benefit. There's a bunch of other problems with the with keyword but that one I think is kind of an incontrovertible argument. It's going to slow things down because the engine is going to skip over some optimizations that it would otherwise have available.
JOE: Huh. Crazy. I had no idea it did that.
JAMISON: So, I want to channel my inner Angus and push back on that a little bit. If it runs slower and now instead of doing 2 billion operations a second you can do 200 million operations a second, there are plenty of cases where that does not matter. And yeah, you get this abstract feeling like, “Oh no, my code is slower.” But it's not a user-facing thing. And there are things that you can do with with and eval that are difficult to do other ways. So, yes it has tradeoffs but isn't that part of the point? That you should be aware of those tradeoffs so that you can decide when it's worth it to make them.
On the other hand, let's dig in specifically to the question of the with keyword since that's what at odds here. The with keyword does not just simply pollute its own usage. It pollutes the entire file because of the way the implementation works. So, it is the entirety of your program that is going to run slower as a result of simply using the with keyword once somewhere within that file. So, if you have a file that has 10,000 lines in it and only one line has the with keyword, it has virally polluted the optimization benefits that would be available to all the rest of that code. That's one observation to make. If it were only that the with keyword itself were slow and it had no effect on anything else, you wouldn't hear me making that case as strongly. But it's because it affects everything else that I'm making that case in that way.
But even if we take performance entirely out of it for just a moment, the with keyword has a behavior to it which is one of the worst evils in all of programming design and all of language design which is that it is impossible to predict its behavior until the runtime occurs. You cannot statically analyze and predict its behavior ahead of time. And you have to run it. And what I mean by that is this. You use the with keyword to say with obj, with object, and then inside of it you say something like 'a equals two'. Well, you would like to believe that what that is doing is setting the a property on the obj object to that value two. Unfortunately you cannot predict or know whether that is going to happen unless you know what the shape of obj is. Because if obj already has an a property then it will indeed set it to the value two. But if obj does not have that property yet, the with keyword will not add it to that object. Instead the with keyword will treat that as a failed lexical scope lookup for a variable named a and it will then walk up the scope and look for a variable called a in the outer scope, in the outer scope.
And then because you're using the with keyword you're going to be in non-strict mode. And so, when you get to the global scope you're going to end up creating an accidental global variable called a. That behavior of not being able to predict or validate how something is going to behave, not even being able to look at the code as a human and understand what it's going to do because you don't know the shape of obj, that's a terrible design. And it creates much, much harder to understand code. So no matter what kind of benefits you might be able to cite about not having to say 'obj dot' over and over and over again for example, they're not going to end up in my mind countering that argument which is it's creating these effects at a distance because you can't predict its behavior.
JAMISON: That makes sense. I have kind of a more general question to get back to the education stuff we were talking about at the beginning of the podcast. It seems like there has been a huge rise in the amount of resources and institutions devoted to education in programming. And especially the bootcamp movement where there are just places all over the place springing up to teach people how to code. And some of them seem to put a little less emphasis on teaching skill I guess than others. Some of them will really emphasize “Our instructors are successful industry engineers who worked at this famous company or this famous company,” and not as much focus on, “They learned how to teach here.” And do you see that as a problem I guess that there are so many more people teaching but that we don't as an industry talk that much about the skill of teaching? It just seems like it's kind of assumed. If you know how to do a thing, then clearly you can teach it. Like you built some system, you can teach other people how to program.
KYLE: Yeah, that's a great question and a tricky one to navigate well. So first off, disclosure. Most people probably know that I've spent quite a bit of time working with the curriculum with MakerSquare. So, I actually have first-hand experience at a developer school. And so…
JAMISON: And lots of them are fantastic, too. I don't mean to say that… like, none of them…
JAMISON: But there's definitely a mixed bag.
KYLE: I would actually re-frame this debate a little bit. So, I think it's definitely true, the observation that you're making that not all coding schools are the same. And not all teachers are the same. There are teachers that believe deeply in the process of education and pedagogy and knowing what you're talking about and being accurate and making sure that everybody gets what they need. And there are teachers that just sort of gloss over, reinforcing the same stuff that you've heard everywhere else. And they are very effective in that manner. So, not all teachers are the same and not all schools of course are going to be the same. You do need to pay very close attention to that.
But I'd also, to push the debate even further I'd like to re-frame it slightly and say that I think part of the problem that exists right now with developer schools and really developer education as a whole is that the industry has forced these coding schools to do things that otherwise they wouldn't really naturally want to do. Because the developer industry, the business industry that hires these developers has said, “I just need you to make sure that they can invert a binary tree on a whiteboard,” well necessarily then because that's the way most interviews happen, guess what the developer schools do? They optimize for making sure that the developer can pass those interviews. [Inaudible] they spend at least some of the time instead of teaching them how to really understand the code, they spend some of the time just teaching them how to pass that interview. Why? Because they paid $20,000 as a transaction and one of the promises is that they would get a job. That they would get interviews and they'd get a job.
So, part of the reason why we have really terrible tech school grads or if there are grads that are coming out and they don't know stuff, part of that blame is on the school but part of that blame is on the industry that's being hired into by wanting the wrong things. Optimizing for the wrong things, incentivizing entirely the wrong things. If we could change what we look for in the interview, if we could say that we value looking for people that are critical thinkers, that are really deeply problem solvers and not just people that are good at coding on whiteboards then I think you would see a new revolution of these developer education programs producing developers that are more optimized for that. Because those developer schools, right or wrong, exist for the purpose of getting somebody into our industry. And they are looking specifically to the companies that will hire their graduates to set the pace and to set the lead.
I ran up against this a whole bunch so far in my time at MakerSquare. We've run up against this, banged my head against it because there's a tension there. I come to this notion of building curriculum from we ought to teach them how it really works. But I also know that if I spend all my time teaching how it actually works and I don't spend any time teaching you how to answer the interview question in the way that that person is likely to want to hear it, you're not going to get a job. So, we need to fix those problems. And I think that will then trickle down to allowing the people that care the most about teaching in developer education space to do it. We also need radically different models for teaching than what we… and I don't mean that the developer schools need to go away but we need lots of other approaches to teaching. So, that's a lot of the things that I spend my time thinking about, banging my head against these days, is how do we improve that. And I think one of the things we have to do is advocate for employers to start hiring for the right things.
JOE: Well said. Well said. I wish we could spend a whole episode just talking about that.
KYLE: Well, I can certainly come back at some time and we can talk about that. You can probably tell I have lots of thoughts on it.
AIMEE: You can do your part, too.
JOE: Yeah. Okay, well we should definitely wrap up here. We've hit our hour mark. You got places to go and people to see. So, I'm sure everybody's excited to get to the picks portion of the show. Let's start with Aimee. How about you?
AIMEE: I have one pick this week and it is a book. So full disclosure, I have not read the book yet. But I did watch the TED talk and the book is called 'Your Code as a Crime Scene'. But there's also a TED talk that goes along with it so I'll put both links in the show notes. But even the TED talk was really, really good. So, the guy has a background in forensic psychology. And he uses that to analyze where bugs show up in your program. He uses the principles that he learned studying forensic psychology and applies that to tech debt. So, I just really, really thought this TED talk was super interesting. And I'm sure the book is probably amazing. It's on my list of things to read. So, that's it for me this week.
JOE: Awesome. Jamison, how about you?
JAMISON: I have, let's call them four picks today. The first one is an episode of an NPR podcast. And it's on the history of the Open Office. The Open Office is a pet peeve of mine. I really dislike them. [Chuckles] And it was interesting to me to hear about where it came from. It was basically just this architect working at a fancy advertising company that was like, “I don't know. I'm going to try this thing out.” And then because that company was so cool and everyone wanted to be like them, it kind of spread. That was the argument they made. So, that was kind of cool.
Another pick is just a concept that I learned at Web Rebels. It's called Zooko's triangle. Names can be unique, memorable to humans, or meaningful. Pick two of them. It's not like a hard mathematical law but it's kind of a commentary on the difficulty of aligning all these different incentives when you're naming variables or modules or when you're doing distributed systems things. Or I don't know, just an interesting thought.
My third pick is a movie. It's on Netflix. It's called 'The Barkley Marathons' and it might be my favorite documentary ever. It's amazing. It's about this sadistically difficult ultra-marathon in kind of the woods out in Tennessee by this guy who's hilarious. He's kind of like, he kind of just seems like he's messing with people like, “And then they'll have to do this,” and just laugh to himself. He starts the race by smoking a cigarette. That's like the starting gun. And that's kind of…
JAMISON: That's kind of his whole aesthetic. It goes from there. And it's really good.
And then my last pick is just React Rally. It's a React conference in Salt Lake City in August, August 25th to the 26th. We have our speakers announced. They're great and we are excited to have them. And I would love to see you there. If you go to ReactRally.com you can buy tickets. Those are my picks.
JOE: Awesome. I'll go next. So, I went last night and saw the movie X-Men. Thoroughly enjoyed it. Absolutely enjoyed it. I thought I'd not like it anywhere near as much as I liked the 'Civil War' movie, the Captain America movie. But I really did like it quite a bit. And the scene with Quicksilver as in the last movie was just fantastic and super awesome to watch. So, I'm going to pick that.
I'm also going to pick America's Got Talent. It's out on, it just barely started up its next season. I always love watching America's Got Talent and seeing all these amazing people do amazing things that you never thought people could possibly do and just hone sometimes the weirdest thing to an absolute art. And I thoroughly enjoy that. Fun to watch with the whole family.
And my third and final pick which I picked certainly last week, last time I was on, is the game Overwatch. Which I know Jamison plays.
JAMISON: Oh yeah. We've played together.
JAMISON: It's solid.
JOE: Solid game. Super fun game. Might have to uninstall it so I can get some work done. Absolutely the best shooter I have played in a long, long time, for at least multi-player shooters. So, great game. Highly recommend it.
Kyle, how about you?
KYLE: Yeah. So, since you just recommended a game I'll recommend a game as well. It's a mobile game as far as I'm aware. It's available on all the platforms. It's called Stack. It's a totally casual sort of game. So, it's not like a first-person shooter or anything. Literally just these blocks fly in and you have to tap the screen to make sure they sit right on top of each other. And you're trying to get the stack to go as high as possible. And if you misalign them then pieces fall off and your stack gets smaller. And eventually you run out of being able to build the stack. So, I got totally addicted to this thing. But part of the reason why it was fun to play is because there are all kinds of really rich metaphors here for software development. Making sure that when you add something on that it fits well with what's already there. The negative side of choosing technical debt and how that builds up over time and so on and so forth. So it's actually, it's a fun game but it also makes you think as a developer, I think. At least it did for me. So, go play Stack. And I'll just brag for just a moment, my high score in Stack is 203. So, if anybody out there has a better score than that, tweet me and let me see that.
But two blog posts that he's written recently that really stuck out to me, one of them is called 'A web for everyone'. And anyone that's followed me for a while has known that this is a big passion of mine, that I think that this tiny little section of the world population is building the web for the whole rest of the other 7.6 billion people. And I don't really think that we are giving that the proper weight and justice that it deserves in terms of how we think about things. We only think about things in our little envelope. Well, my boss only wants me to build the app for people that live in my hometown. So, why would I even care what it looks like to somebody else? And that is fundamentally violating I think one of the most important principles of the web.
Jeremy makes that case I think very eloquently and in not a terribly long blog posts. These blog posts are pretty quick reads for it. But he ends with this notion of build a web that works for everyone. That doesn't mean that everyone has to share the share experience. Let's accept that all sorts of people out there are accessing the web with all sorts of browsers on all sorts of devices. Couldn't have said it better myself. So, I totally recommend you reading that. And I recommend you thinking more deeply about that principle of how we build the web and what that responsibility is.
Even more controversial and impactful is another blog post that he wrote called 'Regressive Web Apps'. And I totally think you need to read this one as well. He's making the case that the web is losing some of the stuff that is the most important of the web because we're in this race to try to keep parity with native apps. And he's talking about this recent trend of “progressive” web apps. And there's plenty of good and bad about what a progressive web app is. But he's making the case that we need to consider the cost of chasing after those things. And in this particular case, he's talking about losing the URL bar. The URL is a really important part of what makes the web the web. And if we lose that entirely, is it even still the web?
So, two really, really good thought-provoking pieces from Jeremy. And I totally recommend you follow him. He's fantastic. So, those are my picks.
JOE: Awesome. Well, thanks again for coming on the show, Kyle. We really had a great episode. I was absolutely just absorbed in the discussion. So, I hope the listeners were as well. And thanks for your time and thanks everybody for listening. We'll be back next week.
[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.]