257 RR Learning and Training with Neil Brown

00:00 01:02:12
Download MP3

01:29 - Neil Brown Introduction

02:32 - Where do new people get stuck?

07:21 - Targeting Particular Age Groups

13:46 - Becoming Professional Programmers

15:33 - Apprenticing

17:20 - Teaching Theory and Algorithms vs Practical Aspects

20:42 - Value and Negotiating Raises

24:06 - Preparing Students for Business Challenges

25:39 - What is the first thing students should learn?

28:46 - Using Games

30:45 - Using Music

31:48 - Hypotheses Testing

34:08 - Tools

38:23 - "Frame-Based Editing"

40:21 - Beyond Beginners

41:15 - “My Holy Grail has been to radically simplify professional programming. I now realize that simplification is not fundamentally a technical problem but rather a cultural one. Our nerd culture embraces inhuman levels of complexity. Mastering mind-boggling complexity is our mutant superpower. It is our tribal marker. Complexity is the air we breath, and so it is invisible to us. Simplification will only come from outside this culture. To disrupt programming I first have to reinvent it for a fresh audience of non-programmers.”

44:26 - Technical Matters vs Elitism

47:57 - Making Programming Easier to Learn

51:20 - Team Structures in Academia vs Industry

Picks

git-standup (Coraline)Craft Conference (Jessica)UtahJS (Chuck)Zoom H6 (Chuck)Ian Leslie: The Sugar Conspiracy (Coraline)The sugar conspiracy (Neil)Treasure Islands: Tax Havens and the Men Who Stole the World by Nicholas Shaxson (Neil)

Transcript

