I have spent the last twenty years engaged in every aspect of developing software imaginable. I have been a principal engineer, a technical team lead, an engineering manager, and a lead architect. I have been promoted, laid off, fired and resigned from more companies than I care to mention. I have been self-employed, worked for small start-ups, and for large publicly traded companies. I have seen projects from conception to production, and have witnessed projects crash and burn first hand – sometimes due to my own inexperience. I have learned more from my failures than I have from my successes, and I learned my most important lessons the hard way – sometimes the hardest way possible. My blog and the associated projects are my way of sharing what wisdom I have gained through my failures so that other’s can avoid my mistakes.
Platform Architecture – I very much enjoy the challenge of building platforms for other developers to use. The style of platform I tend to design can be thought of as: low-code, component-based, domain-modeled, service-oriented, and correct-by-configuration. These platforms were built for companies I worked for, so they are not my intellectual property (something you give up when you sign an employment agreement) which means I can’t open-source them. Even more distressing, I have legal incentives to not discuss them at length. This is one of the reasons you’ll find very little if any discussion of technology in my writing: the topics I want to discuss the most are the ones that have been directly materialized in platforms I don’t own. Other topics have been covered ad nauseam by other content producers in the industry.
Product Development – So far in my career, I’ve created two from-scratch enterprise-grade products from the ground up by myself. For better or for worse, my professional background is in building enterprise grade products, by which I mean to say high complexity, high quality, and high reliability.
Product Marketing – I’ve gotten demonstrably better at marketing over the last several years, and am still working on mastering the discipline. My goal is to be as good at Product Marketing as I am at Product Development.
Full-Stack Coding – I try to maintain a high-bar for calling myself a “full stack developer,” which results in me being able to do things like CSS3 responsive animations, Object-Oriented micro-frontends, high-performance highly-scalable Functional backends, custom ORM layers, 1st-normal-form DB schemas, and stored procedures that return JSON objects. I don’t have “favorite” languages, but tend to find myself in the web development ecosystem most often simply due to the flexibility of building web, desktop, and mobile apps. If I were forced to list my favorite programming languages it would be CoffeeScript primarily for it’s Python-like qualities, and Swift/Kotlin, which I consider effectively the same language, as I do Java and C#.
Producing Original Content – So far I’ve produced four works that could all be published as books if I chose. I choose not publish them as books simply because I find the book-publishing model antiquated and restrictive in comparison to the modern alternatives of content distribution. My work has centered primarily on software development, but now is beginning to focus more on the general topic of “soft skills” which is broadly applicable to all industries.
My educational background is in Physics, which has caused me to look for patterns the describe the world around me. When I left academia for the private sector, that instinct manifested itself as looking for ways to simplify complex problems, with the two most complex being technical in nature and human in nature. There is a lot of literature on how to simplify technical problems, but very little on simplifying people problems. This is my motivation for creating archetypes: an attempt to simplify the problem of working with people.
Science educations are rooted in reductive reasoning, which works very well for technical problems, but if taken too far when describing people can lose practical value and provide a justification for unfair stereotyping. Walking this line of maintaining practical value while discouraging unfair stereotype assignment is a process I take very seriously, and seem to have managed fairly well thus-far based on the feedback I have received.
My (Formerly) Bad Archetypes:
- I have been The Extreme Underestimator, coming in many times over my original estimate on more than one occasion.
- At various points in my career I’m sure my managers considered me The Diva, whether I deserved the label or not.
- Mid-career I was desperate to be placed in a managerial role, and while I was working to get promoted I was The Aspiring Manager.
- Once I realized that I preferred technical leadership over management I became The Wants-to-be-Technical Development Manager.
- After I had transitioned out of management, for about a year I was The Incompetent.
- I have always struggled against being The Idealist, which has caused me no end of troubles when I found myself in the wrong work environment.
- I have been The Hostage Taker when I was trying to mature a framework prior to handing it off to other developers, and while it wasn’t my intention I was indispensable during those periods.
My (Current) Good Archetypes:
- I am a Ghost, and am notorious for disappearing for days or weeks at a time only to emerge with entire systems designed, implemented, integrated, tested, and ready for deployment.
- I am a Healer and have no problem – as a former colleague once put it – nuking a codebase from orbit if I have to.
- I am a Mechanic specifically around building low-code platforms for other developers.
- I am a Sage who has coached a lot of software developers, trained managers, and advised executives on every aspect of being a part of and running a software development organization.
- I am a Rogue, which has lead me to start three companies on my own, as well as lead multiple initiatives while working for enterprises.
- I believe in stoicism, which I apply uniformly in my personal and professional pursuits. Professional stoicism, however, carries with it consequences, but these are consequences which I am perfectly willing to accept.
- I believe in level playing fields, whereby everyone has an equal chance of success, but that success is not guaranteed.
- I believe the fairest environment is a meritocracy where people are judged on what they can do rather than their attributes.
- I am a realist firmly grounded in reality, which is a position that is neither pessimistic nor optimistic.
- I believe that every individual is different and should not be treated as a small, fungible cog in a big machine.
- I believe the best teams are made up of individuals each having a unique strength, and whose weaknesses are balanced with the strengths of their teammates.
- I believe that problems should be defined before an attempt is made to solve them.
- I believe your choice of tool should be made after knowing the problem you have to solve.
- I believe in knowing all of your options before you make a decision, with the first option always being to do nothing.
- I believe that in the face of new information, we can and should change our minds.
- I believe that the majority of issues found on a team can be dealt with if an emphasis is placed on respect and trust rather than process and procedure.
- I believe that when you fix the people, the process will take care of itself.
You can reach me at email@example.com.