What to read #1

List of links of interest materials to read with short description.

FOMO? YAMO.

Hype technologies and methodologies aren't necessery.

Why is the file being rsync’d instead of an S3-Ansible-pipeline? — Why not?

Why is there a full fledged Node build environment for a page with a form?

Why is the CSS hand-written (for a single page site)? — Why not?

Why is there no K8s manifest for the project? — Why should it?

Why was this desktop application (200 MB) with two buttons written in Electron?

ElasticSearch instance to make 100k items searchable. — What? Why!?

“AI/ML pipeline” for detecting anomalous (deviations from baseline prices) transactions. — What? Why!?

Why not rewrite it in Rust to make it safe? — …

Choose boring technology

Master common technologies to optimize costs of research and support.

The problem with “best tool for the job” thinking is that it takes a myopic view of the words “best” and “job.” Your job is keeping the company in business, god damn it. And the “best” tool is the one that occupies the “least worst” position for as many of your problems as possible.

Clever Code Considered Harmful

Write simple production code so junior can understand it. Concentrate complex code and build clean boundaries between complex and simple parts.

When it comes to day-to-day production code, here's the barometer I like to use: will a junior developer, someone at the very start of their career, struggle to understand this code?

If your app is architected so that the most complex concerns are all dealt with in the same place, you can keep the overwhelming majority of your app’s surface area simple.