
## Notable Project #1: Clinical Content Management System

During my initial tenure at McKesson, I became privy to the challenges faced by the Clinical Information Services team, affectionately referred to as the Content team. Their struggle with outdated toolsets, particularly evident in the arduous process of content creation within both the original and new EHR products, piqued my interest. With smaller content types, such as Labs, requiring up to 10 hours for inception to production, and larger types like Regimens necessitating 1-2 days, it was evident that our workflows were hindered by obsolete ETL processes spanning multiple teams.

It wasn't until my promotion to Lead Architect in February 2023 that I found an opportunity to effect meaningful change.

### Problem Statement

Given the imperative to revamp processes for various content types, I prioritized addressing the inefficiencies surrounding Labs. The overarching aim was to streamline development and delivery on a per-content-set basis, expediting tool deployment to the Content team.

Labs remained solely developed within the original EHR product, serving as the last vestige of code preventing its sunset. The significance of retiring this outdated system extended beyond mere efficiency gains; it addressed numerous Information Security concerns inherent in the original application.

### Solution

Navigating the landscape of transitioning from the old to the new EHR, I spearheaded the development of a new standalone application. Faced with resource constraints, I engaged available assistance during innovation time to determine our optimal tech stack. Ultimately, we adopted React for the frontend and Node/Express/Postgres for the backend.

Seeding data from the new EHR via ORDS (Oracle REST Data Services) and subsequently transforming it into our Postgres database allowed us to establish a unidirectional data flow under our complete control. This newfound control facilitated mass publishing to production, a feat previously unattainable with our antiquated toolset.

Additionally, we crafted a custom SNOMED tree, organizing Labs hierarchically using a Dewey Decimal System convention, a familiar framework for the Content team.

### Result

The transformation was palpable as the Content team achieved remarkable efficiency gains. Building a lab now requires less than 5 minutes, with deployment to production taking less than 10 seconds. This monumental improvement starkly contrasts the previous labor-intensive process, where a single lab could consume upwards of 10 hours.

### Technology Used

- React V18
- Redux Toolkit
- Chakra UI
- AG Grid (Enterprise Tree Structure)
- Jest / React Testing Library / Cypress
- Vite
- Node V20
- Express
- Postgres
- Supertest / Mocha / Chai
- Hosted on Azure using Docker, Istio, and Kubernetes

## Notable Project #2: Ontada Design System Component Library

### Problem Statement

Upon joining McKesson in April 2021, I was made aware of an ongoing initiative to develop a React Component Library for the newly established Ontada Design System. Like many large companies, disparate implementations of identical components proliferated throughout our product portfolio. The need for standardization was evident, with the myriad implementations becoming increasingly burdensome for stakeholders at all levels.

### Solution

Given the company-wide mandate to utilize React for all frontend development, our approach to the component library was straightforward. We undertook the development of approximately 50% of the design system components in React 16, subsequently releasing V1 two months later. Iterative development ensued, culminating in the extension of these components to React 18, with a focus on achieving coverage for 90% of use cases.

### Result

The introduction of a singular component library has proven instrumental in consolidating development efforts across the organization. Rather than managing a multitude of disparate implementations, teams now rally around a unified library, fostering consistency and efficiency. Though different products may adopt varying versions of the library, alignment towards a common long-term trajectory remains paramount.

### Technology Used

- React 16 and React 18
- Chakra UI
- Vite
- Chromatic
- Storybook
- Jest / React Testing Library

## Notable Project #3: Typescript Implementation for 5 Inherited Projects

### Problem Statement

In the realm of enterprise software development, the absence of type safety coupled with the lack of code linting and prettification poses significant challenges. This not only diminishes the enjoyment of the development process but also transforms it into a daunting ordeal.

### Solution

The solution lies in a systematic approach, wherein each project undergoes iterative transformation. By prioritizing the conversion of numerous components and containers to Typescript, we embark on a journey towards enhanced code integrity and readability.

### Result

The implementation of Typescript brings forth a multitude of benefits, chief among them being the availability of type checking. Moreover, our endeavors unearthed a substantial amount of redundancy within each project, accounting for approximately 5-10% of the codebase. By rectifying unused variables, eliminating obsolete imports, and standardizing variable types, we succeeded in streamlining the codebase, resulting in cleaner and more robust software. Additionally, this endeavor simplified our testing procedures, paving the way for a more efficient development lifecycle.


