I think we should probably get started. I think this is a good group. I think everybody here is ready for a nap, a nice, soothing, relaxing experience.

In literally every conference talk I've given, I've been scheduled directly after lunch, save one. And at first, two times, three times, I'm like, this is obviously a coincidence. Like, nobody, like, you know, I don't know how they put schedules together. But I think they were like, hey, that guy that talks like he's on crack, let's put him after lunch.

I think there may be, like, a conspiracy afoot here. So, we're here to have a little bit of fun today. I'm from Austin, who all here is from Austin? Solid, solid contingent of people who felt pressured to be here because they know me. Awesome, thank you. A lot of people, you know,

think of Austin or keep Austin weird or whatever. We actually don't say that there. It's like saying San Fran in San Francisco. People don't do that. Nobody says keep Austin weird. They all say breakfast tacos. That's the actual phrase. Today, we are here to learn about how to dockerize your React container. So everyone, forget everything you know

about web development. You're about to have your minds blown. Hang on, hang on, hang on. My tech death watch app is alerting me that Docker and React are over. Okay, sorry everyone. Forget everything I may or may not have taught you inadvertently about Docker and React. According to Hacker News, I am now going to show you how to web pack your Elm Kubernetes.

The first thing that you need to do to get to hello world in web packing your Elm Kubernetes is, yeah, I don't know what any of those words are. If you weren't looking actually for that. A lot of thought leaders in tech have taught me to use your insecurities to sell things to you. And so that's exactly what I'm here to do today.

I'm gonna take your insecurities and I'm gonna sell you things. But first, let's talk a little bit about midlife crises. A midlife crisis is complicated. Some of you are going through it right now. It's basically when you face your mortality and you decide to start making some rash decisions. This is my dad. When he was just a shade younger than I am now, he shares my enthusiasm for fanny packs.

This is his brother. And my dad went full-blown midlife crisis. He bought the red sports car. He traveled the world. He got remarried and he moved his whole family across the country. And I think as web developers, our knowledge expires so rapidly that we've started fixating on its mortality almost all the time.

And that leads us to start making some rash decisions. So if you're new to Ruby or you just love it, I bring you a word of comfort regarding your career. If you're lucky enough to feel comfortable with it, then I also bring you a word of caution. Since the web tends to reinvent itself every 45 seconds, it's tough to think past the framework that we're supposed to learn.

We're gonna become permanently and immediately unemployable. So I'm Brandon. I run the front side. I think we're doing some pretty special stuff there. We're working on a catchy slogan to kind of get that message out to people. I'm open to feedback. We're sort of spitballing here.

This is us a little over a year ago. We've always been like this really tight-knit group of folks trying to help each other, teach each other, make each other feel awkward in Photoshop. We've grown since then, but our mission is the same. We build great software and we like to work in JavaScript. We want to build ambitious front ends. We like to use Ember for that,

which is a JavaScript framework that's famous for being authored by a near-sighted hamster. It was when I was first learning Ember that I started noticing a pattern that I would like to share with you. So let's talk about the state of web development today and make some predictions and explore that a bit. So I'll let Clubber Lane actually make the prediction if you're trying to keep up with the pace of new tools, languages, frameworks.

So let's talk about the pain. Pain point number one, how are you supposed to stay on top of new tools, much less evaluate them? So Ember is about four and a half years old. Other frameworks have come along since then. More than a few frameworks have come along since then. I just want to ask, in what universe

can there be 24 best frameworks? Like really, let's, come on. I think we're maybe using the word best a little loosely there. So you just sit there and you stare at all these choices like an open fridge with a bunch of mystery crap in Tupperware containers, right? Like none of those look very appetizing. And people talk about this stuff like I'm supposed to know what these things are,

I'm supposed to have evaluated all of them, but I haven't heard of half of them. So maybe I'm getting too old and maybe web development has run me over and I hit my midlife crisis and I need to go buy a sports car and become a manager or something? I don't know, Nick can tell you. But this thing starts feeling like a treadmill. Like a mean-spirited treadmill that is always just like a hair faster

