This is a picture of my bike lock.

There are many bike locks, but this one is mine.

I always put my bike lock on as seen.  My helmet with the lock running through the styrofoam (because, on the off chance someone wants to steal a bike helmet, they’d have to destroy mine to get it).  The lock running through both the front wheel and the frame, so that the wheel can’t be stolen–nothing sadder than a locked bike with a missing front wheel–quick release works well.  The actual lock (where I put my key) sheltered from the elements, both because the helmet protects it and because it is facing down.

After commuting on my bicycle hundreds of times and leaving it overnight a handful of times, I’ve determined this is the optimal lock procedure.  Not that I’m not open to new ideas–a few years ago I took my helmet with me, but then I saw someone lock their helmet like this and thought “what a wonderful idea!”.  But once I arrived at what seemed an optimal solution, I just put it on autopilot.  This frees up my mind to pursue other things.  It also means I have not analyzed the way I lock my bike in a deep way until I started to write this blog post, and once this is done, I won’t think about it for the foreseeable future.  The bike lock setup is settled.  I’m always looking for other aspects of my life to settle, while still being open to possible improvements (if you lock your bike differently, let me know!).

There’s a similar tension in software development.  On the one hand, I want to be open to new ideas, frameworks, concepts and solutions.  On the other hand, it can be easy to go after the newest ‘shiny thing’ every time, spin my wheels, and not accomplish what I need to accomplish.  One way to the latter issue is to make some decisions in my work life.  This can range from the trivial–I have used the same aliases file for over a decade–to foundational–I only work on the unix stack.

Sometimes settling constraints are imposed by the project–it’s a RoR app that needs to be upgraded, or there are already extensive java libraries that this application will use (and that can mean that you won’t get the gig or the job).  Time also can be a limiting factor–deadlines have a wonderful way of focusing you to work on the problem at hand, rather than running off to explore that new library.  It’s also important to realize that you can settle the trivial–what shell you work in, what OS you use, how you lock your bike–which lets you focus on the important–the app you are writing, the restaurant you biked to.

(Of course, what is trivial for some projects may be foundational for others.)

When you are working on a side project, sometimes settling on a technology can be hard–it is more exciting to explore that new XYZ rather than grind away at a bug or a new feature in an app that I’ve already written.  But, in the end, extending and shipping an existing app almost always is more rewarding.

We software developers live on a knife edge–on one side is irrelevance, though it may be profitable (COBOL), on the other side is flitting from new technology to new technology (whether it is Erlang, Haskell, NodeJS or something new) but never mastering them.