Wednesday, March 18, 2026

We’ve all heard of those network effect laws: the value of a network goes up with the square of the number of members. Or the cost of communication goes up with the square of the number of members, or maybe it was n log n, or something like that, depending how you arrange the members. Anyway doubling a team doesn't double its speed; there’s coordination overhead. Exactly how much overhead depends on how badly you botch the org design.

But there’s one rule of thumb that someone showed me decades ago, that has stuck with me ever since, because of how annoyingly true it is. The rule is annoying because it doesn’t seem like it should be true. There’s no theoretical basis for this claim that I’ve ever heard. And yet, every time I look for it, there it is.

Here we go: Every layer of approval makes a process 10x slower

https://apenwarr.ca/log/20260316


Rob_Pike's 5 Rules of Programming

  • Rule 1. You can't tell where a program is going to spend its time. Bottlenecks occur in surprising places, so don't try to second guess and put in a speed hack until you've proven that's where the bottleneck is.
  • Rule 2. Measure. Don't tune for speed until you've measured, and even then don't unless one part of the code overwhelms the rest.
  • Rule 3. Fancy algorithms are slow when n is small, and n is usually small. Fancy algorithms have big constants. Until you know that n is frequently going to be big, don't get fancy. (Even if n does get big, use Rule 2 first.)
  • Rule 4. Fancy algorithms are buggier than simple ones, and they're much harder to implement. Use simple algorithms as well as simple data structures.
  • Rule 5. Data dominates. If you've chosen the right data structures and organized things well, the algorithms will almost always be self-evident. Data structures, not algorithms, are central to programming.

Pike's rules 1 and 2 restate ~Tony_Hoare~ Donald_Knuth's famous maxim "Premature optimization is the root of all evil."

Ken_Thompson rephrased Pike's rules 3 and 4 as "When in doubt, use brute force.".

Rules 3 and 4 are instances of the design philosophy KISS.

Rule 5 was previously stated by Fred_Brooks in The_Mythical_Man-Month. Rule 5 is often shortened to "write stupid code that uses smart objects".


i have no problems falling asleep anymore, but i used to. the reason it's not a problem anymore is probably a mixture of many things: financial security, a stable relationship and, somewhat surprisingly, a TODO-list app i actually use. the last one sounds a bit banal, but i used to jolt up and worry about having forgotten some important task.

other techniques and factors:

  • going to bed when you're actually tired: sounds somewhat obvious, but people ignore it
  • better screen hygiene: this never really worked for me and i never seriously tried it because it wasn't really necessary
  • the military technique: breathing and muscle relaxation together with a repeated mantra. i tried this for some time with varying success. my daugther loves it though - if she can't fall asleep i caress her limbs while mumbling in a soothing voice: "your leg feels very tired, it's falling asleep, your foot is also very tired, your back is very tired, ..."
  • for myself, i had better success with thinking - mostly fantasizing - about or planning things i like, for example having (unrealistically great) success with a project, thinking about a multi-day bike tour i'd like to do, inventing a "deus ex machina" device that changes humanity for the better and turns the world into a paradise

today i read about cognitive_shuffling: https://www.bbc.com/future/article/20260311-cognitive-shuffling-the-micro-dreaming-technique-that-helps-your-brain-to-rest


Thursday, March 12, 2026

CI should fail on your machine first When you think of CI, you probably picture a remote server somewhere: GitHub Actions, GitLab CI, Jenkins. You push your code, you wait, and eventually you get a green checkmark or a red X. ... This is the feedback loop we've all accepted as normal. What if CI could fail on your machine, before you even push?

https://blog.nix-ci.com/post/2026-03-09_ci-should-fail-on-your-machine-first


Tuesday, March 3, 2026

microgpt

This is a brief guide to my new art project microgpt, a single file of 200 lines of pure Python with no dependencies that trains and inferences a GPT. This file contains the full algorithmic content of what is needed: dataset of documents, tokenizer, autograd engine, a GPT-2-like neural network architecture, the Adam optimizer, training loop, and inference loop. Everything else is just efficiency. I cannot simplify this any further.

by Andrej_Karpathy

https://karpathy.github.io/2026/02/12/microgpt/ HN


The real cost of random I/O The random_page_cost was introduced ~25 years ago, and since the very beginning it’s set to 4.0 by default. The storage changed a lot since then, and so did the Postgres code. It’s likely the default does not quite match the reality. But what value should you use instead? Flash storage is much better at handling random I/O, so maybe you should reduce the default? Some places go as far as recommending setting it to 1.0, same as seq_page_cost. Is this intuition right?

https://vondra.me/posts/the-real-cost-of-random-io/ HN

interesting article about the legacy default setting values vs. updated real world measurements and the resulting consequences.


Monday, February 9, 2026


Thursday, February 5, 2026

sqldef is a CLI tool for diffing two SQL schemas. You can use it to manage the migration of RDBMSs using regular SQL DDLs. Supported databases: MySQL, MariaDB, TiDB, PostgreSQL, SQL_Server, and SQLite3.

https://sqldef.github.io/

this might come in very handy sometimes!


Thursday, January 1, 2026

and by the way - belated happy new year everyone!


The challenges of soft delete

https://atlas9.dev/blog/soft-delete.html (HN)


Sunday, December 21, 2025

Anyone who has read Tolkien’s letters will know that he is at his funniest when filled with rage, and The Bovadium Fragments is a work brimming with Tolkien’s fury—specifically, ire over mankind’s obsession with motor vehicles. Tolkien’s anger is expressed through a playful satire told from the perspective of a group of future archaeologists who are studying the titular fragments, which tell of a civilization that asphyxiated itself on its own exhaust fumes. Tolkien’s fictional fragments use the language of ancient myth, reframing modern issues like traffic congestion and parking with a grandeur that highlights their total absurdity.

https://lareviewofbooks.org/article/isengard-in-oxford/


archive