I joined pull.systems as a contractor to help get it to a v1 after its seed round, where it was spun up out of an incubator and funded by Porsche, also its first paying customer. It is an EV analytics platform that analyzes vehicle data and telemetry to predict anomalies, patterns, and ultimately assist the customer in identifying problems and investment tradeoffs.
As a staff engineer, I was hired as a contractor to get the system from its buggy alpha state to a working v1, building on the solid foundation laid down by the previous team. The CTO was one of the smartest people I had the pleasure to work for, and although we had different perspectives on requirements discovery and agile, we both invited differing opinions to be shared and critiqued from each other and from the team, resulting in an environment of honesty and healthy debate. I truly enjoyed our work and was very glad to help get the team to v1.
Read more...
Project: Pull Workbench v1
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.
