Directed Practice: Aaron Bedra on Clojure Koans, Technical Writing, and Speaking Mastery

Yeah, so the whole thing actually started, Jim Wyrick and Edge Case had put together the Ruby Koans for learning Ruby, exploring the language. They were really well done. I picked them up, just wanted to see what was going on and I really enjoyed the teaching style. I really liked how that works. And that style of, you know, explain something very, some simple concept and show how it works is also presented in like The Little Lisper and The Reason Schemer and those books. I really like that kind of very close one-to-one, teach a small concept and kind of evolve it. And you're also so close to the source code, you're not in another tool in a little website or something like that. And, you know, a small amount of work can be done to just kind of bend the language into a little DSL, you know, and Ruby and Clojure both have some great ways to do that. So you kind of bend it to your will and make it work the way you want and you kind of create this little learning environment. So I tried to mimic what Jim had done with the Ruby Koans very closely because I like that style. Right. And then after that, Colin Jones of 8 Lite actually took, I mean, he's contributed, I think, way more than I have at this point. He really put his eye on it. You know, he saw it, he embraced it and really went with it. And the new Clojure Koans website is actually a product of 8th Lite as well. And it's written in Clojure as well. It is, it is. The Judo framework. Yeah. And so, you know, those guys really took, they did all the work here. Right. It really wasn't me. I started the project back in 2010 at CodeMesh. Oh, okay. So this was actually a project at a conference. Yeah. So at CodeMesh in 2010, a full bunch of folks had talked about, you know, the Ruby Koans. They were becoming popular at that point. We said, hey, what about a set of functional language Koans? And we actually started the project as a collection of Scala and F Sharp, Clojure. I don't remember, a lot of these people participated. Yeah, because it originally was just kind of functional and you just had an umbrella. Yeah. It just kind of seems to have focused now. So

Technical books are, you know, I think this is my first big book, right? I've done work for Peep Code for Jeffrey Grossenbach. I wrote a small book on rail security several years back. It was much smaller. So this was a bigger endeavor. About 300 pages this book ended up being. So, but it was the second edition of Stu's book. So there was already a foundation. So it was much more daunting than the Peep Code book for me, but it was also less because it wasn't, you know, a blank slate. Right. And so with that, I mean, you've obviously been doing Clojure for a very long time and you've contributed to the code base. How much of writing the book was having to learn new stuff versus codifying things you already knew?

The first edition that Stuart wrote was kind of pre 1.0, right around 1.0. And this book is targeted at 1.3 and up. So the language that evolved quite a bit and between Clojure 1.0 and 1.3, there were lots of changes. So if somebody picks up the book, it's still relevant. Yeah, absolutely. Yeah, this is, you know, a couple things have been released since then, but there are, this book is still very relevant. You won't find code examples broken or anything like that. Nothing has changed interface-wise. Oh, okay. So the code examples would still work even if you used them with, you know, 1.4 or 1.5, as far as I know. Right. I've tried most of them, so. Okay. Yeah, just the last kind of group of questions is you've gone and spoken at a lot of different conferences. You've gone in RailsConf, No Fluff, Just Stuff, ClojureConf, very different communities. Yes. Just in those three conferences. Yeah. Do you talk about different topics or do you tend to, like, have the same topic but maybe tailor it for that audience?

Just when you're preparing for your presentations, are you one of those types of people that likes to sit down and figure out, this is my script? Or do you kind of just say, I know this thing, and then you just go with it?

So I'll fire up Emacs in org mode and write an outline. And, you know, that has gotten me through lots of things. Okay. And the reason I do that is because, I guess the story is important. And when you break that down, it gets rough to follow. Right. And if you're moving really fast, because, you know, an hour is a long time, so you have to move quickly. If you skip a beat and go off somewhere else and don't really transition well, it's hard to follow. Yeah. If you get off a toot, it's hard of a script. Yeah. So that outline helps make sure the story is going to go the same place from start to finish. And then after that, I fill the details in slides.