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.  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.  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.  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.  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.  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.  There's a lot of diminishing gains. And you just start dropping off in your effectiveness and what you're retaining and everything else.  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.  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.  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.  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.  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.


Tonight's big game brought to you by U.S. Army Europe and AFN. Sir, isn't it great that we get to call the big game this year? What a great year it's been so far. These teams have really overcome some challenges to get here. You know, the soldiers of U.S. Army Europe are the same. Always pushing to be the best at what they do. I know many of the Usur team are watching the game now with their friends and family. I want all of our team members to enjoy the game to be safe. Strong soldiers, sir. We'll see you next week.


Asos wants to be the number one fashion destination for 20-somethings around the world. We don't have shops, people know about Asos from the internet. We have one minute where that digital platform is out, we're not serving our customers. Because Asos offers such a wide variety of products, 87,000 at any one time with 5,000 new ones added each week, we've invested heavily in their recommendations platform we need to help our 18 million active customers discover the things they love. We really like Cosmos DB as a fully managed database service. Cosmos DB is used as the model store, the gateway from the offline to the online data science worlds. It allows us to distribute the data models to be near the services wherever in the world they're deployed. We like the immediate elasticity so we can store data models of any size. We like the very low latency for random reads. During peak sales periods, we need extra compute power to cope with customer demand and manage our large data sets. On Black Friday 2017, Asos services backed by SQL Azure and Azure Cosmos DB processed 750,000 orders. The product API served more than a billion requests over Black Friday through Cyber Monday, bursting up to five and a half thousand requests a second with an average response time of 39 milliseconds. We had literally no problem throughout the entire weekend. Azure has delivered as a rock solid platform to create an ever more compelling consumer experience.


