// HACKER NEWS — CYBERSECURITY
Simple Is Not Small
2026-08-27
• audience—programmers
• ideas
• software-architecture
@notjack.space: UIs with too many buttons confuse and alarm me
@sixfold-origami.com: ah, this is the unix thing!
@notjack.space: no, because I want cross device sync to actually work
Recently, I gave a talk titled "Precise, consistent, and reliable code coverage".
It's about a truly gnarly bug that took my company 9 months to debug.
At the end, my friend Predrag asks:
How would you recommend that we think about building tools such that these epic debugging stories aren't as necessary?
We need to prioritize simplicity.
If you go back to my coverage pipeline, there are a lot of nodes in this diagram. [...]
The tooling's complicated.
We need to rethink how our computing works.
Consider two programs to calculate the frequency of words of a file. First, a small unix pipeline:
This says "read README.md, translate each word boundary into a newline, collapsing multiple newlines, convert uppercase to lowercase, count the number of occurrences of each word, then show them in frequency order".
I think this is what most people think of when they think of "simple":
each program is small, they're designed to be joined together ad-hoc in this way, it's concise and somewhat easy to read.
This does the same thing, with a few more names and higher-order functions thrown in.
Now, let's say we want to make a small change: show the output in the original file order.
In Clojure, this is fairly straightforward:
store an ordered sequence of the words in word_seq, store a map from each word to its frequency in freq_map, iterate over the sequence, and look up each word in the map: