086 iPhreaks Show - Teaching People to Code with Joshua Howland

00:00
Download MP3

The panelists talk to DevMountain's Joshua Howland about teaching people to code in iOS.

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 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/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 onset. 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]**[This episode of iPhreaks is brought to you, in part, by Postcards. Postcards is the simplest way to allow you to feedback from right inside your application. With just a simple gesture, anyone testing your app can send you a Postcard containing a screenshot of the app and some notes. It’s a great way to handle bug reports and feature requests from your clients. It takes 5 minutes to set up, and the first five postcards each month are free. Get started today by visiting www.postcard.es] **CHUCK: Hey everybody and welcome to episode 86 of the iPhreaks Show. This week on our panel we have Andrew Madsen. ANDREW: Hi, from Salt Lake City. CHUCK: Alondo Brewington. He must be using Shush, too. I’m Charles Max Wood from DevChat.tv and this week we have a special guest, Joshua Howland. JOSHUA: Hi guys. CHUCK: You want to introduce yourself real quick? JOSHUA: Sure. My name’s Joshua Howland. I’m an iOS developer and I work for a company called DevMountain. We have a 12-week course on iOS development that we’re having a lot of fun with. CHUCK: Awesome. So it’s a 12-week course – you’ve got some graduates at this point? JOSHUA: Yeah, we’ve been through two cohorts so far, so we’ve sent about 35-40 graduates through. We’re just about to start – the way it works, one of the things that we did that’s a little bit unique is that it’s an after-hours course. You can work your full-time job or whatever and then classes start at six and end at nine, three days/week, and then they’re on Saturdays for a few hours. That allows us to educate people while they’re still working and allows them to make the transition more easily. We just finished the last two after the last cohort, we’re just about to start another after-hours cohort in two weeks, so we’re getting ready for that. CHUCK: Are you teaching them Swift or Objective-C? JOSHUA: The curriculum is all in Objective-C. In fact, the class as it’s being taught is taught like Objective-C. All of the class resources are available in Swift. I tried to go all Swift with this last cohort and about two weeks in, Apple made changes to the compiler and all of my previously written curriculum – all of the code, practice materials – broke. I mean, not all of it but a huge chunk of it had broken, so I had to go back and fix it all in the students. It’s really hard, I think, where Swift is currently for students to learn on a bit of a moving platform, so we’re keeping them on Objective-C for now. Plus today, if you went to get a job as an iOS developer, it just wouldn’t make sense if you were Swift-only. We do have a couple of classes that are on Swift, but for the most part, we stay in Objective-C. ALONDO: Now are these students coming with their own laptops or are you providing it during the duration of the course as well? JOSHUA: No, the students have to provide their own laptops; if they want to use iPhones, their own iPhones. They get a textbook; they use the pretty decent iPhone coding book. I got to look up which one it is now that I brought that up. We give them a textbook and a bunch of code on GitHub, but for the most part, they bring their own laptop. ALONDO: Okay. During the course, they’re starting with the basics and then getting into an actual project. Is that the way that it’s structured? JOSHUA: It’s really practical. They build about 40 applications over the course – I mean, applications. [Inaudible 04:11] little things. But maybe ten pretty strong applications, like a Pomodoro timer app or they do a Day One revamp called DayX, and a number of other small – a scorekeeper app. They do these small apps along the way and then halfway through the course, we set them off to work on their own capstone projects, so they get to pick a big project they want to work on and then they’ll spend maybe six weeks and however many hours they have available on that time to build their very own project. We’ve had some pretty impressive capstone projects come out. ALONDO: Anything that’s made its way into the App Store? JOSHUA: Most of the students actually get an app in the App Store; some of them even have two. We’ve had multiple students with a couple of apps. One of my favorites that's in the App Store right now is Pointedly, which is a scorekeeper app; WiredIn, which is one Caleb Hicks – one of my good friends, he went through the course – did. There’s a Piano Timer app. The Piano Timer one’s pretty cool because it only counts down the timer while the piano is playing, so if you put an extra piano while your kid’s practicing piano, it listens for certain frequencies. If no one’s playing the piano, then it doesn’t countdown, so you can kid of torture your kids with actual practice time. There’d been some pretty cool ones, and like I said, it’s very practical. In fact, we spend only a little bit of time on theory; it’s mostly just “This is how you build this, this is how you build that, these are what the example gives you” and everything’s about building and doing and experiencing. That’s obviously how you really learn to program. ANDREW: Along with that, I’m kind of curious about what things you focus on. iOS development is a huge topic and there are tons of different frameworks and APIs and different kinds of apps you can write. I imagine you have to basically teach a subset of that. Can you talk about what the subset is that you think is sort of the essential stuff for somebody to learn that’s going through the course? JOSHUA: We start out really, really basic. It’s stuff like how to put a view in and from there it goes into things like the navigation stack [inaudible 06:07] controllers, we spend some time networking, we spend some time with third party code, pulling in CocoaPods sub-modules – that kind of thing – so that they can go to GitHub and get libraries or useful tools. Then the first six weeks, every day is a new UIKit object. I mean, we do a lot of time on TableViews; we spend most of our time on TableViews – DataSource and Delegate method. The delegate model is so strong in Objective-C and in Swift and in Cocoa, I guess, but if you can really nail down how a TableView in the delegate works there, then other delegates start to make a little bit more sense – or the protocols start to make sense. So we spend a lot of time in that. Then the last six weeks, every class has a one-hour lecture on a topic like MapKit, for example. Instead of diving deep into MapKit, we spend an hour reviewing what MapKit is, go over the API endpoints, what Apple makes available to you, and then we let them loose. Any student that has MapKit in their capstone project can go talk to the teacher and get further instruction on MapKit and have a little bit more detail. The first six weeks we give them the foundation for walking away with [inaudible 07:20] and I think what we found is most people that want to learn iOS, they start and they try and the hardest thing is knowing how to learn iOS. I think what we teach them that's the most powerful is we give them the skills necessary so that they’d feel moving forward, that they can take the time and if they put in the work that they’re actually going to be able to figure it out and make it happen. Because we give them the tools: how to read through Apple docs, how different APIs – what is Apple’s style of the way the APIs work and how the code should fit together and the life cycle of ViewController. Little things that are hard to pick up on your own, but as we work through with them for 12 weeks, they walk away with the ability to really dig down and build on their own. CHUCK: Are you typically looking for people who have other kinds of programming experience, or are you looking for people who are brand new to programming? JOSHUA: This is probably the most common question I get from potential students. “I’m not really good enough yet at programming.” We’ve had a lot of students go through the web first, and then come in to iOS, and they always say the same thing. They say, “I just wanted to understand programming before I jump into iOS.” I think it’s silly. It’s like saying, “I needed to learn Japanese so I studied Spanish for 12 weeks.” [Chuckling] But obviously, learning a second language is difficult. Learning something that’s a completely different way of thinking is difficult, but if you’re up to that in learning in any language – Objective-C is no more difficult. In my opinion, it’s more verbose; it’s more legible for me. Obviously, it’s my native programming language. The same kind of goes for Swift. It’s the kind of language where, if you’re going to pick it up, knowing another language I don’t think helps that much. So we do spend a good first week diving into thinking like a programmer – how does a programmer see things and how do they approach problems, and how do they solve problems. Whether you come in with a background in Ruby or no background at all, I think you’ll do really well. In fact, Chuck, you and I talked a while ago about this. I think the best students are ones that want to think that way. It’s not just “Just show me how to build an app”; it’s “I want to think this way and I want to understand the way developers think.” When they start thinking that way, when they have the desire to think that way, it gives them the ability to learn. Developers that do come from other backgrounds, they do really well, but that doesn’t mean that students that don’t come from another background don’t do well because I think they do pick it up pretty quickly. ANDREW: Maybe this is too broad of a question; maybe it’s not easy to answer. But talking about somebody who’s starting from scratch, who doesn’t have programming experience, what are some of the things that you find that are stumbling blocks, the hard parts for them to grasp? JOSHUA: Frames. No, I think whatever they approach first. Programming is hard because it’s a different way of thinking. It’s not innately hard because of what it is; it’s hard because we’re not used to thinking the way that programs written. And so whatever it is that they’re learning first, that’s going to be the thing that they struggle with. It’s really interesting because we kind of transitioned how we did pre-course material and pre-class readings so that by the time they’re in class to learn something, it’s their third or fourth time working on it. That way, they’ve started to grasp whatever it is. I mean, there are things that I think are programmatically complex that students don’t struggle with at all, like having things on a background thread versus a main thread is something that a student doesn’t – they don’t struggle with it. The reason they don’t struggle with it is because they don’t have to think about it. They just say, “Wait, which thread is this on? Oh, it’s on the background thread. We went to the main thread in order to change the UI, right?” The things the struggle do struggle with, like I mentioned – frames – thinking about an x-coordinate, a y-coordinate within a height their very first day, which is you do frames on the first day, their minds just blow. They’re like, “I have no idea what you’re doing on the board there. What does this even do? What is this? This is alien,” which is weird to me, and probably very weird to you. You’re like, “Why would frames be hard?” but this is a completely new way of [inaudible 11:38] thinking, and so it acts as a stumbling block. The other thing I guess, coming from an object-oriented programming standpoint, is the difference between a class and an instance. I think that is hard to explain, and because it’s hard to explain – being hard to explain probably makes it hard to understand, because we’re probably not giving the best explanation possible, but I think students have a hard time grasping, unless they come from the background of object-oriented programming, they have a hard time breaking, separating the class from the instance. ALONDO: Are the students being introduced to autolayout at this portion to sort of mitigate the stumbling block of frames, which is having a different relationship to understanding how views are laid out? JOSHUA: That’s the hard part. If they’re struggling with frames, do you start with autolayout the first day? Because autolayout’s not for the faint of heart, if you have never written a view layout code at all. We come into autolayout about the third week, and I think even though we spend a significant portion of time on autolayout, again, just like frames, it’s just this thing that the students – their brains aren’t working that way, and so it takes time. Some of our students walk away masters of autolayout and masters of frames, and some of our students come away really struggling to figure out how to create a decent constrain; how to make their views layout. I think a lot of it has to do with their ability and their desire to wrap their brains around something that’s complex and that they haven’t thought of or experienced before. ANDREW: I get into this discussion with my brother a lot. He’s actually an artist, but we sometimes talk about programming or art talent. I can’t even draw a circle; I have no artistic talent whatsoever. What do you think about the idea that some students just have a natural aptitude and others don’t? Do you think you see that? Do you see people who try really hard and really never get there as opposed to other people who don’t have to try very hard pick it up really easily and become great iOS programmers? Or do you think if everybody works hard, it’s really just effort put in and desire that matters? JOSHUA: I am consistently shocked by which students come away the best students. There’s obviously one or two students that are going to come in, and they’re going to come in with a background in development, and they’re going to understand the concept more easily and they’re going to move forward more quickly. But the rest of the students, say the other 95% of the students, I’m always shocked which students come away with the best-looking code, the best understanding of APIs. None of it in my mind comes it has to do with their aptitude; it has to do with their work ethic. The students who put in the time and care so much about the product that they’re building and what they’re working on, they’re the ones that just –. In the iOS [inaudible 14:29] we have Mattt Thomspon, who’s really a good example of just the most prolific programmer in probably all of the industry, and he’s just accomplishing so much and just builds so many things. I don’t think it’s because Mattt has an aptitude for building lots of things; it’s really because Mattt Thompson is digging in and spending time building stuff while the rest of us are watching TV shows or browsing Twitter. It’s powerful when you dig down and write code, how much you’re able to learn about the code that you’re writing and how much you’re able to understand about the APIs. When I’m implementing something in an app, I spend a little bit of time researching and trying to understand how the API works and how my code’s going to look, but I don’t really understand until I’ve written those lines of code. That’s kind of [inaudible 15:18]. The aptitude is not nearly as important as digging down and actually putting the finishing [inaudible 15:25]. CHUCK: It’s interesting, because if you’ve read Malcolm Gladwell’s Outliers, he points this out, that there are some people that may have a natural aptitude or talent for the piano, but the ones that wind up going to the academies where “blah-blah-blah, you’re an awesome student” and you become well-known in your field and all that stuff – they’re the ones that put the hours into practice. The aptitude may lead you to learn about those things or to be interested in it in the first place, but the thing that's going to determine whether or not you’re a success is actually the rest of it where you go in and you practice every day and you do what you got to do in order to make it. ANDREW: And I think that’s become pretty popular. I think he talks about spending 10,000 hours on whatever it is you’re trying to master. Of course there’s been some criticism of that, that that number’s not really 10,000 hours and there’s not a hard number and whatever, but anyway, for the purposes of discussion, I’m kind of curious. This brings up something I wonder about, which is that I’ve been doing Objective-C development for getting close to 10 years now. I consider myself good at it, but I kind of feel like I only really got good at it after years and years of doing it. I sort of wonder, Joshua, what you think about this idea that you can actually learn to be a good developer in 12 weeks. Do you think that’s really true, or do you think you’re giving people a good foundation, and that there’s just some certain amount of time that they do have to put in beyond that to really be good? JOSHUA: This is my second most popular question. It’s actually my favorite to answer because if you know my backstory –. My backstory is I’m an econ major. I went to BYU, graduated in Economics, got a job as a financial analyst at Zions Bank where I worked for three years in the worst time of the market – it was 2008 when the market crashed. When I thought about getting in iOS development, I didn’t even decide to learn. I just said, “I want apps in the store” so I actually hired Indians to build the apps for me and paid them $2,000 for four apps, and they were awful, and they were crashing like crazy. And so the only way that I could really make money off of these apps was to actually go and figure out how to fix those bugs. Digging into the code was how I learned. Like you said, Andrew, it took years to really figure out what it took to build these apps out and to make them work. Even more than that, it took some time working in a dev shop with a senior engineer, reading the senior engineer’s code, and asking questions and getting answers about that before I became what I would consider proficient in the language. I told my students pretty consistently, “I wouldn’t expect you to walk away as senior engineer, obviously. You’re not going to be able to solve your own problems,” which is kind of – if I have to separate between what is a senior engineer and what is a junior engineer, I would say a senior engineer says, “This is my problem that I need to solve and I know how to do that” and the junior engineer says, “This is my problem. I don’t know how to solve it; I need to find someone that can help me figure out how to solve it.” And so I tell my students, “You might not know how to solve these problems; you might need guidance and help from other engineers.” I tell my students, “You’re going to want to find a job as a junior engineer in a dev shop where you can learn from smart guys that have been doing it for a while, and that’s how you really learn.” What we give them is the ability to figure out how this works. What we give them is the ability to not be scared away by Apple docs. Every student that comes in, they’ve done the same thing. They’ve spent hours and hours doing things like Ray Wenderlich tutorials. When they go to a Ray Wenderlich tutorial, they suss out the code and they try and figure out these little things that they can change and try to get whatever it is they want to build. We try and teach them a way that understands the fundamentals of it, understands how to look up APIs on your own and not be afraid of the actual code and the actual documentation. That’s what we give them, not “Hey, you’re going to be a senior developer.” That said, and this is a big deal, I have students that are making $15/hour. I tell them, every single one of my students – every single one of them – can get a job working for a contracting shop, that as a junior developer on a team with another senior developer, for $30-$35/hour right after graduating. They can get that job and they can learn and work under a senior developer, and that’s a big step up for a lot of these guys. I’m not saying you’re going to graduate and you’re going to be immediately doing $75/hour, but I have some students that graduated in the first cohort that are already charging close to that, because they spent their time working under a senior engineer for the last six months, and it’s really, really powerful. ALONDO: I just have one question about tools. I was just wondering if you find the development environment being an impediment at all, or if it’s just people had an easier time in comparison to some other development environments that you’ve worked with. JOSHUA: Okay, so this is the moment of truth for me, I’d actually like to hear from the three of you because this is the thing; I hear this all the time, “Xcode is not a powerful IDE or there are better ones out there.” The only other one I’ve ever used was Eclipse for Android development, which sucked monkey balls [chuckling]. CHUCK: Oh, come on! Tell us how you really feel! JOSHUA: No, it was the freaking worst experience of my life. I was “Please, put me back in Xcode.” The Ruby engineers that I work with, they all use Vim and just in terminal. So when you say –. CHUCK: Nooo. I’m an Emacs guy, sorry. JOSHUA: You’re an Emacs guys. Regardless, even Emacs’ in terminal, right? CHUCK: Don’t say it. Don’t say it. No, go ahead. Say it. JOSHUA: Is that better than Xcode? Are there autocomplete stuff in Emacs that's as powerful as the autocomplete in Xcode? This is a sincere question: what are the better IDEs out there? I just don’t know. And so I tell my students, “I never have a problem with IDE for my students because a) they don’t know any better and b) I think it’s the best, because I’ve never had experience with a better IDE. ALONDO: Well I can say from just my development experience, I completely agree with you in regards to Eclipse. It was one of the reasons why I stopped doing as much Android development as I was in the past. I am giving Android CDO a try now. I came into iOS development from Windows, and I was using Visual Studio, which I found to be a pretty good IDE, and I’d used some Borland IDEs before then. But I’d been quite pleased with Xcode; it’s come a long way, it’s a really good development environment. I do use AppCode for refactoring code just because it still has some features that are a bit better, but Xcode has closed that gap quite a big as well. So I’m in agreement as far as the quality of Xcode and for iOS development, I think it works just fine. ANDREW: I’m kind of in the same boat as you, Joshua. The main experience I’ve had with IDEs other than Xcode is the development tools for writing firmware for embedded controllers for microcontrollers, and those are uniformly terrible. I mean, they’re a joke. They’re so bad because the companies don’t really care, and if you’re writing for that microcontroller, you don’t have any choice. In terms of Emacs or Vim, I think that’s kind of silly. I mean, that's not an IDE, and you’re not going to sit a brand new programming student down in front of Vim  and say, “Here, you’re going to learn how to program and learn all these frameworks and this brand new language. Oh, and a program that works completely differently than any other computer program you’ve ever used in your life.” It’s just not feasible. So I’m kind of in agreement that, especially for somebody new, Xcode is really, really good and it’s just the kind of thing you need when you’re getting started doing programming. CHUCK: I’m going to jump in here as well. For my Ruby stuff and JavaScript stuff, I tend to opt for Emacs. And yes, it doesn’t have the autocomplete stuff that you like to have in normal IDEs, and it doesn’t have built-in refactorings and things, as far as those are useful. The flip side for me though is that I can move through a project very quickly with those, but we’re not talking about me as kind of a command line, power user person. If we’re talking about just teaching people, yeah, I opt for using – in Ruby, Komodo or RubyMine. Komodo does JavaScript as well, or WebStorm. RubyMine and WebStorm are both done by Jetbrains, who also does AppCode, and those are terrific IDEs. The issue that I generally have with IDEs is that they usually are very complicated programs. I usually only wind up using a handful of the features that are in them, so the autocomplete is nice; some of the code navigation stuff is nice; the way that you can visualize some of the classes and the interactions between the classes is nice. But sometimes when I’m working in code, I just need everything else to go away, or I needed to act in a particular way and it seems like I’m able to get that a little bit better with the text editors. For me, it really just comes down to how you work, but I haven’t seen anything in Xcode or AppCode or any of the other IDEs that really help or hinder you either way. As long as somebody’s there to guide you through and say, “You write the code in the h-file, and then in the m-file, and then when you compile it you run it in the – you build and run, and then if it builds properly then you can go and you can do your thing in the simulator.” You have somebody show you how to work a process through in there? I think that’s way more important than what tool you’re using, unless the tool is just not up to par. And I have to totally agree with you on the Android development tools. I haven’t met an IDE that I liked for building Android apps and I’ve only done a little bit of it, so there may be an IDE out there. Jetbrains – they have their Java IDE and maybe that works great for Android. But the one that they tell you to go install with the clips is awful. JOSHUA: You just reminded me that I do use PyCharm for Python development. I’ve forgotten about that. But even PyCharm, I don’t like it as much as I like Xcode, and maybe it’s because Xcode was my first IDE. The other thing, Alondo, is that these are students that have no idea what to look at. Xcode, what Chuck was just talking about, which is, Xcode’s ability to modify or click and see the command-click a method and then you can see it in the heterofile, or command-click a property and you can see where it was defined, and control-click or option-click – I don’t remember which it is now – a class, and now you can see the actual documentation. I tell my students, “Building apps for iOS is really powerful because there’s this bible of documentation where for JavaScript or Ruby there's no real bible of documentation like there is for all of the APIs – every single API available for iOS.” They can command-click or control-click, get into the documentation and read that, and Xcode is a powerful tool for a beginner, I think. CHUCK: Yeah, the documentation lookup is definitely handy, especially when you’re learning. The only issue I ever have with IDEs is that they do way more than I need them to most of the time, and it’s like, “Okay, where is that one thing that I need?” Sometimes it gets in my way, but other than that, if they’re well-designed, they work fine. And ultimately, like I said before, if you have somebody that can go in and show you how to do the work in Xcode, then Xcode’s the tool. As you gain more experience, then you can go and try out some of the other things. Otherwise, I don’t think it really matters, as long as the IDE is up to par if you’re using Xcode or AppCode or something else that will do the job and will perform nicely. JOSHUA: Let me ask another question. We teach, for example for networking, we spend two days on basic networking, then we have a number of days obviously where we do some networking code. But we talk about NSURLConnection and NSURLSession, and we also us AFNetworking. So here’s a question for you guys: do I teach the students AFNetworking mostly and just not even worry about them understanding what APIs are behind AFNetworking? Because we just assumed that now we’re moving to Alamofire and those kinds of things will always be available, and for that matter, how many engineers out there today know anything but AFNetworking for iOS networking code? Basically any project the students sit down on is going to be based and use AFNetworking. Do they need to understand NSURLConnection, NSURLSession in order to be competitive in the marketplace, in order to seem like a reasonable hire when people are interviewing them? ANDREW: I can only answer this with my personal biases completely intact, and so I’m stating that upfront. I think people who listen to the show regularly know that I’m biased against third party code, and AFNetworking is most definitely included in that. I think that, and also speaking personally in terms of Mixed In Key which is the only place I’ve ever had input in hiring, we wouldn’t hire somebody who couldn’t do networking without AFNetworking. There’s a practical reason for that, which is that we don’t use AFNetworking, and we don’t have any plans to start. The other reason is, just philosophically, there's sort of this important leap that somebody that’s learning should probably understand, which is that AFNetworking’s great and it’s really useful and it makes all these powerful or complicated things way easier. But on the other hand, it’s just some code somebody wrote. It’s not magic; it’s something that somebody wrote on top of existing APIs to extend them or to make them easier to use or whatever. And so I think it is important for them to understand those underpinnings, that those are there, that they could use them too. Maybe even further than that – which I’m not saying they would actually have to dive into this, but some understanding of the fact that even the Apple APIs are not magic. They’re code that somebody wrote and there are lower-level APIs under those. Actually in the case of networking in particular, you can access those if you want. You can drop all the way down and write POSIX networking code, so I personally think it’s important that people understand the lower-level APIs. Maybe they don’t spend a ton of time using them because there’s this argument to be made that it’s a waste of time, but they should know that they’re there; they should not be frightened of them. ALONDO: I’m going to have to agree to the extent that I definitely think that when you’re talking about building software in a company, you have to determine where your time is best spent, but it’s really important to really understand how things work. In fact, I had a really interesting conversation with an Apple engineer you probably all know specifically about AFNetworking versus using the native frameworks, and he was of the same opinion as you, Andrew. It’s just not that complicated, and that was an example of where it’s just not that complicated, that it’s an impediment to learning, and that you should know it and you should use it. That being said, there are some instance maybe some other third party libraries that are just not in the core of what your app does that your time is better spent focusing on the core functionality [inaudible 30:44] saves you that time and cost. I don’t draw a hard line in this saying, “No, we never use third party software.” CHUCK: I have to jump in here and slightly disagree. I think it’s helpful to understand underlying technology and why and how it works, but I really would have to go back to the purpose of this course. Is the DevMountain course to get them to the point where they can write their own apps, or is the DevMountain course there to teach them how all of it works? To a certain degree with beginners, I feel like you could get away with hand-waving some of this stuff, so you can actually put something out there and then just say, “Here’s how you do networking” and you teach them AFNetworking. And then they go ahead and they’ve learned how to do it with AFNetworking. As they gain experience and they can start to figure out, “Oh, this depends on NSURL.” Then they’re capable, functional programmers that can participate in the ecosystem and can do the programming and can get the work done, without necessarily having this deep understanding of how the system works. Eventually, they’re going to have to have it, right? But initially, just showing them “This is the process for doing this kind of thing,” I think that’s fine. I think you’re totally okay doing that. Now if you came in going for a mid-level or senior position, yeah, I wouldn’t hire you unless you understood: “This is what’s happening under the covers.” ANDREW: I think we’re actually in agreement, Chuck. You could get ridiculous, right? You’re not going to teach somebody, probably not going to teach somebody the Objective-C runtime at all. You’re certainly not going to teach them how Objective-C message send is implemented in assembly or whatever, even though that exists and somebody wrote it. If you want to, you can go see how that’s done. I just think there needs to be this idea implanted in their heads that these abstractions or these higher-level abstractions with third party code or whatever are just that. They’re higher-level abstractions or third party code or whatever are just that – they’re higher-level, they’re abstractions, there are underpinnings, and maybe they don’t need to know all the details, but they do need to know that those details exist and that they’re accessible to them. I don’t know how to put this, but they’re a place to look. That’s a possibility. If AFNetworking doesn’t do something they need to do, they do have this option of dropping down to a lower level. Or when they’re debugging, there is this depth that they need to realize it’s there, and it’s not off-limits to them. I deal with that every day, basically, especially when bad bugs come up I sometimes really have to dive into low-levels. I’m working on one today where I’ve got a linker error where something can’t be found in the C++ standard library on a certain version of OSX. I don’t know the solution but I know I can find the solution, so that’s sort of the logical leap that I think needs to be made in their head. ALONDO: Would you make the statement, for instance in this case, not to [inaudible 33:28] but because network connections are so ubiquitous in apps these days that that would be one exception to the general rule, saying, “We’re not going to do a deep dive in all of these things, but this is one particular case where there aren’t really any apps you’re going to be developing anymore that don’t need some sort of network capability. JOSHUA: So obviously, I bring this up because like I said, we spend two, three days just on RESTful service communication, and we use NSURLConnection, NSURLSession for the first day, and then the second day we do AFNetworking, and then from then on we use AFNetworking. I’ve had students and teachers say, “Why even teach NSURLSession? Why even teach NSURLConnection?” Can I tell you a funny story? CHUCK: Yeah, go ahead. ANDREW: No humor allowed. CHUCK: And no stories. Stories don’t work on podcasts. JOSHUA: [Chuckles] I spent my first two years of programming not even knowing AFNetworking existed. That was back even before NSURLSessions were created, so I was all NSURLConnections. I was applying for a job in San Francisco; they had me write some code. It was a timeline view with images that you would scroll through, and you’d have to load the images. When I first shipped it, I just shipped it with loading the image in every cell, which obviously was finicky, so I sat down and wrote my own queueing procedure for the images. I’d queued up all the images, then load them, then as it loaded then it would update the images in the cache, and then the cache would load the UIImageViews in the cells. As you get flipped through to TableView, and it was smooth as butter, right? So I submit this code to this application process, this company, and the first question they ask is, “Why didn’t you just use AFNetworking UIImage for this?” I looked at him and I was like, “What is that?” I didn’t want to admit that I didn’t know what it was. They both looked at me and they said, “Wait, you really don’t know what AFNetworking is?” This has been my experience over and over again with a lot of these libraries. I use some lower-level API, and then I find out that just scores and scores of developers are all using third party code. When I was working at the church, we started one of those little drawer views, just custom code it. At one point they said, “We should probably use a third party library for that.” I don’t know if you guys know what [inaudible 35:50] ViewController is, but that was – or viewDeckController, DeckViewController – whatever. ALONDO: Yes, I do know that. JOSHUA: Everybody was using it at the time and I had never even heard of it, and so this has been a consistent thing for me. Like Andrew, “Not written here” is kind of my mantra, but I think there’s a balance, and so we definitely have to figure out – especially as we’re teaching students as pragmatic as possible, “This is how you ship code. This is how you actually [inaudible 36:17].” The truth is, if they spend too much time in the theory of lower-level code that they’re not actually writing a lot of code; they’re not building things and they’re not making apps that can be submitted to the App Store, if they don’t get there, then we miss out. They miss out on a lot of learning opportunities. Even more than that – and this is what’s really interesting – Alondo says every app has networking in it. But what’s really interesting is not every app – and in fact I dare say, most apps – a great majority of apps do not have custom RESTful API to hit. They’re using Parse or Dropbox or CloudKit, or these other networking services that are completely abstracted away even from the networking code. Unless you’re working for a company that has a backend that you’re hitting, you’re likely going to be using an even further abstracted third party service to reach back into that [inaudible 37:08]. I say that in 30 capstone projects, only one of them have AFNetworking in it at all. Most of them just have Parse or Dropbox or some other type of backend service, if that makes sense. ALONDO: That’s a good point. CHUCK: Yeah, but a lot of those even are going to have libraries that wrap around NSURL. They just encapsulate the conventions for talking to that service. JOSHUA: Yeah, even more than that, they encapsulate the caching of the data, so Parse just barely released the actual local store of whatever it is that you’re fetching form the server. They don’t just wrap around the networking; they also wrap around the caching at the store and then the retrieving and the fetch results controller. I mean, they wrap around so much that I think if you have a Parse app, you could really protect yourself away from understanding anything in normal API parlance. CHUCK: I’m also curious. You said that a lot of your students, they go learn web and then they come learn mobile. I’m interested to know what things give them a leg up on and what things set them back on. JOSHUA: I should point this out too; I should've said this earlier. We are in the process – in February we’ll be starting an immersive course for iOS. Let me come back to your question and answer this right. The students that come from web – we have two web classes that we’ve been doing, one is after-hours and the other has been for the last three months, an immersive course – or six months. They can take a full-time web course, and what that means is that they come into iOS, which is after-hours, and they get their mentors for a few hours a week. They come from web where they’ve been working on this full-time and really dedicating from 9 to 5 every day. They’re with a mentor and they have instruction twice a day, and they’re coming from that into iOS after hours, which I think, for that reason, some of the web guys have taken it a little bit less seriously because they came from the immersive [inaudible 39:07] after hours. We actually are launching the immersive because we’ve seen so much good in the immersive for the web, but as far as programmatically, what I see – weaknesses and strengths – I think web students, they come in and they are unfazed by the fear of code. Really funny – in iOS, one [inaudible 39:29]. You have to keep your code in-between an opening and then closing bracket; you can’t just type anywhere and [inaudible 39:36] to run. New students, they don’t get that, and so the first day I’m spending my time walking around; I’d be like, “Place your code here.” They’ve got to [inaudible 39:46] or they’re like “What is this compiler here? What is this? It won’t even build. I read everywhere.” The web students come in with none of that. They understand opening and the closing bracket; they understand that spaces or periods can make a huge difference, or lack of a semi-colon is why it won’t build. And so the fear, “I didn’t do what it did on the teacher’s computer. I did it up on the screen, I did this, but on my computer it’s this. I’m screwed. Nothing’s going to work.” That’s how a new student is. Whereas a web student will say, “What’s different between my computer and the teacher’s computer?” and they’ll be able to process that, only because they’ve spent  the last 12 weeks going through that experience, and so they’re unfazed and not afraid of that. Like I said, as far as technically speaking, the web students are coming in, they have just learned Spanish and now they’re learning Japanese. The disadvantage for them is they’re burned out. You’ve spent 12 weeks learning Spanish; now you come in and I’m like “Okay, now it’s time to learn Japanese.” It seems like, “Oh, man.” By the ninth, tenth week, the web students would be like, “Jeez, I am not retaining anything anymore.” And they do, and they do really well. In fact, our best grads have come from both. But it is hard – it’s 24 weeks of school, like a full year of school, and it is just non-stop every day, just beating heavy stuff in your brain and practically building everything you possibly can, and it can be really hard for the students that come from web. CHUCK: Well we’re getting close to picks time, do you guys have any other questions for Joshua? ANDREW: I can’t think of any. CHUCK: Alright. Let’s go ahead and do the picks then. Alondo, do you have some picks for us? ALONDO: I have one pick this week, and it is an online course site called Udemy. It was recommended to me by one of the managers at my company for helping my nephews in school and just kind of learned topics. I’ve been testing it out this week and I’ve found it quite useful. Their courses range from free to some paid classes; typically they’re not that expensive. So far, so good though. It’s pretty simple to use and it’s a helpful site. CHUCK: Awesome. Andrew, do you have some picks for us? ANDREW: Yeah, I’ve got three picks. First one of these is going to seem a little weird because after the discussion we just had and the fact that everybody knows I’m sort of biased against third party code, but my pick is contributing to open source. Even though I say that, I actually have two libraries that I wrote that are open source that are sort of in the style of AFNetworking in that they wrap lower-level APIs and add powerful features and make them easier to use. Of course I use those myself; I wrote them, but I also hope other people use them and I especially hope people contribute to them Also, this weekend, I was playing around with Carthage, which is a dependency manager that came out recently that we’ve talked about recently on iPhreaks. I have started working on a contribution to that to fix some outstanding issues. Anyway, I just think that’s a great thing to get involved with, a good way to get to collaborate with other people, to learn new things from them. Carthage is all written in Swift, so it’s giving me some good Swift practice, and it’s really not as hard as you think. Find a project that you’re using, either if there’s something that you find that’s a deficiency, a bug or something you’d like to see improved, to create your own issue for it. Otherwise, look through the list of issues and see if there’s one that you can pick off that you can fix yourself and then submit a pull request. I think that's a great way to contribute and also learn. My next pick is one that may have been done before, but it’s Arduino. I’ve been playing around with Arduino; I’ve actually been working on a project with Josh where we’re using Arduino. Having done firmware and designing hardware with microcontrollers professionally, I’m quite impressed by Arduinos. This is basically a little microcontroller that you can program very easily; that’s really the whole point. You don’t have to have any experience with hardware or even programming before to get an Arduino, get it set up and start doing cool stuff with it really quickly. They’ve taken away a lot of the steep learning curve that is normally involved, and there’s just a huge community and ecosystem around them, so you can get all kinds of sample code and complete projects and all kinds of accessories – shields that do different things for them. It’s all open source – the hardware and software are open source, so it’s a really cool project. It’s gotten really popular in the last few years; it’s being used for all kinds of things. I really like it. If you’ve never done any hardware, I definitely recommend getting an Arduino and diving in. And sort of going along with that pick is Dash, which I think has probably been picked before, but this is a documentation browser for the Mac. It’s just a general purpose documentation browser and it has tons and tons of different documentation sets available for download, including Cocoa and Cocoa Touch API documentation, but it has the Arduino documentation as an available set, so I’ve been using that as I’ve been working on this project. Those are my picks. JOSHUA: Okay. I’m new to this. I got a couple as well, if that’s okay. I’ll do a really weird one, but I think if you’ve got listeners that care, then this is pretty cool. Home Depot has Cree LED Light Bulbs on sale really cheap right not, so you can get a 4Flow filament for only $2.99 – that’s a 60W light bulb. Or you can get a Soft White, which is 2700K – it’s a 60W equivalent – for $5.97. We were able to completely do all the LEDs in our whole house for 200 bucks. I know that sounds expensive, but it saves a lot of money in the long run and you feel good about life because they come with a ten-year warranty, so you can just get them replaced – for ten years [inaudible 45:16]. That’s my first pick. I know it’s a little bit weird. My second pick is a book that, as we started talking today, just keeps coming back to mind. It’s Traction – it’s a startup guide to getting customers by Gabriel Weinberg. He’s the CEO of DuckDuckGo. This book is on how different traction channels that you can use to build your customer base for your product. If you have an independent iOS app or if you have a book that you’re working on like a side project, these will be 19 different traction channels – I think it’s 13 – but they’ll help you find customers for your product. It’s super powerful; it’s really, really easy to read and I think it will do to marketing what the Lean Startup did to product development. Those are my picks. CHUCK: Very cool. We were talking before the show and I actually bought that book. My picks are, first off, I’ve been reading a book called becoming a Key Person of Influence. It basically talks through becoming, like it says, a key person of influence in your field, and it’s so far just been a very cool book to read, so I have to recommend that. The thing is, I usually listen to audiobooks. This one doesn’t have an audiobook, so I actually have been reading it on my Kindle and it’s awesome. It’s so good that I’m actually reading it. Anyway, I’m going to definitely pick that. I don’t know if I have any other picks, so I’m probably just going to leave it at that. Thanks for coming, Josh. JOSHUA: Thank you for having me. This is really cool; I love listening to you guys and it’s been fun to chat. ANDREW: Thanks, Joshua. ALONDO: Great, thanks a lot. CHUCK: If people want to get a hold of you or follow-up on what’s going on with you or DevMountain, what are the best ways for people to do that? JOSHUA: Always the best place for me is Twitter. It’s @jkhowland – H-O-W-L-A-N-D – on Twitter, and DevMountain is D-E-V-M-T-N @DevMtn on Twitter, and so those are those places. I’m working on a product, if it’s okay to pitch myself. CHUCK: Please [crosstalk 47:20]. JOSHUA: It’s a “Leave Me Alone” sign for developers that are working on stuff and they want people to stop bugging them. It’s just a little LED; Andrew’s working on the Bluetooth so that you can turn it on and off with a keystroke on your Mac. You could find out more at wearewired.in, and it’s just these little wired-in signs. I’m having a ton of fun with it, and hopefully it’s something that fits your listeners. If it is, then sign up for the mailing list, and then when we launch we’ll let you know about it. CHUCK: Ooh, I think I need one of those. JOSHUA: Yeah, I think they’ll be cool for independent developers, or podcast recorders, for example, you’d get an ON AIR sign. You’d put it up above your door so that your wife doesn’t open the door while you’re in the middle of recording. CHUCK: That’s exactly what I’m looking at, actually. Earlier – I’m trying to remember – I think it was this morning with Adventures in Angular, my three-year-old came in here crying because my five-year-old wasn’t being nice to him, and my wife had run over to her sister’s house for a few minutes. So yeah, it’d be nice to have that sign up that basically says, “Do not disturb or you will die” or something. JOSHUA: [Chuckles] Yeah. ANDREW: I actually have an ON AIR sign, one of our signs that says ON AIR, Chuck. I don’t have it outside my door yet. I need to do that. JOSHUA: You can do a custom text, so You Will Die is probably possible, actually. CHUCK: [Chuckles] Death To Intruders. Anyway, thanks for coming. We’ll wrap up the show and we’ll catch you all next week! [This episode is sponsored by MadGlory. You've been building software for a long time and sometimes it gets a little overwhelming. Work piles up, hiring sucks and it's hard to get projects out the door. Check out MadGlory. They're a small shop with experience shipping big products. They're smart, dedicated, will augment your team and work as hard as you do. Find them online at MadGlory.com or on Twitter @MadGlory.]**[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]**[Would you like to join a conversation with the iPhreaks 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 iphreaksshow.com/forum]**

Sign up for the Newsletter

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