Position(s) Held

Dates of Employment

website

tech stack

McKesson


## Main Notable Project: HP 3D Center

### Problem Statement

Upon joining HP on a one-year contract, I assumed the responsibility of leading the frontend development initiative aimed at addressing a critical business challenge.

The primary objective was to provide clients, equipped with numerous 3D printers and auxiliary devices, with a comprehensive overview of each machine's status. This entailed monitoring various parameters such as the printer's current stage in the printing cycle, pending jobs, material levels, and other pertinent metrics, as showcased in the accompanying video.

### Solution

Embarking on this endeavor, we commenced with a greenfield approach encompassing the entire technological stack. The frontend development was anchored on React and React Query, complemented by HP's 3D Print Design System, codenamed Veneer. Simultaneously, the backend infrastructure was constructed using Go, with Redis serving as the designated data store. Data updates were furnished every 10 minutes by our Firmware team, responsible for aggregating and managing the raw data.

Our team composition comprised four frontend engineers (including one lead, two seniors, and one junior), three backend engineers (comprising one lead and two seniors), and two senior QA engineers. Despite the robust team structure, the project's fruition spanned a year. Predominantly, our challenges emanated from collaborating with the firmware team and deciphering the data's cadence to ensure accurate computation and visualization.

### Result

The culmination of our efforts is showcased in the accompanying video snippet:

