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.