 All right, so I'm going to go ahead and get started. Can everyone hear me? All right, I'm going to get started, and if worse comes to worse, we'll finish early. So I wrote the proposal for this talk right after why the lucky stiff disappeared himself. I took a step back and was thinking about what I'd learned from why. The thing that stood out the most to me was that he didn't seem to be too concerned with the seriousness of his code. He was not in it to show how professional he was, how robust his code was, or to espouse his ideas is superior to all others. So since why I inspired me in doing this talk, I thought I'd highlight some of the projects I found most embodied hit this aesthetic of fun. So first off is Potion. Potion is this nifty little language that Y created that was influenced by Lua in its implementation and by JavaScript and Ruby and Python and its syntax. I was a little surprised that Y decided to hack out his own little language. I really thought that building a language was something that was fairly dry. I mean, there's a web page on the internet where you have to decide which picture is of a serial killer and which picture is of a programming language creator. So they're usually present company excluded cut from a very different cloth. But Y showed me how you could create a language and do this normally very dry thing, but still have fun and do it playfully. Next is just camping. So I followed the development of camping for a while and tried to figure out what the aesthetic of what Y was trying to do was. And a lot of people wanted it to be a Rails competitor. A lot of people wanted it to be this big, all inclusive thing. But Y just kind of wanted it to be this tiny little framework for him to tap out little web apps and have fun with. And he also wanted it to fit on a t-shirt. So he had this limitation that it only be 4,000 characters. So here you can see the t-shirt version of camping in its entirety. Y brought us plenty of other things, too. There was red cloth, Hricot, and sick. The latter is a particular note to me. I'm willing to bet that very few of us are eager to write a yaml, parser, and emitter. And yet, Y did, and now most of us use it as part of MRI. So clearly, you don't have to do things that are traditionally considered fun in order to have fun. You can do things that lower the friction towards other people having fun, and you're still increasing the net amount of fun that can be had. So a survey of Y's works is incomplete without mentioning his mixed media works. His presentations and shows, there were really more shows. At various conferences, we're amazing. And if you missed any of them, find them on the internet. The poignant guide is a touchstone of our community. You're likely to either love it or find it just a little bit wacky. But no one can discount the influence that Chunky Bacon and the cartoon foxes had in making our community one where a tongue placed firmly in cheek is welcome and encouraged. So right before Y disappeared his works, he had lamented about the temporary nature of software. And it's true that hardly does the dust settle on the current hotness before the new hotness comes along and tries to supplant it. But if you consider the notion of building one to throw away from the mythical man month. In software, we're used to the notion that writing code is a learning process. And it's not uncommon that we'll find that we can do a better job from a clean slate after we've worked through a problem domain and figured out what's really going on. But why is code has showed us that software can outlive its useful life? Code can exist as something that makes you happy and as something that makes other people happy. So even if it's only in the act of reading it, not all software ceases to be useful after people are done executing it. So I encourage everyone to go check out the Y mirror on GitHub. Just look through his code. A lot of it's very playful. A lot of it's a little wacky, but it's fun to read. So I just wanna say thanks, Y. It's a very great contribution. So back to the matter at hand. I got kind of concerned that the Ruby community was losing its sense of fun. As I was thinking of this proposal, I was struggling with my own work. Or more accurately, I was struggling with my lack of finished work. It had been months since I felt like I'd made something of consequence. Plenty of big ideas, but no finish. And through the lens of Y's work, I came to look at things from a slightly different angle. I started to think that maybe we've lost track of fun here in the Ruby community. I've observed a lot of consternation about whether Ruby's release management is good enough. Whether it's GC is suitably comparable to other runtimes. Or whether we're all just a bunch of weenies distracted by the newest shiny things. My point on this talk was going to be that we need to get back to having fun. And rekindle that amazement we first felt when we typed some stuff in and made the computer do something different. But it turns out, people are totally still having fun. They're making games, they're doing graphics, they're doing sound. They're doing things in the real world. And so you've got people doing stuff like Ruby processing for doing graphics. And Ruby on acid for doing even loopier graphics. People doing like Giles Boca and his generative sound stuff. And there's another talk on generative sound later. And people doing Arduino and hacking hardware. So there's plenty of people doing completely impractical things. And so I just wanted to highlight a few of them since I had lost track of it. So one of the people doing lots of fun stuff and one of my heroes lately is Greg Bornstein. He brought us a very clever way to write Ruby and run it on an Arduino. After a stint working on a music site called Grabbit, he's now at NYU's ITP program which is sometimes called the center for the recently possible. So he's there bringing his talent for music, hardware hacking, software and design to make really cool stuff. And he's been cataloging it on his websites. And I'm having a fun time just seeing how he takes his polymath nature. I think he's really a great definition of someone who knows a whole lot about a lot of things and puts it all together in a great way. So he's definitely having fun and I'm having a lot of fun following it. There's a lot of people doing study groups like the SICP group. So people are studying the wizard book, the book about the structure and interpretation of computer programs and they get together in person on mailing lists and talk through solutions to the problems. And sometimes they even solve them in languages that aren't scheme. So they're learning stuff but they're having a lot of fun twisting their brains around learning new language. And if number problems are more your thing, there's a site called Project Oiler that has a bunch of, basically math problems that you would write a program to solve. And these are really great for bootstrapping yourself if you wanna go learn a new language. So here I've got a Haskell program that I wrote to solve one of the Project Oiler problems. And it's a really great way to get started with a language that you wanna learn but aren't sure where to get started. Or like Haskell, I can't write any Haskell programs that do IO. So most of the programs I'm used to writing do some kind of side effects but these are all just math problems. So it's very easy. You can do language hacking for fun. So Mark Andre Cognier, the guy who wrote Thin, is having fun hacking on languages. You can see some parts of his tiny ruby here that he's written this tiny little interpreter that executes a very, very, very minimal subset of ruby. But if you check out his GitHub page, you'll find a plethora of little language experiments he's done. He even self-published a book on how to join in the language hacking fun. Basically everything he's learned, he's documented. And Charles Nutter is doing some very similar things with JVM languages. So those are some people having what would be traditionally considered fun. But there are people doing things that are fun for them that most of us wouldn't consider fun. These folks are doing excellent work on virtual machines, asynchronous IO frameworks, and improving the XML consumption landscape. So their work enables us to have more fun. We'll start with the people working on virtual machines. Whether you love them or hate them, folks like Kouichi, Evan Phoenix, Brian Foro, Charles Nutter, Tom and Ebo, Laura Alcensionetti, and Brian Lam are out there busting their butts to make us hotter, faster rubies. And worst of all, they can't even do it in Ruby. They're knee-deep in C++, Java, C-sharp, and Objective-C. So to some folks, writing a virtual machine is fun. And hopefully some of these guys I listed are having fun, or they consider writing a virtual machine fun. And to write one for a language you love is even better. Now it's probably the case that these folks don't exactly love Ruby anymore, and they would love to remove a feature or two to make their lives easier. But in toiling away on building better rubies, something that is by no means easy, they are making possible for all of us to have much more fun. And so these guys are my heroes. So there's another interesting group of people. If I had a nickel for every time I heard that Ruby will lag behind due to its immature GC, its naive IO, or its quaint concurrency model, I could buy myself a really, really nice glass of scotch. And yet there are a lot of folks hacking away in these areas and making it easier to push Ruby to its limits. And I think the work that they're doing is kind of just like in The Empire Strikes Back when Han Solo cuts up the taunt on, and he says, I thought this thing smelled bad on the outside. So they're down deep in the internals, tearing things apart and making it better. So folks like Joe DeMotto is hacking around and making threading context switches more efficient. And Evan Weaver is doing some really great stuff, profiling MRI's memory behavior to figure out where it can be improved. The Fusion guys are hacking out Apache modules, which are not fun, to make writing Ruby apps easier. Event Machine makes it so that we can write apps that don't need to lean on threading so heavily. Philip Cromer is building tools, a library called Wukong, so that you can write Hadoop scripts that operate on big data more easily. Ilya Grigorik is writing great tutorials so that those of us who typically work in the application level can understand how these infrastructure bits are interesting and how we can leverage them and get started. So there's fun to be had. You just have to decide on what's fun. Sometimes it's in the bowels of the code and not in the sexy, shiny parts that actual users interact with. Lastly, I'd like to single out someone as a great example. So, WrexML is bundled with Ruby and raised the bar on what I'd consider a humane library for dealing with WrexML. It's a delightful API, but internally it's a little pokey. So I had long contemplating sitting down with something like LibxML and building a decent API on top of that. I knew it'd be a net awesome for the Ruby community, but I didn't do it because frankly, I want as little XML in my life as possible because XML is like a wookie and if you make it mad, it'll tear your arms off. So I decided not to do this because I didn't want to make something and then abandon it because I hate it. But Aaron Patterson came along, did it and has stuck with it. So now Ruby has an excellent library for dealing with XML and it has more Aaron Patterson and that's a win-win scenario. But he's sitting here having to cautiously shave this wookie to make it more presentable for us mere lay programmers. So salutations to Mr. Patterson. So if you ever thought around thinking, man, I would love to work on a virtual machine, a system level library, or some thankless infrastructure bits, but that's not gonna get me on Hacker News. Then think again, it might not get you on Hacker News, but who cares if you can succeed in doing one of these things, you can have fun and at the same time enable other people to have fun. So there's lots of fun stuff that's gonna be talked about at RubyConf this week. Jeff Casimir is gonna be talking about doing generative art in his talk, Code of Art. Ron Evans and Damon Evans are gonna talk about flying Arduino robots they built in flying robots. Ninh Bui is talking about game development in the aptly titled Game Development with Ruby. Noah Thorpe is talking about generating music and making music with Ruby. Logan Barnett and Jay McGavern are talking about making games with Jay Ruby and Ruby Game Development with Gemini. Aaron Patterson and Ryan Davis are gonna wow us with some fantastically bad ideas and the surprisingly titled worst ideas ever. Matt Avenetti is gonna show us how to build games with Mac Ruby and writing 2D games for OS 10 with Ruby, and Sarah Amari is gonna show us how to get kids interested in coding in her talk indoctrinating the next generation. So there's plenty of fun to be had. Hell, there's even three presentations just on writing games, which are pretty much the definition of fun. So you've got no excuse to not get to at least one of these talks and figure out what kind of fun you might wanna be having when you're programming for yourself. So that's kind of the fun part. I've still gotta make up some problem here though and show you how to solve it. And it's gotta have some believable relation to the notion of having fun. And thusly, I started thinking more about enjoyment and the goodness of the things we make and how we can make more stuff. And I ended up on an interesting tangent. All of us have something we want to make and the process of making that and actually producing that in the end product is fun. But lots of us, myself as an exemplar, encounter roadblocks to making it. We're either not making enough of it, we're not happy with how what we make affects our peers or worse, we're not happy making it at all. So at the risk of going down a tangent that is perhaps too soft for RubyConf, I'm gonna share some solutions I've found for these problems. And none of these things are panacea. They're just things to try when you get stuck. They're things to do when you're not having fun. So there are three sorts of problems I'm going to tackle today. And I've kind of arranged them in a hierarchy of open source developers' needs. And they move from having more fun and removing non-fun to making more things and then to making more and meaningful contributions to the Ruby community that you're a part of. So I haven't completely cracked this nut. I've got some ideas about things that helped me along towards these goals but I haven't found the silver bullets yet if they exist at all. So what I do have is a bunch of hacks, patterns, whatever you'd like to call it that seemed to help. When I find I'm not progressing at the rate I'd like to, I employ one or more of these like fault of these ideas to get myself back on track. So at the bottom of the open source developers' hierarchy of needs is enjoyment. If you can't enjoy making open source software you should just do something else. There's no problem in that. So the first thing you should do is to do it for yourself. Most of us write software for monies. So this puts us in the habit of taking other people's needs and translating it into working code. When you do this in a particular domain for long enough then you start to get a particular set of itches. You'll notice you're always coming up with user authentication system or ways to write views or whatever. And soon enough can seem like those sorts of things are really interesting to you. And this is kind of a coping mechanism for your brain. It's possible these things are interesting to you but it's more likely that your brain has sort of convinced you that this is interesting so you keep working on it. But for a select few, writing just in time compilers or wrappers for XML parsers is a good time and praise be to those sorts of people because they make all of our lives easier. But for the rest of us it helps to step back and ask what kind of projects we're really interested in. Maybe we'd rather write something that does interesting things with music or graphics. Maybe making a game would be more fun. If you're like me you've got all sorts of ideas bouncing around in your head that are basically applications that are just punch lines, just jokes. So deciding to devote time to one of these projects is fun because you matter. As much as possible you should toil for your own reasons not just because the money is great. Many of us are lucky to work with the tools and languages we enjoy and get paid to do it. But it can go further than that. Work on the problems you enjoy with the people you enjoy and do it for you. So one thing that I found helpful is to write down all the projects I want to tackle but convince myself are too impractical or not sufficiently adult. And I reconsidered those projects and putting some times towards them and seeing if that was enjoyable and fun. Another thing is to think about the work for money you do on a daily basis. Is it enjoyable and why is it enjoyable? If it's not enjoyable what could you do to make it more so? And then think about how I thought about how could I change my workplace or change my workplace to augment my enjoyment. So something really critical to any kind of creative endeavor is to not burn out. We all love thinking about the awesome things that will happen once we've shipped our projects. We'll get large bags of money, huge recognition by our peers and unicorns surely await us as soon as we ship, publish or launch. So we put our noses to the grindstone and work our tails off until we get there. And working hard is great. Most people do want to work hard at something and if you can get outsized rewards for doing so, great. But there's a flip side to keep in mind and that's burnout. It's easy to get so deep into something that it consumes you. Your well-being becomes intertwined with it. If a project is going well, you're in a great mood and things are splendid. But if it's going poorly, you feel down and cranky and unmotivated. So it's really important to pace yourself. If you're finding that you're just going through the motions not making progress or dreading the work, stop. Take a step back and figure out if you're taking a wrong turn somewhere. Get away from the project for a spell just to clear your head. Our bodies are clever things. When I started working out this year, my muscles would ache for a couple of days afterwards. And at first, running was very painful and not at all pleasant. But as I got into it, I started to hurt less. And eventually it got to the point where if a muscle was hurting, I knew I was doing some motion wrong. And I think our minds work the same way in part. My brain feels sharp and focused on the days that I get my best work done. And it feels dull when I'm going down the wrong path or I'm too frustrated to work on something. So sometimes it seems like our culture demands of us to just push through, muscle up and get it done. But often this is exactly what you don't want to do. You'll end up hating the project or having to clean up after yourself later, or both. So next time you find yourself banging your head on a wall, just stop. It's more important to solve the problem eventually than to solve the problem right now or with the tool that you have in your hand. And if you dread working on a project, pick up something else. Don't worry about when the urge to return to your project will come. Just do something and let your mind roam a little bit. Eventually your mind will roam back and you'll probably come back with a great idea to boot. So if you're like me, you read that you should do exercise and you groan. Exercise is boring, tedious, and necessarily hard work. It's easier to go read a book, play a video game, or watch a movie. However, I found out after I started a real workout program doing strength training and cardiovascular exercise, my brain was much sharper. My workouts had the same mind clearing and focusing effect that taking walks had but to a much greater extent. So the morning after I went on my first significant run, my brain felt like it was in overdrive. Awesome ideas were coming left and right. My mind was focused and I didn't procrastinate at all, which I'm normally a terrible procrastinator. So much of what we know about the human body and in particular fitness seems to change like programming language fashion. But there is some research that shows that exercise gets the brain and body working in ways that aid creative problem solving like programming. I've also found that exercise is a great way to wind down the day. After a long day of interacting with people and immersing myself in problems and writing code, I like forwarded my workout in the evening. It was my brain of time to process the day's events. I can step away from the challenges of the day and figure out what's important and how to act upon it. But luckily exercise is easy to do. You pick something that sounds interesting, try it, and if you like it, you commit to it. And if you don't like it, you do something else. So committing to an exercise program is a lot like committing to a project or goal. It's all about showing up. If you get to the gym or lift up your shoes enough, you'll make visible progress. If you sit down and hack out your projects, eventually you'll have something to show for it. So the hard part about projects and the hard part about exercises is the commitment. It's a lot easier to want the results than it is to get them. But if you commit to a project or commit to an exercise, then you'll get what you want. So moving up one level in the hierarchy of needs, you've got creating. Once you're enjoying stuff, then you start wanting to make more stuff, or at least I do. So one of the challenges of creating is that you need to do some deep thought. So some days I sit down at my computer, put my hands on the keyboard, and nothing. I bounce around between web apps and the task switcher, might surf the web a little bit. But despite my excitement about the notion of whatever my project is, nothing related to it moves from my brain to my fingers to the screen. So we all find energy in the oddest places. Each of our brains is activated by different things. For mine, it's a hot shower or a leisurely walk. Yours might turn out to be the first cup of coffee or a set of push-ups. The key is to try lots of different things until you've got a good idea what flips your brain into the on position. So these places and activities are what I call my thinking place. It's where I go to let the ideas bounce around in my head and come to the surface. So sometimes I go into a problem that needs solving, but I'm not making progress sitting in front of a computer. I actually rearrange my schedule so that I get up in the morning, start working on some code for a couple hours, and then when I come to a problem that I have no idea how to solve, that's when I take my shower. So I can go in there, stand around in the hot water, not really think about it, and then start to think about it. I take ridiculously long showers for a man. So I take these long 30 minute showers, lots of steam, it's good. And yeah, and usually I figure out what I need to do with the problem far faster than I would if I just sat there and forced myself to sit in front of the computer to figure it out. So regardless where you go to stewing your ideas, ponder in actions, and figure out what to do next, it's good to know where that is. So the great thing about this thinking place is it's often where ideas smack you out of nowhere. You go in expecting to, you go in not expecting to think about some particular challenge. And they're let alone come up with a solution for it. But it comes right out, obvious and well-formed. I know a good thinking place experience when I feel the burning need to jot all the ideas I had just had on a whiteboard before they're forced out of my head with some other pressing or more practical need. Another way to know that you found a good thinking place is if it's a place you can talk to yourself and not feel absurd. This is why I like thinking on walks or in the shower. There are private activities where no one is around to wonder if I'm going a little crazy or not. So next time you're faced with a gnarly problem, get out from behind the desk. Go somewhere else, talk yourself through the problem, whatever. If you find yourself having lots of great thoughts somewhere, if you find yourself doing a lot of great thinking someplace, try to go there as much as possible. When I was growing up mowing the lawn, I found extremely conducive to long periods of thinking because mowing the lawn is so mindless I could just think about whatever. Well, that doesn't mean I really want to mow the lawn that much. So in creating, it's really important to just get started. Procrastination is our enemy. It guides us away from what we want to do and towards the things we somewhat enjoy but often wish we did less. So there's a really good book about what the insidious forces of procrastination are called The War of Art, and I highly recommend reading it. It's really short and easy to read. So not only is it full of good ideas, you'll feel like you accomplished something because you read a 200-page book in an hour. But for our purposes, let's talk about procrastination's greatest enemy, which is getting started. Overcoming inertia and putting the metaphorical pin to paper is often the hardest part. Once you give yourself permission to choose a tiny little corner of your problem and go with it, things will get a lot easier. Once you've got a little bit of the project outlined, it becomes much easier to pick part of it and start to flesh it out. And this is, in my opinion, one of the reasons like rails appeal to so many developers early on. Instead of spending time picking ORMs, templates, and controllers, you just run a few generator scripts and start filling in the blanks with what you actually wanted to make. So giving yourself permission can route around analysis paralysis as well. Rather than think about all the pesky details or challenges you may come upon in your project, you come upon them as they really exist, instead of as they exist in some theoretical world inside your head. The real problems of any endeavor are often very different than those we predict inside our heads. So just getting started and addressing the real ones, instead of the imaginary ones, can save a lot of time and stress. The best thing about just starting is that you've started. Maybe you time-backs the start so you don't chase false paths, or perhaps you just check off one item on a list of 10 things to get done. Sometimes it happens you can solve the whole problem in one sitting, which is really awesome when it does happen. But no matter how you tackle it or slice it, once you're done, you can look at what you've done and say, well, it's a start. And as you put it aside to work on other things, you can decide whether this project that you just devoted a little bit of time to is worth continuing or whether it's better to put it aside as an interesting data point. So no matter the outcome, just starting is the important part. So another good thing about creating is you want to go look at what other people have created. If your energy level is low, going and reading other people's code is a great way to spend your time. So just like a musician learns by listening and a writer learns by reading, developers can learn a lot and get new ideas by absorbing the code of others. And so for example, in our community and Ruby, there are a few pieces of iconic software. So just pick one of them that you like and start skimming through the sources of it. It may not be the best code. And in fact, it may be pretty shoddy internally despite its outside utility. But reading code is a great way to get started developing opinions and aesthetics on the topic of code. And I also like to read the code of the people I'm inspired by. If I think what someone says on their web log or presentations makes a lot of sense and is very agreeable, I find it really intriguing to dive into their codes and see how their approaches to problems differs from my own and matches the things I already do. Reading code is also handy in that it flip switches in your head. You can come across a solution to a problem you were thinking about earlier, or it could inspire you to approach a problem from an entirely new perspective. Or maybe it just motivates you to get back to your project. No matter what, you come out ahead. So code reading is also great because it's easy. Everything you need, you've already got. Just download some sources, pick an example or test, and start figuring out how the application or library works. Think about how you might make it better. Look at the shape of the project and contemplate how that makes you feel as a developer. The nice thing about reading code is you don't need to produce anything to say you're done. The end goal is just to expand your mind. As long as you've done that, you're well off. So grab an interesting project, download it, and read through it. Or take some of your own code and step back and look at it not to fix a bug or make an improvement, but to see the bigger picture about how you've made things, how you can make it better in the long run, et cetera. So making things requires time. And nothing is more frustrating than waking up with enthusiasm to make something but no time in which to harness that energy. So it's worthwhile to rejigger your schedules so that you've got time to make things that are important to you. Most of us don't think too much about our schedules, but it's really important to reconsider them. We get up with time to prepare for work or school, go there, eat a couple of times, come home to unwind, and then hit the sack in time to sleep well before it's time to rinse and repeat the next day. This works perfectly well for a lot of people. But if you want to make awesome things, you need a more detailed schedule. You've got to fit your time for creating in your day somewhere and there's no fixed formula for this. It largely depends on knowing what your day looks like and what times of the day you are at your most energetic. Do you get stronger as the day goes on or perhaps you start off high and trail off throughout the day? This is the most important thing to know. Once you know it, you need to schedule time so you make things for yourself when you're at peak energy. Once you've figured out your high point, most other things fall out. If you're a morning person, you probably need to get a couple of hours, you need to wake up a couple of hours earlier so you can make stuff before you go to work or school. If you're an afternoon person, you have to figure out, you have to find a way to avoid friends, TV, video games, kids, et cetera during your time for creation. If you're a night person, you have to figure out how to wrap your relaxation or family time up so you can shift gears and make your cool stuff. Finding that time to make your awesome stuff is the easy part. Making the time is another ball of wax. Exercising, eating, bathing, books, movies, TV, sports, video games, socializing, family time, chores, and a myriad of other things tug on us. And somehow we have to find a way to eliminate, minimize, or mitigate the time we spend doing those things so we can make the awesome. The easiest thing is to appraise how much enjoyment you get out of all the things you do that aren't work and aren't making your awesome thing. Then you have to decide to cut it out, minimize it, or embrace it. Cutting out things is hard at first, easing the long run. I used to spend a lot of time playing video games. I played Call of Duty in Modern Warfare for like two days. It has a timer in the multiplayer thing. And when that thing got to two days, I was like, all right, no more, no more video games. So I convinced myself that I had better things to do than spend time shooting at teenagers on the internet. And everything got easier and easier the further I got away from games. So minimizing other things you need to do, for me, is a little harder. There are things I love to do a lot, but can only do a little. I would love to spend all day reading, but I can't, and so I ration it out over the course of days and weeks. Other things like chores, I just try to minimize the time I need to do it. So if I keep my desk clean, for example, then I don't have to go digging through it on a Saturday and reboot it and spend several hours on it. Mitigating distractions is really crucial, but it's a negotiation. This is where things like your family and your project come to loggerheads. You've got to spend time with your parents, life, girlfriend, dogs, cats, World of Warcraft, Mount, et cetera. But you also want to take time to make things. What's worked for me is to make sure I spend a little time each day away from the project, just to relax. And then figure out how I can work on it in a semi-distracted state during the week. Then on the weekends, I block out large chunks of time, one for my family and one for the project. And that seems to work well. So the crucial things are to notice how eager you are to do your work each day and figure out what your peak time is. And then reclaim that time slot for your own projects by rearranging your schedule. And take stock of all the things you do, decide what's important, and go with it. You want to minimize or mitigate everything else. So the very top of the hierarchy of needs is contributing. Actually making things that your peers in whatever community you choose, whether it be Ruby or whatever, making things that they find useful and awesome. So one of the things that works really, really well for me is to work on a project with someone else and owe work to them. So there's lots of projects that are just too big for one person to tackle by themselves. They need a diversity of skills that aren't present in one person. Others need a balance of opinions to keep decisions moving down the right path. And some just need more people toiling to take advantage of timing. No matter why you end up working with someone else on a project, there's a handy side effect of committing to work with someone towards a common goal. You end up owing them something and that's really powerful. So some days you might wake up not particularly wanting to put in the hours on the project. Perhaps there's a more interesting but less pressing part you'd like to work on today. Working by yourself, you maybe tend to just skip out or do the fun part. But if you owe someone, your personal pride and admiration for the other person can help nudge you in the direction of putting in the hours on the less exciting part. Working with someone who you respect a lot is a very powerful motivator with sticking with the project. But there's another benefit. It's exciting to work with people you deeply respect. Otherwise, droll, boring projects become very interesting just from the interaction of working with awesome people. Another flip side of owing someone is that they owe it to you. There will be days that you are uninspired by what you've accomplished lately. But the other person that you're working on the project will come up with something that amazes you or energizes you. So the benefit flows both ways. So another, so a great way to get started with this is to keep an ear open for projects you could work on with very interesting or motivating people. With your heroes, people you respect, et cetera. Owing it to them could make an otherwise tough project much easier. Plus you get to say you've worked with someone who's working with respect and that is a great multiplier when you look back at what you've done lately. So another way to contribute is to take one for the team. This is just like Nocogiri. Very few people probably want to deal with XML parsers. But if a couple people can put time into that then a lot of people can benefit. So it's hard for me to look at stuff like Ethernet drivers, email handling code or code that deals with XML schema and think this looks fun. I like to spend much of my spare time working on this. But the beauty of open source is that we all find fun in different things. Somewhere out there someone does think those things sound fun and will spend their time working on it. So if you put your kind of economic philosopher hat on you probably come to the conclusion that these people are really crucial to the progression of our communities and crafts. Through their hard work we can devote less of our brains to uninteresting detail work and more effort to things that are actually fun. Whether these people are, they deserve an outsized portion of our praise as a community. And if you are one of these people working on something you find rewarding with the majority of the community around you finds tedious then there are a couple of special rules to maximizing your happiness while working on this sort of thing. First off, make for damn sure that people know what you're doing. There's no sense in toiling on the tedious edges if no one knows that you're doing that. Second, make it easy for people to make small focused contributions. If they find a bug you're unlikely to come upon removing friction so that they can report the issue or even better a patch will make your life much easier. Third and maybe most importantly make it really easy for people to use your work. I read a great essay last week called The Selfish Class which is all about making classes almost more viral and increasing their chances that they will be evolved into other people's code. So that's very much worth reading. So if you know someone who's working on one of these tedious projects that helps everyone out definitely shake their hand, tell them they're doing a great job and thank them. And if there's a problem space that you're really interested in but you think other people find tedious, maybe give it a go and see if you can solve that problem for all of us so that we can do more interesting work. The last trick I have for contributing is that sometimes it's useful to write words instead of codes. Our minds are always full of ideas and sometimes they just pop out. But other times these ideas need a little help coming out. And one way to help them out is to switch modes. Instead of trying to think something through, we can talk it through. The pragmatic program is called this rubber duck pairing. Another way we can control ideas out of our head is through writing. The act of writing utilizes different parts of our brain than typing in code. And we formulate ideas differently when we're doing this and we use different structures to express these ideas when we're writing. So if you find yourself stuck, try switching from coding to writing. I've often found that talking to myself through writing, I can better understand the problem at hand. If I can't get myself started on some code, sometimes I'll write the documentation or the read me first. After all, if you can't describe code, you probably shouldn't write it. You can even take this another step further. Push the keyboard to the side and actually write. Use a pen on paper. Take advantage of paper's random access nature and write all over the page with no structure instead of writing in a one-dimensional stream of characters like you do in a text editor. Or perhaps if you find yourself in a low energy situation and you'd like to make progress on your project but don't have time to jump into the code, go write some documentation. Think about a tutorial for developers or a guide for users that would help the people you want to reach. So there are two tricks at play here. First, you're activating a different part of your brain and if you've been in a rut, maybe the solution is lurking in that part of the brain. If you're down on energy, perhaps this will serve as a running start. Secondly, it keeps you going. Even though you're not writing code, you're still making progress. And while it might only be motion and not useful action, it is progress nonetheless. So always keep a list of things you need to write and if you don't have much time to jump into some code or you just don't feel like dealing with code, do some writing. And if you find yourself stuck on a project, switch modes and try drawing it out, writing it out, whatever. Putting your mind in a different place can often be really, really helpful. So I came at this talk with the idea that seriousness is the enemy. Always writing production ready code and dismissing the ideas that aren't sufficiently professional or my enemies in creating things and having fun at the time that I had the idea for this. But over the months since then, I've come to regard a different kind of seriousness as the crux of the biscuit. Taking your own time seriously and deciding how you want to use it is important stuff. Once I started to think about how I use my time about what is important and fun versus what is necessary or extraneous, everything else fell into place. I thought about what was fun, examined the spectrum of how people are having fun doing those things and how to start down the road of joining those people making fun. So my hope is that by cataloging the kinds of fun you could have, showing specific ways, specific people are having fun and then giving you some tools for choosing, creating and contributing more fun, you'll come away from this weekend both re-energized by all the other presentations you're gonna hear, but better prepared to take that energy and convert it into awesome stuff. So, thanks.