00:00:11.240
So, who has met me before? There's a few people here. If you're expecting cheery stuff and fun, goofy jokes, as you can see from the title, it's possible that this talk is going to be a little less light-hearted than usual. This is also why I'm dressed like this; I would never impose this on you ever again.
00:00:29.070
This is a serious topic, and it's the first time I'm discussing something like this at a conference this big, with a room this wide, which is going to be interesting. It's also the first time I’m telling this story in this way, so if it's a bit messy, that's normal; life is messy, and death is also messy.
00:00:41.399
So just roll with it if you can. You can laugh at me if you want, you can cry with me if you want; it doesn't really matter. I really recommend you to go see Ernie Miller's talk after this; it’s a perfect sequel and it's going to be much more upbeat than mine. So, let’s get started.
00:01:08.159
Since I indicated that it would be a light-hearted talk, I'm going to start by saying something a little heavier: we are all going to die, without exception. There you go.
00:01:29.250
Our websites are going to 404, and we will probably tell our friends. We might try to see if our old websites are still alive somewhere in the Wayback Machine, but a lot of those links are going to be dead. This is what we do: we make things that disappear quickly, and then we also disappear quickly. Thanks; this is me, usually I’m more cheery.
00:01:54.509
I work for a company called Code School, and I've been doing that for the last six years now. This company was acquired by Pluralsight in 2015, and we do a lot of the same things. We're basically trying to infuse Pluralsight with the elements that made Code School special for so many years.
00:02:19.049
I’m going to tell you the story of Code School, or any app, website, startup, or company that you've been a part of; it's not particularly special, it's just one of many stories. But I'm going to attempt to glean some useful knowledge and wisdom from our little story.
00:02:30.989
Back in late 2010, in Orlando, Florida, someone did this, a common occurrence that millions of people have experienced. Realistically, it’s probably more accurate to depict it a bit differently; the bottom part is wishful thinking. It was actually my friend Andrew Smith, who I went to school with and at the time worked for NV Labs in Florida.
00:03:07.560
They had been working on this idea because they attended numerous conferences and workshops, where they had to organize many Rails workshops. The process was confusing, messy, and people wouldn’t be in sync; oftentimes, they wouldn’t have the correct dependencies installed. So, they decided to create something called 'Rails for Zombies,' which would simplify that process.
00:03:18.419
This was the first commit to turning 'Rails for Zombies' into its own product. It was something that could be taught on multiple platforms, not just Rails itself. As is customary when you create a Rails app, you spend a few days changing the defaults and installing the specific tools you prefer, like RSpec, Factory Girl, Factory Bot, and Tapas Bar.
00:03:30.599
You noticed some people starting to join in on the fun. By December, they were really excited and worked even through the Christmas break to get it done. The actual first commit occurred on December 22nd, 2010. I joined this story exactly one year later, in January 2012, after trying everything I could to get into this adventure.
00:04:02.639
At the time, I was in school, and I could see there was something special happening. The site looked like this: if you've been to Code School, you know how it had a very textured design, with lots of cool royalty-free art that looked fancy, coupled with various interactive buttons and calls to action. Initially, we only taught a few subjects, perhaps just four or five courses. It was a tough sale to pitch subscriptions against that backdrop.
00:04:48.870
The very first thing I did was nitpick; there was a button that wasn’t clear enough for team subscriptions. That was the first thing I touched in the codebase three days after starting my job. Fast forward two years later, I was a bit more comfortable and much less concerned about impressing others.
00:05:14.790
Earlier, I think DHH talked about barriers to entry in the community. We were really concerned about bringing people into the Rails community, as it had so many advantages and benefits. During that time, 'Rails for Zombies' was this platform that eliminated the need to install Ruby or deal with any dependencies. Users could just start experimenting with Ruby and Rails, understanding how the interface and APIs worked.
00:05:41.900
It didn’t teach everything, but it helped users get started quickly. We also revamped the 'Try Ruby' website, which had become somewhat abandoned, making it more engaging and secure. The timing was right; browsers could handle the features we implemented, and other companies also joined in to teach people this way.
00:06:14.190
We spent an inordinate amount of time crafting quality content. Just like magicians performing tricks that bewilder the audience, we put a lot of effort into making our courses the best. The audience responded — people like you wanted to invest in our success and share their learning experiences with us, contributing to our growth.
00:07:00.120
In a few months after I joined, we revamped the website and added numerous courses for JavaScript, Node.js, iOS, and many other technologies. As someone who worked on the website, code school dot com became widely recognized — when people started their pet projects today, they were familiar with deploys on Heroku.
00:07:35.750
It was a fantastic, fulfilling time. However, there was also this aspect where we didn't notice as we were growing expenses creeping up, leading to monthly costs in the hundreds, sometimes even thousands. Occasionally, we’d have spikes in traffic whenever we released a new course, energizing the team.
00:08:12.330
We got excited about building this thing because we saw the positive response from users. We started adding gems and new features, and the project started becoming bloated. Aside from software dependencies, we began seeing human dependencies grow as well.
00:08:47.880
The team expanded, and people were relying on us to teach in their companies and schools. This was a time when we weren’t quite responsible enough to manage all of this on our shoulders. Adjusting to this growth took time.
00:09:18.350
During this time, we frequently questioned whether we needed to continue paying Heroku for hosting or if we could manage it ourselves. The naive belief of 'what could possibly go wrong?' often led to miscalculations.
00:09:45.270
Over the years, it took us considerable time to return to that earlier developer experience on Heroku. There’s this economic concept called opportunity cost; it’s the loss of potential gain when choosing one alternative over another. If you allocate funds to one choice, who knows what you'll lose on the other end?
00:10:10.930
This predicament only compounded when we noted how other successful peers in the community had convenient tools or customized solutions. It sparked ideas in us. We thought about creating our own tools to cater to our specific needs, believing that our unique setup would require it.
00:10:35.370
But the truth is, most of us are not that special. Sure, the product we create can be unique, but we all still face the same fundamental challenges: managing users, authorizations, billing, server configurations, and handling security.
00:11:00.150
We often built small tools to improve various aspects of our applications, conducting experiments with frameworks like Phoenix or Node. Before we knew it, we were managing over a hundred Ruby repositories for a team that never grew beyond fifty people.
00:11:26.440
We were producing more repositories than we had people. The desire to be unique drove us to develop solutions specifically for our niche, spending energy that could have been used on more standardized tools.
00:11:47.740
As David discussed this morning, we often felt that the built-in tools weren't special enough for us. We justified our choices based on a so-called quest for uniqueness while neglecting the value of adapting existing solutions.
00:12:09.980
This extended to newer frameworks emerging that competed with Rails, which were great for experimentation. The challenge was creating a false dichotomy where we saw Rails on one side and freedom, simplicity, or novelty on the other.
00:12:31.460
What we missed there was that we shouldn't have viewed it that way—especially as a small company with no investors. However, many good ideas existed within those alternatives, and many communities were eager to share these concepts.
00:13:02.420
And once in a while, those ideas would surface and become part of Rails itself. Think of Ruby as this vast arena of possibilities where useful techniques from various areas made their way into standard practices, benefiting everyone involved.
00:13:25.250
In 2010, significant conversations centered around where to place business logic, whether it belonged in Ruby’s core or within the Rails domain. We found ourselves caught in the chaos of choosing how to organize our work.
00:14:05.100
Everyone was discussing architectures like Service-Oriented Architecture (SOA) fiercely. At the time, we were eager to be thoughtful and responsible as our company matured.
00:14:36.600
Some senior team members decided to embrace this paradigm, considering it might give us clean, well-defined boundaries while still encapsulating business logic within manageable services.
00:15:07.650
Ultimately, opting for a distributed service architecture led to trading local complexity—something we understood—for the potential chaos of inconsistencies across multiple services.
00:15:38.530
Instead, we simplified; we kept operations centralized within one monolith that was service-oriented in nature. It made sense because it mechanically allowed us to create users, subscribe them, and charge for services effectively.
00:16:03.520
However, things became complicated when someone needed to charge a subscription without performing all the other linked actions we'd not foreseen, resulting in breakdowns.
00:16:29.230
This tug-of-war between functionality and service structures revealed that as long as we used Rails, we were stuck with its persistent models. Despite efforts to use 'service' abstractions, it often felt like just adding a decorative mustache to the existing Rails functionality.
00:16:51.270
With this realization, service definitions began to shift. We retained some of those 'Rails' approaches while attempting to adapt to new ideas, yet somewhere along the way we lost track of the balance.
00:17:15.490
The project that took off from a conference began morphing into a product upon which people became increasingly dependent, so we had to take all these considerations seriously.
00:17:42.120
Performance, reliability, and the unfortunate term 'doctor's excuse' seldom sufficed for justifying haphazard decisions, especially as we began feeling accountable to our customers.
00:18:05.360
However, the cycle of instability persisted. People entered and exited roles whimsically, resulting in a lack of ownership over our products. The instability was palpable, leading to inadequate knowledge of how everything integrated.
00:18:31.290
During this period, Katie and Joel joined our team. We recognized the importance of building our team responsibly, pairing individuals with varied backgrounds to cultivate our project's future.
00:18:56.570
Their collaboration—the combination of technical proficiency and liberal arts thinking—proved invaluable in our discussions. They allowed us to look deeper into our processes and vocabulary.
00:19:22.330
As the team diversified, we felt compelled to foster an environment where all voices could matter, allowing for constructive feedback and discussion without fear of punishment.
00:19:46.560
As the company matured, we began to institutionalize our processes, inadvertently stifling the excitement and spontaneity that fueled our earlier success. We introduced rigid frameworks around production, which led to less enthusiasm.
00:20:09.180
A quote often attributed to Mark Twain says that during a gold rush, it's a good time to be in the pick-and-shovel business. As we took stock, we noticed that we had accumulated an abundance of tools and resources.
00:20:35.610
This fertile ground led to a surge of companies filling the gaps we hadn’t realized existed. But for us, the trappings of excessive creation became problematic; our ability to objectively assess our output came into question.
00:20:58.140
We became focused on scalability—more people were using our platform at different times across the world. Our website began faltering under heavy spikes while we ignored necessary upgrades.
00:21:26.800
This led us to seek assistance from those in the community who were more seasoned than we were. Performance became a critical area of concern.
00:21:54.570
We eventually reconciled the reality that Rails could scale. However, we overlooked browser performance challenges, believing those weren’t our problems but rather issues for JavaScript developers.
00:22:29.650
We found ourselves spending excessive time scratching our heads over graphs when we should have been focusing on solid, clean code.
00:23:05.380
Moreover, as a company, we learned to value the people over the code. The people owned the products, the services, and were the keys to success.
00:23:25.830
Where coding once dominated my focus, I've shifted towards removing old lines of code—bulldozing outdated practices to make way for newer ideas to flourish.
00:23:49.170
As we reached a substantial scale, security became a pressing concern. The risks involved with who had access to sensitive information grew with our team size.
00:24:12.370
We retained old habits from a scrappy startup phase, leading to insecure data practices. I recall a particularly embarrassing note: many old passwords were stored in plain sight, leading to a moment of panic.
00:24:39.600
Eventually, we started receiving communications from ethical hackers who discovered vulnerabilities. Their feedback, albeit sometimes alarming, was essential.
00:25:04.910
Just as a town may overlook subtle issues until disaster strikes, companies can lapse into a false sense of security, only to find themselves in difficult situations.
00:25:23.800
Privacy regulations, like GDPR, introduced challenges that required immediate attention. We began noticing significant implications, particularly relating to user data management.
00:25:41.360
Identifying sensitive personally identifiable information (PII) became paramount as we recognized that certain data, such as IP addresses, lay within our reach as we collected records over the years.
00:25:58.930
As our compliance obligations grew and became prohibitive, we faced new responsibilities we hadn’t fully anticipated, leading us to acknowledge the intricacies involved.
00:26:16.480
About three years prior, Pluralsight acquired Code School, and during that time, our focus shifted toward integrating the best of what we had created into their platform.
00:26:34.340
Now, though the journey has led to changes, we are faced with bittersweet news: as of June 1, 2018, Code School will be shutting down.
00:26:53.300
That reality fills me with sadness; the term 'sunset' feels more like a euphemism for a demise, where we shroud an ending within polished phrases.
00:27:08.870
In stark honesty, we need to recognize that saying 'we are shutting down Code School' is a painful truth—one that reflects the hard work and dedication poured into building something supportive and valuable.
00:27:27.830
While the spirit and interactive core of Code School will continue in some form within Pluralsight, the transition cannot erase the hard-fought history we have built.
00:27:41.320
However, as I look back on this experience, I realize there is far more to celebrate. It’s not solely about the legacy of a product but the team I've grown alongside and the community of learners we created together.
00:28:09.710
Though the endeavor that consumed an estimated 20% of my adult life is concluding, I want to ensure that this journey informs the future rather than defining it.
00:28:30.050
This is a moment of reflection on how to better navigate the complexities we face, reminding ourselves that we must prioritize our values over mere functionalities.
00:28:43.910
Wrestling with challenges should never impede the kind of culture we want to uphold, one built around empathy, understanding, and integrity.
00:29:02.320
Lessons exist all around us—in the triumphs and failures alike. Encouraging one another, fostering a sense of community, and celebrating even the tiniest victories makes all the difference.
00:29:13.970
This journey, rife with moments of joy and chaos, perfectly encapsulates the essence of learning by doing and supporting each other along the way. Thank you very much.