than you can actually run. Like who set up this ecosystem? Was this designed by like a sadist, an entire industry, just to torture us web developers? The second pain point is that once you do actually decide on a stack, there's just no way that it could possibly live up to your expectations of it. Like you've been waiting 20 years for a new Indiana Jones movie. It's about aliens whose treasure is knowledge.

So let's say you did pick a tool that isn't about aliens. He's all right, everybody, he's fine.

But when it comes time to actually ship, you pull out that Jenga piece and it falls apart on you, right? And what used to take minutes now takes days and documentation's really scarce and you're diving into the source code all of a sudden to see whether it's a bug in the tool or if you're just an idiot. So the third pain point is it never seems safe to fall in love with your technology. Like we're here because we love Ruby, right? It never feels safe to fall in love with your tools though.

Like my grandpa used the same frickin' miter saw for 30 years to build houses. And you don't get to keep a tool for 30 months. So I checked Google Trends actually on this shortly before the talk and I have some unsettling news. Rails, Rails didn't make it.

We did everything we could. We tried giving it WebSocket support. Ah, I'm just so sorry. The injuries it sustained from Node were just too great. Damn it, this is always the hardest part of the job. I'll see you at the crossroads, Rails.

Let's talk about MySQL. It died so long ago, only you old timers even remember what that was back when we still used relational databases, am I right? Ask your grandma about those sometime, she'll remember. That poor, poor MySQL dolphin. So my favorite front-end framework got killed last year because a new library showed up. So what am I supposed to do?

Now that actually is a little bit of dispute. Since it's a four-year-old JavaScript framework, it was well past its life expectancy and it could just as easily have died from old age. So I went to EmberConf in March and James Kyle, the creator of Babel.js, mourned with us at this giant funeral for Ember. And I think everybody will remember where they were

when they heard that Ruby had died. It almost, almost makes you feel like a little guilty for all the times we were dancing on Java's grave. So the thing is, this process, are you starting to get a pattern here? This process is totally predictable. It's so predictable, in fact, there is actually a chart for it. There's a company called Gartner which gets paid a lot of money by a lot of large companies to chart where these tech trends

fall along this axis every year. And none of these things actually did die, did they? Turns out once it's gained popularity, technology is harder to get rid of than Steven Seagal's toupee. So why do we do this? We're just trying to get from a higher state of pain to a lower one. And something comes along that addresses and promises and in some case actually creates this dissatisfaction

with our current tools. So what's amazing is how quickly this can happen. Like your own brain. You're not, you're susceptible to it. I'm susceptible to it. I was at Macworld 2007. Steve Jobs got up and this was like, I was jazzed, right? I'm in this audience like you are and Steve Jobs gets up and he's like, ta-da, freakin' iPhone.

And I was like, what? And I took my six month old Motorola Q out of my pocket and I looked at it and I literally wanted to hurl this thing at the screen for not being a phone I had just learned even existed. So I want to look at this cycle through the lens of Rails history. First let's look at it in the abstract, then through Rails history and then how to apply it

to selecting frameworks, languages, things that you might want to learn. And lastly, I want to offer that comfort and caution to those who might feel a little uneasy about the pace of change in technology. So let's start with those abstract concepts and talk through how this cycle works. So naturally, we'll use medium think pieces which is the de facto way to demark the start of each of these phases.

So the first is the technology trigger. There's a launch with a big promise and the initial spark of interest hits a few early adopters and then Hacker News crowd jumps on it. They get excited, they vote it up and the tech is off to the races. Then it gets to this peak of inflated expectations. Suddenly it's all anyone's talking about. Performance, security, new capabilities that you haven't even dreamed of yet

are yours for the taking if you'll just adopt this new tool. Now at some point, the rocket ride is over and we find ourselves in the trough of disillusionment. The tech doesn't meet those outrageous expectations. And then you get people loudly quitting and the wailing and the gnashing of teeth. But if the tech survives, you reach this slope of enlightenment where you start seeing a light at the end of the tunnel.

