 Small details, a big impact, and the general topic area here is it takes a lot of little details to get a product to work well, and it's actually pretty hard to ever give a talk on any of those details because on their own the details are pretty boring. So we decided to put together a talk that had a few of them as vignettes that talk about, hopefully both motivate you to think about this kind of stuff in your own applications but also give you a sense of like what kind of stuff we think about working on our product. So first of all I am Y-Cats and I work on a lot of open source projects. I don't actually know what to say about this slide except I work on way too many open source projects and I like it a lot and it's great and you probably know me from some of them. My name is Liz. I'm infinite math on the Twitter. I used to be a cartoonist. I was a cartoonist for about ten years before I got into engineering. I have something like five books published out there that are graphic novels. I just started getting into programming about a year and a half ago and I just started working at Tilda on Skylight about three months ago. So death by a thousand cuts or big things come in small packages. Every day you make a choice. Sure, your app works. It does its job. Your users are technically getting what they paid for but you can do better. We can all do better. But how? User experience is a story like a movie. You know exactly how you want it to go from beginning to end. User signs up. User logs in. User interacts with your landing page etc. Unintentional not to Kansas by the way. I didn't even think we're gonna be in Kansas City. But what if they click on something unexpected? What if they take a wrong turn? They can easily end up in a choose-your-own-adventure style scenario that you never planned for and suddenly they're on the Vampire Express to Terror Island. Weird things happen. Users end up in unexpected places. It's your job to make sure they're guided through seamlessly and they don't even realize it was a weird place to begin with. You don't want your user experience to end up being like that scene from Dune where Patrick Stewart is carrying a pug into a laser battle for some reason. You don't want that. You want to be like Gandalf riding in on a bunch of eagles to save Frodo and Sam at the peak of Mount Doom. Sure it doesn't make a whole lot of sense if you think about it too hard but when you're in the middle of it and you're watching it you're thinking yeah of course this is what happens. This is a good user experience. The first thing I want so we're gonna talk about four different vignettes and the first thing I wanted to talk about was what seems like a very small problem but before I do that I want to just take a second to talk about Skylight just so you have a context of what it is I'm talking about. This is Skylight a while ago a few months ago and you log in you get a list of your endpoints. They're sorted by a thing we call Agony which basically just means things we think are probably a good idea for you to work on. So if you have a endpoint that doesn't get hit a lot then we don't care that much that it's slow but if you have an endpoint that gets hit a lot maybe a little bit slow matters a lot so we try to combine those in a way that feels intuitive we call that Agony and then we also have these little heads up things those little red icons that mean there's some database problem or some memory problem and we try to give you some details about that. So that's sort of the experience you should definitely come by our booth to see a whole demo but what you can see on this page is that there's a bunch of numbers and actually the Agony index used to just be invisible it used to just be the way the default list was sorted but that actually sucked and people couldn't we would say it was Agony and they would get it and it would be great but it meant that it wasn't a thing you could click on to sort by it you had to we had other UI was annoying but there's this thing in the second to write column it says RPM it looks like this column here and it's like the thing you would do if you were designing this page I think the first time and basically what happened is we shipped this feature like really early was one of the first things we did and people kept saying to us like there are too many things that say like 0.01 I don't actually care about 0.01 or 0.03 those things like the same thing and like what is an RPM like so New Relic has RPM and they tell you means requests per minute and that's what it means and you can learn that fast but it is also true that the first time you ever see RPM in your life it's like what does that mean is it like a car term are they doing something with so there's this problem so the first thing that we do is okay if people don't care about difference in 0.01 and 0.03 fine we'll just say everything is less than one and we shipped that but that didn't help a lot because now there's just a lot of questions so this is something if you've used skylight you know that this is a thing that we've worked on for a long time all of our UI's are things that we've worked on for a long time but this is one that took us a lot of time to figure out what the right answer isn't that's what I want to talk about so what what should we do what's the solution so we have a really great designer so we toss the problem over to him we said okay what's what should we do to make this easier and he said well first of all your indeed RPM is not good you should not say RPM let's change that to popularity and that is great that's good and then he without looking at any of the actual numbers he just said okay we will use a filled bar to indicate how popular your endpoint is so like endpoints that are not very popular will have an empty bar and points that are very popular will have a filled bar and I we looked at this design we said ah that's pretty good that feels great so obviously we should go ship it and so so we did the way skylight works is we don't ship anything to every customer right away we always create a feature flag and because skylight uses skylight we can test it on our own app so we tested our app with the feature flag and we saw this he said okay that was a cool idea and the word popularity is indeed good but that isn't what we wanted so what exactly is going on here why did that happen so first of all this is like the thing you learned in school that there's this normal distribution things are bell curves thing most of the things are clustered off towards the center things that are not at the center decay at either side at the same rate so like a five foot tall person or sorry like a 10 foot tall person is just as uncommon as a zero foot tall person and a seven foot tall person is just as uncommon as like a three and a half foot tall person whatever the exact details are here they use the metric system here which I as an American do not know but the point the point is that this is how we think about the world and largely because physical things sort of operate this way things that are physical sizes things that are just sort of random in nature have a sort of random results but a lot of a lot of things in the world actually look like this other distribution the thing that's called log normal distribution and it's not surprising that if i show you this probably like half the room has already left they're just being polite and waiting for me to get to the next slide but this distribution doesn't look like a thing you learn in school and you probably already have enough trouble i do certainly with the thing you learn in school so like forming an intuition about what's going on here is pretty hard but interestingly this kind of thing actually shows up everywhere so the top left is income distribution the top right is the survival of egg to smolting ratio bottom left is population size in a city bottom right is commute distance from your house you can see wow these things all look the same that perhaps is surprising and if you go look at your skylight endpoint you'll see wow that actually looks also exactly the same and in fact it is so calm this is so much the case so this distribution is called the other one was called the normal distribution or bell curve this thing is called the log normal distribution and it's so much the case that this is common that there was a performance company that got bought by sosta whose name was literally log normal right so the intuition that everyone has about bell curves is so wrong that this company called themselves log normal just so like make that point so what's going on here what's going on here what's going on here is that you expect and our designer expected that we're talking about at bell curve but we're actually not right so you thought oh well you know if we just put the amount of popularity on the graph then you'll have a bunch of things towards the middle and you'll have some big ones and some little ones but that's not actually what's happening so just like anything else that's not what's happening so this doesn't end up working out so the first time somebody encounters this I think people learn this problem they say oh well there's a obvious solution to that problem my phd friend in statistics has told me the solution which is that you should just take the numbers and you rescale them in terms of a so I said it's log normal so you use a log scale and you can rescale them and that that works right now you you have uh popularity in terms of a log scale but there's a bit of a problem here which is that this person is going to think reasonably if something is if the bar is twice as big that probably means there's twice as much popularity and the reason that they think this is not an accident it's not something that they have gone to school to learn it's a thing called pre-attentive visual processing pre-attentive visual processing is how most people process most things the first time they see it and here is a couple of examples so the the game of the game here is one of these things is not like the other and if you look at the left the left image here what you'll see is that there it's very easy to notice that the red circle is red and that's because there's a very strong visual visual variable and there are certain visual variables that are very powerful that human beings understand instinctively the right side has also you can eventually discover that the circle is there without engaging the logical part of your brain but it's a weak visual variable it's harder to see similar story here one of these things is not like the other on the left side it's quite easy you there's one variable it's is this thing filled is it empty that's a pre-attentive variable we get it right away on the right there's just no distinct feature so it's actually hard to understand what it is that you're looking at so again this our friendly emoji user says double the ink means twice the twice as popular obviously and he thinks that because physical size length of things is a pre-attentive variable and you're just not going to fight that there's no point in fighting that so don't even try to switch to logarithmic scale even though you're a phd friend who turns on the logical part of their brain may be able to fight the pre-attentive system in their phd work the human beings normally do not and you nobody signs up for scythe to get a lesson in statistics so this just doesn't work so what did we end up actually doing here we ended up going with this triangle thingamabob and we didn't invent the triangle thingamabob a lot of systems that have similar problems do it and interestingly a thing that you'll notice is the antenameter is also a weirdly shaped thing and if you actually if you try to ask os 10 like i am a power user and i know the magical incantation where i can hold down alt and click on the thing they still give you a number that like no human can pre-attentively process incorrectly you like have to google what that means there's no way that you could get you could try to figure out what that actually means and in fact the whole reason why decibels exist in the first place is because noise is one of these weird distributions and if you try to tell people oh think about noise in terms of how many jewels it is or something like that that equivalently doesn't work so these problems are all pretty similar and the canonical solution to this problem is the is the weirdly shaped shapes and the reason for that is that people don't don't have a good job don't do a good job of identifying how much area weirdly shaped things have so the pre-attentive system simply doesn't kick in it's it by the time you start thinking about it it's already too late the pre-attentive system has no idea what's going on and now you can make it mean whatever it is that you want so yeah people don't know what's up so we went with we went with this and the cool the cool thing about this is that in addition to the pre-attentive system not kicking in and doing the wrong thing here people are used to this antenna meter meaning like if it's twice as big it means like twice as signally which doesn't mean anything so popularity actually turned out to be a good word it means like twice as popular but that doesn't really mean a lot and so using this this icon that has a general purpose meaning as doesn't mean a lot hand wave hard to say turned out to be the right thing so being that skylight is a rails profiler with a customer base of mainly developers we wanted to give our users the option of signing in with github this would add convenience for our customers who are probably already signed into github anyway but it would also position us to take advantage of the existing concept of github organizations and their related permissions instead of having to come up with something similar on our own later on most people are familiar with the experience of signing into an app using authentication from some other application like facebook google or whatever you just click sign in with github you leads you to an interstitial page where you authorize the application and boom you're signed in and return to the app fortunately most users will enjoy a seamless experience everything will work as it should and all will be right with the world that said we still wanted to account for the rare not so happy path well first of all what is the happy path well the least ambiguous way for a customer to connect their existing skylight account to github is to first sign in with their email and password then head over to the account settings page um and just click the connect to github button the customer will then see the connected account information their github username and then they can easily sign in with github going forward a common issue that we noticed when we were looking at other apps that use oauth sign in is that it's really easy for a user to not actually remember if they signed up with an email password combo or oauth or both speaking for myself i usually forget as soon as i sign in uh by displaying the information right there on the account settings page we're sort of aiming to mitigate that confusion if for some reason the github account you authenticate with is already connected to a different skylight account we'll just let you know in like a message bar at the top of the screen so how about the edge cases what about people who already have a skylight account but it's not connected to github yet and they click the sign in with github button in this case we redirect the customer to an interstitial page with an email form uh field pre-populated with their email address that we get from github uh we focus in on the password field to prompt you to sign in uh once they're signed in we just connect the account to github automatically so they can just go forth and sign in with github to their heart's content uh but what about people who already have a skylight account and they click sign up with github obviously we don't want to sign them up for a new account or treat them like they're new here uh so even though they've signed uh they've clicked sign up instead of sign in we treat them as if they're signing in we just logged them right in but since they did click sign up after all we should just check to make sure that they're the right person after all it's totally possible that they really do mean to sign up but their co-workers signed in to github on their computer and we're logging them in as their co-worker so in this case uh we just kind of casually make them aware of who they're signed in as at the top of the screen uh with this helpful welcome message if they're not that user they can just sign out and sign back in with their own uh github account so if the customer already has a skylight account but it's not yet connected to github and they've used the same email for both uh clicking sign up with github will lead to the same interstitial page but with a little error message at the top that just says you know that email's already taken uh again all they need to do is sign out of github sign in with their own account and it'll be fine so this meant that we had to implement oaf oaf is easy right sure let's say sure there's even a super simple gem called omnioth github we can use however there's a problem there's always a problem right github's oaf configuration allows us to supply one redirect url this is how github knows where to send a user once they're authenticated it doesn't know the difference between a user who's signing up versus signing in versus connecting their existing skylight account so suddenly it's not so simple we had to figure out how to deal with all the different roads a user might go down and account for how the user themselves might expect it to go as you can see from this chart that i made uh that i drew myself so interstitials are terrible i think we can all agree on that right just think about all the times that you try to visit a website on your phone and you're forced to click through some nonsense interstitial that's trying to get you to download their app you don't want to include these things unless you absolutely have to an interstitial page can easily be that patrick stewart in a laser battle holding a pug thing that we're trying to avoid here so how can we begin off how can we make this sort of incongruous thing feel as natural as possible we thought long and hard about it before making the decision to include these interstitial pages and we only included them once we realized that we were making a choice between a potentially awful experience for a small amount of users or a slightly awkward one for maybe a lot of users um we don't want people who mean to sign up for a new account to be led off to someone else's account with no explanation right we certainly don't want people accidentally creating duplicate accounts all over the place we don't want to assume that the person who's logged into github is the same person trying to create a new account especially when we can just check and let them know um at the same time we don't want to replicate the typical terrible interstitial experience so we spent a lot of time thinking about this anything we can do to create less work for the user is what we should do if github is passing us an email address and what we want is for the user to sign in to their existing account just put it in the email field if we want them to enter their password focus on the password field just make it easy for your users be Gandalf so let's talk about rust uh so we use rust at skylight and it's probably easy because a lot of people do this to think oh they probably use rust because it was like a cool technology and they wanted to have an excuse to use it but actually uh when we started using rust it was not that cool of a technology and um it was pretty scary it was still pretty new and we had a pretty good reason to use it so what is the problem that we're trying to solve with the agent so obviously in order for us to give you information about what's going on in your application we need an agent that collects the information and sends it to some server that is processing it and producing those nice reports so how does that what is the the problem here the general problem for the agent is that we want to instrument your uh your application efficiently but efficiently really is a pretty important thing here if you install an agent that is supposed to detect why your application is or slow and it makes your application slow we probably have automatically failed uh out of the out of the gate so it's pretty important everybody who builds these kinds of things cares a lot about making sure that the agent the agent itself is not really impacting the performance of your application so what what possible solutions are there to to use the most obvious solution and this is what basically everyone does including us out of the gate is to write it in ruby um the nice thing about ruby is that ruby isn't is a safe language and it's already a language that by definition you have in your app because of your Rails app and we can catch it we can be careful and catch exceptions and uh the likelihood of something going horribly horribly awry is is pretty low if we're careful so write it in ruby is one option and it works pretty well to collect the baseline information like how long it took to render a template unfortunately ruby itself is a pretty slow language and that doesn't mean it's intrinsically slow uh for everything but if we're trying to collect a lot of very fine-grained information it may end up being slow and in particular a thing that we really wanted to do that we do now is collect information about how many allocations happened in a particular area of your application and those are fine-grained areas and that really means we need to hook into every single allocation ruby has a nice friendly C API for looking into every allocation um but so should we write it in C should we write the part of it that hooks into every allocation in C and unfortunately the thing about writing things in C is that we're asking you to take our program and put it into your application and if we just have to write anything that is performance critical in C there's a pretty good chance that we mess up somewhere and take down your application so um I think we were pretty nervous we have some C now but we were pretty nervous about like just saying oh from now on everything is written in C I think every even the best C programmers like the C programs that write crypto libraries occasionally mess up and have massive vulnerabilities like heartbleed right so it's hard to get things right in C um another option would be write it in C++ but actually C++ isn't that much better from the perspective of like am I really sure I haven't messed up and caused the application to crash so we had a prototype in C++ that I think probably we might have shipped um and it was it worked but I was personally pretty nervous about like how many people on our development team would be able to maintain this thing so the thing about C and C++ is that it's actually pretty easy to write a program it's your C++ that compiles runs you run your tasks everything's great and then boom you uh have a segmentation fault and now a lot of your users are angry so uh if it's your own segmentation fault in your own app you'll probably anger at yourself but if we tell you to please install our agent and all of a sudden your entire Rails app starts crashing uh you will probably be very upset at us and slow is better than angry users so uh and in this case slow doesn't mean the agent was slow it just meant we couldn't add features like the allocation tracing stuff that we really wanted right so so slow is better than angry user but unfortunately slow means we can't ship the features that we that we want so what sort of happened around the same time that we were exploring the C++ uh story is uh Patrick Walton from the Rust team wrote a blog post that said like by the way we previously thought that a garbage collector was a pretty important thing for Rust but what we recently realized is that the ownership system that Rust came up with is actually uh generally better than than the garbage collection story for systems programming for C programming and um we're gonna get rid of the garbage collector he said this in like august or september or something like that and i happened to come across that blog post and like in october i said okay we're gonna i'm gonna see if i can take apart the hot spots of our application uh specifically the serialization parts part serializing the trace and send the server i'm gonna see if i can turn that into rust and i took like a couple weeks and did it um and so we ended up going with rust i ended up being able to uh ship a pretty uh a productive uh little slice of our application we didn't rewrite the whole agent and we never will the a big chunk of our agent really does want to be um something that hooks into ruby at the ruby layer but we we basically we got to a point where it was clear that we could take hot spots of our application rewrite it and rust compile it ship it to ship it as part of our gem and be very confident that it wouldn't crash and in all the years that we've now been shipping rust we've never had a crash uh segfault in the agent that was attributable to our code at all so that's actually pretty great um and that's something that maybe you might find surprising and it is actually just a fundamental characteristic of rust that um unless there's a bug in the rust compiler and a bug in the rust compiler is basically like a bug in ruby like a bug in ruby could mean that your ruby program segfaults but that's not your fault um and if some if you install a c extension in ruby and there's a bug in it and it causes segfault that's also not your fault that's the c extensions fault um and the similar story in rust if you write uh if you write rust code and it compiles um it has the same story it's a safe language just like ruby um and so the idea is if it compiles it can crash and i would definitely recommend that you take a look this is the rust 1.0 blog post and so we talked about um in the blog post you talked about stability in general about rust being a stable language we talked about community which is a pretty important thing for rust but we also talked about these four things uh memory safety without garbage collection concurrency without data races abstraction without overhead all of which sound like contradictions in terms and which through very uh simple primitives that work pretty well um rust ended up being able to allow you to say if it compiles it won't crash um and really what it comes down to is um in rust you can write low level code that you know is efficient without fearing that you'll crash and probably for your own application in 2013 was not the right year to do it but for us um writing fast code that also we were sure couldn't crash was like a core business value that we needed to figure out how to do so you know rolling up our sleeves and getting into the swamp with whatever rust looked like back then uh was well worth it um and in fact allowed us to ship the allocations uh the allocation trace feature and make our our our agent small uh at a time where perhaps people didn't realize that that was possible uh tomorrow godfrey is giving a talk uh chan can code on helix which is our uh we're open sourcing a binding layer uh between rust and ruby it's pretty cool he's gonna talk about it and you should definitely go check it out names let's talk about names names are really important just ask anyone with a name more complicated than jane doe getting someone's name right is a sign of respect when someone introduces themselves to you for the first time most people will at least try to make sure they're pronouncing it properly and if you're the one introducing yourself you can pretty well guess that someone who doesn't put in that effort probably is not worth your time but let's go a little deeper people change their names or they go by names that aren't the same name on their government issued id uh but they still need billing and other official documents to be addressed to their legal name people change their names for all kinds of reasons uh sometimes they're fairly innocuous ones but sometimes they're more serious um there are situations when which calling someone by their legal name instead of their chosen one can present an actual safety risk for them but keeping that in mind respecting your customers alone should be enough of a reason to put some effort into calling them the name they want to be called i've been called Liz my entire life so the minute i pick up the phone and someone on the end says oh is Elizabeth there i know it's a sales call i hang up on them a lot of services will take your full name and nothing else and then every few weeks you get an email that awkwardly addresses you with like greetings Elizabeth Bailey i literally received this one while i was putting this talk together so of course these services mean well but it's awkward it's the Patrick Stewart holding a plug thing again it takes you out of the experience not only does it take you out of the experience but it also makes your service seem really disconnected and robotic no one wants to read an email sent by a faceless corporation most people will delete that email without even reading it if your team is anything like ours you're hardly a faceless corporation you're a bunch of people who really care a lot about your product and its customers so how do we avoid this problem how do we handle names when customers sign up for skylight we used to ask them for their first and last names and nothing else and then we would address our emails to their first name this works well enough in most cases but again what about the edge cases well as it turns out they're not even really edge cases more than half of our own company actually goes by a name that's not on their driver's license so it's not that uncommon for someone to go buy something other than their legal name so it really makes sense to design for this case in point we have a large number of customers signed up for our skylight emails which are sort of quick little messages we like to send out once or twice a week giving updates on our progress on various features uh what conferences will be uh things like that we don't want to alienate our customers right away by calling them the wrong name they might delete the email before they even get to the sweet dog gif in our case we opted to swap out the first and last name with full name and nickname so pretty much all correspondence now is addressed to the user's nickname but we still have their full name on file for billing purposes and other official business if we need it for our existing customers we just concatenated their existing first and last names for their full name and we use their existing first name as their nickname but we wanted to make sure that we kept track of who chose and confirmed their own nickname and who was just assigned their existing first name as a nickname we did that by adding a simple boolean field called nickname confirmed and just marking it false for all our existing users whoa uh yeah this is all well and good but this it's how we handled the UI uh that at the this is all well and good but it's how we handled the UI for this problem that really gets to the heart of this when a user signs up for skylight for their email address we start by trying to guess what they might want to be called based on what they enter as their full name and warning there are actually some like 10 year old doctor who spoilers in the following gifts so we don't just assume that this is the case and we move forward we ask the user can we call you that if they say yes we mark their nickname as confirmed and we just call them that name from there on out but we don't uh yeah if not all they have to do is click no and they're they're prompted to enter whatever name they'd prefer to be called so once they're signed up we mark their nickname as confirmed as well but I warned you um what about people who don't want to enter a nickname or they just don't for some reason they just don't enter it uh when they sign up we'll continue to use whatever we think is their first name we'll keep their nickname marked as unconfirmed so what do those people do if they decide that they do want to change their nickname from what we guessed for them well all they have to do is go to the settings page and where it says can we call you that just click no if the user hasn't told us yet that it's okay to call them jack uh we just make sure to ask rather than assuming they'll get the same opportunity to enter their preferred name and save it and now it's marked as confirmed so we know not to ask again so let's say you saved and confirmed your nickname we'll assume this is okay uh you can notice the subtle difference in wording we'll call you versus can we call you um but let's say you need to change it something else it's easy you just go back to the settings page and right where it says we'll call you that you click change then you can just go ahead enter your new nickname and save it done if they haven't set up their app yet and they get this screen when they sign up we have roughly the same interface set up here we greet them by the name we have in our database but if they haven't confirmed yet we ask you know can we call you that and they can either accept it uh whoa why does that keep happening I don't know where I am so we're here um yeah so we call them by what we have in our database but if they haven't confirmed it yet we ask can we call you that and they can either accept it and change it right there or you know they can do it on the settings page later on uh this is also if people sign up for github uh sign up with github they get directed to this first they never get a chance to enter their nickname so this is actually a great catch all sort of for people who sign up with github as well uh so for the technical implementation we had some interesting challenges some of the apps interface is uh in Rails views while most of it is an ember uh the sign up page is a Rails view so we tackled that first when I first learned a program I learned Ruby in Rails first I only knew a tiny bit of JavaScript when I started learning ember and then I found myself working on a number of ember applications that just used a Rails API so I was almost never in a situation where I need to write straight up JavaScript for a Rails view uh when we were initially working on this I worked on it largely with my pairing partner Rocky and we had both just started working it till that I think that week um so we're both new to working on Skylight Rocky was new to Rails I was new to straight up JavaScript um and we you know we found that our you know weaknesses and strengths sort of complemented each other um so yeah since I never built an app in plain JavaScript with jQuery before like Rocky had I had no idea how much easier ember actually made things we needed to use debounce in order to give our users a little breathing room while they were typing out their names so we would be sure we wouldn't display anything until the user is done typing so without debounce the experience would be a lot choppier they'd see every single character on the screen is they typed it which is like super not graceful not elegant at all uh it's certainly not something we want so something so seemingly simple um it's actually I found not native to JavaScript uh it turned out we actually had to write our own jQuery debounce plugin after scouring the internet for a solution we ended up basing our plugin on a blog post by Dave Walsh that worked really well for us uh something else I was unaware of is that some methods like trim are not accessible in all browsers so we had to polyfill javascript string dot trim method in case we have a user who's on one of those browsers uh this method is important because we want to make sure we're removing that white space surrounding whatever name the user enters so we can be sure it displays properly a lot of apps don't do this right or at all uh which is really frustrating as a user I can't even count the number of times I've tried to log into an app and I was told oh your email's not valid your email's wrong I know this is the right email oh it's a white space at the end of it it's so annoying um so yeah overall when it came down to I think this is not gonna let me do this no no oh god okay it keeps keeps going forward for example you can type umd to move your speaker notes up and down and you know it worked when I practiced it this did not happen to me when I practiced it overall when it came down to names we really put a lot of thought into making sure our users were being addressed by the name that made them feel comfortable and we tried to find every opportunity to make sure we're getting it right so they can change it as soon as possible so uh in closing uh when you're building an application the little things really matter um this is something that uh this is something that you can lose in the technical work it can you can spend a lot of time on like what JavaScript library to use for this or that thing or what auth library what uh you know how to this you are going to structure your migrations but at the end of the day you're building a product for our users and um like Liz said in the beginning when you're building an app it's kind of like a movie you're building an experience for users that's how you should think about it um you really want your users to have a really good experience and like a movie uh making an amazing like like in the same way that making an amazing movie requires a fanatical dedication to every detail I I am often inspired by the fact that if you look at stories about Pixar movies Pixar uh animators will say like I spent 30 days on this 30 frames that only lasted like one second but we really wanted to spend every little second to make it right and I think there's a really big difference between uh the end product of applications that's that take the time to get these little details right or movies that take the time to make sure that the expression on his face is exactly right at this moment for 30 frames or 40 frames um and the opposite right you can you can make the decision to not care it's easy to say ah that whole name thing that we just discussed doesn't matter or that whole all thing like why does it even matter we'll just do it's fine there's one redirect URL we'll just use that to mean which is just one flow but in fact uh the user is experiencing something you're experiencing they're experiencing the experience that you have put together for them and it's worth taking the time to think about what they're experiencing at every step it's worth taking the time to say uh if the user press the sign up with github there is a difference between whether the account exists with this email or not uh the experience that a person should have is different or like Liz said before the subtle difference between can we call you jack or we'll call you jack depending on whether you actually took a step to confirm your email it's very easy to say uh that doesn't who cares but i think as a user you know that there's a big difference between applications that always say yes to that kind of thing and applications that always say no applications that always say no just always suck um and it's very it's hard to say oh we'll say no we'll say yes some of the time i think you have to have an attention to detail and take the time to get the little details right so uh Liz talked about this earlier and i wanted to reiterate um this is just a taste of the kind of stuff that we we do at tilde we have a let's say twice weekly email but that's a lie a periodic email that we try to send out twice a week um we used to say daily but that really didn't happen um we have an email that we send out where we talk about stuff like this uh basically every engineer gets assigned a day every couple weeks and they write what they worked on what things were hard uh what details they spent time on that day and i think it's really pretty great and you should sign up for it um you can sign up for it uh you have to make a skylight account to sign up for it but you can sign up for it with a free account and you never have to pay uh pro tip so uh just make an account um and you can get access to the to the daily email we used to call a daily email to the periodic development journal frequent emails uh like a lot of people sign up by the way it's we have like when we started i said i wasn't sure what would happen like maybe like six people would sign up but we have like i don't know hundreds close to a thousand people who receive it every day or whenever we send it out it turns out uh now and i think that's pretty awesome i would also like i think if you haven't if you have the ability to do something like this for your own company the world is a better place when people talk about how they work so uh thank you