 I don't think Jeffrey Grosebach needs much of an introduction. You've probably all heard his voice, if you have it, he'll show you on you. But now you can see his face. So Jeffrey, take us away. It was quite a great conference. Have you enjoyed it? Grosebach, I am left-handed, and my company is Pico Streetcasts, the new tutorials where we get job scripts, all that kind of stuff. Today, I wanted to talk about thinking about for even up to last year creativity and coding. And one of my favorite books that I read, probably the first book I read about programming that wasn't just to teach me a book about programming that wasn't to learn a specific technology, was Mythical Man Month by Frederick Brooks. And he basically, this book was basically pragmatic programmer or software craftsmanship of 1975. And one of the things that he had to say in there that I thought was brilliant was the programmer, like Pico, it works only slightly removed from pure thought stuff. Builds his castles in the air, front air, creating by exertion of the imagination. And what we do as programmers, we are creating something from nothing. We are starting with just ideas. And then we end up with a product of some kind. Pretty amazing. We're creating something out of nothing. And since we're doing that, this creative enterprise, well, how do we go about doing that? Is there anything that we could possibly learn from the ideas of other creative artists, even visual artists, or sculptors, painters, writers, those kinds of things. And so I thought, well, there are quite a few techniques and tools that they use. We benefit from any of those. Sketchbooks, books, prototypes, fatigue of each other, practice, and repetition. One of the things I did for myself to learn about this was to go around and watch different programmers as they were coding and working on different projects. And as expected, I actually did learn quite a few different things about the practice of writing programs. One of those came from Zenshaw. And this was quite shocking to me when I heard him say this at first. He said, if I get halfway through fixing something and I realize that there's something else I need to fix, I'm just going to fossil revert. It's the fossil source code control system. And he's going to start over. People find that weird, but they don't mean that it's not about the code. It's your understanding of the problem that you're working on. I remember talking to people right when I was getting started in programming. And people say, oh, this other person is a much more productive programmer. They write twice as many lines of code as I do in a day. Of course, it was Java, so you have to write twice as many lines of code. But it turns out that's not what it's about at all, is writing, being productive, is writing more code. It's how do we understand these ideas? How do we have these moments of epiphany to realize, oh, that's how it works, or this is what I should be doing, or this is how the UI should look? That's what's important. And as part of that, here we immediately get this idea of a prototype, and not just a prototype that eventually then becomes the full project. I remember my first big groupie project was the Prusa Rails app. And for the clients, I made a little prototype, and he was pretty impressed right away. And so we just took that exact code base and kept building and building on it until it's still running today. And visual artists don't do that. They'll make a small prototype that they'll throw away, they'll get rid of it, and this is exactly what it said, shot us. I mentioned this to Gary Bernard, and he said he'll take it even a step further. He says restarting a coding project with a better understanding of the problem should not be a rare event that only happens accidentally. It should be a regular part of your workbook. You should have that built in for the beginning. You should do that regularly. And this is, let's talk about refactoring a lot, taking some code, making it better. This is actually not that at all. This is actually debating whatever code you've written. And we're often so attached to the code that we've written because it was so hard to write, and it took many hours to put it together, and yet we don't, I've learned to realize that that isn't the most valuable thing that I do in the day is the lines of code that result from whatever I do. It's those ideas, and often those ideas can be better expressed by starting over completely deleting a prototype. I thought this was a great idea in itself until I realized this is actually straight in the Mythical Man Month. He has a whole chapter on this. He says in most projects, the first system is barely usable, and inevitably you have to start over again, and it's going to smart, but it will be smarter. And so he says, well, let's put this into our workflow. Let's plan to throw one away, use the first pass-through as a learning experience, learn about the problem, learn how to implement solutions, and then start over from scratch with those new ideas. Now we don't like the idea of, you know, we've heard about the big rewrite and how horrible that can be and that things are often very difficult to rewrite once you have a whole lot of code. And so in fact, this is not about the big rewrite, it's about doing it in small steps along the way. For a while lived in Seattle, Will Shipley, a coder and businessman that I admire and learned a lot from some of the things he said, he says, don't write code until you know what you're doing, but that doesn't always just evolve just kind of sitting there and thinking about it. Maybe it's actually writing code is the process by which we learn to think through things, but that doesn't mean that that code is what we should end up using. Maybe it's that process we write a small project and then we throw that out. So he too uses this idea of kind of a disposable prototype. He said that when he's writing a larger application, he'll have a dozen small programs and he starts completely separate from the main code base just to figure out API or a UI issue or how to write an algorithm to solve a specific thing. It kind of insulates him from all the other things that can go wrong, you know, oh, I need to upgrade this thing to get that thing to work and then oh, how do these things work together and how do I bundle these things. Isolated small projects often be useful in that kind of creative process. Personally, I've put that into practice by starting a blog where I do a different design for every blog post. Now, this does take quite a lot of work, but my goal at the beginning was to get better at front end design, but also HTML markup, CSS, JavaScript, putting all those kinds of things together. And I find that having these small projects where I was basically starting from scratch really helped me to not only learn specific things that I wanted to learn, but also help me figure out things that I didn't expect that I was gonna learn. And that's ended up being a valuable thing to accidentally learn things, try something that has no immediate benefit or application, but just experimentation and learning in general has been really valuable. Not to mention fun. It's fun to be able to put something together that doesn't have specific requirements at the end and is a small enough project that you can finish it in a day or two and you get that thrill of finishing a project, learning something, stumbling on something that you didn't even intend to learn and then moving on to the next thing. Some of those have included different oddities of CSS or WebKit animations, masks, all kinds of stuff has been pretty interesting. Some of it, you know, I haven't actually used it in an otherwise profitable project yet, but it's still in the useful learn. Another thing that's helped by doing small projects of my own is to learn to criticize my own work and learn from it and that's definitely something that creative artists will do. That's often hard for us because in order to be a programmer, you have to be quite an optimist and in Fred Brooks talks about this, he says that all programmers are necessarily optimists because maybe attracts people who like a happy ending, but we kind of have to have that continual optimism of well, you know, this I fixed the last bug, I've implemented it correctly, my tests we will pass because I'm supposed to go green and everything works out. But of course, it doesn't often work out and I think that sometimes, you know, I know for myself sometimes keeps me from looking at my own work, critiquing it or even accepting other people's critique of my work, which is actually really hard to do on the internet, especially because we end up being defensive of our code and thinking that, well, I put a lot of work into this and why would anyone criticize it or say that it should be done differently? The internet, as we know, tends to kind of amplify any kind of critique or criticism and makes it hard to receive. There are a lot of people who are, you know, appear very mean on the internet, but turn out to be very nice in person. I tried to think of someone from Seattle who fit that description, but was unable. So, you know, watching people write code in person and then either giving or receiving critique, of course, with a little bit of diplomacy. One of the places that I saw this happen really well was an event in Australia called Rails Camp. They've recreated this other countries a little bit. Basically, it's like a food camp where they just run out. Well, for that, they run out of the summer camp for a weekend and there's no scheduled talks. You just go, maybe there are some presentations, maybe there's just a room full of people writing code and you see what other people are doing. And it's a great way to go and actually watch people write code and learn things that way. One session there were two guys, Miles Byrne and Tim Lucas, who talked about, who took some existing code and as a session with 20 people watching on or something, explained how they would improve this bit of code and the original author was actually right there in the room and it was a little hard for him to not be defensive of his code but it turns out these guys were brilliant programmers and had a lot of good things to say. For example, here was one where they looked at where he had just printed out a message to the screen and then called exit to show the program didn't have enough information to go on and they realized, well, there are a couple things that could be better, could, if you're printing out something that's an error, well, that should go to standard error, not the standard out and if you're going to quit because the program couldn't complete, well then you should exit with non-zero, not exit with one and if you're gonna do all that, you may as well just call it the board instead of building that all up yourself. So really just, you know, straightforward, useful, practical critique and this is something that's really built into the way graphic artists often work but as programmers, especially with open source projects, you kinda have to go out of your way to seek that and to get that kind of positive, useful, learning kind of critique and again, it often works best if you do that in person. Another thing that I have learned or I'm trying to just think about my creative process is that creative time is not wasted time. Fortunately, being, running my own business and having some flexibility for a couple months, I decided I would start every day going to my favorite French pastry shop up in Ballard called the Honoré Bakery. So unfortunately closed for the next two weeks because they're on vacation, but and you know, having an espresso and eating a French pastry and writing down in the little sketchbooks and ideas about different programs I was trying to write or things to solve or screencast to make and after a couple weeks of that I thought well you know, maybe this is kind of a waste of time, I should be you know, just sitting at the computer working hard on things instead of just being away from the computer and just having undirected thought without any specific goal in mind. But then I went through and I listed all the things that I had solved, thought of or good ideas I'd come up with by having that time and you know, there's a whole list of things that had been useful to me personally or more profitable for business or overall worthwhile and I realized that's you know, that's a, it's hard to do to have this completely undirected time where you know, just give yourself 30 minutes and an hour to have really nothing on the agenda and think you know, this isn't you know, trying to sketch things upside down or things like that, it's just kind of open-ended thing at a time and that's turned out to be hugely useful. Other things that have been useful for me in that context have been just to generally think about, oh what, you know, I guess if this was Six Sigma I would find some way to measure this, but thinking, you know, what are the things that I have done in the rest of my life and what have those increased my programming creativity or have they made it harder? John Barnett talked about the general stress of programming that leaked into the rest of his life. I guess I was trying to kind of do the opposite of how could I structure the rest of my life so that it would improve my programming or improve my ability to come up with ideas and be fresh and think through some of these things. Definitely found that exercise has been huge. Actually two days ago, right before this conference there was a big bike race around Mount Rainier. Strangely with that, doing exercise in the morning has been huge. There are physical things that go on of endorphins and clear thinking that I find I get if I even do 30 minutes of exercise in the morning and then I get that benefit all day long if I exercise in the afternoon or evening then I kind of waste that on sleep which is often a good time to come up with good ideas too kind of with the subconscious but doing some kind of little exercise in the morning has really helped me think a lot more clearly. Another thing has been laughing. I've been fortunate to hire someone in the last couple months who laughs at 100% of my jokes. And occasionally laughs at me when I have not said anything funny. So that actually has been helpful. And when we talk as Ruby programmers we like this idea of Ruby bringing us happiness. Well, is that reflected in our mood and the other kinds of things that we do in life? Does that make out to making us happy when we're not coding or could happiness and other parts of life make our coding better and happier in that way too? So overall, what I'd like you to take from this is just thinking of yourself as, you are a creative individual that doesn't need to get all fuzzy of thinking of yourself as an artist but as a computer programmer you're coming up with ideas, you're building things from nothing and these are creative endeavors. Think about the process of doing that and the way that you could improve that with prototypes that you may throw away with critique from other people with parts of your daily life that could improve your mood, your environment or the other ways that you write or grant. Now, because this is Seattle we probably should end this by putting the laptop on flame on the stage but I don't think that's allowed in the building contract so thanks again, it's been a great conference and look forward to talking to you later in the evening and whatever else we end up doing this evening. So thank you.