You start hearing things like 2.0 and 3.0. The learning tools, the materials, the community starts stabilizing. And finally, you get to this nice plateau of productivity where a bunch of people become quietly productive and they don't really see the need to talk about this too much anymore. And I will tell you something I've learned about Hacker News is this is something I promise you will never see there.

Yes, we've been quietly productive with Ember for about 18 months. It's pretty nice. That's weird, where are the upvotes? Boo, go home, you're boring. So those are the peaks and valleys of successful technologies if they make it out of that trough alive. So let's go back and look at this, the lens of Ruby on Rails history.

So how many of you remember this? It just uses Ruby everywhere. Look at all the things I'm not doing. That's how much work you have to do to get to Hello World. That's not a lot. Whoops, it worked, whoops. Okay, I wanna see a show of hands of how many people in here remember that. That is a startling small percentage.

Okay, but also, that's good. That means that only a few of you are near death. So that was the technology trigger. The bad news is, yes, you are old. I wasn't even a programmer yet when I first saw that. But my friends that were programmers showed it to me and I was like, what, I wanna do this for a living. That's amazing.

Luckily for us, Buzzfeed was there to capture every step of Rails' rise to power. The trigger event here is where the tech analyst, the Hacker News crowd, trip over themselves to get the scoop on this new framework. And you start hearing these breathless claims like it will make your wildest dreams come true and cure rabies. The hype builds up until it becomes a little ludicrous. And that's when Rails hits its peak

of inflated expectations. I really wanted to put a Photoshop together. But how in the world could I possibly do something better than this? Let's all reflect on how this was a thing. Ruby everywhere. Man, GQ for programmers. Anyway, you wanna build a web app, migrate a database, fix a leaky gutter,

fix your marriage, I don't know. Ruby will solve all those things. And who could forget Def Leppard's monster hit from that era. If only somebody in the community was wise enough and prescient enough to predict this around, say, I don't know, RailsConf, 2006. Obviously, we did. His name was Wylie Lucky Stiff.

And I wish I could thank him for all that he's done for me, including inspiring me that code could be art when I was intimidated by the idea of learning to program. He had an astoundingly prescient warning for us 10 years ago. And I encourage you to watch the whole RailsConf, I don't know, talk or performance, but this is from a video series that he did called The Least Surprised.

Right now, anything is possible with Ruby. First of all, it's unstoppable. The hype machine is totally rolling down the street. People have been trying to hit the brakes. The brakes on the hype machine are all burned out and they don't work anymore. And second, so many great projects have used Ruby that it's proof that you can do anything you desire,

any of your wildest dreams can come true. I used Ruby to lure Catherine Zeta-Jones into my unicorn petting zoo. You have a unicorn petting zoo? Made entirely of Ruby. So we get here, we get into this frothiest peak,

just mentioning the name of the technology and the title of your introductory conference talk means it's gonna be standing room only. You can Google for like 100 hello world tutorials and none of them actually help you understand this new technology. But they are there. Once you do figure it out, this promise of productivity gains means that you're finally gonna ship web apps 10 times faster, right? So when a recruiter asks if you're like a rock star

or a Jedi, you'll be able to say, uh, both. This means you finally get to wow your boss, fulfill your wildest dreams, buy the house, get the raise. That's not the actual promise, but that's the one that we buy. And all the hot air from these inflated expectations, it starts seeping into our egos just a little bit.

And you start thinking everybody who came before you is maybe just totally wrong and you're just a little more right than everybody else has ever been. And you get to get up on stage and tell the establishment exactly what you think of them and what is more fun than that kind of rocket ride? Come on, the kid, we're taking this baby to the moon! But like drinking expired soy sauce,

the reality starts catching up with you. A technology inevitably goes through this trough of disillusionment. Again, if only someone could have predicted this. Mr. Molski, obviously some people here don't have your vast vision for Ruby. And I'm not sure even I understand the point

of indulging these decadent wishes any further. You're just setting this all up for a huge crash when things don't pan out and the idealism fades and the world moves on to the next language, something even more beautiful and expressive. I like to call this imaginary future language absinthe, a language smooth and creamy and scented with purest of licorice.