Hey guys, how you doing? So this is my top 10 stocks for March 2022. And my 10th pick is Facebook. I think Facebook's taken a huge hit here. You can clearly see that in the last five years, the lowest they've been is around $123. So this is despite the fact that they've really grown, they've grown their revenues. And I believe that this is oversold. I think that we are now oversold on Facebook. You always need to mark the low, low over the last five years. So you could see it could go a little lower. There's a little bit of a gap to fill. But I think there's also a very good chance it could go a lot higher. So you could see the high point here, $383, not too long ago last summer. And it's just trended down like really aggressively from $385 all the way down to under $200 with this focus now on changing their name to metaverse. So they've lost a huge amount of the market cap. I do believe the metaverse is going to be big. But the question is how much more of the market cap will Facebook lose? So I'm not saying this can't go lower. It was just at $190. We can go back to the last month and see it hit this zone here right around $191. So clearly it could go lower. It was just at $191, not too long ago, last week. So this would be a great entry for me if you can get under $200 for Facebook. It's a quality company, tons of money in the bank trading right now about 13 times revenue and earnings. So I feel like it is undervalued, underappreciated, underexposed, could definitely go lower. But I also feel like there's a huge gap to fill. Just in the last year, you can see here huge, huge, huge gap to fill. If it goes back to those levels of $380, you're almost doubling your money on Facebook. So too good to pass up, too good of a quality company, too much money in the bank, too big of a database of customers and advertisers utilizing Facebook. That's why they're my number 10 pick for March 2022. Now, if we go and we continue on here and we continue on to our number nine pick, and I think it's important right now to look safe and look into safety and look into banks. So I've never talked about JP Morgan on the show. I really like JP Morgan. You can see this is the one-year chart and you can see we're right around the bottom, right around the bottom of the one-year chart. So very bullish on this. I love buying stocks at 52-week lows. You can see the 52-week high is around 172. It's right now at 141. I think there's a huge gap to fill here. This is a quality bank, quality company, one of the bigger banks, and they've just announced that they're getting into crypto. Look at the dividend, 2.7%. So you've got a 2.7% dividend. They've just announced they got into crypto and they're around a 52-week low. That's the trifecta for me. That's my number nine pick for March 2022. And number eight, another bank, another one I've never talked about on the show, but I really like Goldman Sachs. Been a big fan of Goldman Sachs for a long time. You can see that they're really close to this 52-week low, right around like the 320 mark. I guess it's been a little lower, let's say 318. At the beginning of last year and March of last year, almost a year to the day, you can see was at 319 right now. It's at 339. But I like to look at the high high here, 425. So it hit a high high of 425. It just recently hit 324 just last week, which would have been a decent entry. And I believe this is a good quality company. Once again, a quality dividend, 2.2% dividend. You're dealing with one of the largest banks in America and a huge gap to fill to go back to 52-week highs, closer to 52-week lows. So in my opinion, safe pick, safe stock, quality company, company that I'd like to buy, I'd like to own. I remember talking about and thinking about Goldman Sachs years ago when we're on YouTube and it was at $100. And now it's at 339 and I still think there's some upside. So they're my number eight pick for March 2022 and another their dividend pick in number seven. So I really think there's a lot of volatility in this market right now. And during times of volatility, you want to look at the volatility trade. So this is the VIX, VIXY Pro Shares Trust VIX Short Term Futures ETF. So if the market goes down and we're having a lot of volatility right now where there's a lot of downward pressure, the VIXY is a very good trade. I've also given you UVXY, which has done well. I've also given you the VIX, which has done well. And you can see here, it's come down a lot because the market's been hot for the most part over the last couple of years. Really, since the last crisis, it's been hot. So in knowing that, you have to think that there could be a trend reversal. So the trend was hot and this came down, but it's come back up from these lower levels. And you can see that now it's starting to bounce off this $14 mark. So when I do these videos, it's not to tell you to buy it today. It's just to put on your radar, put on your watch list. It's up 6%. So I wouldn't be buying this today. But if you could see a dip back down to that $14 mark, that seems like a decent entry. $14 or $15 seems like a decent entry in my opinion. That's where I'd be looking to enter into this trade. And this would be a short-term trade. I wouldn't be holding this. I don't believe the market's going down long term. I believe the market will always go up long term because historically that's all it's ever done. So I'm always going to believe that that's going to be the trend long term. But short-term, very good chance that we could see more volatility. We are having a war right now in the Ukraine with Russia invading the Ukraine. That's affecting a lot of the markets and we're getting a lot of volatility. So VIXY is a volatility trade. It's a way to hedge the markets. If the markets go down, VIXY is a way to play the markets. If they go down, you can buy this stock and make money. If the markets go down, this stock goes up. So VIXY my number seven pick for March 2022. Now in number six, I really like this company. I like them a lot when I started doing YouTube Twitter. When I started doing YouTube and in 2017, Twitter was one of my top picks. I remember it went down to $13. You can see here their five-year chart. So it's gone up and down a lot. Been very volatile. Did extremely well under the Trump time as President in America, but has struggled since. And I think it's a quality company. I use Twitter every day. I think it's one of the best ways for anyone to just share ideas in short form in an easy format. I think Twitter will continue to be a part of the fabric of social media and it will always be a part of the fabric of social media. I think it's come down a little too much. I think it's a decent entry point. There's a huge gap to fill here for it to go back to its highs where it hit just last year at $81. And I feel like it's starting to come near a bottom here around that $30 mark. So if you can get Twitter around $30 or lower, I really think that's going to be a good entry point to a quality company that I think has a lot of potential. And I think if they start doing share buybacks, we could see Twitter really explode. If they start getting involved more crypto, which I believe they will, we could see them explode further. I think there's a huge gap to fill for Twitter and I really like Twitter. That's why they're my number six pick for March 2022. Now you can see the theme here. All of these picks are quality companies. We're really not interested in anything that is not a quality company in this marketplace. There's a lot of volatility in the market. There's a lot of really good companies trading lower than I believe they should. Another one of those is PayPal. Love PayPal. You can see PayPal hit $300 twice last year. And I believe in the future it goes back to those levels. And PayPal really hitched their way into Bitcoin and Bitcoin's come down. And you know, PayPal's come down with it and that's okay. I think that's a buying opportunity. You could see it just hit $95 last week. I think that would be a great entry point. If you can get PayPal at $100 or less, I really believe there's a huge gap to fill here. I think in the future this will once again be a $300 stock. I don't know if it happens this year, but I think in the future we will see a $300 stock again for PayPal. I really like PayPal. I think they will continue to be a leader in innovation and payments. They're also very heavily involved in crypto and in Bitcoin. And I love that. And I love cryptos and I love Bitcoin and I love PayPal. So I believe, and I'm a holder of Bitcoin and a lot of top exposure to Bitcoin and cryptos, I think that PayPal, when Bitcoin makes a move, follows it up. And I think we see PayPal back to $200 or $300 in the future, which means you could make 100% to 200% on PayPal. So really good quality company, not saying it can't go lower. Anything can happen in the market, but I believe it's undervalued, underappreciated, underexposed. And if you can get into PayPal under 100, I mean, I think it's a huge winner. I'm not owning them right now, but if I do own them, I'll definitely let you guys know in the future. And our club members and our trading club always know first, especially VIP members, every single trade I make, every buy I do, every sell I do in stocks and cryptocurrencies. Next on my list, Uber. I like Uber a lot. I'm a big fan of Uber. Been a big fan of Uber. I use Uber Eats. I use their cars, their car service. So I think Uber needs to be on everybody's radar, on everybody's watch list. I think it's a quality company that is undervalued, underappreciated, underexposed. I think that this is just a buying opportunity for a really good quality company. I really do. You can see the lowest they've ever been is $13. Obviously, that would be a gift. But in the last, let's say year, so go to the one year, you could see the lowest they've been was just last week. It hit $29. So that was a great entry, in my opinion. And you can see the high they've been in a year is $62. So I always look at growing companies and I look at the high, high and the low, low. And I think the high, high, the previous high, high is where it's going again. I believe this will be a future $60 plus. I think it's a quality company. I've traded this before. I won my last trade on Uber. I fully intend to get into Uber again. Just waiting for the market to settle. But I really like these prices and lower for Uber. If you can get in at 35 or lower, I think you're going to make money on Uber. Quality company, Uber Eats allows them to, I think, just explode on a global scale. And then Uber as well, I think is also going to continue to help them explode on a global scale with their driving service. So I really believe in Uber, they're my number four pick for March 2022. And I think these prices are lower. Our quality, quality entries for a quality company. Now, number three, this is one I've never talked about before, but another quality company, I'm looking for as many quality companies as possible that I can give to you guys, especially in volatile times in the market. And right now with us dealing with a war right now in the Ukraine and Russia invasion of Ukraine. I really think eBay is a quality company. Another company with a dividend, my number three pick for March 2022 dividend of 1.6%. You can see it just hit a low here for the year. Love identifying quality companies and buying them at 52 week lows. I really think that's the best way to trade. If you're trying to build a portfolio, you want to invest in quality companies that have resources, money in the bank, and have dividends so that while you're waiting for them to grow and expand and explode, you're getting paid to hold that stock. That's really been one of my modus operandis as I grow and evolve and develop my trading strategy, my trading plan as an investor. And as I continue to grow, I'm looking for more quality companies. And I think this is the year of the $50 stocks. And I think that this is one of them, eBay that I think can make us a lot of money. You can see here, it's been as high as $80. So not too long ago, just a couple of months ago, and it's come down from $80 in October of last year to this, I think gift price of $53.82 right now, it did hit last week, a low of $49. So I think if you can get in at $49 in that range, you're doing great. Once again, quality company, paying a dividend, and you can't go wrong with dividend stocks because those are companies that have cash flow. That's why they're paying a dividend. Those are the best, biggest quality richest companies in the world. So get invested in some dividends in your portfolio, especially in times of volatility. And right now we are going through major volatility to start 2022, especially because of everything that's happening on a global scale. Now let's take a look at our number two pick, which I absolutely love. And I've loved them since day one. They've always been one of my favorite picks. And they've been one of the top stocks in America for the last couple years. And that's drumroll, Tesla. I think Tesla is undervalued at these levels, not that they're undervalued based on their revenue, but undervalued based on the potential for Tesla. You're talking about the number one electric vehicle company in the world. They had a nice dip just last week, hit $700. I was screaming the buy on Tesla in our trading group, and it's bounced. It's bounced very aggressively. You can see it's been as high as just about $1,250, and it came all the way down to the $700 mark, and it's come all the way back already to $856. I just think Tesla's a quality company. They got one of the richest men in the world and Elon Musk at the helm. And I just feel like they've got a lot of tricks up their sleeves. So I think this is a quality company. Buy them on dips. I think if you can get into Tesla at $800 or less, if you could have got in at $700, that was an amazing entry for Tesla because I believe they will go back to $1,200, $1,300 range. So I feel like there's a huge gap to fill here for Tesla. There's money to be made with Tesla. They've got tons of drivers of their cars. They're going to continue to be the leader, the global leader in electric vehicles. I don't see anybody coming close. And I just feel like they are the number one electric vehicle company in the world. So when you think about that and the whole world is going electric and everybody wants to be electric by 2030, I just feel like Tesla will always be in the news. They'll always be in the headlines. And they've gone down with the price of Bitcoin. And with the price of Bitcoin going up, Tesla's going up. So Tesla's up 5% today. Bitcoin's having a nice day today. So you've got to understand that Bitcoin's going to make moves right now. Bitcoin's at $41,600. So if you believe in Bitcoin like I do, and you can see that Bitcoin has exploded over time from under a penny in 2009 to now $41,600. And Tesla goes up and down with Bitcoin because Tesla owns Bitcoin. It actually owns physical Bitcoin. So Tesla's going up and down with Bitcoin. I feel like Tesla's a quality company that has a great future and we can make a lot of money on Tesla. That's why they're my number two pick for March 2022. I wouldn't buy them in the green. Always wait for dips, wait for red days, wouldn't chase them in the green. But if you can get them at $800 or lower or even $700 or lower, I think that's a buy for Tesla. And you can clearly see it's up today, 6%. Now at $858, so investors are buying the dip. In number one, I have to put the number one, not because of today, but just because of what I think they're going to do. And I just feel like this is a quality company that is extremely undervalued, underappreciated, underexposed, virgin galactic holdings. You can see here, it's been as high as $57. And you can see for the last five years, it's had these runs where it's been as high as $60. And it's done it multiple times. So they've obviously dealt with some issues. That's why the price has come all the way down. I just feel like this is the lowest it's ever been. It did hit a low of $7. If we can get back in at $7, I see a huge multiple here. Huge, huge, huge multiple. And their flights have been stalled right now. But when they get back to their space exploration, I think you're going to see it explode again. And there's going to be huge multiple to be made. That's why they're my number one pick for March 2022, virgin galactic holdings. And I just feel like they're extremely undervalued, underappreciated, underexposed. I do not have a position. I am hunting a position. I'd like to get it under $10. But if I can get it under $8, then I will be screaming by at least a thousand shares at $8. And yeah, but that would be my entry really. If I can get it at $8 or less, even at $7, I would be a proud owner of at least a thousand shares. So I think that this goes to $20 in the future, maybe as high as $50 again, which it's been multiple times. So if it goes to 20 from here, it's a double. If it goes to 30, you're making 200%. If it goes to 40, you're making 300%. If it goes to 50, you're making 400%. And it hit 50 twice last year. It actually hit 60. So huge upside potential for virgin galactic holdings. I don't know if it's going to happen in March. I just feel like it's going to happen in the future. And if and when it does, you're going to get a chance to win big. Thank you for watching. If you like our top 10, smash the like button, comment down below, share the video everywhere and subscribe if you're alive. If you're not winning, you're probably not watching. We're bringing the winners and we bring them to first. Now I must remind you that Rich TV Live is strictly for information and education purposes. Please do your due diligence, do your research before you invest in anything we talk about or discuss here on Rich TV Live. In saying that, we do love to bring you winners and we love to bring them to you first. I really like our top 10. I think this is a quality top 10. I think that these picks are going to make you money. And I also believe that these are quality picks. So thank you guys for watching our top 10 picks for March 2022. And if you'd like to learn how to trade, you can join our trading club at richpicksdaily.com where we have all of our picks right here. You can see here our top picks for the last couple of years, all public on richpicksdaily.com, 265 picks with an average peak profit of 350%. Thank you guys for watching. This is your boy Rich from Rich TV Live and I'm out.