Born To Code: Bio Of A Software Developer

I've been writing code since I was nine years old, when I learned BASIC on a DEC PDP-11. When I was 10, I mowed enough lawns and managed enough garage sales to buy myself a brand new Apple ][+. I quickly mastered BASIC and moved on to 6502 assembly language. Since then, I've been through more languages and environments than I can count: FORTRAN, Pascal, and even COBOL (shh don't tell anyone) on VMS; C++ on a IBM PCjr; 6510 assembly on a C-64; Logo on Apple //e and IIGS (I taught a class in Logo for both teachers and students at my school when I was 13 😂); C++, Lisp and Perl on various Unix flavors... and those are just the things I learned pre-internet, which I don't even put on my resume.

I learned HTML when Tim Berners-Lee still had to explain what the W's meant. I taught myself Javascript, and always to be just a little ahead of the curve for what Firefox could successfully parse and execute. I still remember searching for information on Altavista, before Google meant anything that didn't have 100 zeros. And of course, I still wrote all my *real* code in C++, including my CGI applications (remember Common Gateway Interface? No? Lucky 😜) to process form data.

Eventually I found the need to learn VB6 (honestly I'm sure it was an ealier version at first) in order to automate tasks in Microsoft Office applications (back when Office application automation was still a Brand New Thing, understood by few) during the run-up to the Y2K shakedown. In fact, I managed to code myself right out of a job, but that was inevitable in January of 2000 anyway. The experience served me well as a convenient springboard into ASP applications, however, and I immediately leapt at the opportunity to update to ASP.NET the instant the .NET Framework 1.1 was available. After a brief pass through VB.NET, I quickly learned to love C#, and to this day it remains my favorite language. Of course, I still used C++ in creating one of the first commercially-produced Palm Pilot subscription services (remember when those were separate from your pager, let alone your phone 🤣), and I was also able to take my first really deep dive into SQL Server Database Administration and performance tuning at that job. Eventually, the company was bought out by one of the manufacturers for whom we had created an advertising website, and everyone who wasn't working on that website got to stick around just long enough to shut down their applications gracefully before getting our walking papers. At least I no longer had to maintain the PalmOS application anymore, which by the end was down to less than 100 users who hadn't bought a smartphone yet 😂.

I spent a brief period writing Java code in a Unix environment, and while I'm quite capable in the language (and quite happy in the environment) I find it impossible to keep up with the profusion of new frameworks that seem to constantly crawl out of the woodwork. At the time, I was mostly working with proprietary libraries used to retrieve and process data from a wide range of electronic sensors, so I never had the chance to really benefit from the wide array of tools and libraries which were publicly available. It certainly didn't help that, of all the development jobs I've ever had, this was the one place where I just wasn't happy; despite the extraordinarily interesting scientific uses for the data we collected, processed and stored, I felt that management was not very knowledgeable about the capabilities our software could add and boxed me into a rather tight corner that kept me from expanding my knowledge, skills and usefulness. I'm sure I could have worked through the difficulties eventually, but I was making about $30,000/year playing online poker in my free time, and at that point my partner agreed that I should take a shot at professional poker instead of remaining unhappy and unappreciated. Since then, beyond occasional light maintenance, I've had a dearth of professional opportunities to use Java, and my lack of familarity with the ecosystem of tools and libraries available makes it the weakest for me of all commonly-used languages.

Of course, the online poker boom eventually busted, but well before then I began to miss writing code; anyway, my partner at the time had decided that she wanted to buy a house, and "professional poker player" doesn't look good on a loan application. I jumped back into the market and soon found myself writing Microsoft Management Console plugins for administration of the full-disk encryption solution used by DOD (and many other, less-impressive sounding clients). I spent the next few years advancing from maintenance coder to primary developer and eventually architect of the authentication and policy management service, using a C# windows service (pre-WCF, back when you had to listen to ports yourself😉) for secure communication and SQL Server for high-performance data access. It was during that time that I made the contribution to open source software of which I am most proud, fixing a bug in the implementation of the Diffie-Hellman key exchange algorithm in the Mono framework (since Microsoft's framework didn't even support it at the time).

Eventually that company got sold out from under me as well, so I spent the next several years working my way up from maintenance contractor to supervisor for the mid-tier development team at a major online brokerage; we specializing in ASP.NET Web Services (SOAP request/response originally, updated to WCF later, with the eventual addition of REST/JSON interfaces) and Windows Services for back-end transaction processing. My proudest accomplishment there was the complete redesign and overhaul of the service which maintained streaming connections delivering quotes to our client applications, which I wrote in C# except for the performance-critical functionality in C++. After the rewrite, that service kept our company in the top three online brokerages for fastest average quote delivery and highest uptime month after month for nearly two years, taking first place for fastest in 14 of those months. In fact, it was so successful that the company was once again sold out from under me, and the buyer shut down our streaming service so that they could break into the top five without having to compete.

Most recently, I found myself picked up for a C#/SQL Server contract-to-hire position, only to learn on my first day that I'd thoroughly convinced the interviewers of my ability to pick up new skills on the fly and landed on a newly-formed team using a technology stack I'd never actually touched before. Nevertheless, I always relish the opportunity to learn new skills, and the breadth of my experience serves me well in these situations; I picked up Python pretty easily, and almost immediately became the team SME on Apache Spark. Prior to my arrival, the team had decided to architect their new data intake system using AWS Lambda functions and an AWS Glue application, not realizing that their developer with Apache Spark/AWS Glue experience would be accepting another job and leaving during my first week of employment. Fortunately, I managed to teach myself enough Python, Apache Spark, AWS Glue/Lambda/CloudFormation/etc and domain knowledge within my first year that I not only got the solution up and running but made myself indispensable. When the company took an unexpected financial hit and had to lay off half their development staff just before my first year there was complete, I was the one person from the team that was deemed essential to keep the system running.

Unfortunately, among those who were laid off or moved to other positions at that time were exactly those people in architecture and management who had originally supported the design which I had inherited. Even I thought the design was ill-conceived for the purpose at hand, although the problems could have been fixed if more resources had been assigned or more support from management had materialized. I continued to maintain the solution for another two years, with occasional (and often begrudged) help from the new team to which I was assigned. During this time, I also picked up TypeScript and the Node.js framework to develop several AWS Lambda functions which implemented a REST API to allow end-user access to lookup tables used during the data transformations implemented in the Glue service. I also became something of an expert in AWS Athena during design and implementation of a system which tracked all transformations to the incoming data and allowed reporting on the success or failure of each operation, both in detail and in aggregate, delivering daily statistical reports to stakeholders and weekly detailed error summaries to those responsible for correcting the data problems.

Sadly, I was always slightly aware that I really never had a chance to truly succeed at that company; there was no feature or improvement that was ever going to change the new management team's mind about the "right" way to solve the problem. After I spent a couple years improviing and maintaining the existing solution, others on the team began training in SnapLogic, which had been chosen as the architecture of the future (along with SSIS packages and SQL Server). I gamely went through my SnapLogic training along with the rest of the team, and after spending a little bit of time with it I was confident that I could continue to contribute, but I don't think there was every any intention of allowing that to happen. When the Principal Developer and two other Senior Developers delivered a proof-of-concept for a replacement of my solution six months past their deadline (even with some significant reliance on my experience and lessons learned), it was immediately accepted as The New Hotness; missing functionality that had been critical when I built it was suddenly not so important, lack of error reporting somehow became a *feature*, and I found myself laid off a week before the reviews that determined our bonus.

So now I find myself here, in search of The Perfect Job, while I brush up on some of my old skills and expand some of my new ones. Recently, however, I read a bit of advice that I wish I had been given decades ago; someone answering a question on StackOverflow suggested to a new developer that they should keep a blog of everything that they learn each day, because within a few years they will have a treasure trove of knowledge that they can search, share or suggest to others. Lacking a time machine, I can't go back to the beginning of my career and start such an endeavor... and of course, if I went back to when I started programming, no one would even know what a "blog" is. Never let it be said that I can't learn new tricks, though... I intend to continue writing code for at least as long as I have been doing it so far, so this is as good a time to start as any. I don't know if anyone else will ever read this or not, but if nothing else this summary will serve as a good reminder of who I was right now when I go back to re-read this in 20 years or so, and of course if anyone who looks at my resume wants to dig a bit deeper and learn more about my career path then I have the perfect response already written 😀