She's lying, absinthe is the apocalypse. She's got rabies. Keep the cure to ourselves. She's going to steal our eigen classes. I actually genuinely wonder if elixir is intended as like this oblique reference to absinthe.

I'm not sure. So this phase is marked by prominent defectors. This is the thing that, imagine this, the thing that caused people to leave for your greener pastures is causing them to leave for other greener pastures. Go figure. By the way, this is, I'm just going to stop here and say this is my favorite slide out of all of them. This is maybe the best thing I've ever done in my life.

So remember this? There were some prominent defectors in this phase for Rails but I think this one takes the cake. I met this guy actually at Mount West Ruby and he seemed fine but I mean this dude literally offered to fight every developer which seems, I don't know, a little aggro considering we're talking about which interpreter we choose for strings of characters we like to type into a computer.

Like hey man, do you want to fight about it? And I'm like, I just wanted to open a poll request. I don't know, I don't want to get punched in the face. But that's the amazing thing. Once those super early adopters get mad and start leaving and they declare your tool dead, the tool actually starts getting to do real work. And this is where we start seeing service-oriented architecture talks at conferences.

You know people are putting a technology to some real work when it has to speak XML over non-restful endpoints. And this is where blog tutorials turn into book deals. And this loose affiliation of enthusiasts turns into a real community. And all those enterprise dollar, they get to buy race cars. I don't think DHH hates this phase. And finally you get to this plateau

where a bunch of people become quietly productive with the tech and they don't see the need to talk about it so much. It's not cool anymore. There's nothing exciting or cool about quiet productivity. You don't get any more magazine covers. It's been a decade since MySQL did anything anyone considers cool. But you know what is kind of cool?

Billions of dollars. Billion with an S? So is Rails a good technology or a bad technology? It doesn't matter because it's an entrenched and productive technology. So here we'll have to take a little bit of a detour before we dive back into the history. At a RubyConf talk last year, I shared the concept that there are three predominant personality trait types in technologists. Pioneers, settlers, and town planners.

So we're gonna run it through a quick cliff notes version of that. Pioneers itch for the latest technology. They like fording the rivers. They like contributing and they like exploring the new territory. It's all about that thrill of discovery. Settlers try to create order from that chaos. They build infrastructure and communities. They connect that pioneering work to real business and user needs.

Town planners are just trying to get things done at a scale and performance that's impossible with the unproven technology. They're trying to turn your exciting technology boring and they will always win. So let's dive back into the history to see how this fits together. My theory is that DHH is actually a settler who was sort of pushed into pioneering

a solution out of frustration. I doubt he'd disagree that many of his ideas were lifted from pioneers like Martin Fowler. Now outside of Utah, people do not realize how big a deal pioneers are there. They get their whole own day on July 24th. It is bigger than the 4th of July. And I think tech loves its pioneers too. And when Rails fired the starting gun with the blog in 15 minutes deal,

they held a parade for DHH. And Rails was surprisingly familiar in the look and feel to the Rails that you'll see today. But you would die a death of a thousand cuts if you actually tried to use it, much less deploy it. I don't know if anybody here remembers how that was done. Did anybody deploy pre-1.0 Rails apps? How fun was that, super fun?

Yeah, super fun, he said super fun. So take care of your old stuff. Some poor schmucks even bet their companies on this unproven new technology. Whatever happened to these poor saps? This is actually a fun bit of retconning. This didn't used to be a demo store for Shopify. It was Toby Lukey's original business from which Shopify was actually extracted.

And then all those settlers arrived. People needed guides, books, supporting libraries, deploy tools, hosting services. These settlers were all too happy to look at these as opportunities to help and to build businesses. Around this time you might have had like nine to 50 gyms starting with X as something. Rails 1.2 introduced RESTful routing,

which basically turned it from this academic concept into the predominant architecture for web apps today, which is kind of braggable. A huge part of settling an area is setting up schools, right? Well, I think we owe a huge debt of gratitude for Ryan Bates for starting RailsCasts. I know I always had two or three tabs open to this site at all times.

More no-name startups dumping their futures into the black hole of unproven tech. Get a grip, hipsters. Sorry, Hiroku, that was a dumb move. GitHub got their start using Rails around this time. You gotta love a service that launches with the promise, no longer a pain in the ass. I think that's a good pitch.

