SQL

Upon joining, I came up to speed quickly on the stack of the early version of Pull Workbench, which was very buggy but demonstrated the initial ideas and had a solid set of the latest technologies and patterns established in the codebase, providing for a solid starting point.

I was entrusted to aid our CTO in hiring several additional employees, and so I joined and conducted interviews for the first several months while working with the existing team AI + Full Stack to deliver features and solidify the system, with the aim of keeping it fully working with each merge, after playing a little catch-up to fix the early bugs that worried our business partners, giving them confidence that our team could deliver.

From there, I developed full stack features solo or by pairing with team members, and ultimately led a squad of 5 team members alongside a second squad that together comprised our engineering team.

Much of my time went into authoring complex analytics sql queries using the impressive Kysely library, a fluent, typesafe query builder that we used for our postgres and redshift databases. Given the nature of the product, we needed to make decisions on which queries could be run in real time vs. which queries and subqueries would need to be computed offline as part of a network of airflow dags.

On the ML Ops side I advocated for traceability and reproducibility / determinism of all models and artifacts, and integrated with systems that implemented that, such as Airflow to coordinate DAGs of ML training jobs and Sagemaker's metadata API, which we controlled via model lifecycle automations that produced and stored models, artifacts and metadata that were in turn consumed at runtime or in batch by our analytics stack

On the frontend, I helped us deliver an initial version of the Pattern Editor, a UI and set of APIs that users could use to put together their own patterns of interest, such as looking for certain anomalous ranges of quantities that themselves may be derived from other user-defined patterns. This entailed not only a UI that was DAG-aware but also a layer that converted the json representation of these patterns from the frontend into typesafe kyesely queries to be executed against redshift.

My PM and the business wanted to illustrate to other teams that a fast-paced, fail-fast approach where we released daily (as opposed to 1-3 times per year) would serve us much better in that we could learn quickly, iterate and pivot, without huge costly investments into products that did not meet expectations or deadlines.

Before hiring my team, I set up a CICD pipeline and basic framework of a site that could sustain a heavy and intense crawl from google.

New hires all released to production on their first day of work - a principle I had brought to the table, that it should be so automated and simple that someone could set up and deploy a small feature within their first few hours of working at Sourceability.

Our parts and datasheets website, which also incorporated proprietary availability and quality scores, was used - within 3 months of inception - to successfully sell a 3 year Analytics API contract to an international multibillion dollar company, as well as driving organic traffic and learning how to scale to sustain google crawls of the hundreds of thousands of electronic component parts in our inventory while scaling down outside of the crawl / high-traffic moments.

• Full Stack - React, NodeJS, Typescript, Kubernetes, Gitlab
• Functional Reactive Programming - RxJS, highlandjs
• Daily Production Deploys - Canary Deployment w/ K8s
• Constant Collaboration - No “throwing over the wall”
• CI/CD Automation Pipeline - Every user story gets an instant shareable environment
• Coaching / Mentoring / Leading diverse team

Having shown in Quoting (F3) and REF 2.0 (UI Framework) that tests and low complexity policies led to fewer bugs and higher velocity by doing some a/b studies, the business invested in tooling to automatically measure and enforce policies across the Direct Quoting line of business software development teams.

These teams used a variety of software stacks and technologies, including proprietary build and release systems.

I consulted with the build and release team, at the time, a separate team, to understand their plugin architecture which already was in use for all said teams.

Next, I worked with each team to understand their level of code coverage across different types of tests (unit, integration, end to end), and agree with them what targets they wanted to meet, and at what point in time.

Some teams required me to implement coverage measurement tools. Keep in mind that we were not able to use open source tech, and actionscript had no unit testing or code coverage tools.

I worked with a mentor of mine to write a lexer-parser-generator, which took the grammar for the actionscript language and allowed us to instrument our codebase with a pre-build step that inserted beacon calls with metadata into the various methods of the application. The coverage monitor and unit test UI was written in C#.

I exposed the coverage reporting service using web services running on SOAP via MS ASP.net WCF communications stack. Initially an MS SQL database housed the data, but as it grew, we moved it to a data cube where various dimensional summary and BI queries could be more efficiently run without interfering with the transactional nature of concurrent builds reporting their metrics in across the business.

Built upon existing code analysis and instrumentation tools to create a cross-platform solution for the build-time analysis of unit and system test code coverage, cyclomatic complexity, code coupling, defect density, change volume, maintainability, and other quality metrics. Data from many different proprietary formats is transformed into a single canonical format, where it is in turn normalized into a relational structure to facilitate on demand querying for system-level quality benchmarking, real-time code quality reporting, providing objective insight into QA risk assessments / test strategies, and enforcement of architectural standards and constraints.

We went through several iterations of the website, but our goals were SEO optimization and systematizing the internal booking process with salesforce while exposing certain information about entertainers, acts and availability through the website, and keeping those in sync with entertainer calendars.

With the help of some interns, I designed and built the website from the ground up, and hosted it at Cleveweb.com, the software solutions company I had formed a few years earlier.

montgranite.com - supplier of natural stone website. After assessing their products, we categorized them according to stone type, colors, texture and brand, then I created a MySQL database and an ORM to read/write PHP objects and their relationships from the database and present it as a front-end, which I designed to resemble a piece of marble.

I then hosted the company's website and email for a number of years afterward and actively updated the site on retainer.