 I'm also setting my coffee down. So before I get started on the talk part of the talk and the intro part of the talk even, I just want to say that this slide does not refer to veterans. Members of our US military serve for our right to have a voice even when that voice is against the country that they serve, and that's pretty awesome. So since I'm up on stage, I just want to say thank you to our US veterans and whether they see combat or not, they put their lives at risk when they enlist. And so thank you. I am honored to be in a community with those who have served, and thank you very much. So this does refer to everybody else's butt, especially mine since it's facing the goat. But this should surprise no one that I have a, I do have a little bit of a content warning, which I will occasionally use so-called curse words, at least on my slides at the very least. I did my grad school work in English just up the road at the University of Cincinnati. And so I do have a healthy respect for language and words, and I don't mean to offend anyone when I use them. And I hope you still get takeaways in spite of my horrible language. Okay, so I know you folks came here for some kind of a talk involving goats, but I'm going to start with cattle, or cows as their colloquiality known, regardless of gender or whatever. I know all these things, so it's just too much. So I was doing a road trip last month through Washington, Idaho, Montana, and Oregon. In fact, I got the call about this being a keynote while in the hills of Montana. The phone actually cut out, so I'm like, I think I'm a keynoter, but I don't know. But in any case, we saw a lot of cows, and we'll just skip to the end. I decided I wanted to pit a cow. So I found an accessible field, and I got onto the field, and I discovered that these were not the lady cows designed for milking that I had thought that they were. So there I was, surrounded by cows with my friend filming me. And I got off the field slowly, and later at a diner I did what we all do, which is Google for information about what all these cows were up to. And I found out some information that just kind of blew me away, and I thought, oh, good, I'm going to be on a big stage. I get to share this with everybody. And so you have to hear about cows. So you don't know what you don't know. And what I did not know, and maybe you two are in this camp, an ox is not an animal unto itself. Did you think an ox was an animal? It's not. It's a role. No animal is born being an ox. I had no idea. I played Oregon Trail my whole life. The oxen were pulling the wagon. I had no idea that an ox was not an animal. It's a role. It's a cow that is trained to be a draft animal. And by cow, I mean, again, all the genders. But your lady dairy cow, she can be an ox. But no one's born an ox. That's just crazy to me. I had no idea. So even, hopefully this is news to you. And so even if the rest of this talk does not go well, you now know about that the ox is not an animal. Don't spread that rumor anymore. But don't worry. Even if this is not news to you, I'm totally going to use a horrible analogy about this later. Spoiler alert, it's going to have to do with you being able to be a cow, a code cow, and you can still do the ox's job of being a documentarian while you are a code cow. So that's awesome. But frankly, I'm still pretty blown away by this information. And now you know. OK, so my name is Tara Scherner Delafonte. You do have the empathy of a goat. And I will be talking about documenting with the user in mind. I am a software engineer at Roostify, which is a tech company based in San Francisco. We're making mortgage buying awesome. No, really, it's happening. I'm part of it. And I work for my home office in Portland, Oregon, by home office, I mean in my living room with my cat. And my Twitter handle is media remedial. That's back from when I did more things with words. And I want to point out it's not on any of my other slides, because a lot of the images and content aren't mine, so I don't brand them. So if you want to tweet, go wild. But that's where it is, up there, media remedial. And then speaking of animals taking on roles and that sort of thing, when I'm a goat, I tweet at goat user stories. And I do have stickers that look just like that, by the way. Also Roostify stickers, I put them over there for after. If you aren't familiar with goat user stories, I do a traditional user story each day at 10, 20 AM Pacific, actually. And it is the traditional format for a user story as a user. I want to so that. And my user is always a goat. And so sometimes it's serious, sometimes not. Sometimes goats just have problems they need to share. So that's what that's all about. OK, so the user and documentation. I'm going to make up a statistic now. Let's say, as developers, about 80% of our job is working with tech. So documentation should not be as avoidant worthy as it tends to be. But I mean, even with my sort of over-degree English person self, I don't want to stop building things and solving problems to do documentation. So what this talk is sort of geared toward is talking about good documentation that's built into our processes. So it feels less like putting on the yoke for oxen reference and just kind of building that into our dev process. So first, I want to talk about the user. And this part is nothing new. The user is in the mirror. It's especially the user. You the user, three weeks from now, five weeks from now, when you no longer remember that awesome code that you built. The user that I'm going to talk about today is future us, your fellow developers, those on your team, those elsewhere in your company, other developers who are using your code, managers, stakeholders, and clients and customers, but really the folks that you're usually interacting with on a day-to-day basis. And the reason we have jobs. So then the documentation puts some examples up there. Homegirl's not going to talk about this kind of documentation, like formal documentation. I'm homegirl in this example, by the way. I say that about myself sometimes. I forget that's not natural language. But in any case, I am not going to be talking about that formal kind of documentation. Again, I'm talking about the documentation in code, in Git commit, in PRs, in other types of documentation that we actually run into and actually read and use on a daily basis. I love this image. I send this image to my friends when they are promoted into management. And you can already suspect why. But I do. I congratulate them, Mazel Tov, on moving into management. I'm Jewish, so I say Mazel Tov. But you can say it too. It's awesome. And then I'm like, here's your box full of meetings. And this is how I view things. So no matter what Rubyists tell you, comments in code are not the enemy. I know that's horrible to say at RubyConf. But it's true. Meetings are the enemy, at least in my opinion. And it's my talk, so that's what we're going with. So good documentation is not only empathetic to the user, but it helps avoid meetings, which is my goal for you. So if no one has to ask you a question about why you did something, in what way, how the behavior changed, you get to keep coding and building the fun things. And that's the goal. So we're paid most of us pretty well for our knowledge, experience, and ability to kind of code fast, hopefully. Writing good code at a good pace is one of the ways we earn our keep. And then another way is by clearly communicating what the user needs to know. And so that they can use their knowledge and do the next thing, whatever that next thing is. So if you're on a team, that's what you need to be doing, even if your team is only you and future you, which I particularly thought about yesterday during Matt's talk, when he's just 1993 and he's the one user. But it was also future Matt's was also on the team. And I have purposely resisted asking him what his documentation was like back then, because I didn't want my thesis proved incorrect before my talk. I'll ask him later. But in any case, even if it's just you and future you, documentation is so key because it can help speed you up and keep you coding rather than explaining or under explaining when somebody needs to go. And that's the two sides of the curse of knowledge, over explaining and under explaining. Neither serve you well. Both are going to have you ending up in meetings. So if you assume that most of the people reading your code all know the underlying concepts and the tech details, you might have the empathy of a goat and not in a good way. Let's say they can read the code and know what it does. Even the best code cannot explain why it's there and what it's doing there. If it's unusual, if it's implemented to solve something surprising or it behaves in an unexpected way, understanding the code, being able to read it, isn't necessarily enough. And we're already users of people's documentation when we're coding. I mean, does anybody get through their day without googling? I do not. But the kind of stuff that we benefit from when building the code, that's the sort of documentation we should be contributing and what I'm hoping to encourage you to do. So if we document things, maybe we save other people time and it doesn't have to be redocumented. And maybe you save time and perhaps ideally have fewer meetings. So the flip side of the curse of knowledge is over explaining, which I may have done with livestock earlier, but it's too late. An overwhelming amount that no one can hope to parse out or need is one of the curses of knowledge that we get to. But it's at least a start. And I will get to how to recover from over explaining unless you're doing a talk. So the first thing that you have to do is find those user stories that I mentioned about the goats earlier. And while I was looking for an image for these slides to prove the actual point I made, I found all kinds of inspirational quotes on the internet. That's no surprise. And this is one of the quotes. And then the image was sort of funny, even though it's blurry. If you only focus on the problem, you might miss the easy solution, which sounds totally logical, right? But what if getting out of the crate is not the cat's problem as far as it's concerned? What if you just assume that the solution is just hopping out of the crate? What if the crate's just missing a blanket? Or it's trying to stay away from a mouse? Or a toddler? Or something? So you need to start, certainly, by identifying your user, who again might just be future you. But then you need to identify with the user. And one of the best ways to do that is to focus on the problem, not the solution, just in case that was not clear. So one of the most valuable things that I ever did as a developer was to watch an end user. In this case, it was somebody internal to the company. And what the user wanted was a solution to a CSV loading problem. Now, if you have ever worked with a CSV loading problem, you know that I could possibly solve that one. But there will be another one. And so focusing on the solution and what the user wants is not really going to help me very much. So I watched her up. It was a salesperson. I watched her upload the CSV and show me all the hell and damnation that happened afterward. And I watched her. And it just was sort of blown away. She was showing me all the things she had to do just to sort of leave out tons of details. There's dates and times and other things on the CSV. And they're also supposed to line up to other things that are already in there. And if they're not in there, she has to use a pull-down list and find the thing and line it up and oh, God, it was awful. And so I'm looking at this. And obviously there's a CSV loading problem. And that's one of the problems I'm going to deal with. But what I found is that every time there's an error, she has to go into this pull-down list. That sucker was not even sorted. It was not sorted. So like there's like 50 dates and they're looking for something on December 17th at a certain time. There's a bunch of December 17th and then there's other dates and then there's more in December. Oh, God, it was horrible. And then she had to do it twice in each one. Somebody left an equal sign on the view page. And so the poor woman had to go in there twice and fix that. And she didn't even care about that. That wasn't even the problem she cared about. Moreover, she'd fill out all these things and there'd be more problems on other pages. She couldn't save the one page and move on to the other page. And she didn't even consider that a problem. But those were, I could totally fix those real quick. Like less than an hour, we'll have that pushed up. And at least when you have a CSV loading problem, which even if I fix this one, you're gonna have another one. Now she can save the things and all the things are awesome. So if you start with what they want or the solution, you could miss improving somebody's life exponentially. Each time something goes horribly wrong. So if you can watch the user, even if it's a fellow developer who's verifying that your code works as expected, that's so helpful to know not only about code design, but about what you might need to explain, either in the code or in a Git commit or something to explain some unexpected behavior. If you can ask a product manager to screencast somebody using the app that you're building, so much the better. And you'll find out what questions everybody has and find out what information you need to convey. If you can grok, if you can be one with the problems, you'll be that much more alert to empathizing with the user. And oh God, saving that poor woman from all those horrible pull downs. Oh, it's awful. So I hesitated to bring up commenting in code to a bunch of rubies, but I'm gonna do it. It should be easier to grok with a coder and there are possible problems, but old code is old English. And it's not right for every project, but if you've got some kind of method, say that you're putting into your code, and maybe it's gonna be short-lived or it's relying on a particular version of Active Record, and it's something that perhaps somebody could remove in the future. And this particular comment, it is an actual comment from code, including line three, which by the way, this was only like three lines, but I had to bump up the font and all that kind of thing. God bless Sam Livingston Gray who writes the best comments in all of development that I've ever read. So it clearly explains why this method exists and it tells you what exactly it's trying to accomplish and why it's trying to accomplish this. So if you come across this comment right in code, and it's like we're in Active Record four now or whatever and this is no longer an issue, maybe we can remove this method and make things work traditionally and then remove that, maybe leaving line three because it's funny. But this is the kind of thing that you might wanna document in code because this isn't about how the method works, we can read how the method works, but why it exists in the first place and can easily be removed later, you're not gonna think, especially I was in an app that was several years old with tons of developers in it, I'm not gonna think, hey, this is an unusual method, I should look and see what the original commit said and what all the information is. Probably it's been refactored and changed over the years and probably nobody would bring the information across through all the commits. I wouldn't, I'm lazy. But if it's a comment in code, it's accessible, it's right there, it's potentially short lived if that problem goes away. So these are great things to comment about in code. So you wanna explain the why and now I wanna talk about commit messages and I am going to cover the rudimentary parts because why should we assume that everybody knows some good practices? If you don't have a traditional, like I do this for my commits every time, maybe you could, which is great. So you wanna explain what, you wanna explain why, how is more like what you talk about over beers later on. But in a great commit message, you want to again cover what the perfect code cannot explain and so some practical things for a commit message. Just gonna cover this, I know this is review for a lot of you, but it'll be real quick. So the first thing right off the bat is your first line of your commit message. This is gonna appear in your get log one lines and it starts with a capital letter. It does not have a period at the end. It's less than 50 characters. Skip a line, this is very important. And then explain the what and the why. Discuss anything unusual. If again, if baby seals are gonna be clubbed, if something has changed, note that. That is important. It's very helpful. If there is, if this is unusual thing and you found documentation, yay, about implementing it, include a link. You can include little bullet points with the hyphens there. If you've got an issue that you can link to with a Kanban board, include that. I will say, don't rely on auto magic services. If you can have a direct link to something, that's good. Okay, so we're moving on from that. I know that's review for a lot of you, but a good commit message, this is part of like documenting as part of the dev process. So I mean, a good commit message does not take all that much time and this text can be copied later and it's awesome. So let's say you're not that ambitious. One thing I didn't cover on the last one or the last slide is the form, like the tense. There's an official name for, I think it's like imperative or declarative or something that you're supposed to put these in. I just always think this commit will and then what follows is the commit message. But you can do git commit slash m, that's for message and put it right in there without any explanatory stuff. It's kind of sad, but that after style, that why style, I sort of think of that as a condensed user story. So if you can figure out your user as a user, I want to do something so that like maybe the user wasn't enabled before. So that's important, now they can do that. Maybe they couldn't have, they couldn't use a goat message before. Now they can. What's changed and why? That's sort of encompassed. This isn't a great example, you can do better. It'll be great. So that's the sort of thing you wanna do. And then if you have done a good commit message, well, if you use GitHub and use it for PRs, it will all translate up onto GitHub if you've done this well, especially that line skipping thing. It'll be up there and then you can address it more with like company specific things that you do, maybe you do some of that auto magical stuff. One of my last companies we waited till we were in the PR stage to add who we paired with, which kind of documents non-driving work and gives credit where help was given and that sort of thing. So you can add some different things. And again, just the whole idea is to make documentation just an automatic part of the experience. So ideally you are crafting code that is easy and obvious for the user to use, but it won't be obvious to everyone. Maybe it's not, right now I'm at a company where we do a lot with compliance and security because it's the mortgage industry, banking industry. It's really important. So a lot of the documenting we do, we have to explain through audits what we do and why and we have to justify the changes that we make in code. So sometimes I'm writing this for a security person or a financial person and that's important to consider when I'm writing these commits and these PRs. You have your own context and users that you're writing for. So it's not gonna be obvious to everyone and if you want to avoid meetings like explaining to the security person why you made this change, document what changed and what. Comments are not the enemy. Documentation is not the enemy. Meetings, if I have not been clear, are the enemy. So you want to comment where necessary and helpful and write a great commit message. Depending on what needs to be written you may be self-conscious about some of your writing. So you may need just some practical writing tips. I have that for you. I know, you're excited, I can tell. Everybody loves this documentation. So this is an excerpt from Anne Lamott's awesome book, Bird by Bird. She does write about writing and this is a quote from this excerpt which is almost all good writing begins with terrible first efforts. You need to start somewhere. Start by getting something, anything down on paper. So if you're one of those over-explaining folks at least you're getting started and I want to reiterate that I'm talking about anything you might feel self-conscious about writing and that includes commit messages, stack overflow answers, a lovely rake task that makes lives better, a read me, I don't care what. If you're unsure about even getting started just write a shitty first draft for the love of all things, holy. The hard part is getting that first draft down but the first draft writer is the unsung hero. The best writing is rewriting, we know that. So you can be, you can let the rewriter get all the glory. You will be a hero to the rewriter. If you just, you know, just put it down there. They will know how awesome you are for having a place to start. So just take the leap and I know I couldn't help it, take the leap. There was a goat, I write, yeah, anyway. Just don't think about starting, just get started. And okay, so now some. I was an English major and I really, I'm not a Shakespeare fan. But practical tips for most of your documentation. Okay, so just some practical writing tips. We can't cover it all, but write shorter sentences. Don't try to sound sophisticated. Nobody wants that shit. Avoid jargon and acronyms. And again, this goes back to having empathy for the user. Like you're not writing only for future you. You're writing also for the people who don't understand all of the things that you're including. So if you can spell out an acronym like CI stands for lots of things. Sure, continuous integration is all very nice but it won't always stand for continuous integration. Write that stuff out, avoid jargon, picture the context and the likely user. Even if you're Matt's with this, there's you and future you. But later there's a million Ruby users. So let's just imagine that he wrote documentation with us in mind. I just, I haven't asked him yet. So it could be true. Writing is thinking, or at least it is for me. I write myself, as I write, I'm thinking, I'm developing an idea. And I asked specifically, I'm a member of Write the Docs which is an organization for technical writers. Cause at one point I thought I wanted to be one but this stuff pays so much better. But so, and it's so much more fun. I saw puzzles for a living, yay. But you will write your way to the main point. And I asked this organization of tech writers like in a chat what advice I should give to a room full of developers. And here's what they said. They said you, many of you will over explain yourselves all the way to the main point. Move that sucker up to the top. You don't even have to edit out the stuff that got you there. You don't have to delete it. That would be nice. But if you could just move it to the top. That's what they asked me to share with you. And that's actually what I used to tell my comp students. They would get to the thesis. I'm like that sucker needs to be way up here. And then you write the stuff that supports that. So please, if you write your way to the main point, move it up and edit it out if you can and use specific examples. That's really, that's the best writing advice that I've got. And then here's the secret to writing, which is handy. But don't let feeling not good enough stop you from writing that shitty first draft. Crappy first drafts are fantastic. All writing requires rewriting. Be okay with writing that first one. And then maybe future you can edit it. And that's gonna be awesome. You're gonna do great with that. Okay, so now let me just be honest, this last section is for miscellaneous stuff. I would hope to get to some recap and stuff and then stuff about being famous and making money if you're into that kind of thing. So the best way to get good at writing is to do more of it. So some more ways to practice. Write install instructions and ask one of your fellow developers to follow those install instructions and see what you missed. Find out what you missed. Offer to follow someone else's instructions and take the second draft. Remember the second draft is awesome. Everybody loves the second draft. Do that. Update or read me. I signed up for, I should have put this on the slide, docsdoctor.org. Anybody do that docsdoctor.org? Oh my God. Okay, here's what needs to happen. You go to docsdoctor.org. And this is all about all the things that are not documented out there in open source projects. Each day, and you don't have to do it this frequently or this much, they send me two pieces of code from Ruby and from Rails that are not documented and just sort of suggest that, hey, I might want to be the one to do that. One day I did that and I submitted a pull request with some documentation to Rails and they said, hey, you know what? Turns out that code doesn't work like everybody thinks that code works. And hey, would you like to deprecate that and then remove the code? So I'm like, oh, I'm gonna be a Rails contributor. And then I was and if you work at Living Social, you know that I then bragged about it profusely, especially because I was in the release notes right above DHH. Oh, it was awesome. And if you think now being able to say that I am a Rails contributor didn't lead to job interviews and negotiation and salary, you are incorrect. So, and that was just because I tried to do some documentation and that's how I got my first two PRs into Rails. But if you're using this open source stuff, contribute to it and they need documentation. docsdoctor.org, I'm telling you, sign up for it and there's tons of different projects you can sign up for. I just chose Ruby and Rails for reasons that should be clear, given where we are. So write blog posts, save someone. How many times does a blog post save me? Oh my goodness, it certainly has. Publish a tutorial, even a YouTube one where you do a screen cast for something. Reduce cost by saving future time, figuring these things out. Give a conference talk about some horrible problem you ran into. I gave a conference talk like two years about this horrible strong prams thing. Oh God, it was awful. And I contributed to the documentation that is out there on the internet if you search for particular problems and run into. In fact, one of my problems contributed to the development of, not by me, by Andrew Hunter, I believe, at Living Social, the Ruby gem called strong like bull. And that happened because I kept screwing the pooch with my strong parameters. They kept blowing up the app I was working on and people kept saying terrors, parameters are strong like bull. Oh my gosh, it's totally tight. A bull could be an ox, just so you know. I didn't even play in that. But so now the gem, by the way, is called strong like bull and it can help you do your strong parameters. But so documentation can lead to Ruby gems and all the things are awesome. So justify a salary increase by all this amazing time you've saved, solving problems, so that's awesome. Okay, some of you may recognize this, it's a little faded out, but it's kind of the loading thing for Slack. I wanted to bring this up because conversational documentation is awesome. You're not trying to document anything, it's part of your dev process. You put something out in a room or something. It doesn't have to be Slack, it could be any kind of service like this. Here's my problem. People try to sort it out and eventually there's a solution. If you pay for a service like Slack, you have automatically documented the problem. You pay for Slack so that you can search the archives. That's why you wanna pay for Slack. If you're not doing that or paying for whatever service you use, do that. You wanna be able to, that's automatic documentation. That should be an easy sell if nobody is buying Slack yet, have convinced them this is automatic documentation. You no longer have to document whatever it was outside of it. You just leave it in Slack and find it later. So automate those documentation steps. And then since I've got Slack up here, this is an actual release note from Slack and I kept it because first of all, some of your commit messages and PR messages can become release notes. But I think also it's a good reminder that your personality doesn't have to leave just because you're writing official documentation. And so this is a good example of that. It has our Sam Livingston Gray's commit messages and code. I feel sad for you all that you don't get to read those because oh, there was one about the Pope. It was great. Okay, so this is actually from Eric Hulsher who is the head of Write the Dots. Again, that technical writing organization and I'm gonna quote him so I'm gonna read from this. He says, if people don't know why your project exists, they won't use it. If people can't figure out how to install your code, they won't use it. If you have no users, people won't contribute to your open source project. If you have no documentation, you will have no users and you will not get contributors. So if you are working, I know many of you are working with an open source project, if you want to make Ruby great again and be stronger together, this is from Matt, it's not any political candidate, then you wanna contribute to the documentation for Ruby and build this community. And so then if you are the first to document something, like the crazy strong pram something, although that didn't really lead to fame and fortune, like I'd hoped. But if you are the first to document something and it becomes useful, it could become widely used. You could become famous, if that's kind of your thing. You could co-write a book about something related to this. You could write your own book just on your own. Neil, you've written books, talk to the people, tell them how to write a book later. Not right now. You could tweet about Oxen or something and Ox user stories totally available. You could be doing this. So there's all kinds of ways to use your writing to elevate your career, whatever the heck you're doing. Look at this goat. Oh, I love goats. So a quick recap, focus on the problem, figure out what the user needs, not what they want, write the shitty first draft. Explain the why, move the main point to the top for all things holy, move the main point to the top. Future you might be the user, so be good to yourselves and rock your user as a goat. So that's all I have other than stickers and information about Roostify over there. So thank you very much for your time and attention or documentation. I'm not sorry that I suggested comments in code. It's good for you. If you have any questions, I can answer them. Otherwise, you just get out early and nobody ever minds that. Do I think some of the advice I gave applies to writing software? Absolutely, and in fact, if we go back to my made up statistic, about 80% of what we do is write text. In fact, I tried to explain to my dad what I do once and he said, so you're a typist? He's not wrong, right? But absolutely, I mean, if you're thinking, I think about text or content as the stuff I'm conveying in words, but also the stuff I'm conveying, which in some ways is the software, right? It's what they see and how they use it. There was actually somebody else's, yeah. Why all the goats? This is, you know, people ask me that. It's okay, God, I'm up on stage, but do we wanna do all that? I'm gonna over-explain as what is about to happen. Okay, so I'm staying at my rabbi's house and the rabbi's wife has a metal goat outside called Sookie, one day I'm walking by and I'm like, hey, Sookie, how's it going? Because I talk to myself and inanimate objects, now you know, and then I'm like, how's it goading, Sookie? And I laughed all day long at my awesomeness because I'm a nerd and I laughed all day and that was what inspired me to start liking goats because I just amused myself so damn much by that. And so then, and it's like years later and I am living two blocks from a farmer's market and they advertise that goats were coming. Oh my goodness, this is exciting. And so this is my chance. I've never seen a goat like that I could touch and so I said, do you think your goats would mind if I hugged them? And they're like, we love, the goats would love you to hug them. And so then I am now the official goat hugger of JK Goats in Damascus, Oregon. And I am allowed to refer to those goats as my goats, which is fantastic. And I now hugged goats on regulars, but I started liking goats. So then I joined Living Social. I'm talking about goats all the time and there are goat puns happening. I'm bleeding it to death. Yes, I just said that. And I'm talking about that. And so somebody in the office drew a goat on the whiteboard. That was the office goat. And then Matt Robinson, who was our DevOps manager at the time, he said, you know, we should do something like cat user stories on Twitter, but with goats. And so the whole team sort of listed some goat user stories, lots of things about branches, as you can imagine goats love branches. And so, and in fact, we developed a slack room for goat user stories. And the whole goal was like to overtake cat user stories, which is now just not even happening. But who would have thought we could have overtaken cat user stories on the internet with goats, but we did. So that was successful. And eventually, and it was a team effort with putting together the goat user stories for a long time. And then Matt kind of gave it up for a while with me and Matt. And then Matt left and he handed over the goat reins to me and gave me full, full ability to do that. And I'm sorry I over-explained that, but I'm on stage and what the hell, you know? So that's, I love goats. They're great. Any other questions? Oh my goodness. It's all syntax, right? It's, by the way, she's an English major and she wants to know how to encourage other people in the humanities to do coding. Well, first of all, the money, right? Am I right? Like, I was an assistant dean up at the Union Institute and University for a while in the PhD in humanities program. So, you know, I was the assistant dean, made half what I do now. I make more than the dean made back then. It's so money for starters. But honestly, you're working with syntax, you're pattern matching, you're doing all the things that English majors do all the time. They're looking for patterns that they're, you know, everybody, you know, in high school, you have to look for the theme of the stupid literature that you're reading. You know, but we're doing that when we're building code. We're solving problems. We're using those critical thinking skills that we apply. And so honestly, I would just say they've already got the skills and 80% of the job is typing. You know, it's writing words. So you're basically a writer or a typist. You know, I think my dad still thinks I'm a typist, which is okay because he sends me money and I'm like, okay, more money. That's not what I was in it for, but you know, I need more go stickers. So yeah, it actually hasn't made me real rich then. Yes. Why yes, Betsy, who works at Roostify. Roostify is hiring. And thank you. She's a ringer. There is information on the stage right over here about Roostify and even a direct link to our jobs page along with Roostify stickers and Goat User Stories stickers right over there if you are interested. Thank you, Betsy, from Roostify. Okay, well thank you very much for coming to a documentation talk. Who wants to come to one of those?