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”.
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.
In January 2021 the Dutch government announced curfew/avondklok that forced almost everyone to stay at home from 21:00 to 4:30.
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.
A wristwatch from The Walking Dead: Saints & Sinners (VR zombie game) seemed like
the ideal interface for an app like that:
Aiming to achieve a similar experience, but without the zombies, the mockup looked like this:
In the game, a player also hears a bell when the dangerous time starts. The app uses push notifications instead.
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:
Expo provides two kinds of releases:
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:
(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:
(green - safe and automated, blue - unsafe and automated)
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.
The UI didn’t get much bad feedback, and was easy to implement:
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.
The selected tech stack probably is not the best for an app that needs to have reliable notifications. Discovered downsides:
@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.
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.
A few weeks ago
I finished reading Become an Effective Software Engineering Manager by James Stanier. Overall it’s a
nice book, it gives a good overview of possible responsibilities and
expectations, covers good and not so fun parts of the role, and
explains all the relevant ceremonies.
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.
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.
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.
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.
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.