In Defense of the Lone Code Archetype - Part 2 (The followup)

Roughly half a decade ago I expounded upon the virtues of the lone coder archetype, which was in response to a flurry of "______ is the one-true way^tm" where said blank could have been XP, Agile, Hierarchically Big-Team Structured Environment, etc.

I feel it necessary to further discuss the situation by pointing out the environments where the aforementioned 'mindsets' (as it were) just do not cut it. I'm not saying that these various means and methodologies don't have their place or purpose. I'm saying that there is no magic solution that fits every environment.

First and foremost let me point out that while I currently find myself working for the corporate behemoth that is Comcast, I have primarily functioned in extremely lean staffed companies/start-ups and I do enjoy the environments regardless of all of the negatives resultant from their miniscule size(s). Many of the methodologies against which I argue as not being the end-all-be-all or one-true-way just simply wouldn't be a great fit for these smaller, faster environments. I'm talking about companies in which there is no QA department. There are no "project managers" outside of those coding individuals doing the coding. There are no dedicated "scrum masters" to keep focus and direction.  Turn around time for a project can be anywhere from 18 months for a massive project to as little as 30 minutes for a last minute 'big money deal' directly arranged by the owner of the company.

I can't say that I love all of those really hair-raising tight-deadlined projects, but I can say that I do find myself thriving in such environments while I've watched others come and go, not being able to make the cut in such an unstructured (comparative to textbook scenarios and larger companies) work space.

I don't want to send the wrong idea here though. Proper design, implementation and testing methods need to be utilised, though in many cases the specific type will vary dependant upon the various variables (time until deadline, technical requirements (formal or otherwise), availability of those requesting said application(s) and/or change(s). All I am stating is that talk of scrum methodologies, stand up meetings (even if only for 5-10 minutes tops daily), etc. just don't cut it in these environments. Entire projects sometimes need to be not only designed, but put into production in less than an hour's time while all of the normal daily actions take place.

Before anyone starts to think that "these tiny companies aren't worth it", I will clearly state that with rare exception, all of the aforementioned companies (if only by reference and not by name) have been and/or are rather profitable, more than worth the effort. I will state that I have both seen individuals who whilst highly capable in their own right fail miserably as well as those who happen to be incapable of coping with the frustrations of not doing daily work in a manner conducive to that which they learned in college.

There is ultimately a place for everyone, but for the truly cutting edge companies such luxuries as what would seemingly be order, structure and time frames simply don't exist. It is also a world in which competency pays/paid off for those willing to cope with things during those really hectic moments.

Now before anyone starts the tirade of "these environments aren't sustainable" responses, I will state that as the companies each find their own groove, the hopes are that there'd be a bit more consistency, planning and structure to what can otherwise seem a bit of guided chaos, though more oft than not, this isn't the case.

Lone coders fit these environments but are of a specific mould.  Those constantly needing direction or looking for hand holding need not apply as these are the kinds of environments where learning the process as well as what are deal makers and deal breakers must be done swiftly because the calls made in all areas from architecture to one-off applications need to be done unapologetically and with the future in mind by said lone-coders.  Luxuries such as access to others capable of having half of the answers remains just that, a luxury.  It takes individuals of a certain mindset which brings to mind the commercials for the US Marines, which can be equally applied (for different reasons).

"The few, the proud (albeit questionably mentally unstable though surprisingly effective), the lone coders."

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.

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.

The seemingly separate world of tiered development enclaves.

I realise the subject of this post is a bit of a mouthful but it was the best I could do to summarise what I'm thinking.  In the world of software development there are often a series of cliques based on languages and/or platforms.   In other words, we have our Java/C#/Python/Ruby/Erlang/Scala/etc. running on Solaris/Linux/FreeBSD/Windows platforms.   There are tight knit groups fervently gathered around almost any combination of those two collections.

The impetus for this rambling is that there are expectations that each group places upon everyone regardless of group.  For the Java/C# crowd, as an example, there is an expectation of certain protocols and mannerisms of doing things such as the use of SOAP and XML for webservices or the Python/Ruby/Node.js equivalent crowd touting heavy use of JSON and ReST based systems.  

What amazes me is that the more closed in a group, the greater the expectation that the world does everything the same way seems to grow, not shrink.  Note that this doesn't imply everyone, just a surprisingly larger number than anticipated (by a long shot).  I don't mean to imply this is across the board with no exceptions.  People used to working with web services in Java utilizing SOAP and XML seemingly care little (and know less of) the more current alternatives such as JSON and the various frameworks and standards.  This is a problem because it leads to an adversarial misunderstanding which I think holds back collaborative situations as well as opportunities to expose individuals into a more cross environment manner of function.  

I know that with my near-two decades of professional experience that I have worked in a core of languages (Perl, PHP, Python, Javascript, Ruby, ARexx, Pascal, etc.) with a series of acronym based technologies and formats (JSON, XML, PostScript, YAML, etc.) but that there are people out there flabbergasted to find that I've never had to work with CORBA, SOAP, XSLT, COM or even something as innocuous as certain frameworks whether Cake, Struts, Catalyst, .Net or Seaside.  

The reaction is often one of shock and confusion because for so many, the entire world revolves around a solid set of standards, practices, protocols and languages which without, so many would feel like a fish out of water.  In reality there are only so many ways to write an 'If loop', or an iteration over objects in an array/list/hash/tuple/set, etc.  There are only so many ways to re-implement MVC frameworks or 3rd party libraries.  

I often make it a practice to keep current with the langauges, frameworks and protcols of my not-so-close (codebase wise) friends so my familiarity is there, and has actually benefitted me during technical interviews over the years.  This ties into what I'm saying, I will come back off of this slight detour.  I was at an interview for a perl position at a large development company in the King of Prussia, PA area back in the early 2000's and it involved a 6 hour interview process on-site.  I will spare most of those hours but there were two 45-60 minute interviews that stood out.  The first was on 'C' followed by 'Java', neither of which I've coded professionally (or personally for any non-learning period of time).  Keeping current did help me muster my way through the concepts and what not, albeit barely.