Hardcore forking action, never forget. So Rails was created to fight these architecture astronauts that had set up and fragmented the Java web culture. But as our needs grew more complex, our architecture started responding. These previously maligned computer science folks take over much of the development of Rails, bringing modularity and relational algebra to active record.

The big money starts moving in, and the Rails tent just has to start getting bigger. These starts including things like code schools and enterprise needs. Now, at this point, both your bank and the startup disrupting your bank are using Rails. That's how these three archetypes play out in a successful community.

Everyone has all three internally in this big soupy mess, but one is typically dominant. So let's push through a little quiz, like a little Cosmo quiz here, which irritates you the most, being required to use updated tools, team members that try to rewrite everything in the hipster stack, or anything that just gets in the way of shipping. What do you enjoy the most? Accepting a pull request for your open source library,

applying technology in a way that actually makes your business real money, solving a tricky performance issue. Where do you feel the most helpful? Showing somebody that there's a better way, a new, better way of doing things, or improving somebody else's documentation, or automating a tedious deploy process. Each of these roles is valuable. Pioneers experiment, and they help define a sense of what the future can look like.

Settlers connect that to real problems and opportunities, and town planners help that scale to affect large numbers of people. Settlers and town planners may call pioneers hipsters. They're swept around by all these fad technologies. Pioneers often get mad at settlers for using their innovations to gain notoriety or to make money. And town planners get called out for lacking a sense of adventure,

for being architecture astronauts when they're just trying to make things stable, predictable, and scalable. As humans, we're wired to be dismissive of those that don't share our default outlook, and you wind up saying snarky things that are kind of true, but not really, I don't know. I think any criticism of millennials is generally hilarious, but not really accurate.

So we take on each of these roles at different points, but it's to our advantage to lean on what we're best at. So me, I perform best in the settler camp because I enjoy connecting things to practical uses. I live for that synthesis and for the serendipity of it.

So great, now we know the hype cycle, and we have an idea of our preferences. So now what? Well, once you know this stuff, you can set yourself up for some pretty rad career success instead of being at the mercy of this cycle. If you don't understand it, you can actually lose at this game. You can watch as your skills turn into commodities and become devalued. You can burn yourself out trying to keep up,

or you can side with tech that doesn't make it, or you could just opt out entirely and stay a Fortran programmer. I hear that pays pretty good, actually. Now this may all seem like a little bit of information overload right now, but once you understand the cycle, you get to play to its strengths. I actually thought I was gonna invent this workout video, but apparently it exists in The Simpsons, so. That combined with understanding your preferences

means that you can focus your attention where it's most valuable. So let's use that to map out the cycle for your personality type. You simply can't get wrapped up in every piece of new technology that comes out. But when you do feel obligated to check something out, you just need to answer these two questions. What stage is it in, and should I worry about it?

Pioneers are best served by grabbing interesting new tools, jumping right in as soon as they hear about them and it seems interesting. Settlers can just watch at this point, and town planners can safely ignore for now. Now at the peak, it's time for the pioneers to really shine. Settlers can exercise some skepticism, but they need to keep an open mind, and town planners can again safely ignore and keep shipping with the stuff that they know.

This phase is where everyone starts taking notice of a tech, but it rewards pioneers the most. Pioneers can train, consult, write blog posts, even become a core team member in this unexplored new territory. Once a tech's hype cools a little bit, it hits that trough. The pioneers can exit the ride if they want. They can change roles and stick it out, but they have to be aware of the fact

they're actively switching from pioneer role to a settler role. It looks like it's gonna make it through the trough, it's time for the settlers to step in, and the town planners can glance up if they want. Pioneers at this point of the slope of enlightenment are just done if they want. They're done. The technology is now climbing that slope because enterprising settlers are the ones writing books,

establishing consultancies, building products, creating an entire support infrastructure underneath it. The town planners need to start running through some of the new tutorials coming out to be aware of, oh hey, this is a technology I might actually have to pay attention to. Then you get to this nice plateau of productivity. Settlers can apply this now low-risk tech to novel business problems. Town planners can help automate improved performance,

