Showing posts with label Larry Wall. Show all posts
Showing posts with label Larry Wall. Show all posts

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.


15 April, 2007

The Importance of Being Passionate About Coding

Throughout the years I’ve worked with a considerable amount of software professionals and have known a countless number of computer enthusiasts.  I dare say that the number of those who are passionate about their involvement in the aforementioned fields is far greater in the latter of the two groups.  I wasn’t going expound about this topic for some time but a recent phone call from a previous semi-co-worker (an employee where I recently held a contract) who had just returned for forty days in India learning some new technologies.  


    I have personally seen a multitude of coders over the years who were quite competent (or close enough) at what they did in terms of developing new systems or upgrade existing ones.    What I don’t see as often is that elusive fire that burns within the not-so-common coder, software engineer, developer, etc.  Some of you may be that person or know that person.  The one that is incessantly infatuated about this new algorithm, concept or design which might be revolutionary or simply solves a problem in an elegant way.  


    Even if you don’t know someone personally, you know of people like this.  In the spotlight we know of people like Guido van Rossum, Larry Wall, Donald Knuth, Kernighan & Ritchie.  Mind you not all amazing coders are language developers, though I would fancy a guess that most if not all of those who have the yearning for their craft have on one or more occasions figured out whether on paper or in their heads a way in which they would design a language or re-work an existing methodology to make it better.  


    Coders with this mindset and thirst don’t operate this way for fortune or fame, they do it because they have a natural yearning to create, design and improve solely for the purpose of knowing that whatever it was they needed to do was being done right.  You might recognise these people by their visible expression of excitement when discussing a new piece of code they worked on or a problem they re-worked.  However it is usually more apparent when you speak with them about coding in general.  Their eyes widen and you can hear the infatuation in their voice.  They sound much the way they did when they first discovered coding whether it was as a child or as an Adult.  That’s the fire and passion I’m referring to, and it is my hope that everyone, coder or not, gets to know at least one person like this, even if they themselves are one of these people.