Ron Savage

This article is about the tension between writing code and owning code.

We all know about working for some organization (hereafter 'org'), which
ends up owning our code. I think the tension arises because we pour some
of our heart into each program, especially those we feel are well-written.

But we're uneasy with the fact that the resultant code isn't ours.

So, how do we reconcile this tension?

I thought about this for years, until one day I had an insight which I
feel resolved this issue for me.

The first step is to take your focus off the program you're currently writing,
and look at your history. Almost certainly there will have been a series
of such programs, written for a variety of orgs.

Now, stop thinking of them as programs, and imagine they are a series of
poems, paintings, sculptures, magazine articles. See the similarity?

The next step is to see that a series of creations, poems or programs etc,
are simultaneously all similar and yet all unique.

So?, you ask. Well, that means precisely this: You can write a program for
the org, and then - perhaps not immediately - go home and write a program
which is both the same and different.

It's just like someone writing a series of detective stories, all featuring
the same lead character(s). This could be a TV series - same people each week,
different story.

But how do we ensure it's different? By self-education. That means, reading
blogs, programs, etc, to absorb ideas, so that the next version of that
program incorporates new techniques.

It might be as simple as seeing someone (e.g. me) recommend a Perl module
such as Log::Handler.

Or you might choose to switch from a marvellous and light-weight object
system such as Hash::FieldHash to a sophisticated but heavy-weight system
such as Moose. I've done that, in both directions, and the code which uses
methods hardly changes. The biggest editing effort goes into the declaration
syntax.

And how does that help? Well, it helps if you're flexible enought to adopt
modules you've not previously tried. Ok, so sometimes the module does
not satify you the way you expect. Nevertheless, this is how you learn -
by playing with alternatives, and adopting some of those alternatives
in your new code.

As time passes, you read more blogs, consider ideas and alternatives, and
decide to use them. Even better, you weigh up the reputations of those
making these suggestions, and consciously decide to change the way you
write code.

The end result can be code which incorporates ideas from the program
written for org, and yet is re-written with enough differences to allow
you to feel comfortable that you haven't done anything unethical.