create enterprise-scale solutions. What was once a toy solution is now running Fortune 500 companies and handling your bank transactions. So I told you earlier I was gonna give you a comfort and a caution. So let's start with a comfort. You might be wondering about whether your favorite technology is eroding underneath you. Maybe Elixir is gonna come kill Ruby.

Maybe Phoenix is the new Rails. I read a Medium Think piece that said that. It must be true. Or the tools you use are garbage and outdated compared to this shiny stuff that you're reading about in these blog posts. Like, oh no, am I gonna have to go get a suit? Like, is this my life?

Or maybe that you're broken and lazy because you'd rather keep working with stuff that makes you feel productive than learn seven new programming languages this month. So for the last year, I've been working in a production Rails 2 app. And you know what? It solves a lot of problems for a lot of people. And it's full of problems that are in no way related to the fact that this thing runs in Rails 2.

And I'm also working on a side project in Elixir and Phoenix. And you know what with that? I cannot shake the feeling that if I'd just use Rails, I'd be done like five times over by now. I mean, it is great to learn new stuff. But we've gotta stop this cycle of making people feel inferior for using the things that make them feel productive. Let me put a finer point on it.

Nobody gets to make you feel ashamed of liking the stuff that you like. And when the shoe is on the other foot and someone likes something you don't, please consider this. Please don't yuck someone else's yum. It actively chases away the people that we most need in our community. And it only leaves room for cynics. And I know most of us have done this at some point or other. I know I have.

I'm not super proud to admit that. Moving on. I wasn't going to take questions, but it seems like we have one. I'll repeat it. Brandon, if Ruby isn't dead, why do you run a JavaScript consultancy? Fair question, okay, okay. Doesn't that make you a humongous hypocrite? All right, first of all, ouch. Second of all, I really prefer working on the front end.

And my opinions on whether you should write your JavaScript yourself or tell Rails to write it for you are apparently controversial. Okay, I'm a child of controversy, I guess. But third of all, yeah, I don't know how good a bet, if you're going to establish a consultancy today, that Rails as a specialty makes sense.

Or really any plateau of productivity technology. Consultancies that specialize in a technology are very much selling pickaxes in a gold rush. A big chunk of their value is having that early expertise in these emerging technologies and moving on as the technologies mature. Now if that doesn't sound fun, that's fine. You just move up a level and focus on problems that aren't really technology dependent.

And you go, oh yeah, I just solve scalability problems for people and I happen to use Rails. So that's where the caution comes in though. That leading edge of technology does move pretty fast. And if you stop learning, you can eventually be left behind and see your skills become commoditized and devalued. If your job, like apparently this lady here is to hold that other lady's cell phone briefcase thing,

you might have stayed with the technology just a little bit too long. I don't know, those are pretty cool. And that lady is really nice to carry that other lady's cell phone thing while she's on the phone. Think about what her day's like. So in that bouncy sports ball game with the net, with the basketball ring, there's a thing where you plant a strong leg and you pivot around that, right?

I suggest having one tech you use to ship to production and something you do on the side for fun. If it catches for you, awesome. The more you do it, the better you get at it and the more you wanna ship stuff in it. If it doesn't catch for you, fine, swap it out. No harm done, right? There's stuff you do to learn and there's stuff you do to ship. Now if you follow this pattern, you rarely feel this swung around by the cycle.

You just use the tool that you learn on the side more often for new problems. I love Ruby, but I'm a full-time JavaScript programmer now. The thing is, I didn't really notice that happening. There wasn't like a period of time where I was like writing a medium think piece about how I'm leaving Ruby. There's no dramatic exit. It just kind of happens. You just start leaning on this thing that you know.

One last warning, there are technologies that bet the farm on hitting a big peak and hoping that carries them through. This almost never works unless the goal is hitting like big VC rounds, in which case, go for it and then disappear, move to Mexico or whatever. Famous Meteor, I wouldn't say them because they would sue me, so let's say Mameus and Meteor.

