Yan Pritzker photographer, entrepreneur, software engineer, musician, skier

How to win friends with Maintenance Driven Design

Posted 4 April 2012 @ 6pm Tagged code, thoughts Comments: Be the first!

When I come to a design decision in writing an application, script, or interface. I ask myself only one question: What will the next guy think? I call this Maintenance Driven Design. By designing your software to be maintainable, you will earn many friends and praises.

As software developers, ops guys, designers, it is a known evil that we sometimes choose shortcuts, accruing tech debt with the knowledge that we’ll pay for it later with considerable interest. However, there are a few categories of design choices that we make every day that will make software easier or harder to maintain for the next guy who comes after us, which are specifically evil and malicious forms of tech debt.

Here are a few basic categories that most non-Maintenance Driven decisions fall into. Please don’t be that guy :)

• duplication – This is the cardinal sin against Maintainable Design. If you duplicate code, it will instantly grow into piles of subtly divergent crap. It would have taken you an additional hour to figure out how to do it in a non-duplicated way. It will take your maintainers half a lifetime to understand why and how the code has diverged. My own anecdotal experience says that duplication has about a 1000% tech debt interest rate. That is, 1 hour saved by committing duplicated code will cost you 10 hours down the line. And this interest is compounded over time as the code diverges further.
• clever code – Clever is the enemy of Maintainable. Every time you cut and paste a really cool hack that you found on a blog in 2006, a unicorn dies. Follow conventions, and use existing and accepted practices instead of reinventing the wheel.
• personal aesthetics – Having a strong sense of personal style is awesome. You like snakeskin jackets and neon green pants? Sweet. But leave it out of the code. If you have a personal style that goes against accepted conventions, and you choose to prioritize your style over that of the community, you are not Maintenance Driven. When in doubt, look at the source code for a large community supported project (i.e. Rails) for style ideas.
• poor naming – Single letter variable names are impossible to grep for effectively. Names based on your favorite ninja turtles, though they will win you points with me, are bad for business. Same goes for commit messages – don’t write something clever and witty at the expense of clearly explaining your changes.

Vim – Navigating files in vertical splits

Posted 12 March 2012 @ 11am Tagged vim Comments: 14 Comments

The two most useful native vim mappings for navigation are arguably gf (go to file, use it over any reference to a file, such as a Rails partial), and Ctrl-] (go to tag, use it over any class or function name). But one problem in vim is that by doing these commands, you lose your previous place. Sure it’s easy to go back to with Ctrl-O or similar, but I find it much more useful to open the new location in a split, as you are usually exploring them while retaining the current context. Here are two mappings that do that for you:

If you like these, you might want to check out my Yet Another Dotfile Repo project, which includes these and more!

The cleanest vimrc you’ll ever see

Posted 20 January 2012 @ 12pm Tagged vim Comments: 25 Comments

So many of us use vimrc files that are a frankenstein’s monster, cobbled together from spare parts, gists, and snippets from wikis. One day I decided I was no longer going to treat my vimrc as a garbage dump. As programmers, we strive toward well factored code, so why do we accept such ugly vimrc’s that are impossible to understand, and even worse impossible to share because of their complexity. Let’s stop the insanity! It turns out it’s very easy…

Since vim automatically loads everything in ~/.vim/plugin/, you can just add a directory like ~/.vim/plugin/settings and put each semantic piece in its own snippet. Put your keymaps in ~/.vim/plugin/settings/keymap.vim. Put your visual setup like font and colors into ~/.vim/plugin/settings/gui.vim, etc.

After I did this, I ended up with a vimrc that’s only about 90 lines long including very detailed comments about every section.

I think this is the cleanest vimrc you’ll see on the web. All my vim plugin settings are broken down into individual files, following a convention of one file per vim plugin that I use, plus some extra ones that are too small to be plugins.

Think your vimrc is better? Show me! I want to learn :)

My vimrc and the rest of my vim setup is available as part of my YADR (Yet Another Dotfiles Repo) project. Come check it out, I need alpha testers!