Will Larson: Staff Engineer



book cover Recently I started to look more and more at different directions to grow, and Staff Engineer by Will Larson looked like a relevant book for that. The book explains the responsibilities of senior+ engineers in different companies with examples and real-life stories, which are even interesting to read.

The book also contains a bunch of advice for engineers who are looking into that direction, but at least for me they felt mostly as “do good don’t do bad”.

Casey Rosenthal, Nora Jones: Chaos Engineering



book cover white I heard a bunch of good things about Chaos Engineering by Casey Rosenthal and Nora Jones, so I decided to read it. And it’s actually a nice and useful book. It does a good job in explaining that chaos engineering isn’t a magical randomly failing chaos monkey stuff, but an experimentation-based approach with measurable and predictable outcomes. The book contains a lot of real-life examples (mostly good) of chaos engineering in different companies from tech, processes, and people sides.

Postmortem on a side project: Curfew Alarm



Context

Official avondklok poster

In January 2021 the Dutch government announced curfew/avondklok that forced almost everyone to stay at home from 21:00 to 4:30.

Hypothesis

As a curfew is an unusual and a new thing, it will be useful to have an app that will notify people before it starts.

Usefulness can be measured by gathering feedback from the app users.

As there are/were no plans to advertise or even promote the app at that stage, the number of installations can’t be used as the success metric.

UX

A wristwatch from The Walking Dead: Saints & Sinners (VR zombie game) seemed like the ideal interface for an app like that: The wristwatch from the game

Aiming to achieve a similar experience, but without the zombies, the mockup looked like this: UI mockup

In the game, a player also hears a bell when the dangerous time starts. The app uses push notifications instead.

Tech stack

As a possible tech stack React Native (with and without Expo), Flutter, and native (Kotlin and Swift) were evaluated.

React Native React Native + Expo Flutter Kotlin + Swift
Familarity 😊 😊 😐 😟
Maturity 😐 😐 😟 😊
Tooling 😟 😊 😐 😟

React Native with Expo was selected because:

  • I’m more familiar with React Native than with the other options (haven’t touched native iOS at all).
  • React Native finally looks mature enough.
  • React + TypeScript is fairly nice to work with.
  • Expo handles all the notifications related certificates.
  • Expo handles all the release build signing.
  • Expo provides OTA updates.

Release and delivery

Expo provides two kinds of releases:

  • Full release that needs to be uploaded to stores.
  • OTA release that automatically got fetched on app launch.

The full release process is done with Github Actions and Expo build infrastructure, but still requires a maintainer to download the produced artifacts and upload them manually to TestFlight and Google Play console:

Full release process (green - safe and automated, red - manual)

The OTA release happens on every push to main / every PR merge after tests and linters, the delivery process is handled by Expo:

OTA release process (green - safe and automated, blue - unsafe and automated)

Processes

Despite the project having only me working on it, I decided to stick with kanban at least to track the progress and don’t forget about the next steps.

As the board, Github Projects were used.

What went well

The UI didn’t get much bad feedback, and was easy to implement:

Implemented UI

React Native + Expo + TypeScript stack was nice to work with, there were no tooling related problems and even the type definitions were available for all the dependencies.

The AppStore release process is surprisingly easy and fast. The first release review took less than a day.

The OTA release process works and doesn’t require manual interactions.

Github Projects are fine to work with as the board.

The app actually works.

What could have been better

The selected tech stack probably is not the best for an app that needs to have reliable notifications. Discovered downsides:

  • Background tasks aren’t that reliable (seems like only a native solution can provide reliable background tasks).
  • The app size is huge (50+ mb).
  • Vendor lock on a third party, ejecting when you use a lot @expo/ packages might not be that easy.

When the app receives an OTA update, the launch time is noticeable (around 3 seconds).

Google Play console review time is significantly longer than in the App Store. The first review took more than a week.

The app isn’t actually that useful.

Mark Richards, Neal Ford: Fundamentals of Software Architecture



book cover white Recently I finished reading Fundamentals of Software Architecture by Mark Richards, Neal Ford. From my point of view, it’s mostly a good book. I really enjoyed the part where different architecture approaches were explained and the idea of scorecards at the end of the chapters which shows the pros and the cons of the described approaches is nice. I also liked that the book doesn’t go too much into implementation details and possible tech stacks, but mostly stays on the high level.

The soft skills part of the book about behavior and handshaking with other people is a bit weird. The example with the bullying of a Scala enthusiast to convince them to stop pushing Scala into the project is kind of fun though.

Neal Ford, Rebecca Parsons, Patrick Kua: Building Evolutionary Architectures



book cover white Recently I’ve read Building Evolutionary Architectures by Neal Ford, Rebecca Parsons, Patrick Kua and it’s an interesting book. It shows how an architecture of a system might need to change over time, and with what principles and ideas it can be built to make the whole process less painful. The part about the possible changes in the data side of an application was useful for me. A nice thing that the book doesn’t try to sell a specific architecture (like microservices books), but covers different approaches.

As a downside, the examples/case studies in the book are about not that big systems, and the idea of testing and automatically measuring architecture complexity doesn’t sound that much applicable to something a bit bigger.

Julie Zhuo: The Making of a Manager



book cover Not so long ago I decided to read The Making of a Manager by Julie Zhuo, and it seemed to be mostly a nice book. The book explains the role nicely and gives a few self-checks if the role is interesting for you or not. It has good content on preparing and delivering feedback, which was quite useful, at least for me. The book also covers a few good points on organizing communication and improving meetings.

On the other side, some parts of the book felt a bit too facebook specific. But overall, the book is interesting and useful.

Andrew S. Grove: High Output Management



book cover Recently I wanted to read something about the old school and not new fancy tech management, so I decided to read High Output Management by Andrew S. Grove. And I enjoyed the book. It gives a gasp into a management role with a few cases with explained decisions and outcomes. Although the book is a bit old, it still sounds relevant and a lot of described processes I’ve experienced at work.

Overall the book is a nice reading, but I’m not a manager though.

Titus Winters, Tom Manshreck, Hyrum Wright: Software Engineering at Google



book cover white Not so long ago I stumbled upon Software Engineering at Google by Titus Winters, Tom Manshreck, Hyrum Wright, and decided to read it. Most parts of the book are nice, especially the parts about engineering management, about the deprecation processes, and about their build systems and infrastructure. Some parts are too basic and a bit obvious, e.g. almost every chapter about testing. The culture part of the book even sounds like some sort of a company handbook, which is kind of ok for the book with a company name in the title.

In general, the book is nice and mostly interesting to read. It gives a sneaky peek in the company work environment, culture, and processes with good and bad parts. The book also has some corporate vibes, that some people might even start missing because of the lockdown.

Brendan Burns: Designing Distributed Systems



book cover white Recently I thought that it might be nice to read Designing Distributed Systems by Brendan Burns. The idea of this book to show (or even define) common patterns of parts of distributed systems is awesome, but the book doesn’t have it. Some parts of the book are nice, it has a good explanation of serverless. But most of the book is just examples of different ways to put containers in Kubernetes.

The use cases in the book are really weird (eg use of a sidecar container to add https to a legacy app you don’t have source code of, what?) or I’m using Kubernetes in a wrong way.