There are technologies that do this. You want to look for tech that has a vision all the way down to the plateau of productivity because personal exploration of tech kind of follows the same curve. So we can even apply that hype cycle to picking up a new technology. So you start with a tutorial. You get to Hello World and it's like awesome. You're like, I did it, I finished the tutorial.

I obviously know everything about this technology. I have a simple app. I mean, it's not ready for production, but it's probably pretty close, right? But that isn't real life, is it? New stuff is awesome, but the trouble with buying in at the peak is those pesky expectations. Inevitably, we wind up stuck in a ditch again and we thought we were gonna be rocking and rolling. Suddenly, our two-week spike is looking like a much longer road.

Have you ever built a proof of concept in three weeks that took you like six months to get to production and you're like, yo, this is the same piece of software? I think that might be what they mean by 10x programmer. These expectations get inflated

because you demonstrate the velocity of these tools initially and people start expecting that output forever. Like, hurry up, we need the feature. What's the holdup? And all you can think is, what happened, this used to go so fast. And then you feel this thing nose dive into that trough of disillusionment. You slog through this trough with Rails. For some of you, it's recent enough to remember. For some of you, it is not recent enough to remember, but try to remember.

So why would you do that again? Why would you put yourself through all that emotional pain? Why bother seeing a new technology to your own personal plateau of productivity? Well, clearly you picked your new technology for a reason. Call it curiosity, your intuition, philosophical alignment, whatever. But then the pain starts, things get rough. So why would you stick that out? Well, ponder this for a second. The way our whole industry works has flipped upside down.

The problems you're asked to solve, and even the reasons behind that, have changed dramatically over the last 10 years. And a lot of us didn't even notice. We just kept doing our jobs. We've been swimming in this technology avalanche to stay on top, and we didn't realize the fundamental shift that's occurred.

A new focus on user-centered design means that UX drives technology now. The tools we built 20 and even 10 years ago were designed to solve a different set of problems than we encountered today. So we need tools to manage this new world of UX-driven architecture. And people are creating these tools at a prodigious rate. A lot of our pain comes from trying to deal with the chaos that's ensued from this upsetting of our collective apple cart.

Have you been doing this long enough to remember selling the idea of using jQuery to your bosses? Hey, can we use jQuery? Ah, it's too much, just use the DOM. And that is where client-side UI is headed. Client-side UX tools are headed in that direction. So Angular 2, Ember 2, React, they're just tools used to solve a problem.

But it does explain the meteoric rise of tools like Rails and especially the more recent ascendance of JavaScript. I did some side stuff in Ember. I felt good about betting on it. Now I'm encouraged that I'm starting to hear people call it boring, and I'm like, yes! Your bet may be something different. But it's important to understand the why of these bets to make sure they pay off.

Sometimes it makes sense to switch to something new. And some pioneer types even manage to ride that eternal wave every 18 months. But if you're trying to ship stuff, it can trigger that eternal mid-life career crisis. If you notice this pattern in your work life, maybe check, just to see if you're not stuck betting on tools and technologies that hit that peak.

So the tools that have staying power, like Rails, like Ember, tend to push through their 15 minutes of Hacker News fame. And they are focused on long-term productivity, and you can kind of understand the philosophies of them. And they do things that are unusual, like documentation and things that kind of look like long-term thinking. I want so badly to ship stuff, and I thought if I learned Rails, and then Ember,

that I would be free from all the hard parts. That's obviously not true, it's not even possible. But I bought into it, because that's the cycle. It even sounds like the promise. Look at all the things I'm not doing. That sounds like a really nice promise, but it's not the promise. The real promise is about helping you reach that plateau.

On the plateau, you have time to focus. You focus on things that add value, business value. Serious business value.

This person added a lot of business value. Business value continues to accrue. On the plateau, you have time to think, and you start thinking, hmm, think maybe my boss is an idiot. I'm not saying it's true, I'm just saying you can think about it. Maybe you start thinking, I can do better.

And since you focus on business value, you can afford to fire your boss. And then you do, and you turn out okay, and you get to go have your own midlife prices, but that's a different story, right?

And that's it, till the next episode.