28 May, 2013

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 Roguesthe 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. 

06 May, 2013

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.