This is where I bring it back to my original point for this post.  A couple of years later down the road during a technical interview for a job in a language/environment which does not have the concept of 'interfaces' (as in the C#/Java sense (to name a couple)), I was asked such a question.  I first pointed out that interfaces don't exist in the target environment as it does in C#/Java, and then proceeded to give a crude explanation on how those are used in Java.  The sound on the other end of the interview table was subtle but noticeable; One of confusion as to how someone doesn't use such constructs (or the fact that not all languages/platforms uniformly implement the same exact concepts).

It really comes down to education, in both directions (and I'm not implying academia to be clear).  Engineers should be able to keep their familiarity with other languages/platforms current enough to be able to understand those difference between both their local toolsets and those of everyone else (to a reasonable degree).  Just because I don't code in Scala professionally doesn't mean that I shouldn't read articles about Scala's 'traits', or that I should ignore a different write-up on Groovy on Grails despite not using Groovy or Grails.

This also means that those engineers of the Microsoft stack should at least familiarise themselves with what Django is, a bit of Rails, maybe some PHP and Perl, a little bit of Lua and Lisp/Clojure/Scheme, etc.  In a former situation I ended up taking the development lead in a Microsoft heavy envioronment writing Classic ASP for the first (and preferably last) time, so I've practiced that which I preach.  Knowing some of the pieces that differentiate the languages also give insight into work and processes that may be missing from our own stack(s).  Our corpus of knowledge collectively shouldn't have such extreme gaps from discipline to discipline because it as a whole divides us from possibly creating the next big thing as well as (maybe more importantly so) fulfilling our individual potentials as developers/engineers/creators.

So take this as an opportunity to visit that neighboring x/y/z technology users group, maybe even a smaller convention/conference to get uncomfortable yet ultimately expand one's own horizon and knowledge-base.  Only good things can come of this.  Continuous improvement doesn't solely refer to processes and applications but people as well.

They Say That Time Will Tell.. Ruby Revisited - Part IV

I've written on multiple occasions regarding my flirtations with Ruby (the language) and my ultimate feelings of it falling short of the mark.  I first experimented with Matz's creation in 2003, some 8 years after his initial release.  My first foray was not for professional purposes, but exploratory as a means to best express what would eventually become the SimulaE project which I ultimately crafted in Python.   I did end up writing a machine learning/route optimisation experiment mimicking hospital utilized medicine delivery robots I'd seen at Abington Memorial Hospital in the prior months.  

My conclusions were that Ruby was still too TMTOWTDI than I'd liked.  It all smelled heavily of Perl, which after using for almost ten years (at that point) was less than desirable.  This was long before Rails existed, and it would be another five years before I took another serious look at the language (post Rail's introduction and the famous screencasts which accompanied it).  

Yet here I am five years further down the road from my last foray with the language named fondly after a gemstone.  At this point, I've been coding professionally for over eighteen years, and in general for well over three decades.  I've grown up quite a bit and realised that it was my own issues and pig headedness along with some errant expectations which led to me ignoring Ruby and embracing Python at being closer to the hypothetical "one-true-language."

Years of writing in the BDFL's (Guido van Rossum) creation stemming from the ABC language has done wonders to clarify my deeper understanding of engineering principles, clean code design as well as inconsistencies and even MVC frameworks (Django from v.96-v1.4+).  I believe that it was actually through my understanding of Python interspersed with larger monolithic projects in Perl that drove to my moment of clarity regarding Ruby.  

Don't get me wrong, it wasn't solely the above which led to this epiphany though.  What really finalised it for me was the wonderful Ruby Rogues, the Ruby Freelancer's Podcast and various other podcasts involving Charles Max Wood.  The sheer vastness, diversity and information, knowledge and experience sharing within the Ruby community caught me... hook, line and sinker.   Note: This is a different community (from my own observations) than the Ruby community of Christmas Past as 'eloquently' espoused by the always-blatantly-honest-with-words Zed A. Shaw.

I won't go into the details about what it is in general that made me finally get Ruby this time around but I will say that the recent improvements in the language as a whole and the more natural flow of constructs and method chaining resonate with me as a engineer and polyglot.  The efficiency of :symbols, the consistent smalltalk based mannerisms regarding method invocation and lest we forget the flexibility of code blocks.  I simply leave the reader with this.  Check out the links I've provided.  Listen to the podcasts, try some of the exercises and give an honest assessment of what Ruby has to offer.  I'm really glad I did and now wholeheartedly look forward attending the next Ruby convention which avails itself to my schedule. 

Invoking the inner Howard Roark, for the Sake of one's sanity.

I was listening to episode 059 of the Freelancer's Podcast (formerly the Ruby Freelancer's Podcast) during which the discussion of handling burn-out arose.  That issue in itself hasn't been a matter for me for many years as I've learned how to balance work/personal/familial/etc time quite a few eons back.  It has even been referenced from other associates and one fairly recently (see: Tal S. Raviv's "Customer's Over Code" blog from the founder of Ecquire.com at http://talsraviv.com/2012/10/21/burning-out-startup-founder/), but it did get me thinking.

What really stood out about this podcast was how on-the-ball the hosts seemed to be regarding controlling expectations and ensuring a balance in one's life vs. work.  You are not your job, though that's not to say you cannot be passionate about it, or that it doesn't play a role in who you are as that would be a blatant lie.  In our profession (I cannot speak to others' professions) I have seen time and time again the level of life breathed into both companies and projects alike with all the eagerness to continue efforts with a constantly renewed sense of vim and vigor.   Again, this is not a problem.  The problem is when factors take all that is good in these delicate balanced recipes and throw the odd spanner in them, messing up the works.

For sake of argument, I'm going to give two examples of environments non-conducive to keeping that balance of personal/work and ultimately happiness and what it takes on the personal level of the engineer/developer/insert-professional-role-here to make it work.

Firstly we start with the bad: company F.   This company is a large established corporation with a half-billion dollar annual revenue and a considerable amount invested in technological infrastructure.   The core problem?  At it's core a system that was written by a non-developer some two decades ago  that served its purpose in smaller scale but when retrofitted to grow to the demands of a huge system against its design required a staff of fire-fighters.  Sometimes this happens but it usually involves a means of correcting the core issues not just throwing more fire-retardent chemical upon its base.

Company F is further harmed by sentimentality and assumed-correctness by the original developer, now a executive member, which has caused questioning of said codebase to be verboten.  Compound this furthermore by developers, many on the team who are quite capable and talented not knowing how to say no.  This lead to an expectation of 60-80 hours a week being the norm which is contrary to all of the known credible studies which show effectiveness diminishes substantially and error-creep rising sharply after a certain amount of hours in a given day be applied directly to development functions.  Self respecting developers who are worth their résumés' contents don't fear for their jobs as if it is the only one available to them.  They don't stay in situations where this is such an unwillingness to make the necessary changes to a core system is present due to one individual's sense of emotional connection to what they feel embodies their greatness/mental superiority from days long past.  Good developers and engineers recognize the situation for what it is and leave for greener pastures or they self-immolate trying to play role of code martyr/firefighter.

Secondly we come to a whole different beast: company E.  This is a much smaller company but of the same age as Company F albeit with an annual revenue at a dwarfed 2.5% of the former.   Company E was a brick and mortar business which traded hands via acquisition through the years and despite having a technology infrastructure, it lacks any actual capability in its development department's management.  A tar-pit that many older company's have falling into has been similar to this:  Making a conservative move into development in-house but re-positioning unqualified individuals into decision making roles and leaving them there for so long that they have no only garnered an unwarranted reputation for having skills they never acquired, but they start to believe they are on-the-ball and a player in the field.

This is one of the most dangerous scenarios one usually encounters (in most any field).  Someone who knows just enough of the bare minimum to be horribly dangerous because they can sound like they know what they're doing to the higher levels of management that are clueless on matters such as this.  This leads to some very large sins in the industry, over promising product and providing timelines which have no basis in reality.  These are company relationship killers.  This is a scenario where the individual making the decisions think they know when in reality they are the least knowledgable,  yet their wield a title (and that air of knowledge wrongly attained over time via entropy of concern by those around not directly in the field).

The solution that mentality leads to is similar to company F's perpetual firefighting, but worse on several points, primarily being a smaller player in the field therefore being more fragile if deadlines are missed and secondly, though equally as important is an expectation of the all-hands-on-deck (lack of) work ethic also in perpetuity.  This leads to low morale, a complete lack of trust and a decline in productivity overall.  Software developers/engineers are smart individuals and some of the largest technical companies have realized this so far to the point of letting the animals run the zoo (removing managers) with generally greater success.

Where am I going with all of this?  Expectations work both ways, and they must be managed.  This is where the Howard Roark reference comes in (for those not familiar with "The Fountainhead" by Ayn Rand from their high school or college days).  In this profession there is oft times a dichotomy between managers and engineers who are ultimately trying to accomplish the same end goal.  All too often it is at the expense of the creator/engineer/developer by those who gain their positions of prominence through abuse of that relationship and a one-sided over-bearing controlling of expectations.

