Machine intelligence is here, and we’re already using it to make subjective decisions. But the complex way AI grows and improves makes it hard to understand and even harder to control. In this cautionary talk, techno-sociologist Zeynep Tufekci explains how intelligent machines can fail in ways that don’t fit human error patterns — and in ways we won’t expect or be prepared for. "We cannot outsource our responsibilities to machines," she says. "We must hold on ever tighter to human values and human ethics."
Tagged with “learning” (26)
Recommendation engines are everywhere. They let Netflix suggest shows you might want to watch. They let Spotify build you a personalised playlist of music you will probably like. They turn your smartphone into a source of endless hilarity and mirth. And, of course, there’s IBM’s Watson, recommending all sorts of “interesting” new recipes. As part of his PhD project on machine learning, Jaan Altosaar decided to use a new mathematical technique to build his own recipe recommendation engine.
The technique is similar to the kind of natural language processing that powers predictive text on a phone, and one of the attractions of using food instead of English is that there are only 2000–3000 ingredients to worry about, instead of more than 150,000 words.
The results so far are fun and intriguing, and can only get better.
Kyle Simpson, the author of the You Don’t Know JS book series, talks about education and learning and teaching programming to new developers.
"The actual path of a raindrop as it goes down the valley is unpredictable, but the general direction is inevitable," says digital visionary Kevin Kelly — and technology is much the same, driven by patterns that are surprising but inevitable. Over the next 20 years, he says, our penchant for making things smarter and smarter will have a profound impact on nearly everything we do. Kelly explores three trends in AI we need to understand in order to embrace it and steer its development. "The most popular AI product 20 years from now that everyone uses has not been invented yet," Kelly says. "That means that you’re not late."
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.
3 or option ===
“3”’. So, what I would say is happening there in our goal or our task of trying to be explicit, not allowing any type conversion or coercion to occur, what we’ve done is we’ve actually cluttered that piece of code with an implementation detail that’s actually irrelevant to the program. Because the programmer at that moment does not actually care whether it’s represented as a string or a number. All they care about, the logic that’s trying to be self-evident in the code is whether option three was picked.
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
Linda Liukas believes that a movement in technology is already happening and that we need to engage everyone — especially the next generation — to take part. She wants to create a more diverse and colourful world of technology, starting with the poetry of code.
Linda Liukas is a programmer, storyteller and illustrator. Her children’s book, Hello Ruby, raised a total of $380,000 on Kickstarter. She founded Rails Girls, which has organized workshops in over 230 cities, teaching the basics of programming to more than 10,000 women. Linda worked at Codeacademy, which she left to write stories that teach children about software and programming. She won the 2013 Ruby Hero prize and was named the Digital Champion of Finland by the EU Commissioner for Digital Agenda.
This talk was given at a TEDx event using the TED conference format but independently organized by a local community. Learn more at http://ted.com/tedx
Yesenia Perez Cruz is known by most as a designer but after this week we like to say she’s a designer and student. She’s had the privilege to work at great companies like Happy Cog and Intuitive Company designing websites, apps and interfaces for clients like Zappos, MTV and Chef Garces.
In this week’s episode we spoke about learning on the job, working with talented colleagues and getting better every day. Yesenia’s had the privilege of working with someone of the Internet’s most influential developers and designers while at Happy Cog and needless to say she learned a lot. Things like the Gap concept or the Gray Box exercise. Big or small, Yesenia used all tools to grow her skills to become one of the leading designers in the industry.
We often see blog posts about optimizing our images or HTML, or even our team’s work flow. But what about optimizing our comprehension? In an ever-changing industry where tools, ideas, and opinions grow exponentially, how can we keep up? This is a topic very close to my heart as somebody who is both stubbornly ambitious and also has a really terrible memory.
Front end developers are often bombarded with so many tasks, options, and stimuli, that we end up being overwhelmed by choices, causing a complete paralysis and block to getting anything done at all. This is called option paralysis or analysis paralysis (that’s a real thing). And it doesn’t help that we work on the internet, where opening a new tab is like walking into a new room, causing us to forget what we were just focused on doing, and starting on a new stimuli instead.
The Doorway Effect
Tammy Everts wrote a really good blog post about this phenomenon — "The Doorway Effect" — where she relates neuroscience to the need for quick and efficient website performance. In short, the Doorway Effect explains why we can go searching for something in one room, walk into another room to look for it, and forget what we were looking for in the first place. This is due to our sensory memory, which works surprisingly similarly to a computer’s memory bank.
This graphic demonstrates the theory of Persistence of Vision: a phenomenon where an after-image persists in human memory. A radially spinning rope is percieved as an unbroken circle if spinning faster than 100ms, while breaks are noticed when it spins slower. Sensory memory, responsible for Persistence of Vision, works in 100ms bursts. Once this time is up, we simply move on to the next sensory input to take up that space. Google’s Urz Holzle, in this talk at Velocity 2010, describes how their goal is to make web pages seamless — like they are pages in a book. He says, "we’re really aiming, something very, very, high here, at something like 100ms." Ironic? Maybe. Maybe not.
While there is some disagreement on whether people learn better when tailoring their experience to a particular "learning style" (AKA the "are-learning-styles-even-real?" debate), it is universally agreed upon that various stimuli do influence our ability to recall information. These stimuli come in four "modalities:" visual, auditory, read/write, and kinesthetic.
According to Sunni Brown’s research, in order to really comprehend information and do something with it, we must engage either two of those modalities, or any one of them paired with an emotional response. This is because memory is stored in terms of meaning, and activating multiple senses during any experience makes it more meaningful and memorable.
Last week, Jodi Cutler responded to one of my Instagram photos of a doodle I drew in an important meeting with a link to this TED Talk. At first, I thought, "shit, I must be in trouble". But The TED Talk outlines how negative perceptions of doodling are ignorant and inconsistent with statistics based on education research.
Doodling gets a bad reputation as something people do when they’re uninterested or unfocused, but that is far from true! According to recent neuroscience studies, people who doodle were more likely to retain information than those who did not (about 29% more to be exact). In addition to an increased retention, doodlers have proven to be more creative and spark more ideas. Drawing an image helps stimulate new images in your brain that spark ideas. Brown preaches that "doodling should be leveraged in … situations where information density is very high."
This made me feel a lot better about my doodling, which has covered the sides of my school notes and has recently found itself creeping onto Post-Its and sketchbooks. It can be awkward, especially around new teams, where people may think you’re ignoring them or not listening. Education is key here. To further avoid distraction, I personally find that the best method for me is to doodle repetitive, geometric shapes; it keeps my body moving and my mind in a neutral state.
The dot grid doodle from a morning meeting last week
If you can see, the side comment in the notebook, says "Chemi’s class crits doodle page." Chemi was the professor.
"Doodling helps you concentrate and grasp new concepts because it keeps the brain at an ideal state of arousal"
This idea relates to a lot of the reasons why Developers Work At Night. When we’re at 100% brain power, and buzzing, we’re thinking about too many other things to concentrate on a single task. Swizec Teller’s theory of the "sleepy brain", says that we work best at night because "there isn’t enough left-over brainpower to afford losing concentration."
Another fun fact from Teller’s book: we’re more productive in the morning, yet more creative in the evening.
Something I just started doing lately (unlike doodling) is listening to blog posts instead of reading them. This stemmed out of my intense desire to multi-task as much as possible, and my enjoyment of the freedom that podcasts allow. I think its been working pretty well. If I really want to focus on the content, I will do both (read and listen to the same text). That way, if I get distracted and end up on another web page, there is still the auditory stimuli that keeps my sensory memory flowing (thus avoiding the "doorway effect"), and keeping me on track.
I liked listening to my blog posts so much, that I started turning ebooks into audiobooks
Listening also allows for that mild, ideal temperament to best retain information. One night, while relaxing and crafting holiday cards, I found myself going through 7 or 8 blog posts. The way I do this online is via a Chrome extension called Select and Speak. So blogs are a good start, but I also have several e-books on my iPad that I wish I could listen to instead of read. I discovered an app called Voice Dream Reader ($9.99) for the iPad, and have been using that to turn e-books into audiobooks. Voice Dream Reader also integrates with Pocket.
Keep in mind, none of these are ideal solutions — TTS (Text to Speech) has a long way to go, especially when it comes to development or code-heavy posts. The screen reader trying to read code is just downright hilarious (but also very confusing/annoying). That’s why I’ve decided to provide an audio version for this post, and all future blog posts. It also makes the post less robotic to hear, since it’ll be coming from the author’s own voice. Regardless, audio works best for non-code-focused articles.
The task you’re doing while listening is also important. For example, I can’t write while I listen to another audio source, making coding and blogging difficult. However, I do listen to blog posts while casually browsing the internet, driving, or crafting. Its a great way to passively absorb information, especially when you’ve got a long list like I do..
Actively Avoid Your Other Tasks
Focusing is something that I often have trouble with. I have so many ideas, so many thoughts, so many things I want to do right now! So yes, I understand how advising someone to "focus on one task" literally means nothing. However, one of my co-workers the other day told me the same thing, but from a different perspective. She said:
Pick one thing and try not to think about any of the other things you’re not doing.
Well, of course! That makes sense. Instead of actively trying to focus on one task, actively avoid doing other tasks. If you are making a conscious decision that It is in your best interest to put those other tasks aside, it alleviates the anxiety and guilt of not doing them.
Distractions are doorways. Avoiding distractions (or avoiding "The Doorway Effect"), will help you in completing whatever learning you’ve begun rather than just getting lost in a tangle of disjointed links. There are a lot of tools I use to help with distractions while working.
Self Control (the App)
The Self Control App allows you to to block content on distracting websites (i.e. Facebook) for a set period of time. The app prevents your computer from accessing any of the sites on your self-determined "block list," reminding you to get back to focusing on the task and preventing you from falling into a black hole of distraction.
Nutritional studies show that participants who ate the same food each day were more likely to lose weight than those who consumed a more varried diet (even when they ate mac & cheese every day). The researchers said "habituation" — the body’s decreasing response to a stimulus after repeated exposure to it — was the cause.
When doing development work, listen to music that’s familiar to you. If I put on new music (i.e. someone else’s playlist), and hear something I like, I’ll end up researching lyrics, adding it to my own playlists, searching other songs by that artist, etc. You get the point. So what I’m basically saying here is, play music that won’t be an unintended distraction.
tl;dr: Doodle at meetings, try listening to blog posts, and actively avoid unrelated tasks.
I’m curious to hear if these tips help you out. Don’t hesitate to leave a comment or tweet at me!
In education, Negroponte explained, there’s a fundamental distinction between "instructionism" and "constructionism." "Constructionism is learning by discovery, by doing, by making. Instructionism is learning by being told." Negroponte’s lifelong friend Seymour Papert noted early on that debugging computer code is a form of "learning about learning" and taught it to young children.
Thus in 2000 when Negroponte left the Media Lab he had founded in 1985, he set out upon the ultimate constructionist project, called "One Laptop per Child." His target is the world’s 100 million kids who are not in school because no school is available. Three million of his laptops and tablets are now loose in the world. One experiment in an Ethiopian village showed that illiterate kids can take unexplained tablets, figure them out on their own, and begin to learn to read and even program.
In the "markets versus mission" perspective, Negroponte praised working through nonprofits because they are clearer and it is easier to partner widely with people and other organizations. He added that "start-up businesses are sucking people out of big thinking. So many minds that used to think big are now thinking small because their VCs tell them to ‘focus.’"
As the world goes digital, Negroponte noted, you see pathologies of left over "atoms thinking." Thus newspapers imagine that paper is part of their essence, telecoms imagine that distance should cost more, and nations imagine that their physical boundaries matter. "Nationalism is the biggest disease on the planet," Negroponte said. "Nations have the wrong granularity. They’re too small to be global and too big to be local, and all they can think about is competing." He predicted that the world is well on the way to having one language, English.
Negroponte reflected on a recent visit to a start-up called Modern Meadow, where they print meat. "You get just the steak—-no hooves and ears involved, using one percent of the water and half a percent of the land needed to get the steak from a cow." In every field we obsess on the distinction between synthetic and natural, but in a hundred years "there will be no difference between them."
A.I., artificial intelligence, has had a big run in Hollywood. The computer Hal in Kubrick’s “2001” was fiendishly smart. And plenty of robots and server farms beyond HAL. Real life A.I. has had a tougher launch over the decades. But slowly, gradually, it has certainly crept into our lives.
Think of all the “smart” stuff around you. Now an explosion in Big Data is driving new advances in “deep learning” by computers. And there’s a new wave of excitement.
Guests: Yann LeCun, professor of Computer Science, Neural Science, and Electrical and Computer Engineering at New York University.
Peter Norvig, director of research at Google Inc.
Page 1 of 3Older