Leadership · Apr 2026 – present
TradeGrid
Leading engineering for a student-built Go and React trading simulator: the matching specification, CI, and code review.
- Role
- Vice President of Technology, FinTech Club at UW–Madison
- Status
- Active club project
- Stack
- Go, React, GitHub Actions, Table-driven tests
- student developers
- 20+
- pull requests reviewed
- correctness invariants
- 14
- in the matching specification
- worked examples
- 7
- turned into table-driven tests
The problem
A club team of 20+ student developers builds one exchange simulator together. Correct matching has to mean the same thing to every contributor and every test, whatever language they write in.
Architecture
How the specification drives the code
The matching specification defines terms, price-time priority and execution-price rules, with worked examples. The examples become shared JSON fixtures, which drive table-driven tests of the Go matching engine. GitHub Actions runs those tests on every pull request before review.
- Matching spec to Shared fixtures
- Shared fixtures to Go engine + tests
- Go engine + tests to CI + review
- The specification is language-neutral: it defines observable results, not data structures, so the Go engine and my C++ EngineX can both be checked against it.
- Time priority comes from a defined acceptance order, never from wall-clock timestamps or identifiers.
Decisions and trade-offs
Write the behavior down before the code
The spec became the source of truth for the first implementation and its tests.
Trade-off: Slower to start; in return, a review can point at a written rule instead of an opinion.
How it is tested
- The specification is the behavioral source of truth for the engine's table-driven tests.
- GitHub Actions CI gates pull requests.
Outcomes
- Added GitHub Actions CI and wrote the onboarding guide for new contributors.