How did I get here from where I started this post?  In the Freelancers podcast, it was stated something along the lines of "I inform my team members/company with whom I'm contracting that I have obligations and will be leaving at 6pm sharp."  I too have these obligations and have made it very clear over the years (especially as I grew in my abilities and experiences) that while I have a love of building great product, and that I am paid to make money for those to whom I've contracted, that I also have other responsibilities that I hold of equal or greater value and will not allow those to be intruded upon.  I  am also not saying that there isn't any flexibility, and I say this as someone who worked for three startups simultaneously whilst raising a new born, I can personally attest to having slept consistently under four hours nightly for over a year's time.  I put in the necessary time, but I have a heavy say & input on when that additional time is implemented due to my other highly valued responsibilities.

On a related note, every time I hear a junior developer offering their own personal time (on a regular basis) to finish a project or start a new one I get frustrated.  They're being played for a fool and those doing the playing (the managers, etc.) will reap rewards for the other's 'dedication' and uncompensated offering of time and energy.   A pat on the back or a $10 gift card for what in billable hours would total something closer to $750.00 is an insult.  Atta-boys are nice, but not at the expensive of dignity lost due to failure to accompany said praises through proper reimbursement financially.

We must hold steadfast to principles that guide us for our own health's sake, our sanity and our livelihoods respectively.  This requires being willing to turn down the great sounding contract, or resigning from a role wherein that kind of abuse of working relationship has been introduced.  When we're younger with less of a portfolio, knowledge base and considerably more naïve, we see this as a rather scary suggestion.  It is only once time has passed, that many of us realize that we're the ones with the power as we have the skill set that solves the problems, produces the great product and ultimately wins accolade's for & from our client(s).  We need to continue to demand the compensation for the fruits of our labours and not let that compensation be seen as a benevolent gift, guilting us into indenturing ourselves to do further uncompensated works out of some emotional bondage.

We need to see ourselves as the professionals we are.  This does not come without us as individuals demanding the respect for our roles and capabilities that we indubitably possess.  We can do great things and overcome seemingly insurmountable tasks/projects but for the sake of our respective individual health, sanity and our art, we must do it on equal footing, not someone else's unrealistic dictated terms.  We are all business people forming contracts with one another, it is simply up to us to ensure that we're not getting the short end of the stick and even more so important to ensure that the individuals on the other end of those contracts know this as well so as to end this abusive cycle of unrealistic expectation and abusive of professional relationships.

Why Defined Coding/Operational Standards Matter in Modern Software Engineering Environments

After a brief stint in the hellish 1990's world of programming in Perl for a half-billion dollar company for a few months before the realisation that it was indeed a living code base designed and maintained (I used the word loosely) as if it were still two decades prior, I accepted a new client in the position of Lead Software Engineer & Architect at a local company in Montgomery County, PA, USA.

Much akin to what I experienced at the aforementioned company, I found myself in a microcosmic variant of my former employer save for the fact that the system I am to replace is written in ASP Classic on an older IIS windows centric system.

These situations are not at all uncommon in the real-world, and hopefully they are diminishing at an increasing rate.  This is not me condoning the carte blanche manner of always re-writing an existing system from scratch whether than includes changing the existing infrastructure (for better or worse).  Each instance/environment must be assessed individually along with company goals, available budgeting and forecast to ascertain whether or not such an approach is viable.

Bringing this back to the core reason for this post is that a well defined coding standard didn't exist for either environment, not to mention a revolving door of people assigned and/or employed which had a hand in touch either system.  Both environments differed in that one was a fairly modern agile approach with daily scrums, open communal work spaces and solid department leads for projects and that the other was very much waterfall design based, separated (officed) individuals with little communication and a lack of leadership in terms of working environment understanding (though a solid understanding of the business logic and customer relations carried this disconnect for without it, all would have faltered).   Neither environment possessed nor utilized any semblance of coding standards.

What kind of standards are we talking about here.  The whole gamut is my best response.  How are function names derived, how are attributes accessed, how are constants, classes, variables, methods, etc. named (verbs for methods, ambiguous/nonsensically, etc), typed (cAmElCaSe, alllowercasewithoutbreaks, properly_divided_with_underscores, ALLUPERCASE, MixTUREoFMeans, wthtvwls, etc.).  No set rules for braces or brackets (K&R vs same line), indentations (2, 4, tabs, spaces?).  Lengths of lines, length of method calls before being broken down.  Use of native data constructs.  Rampant string concatenation and massive use of type casting instead of a well kept control of expected content.  Complete lack of logging and little if any use of exception handling (where available).  Poor hiring practices which allowed for a single point of decision to be made either based on a inconsequential question about the language du jour at a given company or because the hiring manager lacks any breadth regarding software engineering both in practice and theory and does not do group interviews with potentials as a precautionary measure.  Lack of enforcement (or implementation at all) of code versioning systems/controls, proper QA practices, etc.

