Keeping an eye on what matters

June 8, 2007

Maybe I am just getting older, but I’ve found that my perspective on what matters in software has shifted quite a bit.

I see so much discussion and thought about things that really in the end, don’t matter a whole lot. Or if they do at all, they only matter to developers. For example, an IRC discussion about whether packages should have capitals in the names. Revision control choices. Whether packages are sharing code enough. Whether files go into /usr/lib or /usr/lib64.

I think what I’ve realized now is that in software, these kinds of things are actually endless. You could spend your entire lifetime doing things like making sure every package in Fedora accepts CFLAGS correctly, or making sure that all the modules in GNOME share as much code as possible.

What I personally have been trying to do recently is keep in mind a target user when I’m thinking about problems. Last night while eating at Boloco I walked by a guy running Linux, so I stopped to talk to him. Turned out he was a programmer working for Tripadvisor. I actually used their site recently when scheduling a trip to Portland; they have an awesome Google Maps mashup with their hotel rankings that I found incredibly useful.

How much would this guy care about capitalization in package names? Not at all.

I know I’m not saying anything new here; it’s a well known problem. And I’m not saying none of this matters at all (in particular Subversion annoys me a lot); but you have to have a good sense for when to tackle things and when not to. I won’t complain if I have to use Subversion, it’s just not worth arguing over.

Some random thoughts on how to avoid technical holes:

  • Write in Python or another high level language. In C, just getting a socket open or something can make you feel like you accomplished something. It’s pretty hard to reinvent the wheel in Python, because so many awesome wheels already exist.
  • Never write the library first. Or at most, write the application (what matters to users) hand in hand with the library.
  • Get something running on to the screen as quickly as possible.
  • Make it cool. Make it something that someone wants as soon as they see it.

I’m sure if the younger Debian developer version of me of years ago had seen this blog entry now I would have thought I’m on crack =) I guess I do have to admit I learned something from that time.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: