All notable changes to this project (my career) will be documented in this section.

The format is based on Keep a Changelog and this project adheres to Semantic Versioning.

🔗8.0.0 - Staff Software Developer @ Shopify (2025 to 2026)

🔗Added

• Member of shop.app Buyer Acquisition (growth) team, focused on the Shop Cash domain.
• First open source contribution to the smart_todo gem, adding support for a context attribute referencing GitHub issues (see diff).
• Contribution to the transition of the shop.app ecosystem to YugabyteDB, including ownership of migration for one of the highest QPS tables (top 20).
• Technical design and implementation of an affiliate payout program in partnership with impact.com.
• Use of Claude Code in daily development workflows.
  • Creation of Claude Commands to automate repetitive tasks.
  • Development of Claude Skills to encode domain-specific knowledge.
  • Development of a Claude skill for ATC (Air Traffic Controller) support rotation, leveraging multiple Model Context Protocol (MCP) integrations to collect data and guide decisions based on team runbooks.
  • Motivated the creation of RangeLink and my-claude-skills.
• Use of Ruby; ramped up quickly through The Pragmatic Studio's Ruby Programming course.
• Use of Ruby on Rails and related ecosystem:
  • ActiveRecord
  • ActiveJob
  • Sidekiq
  • Maintenance Tasks
• Use of RuboCop for code style enforcement.
• Use of Sorbet, RBS, and inline RBS for type checking.
• Use of Redis.
• Use of GraphQL.
• Use of Docusaurus for internal documentation.
• Use of Graphite.
• Use of Buildkite.
• Use of Google Cloud Platform (BigQuery being the one I used the most).

🔗Deprecated

• Octav made a company-wide reorg as part of a strategic pivot and I had to find my next adventure.

🔗7.0.0 - Principal Software Developer @ Octav (2025)

🔗Added

• Transition to crypto/blockchain world; shout-out to Luc Blackburn and Mathieu Baril for providing the opportunity to enter this world.
• Many LinkedIn Learning certificates; check them out!
• Professional portfolio website: ouimet.info. I really like my Career Changelog section 🤓.
• Knowledge in the crypto and DeFi space about L2s, block explorers, smart contracts (ABIs), DEXes, MEV (Maximal Extractable Value), flash loans, cross-chain bridges, AMMs, CLMMs, liquidity pools, lending, borrowing, staking, rewards on EVM-compatible chains and Solana. (Rugs and scams included! 🙁)
  APIs and libraries: DeBank, DefiLlama, Etherscan, ethers, viem and many more!
• Implementation of the Stader protocol in a forked version of the SonarWatch Portfolio project.
• Migration of a GitHub repository that contained a single npm package to a monorepo with multiple packages using Turborepo and changeset.
• Centralized GitHub Actions repository to reduce duplication across CI/CD workflows and improve maintainability.
• Structured logging across services, enabling efficient log filtering and analysis via AWS CloudWatch Log Insights.
• Use of Terraform.
• Use of Docker image layers to provide seed data to dev and test environments.
• Use of BullMQ.
• Use of Express.
• Use of Sequelize.
• Use of Sentry.
• Use of CodeRabbit.

🔗Deprecated

• Flexport made a reorg in 2024-10 and it was my turn to look for a new adventure.

🔗6.2.0 - Senior Staff Developer @ Flexport (2023 to 2024)

🔗Added

• Integrations between Flexport's freight-forwarding core systems with the newly acquired fulfillment business (known internally as omni-channel).
• Foundation for an abstraction layer to smoothly transition ~80 microservices to AWS SDK V3 and out of Node.js v16.
• Knowledge in the global logistics and supply chain industry, focusing on omni-channel fulfillment.

🔗Deprecated

• Shopify sold its logistics division to Flexport in 2023-06.

🔗6.1.0 - Senior Staff Developer @ Shopify Logistics (2022 to 2023)

🔗Added

• Member of the Technical Leadership Community (TLC), a group of 8-10 leaders from across Shopify Logistics' sub-divisions meeting at a weekly cadence; shout-out to Jeremiah Brazeau, the group's main facilitator.
  • ~300 developers in scope, formed through the merging of Deliverr, 6 River Systems, and Shopify Fulfillment Network (SFN) into the single Shopify Logistics division.
  • Sounding-board role for validating system designs through collaborative discussions.
  • Presentations and video capsules on patterns like the transactional outbox and sagas (orchestration vs. choreography).
• Implementation of observability-as-code for the inbounds sub-org's serverless services.
  • Spec defining three observability pillars: success rate / availability (successful requests over total), volume throughput (messages per queue, requests per endpoint), and execution time / latency (Lambda durations, API response times).
  • Domain-specific language (DSL) in monitors.json, with automation generating the observability.yml file consumed by the serverless-plugin-datadog plugin during serverless deployments.
  • Per-environment thresholds (staging vs prod) via YAML placeholders in the generated observability.yml.
  • DataDog monitors tagged for filterable dashboards (e.g., domain: inbound, subdomain: prep, team: prep); the same tag-rich, continuously-evolving monitor set also backed manually-created SLOs per service.
  • Koa middlewares and AWS Lambda wrappers in the reference implementation for harmonized metric instrumentation across services.
  • Initial incubation in the prep service, then publication as a standalone package in the private npm repo for adoption across the sub-org.
• Cross-team facilitation in the inbounds sub-org around domain boundaries and sources of truth, where organic service spinoffs had introduced duplication and unclear cross-domain data ownership. Push toward EDA / integration events as the pattern for resilient async cross-domain communications.
• Contribution to TLC specs for cross-cloud (AWS ↔ GCP) eventing standards between Shopify Logistics and the rest of Shopify, building on Shopify's Monorail format and the prior integration-events spec from Deliverr. Initial scope: async communications (the synchronous side handled by the Logistics API project). Domains spanned merchants, products, and the fulfillment-center pick-pack-ship process (including robot-assisted operations with Chuck).
• Contribution to the prep portion of what became the Logistics API: a single point-of-entry API for internal and external partners that centralized authn/authz, rate limiting, and orchestration in place of exposing 60+ microservices directly. The project shipped under Shopify Logistics and moved to Flexport after the sale.
• Continued tech leadership of the prep team through the acquisition; team grew by one engineer from the SFN division. Operations stayed on the ex-Deliverr AWS accounts, GitHub orgs, and repos. SFN didn't carry a prep feature, so there was no overlap to harmonize; the team's roadmap and velocity remained stable.
• Knowledge in the logistics industry, spanning fulfillment and supply chain integrations.
• Key relationships at Shopify Logistics:
  • Artur Rivilis: Deliverr's VP of engineering at the time; sponsored my level-up to Senior Staff Software Developer during the cross-division leveling exercise across Deliverr, 6 River Systems, and SFN.
  • Biniam Bekele and Alireza Assadzadeh: co-authored the observability-as-code spec with me.

🔗Deprecated

• Shopify acquired Deliverr in 2022-07.

🔗6.0.0 - Senior Developer @ Deliverr (2021 to 2022)

🔗Added