All of those situations were (and still are) prevalent in the existing systems, as well as many more which I will not get into now (solely because there isn't enough brain bleach to forget that they still exist.)   What I can do is point out that because of the lack of all of the above, both companies (while still in existence):

- Find themselves over the years running into longer lead times for changes which would otherwise be quick and simple.
- Experience bug fixes which require lead times of weeks due to lack of documentation, version control, communication amongst peers and of course proper reviews up front before production pushes.  - Struggle to keep current due to lack of faith in the infrastructure of existing systems that any new code would cause massive breakage and production down time.

This is never the way to run a company and after roughly two decades in the field professionally, it is disheartening to have to endure.  There is a light at the end of the tunnel.  The former company mentioned has a few good remaining people that provide a glimmer of hope for change in the right direction if they can convince the powers that be (ego and all) through all the crimson coloured tape that  these changes are necessary which could lead to the arduous process of modernizing.  The latter company referenced has already made that investment both with full ownership backing down the entire hierarchy of the org chart, and in that case, influenced heavily by yours truly.  I see much greater things for that latter company because it has done the realistic self assessment and see that much is lacking, ultimately choosing to do something aggressive to resolve the situation with a great outlook towards future business.

Hopefully we can see more and more existing companies learn from these examples before they find their up and coming competitors who embrace a method to their madness soaring by and taking their bread and butter in the process.

Rediscovering an old friend, Perl.

It has been over half a decade since I was paid to code in Perl, having since moved on to Python amongst other languages.  I use the past tense because this is all changing once again.  Due to circumstances that are almost entirely personal-life related, I find myself moving on from Yorn after the past fifteen months of doing great things with wonderful, intelligent and foward-thinking people.

After months over two months of screenings, phone interviews and an on-site meeting, I have accepted an offer as Production Lead Engineer at Fanatics, LLC at their Conshohocken, PA facility.  I'm going from working in a Python/Django environment for the past half decade plus into a more systems/internal middle-tier/core environment based on an old friend, Perl.   And despite some of the issues which led to this change, I'm wholeheartedly looking forward to it, and here's why.

As we grown our personal knowledge in a specific discipline, in this case programming languages, our perspectives and approaches mature.  When we step away from our comfort zone into some new experience (or language in this case) as I did professional when I moved on to Python as a requirement of Retail Expert Inc, CTO (at the time) Andrew Sernekos, I shifted mentally and learned the way of the Pythonista.  As the years progressed it became the 'one true way' of thinking, which was fine given that my language dictates were in-line with my choices and professional tasks.  I had put aside my TMTOWTDI (there's more than one way to do it) mantra from my Perl Monger/Perl Monkish days of yore.

Refreshing my skills back into the primary language through which more than half of my professional career was built, Perl, has opened my eyes in a way not previously possible.  The memories I had of Perl with its heavily flexible manner/varieties of expression had originally left a negative taste in my mouth but now having disciplined myself cutting through Python, Groovy, Scala and others has proven to expand my view of what Perl truly holds in terms of power.  With great power comes great responsibility and now with the modules from CPAN such as Moose and its derivatives (as an example), the future is looking quite fascinating again for me with a language that has been around now for 35 years.

Here's to the joys of the future and best wishes for the incredible team at Yorn as a sail on to my next contractual adventure.

Theorising vs. Doing

Over the past many years I've found myself slowly moving (in my personal projects) from the realm of actually implementing code about which I've been curious to spending my overwhelming majority of my free time to theorising about various concepts and/or interests, primarily in the field of human language parsing, simulation and simplification of generic real-world object modelling.  Several of these have been mentioned and explored in previous posts over the last 7 years.  

I believe a great reason for this change in focus is partially age, and primarily due to the extent that my days are focused on building the next great startup application.  We recently (as of the New Year) pushed the past eleven months worth of work into existence as our new primary (Python/Django) product replacing the previous multiple iterations of our legacy (Java) product.  The focus and scope of the project limited my ability to go off on tangents wherein I could code my personal projects freely.  This was by no legal hand binding, it was simply a matter of wanting to focus my writing to building our product to the level it needs to be, to the high standards we require (and rightfully so).  

This leave one (me, namely) with little actual time to thunk down in front of my primary workstation to commit theory to codebase, hence I've found myself working it out on handheld whiteboards, sketchpads,  napkins, chalk on the ground whilst playing with my daughter or even simply working these theories out in my head.  While I would like in many cases to put my thoughts into actual runnable logic, I've found that the exercise of stepping through theoretical code in my mind has kept me sharper regarding my thought processes.  True, I cannot share this as easily with friends afar, but given that many of my personal friends are also senior level engineers, discussing (when we do) casually my theories and ideas, they get the gist quickly.  

The point I'm trying to get across here is that while today is perceived as one wherein a bunch of 20 year olds either in or fresh-out-of college spend an obscene amount of hours in incubators or at startups killing themselves churning out ridiculous amounts of code, there is most definitely no slow down in the thinking processes of the more senior of us out there.  We just don't find a necessity it raw churning out of code as it is the concepts that drive the field and aid in future innovation.  Let those who wish to "do" continue to run their path, but lets not overlook the value of those who've moved their focus (whether by situation or by intention) to the more abstract realm of theory as the two are inextricably bound.  We need ensure that these two distinct groups of people are in contact with one another because it will ultimately lead to the newer advances, bettering our field for all involved.

New environments (mentally) as it were... (a.k.a. something old, something new)

Since my last update made a little over a month and a half ago, much has changed.  I've accepted a position as Lead Software Engineer for Yorn, LLC located in Conshohocken, PA.  I haven't abandoned my prior position with the publishing house in NYC, merely time-shifted those hours elsewhere.  Taking this new venture (on top of my previous work, plus the other tech-startup of which I'm a co-founder, Ecquire has proven to be a necessity for my sanity.

Working primarily for the past many years as the sole Software Engineer for a half dozen magazines in a Django/Python/Javascript/CSS/HTML/FreeBSD Unix environment whilst also wearing the SysAdmin hat has been...  draining.  This wasn't due to having nothing to do, this was more to do with having very little room for innovation as the end product wasn't the new SaaS website or Outlook plugin, it was simply repetition with the only real variances being that as dictated by wet-behind the ears designers and graphic artists whose concerns about a given site was more about look than UX.  Don't get me wrong, some of the designs have been gorgeous, but not without the pendantic whining common with individuals who only knowing Adobe Photoshop aren't happy when you explain to them that there is a different methodology at work in producing like-layouts im a web framework.

Either way, back on topic.  I feel for the first time in quite a while that not only am I solving real problems that pertain to a large scale of individuals and companies (as opposed to readership by fashion and/or tattooing enthusiasts) but I am finally in a position in which I have a cohort in crime, a partner, a colleague. Best of all, he's brilliant.  A proper individual for the field, something when I've been trying to find for ages.  A PhD in computer science and a quarter century in the field along with all of the traditionally odd hobbies and sense of humour found more commonly in those with very intellectual professions.  Even though we've only met face to face on three occasions, we've shared many phone calls and Skype sessions whilst working out our designs and product development and it has simply been a breath of fresh air for me.  I have someone off of whom I can bounce complex ideas knowing full well that I'm understood, as well as presenting me the opportunity to expand my own learning horizons.

Excitement stirs ones involvement in a given project and considering that this is what has (and is) happening to me, it is paying off in not only a clearer mind and what I believe are more robust ideas emminating from my thoughts but it has reduced my stress allowing me to be more productive all around whether in the publishing work, my own startup and more importantly in my family life.  It all comes back to ensuring that whatever one does, they need to sometimes step of a comfort zone in pursuit of that which provides incentive and drive in ones given interests and/or profession(s).  I was too conservative earlier on in my professional career and I believe I would've benefited greatly had I stepped out of my cocoon years earlier rather than (as most introverted engineering types do) not think highly enough of myself to be worth more than an abysmal income and working environments to which I was subjected for over seven years.

Times have changed and the future is looking brighter and brighter.  Ecquire & Yorn have paved the way to a better future.  I stepped past my initial nervous/worried leanings and jumped into the world of proper tech startups finding that the grass truly has shown to indeed be greener on the other side.  Now, onto another exciting and challenging day of practising my craft.

2011 and my prospects...

    Having recently entered the new year, I find it fitting to share some recent happenings and thoughts on how they might apply to not only my situation but those of others with a penchant for software engineering and/or administrative careers.

    The past year has been one of making connections.  I have met some great people including several combinations of Angel Investors, Venture Capitalists, Software Engineers and Computer Scientists.   My experiences with our startup, Ecquire (http://www.ecquire.com) has proven quite enlightening as well as fun.  In fact it was through my co-founders I was introduced to so many others in the field, such as Rick Rasansky and Trip Denton of Yorn (yorn.com), and Gabriel Weinberg of the amazing search engine DuckDuckGo (duckduckgo.com) which protects our privacy.

    What I have come to realise is that while I have been working with software behind the scenes of a considerable number of websites on their various frameworks, the technology doesn't challenge me and has proven to be quite repetitive.  There are still some challenges, but there is far more aesthetic issues than technical ingenuity involved.   The issue of technical seclusion is also an issue at hand.  With my primary client for whom I have a special relationship due to past employment in the earlier half of the previous decade, there is a loneliness on two levels.  

    The first being that I am not only the only Software Engineer, but the only technical person period.  I wear many hats including CTO and Systems admin.  I handle all technical contracts for servers and what not, at least related to any only presence.  I'm more than capable of handling these roles though it can be rather isolated and not because I'm physically in a different location.

    Which leads me to the second reason, that being one of no technical peers with whom I can discuss, debate and/or share views on projects.  The owner of the various entities is more understand on technical issues that many with whom I've dealt over the years but there are still limitations of understanding.  Again, I do highly commend him for intelligence, trust and understanding though there are limits of which no one other than a peer would quite grasp simply because it is something that needs to be experienced for commiserating to be legitimate. 

    As a means of striving for more in not only personal life, but my professional one as the combination of both affect my happiness and general stress levels, I've been partaking a re-design/porting job with a technical group which is more up my alley.  I am still delivering the service and quality to which I have committed myself with my primary clientele, let that be stated for the record.  It is just that I need this to keep my mind from atrophying.  I need to be challenged in my field, not to mention be given the opportunity to innovate without having to wear every hat and focus so much on outward aesthetics.  I like  beautiful design and beautiful code, much so less visuals as that is truly the realm of designers. 

    Where I'm coming to for the sake of others is the following:  Push to keep yourself challenged and happy in your field.  For a long time we allow ourselves (especially as we have more people depending upon us in our personal lives such as our families) to become complacent with the idea of security and daily consistencies in our work.  The problem with this is that we start to stress over the rut in which we find ourselves.  We internalise the urge to snap at others when for the millionth time (exaggeration of course) we painfully banal question or task is asked of us.  Though inside, we die just a little bit more each time, in spirit at least.

    The solution (or at least one solution) is to not let fear or complacency hold a firm grasp on us.  It is one thing to allow for short term bursts of such ideals for the sake of a greater good but to allow it to trap us long term in what is almost definitely a downward spiral is unbecoming of our abilities and intelligences both as individuals and collectively as the technical backbone of our industries respectively. Push to find new challenges and if they are drying up as a lake in a newfound desert, look elsewhere over the horizon as our abilities only go so far when our outlook and prospects of change seemingly whither into nothingness which ultimately leave us a shell of our former glorious selves. 

    I'm not taking this new year lying down.  I'm feeling reinvigorated with new purpose, prospects and challenges not only for the betterment of my familial situation but for my peace of mind now and into the foreseeable future.  I wish the same to all of you whom finding yourself in a similar situation might find my words useful and/or inspirational.

Romanticisation, Research & Reality

As I've now hit that point in my mid-late 30's, I've had some internal conflicts recently see resolution.  This won't be one my traditionally long winded/verbose entries, though it won't be short enough for a micro-blog post either but here it goes...

Over roughly the past two decades I've been torn by issue of not attending university, especially one such as MIT, Stanford, Virginia Tech or UC Berkeley in pursuit of a Masters/PhD in computer science.  I feel that I missed out on the social aspect (aside from the excellent environment for furthering myself in a group setting in my field of interest/passion/expertise.   This is simply a recurring romanticised view I have over my regret.  I only envision the good parts, not the tedious drawn out study periods, the painfully boring pre-requisite programs/classes and lecture in mundane subjects solely to satisfy the higher education machine.  I am an autodidact and a fairly effective one at that.  University would have most likely quickly become the bane of my existence.  I experimented with higher education and within the first semester found the pace horribly slow and in the case of required classes, a horrible waste of my time and money (I paid the tuition with my own cold hard cash).   I opted to leave before wasting any additional money and simply continue to do what I had always done, educate myself for a variety or sources, as well as getting my hands dirty in my field of interest (amongst others for well-roundedness).

This brings me to one of the reasons which fed the romanticised ideal as prescribed in the previous paragraph(s); my research in the field of immersive virtual environments.  I have spent a considerable amount of time since my childhood in the areas of researching virtual environment simulations (e.g. simulations of real-world objects and scenarios).  This could entail human interaction with every day objects to be used for gaming or habit studies or to simulate atoms at the molecular level or even the macroscopic planets, interstellar bodies and galaxies in our and other places of the universe.  This is the kind of research which would have either lent itself towards achievement of my PhD or conversely, the focus of my post-doctoral research under a grant.

Finally, the reality (hint: it isn't all that bad).  Working in an academic environment in professorial/research dual/split roles would've been a wonderful way to go, though it wouldn't allow me the flexibility I currently have in terms of working from my home whilst raising a toddler, and being home for my elementary school aged child as well.  Do I get funding to pay for my personal pursuit/continuance researching simulations and their many facets?  No.  Do I have a surplus of time to allow me to pursue said interests after my family and work related endeavours are satisfied?  Not much at this point in time.  Do I feel that the overall balance of what could have been versus what truly is and what still may come my way is reasonable, fair and not worth feelings of regret?  Yes.  I'm rather happy with where I am as a Software Engineer for the past 15+ years and while I'd still love grant money to further fund my research, I can't say that I don't  enjoy some of the daily challenges of my already existing present-time workload.

Just because we might find ourselves in a situation that isn't exactly as we'd initially thought we would want doesn't mean that there aren't equivalent outcomes that still satisfy our initial hopes and aspirations.  I suggest that those of you who have dealt with the aforementioned conundrum, take a good long look at how you might still achieve the equivalent that fits best into your existing life plan and stop worrying so much about such exactness in realisation of ones dreams, otherwise they might never materialise in any recognisable form.

The Usefulness & Addictive Nature of Multiple Displays

It seems to be a divisive issue when dealing with developers, engineers and programmers alike... The usefulness or annoyance of multiple displays.  Recently having upgraded to my fifth display, I felt it was about time that I weigh in on the issue/share my opinions.

Five displays : One 1920x1080, Two 1920x1200, One 1280x1024 and One 480x800 :: 8.4 Mega Pixels in All

Back in 2001 at an interview with Health Market Science in Conshohocken, PA (now in King of Prussia, PA I believe), I had witnessed a key benefit of new up and coming startups for their developers...  multiple displays for each workstation/desktop.  Flash forward a few more years and one Mac Book Pro later and I find that ever company at which I would work, I would attach a secondary display so as to provide more desktop real estate.  Whether this was to provide a shell or two in which to run emacs while accessing a db frontend or browser preview window, it proved beneficial in terms of productivity with less switching between screens, windows and what not.

Ever since my first exposure to such setups (which were astronomical in price to setup back in the 90's and the beginning of the newest millennium), I was rather enamoured by them.  Now in 2010 I find myself working not on laptops, but full blown 64 bit Unix workstations.  A major benefit of such setups is the ability to run a considerable number of graphic cards and their associated displays.  Some wonder what could I possibly have running that dictates so many displays.

I personally like to keep a web browser open at all times so using the picture above, I will explain as best as possible.  So, as I was stating in the previous line, the left most display is running a full height copy of Google Chrome, flanked by three separate terminal windows running a mix of local and remote shells on  various servers.  The middle large display is running my current favourite IDE for python development in fullscreen (in this case, NetBeans 6.8).  The right hand most screen is used for additional remote shells used more so for large rsync'ing and process monitoring.  The upper left screen (a great displaylink/USB powered 480x800 (or 800x480) from Mimo) is used for Skype & Adium (and both are pinned to all spaces/virtual desktops due to content), and the upper rightmost monitor is a free for all to display whatever is needed in addition to all of the aforementioned items (pdf viewing, techtalk viewing, the occasional movie, db schemas or gui, etc.).

The biggest issue I currently have with the setup is physical layout.  A table roughly 144 cm (60 in) wide can only handle three widescreen displays (between 23" & 24" diagonally) when in a concave configuration.  Having to position the additional displays above the lower displays does cause the occasional confusion regarding pointer location.  A better layout would be an array of identical displays, preferably with VESA mounts in a 5 wide portrait layout or a two rows of three in landscape layout.

I highly recommend that others who haven't had the opportunity to work in multiple display setups to try it out as soon as possible.  Those simple keyboard shortcuts used to swap from window to window and/or virtual desktop to other virtual desktop do take up time and can interrupt one's flow.  Is it really worth it when displays are so cheap these days?

Caveat emptor:  The use of multiple displays causes varying ranges of discomfort when penned/cornered/shackled into a single screen machine, not to mention there is desire to acquire more screens after getting acclimated to the first addition, second addition, etc.

Till next time...

The Romanticism of Internet Startups. My experiences, part I.

I wasn't sure what drove me to this point, that of writing about startups (of all things).  I believe it has much to do with the recent launch of the newest startup of which I am a founder as well as the Software Engineer behind the technology in said venture, Ecquire.  In the past months during which the project has progressed to our recent launch at the end of March, my own fascination with startups and my own experience in dealing with them came back into focus.

Back during the dot com boom in 2000, I was starting my 6th year as the lead developer for a manufacturing firm in Philadelphia, Pennsylvania.  The realisation that I was growing rather weary at what I felt would become a dead end job well below my desires and capabilities would later come true for the individual(s) that came later to replace me once I'd left.  I recently found out via a visit, the software I had authored in the 20th century for said company is still being utilised during every one of their 6 production days a week, year round.  I figured authoring a critical application that as been running for over 10 years a full production environment without failure is one point of pride I happily take away from that point in my professional career.

Moving on, both with this post and what I was getting at after all of those years at what was becoming a job with no real future, unless I wanted a full frontal lobotomy.  I started to look around at my potential opportunities and having at the time been rather conservative in the kinds of companies in which I would  allow myself to envision employment, only one of which I was aware of it being a startup.  I had interviewed in a new industry as an attempt at something new with a company at the time located in a new office complex in Conshohocken, Pennsylvania, called Health+Market+Science.  It was the epitome of dot com culture from the very casual attire, dual flat screens (15"-17"ers at the time) to the fully stocked kitchen with both Mountain Dew and Jolt colas and of course the obligatory ridiculous hours kept by the early twenty-somethings.

I ended up not taking that job as the hours just weren't conducive to me, having been married with a home to which I preferred to return to during daylight hours.  I did however find myself in an awkward situation as a friend happened to be working for a financial startup as a contractor and try as he may, they never offered him a salaried position.  After suggesting the position for which I interviewed to him, he found it a more compatible match both in terms of age range, distance from his rented home and preferred environment.  He gave appropriate notice at his soon-to-be-former contract and suggested to the CTO to have me in for an interview.  To make a really long story short, I interviewed and was offered a full time position at a considerable increase over my previous place of employ for the prior seven years.

The new environment was definitely a relief from the previous mid-size company dynamic, though it didn't come without its own oddities and personalities. The projects cam quickly and were fairly varied.  Our niche in the market and in terms of financial companies was breaking new ground in an area of the industry that was too new to have many established competitors or applications which could simply be purchased and utilised for daily goings on.  The environment code wise was simple, replace the existing PHP documents with something better, and at that time and in that case, perl was the solution.

I'm not going into the whole rundown of the years at the company and its daily goings on however I was state that true to its nature we worked some late evenings, the odd weekend and had a blast all the while. It ultimately changed as the company grew and due to certain situations with some of the legacy code's lack of efficiency with our increased activity (i.e. it wasn't scaling), my boss (the CTO) was removed and I took his place.  It would be several more years that I would be at this company which would end six months after the new owners completely destroyed the client relationships and staff morale.  I ended with the obligatory hire-a-thug escorting me from the facility (though I am a considerably larger individual and therefore felt no threat), and a decent severance package.  The new CEO hated me from day one because while promising to continue to provide the high quality of work my team and I output on a regular basis, I also made it clear that we were not 'yes men', nor would I or any of my team kiss anyones ass because of self-imposed importance via titles or roles.   You earned respect, you never gained it by your business card or past.  He was never understanding of that mindset and as such I was given a nice severance pay while other people were just thrown to the street.

Ultimately my first foray into an internet based startup was a fun adventure that definitely provided lots of learning opportunities and allowed me the environment to grow and expand my comfort zone.  All in all, I wasn't unemployed for more than thirty or so minutes as on my way away from the office on that fateful friday afternoon for the last time, I made a phone call and found myself employed starting the upcoming week... at another startup.  More about that in another post!

What's In Your Dead-Tree-Format Library?

Whilst cleaning and reorganising my home office, I came to the realisation that I have accumulated quite a decent amount of books on the various topics in my trade & hobby, software engineering.  After placing my various titles properly in groups on the shelves, I took a photo and it is shown below.  What follows is a breakdown on each book, my thoughts and the source of how it was attained (where remembered/applicable).  Note: Not included are three books currently in transit via Amazon.  One is on ajax, and two are FreeBSD server administration related.

Top shelf first, going left to right:

The Linux Database Bible :: This was a $50.00 book received as a freebie when I attended Linuxworld 2002 at the Jacob Javits Center in NYC.  I can't say that I've used this book much for anything other than the occasional reading fodder when nothing else was within reach.  I'm sure it would be of more use to newbies to both Linux and databases, even now.

Python Essential Reference, 2nd Edition :: I picked this up back in 2003 whilst doing work for a financial company at which I was both senior developer as well as newly appointed (reluctant) CTO.  This is a David Beazley book, and I highly recommend any version of it (there are several newer than my copy) as he is clearly full of expert level knowledge on all things Pythonic.

Python Cookbook :: This was another 2003 or 2004 purchase mainly out of curiosity to see what crafty, yet elegant solutions other Pythonistas has designed and/or implemented.  Definitely a wealth of information on a multitude of topics be it recursively traversing b trees or working with simple CSV files.

Python Pocket Reference :: A simple reference mostly useful for the "batteries included" libraries.

Python Programming Patterns :: This book has shown me why we generally don't rely heavily upon patterns such as those overly used in Java software.  I purchased this along with the Python Cookbook, and quite frankly if I had only acquired this book, my disappointment would have be far greater as I would've had nothing to take my mind off of it.

Perl to Python Migration :: Picked this up at the Micro Center in St. Davids, PA in the early 2000's when I started to migrate some of our perl applications over to Python in the financial world.  Highly recommended, especially for heavy, long-term perl hackers.

Pro Django :: Picked this up in early 2009 as further reference and idea material for the 4 websites I write and maintain for a series of internationally published magazines.  I'm torn on the value of this book, but at least it goes beyond beginner level.

The Definitive Guide to Django, 1st Edition :: Purchased as a reference as soon as it came out, references version .96 of the framework, so if a person is using v1.xx or higher, there are going to be quite a few caveats in the examples, otherwise a wonderful reference, especially when it comes to the appendices.

Practical Django Projects :: A bit of a disappointment as it focuses on blog creation for which a series of examples of this ilk already can be found online for free, not to mention in the Pinax project.

PHP and MySQL Web Development :: I just received this book from a business partner and whist I generally avoid PHP like the plague, I am glad to have references which are a bit more current these days for when I do need to venture into such environments.

Setting up LAMP :: Same as above.

PHP Solutions :: Ditto for this book as well.

Pro Drupal Development :: ibid on this one too.   I don't think I'll ever end up using Drupal, but at least I have a reference if I ever need tit.

Programming PHP :: I inherited this from the previous CTO at the financial firm at which I worked back in 2002/2003 and it has served me well as a reference book.

PHP Pocket Reference :: This also was provided to me with the Programming PHP book.

Programming Ruby, 1st Edition :: The Pick Axe book as it is more fondly referenced by Rubyists.  I picked this book up in 2007 so as to further my own understanding of perl's successor.  I was, in fact, reading it early this evening, though I still find it considerably less useful professionally for me than Python and other solutions.

Programmers at Work, 1st Edition :: This was left to me by a business associate from Ecquire prior to relocated elsewhere.  It is the predecessor of "Coder's at Work", and contains some early Apple, Microsoft, Adobe, Xerox and HP developers and views on the industry.

HTML 3 :: Truth be told, this was bequeathed to me by the surviving relatives of my ex-wife when her younger brother died in an untimely manner.  It is rather outdated, though kept solely as a remembrance of a young life that had potential in several areas of his life.

The Pragmatic Programmer :: I might not like a lot of the most recently branched out Pragmatic series be it books or podcasts, but this book is gold in my eyes.  I made this a company purchased, required reading for all developers from Junior to Senior level everywhere I've worked.  It most recently was recommended to an Intern I mentored during the 2009 summer season.  It has also proven valuable to other associates, even those not directly involved in the Software Engineering field(s).

OOP Demystified :: I purchased this book as a means of helping to teach others the basics of Object Oriented Programming.  It is a rather basic book, and uses the transitional OOP examples cases of registering for a class and doing payroll, like umpteen other books on the topic.

Middle shelf second, again from left to right:

Open Source Development with CVS :: Picked this book up on an departmental outing back in 2000 when moving into the Lead Developer role at a Manufacturing company which didnt have an existing source control system in place, and it wasn't yet time to use Subversion and the company was too cheap to acquire Perforce licensing.

Practical C Programming :: Every developer has at least one reference book for C, many have more.  I'm not a big C guy myself, though I find this O'Reilly reference book a wonderful additional to any library, maybe short of the K&R tome.

Teach Yourself C++ :: This book by Al Stevens was something I'd picked up as the desire to torture myself with C++ a.k.a. Bjarne's plague upon the coding world.  I sooner should've picked up a book on Smalltalk or Objective-C.  Note, the book is written well, my comments are mainly aimed at the abomination which is C++.

Learning Java :: I didn't buy this book as a Java reference in as much as I did for its first four chapters, which by and far the single best example laden object oriented chapters of any book, bar none.  Oh, and they are quite humorous as well.

Head First Java :: When recently wanting to get back into the Java world a bit more than in the past (with my playful experimenting), this was ordered on the recommendation of a good long term friend of mine, himself a Senior Software Engineer focused heavily in Java environments.

Java in a Nutshell :: Standard fare O'Reilly reference book, though drier than others and while laid out clearly, something felt amiss.

Core Java :: Sun's own sanctioned Java tome.  Massive, and packed full of information (and for the price is had to be).  Heavy examples on applets and AWT, which as of this writing is a decade out of date.  Makes a great bookend due to its size.

Java2 : A Beginner's Guide :: Probably one of the nicest Java2 introductory manuals.  This one has been loaned out to newbies to Java more than any other Java book in my library.  Clearly written and never dull.

Javascript, The Missing Manual :: Recently purchased and while full of information spends too much effort on jQuery, so much to the point that the book might've been more aptly named "jQuery", and subtitled "with a chapter or two on non-jQuery javascript".

Linux Programming :: Also bequeathed by my ex-wife's famliy.

Linux in 10 Minutes :: ibid.  See above.

Turbo Pascal, 3rd Edition :: Pascal, while originally a teaching language is also an imperative, procedural language good for systems programming much like C and only slighly slower.  Having moved to Pascal from various versions of Basic and ML, I was happy to take this off of my wife's friend after he completed his Pascal course at university.  The section on algorithms is still one which I reference routinely, hence the reason isn't packed away in a box.

Perl 5 Programmer's Reference :: A $4.99 special at a Banes & Noble in Abington, PA back in 2001.  Only covered version 5.004 of perl, but was so well laid out that it beat anything that O'Reilly could muster for perl references.  Quite possibly out of circulation/print as of this article's writing.

Learning Perl Object, References and Modules :: Essential reading for any non-purely functional code to get written when subjected to perl environments.

Programming with CGI.pm :: Nothing says well engineered than written by an engineer at Jet Propulsion Laboratories.

Programming the Perl DBI :: Anyone doing anything with databases in perl,  will benfit from this thin yes most definitely useful book.

Perl Best Practices  :: I pick this up after reviewing another copy at an Internet Hosting firm for which I did someork..

Object Oriented Perl :: Damien Conway's opus for Perl and Object Orientation.  Explains limitations and information for making robust Django.

Practical PostgreSQL :: Acquired when the original plans for some of my publishers dontnet

Bottom shelf lastly, contains my spoken language reference library which contains books on:

Dutch, French, Japanese, Welsh, German, Korean, Russian and Spanish.  The majority being in Dutch including several novels and grammer books, followed in a distant second by Welsh grammar books (mostly picked up in Waterstones in London surprisingly), then in a close third, Japanese.  I like languages and I do not limit myself to simply one or two.  Anyone who follows looks at the list of people whom I follow on twitter will easily see all of the above languages utilised, sans Welsh (quick, somebody contact Alan Cox!).

Bonus:  Some of my die-cast cars including my highly favoured Peugeot 206 WRC model that I picked up for £2.99 at Hamley's in London back in '03.  I collect the occasional model car here and there, mainly German, French, English and Italian based, but that is fodder for another blog.

The Greying of an Engineer

My birthday is upon me once again, this time in 11 minutes from the time that I compose this brief entry.  As I contemplate what the next year holds for me I find myself having certain realisations floating around my head.  I will attempt to share these with little fanfare and leave interpretations to the reader.

1. Throughout my entire life thus far, one item has remained a constant:  I love to design software and have since I was in the single digit age range.

2. The reason I'm not a horribly rich coder is simply because my goal has never been that of becoming rich, whereas it has been that of writing great code.

3. There are is a lot of talent out there, but it has nothing to do with youth vs. older coders.

4. New methodologies come and go all of the time.  Functional vs. Object Oriented paradigms, Low Level vs. High Level languages, Waterfall vs. Agile development.  All are capable, all can be utilised in effective manners, it simply comes down to competence and compatibility of those involved.

5. You can teach an old dog new tricks, though after having learned said new trick(s), one might still prefer the original. (e.g. I think that jQuery is a wonderful invention, but don't expect me to use it as I feel it isn't explicitly clear.  I'll take document.getElementById('idname') anyday over perl/rubyesque tokens.

Given that my goal was to post this before my birthday comes, I'm ending it abruptly here.  Till my next post.. -Eric

You kids get off my lawn! (oh, and the Apple iPad)

Lately I've been rather busy with work, primarily my main client as well as with the newer work I've been doing with a soon-to-be unveiled startup of which I'm a partner. Our product is launching by the end of the first quarter 2010 and I will be sure to update the site with all the details.

What is really on my mind lately is the annoyances I've been feeling more and more lately regarding what I feel is a loss of substance in the field of computing, interfaces and the sector of artificial intelligence research. Though just recently with the launch of the newly unveiled Apple iPad did I start to feel some alleviation. I will address several of the aforementioned items, but will leave the AI discussion for another post as it will be a lengthy one at best.

Firstly, as 2010 has rolled upon us I started reflecting on how it must be for kids these days and their constant exposure to computers. Primarily how difficult it must be for future programmers and software engineers to get started programming on machines so complex with operating systems so complex that to do even the simplest task requires learning what potentially are complex API's. When I was starting out with computers back in 1979-1980 one could buy a computer (which came with at least BASIC) as well as general instruction books explaining how to program in said language. Within 15-30 minutes any kid would be able to draw bitmapped graphics on screen and possibly even animate and/or add sound as well.

Given that the machine in question on which I first started (a 16-bit machine no less), the TI-994/a, was a 1.067mHz speed daemon, there is much to be said for its overall capabilities. This blog post is larger in size than that machine had RAM (a whole 16k's worth). So, it is true that with all of the amazing capabilities and speed of our newer machines (such as my primary machine with its 8 hyperthreaded cores over two physical quad-core Nehalem Xeon's and 6gb of RAM (of a possible 64gb)) it would be expected. Still, something is lost in the overall simplicity.

Furthermore, my recent curmudgeonly slanted mindset spread to thoughts about how access for all destroyed the quality of the average computer user, especially those networked users (which nowadays includes virtually everyone). When I first started online, there was no AOL, there was no web, there was the internet, but it was limited to Academia, Science Research facilities and the Government. We had modems primarily running at 110/300/440 and later 1200 baud and up. We had acoustic coupler RS232 interfaces (they while novel, are not something which I find myself longing for once again) and we were happy as can be. We knew that getting online and/or running into other computer programmers/enthusiasts (they were usually one in the same back in the day) would lead to interesting conversations/exchanges of a higher intellectual level as opposed to nowadays where the overwhelming majority of computer users are simply that, users who couldn't code their way out of a cardboard box.

Enter the Apple iPad. A machine designed for everyone BUT programmers/software engineers & developers. It provides the mundanes with the functionality to go on about their daily online existences and I'm truly hoping that such devices as this catch on. I hope that items such as this replace the majority of those users' computers. This would give us a kind of return back to the day when the technorati and intellectually gifted were the only ones with machines capable of creating new software. It will help like minded people easily be able to pick out those of similar ilk simply by their possessing an actual computer.

Now I realise that there are people complaining about the iPad specifically those under the spell of Stallman (RMS) and his free software foundation but it is time for them to be grown ups about the situation. If someone creates software, it is their right to keep the source closed, just as it is Stallman's right not to run it on his machine(s). He can be an idealist with cramming such a non-sensical mindset on everyone. Most people really could care less because there are those sources which provide for the applications people want and use, and have no desire (or capability) to modify them anyway, hence the iPad and future devices of similar type are perfect as end users are consumers of the fruits borne of software engineers, not producers of such software.

Now I realise that as usual, I'm diverging from my original topic by going off on a mildly related tangent, so i'll wrap this up by simply stating that it is my hope that with the newer type of device designed solely for the everyday user that we will see a reduction in actual programmable computer sales indicative of a clear divide between producers and consumers once again making a clear distinction between those with the mental prowess and logic abilities/desire to create software and utilise machines to their fullest, and those who are simply consumers of said labour.

Thoughts?

PyCon 2010

I just made my submission to give a 30 minute talk at PyCon (US) 2010 in late February of the upcoming year. I was contacted by PyCon staff with the suggestion that I present a talk sharing my various Python based experiences at various places of employ. I made sure to get the submission in earlier this evening before the ability to do so was shutdown as the window for submisions closed for the 2010 event. Now I must wait until sometime in November to hear as to whether or not I'll be presenting. I will keep everyone posted either way.

Update to Post Regarding Hacking & Ruby

This will be a very short entry as it is rather late and I'm looking forward to sleep. I would do but I do feel that I have to get some observations off of my chest after the past 6 hours of exploring ruby (for the third time).

#1. Ruby isn't as intuitive as one might suspect. Maybe python and others of similar influence (groovy) have raised the bar too high in terms of dynamic language syntax and expectations. The standard ruby idioms are inconsistent and ill-named in several cases, mostly involving native data sets.

#2. Namespaces in Ruby are an even bigger mess than perl. To some degree, perl's system seemed to make sense yet from what I've read, seen and with which I experimented, I find the namespace setup for Ruby to be subpar and dare I saw far from fluid in implementation details.

#3. Ruby is indeed very slow, especially when working with the Array types in combination with large datasets and continual pre-requisite 'include?' method calls for each datum in said set. I did find that I was able to achieve the same results wanted via Hash population followed by a dump of keys to an Array with a noticable speedup, removing the need for the very slow 'include?' method. Membership tests are a joy of high level languages, but a drain on some resources, ruby more than others though without a doubt.

#4. The novelty of mutable and immutable version of method calls (collect! vs. collect, slice! vs. slice) is just that. A novelty. This is an ambiguity which I believe does not help to further ease of readability and usability. It further necessitates that non-standard library code implement similar idioms and 'practices' for uniformity's sake with the downside being a snowball effect in this area.

#5. Ruby isn't sure if it wants to be perl, c, smalltalk or itself as can be determined by the mix and match of terms, keywords and standard method names. It doesn't feel like a concrete language that was purpose built, but more like an object system with various sources for tacking on the remaining pieces of the language so as to round out the feature range.

These experiences with Ruby (for the third time) may have been different had I not been spoiled by Python (most notably), or were I not coding in the field for the past 15 years. This is not the case nonetheless. I couldn't see myself coding in this language for anything mission critical or heavy duty and after looking at the problems many of the ruby back-ended software systems and/or websites vs. the other high-level dynamic languages have suffered, it becomes quite clear when industry giants such as Google and IBM throw their weight behind Python.

This isn't meant to be an argument starting post about Ruby vs. Python as they can be found elsewhere, though if the shoe fits...

Ruby & Project Realisations

This isn't going to be a long post as it is rather late in the evening (morning) and not only am I trying to rest my leg (hyperextended my knee playing football (soccer for the Americans out there) on Monday evening), but I'm also in need of greater amounts of sleep having a four month old daughter for whom I am the primary care giver starting tomorrow given that my wife works in the academic world.

Short and to the point (for me at least) is that I'm delving back into Ruby (for the third time chronologically), but for the second time on a 'serious' level (i.e. with the intent to actually produce usable code and not simply proof-of-concept understanding code). I'm realising that while I love python which has been part of my daily work for the past five plus years, moreso Django/python in the past two, that it is becoming my 'Java/C#' if you will. By that I mean that it is my work language. It is a clean and elegant language which allows me to focus on getting what I wish completed, completed with minimal fuss and easy maintainability due to its explicit albeit brief and neatly aligned syntax. I feel though that something is missing.

If I can go back a little (and long time readers from previous versions of this blog circa 2002-2006 would remember me discussing this before) and bring up what eventually became my professional lingua of frustration: perl. Larry Wall's masterpiece which I utilised professionally from as far back as 1995 albeit I was working with rexx and pascal(!) more so then. I used perl and was attracted to it because of its expressive hacker roots, but was eventually disgusted by the lack of a decent enforceable object model for doing any kind of OOP work, not to mention maintainability was not its strong suit regardless of how meticulous one might be as a software engineer/coder, etc. This is what ultimately lead me to look at ruby but only briefly as it had residual taste of perl all over it. I found python shortly thereafter and have been happy ever since, until recently.

Sure I've looked and learned other languages in the meantime (as well as used them for personal and professional purposes), but just for the past three weeks or so I've realised that some of python's strong suit do indeed take some of the more guttural joy out of hacking out code. In my line of work I find formality and structure do wonders at getting solid code and meeting my clients' needs, which is the whole point. I'm at the point professionally where I don't get calls or emails saying that "something broke". It is much akin to Apple computers. Things just work without fail, as should be expected.

This ties into my other piece of the recent puzzle. I'm doing web framework design and implementation (amongst other custom software components) for primarily lifestyle, art and fashion magazines. It does pay the bills and it is at least involved with a creative branch of what can be a boring industry (publishing), though I find myself pining for more intellectually/scientific/theoretical research based projects/content. This isn't going to be happening anytime soon where I'm currently spending my efforts (professionally as it were). I have no design to stop doing what I'm doing and for whom I'm doing said work. I enjoy the relationship I have with my clients and there isn't anything wrong there. I'm being kept busy with new work so that's nothing about which to complain.

What I am looking to do is start working on some more experimental/theoretical designs and codebases/classes/packages in Ruby so that I can further explore the language and enjoy the more 'hack' mindedness which I find comes with such an expressive language. I will most definitely share my results with all the CodeDEVL readership (as well as podcast subscribers). I may even post a screen-cast soon as my copy of Snow Leopard for my Octo-Mac Pro (8-Core) should be here on Friday and includes new screen-cast capturing built-in to Quicktime X.

If anyone is in the Doylestown region of Pennsylvania and would like to meet up to talk code, please drop me a line. My email is simply 'eric' at this domain (assuming you're not reading this from the source blogger domain but the domain for which the header image at the top of the page states clearly.

I'll keep everyone informed. Until next time..

-Eric