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.


19 August, 2013

The Allure of Small...

     When I first started out professionally in the ever growing realm of software development, I'd taken a position with a mid-sized company of roughly three hundred and fifty employees.  Given that it was my first grown-up gig, I had the common misconception that all companies functioned in a similar manner whether minute or enterprise just at a micro or macro level respectively.  I stayed with that company for close to eight years making a multitude of personal and professional relationships along the way.  It was only when I'd learned the inevitable fact regarding first jobs, especially applicable to software development in that the pay scale will never equal the amount of information, skills and experience attained even if one were to be at said company for two decades.  This being said, I made my exit when I was offered a position a small (less than 10 employees) financial startup in the suburbs of Philadelphia, Pennsylvania.

     The first thing I noticed was that the pace was definitely quicker.  This wasn't as glitzy a startup as another at which I'd interviewed (a company called Health Market Science which at the time was in Conshohocken, Pennsylvania) which was far more geek couture.  I was brought in to replace the existing PHP infrastructure with perl.cgi at the time (as well as the primary back-end processing scripts critical to meeting banking and fed. regulations in a timely (read daily) manner.  The first task with which I was charged was an ETL (Extract, Transform, Load) process from client content to our proprietary Goldleaf accounting software for ACH transactions.  This was a good first test and I passed with flying colours.  No sooner had I completed that task (in days) did I have a new project for one of the largest online Canadian gambling sites (solely a client, before the days of the prohibition against online gambling in the United States) to write an API for handling client verification via Lexus Nexus (which at the time had a different name which i forget) in XML.

     This had been the first time I'd been required to do anything with XML outside of a parse here or there, once or twice at my former employer for a one off project.  This is where I noticed one of the biggest differences between larger companies and leaner, smaller companies.  Had this project been part of my tasks at my former employer there would've been dozens of hours of meetings and the project would be measured in a timeline of many months, unlike the three or so weeks it ultimately took from conception through testing to production.  It was in this manner that subsequent projects continued for the next four or so years, even with the company being sold and my transition to CTO somewhere in the middle of all the work, and the building of a solid team of mostly college graduates though I was glad to have a slightly more experienced embedded systems developer which while not part of our required skill set definitely had his own approach to issues thanks to his more diverse experiences prior.

     Ultimately, the position ended when the company ran afoul of the US Government due to several of its clients causing issues for the US Postal Inspector and was ultimately shut down.  I was quickly snatched up to work on a contract with a Massachusetts anti-fraud retail software house called Retail Expert Inc. (eventually consumed by Tyco's Fire & Safety division.)  I was again in a very small, agile environment working with a single other developer building Python (non-web) real-time returns authentication systems for Burlington Coat Factory nationally.  This of course was in the context of being part of a larger company ecosystem but the project of allowing for tendered currency refunds on returns as opposed to store credit was really down to a small team outside of both my cohort and myself.  This was a contract and it was successfully implemented in time for Boxing Day (December 26th in the US) as expected with great results.

     Having enjoyed working with the smaller companies and their associated dynamic I moved on to another contract with an internet hosting provider with a total of three empoyees (not including myself) in New Jersey working on developing an aging, poorly written Perl codebase.  I established best practices, implementing Git version control and a system to push updates to all two hundred and twenty eight servers (at the time) in Python, long before tools like puppet and chef existed.

     I'm not going to continue with my past history at this point because this is about the allure of small, not my entire work history.  I would eventually delve back into the world of larger and even enterprise companies (as well as being a co-founder and lead engineer of other startups respectively) as I was testing the waters of what it would be like.  To stress my point there were quite a few observations which I have now solidified in my mind, based on my experience.

     Small teams, and small companies while lacking the raw capital (and operating costs) are far more capable of accomplishing tasks at hand.  This of course requires a more thoroughly vetted group of seasoned generalists (unlike the specialists more common in enterprise environments) as the importance and value on each individual in these smaller, more tightly knit ventures is much higher.  The one bus rule is very much applicable, more so than when the number of employees increases.

     Larger companies have considerably more red tape and seemingly superfluous meetings.  I say seemingly solely because it does vary from group to group, company to company.  When lack of understanding exists whether of ability, functionality and/or scope, the number of meetings will naturally increase.  This is further complicated by logistics of individuals involved from various departments and teams to the point that it can be debilitating.  The use of carved-in-stone technologies and the lack of ability to move outside of that realm seems to diminish as the size of an organization grows, primarily due to client contract requirements established early on and the maintenance nightmare which ensues.  However this does mean that while a company is firmly built using flat head screwdrivers and hammers, it is very difficult to implement the use of philips head screwdrivers and reciprocating saws when the tasks at hand are much better suited to said technologies.

     It was based on these earliest exposures to what smaller groups were capable of accomplishing, the speed at which they were able to adapt and the focus possible in direct contrast with my personal experiences at larger organizations, coupled with latter experiences whilst dipping my experiential toes into the bigger ponds of enterprise scale that I'd ultimately decided to only approach and work with the former type of companies barring few exceptions.

     The good news is that thanks to the ever growing market and need for the next-big thing, the proliferation of startups and the relatively low cost of entry into emerging markets for crack teams of agile generalists, the future looks pretty bright for myself and my brethren and sistren (yes, that is indeed the correct though fallen-out-of-use word) in the field of software development.