[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 iOS developers, providing them with salary and equity upfront. The average iOS developer gets an average of 5-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 also give you a $2,000 signing bonus as a thank you for using them. But if you use the iPhreaks link, you’ll get a $4,000 bonus instead. Finally, if you're not looking for a job but know someone who is, you can refer them on Hired and get a $1,337 bonus as thanks after the job. Go sign up at Hired.com/iphreaks]
ANDREW:
Hey everybody and welcome to iPhreaks episode number 144. This week on our panel it’s the just two of us. It’s me and it’s Jaim. We’re going to talk a little today about some topics related to people that are new to iOS development and programming in general— how to learn, how to teach and some of these things just to see where the conversation takes us.
So Jaim, before the show we were talking a little about a conversation I had with somebody that is quite new and is out there looking for his first iOS development job and had questions about how he can get a job that will allow him to learn, to get better and to gain experience. It will be a really valuable first job for him which prompted this topic. Then you mentioned that you’ve been teaching kids to code lately. The thing I wanted to start with is I wanted to remember back to when I was learning to program and I wonder about you, too. How did you very first get started programming?
JAIM:
When I was a kid, my parents bought me an Apple IIe. I did code the basic games doing that— copying stuff on those magazines, created those games. By copying out of magazines, I mean copying a page or two, getting bored and finding a friend that got up from somewhere. But I would code my own games and I got away from computers for a while.
My Apple IIe got a little obsolete when I was in high school. I just played music and did all that stuff. Started engineering and really didn’t code a whole lot in school. I studied electrical engineering and audio based stuff so lot of recording, a lot of circuits and Digital Signal Processing but not a whole out of code. Had a couple classes to [inaudible] but wasn’t graduate thinking, “Oh I’m going to be a software developer.” In fact I was, “Well not really.”
That was the mid 90’s before the first .com boom. The economy is pretty bad at that point. So a lot of my friends are going to grad school and stuff like that. Some found cool jobs but I end up finding a job in QA doing testing and stuff like that. Within a few months they realized, “Oh, he can probably code too,” so it is helpful in the development and I just walked into that role. So it was handed to me; it wasn’t something I was really focusing on. Basically, I was just thrown into the deep end. “Okay here’s a project. Fix these bugs.” I had done a little bit of C, C++ but not a ton of it. So it was basically just learning as I go. That’s how I got started. That’s not a fairly repeatable thing but one thing to take away with it is take what you can; do a good job, help people solve problems; and you can get a chance to code in a lot of different positions. So if you’re doing QA, you can do scripting. There are a lot of different things where you can get a chance to start writing code and get experience creating those software. That was my experience.
ANDREW:
I like that. I guess our experience is— are somewhat similar. So my dad was a— well he is a programmer but he’s also an electrical engineer and he had me doing both from the time I was quite young. I started programming in basic on a PC probably, I don’t know, when I was five years old. We also had a Mac at home so I did a little bit of HyperCard here and there. I don’t think I thought of that as programming at that time but it sort of was. But really it was hardware that interested me. I went to school for electrical engineering like you had. I think I had one C class that was just a required class the first year I was there. But mostly I was not a programmer.
Then, decided I wanted to learn how to program while I was still in college and thought myself. It’s just a thing I did for fun. I didn’t at all plan for it to be my job which was good cause it meant I was doing it just because I wanted to do it. My motivation was good but I also didn’t have a lot of help. I
was figuring out as I went along and found some opportunities to use that programming at my job where I was doing hardware engineering. Then eventually just decided to make the jump and do it professionally.
I have to say that I thought I knew how to program better than I actually did when I really first started doing it with other people who knew what they were doing. I learned a whole lot from working with people who are a lot more experienced than me. My code got better; my grasp of all the concepts certainly got better. It was a really great thing to have somebody around helping me. But I like what you— the part of your story where you weren’t really a programmer and you got sort of thrown into it starting with testing. So you had that experience of going from super, what you might say a super, super junior developer and you were not even really a developer; you were QA into learning how to program. Did you get help from people that were around you?
JAIM:
A little bit but is mainly just trying stuff out. There were other developers in the team. It was a startup so it was a really small company and had other stuff to work on. I wasn’t sure of the questions to ask so I just poke it around till I figured the stuff out. I was not a very good developer for the first number of years [chuckles]. To be honest, a little more of mentoring would have been pretty valuable.
ANDREW:
Yeah. So I wonder about that not as a programmer. But my first job doing electrical engineering, my boss was— had been doing it at that company for 35 years or something so he was very experienced and knew what he was doing, very smart. I felt a little bit out of my depth of course. I was the youngest person at the company period. Let alone an engineer and I would ask him so many questions. I remember one day, him saying, “You need to quit asking me so many questions and figure stuff out on your own.” I felt like, “Well I am trying to figure this stuff out on my own. I only asked you because I can’t figure it out.” The point was I think there is certainly a balance to be struck between getting help when you really need it and also sometimes struggling through things on your own. I certainly think as a programmer, you learned a lot when you struggle through a problem.
JAIM:
Definitely. I think the problem solving is the number one tool that you’re going to use to your entire career. Coming out of school or even coming out of a boot camp or whatever you’re doing, any engineering company realizes that they’re going to lose money on any new hired for the first couple of years. That’s something— my uncle, who was a mechanical engineer, had his own company and he’s like, “Yeah I’m going to lose money on them for the first two years just because being someone to hold their hand, tell them how to do things. But at that point they kind of figure it out. They’re valuable employees but there’s a lot of stuff yet to figure out.” A lot of stuff that is not taught in school and probably shouldn’t be taught in school.
ANDREW:
On the other hand, I think there’s a lot you can learn from somebody that is more experienced and is willing to sit down from the beginner’s perspective if you’re out looking for your first job.
I certainly think there’s a lot of value in finding a company that understands what you just said. That they might not hire you and have you right out of the gate doing really great work completely hands off but they’re hiring you because of your potential and they’re willing to put in time and effort— they can end up with something really good.
JAIM:
Yeah take time—.
ANDREW: and effort [crosstalk] training you or helping you, I mean.
JAIM:
Yeah definitely and taking on junior people and throwing off the deep end probably not a terribly a good way of doing it. I wish I would have handled it more entering. A lot of people I was working with would have helped if I have known how to ask or thought about that but didn’t. But yeah, it’s important to if I got someone I can ask questions with. It’s also important to say that it’s offered a
lot of really trivial things that we do. As software developers, you knew if you’re senior person. Sometimes you’re changing text which does not require a whole lot of experience to do. Changing a color, moving this thing around the screen a little bit. So there are a number of these trivial task that you get to throw to junior developers on and get them into the mix.
ANDREW:
Well that’s an interesting point. I think as somebody now that has some experience and has worked with people who are newer, it’d be interesting to talk a little bit about how, as an experienced developer, you can best do that. Because there’s a whole spectrum in between just throwing somebody into the deep end and not giving them any help and giving them some project that’s— you’re going to write an app from scratch without any help. On the other side, you can be really reluctant to give somebody any responsibility at all because you feel they’re going to screw it up or they don’t know what they’re doing.
What are some ways do you think Jaim, that as an experienced developer can really effectively help and mentor somebody that’s new beyond, of course, time and change text or colors which I think is great?
JAIM:
Yeah. Just keep handing him more and more of things gradually. Let them make mistakes. That’s important. Maybe not let the code get committed, pushed out or whatever. But let them try some things and give them feedback. It’s important to be positive. It’s easy— we do a lot of— with the clients I’ve been working with, we do a lot of full requests. It’s easy to just be negative. All negative full request comments, and when someone just getting their bearings on them, that can be discouraging. So it’s important to say, “Okay. This part is good. This is good. This works. It does what you want it to. Here’s some ways we can improve it.” But I think it’s important to just keep giving more tasks. Let people make mistakes. People will uncover their own mistakes pretty quickly. Andrew, do you have any experience with that?
ANDREW:
Yeah. I think you’re right. I also think that there can be some more formalized processes for helping junior people including things like pair programming which I’m not really a fan of that but I know it works well with some places. But formal code reviews and maybe less formally, just being open and approachable when somebody has questions. I think it can be really easy to get annoyed by somebody new asking questions that to you seem obvious but they weren’t obvious when you first started.
Anyway, so I mean some guidance and feedback that really helps them understand how you might do things differently or learn more about the way that you’re experienced and forms the code that you write so that they can make and learn from that. Sometimes it’s best if somebody doesn’t have to make a mistake and ship a bug and whatever before they figure out a better way to do something.
JAIM:
Yeah definitely. I’m a big fan of Pair programming to transfer knowledge with even if come on a new project or something and people are already working on it and I have accident developer sit down with me. Let’s work through this. Work through a problem this way and understand just the whole ecosystem because there’s a lot with the software project that’s beyond code. Are we talking to a web service? Is there any authentication we have to do? There’s tons of things you had to figure out when you sit down with two new projects. And even for a senior developer who’s done it many, many times, I do consulting so I’m always on different projects. It’s still like what’s happening here? Okay, does this work? How do I get this set-up? That would be completely daunting to someone who’s new. So I think pair programming, even for an hour or two, just to get things started. Get things up and running and be able to watch. Some are more experienced or have them believe you. I always make the junior person drive to the typing and lead them on if I’m in that position.
ANDREW:
Where you work now, do you guys do formal code reviews at all?
JAIM:
So the client had more work with. Yes we do code reviews. So we do code along on a branch into a
full request. We have at least two developers take a look at it. It’s a good chance to see what people are doing and make sure everything’s good. Even I overlook things so it’s always good to have another set of eyeballs on it.
ANDREW:
We don’t have a formalized process for it at mix in key but especially when I was first starting out and whenever anyone new starts out quickly they’re— I hesitate to use the word probation because it’s like they did something wrong— but for a while, at least all of their commits are reviewed. I know I learned a lot from that process. I also learned a lot from doing that for other people because a lot of times, somebody who is new had— knows things or does things differently than I might. I
actually learned things from them. They do things in a better way that I might have so I really like that. For all the people involved I really like that idea of, whether formally or informally, knowing what the people you’re working with are doing, knowing the code they’re writing, not just being siloed off on your own and not really working closely with the code that other people are writing.
JAIM:
Yeah. I think that’s good point. So if you’re someone coming in to programming, ask how or things reviewed. Do they do formalized process? Do people just scan over it? Do they shift it and wait for the bugs to come back and yell at you? That’s why they do it, that’s a bad sign if you want to learn. But look at the process that they have and your option is to learn and code review is one option to get feedback from people that have been doing it for a long time.
ANDREW:
So I have been teaching iOS development for about a year at a boot camp here in Salt Lake to people who mostly are completely new to programming in general. Although, some of them have some programming experience but they’re certainly all new to iOS programming. It’s actually been quite a fun, fulfilling experience to teach new people, to see them go from— they come in and they’re really excited to learn but they don’t know anything. They don’t even really know how much they don’t know and they realize how much there is to learn. By the end, they’re certainly not experts but they feel much more confident with their ability to keep learning and to— they’re able to build stuff. They’re able to do useful things. Helping be part of that process has been really fulfilling. It’s also taught me a little bit about, I don’t know, some of the ways that people learn and how they think.
We actually did an episode with the guy Joshua who wrote the curriculum— the original curriculum for this boot camp. I can’t remember what episode number that was but I’ll find a link to it. We talked to him about writing that curriculum but as a teacher I’ve learned that as I’m teaching, being able to rephrase and explain things in depth and be ready to answer questions helps me solidify the knowledge I have. I think this is true of any field not just programming but it’s been a good opportunity for me to learn things or maybe to better understand things that I thought I knew as I prepare. For that reason I— not everybody can do it as a job but when you have the chance teaching somebody new about some of the stuff you know can be a really good valuable thing, I
think.
JAIM:
So what is it— what are things you’ve learned teaching new developers?
ANDREW:
Well, one thing I’ve learned is that the stuff that I think is sometimes I’m not very easy— not very able to predict the stuff that’s confusing to a new person because that’s not the stuff that’s confusing to me. But even simple stuff like why is there a star in front of everything in objective C, right?
And you take that for granted after you’ve been doing it long enough. But I think more broadly, as I’m teaching, my goal has become more and more to help them understand only as much as they need to know while still understanding that there is plenty more out there to learn. Because there is a balance to be struck between understanding everything which, if you really understand everything, you understand more than I do cause you’re all the way down at the silicon level eventually. You’re down the atomic level eventually but they don’t need to— they don’t necessarily need to understand how the Objective-C Runtime is written but they should understand it enough to build an app. That’s what our goal is. I’m trying to think just off the top of my head of some specifics that I’ve learned.
I think one thing is how valuable it is to teach people and to learn as a new person, debugging skills. So the first few days that they’re working on this, inevitably people write code that won’t compile or it crashes or does something. At first, they don’t even know that there is a thing called a debugger. So very early on, it helps to teach them some really basic skills for critical thinking and troubleshooting and testing your assumptions. I think I didn’t realize how valuable those skills were right from the very beginning.
JAIM:
Yeah definitely. How useful it is if you’re teaching iOS development use code Xcode and the debuggers right there? You don’t have to wire up any [inaudible] stuff like that.
ANDREW:
Yeah but if you don’t know about it, it’s still— I know these people will have an exception get thrown and they’ll see this stuff spewed out of the console but they have no idea what that really is. They know it’s a problem— their app stops but they don’t have the faintest idea of how to start tracking it down. I’m sometimes surprised at how they don’t even seem to read the message that’s logged. Even at first, there is not this connection in their mind between, “Hey these messages, if I read it, it might help me find the problem.” It’s like it might as well just be Chinese. They don’t have any idea what’s going on.
JAIM:
Yeah. If you’re a new developer, you definitely won’t understand what that message means. But you copy and paste it and there’s probably a Stack Overflow question that explains it.
ANDREW:
Right. So I think the point there is, no matter how experienced you are but especially for a new person, there is really nothing wrong with using Google. I certainly put error messages in Google all the time, even now.
JAIM:
Yeah definitely. Daily, I would say. What is that error? I don’t know what this means.
ANDREW:
I’ve also heard or seen somebody – that people that I’m teaching. It’s like they think that— they think it’s like when you or in high school and you’re not supposed to have a calculator on a Math. I think Google is the equivalent of a calculator on a Math test and it’s cheating somehow.
JAIM:
Yup.
ANDREW:
But that’s not how it is.
JAIM:
Life is an open book people.
ANDREW:
Yeah [chuckles].
JAIM:
You’re cool [crosstalk].
ANDREW:
Your job as a programmer will be too.
Another thing I’ve learned is that a lot of times, my basic response to a question will be, “Well, go read the documentation.” I think that’s— it’s important to teach people the documentation as a resource that’s available to them and one that they should use. At the same time, sometimes that’s actually not a very good answer because a lot of documentation is written for experienced people. If you know nothing about this whole subject that you’re looking into, sometimes the documentation is not really the best place to start.
JAIM:
Oh that makes sense. Yeah. Documentation— the Apple docs. They’re very good. They’re swifted; it’s all good but I remember trying to go to read BAND files when I was trying to figure a stuff out and just not getting anywhere with it. But it’s important to learn – teach people how to do Google searches.
I remember I was working a project and I’d done most of the app and they’re going to bring in a junior person. And every time he got stuck, he’d send me an email, “What do I do? I try to walk him through the process like, “what did you try?” “When I ran it, it didn’t work.” “Alright.” I helped a lot a couple times and the questions didn’t get any more complex. I knew this was a smart kid who was just out of school. He might have been an intern at that point.
But I came walking through like, “Okay. Well, what did you try? Did you try Googling anything?” He’s like, “Well I just copy and paste the whole thing. Nothing really came up.” “Well, here, try this. Take this text out there and try that. Before you email me, write down three things that you tried before doing it.” After that, it happened then he had— oh so the questions are a lot better. They’re detailed. I can answer them quickly without going I have no idea. So that’s even learning a little bit of Google foo. Try to research those error messages and knowing which parts of the string are specific to your code. If it’s a variable name, that stuff can show up in a Google search, but you can strip that out, get the rest of the error string. Someone else has probably seen it. It’s probably a
Stack Overflow question about it and they’re explaining it. You could, “Oh, okay well that’s what is.” So Google foo is important— a very important tool.
ANDREW:
Yeah, definitely is. I sometimes think that being able to use Google and also being able to ask – properly ask a question— are really, really important parts of debugging and troubleshooting. I think that’s another thing that’s hard for beginners is that they run into a problem and they often— maybe they wanted to ask a question on Stack Overflow or whatever but they don’t— they really don’t even know how to ask the right question. There are people— this has been talked about a lot actually; I picked an article that talks about this on our last episode.
As a new person, learning how to ask a good question and some of the things that Jaim talked about like fully describe the problem; describe what you’re trying to do; describe what you’ve tried; post the code that you’re using; post a detailed error message if you’re seeing an error message. Don’t just say, “Oh, I got an error. What do I do next?” Cause there’s actually whether you can decipher or not. There’s often a lot about— a lot of valuable information in error messages. But also as somebody who’s answering questions, sometimes you have to be patient and wait through some of those problems if you really want to help. It can be frustrating sometimes but those are the things new people struggle with. Just inevitably, I don’t think there’s any way to solve it behind— besides being patient and understanding and guiding people to do better.
JAIM:
Yeah definitely. It’s important to let people see your thought process when you’re working through it. So even going back like, “What did you try? Did you try searching for this?” That’s a process I use all the time. So it’s important to show— well that’s how a lot of people saw problems. Someone else has thought of this. They’ve encountered it and learn from them. Then there are cases where you’re way beyond Stack Overflow which I get there frequently. You just had to look and you have to read the documentation. But for most stuff, for most apps that’s really not an issue.
ANDREW:
Both you and I said that we started programming when we were kids and I think that’s actually true. A lot of programmers although certainly not all and I think there’s been a real push lately to encourage more kids to learn, to be exposed to and to learn programming. You’ve mentioned, Jaim, that you’ve been working on teaching kids to program a little lately?
JAIM:
Yes. So I’m working with – there’s an organization in Minneapolis that does a bunch of programs that help kids learn to code even from high school girls that are part of Technovation, to the code clubs which I work in which operate at up north of Minneapolis, just underrepresented on the community. So every Monday, I unplug from what I’m doing and head up to North Minneapolis. We’ve got – do some volunteering in this community center. They’ll bring in a group of kids and we try and teach them code stuff.
We use tools like Scratch. We try to do Scratch, if we can, that works pretty good for kids that are maybe third, fourth grade and up. But we’ve got other tools and basically we’re just trying to teach the basic concepts. If you’re not familiar with Scratch, it is a GUI based tool where you can drag the column blocks, probably drag blocks unto a screen that represents moving a figure when the call is right across the screen or doing four loops, that kind of thing.
We actually create pretty intricate programs using this block language. But for kids, they just drag and drop. You drag it off the screen into the program area and we can teach the basic things, basic computing concepts.
Some of the kids just totally get it. They’re right on board. They’re like, “Oh, this is so cool. We can make this move around. I can get my name and make it flash.” Stuff like that.
So, it’s been a lot of fun. But it’s also getting into the cases where they ask question that I have no way of knowing how to answer in terms that you can think of. Similarly, to the Objective-C, why is there star here? If someone just trying to get the syntax down you will explain it pointers are just going to blow their mind. So when they get into more advanced for loops or get into just figure out basic stuff out like, “Okay how can I break this down?” So it’s an interesting exercise but it’s rewarding.
ANDREW:
I wonder about what ways have you found are successful for getting kids to want to learn programming? So they’re— sit them down in front of a computer and have these exercises ready for them or whatever. But how do you make that an attractive thing; something that they think is cool and interesting and worth spending time on?
JAIM:
Yeah. That’s tough. Kids they’d rather be playing games, a lot of them. But there’s a percentage of kids that just get, “Oh this is so cool. I’m creating something.” It’s just important that they have an environment that’s quiet where they can focus. Think about what they’re doing— if you’re trying to do in a loud area, kids are running around and yelling. That’s just not going to work.
It’s hard to— I’ve had trouble picking up a carrot that— because if you talk to a high school kid, “Well this is a good job. Maybe can go to college. You can do it exact thing. You’re going to get a good job.” If you’re in elementary school, you’re not thinking about job stuff like that. So we just try and keep things simple. Just try to do fun things and for the younger kids we do a lot of stuff off code.org. They’ve got tutorials and walk them through. It’s important to— well especially the younger kids— to make sure that if they get frustrated, you’re on top of it because if they get frustrated, they get mad. They don’t understand something it had and, “Okay. Code sucks. I hate it.” So you can lose them pretty easily. But we’re doing this. We can. We’re learning. That’s what we’re trying to do.
ANDREW:
I think there is a— they’re probably is a certain personality that’s just going to do better than others because no matter what, to be a programmer at some point, you have to be the kind of person who’s willing to struggle through a problem for a long time when it’s frustrating. Be fulfilled enough by finally fixing it in and seeing it work. That has to make you happy enough that it was worth the annoyance and the time you spent. Probably for some people it’s just not.
JAIM:
Uh-hm. Yeah we try and have projects that everyone works on so they’re learning one concept and give them the opportunity to modify what they want to. But if this one drags to puff and tap it off the screen, they can do that too. Because we’re trying to expand beyond just the people that might be the natural programmer types. Get everyone exposed to it. So it’s not completely formed if they encounter it in the future.
ANDREW:
I don’t know if you have a good answer to this question. We didn’t talk about it before hand but if somebody’s listening to this and teaching or especially helping kids learn to code or something they’re interested in. Do you know of good ways to get into that?
JAIM:
I’m not sure. In Minneapolis, there is Code Savvy which does a lot of things. That’s a perfect— very good model of how to do things. They do— they have a big involvement with Technovation which is a program for teenage girls to write apps using a similar block-base language but actually runs on an Android app, on Android phone. So look around. There’s a big movement across the country of trying to keep— teach kids to code.
I’m surprised that a lot of these kids are learning Scratch in school. It’s something that lot of kids is being exposed to. So it’s happening. But [inaudible] Code Savvy and that’s Minneapolis-based but there might be similar organizations around.
ANDREW:
Yeah. I wish I knew. It’s not something I’ve got involved with at all. Other than – my little sister’s 14 and she has done some stuff with Scratch and has learned a little bit to program in Python but that’s all just been on her own. I wonder if there is a way to get more involved.
Alright, well, is there anything else you think we should talk about related to teaching or learning to program or to be a better developer?
JAIM:
Think we covered it. That’s all I can they give.
ANDREW:
Alright. Well should we get to the picks?
JAIM:
Yeah. Let’s do a pick. Let’s do some picks. So I’ll just choose some picks of the resources that I used to— I’ve been using this to teach kids to code. One is Scratch that we talked about. I’ll put a link in show notes. Hour of code which has – of code.org, has a bunch of things that are just tutorials that walk you through, basic code type things. So it’s better for younger kids; they’ve had a
bunch of things, and Code Savvy. I’ll keep my picks at those. I’ll put the links in the show notes.
ANDREW:
Nice. I’m going to do a little bit less relevant pick then I’ll have one that is relevant. My first pick is an app called – I don’t know how you say it – Prepo, I guess? Prepo by Mothership.
I had an app that I had been using to do this for a long time but it was junky and it was never updated to support @3x-Retina. So I found Prepo this week. But anyway this is an app where you’ve got image assets for your iOS app or your Mac app. Often you’ll create those at now it’s @3x for the iPhone 6 plus. Then you got to make @2x and @1x versions. It’s not a big deal where you can just use image editor to resize them down and save them out. But it’s a tedious, annoying thing especially if you’re changing them, making tweaks.
So this app lets you keep a catalog of all your artwork and icons etc. You can have those per app and it will automatically figure out which resolutions need to be created. You can just hit export and it will regenerate all of the correct sized retina versions for you. So it’s been a good tool for me. It’s free on the Mac app store. I think they might have— so I think they have an in-app purchase to buy the app for six bucks or something like that which is well worth it for me. So that’s Prepo.
My second pick— I think we’ve picked before and I’d really like to get them on the show so we’ll see if we can do that but it’s App Camp For Girls.
App Camp For Girls is a coding camp. Specifically they do iOS development for young girls. They started in Portland and they’ve branched out a few other locations. I think they’ve done some really good stuff. It’s all basically run by women for girls. The teachers are all women. I’m really impressed with them. I think they’re doing really cool stuff. So that’s my second pick.
Alright Jaim, thanks for talking to me today. It’s been interesting to talk about— it makes me want to go find out a little bit more how I can get involved with teaching kids to code. Or at least to have a better answer the next time somebody asks me about that because it’s a question I get pretty frequently.
JAIM:
Hey definitely. It’s a lot of fun. It’s cool to see kids get it. They’re like, “Oh this is so cool. I get to do stuff. I get to create new things.” It’s a ton of fun. It’s cool to see them like lights go on in their eyes.
ANDREW:
Definitely! Alright, thanks Jaim. Thanks everybody for listening and see you 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 cachefly.com to learn more]