 involved in this year's conference apparently, and actually I was here at the very first incarnation of this event back in 2010, back when it was still Mountain RB without the Rocky, and no matter what it's called I'm really happy to be back. It's always a good time and I always love coming back to the extremely bright stage lights, very excited. You don't get to, you know, even with all the presentations I do I don't actually get to be on a stage very often, so it's pretty cool. And I know you all are feeling pretty relaxed, but that's the end of that right now. We're done with relaxation. It's time for code. This is a technical talk. There is some code in it. More on that later. There is also some people in it. For the last couple of years I've been really interested in the intersection between people and code. And it's really funny to me that we think of these things as separate. For example, a conference always has hard talks that are about code and it has soft talks that are about people. And the naming is kind of hilarious there because soft talks are not easy. Soft talks deal with the hardest topics that we have in software development. And I loved how James Edward Gray II put it in his talk in GoGorukko in 2013. He said, programming is easy. It's being a programmer that's hard. And what he meant by that is not that it's easy to learn how to program. There's a lot of syntax and logical thinking and ways of understanding things that you need to do in order to learn how to program, but once you figure out how to tell the computer what to do, then you figure out that, oh, now I have to figure out how to tell the people what to do. And for me and for many of us, I suspect, figuring out the people is much harder than figuring out the computers. Now, if you're one of those lucky folks for whom that is not the case, if you understand people and now you're just trying to get the computer half of it, then you're starting out with a huge advantage. And don't let anyone tell you different because that's the hard part of software. And I think a lot of the conflict that we get between the hard and the soft and this and that comes from this idea that code on the one hand and the people who write it on the other are two separate topics that can be analyzed independently, but they can't. Kind of like these guys, right? These guys are pretty awesome, but, you know, they're a band. You can't separate them. Each one on its own, not that interesting. You have to put them together. This talk deals with one of the most explicit overlaps of the concepts of people and code, and that is technical decision making. How do we make decisions about code? And the talk comes out of an experience I had earlier this year at the Fluent conference in San Francisco. Fluent is a Riley's big front end conference. They do HTML, CSS, JavaScript, all that stuff. It's pretty big. It's about 3,000, 4,000 people. You know, four tracks, three days, lots and lots and lots of stuff. This is an official picture from the Fluent conference this year. As JavaScript conferences go, fairly conservative, as you might expect. By the way, you can tell it's no Riley conference because they, like, sprung for the fancy don't turn over name tags, right? That's what you get for your $2,500 ticket, I guess. But it's a fascinating conference. It's really interesting to talk to all the people there because it feels like a more realistic cross-section of people who use JavaScript than most of the smaller conferences that I go to. Because the smaller ones draw the fanatics. But many of the folks at Fluent work at large organizations. This is their one conference for the year. So while I was there, I spent a lot of time interrogating people in the hallways, making them tell me why they were there. And as you might expect, the people that I met fell into three categories. These are the only bullet points in my slides, by the way. I apologize. I couldn't find a way to get rid of them. So back-end developers who came from a wide variety of places, PHP.net, Ruby, Python, Java, and they were there to learn more about front-end development. Then there were the visual UX people who wanted to learn more about front-end development, but were coming at it from the other direction. But the biggest group, as you might expect, front-end developers who were there to learn more about the hottest things and take it all back to their company. So these are three groups of people with very different set of past experiences, very different skill sets. And what surprised me was when I asked them specifically about why they were there, they all told me basically the same thing. I wrote down some quotes. You can see if any of them sound familiar. My group has started an Ember project, so I'm going to every Ember JS talk on the schedule, which, given the multi-track nature of Fluent, was actually possible to do only Ember the entire three days. My web app has an old jQuery code base, and I need to figure out what to do with it. JQuery is clearly not the cool kid anymore. I want to learn about Angular. I think I can raise my rates. Almost certainly true. And lastly, we have an ancient backbone.js set up that desperately needs a rewrite, but we're not sure in what. And I think by ancient she meant about six months old. So no matter what direction these developers were approaching front-end development from, they're all there to answer the same question, which is, what JavaScript framework should I be using? And this is one of the big open questions in web development right now. And it's an open question because of this. I mean, not because of Ember, but because of this. Wait for it. There we go. This is a great problem for us to have. We have a lot of options. Unfortunately, there's a lot of options. And it can be really hard to figure out what the right answer is for any particular project. Now, you could argue that these days we have some front runners, but it's still early. Actually, since I made this slide about probably six months ago now, since I made this slide, and several of these have dropped off and there's a bunch of new ones, it's a very, very fast-changing landscape. And every technical community, whether it's Rubyists, or back-end developers in general, or front-end developers in general, or PHP people, every community has some question like this that they're working through as a community. And usually more than one. So for example, one of the other questions that we have as a Ruby community, which is more focused on back-end development, is what data store should I be using? Where we have a very similar problem of lots of different data stores to choose from, sometimes unclear what the value proposition of any given one is. And when you're a developer with a specific project in mind, it's really hard to make a decision about which one is the right one for your project. And the internet has a ton of help out there for you about this if you want to go research it. But asking the internet about what JavaScript framework you should use or what data store you should use is kind of like pulling up right here and trying to figure out, OK, it's noon on a Tuesday. Can I park here? Because you get a lot of seemingly contradictory and confusing information. And that was the case even at the Fluent Conference. So one talk in one room was all about how Ember is amazing. And in the same room, next time slot, Angular. Angular's the way. Same room, next time slot, React is going to save us all. And your job is to synthesize all of this information into a decision. No pressure, right? But it's kind of important. Because the cost of being wrong can be very high. It's not just, you know, am I parking illegally? Might I be chased off by the meter maid? If you pick a JavaScript framework that isn't suited to your project, it depends on how far down that road you go before you figure out you need to turn around and come back. How long is that going to take? So these decisions are big and they're scary. And we don't make them very often. And so when we do have to make them, it quickly becomes very overwhelming. Now it would be great if we could find some way to get better at these. One way to get better at something, obviously, is to repeat it. I'm sure you all know that. We have a very persistent meme in our programming culture that's been debunked several times. But still seems to exist. And that is this one. It takes 10,000 hours, it goes, so the story goes, to develop really good skills at something, such as playing a musical instrument, or programming, or whatever this person is doing. Unsure. And there are several very good explanations online of why this is actually not really true. But the meme persists because there is a kernel of truth to it. And that kernel of truth is that repetition is one of the most powerful ways for our human brains to learn something. The key, though, is not just the time spent, but it's how you spend the time. So you can spend 10,000 hours on something. But if you're not doing it the right way, those hours are wasted. To really learn by repetition, you have to do the action, analyze the outcome, and then repeat the action. That's the key part. Repeat the action, slightly changing something to see if it changes the outcome. And even once you think you got it, even once you think you got the perfect cursive letter L, you need to keep experimenting, keep trying new things. And that's where learning actually happens. And so repetition would be great. If we could repeat these high stakes, large decisions, often enough, we could get better at them that way. Unfortunately, it's pretty unsatisfying to think to ourselves, OK, well, I'll just wait 15 years, and then I'll be better at it. This is going to be great. If that's the only way that we have to learn about these things, then we're kind of screwed. But there are ways that you can apply learning theory to get around that. You can make an end run around this limitation on time and apply some of the information from other types of decision making back to this one. Side note, I did this talk, a version of this talk, in London a couple of months ago. And I got to this slide. And I looked over and I realized that nobody in the room had any idea what an end run was, or even what sport they were looking at, necessarily. And I thought about explaining it, and I was just like, nope, nope, nope. Just going to cut my losses and keep going. Things you don't think about when you try to internationalize a conference. So the decision making, the end run that I'm talking about is the fact that decision making happens at many different levels and at many different frequencies. So language and framework choices are probably the most infrequent decision that we make. But there are other things that we do more often such as decide whether to use some random code you found on GitHub or roll your own. And even more frequently than that are the decisions we make every day. Things like, how am I going to name this variable? Where does that test go? What part of the code should we work on next? But even at the smallest, most frequent level, the process we use to make these decisions is pretty opaque. Like you ask a programmer why they named a variable a certain way, or why they put a function where they put it. And a lot of times all they can tell you is something like, well, it just kind of seems like the right place for it, don't you think? Sometimes you get an answer like experience. Intuition, that's another good one, gut feeling. We use these words because we can't put our finger on what led us to do something. And when I ask a programmer, for example, why they like ember over angular, I hear things like, well, it just feels more natural. And I hear that from the angular people when I ask them the same question. So I think that's really interesting. So I wanted to investigate what goes into that feeling of natural? What goes into that feeling of easy? What data do we collect when we make those judgments? And how do we analyze it? What do we do with it? Because we want insights into these, because these are the ones that are high risk. These are the ones we don't do very often, and that we can't repeat as often as we would like. So what we can do is look at these. Because it turns out that I know a lot of people who make a lot of decisions about whether or not to use code off GitHub all the time, and I'm sure you do too. So to start off, I asked a bunch of my colleagues to introspect for me and think about when they're considering using a gem. What do they do? What do they think about? What do they consider? It turns out that everyone starts in the same place. They start in the read me. Now, I discovered when I was doing research for this talk that the read me is a very old meme, actually. Here's a read me from 1935 about how to operate a telephone, and when people come to a read me, they're looking for bullet points. They're looking for features, functionality, usage, installation of the code. Basically, they're looking for the interface of a gem. What does it do? How do you do it? Information's easy to find. It's usually like right there in little bullet points, and here it is to operate to answer to clear to make calls. There's our bullet points. So I want to consider, to make this a little more concrete, an example evaluation of two gems that do very similar things. So let's say you are trying to pick a gem to make HTTP requests, in other words, to make a request from another server, an API, something that you don't have control over necessarily, and get some data back, do something with it. In other words, you want to use the tubes. OK, you want to use the tubes. If you're in Ruby, there's two basic choices you can make. If you Google, you'll turn up these two. Two contenders, HTTP Party, which I'm pretty sure I'm not pronouncing correctly, and Faraday. And assuming you don't choose Faraday just because you don't want to ever say the other one again, not that I've ever done that, then the first thing you probably do is look at the readme for each project, and you'd skip to the usage section, and this is what you find. You don't actually need to read all the code on this slide, I'll point out the interesting bits. HTTP Party has static methods that you can call directly, or you can include it into your object to get HTTP call methods in that object. Pretty reasonable. For Faraday, they have a very different approach. They give you a connection object that you use to make calls. So both interfaces will work. They'll both do the same thing. So how do you pick one? This is not enough on its own to let you make a decision just like a bullet list of features in a framework readme is not enough to make a decision about which framework to use. So what else do we think about? Here's an exhaustive list. Not quite exhaustive. Feels exhaustive. List that I got from interviewing a bunch of people, and I did say there were no other bullet points, but these don't really want them. Anyway, hopefully they don't count. So these are the things they do. They read the readme on GitHub. We already went through that. They look at the number of commits and how recent they are to see whether the project is selective. They look at the issues, how old they are, when they've been addressed. They look at the comments on issues and pull requests to see whether the maintainers an asshole. They look at the number and recency of tutorials and blog posts when they Google. They look at relative popularity to other gems on things like Ruby Toolbox. They look at when it was last released. They look at how many Stack Overflow questions there are and whether they've been answered. They ask people, all kinds of people, different kinds of people, possibly useless people, other people. They look at the documentation. They look at books, screencasts. And sometimes they actually look at the code or the tests. And sometimes they just shove it into the gem file and see what happens. Or they build, if it's a big thing, maybe they'll build a little sample app to see how it works. So it's a long list. I had to move the font size way down. This is way below my standard font size that I have, minimum font size for presentations. And this isn't exactly exhaustive. There were actually a bunch of more things that people gave me that I decided not to include. But this is a, I want to point out a couple interesting features of this list. The first is that different people rank these differently. So I always poke around on GitHub to establish it's got kind of a reasonable interface. And then the next thing I always do, pretty much, is ask my coworkers what they think. Have you used this gem? But one of the people I talked with works at a company or used to work, he's quit now, which is good. I used to work at a company where it was really a bad idea from a political point of view to display ignorance of any kind about anything. So he would hit the read me, but then the next thing he would do is go look at the documentation. So different people do these differently depending on where they're working and other personality quirks. That's the first thing. So the next thing is that nobody does all of these for any given evaluation. This is a union of things people do. Generally though, the riskier a decision is, maybe the more of these we do, potentially. And the last thing is that this list changes as the community that generated it changes. So for example, before Rails came along, a lot of discussion about Ruby libraries took place on the official English language Ruby mailing list. But these days there's no mailing lists anywhere in here. But the Python community still depends fairly heavily on mailing lists. So all three of these things are basically are just pointing out that the way that we collect and use this data, even if it's a split second evaluation, is actually pretty complicated. And in addition, if you eyeball this list, you'll discover that most of it is not data about code. It's social data. It's data about the people. It's information about the maintainers and users of a project. So I wanna categorize this so that we can have a better idea of what we're looking at here. There is some technical data about the code in here. Let's pull that out first. We can call it interface. That's what everyone starts with anyway. So then we've got all this stuff. And this stuff is all about the activity of a project. How often is it updated? How likely am I to get help from the maintainer? Get a pull request merge, something like that. So we'll pull that out over there. This is the only time I've been able to use this particular transition, so I'm super excited about that. All right, so what do we have left? What we have left is this stuff. This is all stuff about popularity. How popular is this particular gem amongst other developers? How easy will it be to find help when I run into a problem? Can I hire someone who's already used it? Let's pull that out over there. And finally, we've got a couple of outliers. Reading the code and reading the tests. Which don't really fit into any category that we have so far, right? Interface activity, popularity, they're all pretty straightforward. Well-known sources of data, potentially mechanizable collection of data. But what we have left is a little fuzzier. It's really more about how familiar does the code feel to you? How much does this code look like what I would write if I were gonna write my own? How much does the maintainer share my test strategy? So let's call this accessibility, move that over there. So there's our last group. So these are the four categories of data that we consider when we're making a small scale decision. Once I got to this point when I was working on this talk, I sort of squinted this slide for a while and I realized you can actually group these in two interesting ways. So stay with me here, we're about to make a four quadrant system. Apparently this is a thing. So here we go. First off, you can draw one line here, right? The two categories on the top, accessibility and interface are both about you. Interface is about whether the code will do what you want it to do for your project. Accessibility is whether your team feels comfortable with the metaphors the project uses in its code. So call it internal. And then the bottom, the two categories are about the people and project outside of your team. So popularity and activity measure external factors, right? So we've got that. So then of course you can draw another line. And then on this side, on the left side, accessibility and popularity both have to do with the people around a project, right? Accessibility is whether or not your people can use it. Popularity is whether or not other people are using it. And on the right side, interface and activity are both information about the project itself. Information about the code. The interface, as we said, is about whether the framework does, mechanically does what you need for the project. And activity is of course generated by people. But ultimately it's about the project, it's about whether or not you can bet on bug fixes and improvements down the line. So there you go, there's my four quadrant system from making technical decisions. I was showing this to a friend and we got to this part and he was like, this is awesome because you're a consultant and consultants are supposed to have a system that they're selling and I was like, huh, all right, all right, this could be a system, we could call it a system. And I thought, you know, if I'm gonna do this, I gotta own it, this has gotta be mine. I've gotta give it like the most narcissistic title I can think of. So there we go. Thank you very much ladies and gentlemen. The May system, if this does make you wanna throw like truckloads of money at me, let me know. But otherwise I think I'm just gonna do my normal thing, that's okay with you guys. So so far, right, we've got a system, whatever we've got some quadrants, maybe it's not super useful yet because all we've really done so far is capture the practices that people actually do in the categories and categories are useful. These look like useful categories to me. They really only become powerful when we apply them to the higher risk problems, right? That's the whole point. So let's try that. Let's look at how we might apply these categories that we have generated from the lower risk problems and apply them to the higher risk ones. All right, so let's start with interface. The interface of a framework, there we go, the interface of a framework is what's in the readme, right? It's what's in the Angular readme, the Ember readme, the intro tutorials, these are the bullet lists of features that make up most of the blog posts about picking a framework. So that's pretty straightforward. Next activity, largely the same as at the smaller scale, you can get this by looking at the GitHub project, looking at the release schedule, looking at the docs. Popularity, also largely the same, Stack Overflow content, percentage of Hacker News Ranting, number of recent blog posts. Accessibility, this one is a little bit different. Once again, it's kind of the odd one out because in the JavaScript framework landscape that we're looking at today, there are multiple frameworks out there with a sufficient interface, sufficient activity, sufficient popularity to warrant actually considering using them in production. So this is kind of what we're looking at at this point, right, Backbone, Angular, Ember, all three will do what your application needs, they're all reasonably popular, they're all reasonably active. Accessibility is how we distinguish these frameworks from each other. To make this more concrete, I wanna show you what an accessibility judgment looks like at the small scale and then the large scale. So let's go back to our interface example when we're trying to pick an HTTP library. So each of these libraries has a sufficient interface, both will allow you to make any kind of HTTP call, both actively maintained, both heavily used, but they feel different to use. And we can sum up the differences this way. HTTP Party lets you add call functionality to your existing objects. Faraday lets you keep the call functionality in a separate object. So if you come from a procedural background, perhaps the first approach will feel better, feel more natural. But if you've done a lot of object-oriented programming, then the bottom approach will feel more useful. And that's what accessibility is all about. Do you identify with the style of the code? And that's even more important when you're talking about frameworks because those will affect the code you write way more than your choice of HTTP gem. But at the framework level, it's not always as easy to untangle the framework accessibility judgment as it is with the HTTP example, but let's try. Now that we've seen what it looks like in a small scale, let's look at what it means at the larger scale. And I wanna start with a little bit of history about how Java and JavaScript have historically gotten along, which is not very well. For a long time, Java web framework land was a very sad place to be if you like JavaScript because for a while, the state-of-the-art was something called Java server faces. I don't know if any of you have ever done those. I certainly haven't ever seen them before in my life and you won't find them on my resume. But these are Java server faces were packaged front-end widgets. And they're still actually fairly widely used. They usually have some really old version of jQuery and you toss it onto your page with a little directive in your code and it spews a bunch of JavaScript into your markup and it hooked up automatically to your back-ended. You never had to write any actual JavaScript. And that was considered a feature. And that's not the only example that I could give you from the Java land, from Java land, this far away place. For years now, the Java community has put a pretty intense amount of effort into avoiding JavaScript entirely. Google Web Toolkit, anyone remember that? Write Java, compile down into JavaScript. There's more modern approaches to like Dart. So these are basically all efforts to allow Java developers of whom there are hundreds of thousands in the world, write JavaScript without actually having to learn it. However, these days we have a new contender, a new contender is AngularJS written by Java developers and featuring a dependency injection structure eerily similar to that found in modern Java back-end web frameworks. So if you come from the Java back-end world or the .NET back-end world where dependency injection frameworks are standard practice, Angular will feel very familiar. It'll feel accessible. And this is a huge step forward for the Java community because they're writing real JavaScript now which is awesome, good job. But it has a structure layered on top that makes it less risky for them to adopt because they can do JavaScript without having to learn an entirely new development paradigm. Conversely, for those of us who don't come from Java or .NET, the dependency injection in Angular feels a little disorienting at first. Fun, possibly, but disorienting. And that makes adoption riskier because we'll have to take on the cognitive load of understanding the framework in addition to just trying to actually get shit done. And of course there's a learning curve in any JavaScript framework, but finding a framework that fits the way you already think makes adoption less risky. And that's what accessibility measures at its core. It's a measure of how steep the learning curve will be for your team. So let's talk about Ember. It's got a mascot that I think we've decided is a hamster, pretty sure. It's not quite as creepy as the Go Gopher. I don't know, Go seems pretty cool, but I just can't get over how creepy the Gopher is. Like, I was looking at conferences for this year and I came across GopherCon and I was like, oh my God, that's like the creepiest conference logo I've ever seen in my life. So anyway, let's go back to our hamster. I like the hamster a lot better. Ember.js, built by Rails developers and featuring at the center of all Ember applications a router, which is a piece of code that takes any request and decides what's code to run as a result of that request. Eerily similar, you might say, to what's at the center of all Rails applications. And the concept that the routes determine what code gets called flows from REST. And REST is a relatively new, the wide acceptance of REST is a relatively new phenomenon in web development. So if you come from a web framework that matured in the restful era, like Rails or Django or any number of the others, Ember.js will feel very accessible. It'll feel very natural. On the other hand, if you come from Java or .NET or another framework that matured before REST was really a thing, then you're used to having much more control over what exactly happens to a request. And as a result, Ember may feel a little bit overly constrained. And finally, let's talk for a few minutes about Backbone.js, the granddaddy of all of them. So Backbone was graduated out of a Rails app in the 2008, 2009 timeframe. And I know it's hard to think back that far. But that was before the idea of single page apps was really a thing. I mean, there were a couple of people like doing cappuccino or something over in a corner, but we sort of ignored them. And mostly what we thought about JavaScript as was something that decorated server rendered pages. So you'd render a view, you'd assemble some JavaScript, you'd shove them down a pipe to the client. Once they got there, the JavaScript would add this veneer of interactivity over the markup. And if that's how you still think about web applications, then Backbone or one of its descendants will feel natural. It'll feel easy, it'll feel straightforward. Maybe not convenient at times, given Backbone's minimal nature, but certainly understandable. On the other hand, if you're one of these kids today who thinks about web applications as a bunch of JavaScript that runs in a browser, creates some markup and goes out to the internet to get data once in a while, then Backbone feels completely wrong. And so for this framework, the accessibility judgment flows from the types of projects you've done rather than the technologies you've done them in, as with Angular and Ember. And that is just another way of saying that the accessibility judgments that we make about something as complicated as a framework come from many different sources. And finally, on any given decision, accessibility is the most difficult of these to figure out for sure, because it's not like the Angular guys have a bullet point in their readme that says, buy Java developers for Java developers. Everyone who's building a framework thinks that they're building it for everybody. They think they're building for the general case, but they're all wrong. What they're actually doing is putting the way that they think into the code. They are codifying their own thought process. And in as much as that matches up with yours, you'll be happy. As much as it doesn't, you never know. And so I guess the question now is how do you see that besides letting me rant at you for half an hour? And it turns out that as much fun as it is to actually talk about it and to think about these things, you probably don't actually need to know what their biases are when you're making a decision because you'll be able to feel it. When you start using a framework, you'll be able to feel how well your expectations line up with theirs. So when you start using it, you just need to notice the amount of ease or the amount of unease that you feel when you're using it and make that thought an explicit part of your decision process. And remember that even once you're explicitly thinking about accessibility, it may not be always the most important factor in your decision. Sometimes you have a team that's overtaxed and you need to adopt a new technology that is as close as possible to what they already know. Other times your team is ready and willing to be pushed further. Sometimes you want popularity because you know you need to hire five people on a short timeframe. Sometimes you pick something totally unpopular and new because it just has that one feature that you know you're gonna need. But when you're making a decision, just make sure you're thinking about all four quadrants. I wanna close with something that I saw on Hacker News. Actually, I didn't have to see it. Steve Kladnik reads Hacker News so that I don't have to. Thank you, Steve. The context here is a blog post about Nimrod. Nimrod is an obscure programming language. And one of the commenters on this article talks about all the great features it has, how great the interface is, all the cool things you can do with it. And then he says, the only reason that Nimrod isn't popular is that people don't evaluate things logically. And he's clearly very frustrated. And I actually really sympathize with this point of view because the decisions that other people make really do look mysterious if you think that this is all there is to think about when you're making a decision. Nimrod is apparently failing to catch on. But it's not because people are illogical. It's because our logic encompasses more than just the one quadrant that he sees. We're up here and he's kind of down there looking at things through a very narrow portal. So even though you can't repeat the language or the framework decision often enough to get better at it, one thing you can do is take these categories and let them expand the vista of things that you're looking at when you're thinking about a large scale technical decision. And as a very wise man once said, change in perspective is worth ADIQ points. L and K invented object-oriented programming and a few other useful things that we use. And I would say with the things that we're talking about, a change in perspective is worth ADIQ points and maybe five to seven years of experience. That's all I got. Thank you very much. I should tell you I'm writing a book. If you're interested in that kind of thing, I'm writing a book with Sandy Metz taking her object-oriented stuff and applying it specifically to Rails. You can sign up there and this is who I work for. And I don't know if we have time for questions. We have time for a few questions. I can't see anybody though. So the matrix, I should call them, that's a good one. The matrix. That is perfect. It's a pun and yes, I love it. All right, sold. The question was, has my decision-making changed since I identified the quadrants? I think that where this really helps me is when I am trying to make a decision in a group. So if you're in a meeting and you're trying to talk about the advantages or disadvantages of a particular thing, it can be very helpful to just draw the four things and be like, okay, this advantage goes here, this advantage goes here, this disadvantage goes here, and it helps people visualize what, visualize more, it helps avoid the problem of having a meeting where you just talk and talk and talk for an hour and at the end of it, you're not really sure what you come up with. Have I noticed trends in the type of people or programmers that land in one part of the matrix or the other? See, people are already calling it that. That's why I know it's perfect. No, but I think I've used it a little bit to think about, when I see someone who is making an assertion that such and such is the most perfect thing, I use it to think about which quadrant are they standing on, right? It seems like most people have, a lot of people in the Ruby community, especially when it was younger, tended to be people that wanted to be where the new stuff was, and so they were more interested in maybe the interface side of what can you do with it, and they didn't care as much about the popularity or the activity or anything else. And I think that in some cases, people use this even as a reverse, right? They're like, I don't wanna do something that's popular. They may not think about that explicitly, but that's how they, their thought process is that they would rather do something where there are fewer established norms and where they get to forge some of the norms themselves, perhaps, which might be an advantage if you should accept that it's unpopular. So the question was, I'm gonna restate, you can let me know if I'm gonna restate it properly. The question is, when you have people on a team with different opinions, how do you reconcile that? Are there ways to think about decision making? Maybe I'm not restating it well at all, actually. How do you get everyone to a happy place? Isn't that the meaning of life and everything? I think that one thing that I found to help is to actually sometimes write some of this stuff down. So if you actually go through and write down, like, here's the advantages of this particular thing, here's the advantages of that particular thing. And you can also do things like, well, let's try this. Let's do a spike with this particular one for a week, and we'll see how we feel about it. And you almost need to do that anyway, right? If you're making a big decision like a framework or a data store, you need to work with it for a few days before you figure out, to get even a vague sense of whether or not it's gonna work for you. And so what I usually do is try and get all the ones that people feel strongly about and try them. So the question was, are there ways to detect things that feel great for the first couple of days and then feel terrible after that? There's a couple things that I do. One is that I, so the further you are on the adoption curve, fewer of those you're gonna find, basically. So meaning that if you are a leading edge early adopter, you can't expect to run into those things. If you are a later adopter, there will be blog posts about how shitty that thing turned after two weeks that you can find and read. But if you're at a point where those blog posts don't exist yet, what I try and do is do a project with where I actively try to anticipate what I should do and see if that matches up with what I actually have to do. And I try and keep track in my brain of like, okay, so what I was thinking was, in order to get this to work, I should pass a parameter called this. And it turns out that actually what I need to do is call five levels deep, something over here, with a different name, and I wasn't expecting that. So how much does that map up? How much do those things match up? And that gives you at least a vague feeling of, in the future, how much will things match up? All right, thank you very much.