tl;dr

Keep it simple. You’re not impressing anyone.

Bike on Cliff

I went too far.

It was cool, but I got ambitious and started adding support for all sorts of weird uses. Now it’s no fun to work with and the API is more confusing than convenient.

It’s more impressive to make something simple that works well than it is to make something monstrous. As for APIs, too many options make it hard for users to adopt. In addition to the classic KISS and YAGNI principles, every little nugget of complexity added to your code makes it a little bit less stable and a little bit less maintainable.

Kill your darlings.

Ironically, this idea of mine was so simple initially, I was complacent with my commits. Basically, there was no history, no incremental steps to walk back to. I wasn’t totally silly, though. I followed TDD, so I had a bunch of unit tests. So how did I walk it back?

3 Step Plan to Reel it In

  1. Write examples for the ideal (simple) API in the README.
  2. Replace all the tests with the examples. This is a good way to prevent accidental lying in the docs.
  3. Hack and slash the code. Refactor out junk once we’re back on track.

Marionette

Done

list-tweaker is now on npm, in all its meekness. It’s not really something to brag about, but it is useful. That’s what I was going for initially, not something to showoff. As mentioned in another article, small, simple modules make the world go ‘round.