Olo

From individual contributor to a project lead with organization-wide influence.

From January 2016 – January 2019, I was a front-end-focused software engineer at Olo, a scale-up-phase startup which is the leading provider of online ordering for large restaurant brands.

As a Software Engineer (January 2016–May 2017), I was a productive individual contributor even while working 30-hour weeks as I completed my M. Div.:

• I led the adoption of a test-driven development approach in a greenfield Ember.js rewrite of our mobile web UI.
• I introduced JavaScript type systems to the application (landing on TypeScript after an initial experiment with Flow)
• I helped us achieve full AA WCAG accessibility.

As a Senior Software Engineer (May 2017–present):

• I led a team effort to expand our mobile web UI as a responsive web UI to reduce our maintenance burden, improve our overall UX, and decrease the cost of launching new features.

• I designed a new technical strategy for white-labeling (including the adoption of CSS Modules), enabling the business to support more brands by way of better tooling.

• I pioneered Olo’s use of Requests for Comments (RFCs), modeled on the RFC processes from the Rust and Ember communities, as a tool for architecture design and documentation. I began by using RFCs for several important initiatives in my own team. The success of those initiatives validated RFCs’ utility when I later introduced them to the broader engineering organization. They are now Olo’s standard tool for documenting architectural changes and a prerequisite for all new internal services.

• I finished our app’s conversion to a fully strictly-type-checked TypeScript application.

Throughout my time at Olo, I:

• led the community effort to integrate TypeScript with Ember.js
• helped launch a shared component library for future rich client projects
• have delivered over a dozen internal tech talks on subjects including managing technical costs, Ember.js basics, functional programming techniques, and introductions to Rust and Elm
• substantially reshaped our front-end engineering practices and tooling choices as an informal leader among our front-end engineering group

I have matured significantly as both an individual contributor and a leader in my time at Olo. For the first time, I have been able to make a substantial difference at the team level, at the organizational level, and at the level of the broader technical community.

HolyBible.com

A formative experience: a technical success but a product design failure.

HolyBible.com is a beautiful interface for reading the King James Version of the Bible and the Reformation Heritage Study Bible materials online, built for Puritan Reformed Theological Seminary. The MVP launched in December 2014, with approximately 30 months of small bug fixes and feature enhancements following.

I worked closely with a designer to create the visual language for the app before diving into the implementation. The app uses AngularJS, Express/Node.js, and PostgreSQL; I also did a great deal of XML-mashing in Python for the Bible source text and study Bible integration.

The project was a substantial technical success: it has rarely crashed and had no bugs reported since spring 2017. I’m doubly proud of the project because it was only the second time in my career I’d built an entire non-trivial web application from scratch, and the first time I did so solo.

On the other hand, the project was a product design failure. The site is beautiful and functional, but it failed to meet the seminary’s goals for driving more traffic to the seminary landing page. My failure to establish what “success” meant to the seminary led me to deliver a technically-solid piece of software… that solved the wrong problem.

Quest Consultants, Inc.

Collaborating across disciplines effectively and transitioning to remote work.

From May 2012–January 2016, I worked (first as a full-time employee, then remotely as a half-time consultant) for Quest Consultants, Inc.. During that time:

• I improved the performance of one existing computational hazard model by a factor of 7.
• I rewrote another computational model in C (from Fortran 77).
• I supported another rewrite effort (again from Fortran 77) to Python 3.
• I helped the team adopt Mercurial for version control and JIRA for bug tracking software.

Those efforts taught me a great deal about communicating effectively with domain experts, working remotely (as I did beginning in January 2013), testing effectively, refactoring legacy codebases safely, and wrangling large software development efforts over time.

Northrop Grumman

Learning the basics of software engineering.

From July 2009–May 2012, I worked as a Software Engineer I on the B-2 program at Northrop Grumman. My work included writing C (targeting a real-time operating system) and developing requirements for a modernized message bus architecture. My basic implementation of the Sparse A* Search Algorithm¹ was used as a performance baseline for route-finding software on the platform.

Over those three years I acquired a good dose of humility and basic knowledge of software engineering, including the use of bug trackers and source control, strategies for testing, and patterns for writing maintainable code.

Miscellaneous Consulting

Teaching myself web development.

Beginning in January 2010, I taught myself web programming, beginning with PHP and jQuery and the LAMP stack. Having a good working knowledge of HTML and CSS from designing my own blog in college, I decided to learn web development. I began by building church websites and blogs for friends in WordPress. Later, while working as a subcontracting consultant for Innova Computing, I developed a custom CMS for the Oklahoma Board of Medical Licensure.

My goal throughout was not merely to make some extra money, nice though that was. Rather, I aimed to transition from the world of C and Fortran where I began my career to working full time in UI-focused web development. (Mission accomplished.)

TypeScript and Ember.js

As we began actively adopting TypeScript in our Ember.js app at Olo, we very soon ran into the limitations of the existing support. Integration with Ember’s CLI tooling was limited; the type definitions were a mix of incomplete, unhelpful, and outright wrong; there was little information about how to use TypeScript effectively with Ember; and, worst of all, no one was actively contributing to fill these gaps—much less leading.

In March 2017, I began working on the CLI tooling and the type definitions for the Ember ecosystem. Once I began leading the effort, several others began contributing actively; in early 2018 we formed a small team working on shepherding Ember and TypeScript integration forward. Over the rest of 2017 and 2018, I have taught and written extensively on using TypeScript effectively with Ember. Our small team’s efforts have made TypeScript both viable and increasingly mainstream as a choice for Ember apps and addons.

True Myth

In the fall of 2017, I developed True Myth: a TypeScript-targeted library with Maybe and Result types. Several existing libraries in the space work excellently but had a number of downsides, including second-class support for TypeScript, runtime overhead, and APIs designed to mirror Haskell or Scala rather than idiomatic JavaScript. True Myth was my attempt to fill that gap. It takes advantage of TypeScript to supply idiomatic JavaScript APIs with zero runtime overhead (beyond the inherent cost of the container types themselves).

True Myth is largely complete, with a full set of features and extensive documentation. I continue to maintain and expand the library with additional helpers and tooling as TypeScript has supported more capabilities. I have also supported early efforts to translate the library to C^♯.