[![HP 3D Center Video](https://img.youtube.com/vi/93IeL9Xijsw/0.jpg)](https://www.youtube.com/watch?v=93IeL9Xijsw&ab_channel=HP)

### Technology Used

- React 17
- Redux
- Custom Design System
- Vite
- Jest / React Testing Library / Cypress
- Go
- Hosted on GCP using Docker and Kubernetes


Hewlett-Packard (HP)


# Main Notable Project: On-Prem SAML Autheniction to Auth0

### Problem Statement

The team encountered challenges with the existing SP-initiated Single Sign-On (SSO) flow, wherein the Identity Provider (IDP) was hosted on an on-premises server, and the Service Provider (SP) integration into the application varied across partner schools. This setup proved cumbersome due to the disparate authentication configurations of each school, making the integration of a SAML SP into their workflows a daunting task, often resulting in impracticality, if not impossibility, in certain cases.

### Solution

Transitioning to a Cloud-based solution became imperative to alleviate the complexities associated with managing diverse SSO infrastructures. After evaluating various options including Okta, Auth0, and SailPoint, a meticulous assessment was conducted. Collaborating with select volunteer schools, we conducted small Proof of Concepts (POCs) to assess the simplicity of implementation and long-term maintenance requirements for each solution.

Ultimately, Auth0 emerged as the preferred choice owing to its cost-effectiveness, ease of implementation for both our organization and partner schools, and the exceptional support provided by Auth0 in resolving implementation challenges across different environments.

### Result

Before the company's dissolution, approximately 7 months post my joining, all partner schools successfully transitioned to Auth0. This migration facilitated the complete sunset of the SP-initiated SSO flow, thereby retiring our IDP server. Despite the increase in software costs incurred by adopting Auth0 over the on-premises solution, substantial savings were realized on the engineering front. The SSO implementation time was significantly reduced by over 75%, with onboarding processes streamlined to half a day or less, compared to the previous 2-3 days duration.

### Technology Used

- SAML 2.0
- OAuth 2.0
- Auth0
- JWT / PCKE
- React 16
- Redux
- Go


Treetop Commons


## Main Notable Project: Page Builder & Content Management System

### Problem Statement

Similar to McKesson, Cambia faced challenges in effectively managing the content lifecycle, particularly in relation to the content driving member portals across three plans: Regence, Bridgespan Health, and Asurus. The imperative was to establish a system wherein content authors could seamlessly create and deploy content to production while maintaining its intended layout.

### Solution

The initial step involved determining the ideal platform for housing the content. Following insights from two content authors with previous experience in Contentful, a Proof of Concept (POC) was conducted, confirming its suitability for current and future requirements. Subsequently, collaborative efforts were directed towards developing a user interface (UI) abstraction layer atop Contentful's Headless Content Management System (CMS).

Subsequent to establishing the content infrastructure, the focus shifted towards structuring the content effectively for member portals. This necessitated the utilization of technologies such as React DND, Material UI, and bespoke logic to engineer a drag-and-drop page builder. This tool facilitated the creation of multi-column/row layouts employing curated content blocks.

### Result

The resultant solution empowered content authors to effect changes in production autonomously, eliminating the need for developer intervention. Moreover, the system obviated the necessity for new feature development, as content blocks could be generated within the UI abstraction layer, affording content authors the flexibility to construct pages accordingly.


Cambia Health


## Notable Project #1: Scheduler for Compliance Training Rewrite

### Problem Statement

Compligo, the application that Compli was selling, was originally built by a vendor called Matsoft (out of the UK). They used a lot of code from an application that they had built for another client and the resulting code was a mess.

One of the most complex modules was called Scheduler and it was responsible for sending out compliance training on whatever schedule the user set. Given that the trainings had a vast amount of modules (some had 50 or more steps), each with its own schedule for being sent out, the Scheduler code had a hard time getting the trainings out on time and in a performant manner.

The reason for the rewrite was because Scheduler was taking 8 hours per evening to run calculations and distribute trainings and would completely fall over about half the time. We had a lot of ways to fix the problems the next day, but all of the ways were manual and would take up the first half of our development time for the day.

### Solution

It was not a hard sell to C suite that a rewrite was necessary in order to cut down on the Scheduler problem areas. I was afforded two developers to lead to rewrite Scheduler from the ground up with a 6 month timeline. We already knew how the software worked and where all of the problem areas were, so we weren't going in blind.

The first thing we needed to do is move the code away from being a part of the actual Compligo application and into its own service hosted outside of Compligo. Given that the application was built to be self-contained, no APIs existed within the application. It was PHP code and it followed the PHP templating flow to the letter of the law. So, we started there and figured out what APIs we needed to create to get access to the data we needed.

After those APIs were created within the Compligo application, we were able to build out a new service for Scheduler using Laravel, PHP, and mySQL. The new service was responsible for doing all of the complex Scheduler computations, storing the result, and then queueing it to be updated the Compligo database with RabbitMQ. While we could have just used Scheduler to do the computations and then send the result back immediately, we noticed that Compligo could not handle that kind of traffic volume without falling over. So, we had to be very tactical about how to get the data back into the database without overloading the server.

### Result

After the rewrite, Scheduler took around 30 minutes to run every night. The service was very performant and we were missing sending out trainings on time any longer. Also, the load that this took off the Compligo was enormous and we were not having the server issues we were having before.

## Notable Project #2: Users Microfrontend & Microservice

### Problem Statement

After the Scheduler rewrite was complete, we started to see an issue that was being masked by the Scheduler woes. It turned out that the Compligo application could only handle so many user logins at the same time.

To understand why this was happening, you first have to understand how Compligo was deployed. The model that Compli and Matsoft decided to go with (long before I started), was to put multiple Compligo customers on the same server, sharing server resources. If one customer was stressing the server, all of the other customers on that server would feel it. While all of this was setup on AWS with auto-scaling, logging into the application was such a performance hit that if too many customers were logging in at the same time, it would bring the server to its knees and start to throw timeout errors.

### Solution

With the lessons learning from Scheduler, we decided to move away from PHP and use Node and Express to handle the transaction volume in an asyncronous manner. In parallel, our SREs were working on figuring out if we could bring Docker and Kubernetes into our ecosystem.

As we peeled back the layers of the users module, we realized that in order to redo the login, we were also going to need to redo the user management screens. The problem there was that all of these pieces of the user module were so tightly coupled, that even the UI would need to be redone. So, we looked into a bunch of different ways to do this and decided to go with a microfrontend for the User management screen a

### Result

## Notable Project #3: Import / Export Compliance Reporting Rewrite

### Problem Statement

Building on the success from rewriting Scheduler and User login/management, we set our sights on the final performance issue that was plaguging our users: Import and Export. When onboarding new customers, they would have years of compliance data that they wanted to bring into our system so that they could manage everything in one place. The import code was much of a nightmare as the other two modules that we had rewrite, with the added headache that had to be manually run and monitored after hours by an engineer. Thankfully, this is a task we could spread out amongst our engineers so no one was having to work into the night on a continual basis.

On the flip side, the export

### Solution

### Result


Compli


## Main Project: GradPoint Integration for In-House LMS

### Problem Statement

### Solution

### Result


Visions in Education

Main Project: GradPoint Integration for In-House LMS

Problem Statement

Solution

Result

Work Experiences