CodeConf Saturday Summary

Hey everyone! I’m here at CodeConf, and I figured that if you’re not here, you might be interested in a summary of all of the talks. They are not being recorded, so I’ve spent the time to give you the tl;dr, and link you up to the slides. Enjoy!

Dr. Nic - Tinker Bell: being a good tools fairy

First up was Dr. Nic, and he talked about the importance of building tools to help you solve the problems you face. He gave three steps for tool building:

1. Learn something
2. Encapsulate what you’ve learned in code
3. Repeat and go faster

Basically, any time he learns something new, he builds a tool with it, so he can forget what he’s learned. He gave an example of building a TextMate bundle with node.js as his first ever Node project.

Oh, and also, this:

Coda Hale - Metrics, Metrics, Everywhere

[Slides]

Coda gave an awesome talk about how important is is to measure what your code is doing. “Surprises are for birthdays: if something affects the business value of the code you write, start measuring it today.” Basically, he said that everything we do boils down to creating business value, which is anything that makes people more likely to give you money. Code only generates value when you ship it, though, so it’s important to actually measure production, not development. Also, our mental model of code is always subtly different than the code itself, so it’s important to actually measure things, because your intuition is not always going to be correct. You never know when someone’s added a sleep(100) in your inner loop!

Jonathan “Wolf” Rentzsch - Assumptions are Awesome

Jonathan’s talk was mostly about Design by Contract. He started off with a great throwback to the old C programmers in the audience, talking about the difference between K&RC and ANSI C. For those of you who weren’t alive back then, with K&RC you’d write functions like this:

void foo()
int bar;
{
        printf("fooooooo");
}

Weird, right? Anyway, the idea of Design by contract and Eiffel is that you can add annotations to your functions that enforce ‘contracts’: preconditions, postconditions, and invariants. For a pretend mythical Ruby example, you might do this:

# bar.nil? == false
def foo(bar)
    puts "Bar won't be false here"
end

He mentioned that this isn’t so much error handling, as it is an alternate type of testing, really: it’s about catching bugs.

Ariel Waldman - Hacking Space Exploration

Ariel gave a really cool talk about the maker movement and space exploration. She repeated an old mantra, “If you can’t open it, you can’t own it.” She also posed a really interesting thought question: What happens when space is as accessible to us as the internet is? Basically, more people should be looking at hacking on science, and not just code.

Here’s something that’s interesting: It’s really important that we work collaboratively on our hacking projects, because especially in science, not everyone knows everything: hardware, software, physics, biology… so we really need to figure out how to join these communities together and build awesome things. To do this, things need to be made “disruptively accessible,” they should be revolutionary, as well as easy to use!

She’s gave an example of a really neat site that her friends made, over at http://spacelog.org/ , which is a great example of nerds taking a terrible government website that’s buried all of its information in pdfs, and made it super accessible.

Jacob Kaplan-Moss - Writing Great Documentation

[Slides]

Jacob’s talk was really good, and he’s talking about something that I really care about: documentation. There’s a growing sentiment amongst developers around “Documentation Driven Development” as a way to produce fantastic documentation for your project, which is something that we too often collectively ignore.

He mentioned that talking about writing docs is kind of like listening to your parents, telling you to eat your spinach. Django has really taken this idea to heart though, and the Django docs are two times as long as the New Testament. He’s specifically trying to encourage building a documentation culture, in the same way that Rails really built a test-driven culture.

Jacob didn’t shy away from controversy, either: He declared that “patches welcome” is terribly user-hostile, and “use a wiki” is not an answer for documentation. Also, he made a strong statement that automatically generated documentation is basically worthless, because you really need to understand the underlying code already to use them effectively. He called Rubyists out on this: “You do realize that by using rdoc as your primary documentation, you are saying that you care as much about them as Java people, right?”

Ryan Dahl - Node.js

[Slides]

Ryan’s talk was bruuuutal. I happened to be sitting next to some Windows guys, and they were good sports: Ryan ripped into Windows over and over again, but ended his talk with a plea: “If you’re a Windows programmer, I have two questions for you. First, why do you eat poop all day? And secondly, can you help me? Because I really don’t want to come over to your room and eat poop too.” To their credit, they went up and talked to him after, and hopefully this will turn into a great feature for Node.js: great Windows support.

That was the main thrust of Ryan’s talk: the roadmap for Node 0.6. The biggest thing on the agenda is said Windows support, and it’s going to require a big internal re-write, because Windows does concurrency much differently than Linux does.

Gina Trapani - Your Community is your best feature

[Slides-ish]

Gina gave a really cool talk about the human side of open source. It really comes down to just that: projects are made up of people.

The point where Open Source became real to her was due to one interaction on a mailing list: atduskgreg offered help moving to git and kicking off a community. This act of kindness really showed her what OSS is all about: people coming together and building fun things.

There’s four things that are important to growing a community:

1. Enable peer consultation
2. Convert Newcomers
3. Cast a wide net
4. Help your project fulfill its destiny

She also mentioned that one person does not scale, so you need to design some process that will help you not be the bottleneck to your own project. It’s also important that code isn’t the only way that people can contribute to a project, so you should be open to people contributing blog posts, podcasts, or anything else that plays to their strength.

Gina also commented on the diversity of communities, and how important it is to get a diverse group together, because a monoculture will only produce software for that monoculture, and you’ll end up alienating users who aren’t like you.

She had one more great quote: “Make something meaningful in public, and the right people will join in.”

That’s it!

Day one was good stuff, but now I’m off to some parties! Like I said before, if you’re here, say hi, and I’ll have another wrap-up for you tomorrow!