• Founding engineer on the prep team (4 engineers initially, growing to 8), building the prep service: a self-serve offering for prep activities like bagging, labeling, and kitting (often called "FBA prep" in the industry, but here offered through Deliverr's 3PL platform without an FBA-specific tie-in). Operations had been running prep manually for months via Google Sheets and Asana boards; once the business validated the demand, we built it as code. The POC started inside the existing inbound microservice, then spun off into its own standalone service using the strangler pattern. The team treated the prep service as an incubator for new patterns to validate before any ecosystem-wide rollout.
  • Pivot from a CRUD MVP to a domain-driven design (DDD) service to enforce a rigorous lifecycle for prep jobs through a finite state machine, mirroring the OMS approach I had built at SSENSE. The team was initially skeptical of "finite state machine" by reputation, then embraced it once they saw how minimalist the implementation became.
  • Event storming sessions with engineering, product, and business stakeholders to map the prep-job lifecycle. Followed up with state diagrams that informed the DDD aggregate design.
  • First service in the Deliverr ecosystem to implement the transactional outbox pattern. Solved the two-phase commit problem (DB transaction commit + message emit) and replaced Deliverr's existing reverse-engineering approach where CDC pipelines inspected raw DB before/after records and had to reconstruct what business event had happened. Building the event as part of the same transaction kept the business logic where it belonged instead of scattering it across services, removed the "phone-home" pressure those reverse-engineering pipelines created across the ecosystem, and avoided the risk of the CDC pipeline reading data that had already moved on since the original transaction. On the publishing side, prep's outbox pipeline used SNS fan-out (rather than direct SQS queueing from publishing code) so any interested domain could subscribe without prep needing to know about them.
  • Original specification for integration events in the Deliverr ecosystem. Naming convention <Domain>.<Aggregate>.<Event> in past tense, with versioning. Distinguished integration events (cross-domain) from domain events (within a domain). Published a shared, SemVer'd npm package that provided the skeleton and base interfaces so any domain could build its own integration-events package on a common foundation. The pattern was later adopted by more teams and their respective services.
  • Introduction of inversify for dependency injection in the prep service. First use of inversify anywhere at Deliverr; the cleanly-structured code that resulted became one of the visible incubation wins for the team.
  • Small monorepo for the prep service with three independently-versioned packages: the backend service, the prep client (consumed by other services), and the prep-specific integration-events package (built on the shared skeleton above). Each evolved at its own pace via SemVer, avoiding version-skew bugs.
  • Anti-corruption layer when connecting prep to other domains, keeping the prep domain model clean from upstream concerns.
  • First adoption of domain probes in the Deliverr ecosystem; used in the prep service to increment metrics on business-significant events without polluting entity-focused services with cross-cutting observability concerns.
• Ongoing contributions to the GitHub template repo that new Deliverr services cloned as their starting point. Patterns and components incubated in the prep service often graduated here for ecosystem-wide adoption.
• Ongoing contributions to shared npm packages used across the Deliverr ecosystem, following the Boy Scout Rule of leaving each surface a little better than I found it. Encouraged team members to do the same with the components they built.
• Topic-focused Slack channels I created and curated:
  • #serverless: org-wide serverless guidance.
  • #event-driven-architecture: announcements and adoption signals for our internal integration-events packages, EDA-focused articles people came across, iterations and improvements to our transactional outbox implementations and CDC pipelines.
  • #domain-driven-design: "DDD from the trenches" posts linking real PR comments on our team's work to the subtle differences between CRUD-stack organization and DDD aggregates / entities / value objects, and DDD-focused articles people came across.
• Adoption of tsoa in the prep service: shout-out to Gal Tidhar, the first tsoa evangelist in the engineering org. The initial integration required Java installed on each engineer's laptop and couldn't run in CI without it. The resulting manual process was error-prone and drew pushback from the wider engineering org. I brought Docker wrapping (so neither laptops nor CI needed Java), automated the tsoa tooling in CI, and added a safety net that diffed CI-generated tsoa output against PR content to catch and block discrepancies. Other teams then adopted tsoa in their projects.
• Regular PR and technical design document reviews across teams beyond prep.
• Winner of the Rookie Rockstar award at the Engie Awards 2022, voted by engineering peers for the highest-impact contribution from a developer who joined Deliverr in the prior year; shout-out to Jessie Won (prep team's PM at the time) for writing the recipient text.
• Knowledge in the fulfillment and warehousing industry.
• Key relationships at Deliverr:
  • Mikhael Levkovsky: referred me to Deliverr and supported me through the interview process.
  • Flynn Fishman: hiring manager, then skip-level (then skip+1). His mentorship was often framed around a simple question, "X is a good idea, but is it the right time to do it?", that still haunts me today.
  • Steve Xian (Deliverr's founding engineer) and Stewart Buskirk (a trusted early engineer): trust and openness that let new teams champion new patterns and libraries inside their own services as incubators.
• Use of Maxwell as our change data capture (CDC) solution.
• Use of additional AWS components: Kinesis Data Streams, Parameter Store.
• Use of Zod.
• Use of Koa.
• Use of esbuild.
• Use of split.io.

🔗5.0.0 - Tech Lead @ SSENSE (2019 to 2021)

🔗Added

• Member of the Technology Architecture Group (TAG), a group of 6-10 architects, Staff & Principal Engineers responsible for reviewing and suggesting the standards and best practices to be adopted by the development teams across the department.
  • Oversight of projects from 3 other teams to ensure adherence to those standards while still reaching the targeted software *ilities.
  • With most of SSENSE running on Kubernetes, my teams happened to be among the heaviest serverless users; this meant the other engineering teams knew they could reach out to me and draw on my TAG knowledge.
• Project to peel-off the order management system (OMS) out of the company's monolith into its own distributed, fully-serverless OMS to support SSENSE's international expansion. Upward contact was Mário Bittencourt (principal architect); I oversaw and reviewed the work of 3 teams (two with their own tech lead).
  • Reverse-engineering of the existing monolith's order-handling code with one other engineer (3-4 weeks of part-time, iterative work) to produce complete BPMN documentation of the legacy orders' lifecycle. The monolith had accumulated dead code from previous iterations; we sometimes added metrics and observability probes to confirm whether suspect code paths were still being called from elsewhere in the distributed ecosystem. The BPMN docs became the foundation for the peel-off design.
  • With SSENSE in planning for a second physical facility in Europe alongside its single Montréal fulfillment center, the new distributed OMS design had to factor customs and shipping costs into inventory-sourcing decisions, and account for the limited supply of luxury goods.
  • Separate service to manage the multiple legal entities introduced by the international expansion (e.g., surfacing the right entity across the website's terms-and-conditions).
  • This project was my introduction to domain-driven design (DDD), and the first time I led an aggregate data modeling exercise with teams (see DDD Beyond the Basics: Mastering Aggregate Design).
  • Async "training order" pipeline attached to the checkout service that mirrored every order sent to the legacy OMS as a shadow request to the new one, letting us verify the new OMS's external API stayed backwards-compatible with the contract checkout relied on and plan a progressive rollout without touching it. The pipeline was fully asynchronous: the checkout Kubernetes pods never awaited the shadow call. The new OMS exposed a serverless AWS API Gateway endpoint that validated the request body against a JSON Schema and dropped it onto an SQS queue. Added latency on the checkout path stayed near zero, and replay-from-DLQ was available for free whenever a shadow request hit a bug.
  • Event storming with the inventory and shipping teams (engineers, product owners, and business stakeholders) to agree on domain boundaries and avoid silo decisions.
  • BPMN documentation of the business process, iterated after the event storming sessions.
  • State diagrams for the complete customer order lifecycle defined before writing any code, then implemented as an explicit finite state machine in TypeScript. See Building a Finite State Machine from Scratch using Domain-Driven Design by a former OMS colleague.
  • AWS Step Functions orchestration of the customer order lifecycle, split across smaller-scoped Lambdas (one per domain operation). The decomposition gave us Step Functions' built-in retries and error handling at each step.
• First end-to-end project at SSENSE: an automation for the CBSA B13 export-declaration form, covering eligible orders that needed customs paperwork. I owned the system design and guided the implementation team. The successful delivery of this project was my entry ticket into SSENSE's Technology Architecture Group (TAG): other members saw the work and put forward my name.
  • Rather than integrating with the CBSA system directly, we worked through a third-party provider that abstracted the actual CBSA API's implementation details.
  • First time using the C4 model for system documentation.
  • First time consuming DynamoDB Streams from Lambda (Lambda itself wasn't new; the streams-to-Lambda wiring was).
  • First time using SOAP in a TypeScript world.
• Back-end contributions to the product information management (PIM) system in Python.
• Contributions to SSENSE's internal purchase orders (PO) platform, used by buyers and merchandisers to create and manage POs with suppliers. Front-end implementation with React + Redux; shout-out to Franz Recinos for guidance on the React + Redux ecosystem.
• Winner of Hackathon 2019 with my idea to improve onboarding for new engineers.
• Follow-up from the Hackathon 2019 POC to improve the developer onboarding flow. I built a "Welcome" guide (a PDF generated from markdown files, with direct links to the IT HelpDesk request forms and the core systems a new dev needed access to), scripts to install the core dev toolchain on a fresh laptop, and a process with HR/talent and IT HelpDesk that automated the GitHub invitations.
• Knowledge in the luxury e-commerce industry, distributed order management systems (OMS) and product information management (PIM).
• Key relationships at SSENSE:
  • Nicola Rodriguez, Rob Batten, Dmitriy Kolegaev, and Dominique Belanger: allies on the developer onboarding work that followed the Hackathon 2019 POC.
• Attendance at Confoo 2020 (which included booth duty to promote SSENSE's open engineering positions at the time). After the conference, I built and delivered an internal recap presentation to my SSENSE peers covering the sessions I attended, including my first in-person Bitcoin/crypto talk.
• Use of TypeScript and Node.js; shout-out to Yannick Cordinier.
• Use of GitHub Copilot as my favourite coding buddy.
• Use of Domain-Driven Design (#ddd); shout-out to Mário Bittencourt.
• Use of Event-Driven Architecture (eda).
• Use of SOLID principles.
• Use of hexagonal architecture; shout-out to Pablo Martinez.
• Use of CQRS.
• Use of domain probes for domain-meaningful signals.
• Use of serverless framework with deployments to AWS.
• Use of additional AWS components: DynamoDB, Lambda, Step Functions, API Gateway.
• Use of OpenAPI Specification to officialize our contracts; shout-out to Mário Bittencourt for his article.
• Use of Docker and Docker Compose.
• Use of LocalStack for local testing of serverless components.
• Use of inversify.
• Use of Middy.
• Use of LaunchDarkly for feature flags in SSENSE's trunk-based workflow.
• Use of continuous deployment (CD) across all environments.

🔗Changed

• Title/seniority level to Tech Lead in 2020-08; I was originally hired as a Senior Developer.

🔗4.0.0 - Senior Developer @ Zola (2019)

🔗Added

• AWS Certified Cloud Practitioner certification issued on 2019-04-19.
• Knowledge in the wedding and event planning industry.
• Knowledge in the e-commerce industry.
• Use of Amazon Web Services (AWS) (mainly S3, SNS, SQS).
• Use of microservices.
• Use of trunk-based development.
• Use of feature flags.
• Use of Ansible scripts for manual deployments to staging and production environments, run after SSH-ing into a bastion host.
• Use of Guice.

🔗Changed

• The type of companies I worked for; shout-out to Yan Avery for providing the opportunity to enter startup world.

🔗3.0.0 - Architect @ AFS Technologies (2011 to 2018)

🔗Added

• Scrum Master certification.
• Use of Agile methodologies.
• Skills to develop SaaS solutions.
• Building of REST APIs.
• Knowledge in the consumer packaged goods (CPG) industry.
• Use of Java, Spring framework, Hibernate, Mockito.
• Use of Continuous Integration (CI) pipelines.
• Use of ETL (Extract, Transform, Load) processes and MDX query language in a Microsoft SQL Server Analysis Services (SSAS) environment.

🔗Changed

• Title/seniority level to Architect in 2014-09; I was originally hired as a Senior Developer.

🔗2.0.0 - Senior Developer @ Vidéotron (2006 to 2011)

🔗Added

• Knowledge in the telecommunications sector (specializing on the network management system).

🔗1.0.0 - Senior Developer @ Markzware Software (2001 to 2006)

🔗Added

• Knowledge in the digital publishing, prepress and printing industry.
• Use of C, C++, Perl.

🔗0.1.0 - The Beginning (2001)

🔗Added

• The beginning of my journey into professional software development with a passion for problem-solving and technology.