[This episode is sponsored by Hired.com. Every week on hired they run an auction where over a thousand tech companies in San Francisco, New York, and L.A. bid on Ruby developers providing them with salary and equity upfront. The average Ruby developer gets an average of 5 to 15 introductory offers and an average salary offer of $130,000 a year. Users can either accept an offer and go right into interviewing with a company or deny them without any continuing obligations. It's totally free for users. And when you're hired, they give you a $1,000 signing bonus as a thank you for using them. But if you use the Ruby Rogues link, you'll get a $2,000 instead. Finally, if you're not looking for a job but know someone who is, you can refer them to Hired and get a $1,337 bonus if they accept the job. Go sign up at Hired.com/RubyRogues.]**[This episode is sponsored by Rollbar.com. If you need error and exception tracking in your application, check out Rollbar.com. They have a great UI and terrific tools for helping you track down the problems in your application and getting it back up and running as quickly as possible. You can find them at Rollbar.com.] **CHUCK:  Hey everybody and welcome to episode 257 of the Ruby Rogues Podcast. This week on our panel we have Coraline Ada Ehmke. CORALINE:  Oh, hi. CHUCK:  Avdi Grimm. AVDI:  Hello from Tennessee. CHUCK:  Jessica Kerr. JESSICA:  Good morning. CHUCK:  I'm Charles Max Wood from DevChat.tv. And this week we have a special guest and that is Neil Brown. NEIL:  Hi. CHUCK:  Do you want to introduce yourself, Neil? NEIL:  Yeah. So, I work as a programming education researcher at the University of Kent in the UK. CHUCK:  I'm not sure what that all entails. NEIL:  [Chuckles] So, what I do is… what our team does rather, is we build tools that people use when learning to program. So, our two main pieces of technology we work on is we have an IDE called BlueJ which is for Java not Ruby I'm afraid. And we have another one called Greenfoot. And so, BlueJ is aimed at first-year college students. And Greenfoot is aimed at late high school. So we just, rather than try and get people using professional tools that can be a bit overwhelming like Eclipse, IntelliJ [fill in your] favorite IDE here, Visual Studio or whatever, we try and actually design pared down IDEs that art targeted for education that don't overwhelm people new to programming and just try and ease them in better to get them started with learning to program. CHUCK:  I think for us on this show it's been a while since we were new to programming. Even if we've switched paradigms or languages, you still have a lot of knowledge you bring with you. So I'm curious. You pare down the IDEs so that it's not overwhelming for new people. But where do people get stuck? Where do new people have their experience fall apart a little bit that they have to either power through or get some help at? NEIL:  The first thing immediately is syntax. See, the initial barrier to getting started with programming. We now know being fairly technical and [inaudible] have a vague understanding of how a compiler works, we understand the importance of syntax. Why it's needed, why it needs to be precise. And we also have a… fairly easy with fixing syntax errors. If you're developing tomorrow and you get a syntax error you'll just be able to look at the code, find the bit where it's gone wrong, and fix it. For a beginner, they don't know the rules of the game yet. They don't even understand why it's important, why do you have to be so precise, why is everything so fiddly? Modern interfaces, things like Google will say, “Did you mean X?” You're not going to get that so much if you get your syntax wrong while programming. So, the initial barrier that everyone runs into is syntax. They don't know why it's important. They don't know how to get it right and they don't understand the errors when they get it wrong. So, that all makes it very difficult when confronted by that when you're doing programming. CORALINE:  So, I'm curious Neil. A lot of developers don't use IDEs. What made you decide that an IDE was a valuable tool for getting people started? NEIL:  It's interesting actually. I suspect it varies a lot between languages, how many programmers use IDEs. If you talk to different programmer communities you'd probably get fairly different answers. I imagine if you do .NET for example, a lot of people, if you're doing .NET on Windows you're going to be using Visual Studio. So, there I'd expect to get very high IDE use. If you're doing something more like JavaScript programming then I imagine you're going to get a lot less IDE usage. So, Java is one of the realms where perhaps IDE usage is more common. And so for us, it seemed like a natural step to have an IDE. And also for a beginner, we feel that trying to understand several separate tools at once, you've got a text editor, you may be invoking the compiler on the command line, it creates a lot of effort compared to if you just have an IDE as an editor with a button that says 'compile'. It's less for them to take in, less for them to understand. A lot of young people nowadays haven't used a command line before. So, if you're trying to throw them into a command line at the same time as teaching them programming, they've got a lot of new things to learn at once. So, just creating an interface where they can focus on writing the code and hide away some of the details like compilation, it's a good step to reduce the load on them while they're learning. CORALINE:  That makes a lot of sense especially… like I hadn't thought about the fact that different programming communities have different reliances on different tools. And I definitely hear what you're saying with regard to the command line. I've taught some Ruby classes and I've had to do a 101 on terminals. So, I definitely understand the need to, or the desire to bypass that as much as possible. CHUCK:  I'm also curious. Are these problems things that you see within the context of the university? Or do you go beyond the university to talk to people who are self-teaching or doing bootcamps or some of the other ways that people come into the community? NEIL:  Yeah, that's a good question. So, mainly we see people who are using it in a more formal education context. So, they're at a high school or maybe in after school classes or for us, we teach at university. So, we see all our incoming university students. And for us, that's mainly where we've targeted. We haven't actually done so much on as you say things like self-teaching and bits like that. It's really hard in programming in general to know what proportion of people self-teach and what proportion learn in a more formal setting. I've seen some statistics [inaudible] around by a Stack Overflow survey recently, which suggested one set of numbers. It's really… I don't even have an intuitive feel for what the right answer should be to even know if some of these are accurate or not. JESSICA:  But certainly if we have good programming courses available, both independently and in formal settings, that offers the most people opportunity. NEIL:  Yeah, it does. And obviously there's been a huge rise in it seems like [inaudible] over the past few years. Coursera and [inaudible] and all these things offering lots and lots of courses on programming. So yeah, I think ideally it all will be suited to both contexts to allow people to come into it as adult learners and also to come into it as younger learners. JESSICA:  You mentioned that your two IDEs are targeted at early college and late high school. What do you do differently? NEIL:  To target the particular age groups? JESSICA:  Yes. NEIL:  Yeah. So, our original work was BlueJ which was first-year university. And part of that was of course until the past few years there was very little computing in schools. So, if you're going to think about making a tool for somebody who's starting to learn to program, most people started to learn to program in formal settings when they reached university, if we leave aside the self-teaching for a moment. And so, that was 15 years ago that we were developing that and putting that out there. And then on top of that, as people were learning in schools as well, we made Greenfoot which was actually, it shares a codebase with BlueJ but it's for making games. It's got a visual aspect that you run around. If you've seen Scratch you'll know the idea. You've got a stage and things move around and you change pictures and you could do keyboard control and that sort of thing. So, that was what we've bolted on the front if you like, to make it more appealing to younger learners. But BlueJ is maybe a little bit drier. But it allows you to get to some of the more nitty-gritty bits that you need if you're doing university study. JESSICA:  So in fact, over the course of 15 years learning programming in formal settings has shifted younger? NEIL:  Yeah, I think so. And obviously in the past few years, it's the real sort of zeitgeist thing to think about doing coding in schools. So, Code.org, other initiatives in the United States. In the UK we've had computing at school. It was a group that we've been part of trying to introduce computing into our schools. That was very successful. We're now on the English national curriculum from age five to 14. There is a subject Computing which has a Computer Science component. And that involves programming algorithms and similar. So, other countries are thinking of the same. So, it really has become getting people started younger in formal setting. I know people have often started younger by themselves self-teaching. But now it's getting into schools as well, I think. JESSICA:  Oh, that's fantastic. So, there's a formal subject Computing added to the curriculum all the way down to age five. That's wonderful. NEIL:  Yeah. Don't think that they're all writing Java at age five. JESSICA:  [Laughs] CORALINE:  Oh, Haskell's much more suited to five-year-olds. [Laughter] CHUCK:  I know right? NEIL:  Exactly. JESSICA:  [Inaudible] is they're really hard to draw when you don't know cursive. [Laughter] NEIL:  Yeah. And so, initially it might be concepts. It's things like they explore the concepts of algorithms with things like, what's your process for getting up in the morning? First I brush my teeth and I change into my school clothes and I have breakfast. Sequencing and that sort of thing. Some exercises to do with things like precise instructions. There's a really good one involving sandwich making where you get a teacher to act as the robot, a sandwich making robot. And the kids have to tell them what to do. And the teacher deliberately misinterprets the instructions whenever possible. So, the kids say, “Oh, well that's fine. Just take the jam and you put it on the bread.” So, they live up the pot of jam and they just place it on the loaf of bread. They're like, “Done.” JESSICA:  [Laughs] NEIL:  And the kids, they're like six or seven or something and they're all laughing like, “No, no. You've got to put the jam on a piece of bread.” And so it's like, “Okay, so what should I do?” And like, “Take out a piece of bread. Then put jam on it.” And so, he puts a pot of jam on a piece of bread. They're like, “No, no. You've got to use a knife and spread it.” And so, gradually lead them towards being more precise. And it's something that's fun. Kids can do it. We're not teaching them Java but just trying to get across some of the concepts of programming. And then obviously they move into systems like Scratch which is suited for young programmers. And then later in the age range they move onto Python, Ruby, Java, text-based programming. CORALINE:  How long has that program been in operation? Has it been in operation long enough to get some statistics about impact on new students in college who are signing up for CS or anything like that yet? NEIL:  Not quite yet. So, we've been in the national curriculum I think nearly two years now. Alongside that in the UK, we've been making sure that there are qualifications to take between age 14 and 18, that gap between this national curriculum and when they come to university. And some of them were already there but the number's got very low over the years. That's not seeing in increase. And certainly when we talk to students coming into our university we are starting to see people who've done programming. And it makes it very difficult for us as a university because in general computer science courses have always assumed that people know nothing coming in. And you always get this hugely diverse intake of people who've been programming in their bedrooms for the last six years and are proficient in several languages and all of a sudden we're like, “Okay, this is an if statement.” And they all get quite switched off. But at the same time, we have got people coming in who haven't had an opportunity to study much computing or weren't very aware of it. And for them, we do need to teach them, “This is an if statement.” So, it's something that universities I think worldwide find it hard to juggle with computing. There's not a recognized path like with physics. With physics you don't start with, “Okay, this is an electron” or something. You can assume that they know the basics. In computing it's more difficult because we're a new discipline. And that will take some time to settle down, I think. CORALINE:  I'm curious as well about the impact on lower-grade teachers. What kind of training do the teachers get for the young kids to teach them some of those fundamentals? Is that something that the program also addresses? NEIL:  It has been difficult, especially when we live in a sort of age of austerity. So, there was certainly government will to put the subject into the curriculum but there wasn't necessarily the ideal amount of government money to provide the training. So, there is definitely a lag and a big issue there. And I know that affects the US and all sorts of other countries as well, trying to train up enough teachers to back this up is a very difficult logistical issue. And there are not really the proper formal programs in place. A lot of it is quite ad hoc to get people up to speed. CHUCK:  So, I'm curious. How does this approach with high school students and college students affect people coming into the programming community at large? Because it seems like you have quite the diverse set of people coming in as far as experience level goes anyway. So, you've got people who like you said are brand new and you've got people who have been experimenting with or even full-on at a professional level been programming when they come into the program. So, who are you trying to send back out into the community? What level do you expect people to be at when they come and join the ranks and become professional programmers? NEIL:  Yeah. It is difficult. And obviously if you've got that diversity of intake, you're not going to magically arrive at [inaudible] at the same point. Even after three years of study you can't necessarily get them all up to exactly the same point. So, it's awkward. Ideally we've turned out people who are… obviously they're not going to be seasoned expert programmers but who know how to program, who can deal with… we try and teach several different languages, several different paradigms to give people a flavor of the different things that they might be going to do. A bit of experience with web, a big with embedded, to try and just sort of give a broad base to go from. But there will always be an element of learning once they get into the workplace, especially if they came to it not having done so much before. I've seen people really grasp it and within one or two years they actually do catch up to people who've been doing it for longer. But that's more the exception I guess than a realistic pattern for everybody. CHUCK:  I think we also see this in our professional environments too where we're looking to hire people. We may or may not be able to find people at the experience level we want them to be at. And so, we bring people in at various experience levels and try and level them up as they work with us, either as interns or as employees or however that works out [depending on the company]. CORALINE:  Apprentices. CHUCK:  Right. So, do you think the approach is the same or are there differences between apprenticing somebody, I like that word Coraline, as opposed to bringing them up through a formalized curriculum and hoping that you turn somebody out at the end who can go and contribute? NEIL:  Yeah. I think this is a question that comes up a lot, and especially if you start discussing it between programmers who have say a degree and who are self-taught. And it often gets very… a sensitive issue because you can have a workplace where if you were to start saying, “We're going to require a degree” and you've actually got people working there already who don't have a degree, they're going to feel very excluded by that kind of policy or discussion about it. Obviously it's, working at university I would like to think that our degree has value and that it's useful. But I think especially in computing, it's still an open question for a lot of people whether university is worth it. Should I bother to go and do a degree for three years or should I just try and find a job, get started, have three years’ experience? Obviously I work for a university. I'm going to be biased. But I know that a lot of people would say differently on that issue. CORALINE:  I definitely have some opinions on that issue, being self-taught myself. Actually, I used to have one computer course in college and I was bored out of my mind and not really challenged. So, it actually made me think I couldn't do software development for a living because I thought that's what the profession would be like. But luckily I fell into it anyway. But one of the things I've observed from students coming out of university programs is that there seems to be heavy concentration on theory and algorithms and less on the things that we actually do day-to-day as developers including agile methodologies and how to work with other people and some of the more practical aspects. Is that something that you're trying to address as well? NEIL:  Yeah. And I think one issue that comes up over and over again is that we offer a computer science degree and send people out to work as software engineers or developers or whatever you want to call it. And there is… some of the theory stuff comes to that mismatch that we want to teach them useful computer science concepts like big O notation, some bits of formal theory and so on, which they won't necessarily use in a software engineering path. But I think most universities have tried to mix in aspects of that. We certainly cover some agile methodology, do things like version control. We do group projects. We do things like human computer interaction. So, I think universities, there are still a few who are deliberately more formal and mathematical. But I think a lot of the others have tried to put bits like that in. To some extent, some of that there's no substitute for actually having the experience in a professional context. And for that we offer [a year] in industry. So, we teach them for two years, they go out and actually intern for a year, come back, finish off their degree in the final year. And that provides a good mix of experience in a professional workplace that we can't provide but also formal teaching that perhaps the workplace doesn't have the time or resources to give. CORALINE:  That's an amazing idea. I really like that. And I'm kind of jealous that that's what you're doing in the UK and that's not what we're doing here. NEIL:  Yeah, I don't know if that happens much at US universities. It's something that our university particularly specializes in, the year in industry. I know a few other places do it as well. But I don't know immediately how widespread it is. JESSICA:  I know at Stripe we have a lot of interns from a smattering of universities and they'll come for six months or so. CORALINE:  Oh, that's awesome. I hadn't really heard of that being very widespread. I know a lot of companies are not either willing or capable of dealing with an influx of really junior, really early career people in general. JESSICA:  We do that a lot. Part of it's recruiting because a lot of those people come back after they finish their degree. But also, I don't know. Maybe it's easier when you look at an internship at, this is six months, and we give them some project that is doable in that amount of time. CORALINE:  One of the companies that I worked for in the last few years would not hire any people who were not at least mid-level because they felt like they… if they trained someone they would leave. And they weren't really worth the investment, which is pretty sad. CHUCK:  I hear that a lot. And I'm somewhat unsympathetic to the company. I usually just tell them, “Well, then…” because usually what they say is, “Well then, they'll leave and they'll go get paid more somewhere else” and my answer is, “Well, then they're worth more. So pay them more.” JESSICA:  Yeah. CORALINE:  Yeah, exactly. CHUCK:  But that… CORALINE:  We're in a position where the only way to get a pay increase pretty much regardless of what level you're at is to move jobs. CHUCK:  Well… JESSICA:  Fortunately that's really easy. CHUCK:  Yes. CORALINE:  [Inaudible] that. JESSICA:  But it doesn't help us [inaudible]. CORALINE:  We have that privilege as people who are not early career. CHUCK:  That's true. JESSICA:  Exactly. CHUCK:  One thing that I have seen though is that with other areas of business, I talk to a lot of business folks, and it's the same thing there, too. You raise your price. We've added these features to our product or for the podcast sponsorships for example, our listenership has grown so much so we're increasing the sponsorship price. And they're stuck at the old value and the old price, basically. And it's sometimes hard to overcome that. And I see that the same with other folks. And so yeah, it's hard to overcome and ask for a raise as opposed to just going and getting another offer somewhere else and making that work. JESSICA:  Oh, that's interesting. So, it's hard to see the same person in a new light. CHUCK:  I think in a lot of ways, the people that I've seen successfully negotiate a raise either have a boss that is open to that, in other words they're willing to take a look and say, “Okay, you're providing more value so we'll definitely pay you more since you asked.” I very rarely see anybody actually get a raise without asking. Cost of living sometimes is built-in but that's a little bit beside the point. The other way that I've seen it done is somebody goes in and says, “When you hired me I was doing X, Y, and Z and now I'm doing P, D, and Q as well. And so, I deserve a raise” and sometimes they'll get it that way. But yeah, a lot of people, the way they get their raise is they go get an offer somewhere else, they come in and they tell their boss that they're on their way out because they got a better offer somewhere else, and then the boss looks at them and realizes that it's going to be extremely costly to lose them and then makes them a better offer. CORALINE:  I can tell you that that scenario does not play out very often or merely as often with people who are underrepresented in tech because we tend to feel like our positions are very tenuous. And a lot of people just will not, they're not comfortable speaking up for themselves and taking the risk of losing a job by negotiating for a higher salary. Because that sort of thing does happen. CHUCK:  I can totally see that. If you're not comfortable with them perceiving the value that you bring, then having a conversation where you ask for more value in return is hard. Because you don't believe that they're going to recognize that you actually merit that raise. CORALINE:  Exactly. So, one of the things we do at GitHub is there are engineering levels. And with every level there's a set of expected behaviors and responsibilities. And so, as part of the review process your level is reassessed. And there are salary ranges that go with each level. Unfortunately those salary ranges are not shared. But it's pretty clear what you need to move toward to level up as an engineer. And you have some semi-objective measures. You can say, “Look, I'm a level four and a level five says that I'm supposed to be doing these sorts of things and this is how I have actually done those things over the past six months.” So, you can make a little bit more of a structured argument for getting a promotion. CHUCK:  Well, and those kinds of clear expectations are very powerful too because you can then actually say, “I meet the criteria therefore I am a level five and I should be paid level five.” CORALINE:  Exactly. CHUCK:  And it's not criteria that you've made up. It's not criteria that you've set. It's just the system that you're working in. And it removes a lot of the other extraneous details as far as what color your hair is or what gender you are or anything else. JESSICA:  Super interesting deviation but I have a lot more questions for Neil. CHUCK:  [Laughs] I was actually going to bring this back around. I'm curious Neil. How do you actually prepare people for this aspect of having a programming job? We focus so much on technology and so much on, can you do this thing in this technology? And there are so many other aspects of working on a team and having a job and negotiating raises that I didn't have any experience with until I actually had a job and failed at it a few times. NEIL:  Yeah. I think this may come under there's a limit to some extent to how much you can put in one degree. And I think universities, we try and for example help them find jobs at the end of the degree. But you're right. I'm not sure we ever do much with preparation for the more general work issues, things like office politics. People are bound to encounter negotiating pay rises or even what your expectations should be for salary or that sort of thing. I think we don't cover that. Yeah, I don't know whether we should or not. It's kind of… one problem is that whatever you're going to put in your degree must be taught by academics and I'm not sure… [Laughter] CHUCK:  That's totally fair. NEIL:  People who have been academics for a long time necessarily know… JESSICA:  Yeah, that's fair. NEIL:  the answers for this. We almost need industry people to come back and say, “Okay, here's how it is in the real world. Here are my tips on surviving.” That might be something that's quite useful that maybe we should think about doing. JESSICA:  Yeah, maybe a workshop on how to have a job. NEIL:  Yeah. [Laughter] JESSICA:  That would probably be a useful cross-degree program. CHUCK:  Yeah. NEIL:  Yeah, I think so. Yeah. JESSICA:  So, I had a question about teaching people to program and you're introducing them in a friendly way in an IDE that you said makes them not have to worry about the compiler and all the different steps. What is the first thing you want them to learn? NEIL:  So, what we do when we run workshops and things in say Greenfoot for the high school students is we say, “Here's the interface. Here's how you open the editor. Now that you've got the editor open, what I want you to do is put your cursor there and type this line of code.” And the first one you've just got to give it to them. They don't know anything about it. You just say, “Okay.” Our first line of code is usually, “Move open brackets six, close brackets, semicolon.” Hit compile. Go back to the Greenfoot window. Hit run. And your little crab we usually use for our entry workshops will run across the screen. And that way you've shown them a line of code, they've put it in, hopefully they've got it right because it was really short, and something has happened. They've actually made the computer do something. And so then, hopefully they're engaged. “Okay, so I did something.” You go back to say, “Okay, here's another line of code to turn.” And so, put that in then it runs in a circle. Then you might introduce keyboard control with some sort of if statement. So often, we build a mix of the first bit you've just got to tell them directly what to do because they don't magically have knowledge in programming. But once you've shown them some bits you can then ask them to assemble it in a different order. So, you can say, “Okay, we've shown you how to turn left when the left key is pressed. Now you figure out how to manage turning right when the right key is pressed” and just build it from there. So, it's a mixture of explicit instruction. Write this. Do this. And then giving them more rein to do what they want. And one challenge that we have is the longer we make the workshop the more difficult it gets because they all have these ideas. Like, “Hey, so my game. I want to make this thing run away from you or I want the enemies to hunt you down,” or all these different requests or, “I want to make this thing bounce.” And you get so many requests and so many ideas. And the one difficulty particularly is of course they don't have any idea what's feasible and what's easy and what's really difficult. So, they will ask something that's trivial like, “How do I make it move backwards instead of forwards?” That's fine. Just put a minus on the number. That's easy. And then they'll have some other request like, “Okay, I want the enemy to hide from you.” That's like, “Oh,” [laughs] that's a complicated algorithm that you're going to have to build. And if you don't know programming you don't understand that one is the trivial and the other is almost a research problem. So, you just have to manage some of the expectations and steer them towards things that are possible and things that aren't possible. But if they drive it then it's often quite powerful because they're doing what they want to do, not just restricted to doing exactly what you're telling them. JESSICA:  So, the first lesson of programming is programs make the computer do stuff. NEIL:  I guess so, yeah. [Laughs] That'd be a good way to sum it up. CORALINE:  I think it's interesting that Neil you're using games in the high school IDE. I know there's an intuition that games are a more rewarding form of programming to get started with because you can see the effects of what you're doing and games are like a familiar… we have a vocabulary for games already, generally speaking, by the time we get to that age. Is there research to back that up or did you follow your intuition there. NEIL:  Yeah, I think it was part intuition. Certainly there have been studies showing that games can be successful. But I think it's important to try and have a diversity of applications if you want to draw everybody in. Not everyone plays games. And this isn't even like a gender issue or anything. Not every boy plays games. It'd be foolish to assume that. And games aren't going to draw everyone. Obviously you've got to pick something. You have to pick an application to begin making. You might try and do a mobile app. You might do a game. You might try and do a website. Whatever you pick there will be advantages and disadvantages. There will be people who aren't interested and people who really love it. And so, I think for a longer course you'd ideally try and visit several, within reason, several different applications of computing, several different things that you could build. But I think you want to make it interesting. Classic computing problems for starting out are things like convert Fahrenheit to Celsius. And it's just, that draws almost no one. You want something that's more engaging that people are actually interested to make. No one application is golden and will have everyone interested. But there are some that are kind of the opposite. JESSICA:  Well, I was totally interested in converting Fahrenheit to Celsius. [Laughter] JESSICA:   I thought that sounded super useful. NEIL:  [Laughs] Okay, I apologize. CORALINE:  I actually don't believe in Celsius. [Laughter] CORALINE:  Not convinced. So, I have seen… CHUCK:  So, you're converting [inaudible] to Fahrenheit? CORALINE:  That's right. [Chuckles] CORALINE:  I have seen some programs successfully use music as a way of teaching programming because music is more universally appreciated. And the hardware cost can be a lot less too with distributing a Sonic Pi and getting someone up and running with music. And I know music is a great way to teach concurrency for example. NEIL:  Yeah. Yeah, and I think it's kind of interesting. I was talking to some of the people who make Scratch recently, which you know is another tool aimed at beginners. And Scratch has quite strong support for music generation whereas Greenfoot doesn't. And I think it literally comes down, the classic thing that developers build, what they know and what they'd want. None of us in the Greenfoot team are especially musical. Hopefully I'm not doing a disservice to my colleagues. CORALINE:  [Chuckles] NEIL:  Whereas there's one or two on the Scratch team who are really into music. So, they built a lot of music things into theirs. We built less into ours I guess because we were less interested. But yes, it's interesting how these things can come about. JESSICA:  What type of hypotheses does your research group test? NEIL:  It's a good question. Sort of spectrum in research I think, especially computing research, between the people who do a lot of classical science, studies, hypotheses testing, participants and that sort of thing, and then there's the other end where we're sitting. So, this is a long explanation of why, which is kind of we're building things. We have kind of halfway between research and engineering. So, our focus is especially on building tools. At the moment we're doing a partner study with someone who's more experienced in doing testing. So, we have a tool which is called frame-based editing which is partway between Scratch and text-based editing. We're currently testing whether school students when given that and given text-based Java, is there a difference in the performance of the two. So, we assign a part of the students to one condition, the rest of the students to the other condition. So, some of them get Java. Some of them get our frame-based editor. We set them a task, same task in both, then we see, “Okay, do they do it faster? Do they do it with less errors? Do they report less frustration at the end of it?” So, that's the kind of testing that we do. It's not our particular specialism but like I say, we try and partner with others to do that. JESSICA:  So, your group builds tools that other researchers use? NEIL:  Yes, yeah. Well, that's sort of… JESSICA:  You're infrastructure for research. That's so cool. [Laughter] NEIL:  To some extent. So, we build tools that teachers use but we also build tools that provide opportunities for research. One of our other projects is that in BlueJ we actually ask all our users worldwide, “Are you happy to send us your data for collection?” So, this is a bit like what Firefox does or I think Eclipse has it as well, usage data collection. They ask, “Can we keep track of what you're doing in order to make our…” usually theirs is to make their product better. We actually capture even the source code that people are writing with their permission and we offer that to other researchers to then look and see things like “What difficulties do people have when learning to program Java? How do they use unit tests when they're learning? Which compiler error messages seem to particularly throw people off?” So, we're trying to apply a big data approach to improving programming education. AVDI:  So, I have some questions about the tools that you're building. You mentioned the Greenfoot and BlueJ IDEs. And you mentioned briefly that you're trying out an approach you called frame-based editing. And I was watching some of the videos for the tools you've made, there are a bunch of different aspects to how you're approaching writing code. I'm not sure how detailed we can really talk about that. Some of this stuff is stuff you really have to go and watch these videos. You have to watch some of the animations to see what's going on here. But what I'm really curious about is do you have some kind of overarching theories or strategies that go into how you think about how people should, how to change the way people write code? NEIL:  Yeah. I guess… probably the motivation behind frame-based editing is this idea that text is not the best medium for storing a program. This isn't a particularly new idea. If anyone knows structured editors from the 1980s or so, what we do with text-based code is we immediately parse it into an AST, abstract syntax tree. So, why are we adding this useless text bit on the front if what we're actually editing and manipulating most of the time is the syntax tree of the language? And so, structured editing the first time around was an attempt to actually have that tree explicitly in the editor, sort of do away with the needless flexibility of text and actually just edit the syntax tree. And by and large structured editors weren't very good. But you have to remember that this was the 1980s. HCI was in its infancy back then. We've learned a lot since then. We're not necessarily editing on the terminal. Graphical editors give us more options, more flexibility. And so, you can imagine us as taking a second look at this idea and saying, okay, well Scratch for example has been really successful. And Scratch basically is a structured editor. You've got these blocks that you drag around. You've got the bits where you edit the text but you're not dealing with indentation. You're not worrying about so much the syntax errors. You're just graphically editing the syntax tree of your program. And so, we're trying to take that Scratch idea and bring it a bit closer to text-based programming and to say, “Can we have a better go at this? Is this useful?” Our hope, sort of ambitious hope, is that it's useful for learning programming but actually is just useful for programming in general. Because certain issues fall away. If you've ever had an argument over spaces versus tabs in your team, then why? Spaces versus tabs is just a pointless bit in how the text is stored. But it isn't [inaudible] the AST of the program. CORALINE:  There is no argument there. I'm sorry. There is no argument there. [Laughter] JESSICA:  Yeah. It's spaces. Spaces are the only thing. NEIL:  [Laughs] Yeah. So, it's just like, why does it even matter? It doesn't affect the behavior of the program. So, if you edit the structure, a lot of this sort of other issue falls away. And we can also provide for example better IDE support. So, if you're in your IDE and editing some Java and you make a new line and you hit 'control space' what are you autocompleting at that point? Are you autocompleting the type that begins a variable declaration? Are you autocompleting a method name? Are you perhaps… JESSICA:  See? You did not hit 'control tab'. [Laughter] NEIL:  So, your favorite IDE editor shortcut. Like basically in text you don't necessarily know any context. Whereas in something like Scratch you're always editing a particular thing. You know whether it's going to be a number in Scratch. Certainly you have number or some text or a variable name or something. You just know from the structure. The same in our frame-based editor, that you first say, “Okay, I want to declare a variable.” And then you're in the type slot or “What type is this going to be?” Sorry, Ruby folks. But you're declaring what type is going to be. And so, when you hit your autocomplete, you then autocomplete type names. Then you move into declaring the name. There's no particular autocomplete for declaring names, or we haven't thought [inaudible] useful. And then you might have an initialization expression. Then you'd autocomplete method calls or available variable names. So, by knowing the structure of your code upfront you can provide better tool support in particular points in your program. I hope that makes sense. JESSICA:  What is a frame-based editor? What does the frame-based part mean? NEIL:  So, this is just our name for having, we call the graphical rectangles, we've got frames. If you imagine, so instead of having an if statement in a text-based language we'd talk about an if frame. So, it's one entity. It's not just put together out of syntax sort of bits with curly brackets. It's already a rectangle that appears for you that's complete. JESSICA:  So, it's that context, that place in the structure that you know you are. NEIL:  Yeah. And they're always complete. So, you can have half an if statement in a text-based language because you forgot the closing curly bracket or closing de-indent. But in editors like Scratch it just comes as one thing. You just have an if frame and it can't be… it's always terminated. There are no run-on syntax errors that pop up halfway down your program. CORALINE:  I find that, especially with new people sometimes seeing the structure of the code they're writing can be difficult. And indentation is supposed to fix that problem but they often have problems with indentation. And editors aren't always great about indentation. So, one of the things I like about the frame approach from the example video that I saw on your site was that it makes that visual chunking of functionality really intuitive. NEIL:  Yeah. And so, the indentation just come naturally from the structure rather than having to manage it separately. And as you say beginners especially have problems with the indent. It's hard to think of many other computer-based tasks where indent has a particular semantic meaning. CORALINE:  Python. NEIL:  Yeah. But outside programming it's not something they're used to. CORALINE:  Oh, right. Yeah. NEIL:  Managing whitespace, it doesn't usually matter particularly or it's just an aesthetic thing if you're making a Word document or something. So, this idea that somehow the amount of space you put at the beginning of the line affects your program behavior is kind of, it's new and a bit unexpected. CORALINE:  Yeah. AVDI:  Now, do you feel that some of these ideas have legs beyond beginners? NEIL:  Yes, yeah. I think that frame-based editing, if we can get the interface good enough that it doesn't get in your way, then it is potentially better than text even for professionals. That's sort of a big if to some extent, because like I say, the initial try of structured editors just were too rigid. They just annoyed people. They were weird to use. And so, like I say, we're just trying to apply more modern HCI knowledge. But I do feel it's potentially better than text. If I had all the IDE support that I do from, I use IntelliJ's IDEA thing, if I all the support that that gives for refactoring and more complicated bits in my frame-based editor, I honestly think it would be more useful than text. Obviously I'm hugely biased. AVDI:  [Chuckles] Are you familiar with the work of Jonathan Edwards at all? NEIL:  Vaguely. The name rings a bell but I can't… AVDI:  He was at MIT and he worked on the Transcript programming system which was working towards radically reinventing how we interact with programs. NEIL:  Yeah. AVDI:  I want to read a quote from him. He moved on from that project. He's gone on to work with Alan Kay at CDG. But I want to read a quote to you and I'm curious to get your take on it. I'm curious if you'll agree with it. NEIL:  Okay. AVDI:  He says, this is reflecting on his efforts to get some traction with the stuff he was working on. He says, “My Holy Grail has been to radically simplify professional programming. I now realize that simplification is not fundamentally a technical problem but rather a cultural one. Our nerd culture embraces inhuman levels of complexity. Mastering mind-boggling complexity is our mutant superpower. It is our tribal marker. Complexity is the air we breathe, and so it is invisible to us. Simplification will only come from outside this culture. To disrupt programming I first have to reinvent it for a fresh audience of non-programmers.” I'm curious if you have any agreement with that. NEIL:  Yeah. I can certainly see where he's coming from. One difficulty that people have with introducing Scratch to learners for example is that they see it and somehow they just mock it as not real programming when you can write… it's Turing-complete. You can do any algorithm that you want in Scratch and as a programming language it's powerful as any other potentially. But because it's not something that's used in a professional way, people mark it as, “Oh, this is just a toy thing.” And other teaching languages have had similar fates in the past. One of the useful advantages of us for Java is that we can actually point to industry and say, “No, no. This one's real. People use this.” But it's a silly distinction to have to make. But as you say, it all comes from a cultural thing. Some researchers describe it as people are not just learning to program. They're aiming to join what they call a community of practice that they want to come out, go out and be professional developers. And if you're trying to teach them with a tool that they believe is not used by professional developers, they will suffer. I think probably the easiest way to change programming education to some extent is to actually change industry first, even though that's obviously crazy tough. Because then people will actually see “Okay, yeah. I want to use that tool that industry is using.” So, I think if you really wanted to reinvent programming you'd probably start by trying to change the tools that some professionals use. And then that will sort of back-port as it were, into programming education. AVDI:  Interesting. So that's, yeah that's kind of a different approach. But I definitely see your point there. You're right. A lot of what people aspire to in education is what they see going on in industry. NEIL:  Yeah. And that can be somewhat dangerous, especially a few years ago. You'd get people saying, “I want to be doing C++ because that's what industry is doing.” AVDI:  Right. NEIL:  But teaching [inaudible] start programming in C++ is harder than some other languages, especially university. You have to manage those kinds of expectations. Find a way that you can actually reasonably teach people to program while also making it clear that there is a path onto professional development. CORALINE:  How much of the industry changes you were talking about deal with technical matters and how much of it is dealing with elitism? NEIL:  Yeah, I think there's definitely an element of that. If you have something that makes it easier to program, people will look down on it I think. People who already program, they'll say, “Oh, it's just a toy thing.” You see it with I don't know, it seems like games having a game engine already written like Unity or whatever, “Oh no. That's just toy stuff. It makes it easier.” Professionals are now of course starting to use some of these systems because it actually does make sense. But you often see this initial reaction of like, “It makes it easier? Well, it must be nonsense in some way or other.” Like objectively it's stupid. But I think culturally that's what happens and it is something you have to be quite wary of. JESSICA:  It's the conflicting values of, “Do I want to feel smart or do I want to be productive?” NEIL:  Yeah, exactly. CHUCK:  [Laughs] I love that. Well, and it's that classic example right, where the kids get praised for working hard or for being smart. And so, yeah. NEIL:  So, some work, if I can mention something that I am quite interested in, is Andreas Stefik who I think has possibly been on your podcast in the past. CHUCK:  Mmhmm. NEIL:  I find his work very interesting because one thing that he's discovered is that there's very little research or logic that goes into a lot of programming language design. And so, he came to it and started looking, “Okay, which bits have we actually scientifically examined?” And the answer turned out to be very, very little. And then he set about doing it and found this famous result that Perl syntax is no better than randomly generated syntax. And so, he is building a language that can be used for programming education. And he's doing it bit by bit, actually trying to test what keywords make the most sense to people. What sort of semantic model for types or whatever works well for people. And I think that's very interesting and a very useful future direction. For us with our language, we haven't gone along those lines because we offer Java and our other language in the same tool. So, we've tried to stick very close to Java in semantics and keywords so that it's not any difficult to use for people transitioning between the two. But yeah, I think Andy's work is very interesting especially for the future of programming language design for education and industry. AVDI:  That's got to be a very fine line to walk, deciding which parts you're willing to radically change and which parts you want to keep the same for familiarity. NEIL:  Yeah. And I think often people get tempted to change everything. Sort of a temptation, if you get to design a new language, “Well I'm going to have a new syntax. I'm going to have a new semantic model,” especially academics who come to design languages. They want to reinvent everything all at once and obviously it's just, it's difficult. We're just trying with our work to reinvent the editing interactions. We're not going to at the same time try and come up with some new type system or anything like that. It's just too much work. So, we pick, “Okay, this we'll just keep like Java. It's not perfect but we know it works.” Just go with what works for that aspect and vary the bit we're actually interested in experimenting with and playing around. JESSICA:  And if you change everything then you don't learn anything from the difference. NEIL:  Yeah, exactly. So, the study that I was talking about that we ran, we're using Greenfoot in both cases. They're programming using our editor, in the new editor in one and Java in the other. And the semantics of what they're writing is the same. It's just the editor interaction that changes. So, as you say, for a scientific point of view that's important. Everything else held constant, one thing varied, you can actually tell the difference between the two. CHUCK:  So overall, I'm just curious. We've talked about a lot of specific things and we've talked about some broader ideas. But as you study how people enter programming and learn about programming, what is it that you're actually trying to learn? What is your goal? What is the outcome that you're hoping to have or what information are you hoping to glean? NEIL:  So, I think we'd like to make programming easier to learn both in the sense that more people can get into it and understand it and also that they're less frustrated and spend less time getting to grips with it. One thing that we found, I mentioned this data collection project we did with BlueJ. So, we collect their source code and we can actually see for any individual person who's opted in, we can see the program over time as they write it. And when you look through some of those programming traces, some of them were just heartbreaking because you see this person fighting and struggling with the compiler. They're probably by themselves. They don't have anyone else leaning over their shoulder telling them what to do. And they're just going to get it wrong over and over again. And when you look at things like that, you just think, “Surely we can do better.” You see them get a compiler error message. You can see that they've misinterpreted it. They're editing some part in their program that doesn't matter. You're watching it way after it's happened wishing you could lean back in time, tap them on the shoulder and say, “There. The semicolon goes there.” But you can't and you're just looking at this. And so, having looked at some of the programming traces that we see, we can surely make tools that would do better. We won't magically get a hundred percent of the population understanding professional software development or anything like that. But the people who are learning to program, we can make it easier for them. Of that I'm sure. CHUCK:  Well, and if it helps with onboarding one more person or two more people or three more people and you start incrementally making that difference so it's hundreds of people or thousands of people, it changes the face of things because we now have more people with more diverse backgrounds coming in, people who look at problems differently and solve things differently and lead us to think differently. And who knows? Maybe that's going to lead to the next big breakthrough in programming or software or devices in general that in turn make a big difference in our quality of life as a culture or a society. NEIL:  Yeah. And I think one thing that's often missed with this putting programming into schools is people always think that this is to solve an employment gap and that we are there for aiming for everyone to learn to become programmers. But we don't teach music in schools so that everyone can become a musician. We teach it so that they understand the basics and they get a broad education. So, I think if we can… just teaching people to program a bit even if they never do any more, they get a sense of what is possible with a computer and what isn't. And if you think of things like lawmakers who are ignorant of computers trying to legislate for this sort of thing, just having a more, a population that's more aware of what computers can do, what they can't do, what the internet is, vaguely how it works, just being more technically savvy, I think it will just be better for everybody even if they're not doing more active development themselves. But just to have an understanding of what computers are and what they can and can't do. CORALINE:  It's a basic literacy question. NEIL:  Yes, yeah. JESSICA:  That's great. I have one more question. Neil, you mentioned that you’re a programming education researcher as part of a team. I'm kind of fascinated by the differences between team structures in academia versus industry. Could you describe how your team collaborates and works together and how they each advance their career while working in a team? NEIL:  Yeah. I think we're a slightly special case because often we're slightly larger than a lot of academic teams. So, our work is funded through a grant that we received from Oracle for which we're very grateful. And it allows us to employ three or four full-time. The university counts them as researchers because universities don't understand employing anyone who isn't a lecturer or a researcher. So, we're researchers. But really, we do software development for the most part. So, our time is maybe, I don't know, I think maybe 70% software development, 30% research, writing papers, going to conferences and that sort of thing. And so, there are three or four of us like that. We just sit in an office together and you would probably recognize us as a standard software engineering team. We maybe have slightly different goals and approach because we don't have any customers. We're producing open source software. We don't have particular fixed deliverables or time scales or anything like that. So, we can put in the features that we want. We can release it on a time scale that we want. Obviously we're hoping to get more users. More is better generally. But yeah, it makes for an interesting development environment. So, we're like software developers. But you'd probably recognize us as less advanced than some other developers. I don't know, just in terms of our… we're not very hip and agile and everything like that. [Laughter] JESSICA:  Oh, but you're totally doing open source. So, that's all the cred you need. NEIL:  That's true. CORALINE:  Yeah, but they're doing a lot of debating between spaces and tabs still, so… [Laughter] NEIL:  Yeah, so we're like a little small team. We don't really interact much with the rest of the university structure. We're just focused on building our software and releasing it. We all do development, testing, support, and share that around, like happens on small teams. JESSICA:  You sound like a highly functional software development team to me. NEIL:  Yeah. I guess so. Yeah. I don't know. I guess you have this thing where sometimes, I spend of my time going to academic conferences. Sometimes I go to industry conferences. And there's all the latest way to organize your software team and the latest technologies. And that's not necessarily us. We're perhaps a bit more conservative in that regard. So I always, when I go to industry conferences, I feel out of place. But it's kind of interesting. It's interesting to go there and see what it's like. CHUCK:  Alright. Neil, if people want to follow up with you, see what you're working on these days, where do they do that? NEIL:  I'm reasonably active on Twitter. I'm @neilccbrown. So, that contains a lot of details about our work and what we do. And I can also supply links to the… well, if you just google BlueJ or Greenfoot you'll find the things that we make. CHUCK:  Alright. Well, let's go ahead and get to some picks then. Avdi, do you want to start us with picks? AVDI:  I got nothing this week. CORALINE:  You've been too busy enjoying the beautiful scenery of spring in Tennessee, haven't you? AVDI:  That's it. That's exactly it. JESSICA:  You could pick spring. AVDI:  [Chuckles] That's a good one, yeah. CHUCK:  [Chuckles] AVDI:  Spring. Yay. CHUCK:  Alright, Coraline. What are your picks? CORALINE:  I have one pick today. I often have a problem on Monday mornings especially at standup of trying to figure out just what it was that I did the day before. So, someone has written a tool to solve this problem. It is called git-standup. It reminds you of what you did over the last N working days. You basically navigate to the repository, type 'git standup'. You can supply an optional author name and how many days back you're interested in. it defaults to the past 24 hours. And it shows you all of your commits, all of your commit activity in that repo. Or if you go up a level, to multiple repos. So, it can be a good reminder of exactly what you're working on. Maybe it's Tuesday morning and you don't remember where you left off. It's a great way to say, “Oh yeah, that's the last thing I did.” So, kind of handy for standup. Just run that a couple of minutes before you get together with your group and look smart. So, that's it. CHUCK:  Alright. Jessica, what are your picks? JESSICA:  My pick is Craft Conf. It's a conference in Budapest. It's coming right up, April 28th and 29th and they live stream and record the sessions. So, you could watch them live. You could watch my Elm talk live on the 28th or you could watch the recording which is immediately available. Super awesome. They have amazing speakers. You should check out their video stream or if you're in Budapest you should go. CHUCK:  Awesome. I've got a couple of picks myself. First of all, just to preface this I live in Salt Lake City but we are doing a meetup in Salt Lake City on May 5th. It's going to be downtown close to the Grand America Hotel where ng-conf is going to be held. So, if you're in the Salt Lake City area or you will be on May 5th please come by and hang out. And then try and sneak into the after party [chuckles] for ng-conf. But anyway, so that's one pick. Another pick, and this is something that I picked up while I was traveling the last few weeks, and that is a Zoom H6. Now before when I was recording I would record into an Edirol R-09HR which is a digital audio recorder. It has a couple of microphones on the top. It's a pretty nice little piece of equipment. I think they run about a hundred dollars. And it's just nice to have something you can carry around and record into that's not your phone and the microphones are a little better quality than that. However the Zoom H6 is the next level from that. It actually has most of the features you'd want if you had a little portable studio and it's built into this piece of equipment. Now, it's a little less easy to carry around because it's a little bit bigger. It's probably four or five, around about four inches by about two and a half inches and it's about an inch, inch and a half thick. But it is, it's awesome. It has four audio inputs. And the inputs actually take XLR if you know what that is. That's the three-prong plug for a microphone. Or it takes the quarter inch jack which is the larger size headphone jack. So, you can plug any of that into it. It also has volume controls for all four inputs. It comes with two microphones that you can plug into the end of it that are really, really great quality. And overall it worked out great. If you want to hear how the microphones sounded, you can actually go listen to the Entreprogrammers episode from a week or two ago where we were sitting in a hotel room in Las Vegas. Anyway, I can't say enough good things about it. I'm kind of going on and on about it because I really love it. But it is terrific. And it just records onto an SD card that you can then pull out and stick into your computer and pull all the audio files off. And I've noticed that there were some audio issues with the last few episodes. And so, I'm testing to see if my Edirol has just bit the dust, if there's just something wrong with it or with the SD card that I was using. So anyway, that said I'm going to go ahead and yeah, I'm done with picks. Neil, what are your picks? NEIL:  Yeah, so I have two picks. Neither of them are too technical, but an article and a book. So, the article that I read, it's about nutrition science. And the overall message of the article was about sugar and how harmful sugar is, which has been in the news a lot recently. And so, I find that interesting anyway, just whether you should be eating less in general. But the other part of the article is especially interesting from a science point of view because it talks about why nutrition science focused for a long time on fats and saturated fats which now seems to be thought to not actually be that harmful, and why sugar was overlooked. And it's about how science, culture among scientists can affect the places that we look and what we consider to be good results and bad results. It's driven by people basically. We have this vision of science as always driven by the facts and we always just look at what's true and that's not really the case at all. And it talks instead about how strong personalities within a scientific field can push it in the wrong direction. So, with my job as a researcher I found it really interesting to read about that. The second pick that I have is timely at the moment. So, when we're recording we've just had the whole Panama papers and all that sort of things hit the news. There's a book that I read a couple of months ago called Treasure Islands by a guy named Nicholas Shaxson. And it talks about tax havens and offshore tax havens and what that means and what the problems with them are, which sounds incredibly dull I realize. But it's actually a really interesting book. It's far more interesting than any book about tax has any right to be. And it's just this interesting history of tax havens, who used them, where they've come from, all the issues around them. And it makes the whole Panama papers thing make a lot more sense. And you'd probably get quite outraged at some of the bits of it unless you are a billionaire using offshore tax havens yourself. So, I find that really interesting and I thought it was timely. CHUCK:  Alright. Well, thank you for coming, Neil. I think this was a really interesting conversation just about how we learn and what the options are and what a lot of these assumptions that we make mean. So, thanks for sharing with us. JESSICA:  Yes, super interesting. Thank you. CORALINE:  Yeah, it was great. NEIL:  Well, thanks very much for inviting me on. CHUCK:  Yeah. We'll go ahead and wrap this one up and we'll catch you all next week.[Hosting and bandwidth provided by the Blue Box Group. Check them out at Bluebox.net.]**[Bandwidth for this segment is provided by CacheFly, the world's fastest CDN. Deliver your content fast with CacheFly. Visit C-A-C-H-E-F-L-Y dot com to learn more.]**[Would you like to join a conversation with the Rogues and their guests? Want to support the show? We have a forum that allows you to join the conversation and support the show at the same time. You can sign up at RubyRogues.com/Parley.]

Sign up for the Newsletter

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