Expertise
As I've built my software engineering skills over 25 years, I came to realize that there's much more to creating software than writing a pile of code and hoping the technology gods look favorably enough on it to allow it to work.
I did a lot of this skill building at an enterprise social media management SaaS platform.
As the first engineering hire, I took the enterprise social media management company from nearly 0 to 1, inheriting a pre-MVP codebase written in an MVC framework, fixing a large number of antipatterns—N+1 queries, duplicated logic, lack of true service implementations, complex functionality that should have been libraries—and turning it into a viable product.
When management was often requesting the provisioning of several extra instances at any possibility of a traffic spike—which could easily take an hour or more—I knew the costs of not building a more modern infrastructure were outweighing the costs of building it.
I worked in stages—first containerizing the development environment, then building out CI/CD, then rolling out in Kubernetes and phasing over the DNS—building the environment myself, without new hires or handoffs. That system has carried the company through several years of growth, helping meet its 99.99% uptime SLAs.
With the addition of more analytics features, MySQL’s limitations (e.g. limited time-windowing and limited index types) were holding back performance. PostgreSQL was the logical solution due to its wider support of time-series data and its extension ecosystem. I developed and executed a live MySQL to PostgreSQL migration process that involved only 10 minutes of planned downtime.
As the company’s offerings became more complex, the codebase began showing many of the symptoms of inadequate software architecture: edge-case bugs, proliferating dependencies, heavy reliance on imperative code, an accumulation of quick-fix changes, and decreasing development velocity. Each of these effects compounded the others, and I advocated for incremental solutions, but the company did not have the budget at the time.
However, the company began focusing on enterprise clients, and those clients’ contracts came with development, security and quality requirements spelled out. I impressed on management that substantial updates were no longer optional, and that it was worth doing right. To that end, I pushed for a scope that closed every architectural gap we had been living with.
Domain-driven design (DDD) was an ideal fit for the company’s complex domain. Clean architecture became an essential tool in separating application layers, as engineers no longer had to choose between antipatterns in the name of speed or slowness in the name of avoiding them. I implemented those patterns in a modular monolith Symfony backend with a Vue.js frontend. I kept management and other stakeholders informed of my decisions and rationales along the way, and developed documentation, diagrams, and live walkthroughs to bring other engineers on board and up to speed on writing effective code in the new architecture.
This project also benefited from incremental steps: authentication was federated, asynchronous workloads were migrated after synchronous endpoints, the legacy platform was given the ability to trigger events in the new platform, high-touch customers were migrated one by one.
Hexagonal architecture and event-driven architecture also proved valuable. Certain specialized endpoints required very low latency, so I added a few microservices written in Go.
That system today forms a backend with isolated business logic that is continually evolved and extended. Latency is down 80% in some areas. It’s clear to other engineers how and where new features should be implemented. Because SQL queries are highly isolated and predictable, the sources of database load can easily be identified and SQL queries optimized. I led the company’s effort in SOC2 Type 2 certification, and the updated code required nothing more than small remediations to pass.
From a role perspective, I went from developer to lead software engineer to CTO, owning large parts of the code and infrastructure along the way.