 Okay, well, you'd think after five months of doing lectures and presentations, including keynote, I'd know how to hook up a laptop to an AV cable. So good morning, I think. Great to be here. Thank you very much to Ben and Shane and Cascadia for letting us come talk. As Ben said and introduced, my name's Matt Yoho. I was a constructor with Hungry Academy. We've got three of the grads, former Hungrys, on the panel with us. I'm just going to talk for a few minutes, briefly, like an overview of the structure of the program. I'm not going to go, hopefully not getting to go into too much detail about it, because we want this to be a Q&A session, we want this to be a discussion, and hopefully you guys will have a lot of questions, so I need to make sure that you have them when we come to the end of this part. Each of the people here will talk a little bit about their experiences and then we'll move into the discussion part. So Hungry Academy, what was Hungry Academy and how did it begin? Hungry Academy was an effort on the part of living social to hire engineers, basically, to acquire talent, but to do it in a way that was sort of non-traditional. The problem, as I understand it, was that it wasn't necessarily that they were having a hard time finding talented or skilled engineers per se, it was that they were having a hard time finding the people with the right mix of technical ability but also perspective and in particular, like an entrepreneurial bent, sort of, you know, startup Hungry mentality. And decided, sort of, how do we tackle this, well, one thing we can do if we can't find this number of people, if we can't find the people we're looking for, what if we grow them? What if we find interesting, engaging, passionate people from walks of life that may not include software and give them the essential tools they need to be a successful developer. So Chad Fowler, who's now the senior VP of engineering at Living Social, sort of originally came up with the idea. And as many of you probably know, Chad is a very prolific and effective teacher and instructor, you know, this is something he would have loved to have done himself, but of course his duties at Living Social sort of precluded that possibility. So he partnered with, got in touch with Jeff Kazimer who runs Jumpstart Lab as a sort of boots on the ground training partner to get the program running and to, you know, do the day-to-day operations. So between the combination of them, thus Hungry Academy as a program was born. I was then brought on as a secondary instructor. But I have experienced working over the last several years primarily for some of the, of Rails consultancies primarily that are known to be, you know, effective developers of Rails web applications and in the startup space and whatnot. And also have a, did my tenure, my tour of duty on the startup scene as well. So this was effectively, it's probably a little difficult to see, this is effectively the general weekly schedule that the group went through. This is kind of what we stuck to for the most part. At the outset basically we'd identified Chad and Jeff had worked together in consulting with the engineering teams inside Living Social as well, sort of came up with a high level rubric of, you know, where is the essential information that these people need to be taught and exposed to and learn and sort of, you know, mastered to some degree to be effective members of the team. And starting from that we kind of mapped out a curriculum. And you can see here that the breakdown, I know it's right in front of me so I'm not sure I'm turning around, but you can see the breakdown of the week that was split between instruction, lecture, like classroom instruction and project work. So Monday morning and afternoon were like lecture and lesson time. That might include some workshopping like, you know, working on particular lessons, code projects going out in the breakout sessions or things like that. It might be, you know, just straight like slides and lecture of content. Then Tuesdays were half days, so half, sorry, split, where the morning would be less than and the afternoon would be the start of project work. So there were always multiple things going on concurrently. These guys will probably talk about on any given week. So, you know, we'd be covering lecture material at the same time that they would have a project assigned. At the same time that there would be a reading assignment, at the same time they were preparing for their Friday morning lightning talks, which as we learned yesterday, all of that lightning talk preparation really paid off. And then Wednesdays are going to be split. Again, Thursdays would be project time. Projects varied. I think we went through something like six projects throughout the course, six or seven depending on how you look at it throughout the course of the program. Initial, there were some that were individual projects early on. There were pair-based projects and then quickly we got into team-based projects where there would be groups of four. Those projects varied from, you know, a week and a half to three weeks. Early on, it was focusing on Ruby and then quickly got into Rails and web applications. Things like basic online store, e-commerce sites, applications that had multi-tenancy support, we caused them to create a service-oriented architecture approach, various integration with third-party services, things like that. Here's a nice example. Trouder, for example. This was a project that came probably just before the midpoint or right around the midpoint. This, for example, was illustrating a real-time updating application. So this was, I can't remember if this was using Faye or Pusher, but a group that created this was using some sort of WebSockets-based technology to implement the application. So I want to talk a little bit about sort of the demographics of the people that were in the group. We started out, well, and how they got there. So there were 24 students in the program and that came, as Nicole discussed a little bit yesterday, it came out of a pool of around 700 or so applicants, over 100 of which, somewhere between 100 and 120, I believe, were brought in for onsite interviews, going through a round of interviews on the location with literally social engineers and other persons from other parts of the company, as well as with Jeff and myself. So that happened in three different sessions where we brought people in and went through logic exercises and things like that. We got down to 24 persons out of which about eight people had varying degrees of prior experience in programming, but of those probably only two or three had significant development experience. Some people had experience in QA. Some people had just graduated from school in a CS program. Some people, one person in particular, had not yet graduated from school. And then beyond that, then there were other persons from other fields like someone who came in, had been a quantae of analysts with a financial firm. One person had an architecture background. We also brought in people from, that already had worked for a living social, so folks who had been on the sales team or in the customer support team. We actually cannibalized the head of QA for a living social who joined the program. So I only talked about outcomes. So of those 24, all 24 persons were hired. And there was sort of a mixed review to that. A lot of people didn't expect that. And I've been asked the question afterward, did you really think, how surprised were you that all 24 people were hired? Or did you really think that would happen in a sort of a tone of maybe, well, if you hired all 24, then maybe you did something wrong. Perhaps the program wasn't hard enough, which is a reasonable temptation to think. But I think hopefully these folks will testify. It was pretty hard. I think that was a product of a rigorous selection process that was quite a good fortune. Someone, I was in a conversation with someone who was saying, well, really, toward the beginning of the program, I was in a conversation. And they said, really, people should wash out. That's how you know you're doing it, right? If it's so hard, the people just drop out. And that's an interesting viewpoint. But my response to that was, in the abstract, there's a certain appeal to that notion. But the reality is that these are 24 persons who have completely changed their lives. Most people, many, many of the people relocated to this city. They're real people, and they can't just treat this like a petri dish science experiment, right? It could be fun. It could be fun, yeah. But in practice, we sort of did. I mean, the reality is that regularly spending 14, 16 hour days, folks were sleeping in the space overnight. It was like the most hardcore of startup cultures that I've seen. And people pushed to breaking points. So I think my idea was, we don't want to push people past their breaking point. We wanted to push people to what they thought their breaking point was, and then just a little bit further. And I think we came dangerous and close to stepping over that line of points. But in the end, they all worked out. So I'm quite happy with that. Some lessons that we did learn. You can talk more about these later. But I think in practice, we started early on with individual projects. And then we went to a pair project. And then we jumped immediately to teams of four. And we stuck with that until the next to last project, where we went back to an individual project, where we realized we needed to be able to get more insight into on individual level how the group is doing, how the individuals are doing. And because it came down to, OK, well, we need to start deciding on these people are going to be on teams, and if so, which won't. And in retrospect, I think it's clear that it would have been much more appropriate to alternate, to kind of switch back and forth between group projects and individual projects, to get more insight earlier and to provide more opportunity for individualized, both intervention and recognition. Also, we had two instructors, Jeff and myself. And I genuinely believe we did the best job we could. But we probably could have used another hand. We both wish there was more time for things like individual pair programming and assessments and just continual feedback. Those are things that we did, but we would have loved to have done much more. So with that said, I'm going to stop talking at you and let these folks talk to themselves along these lines. And then we'll move on to the Q&A portion. My name's Mark Tabler. Before I came to Hungry Academy, I was a technical trainer and a double extra junior Rails-ish developer. I wrote code, but it was not awesome code. I guess you could kind of call me a paid hobbyist at that point. I came to Hungry Academy in the hopes of knocking the junior and all of the baggage off the front of that title. I wanted to become the best developer that I knew how to become and to kind of earn a spot among the world class developers that I knew that I wanted to be moving in their circles. And in that respect, Hungry Academy really, I think, kind of delivered for me. I don't feel like I'm an experienced amateur at this point. I feel like I'm a new pro. It feels like moving from the minor leagues to the majors. I still have a lot to learn, of course. I don't think that's ever going to change, but I feel like I'm in a place where I can do that now. And it was funny seeing that schedule listed on the overhead because the schedule seemed to stop at like five in the afternoon, which did not match my experience. I also didn't see Saturday or Sunday on that list, so a very short schedule on that overhead. One of my most memorable experiences was when we were doing our first four-person Rails project. What we had done is earlier in Parers, we had written a store system where a merchant could list items for sale and a customer could come along and buy them. The whole thing would go through order fulfillment and hit some sort of a credit card processing scheme, like the whole works. And our first four-person project was to take an existing code base of that store, refactor it into a multi-tenancy system, and set it up so that merchants are also a flavor of customer. And customers can shop from multiple stores and everything like this. Again, that's project number one for a person Rails team. So we sunk a lot of hours into that. And the night before it was due, or I guess I should say the morning before it was due, my team was still holed up in one section of the academy, like two o'clock in the morning, three o'clock in the morning. We've blown past our code freeze by hours now. And I said, forget it. I need to go get a soda or something. I'll be right back. If there's anybody else around, I'll see if they have any ideas. And I come out of that room, and all six teams are represented somewhere in Hungry Academy. I don't want to say everybody was still there three o'clock that morning, but every team was still there, still working on this, because we had something to get turned in and delivered, and none of us were done yet. And I thought that was really kind of a testament to the spirit of what we were doing there. None of us had any place better to be than Hungry Academy finishing this project three in the morning. And the last thing I want to touch on in terms of how I know that Hungry Academy worked for me is that it was a couple of months ago I had completely lost track of time, so I can't get more specific than that. But I was sitting down, starting up a Rails application. I have a user, and I have this other object, and a user has many objects. And it suddenly dawned on me what the has many method is actually doing under the hood, because it's just a method. It's not magic. It's not weird. It's not anything unusual. It's just a method that's defining a couple of other methods under the hood. And I couldn't have put it any better than this, so I'm going to borrow a phrase. It was when I realized that it's dogs at computers all the way down. Oh, somebody else wrote this Rails thing, and they didn't do anything that doesn't exist in Ruby. It's something we can all do. And just that knowledge that runs that deep into what's going on behind the scenes, that is one of the biggest differences between pre-Hungry Academy me and post-Hungry Academy me. And next up, for me, I'm going to try and remember what this whole free time thing is. I heard something about it. Don't remember. Life, that's kind of weird too, so I'm going to figure that out again. And as soon as I've got that settled, then coffee script. Hello, I'm Chris. Oh, I can hear myself. Before Hungry Academy, I was at school in, upstate New York. I was at Hamilton College, liberal arts school, pretty chill, lots of bros. And I was a philosophy major at the time, and so I was really interested in technology, but I didn't know really anything about it. I'd worked at a startup last summer, but I didn't have any coding knowledge, so I wasn't coding, obviously. So I don't know. I saw this on Hacker News and thought it was something that I was really interested in learning. And so I dropped out and came here, and it was cool. So yeah, I don't know. Memorable experience is actually, it's funny that you mentioned the code freeze. Tablear and I are about as opposite on that end of this factor. A memorable moment for me was, so we would present our projects after we were finished. And naturally, I was pushing straight to master 15 minutes before our project was due. And I remember bringing down just our whole server. And being our first time we had built a server, it was just a nightmare in there. And our whole team was just freaking out, probably a little bit distressed. So I just told them, I was like, oh yeah, it works. And I showed them a copy of it on my local host that was working. And they were like, OK, cool. And they chilled out. And then I just kept pushing to master until it worked. And so that was it. Yeah, so I think the best thing that I learned in this that I had no idea was going to learn was working with teams. Chad would tell us this all the time, that people are really hard. Coding, I don't know, it's pretty. The problems are pretty easy. And the solutions we can do, but it's like that dealing with teams, dealing with people stuff. That's really hard. So that was something that I didn't even have the expectation of learning. But once I got there, it was very natural. I'd taken a few computer science classes in just stupid things, like recursive, linked list sorting. And it was weird that it was always individual. Like you were always doing stuff by yourself. Like there was no source control. There was no testing. You were just kind of like derping around in C++ and like hoping something would happen. And it just seemed like this is just so obviously the wrong way to do things. And it was really cool to get out of the program that I guess software engineers have this. People think of us as like loners. Like we just sit in basements and just kind of like hack away. And I don't have a basement, but I do do that anyway. But it's like it's such a team activity. Like there is just like such a community here is something I've learned in my first Ruby conference. But what Mark was saying, late at night, you had people who Mark's wife was still in Portland. Like my girlfriend was in New York. Elise hates DC. And Bookus did too. We had to take care of Bookus. We didn't even know. He wasn't even on Hungary County. But like coming together and like supporting that team and being their family and being there every hour of the day for them was something that was just, it was incredible and didn't even expect that to come out of it. Hey guys. I'm Elise and I'm actually from Seattle. So it's really very nice to be back here. I did actually hate DC. That wasn't a lie. That's fair. So my background is in marketing and business development. So that kind of puts me on one way far into the spectrum of non-technical. Eli, please stop. OK, I've got a front row heckler. So one end of the spectrum of non-technical background. What really drew me to the Hungary Academy program is having been in the Rails community for the previous year and a half prior to the program. I've gotten to work with really cool companies like Peep Code and Jumpstart Lab, Code Climate as a consultant. And I realized what a fantastic community this was and I just really wanted to be more involved than on the periphery. So when the Hungary Academy program came up, it was a no-brainer to apply. The nice thing about it was I loved my job before. I wasn't scared to stay in my career as a marketing person, but I thought it would just be another opportunity, another path. And so when I found out I got in, it was difficult to leave my previous life behind, but also just really exciting to be more active in a community that I really love. So my hopes for the program, I was learning Rails for fun in my free time and I really, really sucked. I think the people at Seattle RB know my trials and tribulations through learning Rails with very mixed results and it's really, really hard to be a novice surrounded by experts. The learning curve is very, very steep. And though I did make progress, we blew through what I had learned in a year in like a day or two at Hungary Academy. So that pace was much quicker. So I hope that I could just try and learn Rails. So I think the most memorable experience for me was for our peer project, another Hungary Academy person named Andy Glass and I had worked together on our first Rails project, which was a store, a basic store. And both of us were in the very, very novice section. And it was a really difficult project, but we ended up in the top three groups. And yeah, it was really cool to prove that we could actually put out a functioning project without any previous experience. So other people who had been doing programming for four or five years, our product stood up to that. And that feels pretty cool. So I also fall in a very different category than Mark and perhaps Chris in terms of how I approached my time in Hungary Academy. I didn't like the hardcore startup 16-hour day. I didn't think it was, and I didn't think I worked productively that way. I didn't think that anyone worked productively that way. And I think there was a lot of pressure to stay those long hours. And so I think this was actually a great lesson in learning how to moderate a group dynamic and be OK with not fitting into that group. So that probably was one of the most challenging things for me is to say, sorry, this is actually good enough. We don't need to do that. I'm going home. And some of my teams appreciated that, and some people did not appreciate that. But that is simply how I worked. It also, so Ryan's talk yesterday was really awesome. I even had a dream about writing a nasty letter to someone that was mentioned. But I think it also brings up that everyone can be an asshole. Everyone can be a little crazy. And I think that I worked with a couple of people that I just didn't get along with. And as Chris mentioned, a lot of this was about working with teams and just figuring out how to deal with that. So recognizing bad behavior and correcting it was a huge part. So what now? They let me leave DC. Thank goodness. And I'm moving to Portland tomorrow. And I'm really excited to be joining the Merchant team. But being in the Northwest with all of these rubies that I love, so thanks. Great. So now we thought we'd take some time and answer some questions. Ryan Davis has one. Charlie, or where's the mic? Oh, Shane's got it. Nice. So my question might be moot. So I just want to start with does living social plan repeating this experience? So yes, so that's interesting. So planning at living social is always an exciting thing. So they had planned that another one would start in September was the original goal. We'll just do them back to back. And that was ridiculous. There is no way to do that. And part of the reason is you make a huge investment in these people. And the people at the end of the day, the product of this was the people. And to decide whether or not somebody is successful at the end, you can check off all of the skills. And there are all those things that we do. But they're also, as Nicole mentioned yesterday, in recruiting technical people, it's very hard because of that team aspect. And do they fit? Will they produce value in the future? So the real test, and Chadda said this to us, is yes, you made it that far. And this is awesome that we've graduated. But the next six months determine whether or not this was even a good idea and whether or not it is something that is worthwhile to do again. I think a lot of people, everyone involved knows it was a success. But it's also hard to say, we just paid these 24 people to do this. And we bought a floor of a building. And now we're going to do it again. And they're like, did the first one work? Are they cool? And we're like, well, I don't know. But we're going to do it again. So yeah, I think the testament of that is how well do we integrate with teams? How well do we produce? How well do we fit with the culture and actually show that we were worth it? Yeah, there's a lot of. This just ended a week ago, which someone said that to me, like, oh, how are you doing? I was thinking it's been like two weeks. But as Mark mentioned, our sense of time is completely shot. But yeah, there's going to be a process of, wow, what worked and what didn't work. There are many things in the macro level we know didn't work or that did, and we need to refine. But it's going to take some time to actually decompress and look at the outcome. OK, so assuming you guys do this again, I fairly agree with Lisa's assessment that 16-hour days, especially when you're learning all this stuff, is complete bullshit. There's a lot of diminishing gains. And you just start dropping off in your effectiveness and what you're retaining and everything else. And you're just grinding and becoming the asshole that you're trying not to be. So what do you guys recommend to the program itself to try to address that so that you can maximize the amount of learning and maximize the amount of effectiveness without the grind and the death march? Can I just before, I would like to say that I, throughout the 16-hour day thing, is sort of to say these people have been working really hard. This has not been easy for anyone. And that was a reality. And I would like to see that be different. And I want to hear, as we all want to hear what you guys have to say about that. But it was not necessarily explicitly the mandate. It wasn't necessarily that there wasn't a requirement. The 16-hour days are being put in. And it's not sustainable. It is not sustainable. I agree. Sure. I think actually, midway through the program, it was said, please don't work as hard. I think it had a lot to do with, like, self-selection for people that were very, very motivated, wanted to win, very competitive. And that just kind of fostered a culture of very intense work. I think definitely more could be done in a future class to say, sorry, hard stop at 6 p.m. Go home. No more computer touching if we see commets after, like, that's not OK, or something like that. But I think it had a lot to do with the culture that just emerged rather than any explicit mandate. I think I can agree with that, too. I mean, I know that I put in myself a ridiculous number of hours in Hungry Academy, but much of that was my own choice. As was alluded to earlier, I went to DC from Portland. And due to a number of reasons, my wife had to stay behind in Portland. And so I was kind of on my own in DC, renting the cheapest, funkiest basement apartment I could find. And my philosophy was that for five months, I don't have anything on my plate except Hungry Academy. And so I personally felt like if I wasn't doing something productive, that that was a moment in time that I wasn't going to get back. I'm not ever going to have a second Hungry Academy for myself. And so I don't want to deliver the idea that I just worked until I was cross-eyed and spent four hours beating my head against one line of code. But by the same token, I worked absolutely as much as I was able to. And if I wasn't writing code, I was reading a book. I was getting ready for a lightning talk. I was reviewing P-casts or something. I was always doing something until I needed to rest. And then I did. And so my days were very long, mostly by choice, and mostly out of kind of a nod to the nature of the program. If all I have is five months to learn what I'm going to learn out of Hungry Academy, what do I do with each of those days? I think we could have been more focused with a message. There was sort of a message set at the outset of what Mark is going to say here. Yeah, you've got a finite amount of time here. Maximize that. Like treat this. Yes, the sort of pace that we're going to be moving at is not sustainable at the long scale. And five months is too long for it. But there's sort of the idea that it is a finite amount of time. And you are free to put whatever amount of your time into it that you want. But what became a problem and where we failed to intercede or do the right thing or what have you was stepping in where we realized that there were sort of group dynamic and cultural forces at work that were sort of putting pressure on people to go beyond what they were comfortable with, go beyond what was good for them. We needed to figure out a way to step in. And it was tricky because there were multiple sort of interests and messages and cultural touchstones being injected into the thing. It was tough. I've been saying to people for the last couple of weeks before the end, you should be aware that you're going to join these teams and you're going to feel like you're not doing enough work. You're going to feel like you're going to be fired because you're not staying until 9 PM every night. That's not going to be the way it is. It's OK. Are we not doing that? We don't do that. Yeah, it turns out, yeah, you can go home for that. Yeah, I think it's important to note that it was very, like, that drive was very self-selecting. It's hard. Like, you put 24 people who are going to drop their life to come do something like this. Like, that's really hard because we will drive each other off a cliff if not watched carefully. And there weren't. Yeah, there were definitely times where we worked and we were up. And the only thing we did was ending up. Like, we would just make our code worse. And so that was really hard. Also, a very good, probably not on purpose, learning experience for stop doing this. You're wasting your time. You're wasting your team's time. And you're just, like, hurting everything because you want to go off there and just, like, be a superhero at 5 in the morning. So yeah, I think, yeah, it's hard to control for that kind of stuff. But we also learned in a very real way why you don't do that. At least I did. More questions? Brian, right here. On the website, it says the breakdown is 40% project work and 30% classroom. And then 30% community. Can you elaborate more on the intent of the community, 30% what was included in that work? And if that 30% of community actually happened. Yeah. I think those numbers were projections. And I'm not sure where that, all I know is that doesn't reflect reality. I'm not sure what the actual percentages would have been. We didn't ultimately kind of sit out in that way. But do you guys want to talk about some of the community? Sure. One of the things that we tried really hard to do was spend Fridays doing open source work and open source projects rather than whatever classroom tasks had been assigned. And I think that was more challenging than we anticipated because on the one hand, if we can write a working store system or a working multi-tenant store system, then surely our code can be used in some open source project, right? But there's so much more to it that goes into contributing to open source. There's community. There's understanding why something works the way it does. It turns out that not every pet feature belongs in every gem that you come across. It's surprising, I know. But so a lot of the community time that we spent trying to get that done wound up being learning how to operate in a community. And I don't think there was as much external result from that as we were originally hoping. But the education was definitely there, I think. Yeah. That was hard. Coming into it, you're like, oh, I want to contribute to open source. I can write code. This is cool. But that's just part of it, finding meaningful areas where you can contribute. Yeah, we worked really hard on a number of really cool projects. I mean, Dan, I think, got a commit merge into Ruby Core, which was pretty baller. That was early on, too. He's too smart. And yeah, we had, I don't know, we had a lot of, towards the end, it was a lot easier because in the beginning we were fighting ourselves to learn. But we had a lot of people, open source gems that they had built towards the end for a lot of API services that weren't well-documented or weren't built before. But again, the program would differentiate it against just learning yourself was that you weren't just supposed to be a programmer at the end of it. You weren't just supposed to be able to write code. You should also be comfortable with the open source community. No projects, no people who are contributing to the future of the language and the community, which was a lot more important than I think people realized going in. And that is a very valuable part of being a Ruby developer and not just a programmer. Sorry. Oh, yeah. So I only got to publish one of them. But for me, my pet desire for contributions to open source is helping beginners. I think a lot of the beginner tutorials cover only the very basics, but don't clear that gap between just having fun and becoming a developer. So I published a blog post on how to basically make API calls with, like, HDT party and just in a very, very simple format. And best of intentions wanted to do more. But once I started getting better, I realized, oh, gosh, I don't know this. I won't publish this yet. Oh, gosh, I don't know this. I won't publish this yet. And I think I need to clear that confidence hurdle just to be like, screw it. The people that need to know this this much don't know that I don't know that part. I think also in the community stuff. So probably because everyone, like the students were so busy working on their own projects, their own code, it was hard to contribute things like open source code. It was hard to contribute blog articles. But somehow they managed to contribute or things like time. So community was also like local community or there were folks who volunteered on several instances for Rails Hotline. There's a program in DC, a local program called Code Now that is targeted at exposing kids from underprivileged school districts, like exposing them to programming and going through a multi-session intro and teaching them Ruby and things like that. And lots of students volunteered their Saturdays and Sundays somehow to do multiple sessions of that. But Jeff and myself were volunteered for that as well and were running sessions. The last project of the session that everyone did was creating projects for an organization called DonorsChoose.org, which is a very awesome organization. The CEO of that company, Charles Best, came and spoke to the group beforehand. And everyone sort of contributed projects to augment or help out with DonorsChoose. Which if you haven't heard of it, it's a platform for enabling teachers and classrooms to kind of propose, you know, to get projects funded. So I would like to take my students to the art museum and we need this much money to make it happen. I need basic supplies for this project in my classroom. Could you donate? So it helped out with that. And the other aspect in that early projection going back to those numbers, the intention was to basically open source or make all of the learning materials and the lessons publicly available. And in effect, they are. But we changed modes so frequently throughout the program. Like they're not really, like some of them are highly consumable and useful. But it still will take a significant effort to go back through and sort of normalize everything and really publish it. But that was one of the early intentions that in practice, like we were all moving so fast and so busy that we didn't follow through in the way we might have liked to on that. But hopefully we will in the future. So next? I have a request that we've gotten through two questions. So I would like answers to be shorter. Sure. OK. So Jessie has a question. Very good. Hi. So down in Portland at ELC, they're starting an internship program. It's going to be pretty small for people. 12 weeks kind of thing. So from the participants, what would you pass on to people entering a program in terms of just advice? Like if you had one quick thing to pick, what would be your advice to them? Don't be scared. Everything that's out there that got written got written by a developer who started where you are. Keep practicing the basics. What you think you know when you do it, you actually probably don't know. So every time you revisit it, you'll know it better. So just keep iterating through even the simple things. I would say ask questions, but try it first. Like the thing that helping people, the best people that you really want to help are ones who have tried it, tried it really quickly, and invested their own time in it and clearly want to learn. If you show that you want to learn, I think this community especially is there to help you and is so excited to help you learn. And just show that you have that initiative and go for it. From a time and team perspective, from a technical perspective, I guess, it sounds like it was a huge success, but the main challenge that I'm hearing is the time and team sort of soft skills. I guess Matt, particularly, would you consider adding more of the time and team stuff to the program next time around? I don't think it was imbalanced at all. The technical was also very, very challenging. I think that the amount of work that went into the team building and the time management was more surprising, but I think that the balance was about right. So it's not a question of more or less, but just being aware that that is part of being a well-rounded developer. In effect, there was a lot of people realizing through the course of the program that software is relatively easy and people are relatively difficult. We certainly put a lot of effort into. In fact, we opened up, in the first week, we brought in Jesse Sternstrasz, who's a lovely person whose name I always butcher, the improv effect. We brought it in to basically do a day and a half or so of workshopping with the whole group that looks like these improv exercises around communication and all of us did them. And I think that really broke down barriers quickly and we sort of got off to a good start because of that. So we did put a lot of focus on teams and we talked about it in lots of discussion. It's just, if you work on a team, you probably know that that can be really hard frequently. So we will continue to emphasize it, but I don't know of any particular new tactics we would take outside of my head. If you have a question, so I have an idea. Let's spread this out a little bit better. Okay, let's make them quick. So how did you evaluate progress and how competitive was that? Was there a feedback out of that one? Yeah, so we received points for things. Those were completely made up and were never actually counted. No one knows what the points meant, but yeah, I mean, we did at the end of every project, we did presentations and we would kind of people in the audience, both living social engineers, non-engineers and like each other, we would evaluate our projects and it was generally pretty clear. Like you knew what you weren't great at and you would just work on it the next time. The evaluation evolves throughout the program and that's one thing, we're going back again for another session, we'll definitely have that refined. We learned a lot on that. We, over time, we moved toward, we did more code reviews. So one of the goals of the program was to produce people with developer skill and an entrepreneurial perspective. So ship viable products, right? So that was half of the emphasis. So it was on things like this, project review. Oh, is this a compelling product? How is the user experience? And the other half was code review and that, and grading or ranking or whatever, was roughly 50-50 as far as points, as Max refers to, but ultimately like the winners came down, like, you know, winners and whatever that, for whatever that meant was really about selection. Like, oh, it was what you delivered compelling. But we also did actually look at the code and that was with myself and Jeff and then engineers from living social teams and gave feedback. I wish we had captured that feedback in a more concrete manner, a more durable manner, but we did interactive code review sessions. Questions? 300 applicants, only four women. What gives? Well, it was actually closer to 700 applicants. Slightly combative phrasing there, but... As Nicole mentioned yesterday, that kind of reflected the demographic of the pool of applicants, so the ratio in the pool of applicants as well. And that was a failure. We learned a lot about how to disseminate the information, how to get this information to, hey, this is something you could and should apply to, to get that in other channels, so to get that for a more even and better represented demographic, right? Yeah, I don't read hacker news. The only reason I knew about it was from Jeff Kazmir. So I think definitely a concerted effort in getting to where women are who might be interested in it would be very crucial. Yeah, I certainly would love to have seen a larger ratio of women in the program. And what was the ratio of female applicants? I don't have access. I never saw that exact data, but it was my understanding is it was roughly corresponded to the ratio in the final group. I'm getting the thumbs up from Nicole, but that's accurate. The interview rates were also about the same. Speaking of interview, we have a question about that. What do you think set you apart during your interview process? We had to make videos to, like part of the interview process was initially, do you mean the interview at Living Social or beforehand? Okay. So part of our interview was completing a logic puzzle and I came in at the very beginning of the day. I had taken a red eye to Washington DC. I was totally sleep deprived. Like my hair was all crazy. And that was my first experience through the different interview panels. And I really bombed it. Like I messed up one requirement completely, but having talked to the person that interviewed me later, he said the way that I set up the project or set up the problem, talked through it with him, was actually what made me stand out. Not, because that's just an error. Clerical error, not a fundamental error. So I think just slowly walking through the problem made me stand out. As a person who administered many of those logic problems, I tried to present it as though this was something we were gonna pair on, right? And that correctness or even completeness wasn't like the crucial criterion. It was how are we gonna work on this together? Can you illustrate to me your thought process and how you're approaching the problem, how you might set it up in a way that I can follow and let's assume that I need your help, right? And so it was about the communication and collaboration process. How is the give and take of information? How do you respond to suggestion? And you were really hopeless in that. I had him, he interviewed me. He was no help at all. I had no clue how to solve the problem, that's true. Do we have any questions over here? In the second? I was just asking, as anything you mentioned before, like in sort of coming into a room full of experts as a newbie, so how, how as a community can we do better helping out with new developers? What can we do to sort of help bridge that gap? Yeah, that's really hard. Because I think the Seattle R.R.B. crew was extremely helpful when I needed help. What? No, ask for help. When I asked for help, yeah, I would usually beat my head against a wall for like, actually, Ryan trained me really well on this. It sounds really weird, but I would, when I first started, I would fumble around with a problem for many hours and then it got cut down to 30 minutes so I couldn't figure out something in 30 minutes that I went and asked for help. And I employed that technique in Hungry Academy and I think I was far more efficient in solving problems. So yeah, I think just being available and not letting, not allowing people to struggle. I think the first six months that I was learning, I was doing IRB Ruby stuff, but I could not figure out how to set up my development environment. It was absolutely impossible. And so just that first step, once that hurdle had been cleared, and I think people helped me with that, but I'm not even sure I could do it now. So just that first step and then just continued checking in. I work with RailsBridge here. I don't know if Renee is here, but we started Seattle RailsBridge and I think that first touch is great, but after the first weekend, a lot of people drop off and don't continue their learning and I think mentorship and just checking in and being there supportive is crucial. And that development environment, seriously, is a nightmare. I just upgraded to Mount Lion and now I'm getting these C compiler issues. I don't even know. I can't do low commits, it's a nightmare. And so yeah, so I was actually, a friend of mine asked me while I was in the program, like I wanna learn Ruby, what can I do? And that step of getting, explaining what the terminal is, installing Homebrew, installing RVM, installing that to somebody who doesn't know what any of these things are, you're just throwing words at them and they're just like, I don't know. RailsBridge.org. Oh. Except it's already on the Mac. One of the things that I would really suggest that we keep in mind as a community is the opposite of this problem. As a novice, I come into a room full of experts and I think that everybody there knows something that I don't and that's not always true. By the flip side of this coin, as experienced developers, you know something that new people would need to know. Don't be afraid to mentor. You can do a lot more help than I think is immediately obvious when you think about it. Did you guys feel like as the teachers, you know there's a couple different areas of teaching people how to code aside from the communication side, there's like the frameworks and the tools, there's the patterns and the practices and then there's like writing readable code, writing maintainable code. Did you feel like five months was enough time to address, especially the readable maintainable code because that's ultimately the success of your scalability of your product. Do you feel like you're able to address that in five months? I think that that was one of the big successes of the program and one of the wins from working in four person groups because if I have written something in my project that my fellow coders can't understand, then I've done it wrong. It doesn't belong in the master branch and that feedback is very immediate and because it gets dropped right back onto my plate to fix and make readable, then yeah, it definitely became a noticeable issue when it wasn't there. I think we emphasized readable code and short methods and good naming from step one basically and honestly I don't know if, you know, how much credit I can really claim but honestly that was my biggest, maybe the most pleased or what I probably regard as a real indicator of success was that I mean by the time we were halfway through the program to the end, like I'd be looking through and reviewing projects and the code was uniformly like very readable. There'd be exceptions here and there we could talk about them and you could have discussions with the people in the group and they would understand like yeah, yeah, I know that's bad, we're aware of it, we just, we had to get that done. But yeah, the code, if you were to go back through and look at the repos and they're pretty much all, I mean they're all public, you know, you could. The readability of the code was very, very high and I think that was just a result of like continual emphasis from the beginning in different ways, you know. We talked a lot about sort of the fractal notion of development and code and patterns and so yeah. We got time for maybe two more. Andy here. I was curious about the criteria for success that you guys planned at the beginning of the program and then like how that ended up at the end and whether, I guess from living in social side, whether it seems like it was a success based on those beginning criteria and whether those changed throughout the program. So the criteria for success of the program at the macro scale or success like was any individual successful going through it? I think, well, the criteria for success, the macro scale of the program was just, is the return on the investment of the, are a significant percentage of these people actually going to join the teams, be like welcomed into the teams. Yes, please, we need you and you're gonna do great. Like that was it, like in absolute terms. And then conversely, that was the metric of success. I think ultimately for the individuals was, are you going to be welcomed onto the team? Are you going to be brought in? I was wondering about if test-driven development and TDD and BDD writing your test first and that sort of stuff, how that factored into the academy or if it did? It did. Well, we actually, so we wound up, we talked about tests continually and I think we honestly, we introduced it, that was one point where we clearly made a mistake was that we introduced rails and testing rails at roughly the same time and it immediately became obvious and could have been obvious beforehand was you can't TDD something you don't know how to do, right? Like that's sort of a fundamental thing. So if you're gonna expect to test drive or really even significantly test a Rails app and you don't really know what the heck a Rails app is, that's not a recipe for success. But we did continually emphasize like yes, tests and when doing code reviews and we basically had rubric and criterion that included like, are you writing tests? Are you writing tests at the right level? Like is your test coverage and makes sense? Do you have integration as well as unit tests? And we circled back to it once or twice later in the program after we had more perspective under their belt about, okay, let's, like one day we went through, let's look at a full like outside and like BDD style approach and go through, went through a cycle of that together. I think also the, so each project got incrementally more difficult and added on new things. At the end, my last project was just a single page JavaScript application and testing that. So I think, you know, we really, like Matt said, we pushed the boundary of what we knew how to do so significantly that it was hard. What was nice is for my individual project, I went back and just did a service oriented Rails app that was actually phenomenally easy to test because I was just testing the API that I built. So that was awesome to know that I knew how to test drive. Yeah, I think it was very important, it was made clear that it was very important, especially Matt had stern words for me a number of times about like, again, like that end goal played in about working on a team, like does somebody wanna work on a team with you? So like for my individual project, I hit a point where I was like three days out and I was like, well, I could do all these really cool features and Matt knows I love the new hotness, but like it made sense for me to just stop adding code and just test and just learn how to do that really well and like know that not so the things between like teams and individual, like individual, I can push up to GitHub and I just push to master and it's all magical land and I don't have to write tests and whatever because I wrote all the code. But like working with a team, if you want your team to understand what is going on and like so that they don't break whatever I wrote and vice versa, I mean, that was very clearly an objective of ours to write code that is maintainable because that, you know, a living social we have a lot of developers and you're gonna have to do that. You're gonna have to perform. If you don't like, they will just reject your commits and that will be sad times. So very excited. I just wanna say you guys are awesome. I'm very much a Ruby newbie and I definitely understand your perspective. This is like my first ever Ruby conference and I wanted to ask, as kind of like coming from outside of computer science without any formal training, I think one of the scary things with being in a room full of experts is that they know stuff about like theory. Do you guys feel like you're well equipped now after five months to not need to know theory and still be useful or how do you approach like getting into really complex computer science stuff? It totally, it really depends on what you're doing. So one of our first, our first talk of somebody that Kevin did talk to us was Evan Phoenix who is just like, it was like week three. We were like, a ray is like, what are those? And he comes in and he drops this talk about like threads in Rubinius. We're just like, what are you talking about? And it was crazy. I still don't know what he was talking about. But he looked great doing it, dreaming. So yeah, so the theory parts, like if you were to be like, Chris, like go write things in Postgres and like do all that. Like that stuff I probably couldn't do, like insight, like the internal stuff or some of the compiler stuff that was talked about earlier with Ruby Motion. That's up. I mean, there is a lot more theory involved. Web development, especially like consumer facing stuff. It's like, does it work? And that like our judgment, it was interesting the way that projects were judged. You would first judge them on all these like technical aspects and all that stuff. And then it was basically like, you can have something that is so beautiful and it is like NP complete. I'm just gonna throw out buzzwords. Whatever. And like, you can have all these features, whatever. But like, if it doesn't work, if the tests don't pass, if people can't understand what the hell you wrote, like the theory is somewhat meaningless, but there are parts, the parts where the theory really does matter. I mean, that's not the stuff that we focus on, I guess. I think we also took a very product-focused approach, which was fantastic. Just thinking about what our users would find useful and going through making user stories going that direction. I think learning is just a continual process and the more we write, the more we'll understand the patterns behind it. I think the big thing I came away with is that when somebody throws a big technical complex concept at me, I'm no longer really afraid to say, I have no idea what you just said to me, but it sounds great. Tell me more. And so that just knowing what I don't know and knowing that it's okay, I happen to know how to write Rails applications. I don't happen to be great at big O notation, but I know enough to kind of smile a nod if you're gonna bring it up. So it's just, like I said earlier, you're losing that fear and being unafraid to talk about what you don't know because everybody who does know these concepts started somewhere. Yeah. I think we also learned a lot of the theory stuff, like in practice. So like we talked about big O maybe the last week or the second to last week and it was like we looked at all the graphs and there's like exponential and like lines and like that was cool, but like by that point we had realized don't nest six loops, like that's not gonna work. Don't join your entire database every table together and then like start doing things. Like that was stuff that in practice we had taken a look at performance and so theory like that. So we have like a very like grassroots understanding of all this stuff. Again, the buzzwords I'm not good at, but I'll look them up. All right, so we are unfortunately out of time, but thank you for your questions and thanks to Matt Yoho, Mark Tabler, Chris Maddox and Elise Worthy.