The Tech

I prefer functional code to OOP, ergo Go and scripting languages. More generally, for most developer problem-domains the bottleneck is IO. E.g. API calls, DB calls, disk writes, etc. As such, in most cases Node is excellent. It’s quite fast, and the ergonomics are top notch. However, it does force developers into a multi-process paradigm (e.g. Kubernetes). For problems that require multithreading over multi-process (e.g. Tensorflow, CSS rendering, fintech pricing), Node is not a good choice, and a second language is reuqired. Similar to Google’s Python + C++ architecture. More on Rust below!

I’m passionate about CI and CD. Good CICD directly translates to developer productivity and team confidence.
On the CI side, imagine being able to test everything on every commit (more on testing below). I wrote many of Kindred’s pipelines, including in-pipeline dockerised integration tests (using docker-in-docker), load tests, multi-pipeline E2E tests with ephemeral environments (using kubernetes-hnc), and lots of other goodies. Good CI changed the way I hire QAs.
On the CD side, sports betting is a highly regulated industry. There is a joke at Kindred: “Kindred is a compliance company that occasionally takes a bet”. This significantly complicates our deployment workflow. Gitflow, gitops, government audits, gated workflows. We are still wrangling with this and iterating towards an “ideal” workflow. 

In the relational space, I spent a fair bit of time with MySQL and PostgreSQL. Things like indexes (composite, hash, functional), keys (primary, foreign, unique), migrations, `explain analyze`, isolation levels, efficient bulk queries, and avoiding ORMs (cognitive overhead, lazy/eager loading performance).

In the NoSQL space, I built the startup’s MongoDB cluster (shard keys and all). These days, I prefer to use a hybrid approach: postgres + jsonb (credit to Emil Koutanov). I also built the startup’s Solr instance and queries. Solr’s “edismax” queries were incredible. Fantastic tech.

The startup began with a php web app and an iOS app. The most senior engineer (Ruslan Starikov) and I had to make a decision on what to do next. This was at the time of Angular 2.0. We didn’t like Angular’s monolithic approach, the breaking changes of 1 => 2, nor the combination of html + js files. Conversely, we liked that React is in essence just a library for writing html in javascript. This is representative of my general approach to engineering, i.e. the Unix Philosophy. It also allowed us to roll the entire app into one “binary”, making hosting super easy. From there we built up the ecosystem with state management (this was the early days of Redux, so we wrote our own Flux implementation). Then routing (with react router) – we hit some walls with SPAs and Google SEO. And so on.

We also considered react-native at the time we made the decision. I was against react-native for two reasons: technicals and politics. On a technical level, these translation layers tend to be janky (think Xamarin). Apple may change its APIs as it sees fit, and Facebook may or may not keep up. On a political level, Facebook and Apple have a relationship of convenience and that may change tomorrow. It’s hard to tell where that would leave react-native. Keep in mind that Apple has a history of nuking software from their walled garden (think Adobe Flash). It’s when we wrote a proof of concept using Electron.js that we became confident that we are on the right track.

Generally speaking, in my experience, the major benefit of the cloud for engineering teams has been Infrastructure as Code. I.e. it allowed teams to manage their own infrastructure. 

Toggle Content

The majority of my experience with message-oriented-middleware has been with Kafka. Things like:

– partial sort order & msg keys
– headers & versioning
– compression, LZ4
– batch operations, de-duplication, tweaking batch size
– (we didn’t get to parallel processing of a batch yet)
– kafka-ui, kowl
– outbox pattern (we didn’t use it)

Emil Koutanov wrote a book on Kafka, so a lot of questions go in his direction.

Toggle Content

Toggle Content

Toggle Content

– databse migrations
– twelve-factor apps
– ephemeral environments
– dependency injection, service providers
– facades (slf4j, open telemetry, open features)
– statically-defined contracts (open api)
– async/await workflows (IO is the biggest bottleneck)
– code quality (formatting, linting, static code analysis, sonarqube)
– testing (see above)
– fully self-contained component tests (act as documentation)
– security (trivy, snyk)
– trunk based development
– layered architecture
– load tests on day zero

I am a Mozilla guy from the 90s Netscape days. Firefox is written in C++, and Mozilla decided that C++ was not fit for purpose. Namely, the highly parallelised CSS rendering engine. As a result, Rust was born. To me this is very significant. Rust was not built as an academic exercise, nor a convenience, but as a solution to a fundamental limitation of C++. This is why it has potential. If you want to know more about the motivation, look into Firefox Quantum. I drove some early adoption of Rust at Kindred. However as a manager, it has been delegating, rather than hands-on.