 So, I, who's met me before? Alright, there's a few people. So, if you're used to like, cheery stuff and like, fun, goofy jokes and stuff, as you can see from the title, it's possible that it's gonna be a little less cheery than usual, which is why I'm dressed like this, which I would never impose on you ever again. So, it's kind of a serious topic, and it's the first time that I talk about something like this at a conference this big, you're in a room this wide, which is gonna be interesting. It's also the first time I tell this story, so, well, really this story didn't this way. So, if it's messy, it's normal, life is messy, death is also messy, so just like, roll with it if you can. And you can laugh at me if you want, you can cry with me if you want. It doesn't really matter. If you, I really recommend, since I probably forget, I will forget to say this after, I really recommend you going to see Ernie Miller's talk after this. It's a perfect sequel. It's gonna get a real, real, real, way more than my talk is gonna be. So, let's get started. Since I said that it would be a light-hearted talk, I'm gonna start with something very, you know, set the mood a little bit. We are all going to die, without exception. There you go. Yeah! Our websites are gonna 404. We're probably gonna tell our friends or we are going to try to see if our websites, our old websites are still alive somewhere in the way back machine, but probably a lot of the links are gonna be dead. So it's gonna be sad. This is what we do. We make things that disappear really quickly and we also disappear really quickly. This is me. Usually I'm more cheery and I talk about things that are a little bit more fun. I work for a company called Code School and I've been doing that for like the last six years now. And this company was acquired by Pluralsight in 2015 and we do a lot of the same things and we're basically trying to infuse Pluralsight with some of the things that made Code School special for so many years. So I'm gonna tell you the story of Code School or any app or any website or any startup or any company that you've been a part of. It's not really that special. It's just one of many stories and I'm gonna try to see if we can glean some useful knowledge and wisdom from the way that our little story happened. So back in late 2010 in Orlando, Florida a someone did this, which millions of people have done. Actually, to be realistic, it's probably more like this. The bottom part is just with wishful thinking but yeah, there's probably more like this. So it was my friend actually Andrew Smith who I went to school with who at the time worked for NV Labs in Florida and they had been working on this idea because they went to conferences and workshops and they had to organize a lot of Rails workshops and they had to do a lot of setup and it would be confusing and messy and people wouldn't be in sync and they wouldn't have the right dependencies installed and stuff was hard. So they decided, okay, let's do a thing called Rails for Zombies that'll make that easier where you don't have to do the setup. This was the first commit to turning Rails for Zombies into its own product something that other things can be taught on other things in Rails itself. So as usual, when you create a Rails app you spend a few days changing the defaults. You spend a few days installing the little things that you like like RSpec or Factory Girl or Factory Bot and Tappy Bar and all these things. Nothing special here. You do see some people kind of joining in the fun and starting to join the party and then it's just a few days in December. I think they even worked around the Christmas break because they were probably too excited to not do it. And this was the actual first commit on December 22nd, 2010. And the way I joined this story was a full year later in January 2012 after trying everything I could to get into this adventure because I could see there was something special about it. And I was in school at the time it started so I tried everything I could to join this adventure. And at the time it looked like this. So if you've been to code school, if you know code school, it was very texturing. There was lots of cool royalty free art that looks really fancy. And there was also a lot of little buttons and calls to action and share buttons and everything. And at the time we only taught a few things. I think jQuery error, Rails for Zombies 2, there's maybe four or five courses. So it was a tough sale to sell a subscription to that. And the first thing that I did was nitpicking. There was a button that wasn't clear enough for team subscriptions. That's the first thing I actually touched on that code base. That's all the way out. I think three days after I started working there. And I think I even put screenshots because I was trying to impress everyone in the commit message. And it cut to two years later, a little bit more comfortable and also clearly less worried about impressing people. This was not just self-deprecated. Actually it's something really stupid. So this is kind of like the range. So earlier I think DHH talked about barriers to entry in the community, in the programming world. One of the things we were really concerned about was to bring people in the Rails community because it just makes it more, there's so many advantages, so many good things that come from that. And that's what we were trying to fight. We were trying to circumvent at least. So if you remember from that time, Rails for Zombies was this thing that you just jumped on on a website. You didn't have to install Ruby or have to do any kind of dependency installation. And you could just start testing, playing with Ruby, playing with Rails, seeing how the interface worked, how the APIs function and how things in Rails worked in general. That didn't teach you everything, but it just got you started really quickly. And we also worked on revamping the Try Ruby website at the time, which was semi-abandoned and made it a little bit more compelling and added a few things to make it more responsive and also more secure. And that's basically the formula at the time, where it was the right time, browsers could do the things that we're doing and a lot of other companies kind of joined in the fun and tried to teach people that way. The content, which we spent inordinate amount of time building kind of like magicians, like you see them do this really easy trick and you think like, wow, how do you possibly do this? It's just way too much time, way too much time and money spent in doing that. And the audience, people like you, which is exactly why I think the success happened and the growth happened the way that it happened is because the people in the community were invested in our success and invested in learning from us with us. And that's how it worked. So it grew in a few months faster than I think some people anticipated, slower than others anticipated. And within a few months of me joining, we had revamped the website, we had added a ton of courses for JavaScript, for Node.js, for iOS, for so many other things like Git. And the development experience on the development side, so as the person who worked on the website, codeschool.com, was something that a lot of people are familiar with when they start out or when they do a pet project. They just worked on Heroku and pushed things and it was easy and it was fun. And I remember at the time how lovely everything was. It felt like you were going to the Japanese garden, selecting little things and not really noticing that we were tallying up $700 worth of monthly cost. It was actually fun to crank things up and you only noticed at the end of the month, oh wow, we probably don't need to have that many dinos for our courses when no one's watching. But sometimes we'd have spurts of activity or whenever we released a course, it was like this big exciting moment of like, ooh, people are excited, let's crank up the dinos, crank it to 11. And we started getting excited about building this thing because obviously we could see the people got excited. So we started adding gems here and there, people joined the team and they wanted to add a feature here, a feature there and just things started to just bloat a little bit. And aside from software dependencies, we started having human dependencies because the team grew, the people who depended on us teaching in their companies, the people who in schools were using our software in our courses to teach themselves started expanding and it wasn't just this little thing that we did ourselves, it was a time where we weren't quite responsible enough to have that on our shoulders and it took a little bit of time to get used to it. We started saying things like this, which happens in every slightly successful startup, why do, why pay Heroku for that much money? We could use that money and do it ourselves, it'd be fine, what could go wrong when you have 10 people on the team and no ops person full time. So that usually turned into this and it took us years and this is something that I hope resonates with other people. It took us years to get back to, maybe I'm exaggerating, the kind of developer experience that we had come to get accustomed to on Heroku because we obviously did not make the calculation correctly. So in economics there's this term opportunity cost, which is a vague definition. I don't really like it. It's the loss of potential gain from other alternatives when one alternative is chosen. So you have a bunch of paths and you pick one and what you lose are the others. This is the way that I think about it in my head. Maybe this is a random number, $5,000 a month you spent on Heroku, instead you're gonna think, well, we're gonna save some but then you forget to add payroll and vacation and security upgrades and framework upgrades and people quitting when they are the only ones who know how to do ops stuff on your team. So it amounts to a lot of stuff. So there's another thing that starts happening. When you see peers in the community or just successful companies around you, you start thinking, well, hmm, GitHub has their own support app. It's really cute and it's really custom and it's perfectly tailored to their needs and they've shown me a few screenshots and I want one and they won't just share it. So why wouldn't we make one? It's not like we have customers who are doing cycles and features and courses and all of these things to take care of anyway. So you start thinking, okay, we're special. So obviously the things that are made for general purpose, they're not quite special enough for us. We're a weird bunch of people and we need a weird bunch of software to cater to our needs and our customers but it's not true. You're not that special. That doesn't mean you're not special, you're just not that special. You have to deal with the same things everybody has to deal with. Users, authorizations, databases, emails, building servers, browsers, security, all of these things that we all have in common. All of these things that we build little tools to fix. All of these things we experiment with little Phoenix apps because we want to be on the bleeding edge or even node because we're insane and we end up with something like this. 103 Ruby repositories for a team that's never been bigger than 50 people ever. So that's more repositories than we've ever had people. And that's multiplied by all the things we have to do for all of these little tools that we built because we want it to be special. Of course, we were very tempted by this thing that David talked about this morning which was like, well, active records are not special enough for us. We have needs that are complicated. We have reporting needs or whatever. We have SQL data reports that we need to do and we are fighting this thing, but it's not worth it. We were trying to justify our difference by picking things that made us slightly different than the common case. Instead of just using what was built and just adapting it as much as we could without going aside from it on the side. So that's the same thing for these smaller frameworks that compete with Rails or at least try to provide an alternative with Rails. They're extremely good ground for experimentation for us and for many in the community and for many people creating new companies from scratch. They're great alternatives or even when they're building new segments or new products within their companies. The problem is that we start doing this thing where we put Rails on one side and Freedom on the other. We put easy on one side Rails and simple on the other or big and small or yes and maybe because maybe it'll work but we don't know and we have the certainty of Rails to back us up and that's probably what we should stick with especially when we're a small company with no investors trying to make something sustainable. What's nice about this opposition however is that you have a bunch of really interesting good ideas in the community just existing everywhere and then once in a while not as often as everybody would like the ideas percolate into Rails. So just like it's called Ruby on Rails you can picture it like this. Ruby is this broad wide wild west and some of the ideas sometimes when you zoom in there's this little cross-pollination point between the two edges of the community where that starts making sense when you're using these tools and you find them so productive, so good, so powerful or performant and you adopt them slowly but surely into things that merge into Rails and become parts of these frameworks that we know like Active Record for instance that's taken inspiration from other community tools that are just maybe more apt, maybe more precise tools but not quite as general purpose. The thing that I remember specifically I think it was around 2013 was conversations about architecture because you grow so fast when you have a little bit of success like this that you stop thinking, you don't have time to think about architecture until you realize oh crap we're in a corner we have to think about it so I think in 2010 the big conversations where where does my business logic go? Does it go in lib because that's where Ruby puts business logic or logic or does it go in app because that's where Rails puts it? So am I mixing Rails logic with my logic? Is Rails my application domain or is it not? But at the time we had this problem services was the thing. People were going crazy over SOA and there were articles every week about should I do this there was a little bit of you should convert you should try this because it'll be more sustainable for you and obviously as a company who is growing more mature we want it to be more responsible and sustainable. So at the time SOA to me was that. I didn't really know what it was. So I looked into it and at the time people who joined the team it's more senior people than me who joined the team decided okay we're gonna try this because it allows us to kind of like have the business activity wrapped into this service self-contained service that is a black box that is easier to test that allows us to have underlying services nested inside of it if necessary and it's a little bit more clean and well defined than at the time our Rails models were. The problem was that if we went full on with the service architecture at least distributed service architecture with microservices and all that stuff. We were trading local complexity which we knew with perpetual inconsistency so lots of work for a team that is not quite big enough to deal with all the networking problems so what we did was really simple. We didn't distribute it we just kept it local we just kept it all in one app one big model with and it was service oriented-ish but we had models and we had services which was kind of weird especially when you joined the team and we had a user create and a create user service basically which was also weird but it made sense because you could create a user and subscribe to the user and then charge that user's subscription for money and we made money and it was great and we were refactoring making a billing system integration at the time so everything was great until that happened. Someone needed to charge a subscription without having to do the other things and things started to break because there were entry points that we hadn't anticipated of course and really what happens is this tension between these services are basically proxies to these models as long as you're using Rails you'll have these models unless you turn off these methods which some people do so you end up with just a Rails with a mustache on top, a service mustache and you make those choices and eventually after you make those choices as we did go full in services you start thinking what if we just had embraced the callbacks and the concerns and not have too many concerns about them what if? Promise we never had time to actually go back and say let's change everything and that's when I think that's when the company and the team and the environment or the group of people that you work with starts to consider that the way we chose is not necessarily the absolute best way that we could have chosen there are some caveats we have to live with them I think that's when we reached a modicum of adulthood the experiment, this little fun little site project that we did at conferences became a product that people depended on so we had to take it seriously we had to take performance seriously we had to take reliability seriously and the we're not doctors excuse that a lot of startups use stopped being the thing that we could go to to justify doing things kind of haphazardly the other thing that happened around that time is that because we felt more responsible of our customers or responsible for we noticed that at least on the team that took care of code school.com there was a lot of instability there was a lot of people from the consultancy that were helping in people coming in from another team joining in and leaving because they were working on a course or something like that there's a lot of instability and also there was a lack of ownership because of that churn not necessarily because people left the company but because people moved around to be flexible and inside the company we didn't have enough ownership of the thing that we were building working on so not enough people knew the precise deep integrations or the APIs and how they were designed and their services and that's around the time where these two people came in on the, I gotta turn around to see it on the left is Katie on the right is Joel and this is when we decided to responsibly and purposefully build our team with people that we nurtured and took care of and grew with the team. Katie has a computer science background and Joel is more like me he's literally liberal arts major someone that I didn't think I would ever meet in a team like that and that collaboration of the computer science aspect and the liberal arts just thinking and naming especially the ability to name things properly was very useful so we had the computer person and the book person which is a simplicity, a simple example and in many ways not just through education but through background it started bringing a little bit of diversity which people have many definitions for many bullshit definitions many geographical or ethnic or gender based definitions or simply just perspective which is kind of like the corporate excuse for diversity what we had to do when the team started becoming more diverse, more interesting, more challenging to the way we had done things before was to define this kind of framework that when you join the team you have immunity at least for six months anything you say we won't do we won't attack you for it you can criticize our ways because obviously they're set in this little pool of people that we knew and that we grew with and so you should feel free to say things like why are you doing it this way this seems strange to me you don't have to be aggressive about it of course but you can tell us to our faces and we will show you by being vulnerable when we screw up which happens all the time especially in a small company that we will take your feedback and we will receive it and we won't punish you for it and when the company becomes more mature there was this thing that I remember clearly is people started to say things like well we have a process like oh well we have to attend this meeting because this is part of the process and people started justifying things that weren't pleasant, productive that didn't make sense because it was the process because they had been so loosey-goosey they wanted some structure to feel like we were a serious company we weren't messing around and things like Bibles basically edicts that just said this is the way we do things this is the way we operate this is the little steps we have to go through to deploy our software or make our things and that started but kind of like adding rigidity to this process and people started to not enjoy doing the thing that they were enjoying a few months prior as much this quote that's attributed to Mark Twain but I don't take it at all from Mark Twain which is during the gold rush it's a good time to be in the pick and shovel business and around that time we started noticing that we had a lot of shovels in the closet and everybody does too because obviously since the start of boom started happening a lot of companies are filling in the cracks and things that we have to do or that we could do better or they specialize in so there's this big big industry of shovel and service companies that offer you to use something instead of having to make it and it's a really hard conundrum for people who build software because obviously we could do it we could spend three months making mill chip but it would suck and nobody would use it and nobody would maintain it and this is exactly what happens with not invented gear and other problems like this is that we probably should use rather than make but we're makers so we have a bias towards making it's also a time around which we start worrying a lot more about scalability because of course more people are using us in different countries at different times we're sleeping sometimes often and they're not sleeping and the websites doing this and there's big spikes and we're not responding fast enough because we never considered that we had customers in this other side of the world that doesn't load videos as fast because we don't have CDNs and we have things like this and we feel shame and we start to look to the community for help for people like Nate Prokofic who's teaching us ways to be more performant or teaching us ways to think about things that we assumed work a certain way like web servers and provisioning and things like that so we start noticing that we get back to this idea that maybe actually Rails can spell it's possible except if you look at the browser timing so that's the problem except it's probably just more my problem than the problem of JavaScript and thankfully also Nate can solve those problems for you and other people like him can help you figure out all of these things but because we were building so fast and growing this is not something we had the time to focus on and eventually it starts to bite you and you spend way too much time looking at this graph so performance is hard work but really the thing that is even harder is people and one thing that we learned to do at the time and since then in the last two to three years was to devalue the code stop thinking of it as a thing that we have to protect and care for and never discard or anything like that and overvalue the people because the people own the code they own the product they make you successful and also they make the customers learn at least on our side so when I look at just the last what five years most of what I do is bulldoze code that's just I am not a developer I just delete lines of code and that's basically what I've done because of this exact same problem because we have too much old code and it's really impossible to keep it all together and of course whenever you reach a certain scale security starts becoming an issue especially things like who has access to what especially when they get fired and you don't have access to the things that you used to have access because you didn't think through it you didn't share the things because you're a scrappy startup and you're just sharing everything on a I think it was a little base and I was at 37 signals thing that you could write notes in all of our passwords were in that one file or seeing that one one then going oh my God oh no and then people like this start showing up they're fun they send you little emails like this this is the first email I managed to find from someone saying like as I said I have found several serious security vulnerabilities so I want to ask you if you make a team on Hackerone Hacker what is this I look it up uh oh what is that I didn't know what that was either just like SOA shame I see a little activity thing zoom in on it oh so Twitter just posted a vulnerability they had and just there's someone's name I don't really know who that is $1,200 they were paid for this little vulnerability I don't I don't know much about the vulnerability that seems like a good decent amount of money and also why are they sharing that I don't want to share that that's shameful and it turns out that Hackerone is part of a great little movement that started happening kind of like what GitHub did to programming and sharing your code is this idea of just sharing the bug bounty to the rest of the world so that researchers have reputation so they're not just this weird person who sends you weird emails with typos everywhere because they do and that you have some guidance for what to pay them based on the severity of the vulnerability that you're faced with and also that you attract white hats before the black hats come over which is not necessarily the case but at least some people tell you that you have holes in your software and you don't have to make these announcements to the rest of your customers whenever someone eventually finds out so this is the time at which you realize that just putting stuff over your ears and not looking at the vulnerabilities are not trying to think too hard about it because you're not a doctor or a hospital so nobody's gonna die yeah, but people's lives are connected to their credit cards and their email accounts and their accounts and all that stuff especially when you start dealing with our price customers and privacy, which has been in the news lately becomes an issue too because you have customers in Germany for instance who have very specific needs when it comes to data retention things like leaderboards on code school or things we had to add toggles for features to disable because it's illegal to compete in a work setting at least as far as we understood in Germany so we couldn't just show you how many points you had on a course unless we had some kind of provision for disabling it out the GDPR if you haven't heard about it you should really, really look it up now because you have a month and a half to deal with it is actually going to change the way you develop not just as an alarmist statement so PII is personally identifiable information so we, I say we even though I'm French but in the US people think of PII as your address, your credit card things that are sensitive it turns out that with GDPR the definition of personally identifiable information includes your computer's IP address now if we think about the computer's IP address and Rails if you look at how many people have downloaded Rails and how many people have downloaded Devise kind of get a sense for how many people are using Devise in Rails and that the Devise module called trackable by default tracks sign in count time stamps and IP addresses last IP address and current IP address so probably let's say like this many of you have IP addresses they're not supposed to have in your database if you're using Rails and Devise together and you can look through your schema you'll probably see it and realize oh yeah actually yes it is there as it is for us so are you GDPR compliant when you start becoming more mature as a company this is the kind of stuff that you worry about or you pay a lot of money for lawyers to worry about and freak out when you're not you don't know until you get fine and I just noticed a few months ago a few weeks ago people started talking about it on Reddit for the Rails subreddit and there was a lot of answers and most of the answers were like oh this is terrible we paid a lot of money and we don't know what to do or we hope we'll finish in time and if you check your email inbox you will see that a lot of companies especially the big ones right now are sending waves and waves of emails saying like oh my god oh my god yes we have GDPR you can take out your data and we'll turn it off if you won't please, sorry if you look through Devise's issue tracker sadly it doesn't seem like anybody's raised the issue so at that point you've had a lot of data for us it's data like user accounts and subscriptions and also code submissions is that private is your tri ruby submission from five years ago private data because you practice then you type code that you technically own is that private data I don't know probably not but also we're storing it not because we need to but because why not we might find it useful to teach better later but it's also data we store and is associated with you that's a problem where does that data go when it's over by over I mean your company dies or you get acquired or I don't know something else and this is the present time we're getting to right now so about four three years ago as I said earlier Pluralsight acquired code school and since then we've worked with them to basically integrate a lot of the things that made us interactive and compelling into the platform over there and during that three years even though we took our time and we were really not responsible and careful to do it right eventually this had to happen so on June 1st, 2018 in a month and a half code school.com is going to shut down for good that is sad that makes me sad I hate this word sunset sunset is just the worst word to use for something like this because the sun comes back after a sunset it's not dead it's not like you're telling someone oh we're taking Rowdy to the farm it's horrible we're not taking it to the farm we're killing it or it's dying so I even I got so just used to this term that I even made the feature flipper for the sunset on code school.com sunset and I hate I hate that I did that and I wanted to change it but it's too late so after you announce a sunset or turn off your subscriptions and things like that what happens is amazing for the first time as a startup you actually stop making money so you're an actual startup for the first time in six years it's not that fun actually and what happens is I think that the problem with the word sunset and the words you know aquee higher and things like that is that people stop being honest about really what happened it's like this is something that we worked on for six years together there's a lot of people who depend on it and when we're saying we are shutting down code school forever that's an honest statement we're not doing it to the wean we're doing it because it makes sense we're doing it because we've moved on to something else and we've adapted the things that we loved about it but it still hurts for the people that use it the people who built it for years and who for so many years define themselves as the people who made that thing and were appreciated by the community and their students for it so while the spirit lives on like I said and a lot of the interactive fun stuff that we did at code school are going to live on and it still hurts and it hurt for a long time and then now it's different because now it's public and it doesn't hurt the same way and now it's more acceptance that said we've never I don't think anyone I know has ever thought okay what will I do if the thing this thing I'm so excited about that I'm so devoted to dies or something happens or something I don't expect happens we don't really make a living will for the companies and projects and exciting things that we work on code school is 20% over 20% of my adult life actually my whole life so it's not like this little thing that just disappears and it took me a long time to just think okay well there's an after and there's great people and that's the thing that I think I want to focus on at the end of this is I don't want to be defined by the thing that I made that is a legacy app I don't want to have that only be my legacy I want it to be the people that I worked with the people that I influenced or touched or the students in Malaysia in the middle of the night while we were doing a free weekend on on a Saturday and I was in the night shift because I am terrible at sleeping who sent tweets with you know the weather outside in Malaysia to say hey we're doing this code school free weekend with you and it's just like wow I'll never meet that many people in my entire life and they're using this thing that I were making all together and learn and finding work from it finding meaning from it so I try to think back on the things that could have made this adventure better or just generally the things that we should do because it's about the people is if there's toxic people get them out of there don't wait because it's proper don't wait because it's professional because raising your voice is something that you're not you know defining yourself as someone who's angry get angry at people who are toxic get angry at people who mess with your team and the people that matter nurture the good people the people that join your team and the junior developers that so many people think that they can't you know they don't need to build a company these are the people who stick around these are the people who just have loyalty and will become the thing that you're building more than the people who just come in and swoop in and share ownership with them make them trust them give them the keys and just if they screw up help them out don't blame them for screwing up and the product and I don't mean the product as a as a thing that you sell I mean the product the result of the things that you did with the people get involved in the community that is part more that is around that product get involved with the people that you work with or the support team that supports your software get involved with them and see what they're actually doing in the front lines when they're talking to people who use your product accept mortality accept that there are good constraints around the things that you do you don't have enough time you don't have enough money you don't know how to build the thing these are good things these are not we keep trying to fight the idea that we're going to run out of money these are good constraints these are things that make you choose things more responsibly avoid wasting your time doing things that you might not need to do so accept it and then finally the ideas share them share the good things that are part of your team culture sometimes we get protective because we're afraid that if we share those things maybe we'll ruin it or maybe people will make fun of us because it's naive there's so many things that we did at good school or that we'd still do at good school they're naive we have a compliments app that just we send a little thing and a little dashboard which would show in the kitchen like a nice thing someone said about someone just because we wanted to foster that and it's just something that I think Katie Delphin did one day because she felt like she wanted to share the little note cards and she realized that she wanted to help other people do the same thing make it easier I think Terence Lee and Richard Schneemann started doing that a few years ago at RailsConf is giving people little cards to say thank you I appreciated what you did or I appreciate you just as you not for what you do necessarily focus on joy focus on those little moments I know that early on in the story of GoTo a lot of it was fear a lot of it was stressful but there's little moments of joy like when we finally released a course on July 4th and there was a huge success and we had tons of other things to do but we could focus on that joy for a little bit and learned by doing of course because that's our motto I think that's a thing that I mean I learned from code school ended up working at code school so this is something that's very clear to me as an advantage and as David said this morning those two things are connected just in time learning just even if this is Stack Overflow it's okay not to know everything it's okay to discover it as you go and if we can help others discover things as we go or help them get in the community that we've made it would be amazing thank you very much