I've written "a lot of code":http://github.com/geemus, both hobby and work, over the last year, and looking back I can't help but think that writing code for yourself is easy; it's writing code for others can be tough. In this session, I'll share some examples of good and bad practices gathered in my years writing code and libraries, and discuss how to get past being too close to the problem. I'll talk specifically about growing your work into something anybody (and hopefully everybody) will use.
Along the way we'll discuss the differences between code for yourself, code for other users and code for collaborators.
Some example tips:
- Help new users get started, but don't get in the way of power users.
- Examine the seams of your library and consider how you can keep it focused.
- Be consistent: more consistent code is easier for others to understand (and contribute to).
I'll also go over some examples of things to avoid:
- Don't monkey patching: don't muck with other peoples code, lest it muck back.
- Not invented here: once you start writing libraries it can be hard to stop.
- Exceptions: if everything in your library works like x, except y, then you always have an extra case to keep in mind.
I'll share a mix of concepts and concrete examples that altogether will help nail down what it takes to write better library code.