28 August, 2013

A Rebuttal to Keeping the Source to Everything One Writes Publicly Available...

     A little over three years ago, I chimed in with my views to an absolutely wonderful article by Nathan Marz on his blog, "thoughts from the red planet".  It was entitled "How to get a job at a kick-ass startup (for programmers)" and I do recommend reading this if you have any interest at all with following and/or joining a startup.

     One of the points he brought up was regarding maximizing one's personal brand, which included making a website with one's projects listed, links to GitHub repositories, etc. to which I responded in kind:

The whole concept of having tons of publicly accessible side projects and/or one is able to just whip them up on a moments notice simply for filler to show abilities is fine and dandy if you're 20 years old. If you've been in the field working for private firms and/or clients for the better part of two decades, raising a family and what not, that isn't going to be your top priority. 
Much of the code I write on the side is for me and I have released some software here and there, but executables. I share code when I choose to, after all, my creation, my choice. I'm happy to discuss and go over bits and pieces of some of my larger side projects as an example of my capabilities and passion for my art however making the source available just isn't always in the cards and we have seen a very unfortunate change no thanks to people like Richard Stallman who think they have a right to touch someone else's work simply because it exists. 
In my roughly 16 professional years as a Software Engineer I have worked in companies of all sizes both as an employee and as a contractor. I'm actively part of a startup as well as contracting long term with a group of media companies and in all of that time, I've never had a problem attaining great positions with wonderfully talented people despite not having a git hub account or dumping all of my projects source trees and repositories to the four winds. 
People need to consider that there are many of us for whom personal time is limited by responsibilities other than code and as much as we might want to dedicate the rest of our breathing moments to making great software for ourselves, we have to settle for doing so on someone else's time. Which is just fine for me, as coding makes me happy even if it isn't my own idea or time on which I'm doing so.

    All too often there is this assumption that everything one writes is free for everyone else to see.  Just because one codes for themselves does not implicitly mean that they want to give away what they've written, nor does it mean that they want everyone (or anyone else's) assistance and/or input.  Many of the personal projects I've written have been lifelong experiments/challenges for my own personal joy and growth.  Sometimes it is merely re-inventing the wheel because I feel there is a better way to do so, and sometimes this proves to be correct.  While I'm quite glad that there are others out there sharing their creations, primarily those writing languages free for all to use, I do not feel beholden to share everything I create.

     I'm also an artist having sold many paintings in several mediums.  This doesn't mean that I want others to take my work and 'mess' with my vision.  The personal concept of "mine" seems to be less prevalent with the younger coding crowd these days.  This is a matter of personal preference, though when it becomes an expectation, one of communal works and their derivations, I take offense at that assertion.

     I have also been responsible for scouting out, mentoring, interviewing and hiring a number of developers over the years, and while seeing examples of projects they've done can be pleasant, it was never a requirement or of any real factor in my decision making.  I've been of the mentality that I don't want someone who knows everything, I want someone who knows how to figure out what they don't know when needed.  I'm fairly fond of the method of assessment based on requesting a simple program be provided by the following day in two languages that I choose, that I am sure the applicant has had no exposure, but I digress.

     My primary point deals with this being a generational issue, one that needs to be made more apparent.  Passionate developers young and old have a thirst in them, though how that thirst is quenched varies from person to person, situation to situation.  Many of the younger developers I know spend much of their personal time coding, which is wonderful, especially in their early careers wherein their experience is less polished.  The majority of my friends are hovering around their forties and have families which take priority.  That doesn't make the thirst any less present, it simply means that the means by which satisfaction takes place is handled via their paid contracts and/or salaried work.  This is all the more reason to find jobs of interest and not simply accepting 'any' position for which one is qualified as there are multiple purposes now being served due to the lack of personal time for such activities.

     As an aside, this does not mean that there aren't those out there balancing family lives and open personal project repositories.  It simply means that when assessing potentials for positions, to borrow from Larry Wall's Perl mantra (TMTOWTDI): "There's more than one way to do it."  Please keep that in mind next time you're in charge of talent acquisition for any company startup or otherwise.

No comments:

Post a Comment