A working engineer's alternative to the algorithm-grind.
TechProgramming is a peer-reviewed publication run by 42 senior engineers. Every article is written by a practitioner, reviewed by a second, and benchmarked on reproducible hardware — so you can trust the result in production.
Meet the 42 senior engineers who write, review, and ship every piece.
No interns, no anonymous contributors. The roster below is a slice of the editorial board — four working engineers with a combined 58 years of production experience, plus their day jobs and the beats they own on the site.
-
01
-
02
-
03
-
04
Plus 38 more — including engineers from Cloudflare's edge team, Stripe's data plane, and Mozilla's Rust working group. The full editorial board meets every Tuesday in Berlin and remotely.
See how peer review works →Why a Berlin flat in 2012 decided to publish against the hype.
In the autumn of 2012, David Reimer — then a Mozilla engineer on the Servo rendering pipeline — and Priya Chandrasekar — then a staff engineer at Stripe on payments-risk — kept having the same argument over weeknight dinners in their shared Kreuzberg apartment. Every engineering blog they read was either a recruiting funnel, a thinly disguised product launch, or a vague gesture toward "best practices" without any reproducible evidence.
Neither of them wanted to start a company. They wanted to write the kind of piece they wished existed when they were stuck on a 3 a.m. incident: a long, opinionated, technically rigorous account of how a system actually behaved under load, with the code linked and the benchmarks reproducible on a second machine.
They registered TechProgramming Editorial GmbH that December, posted the first piece — a 6,200-word teardown of the TLS 1.2 renegotiation flaw — in January 2013, and committed to two editorial rules that have not changed since: depth over hype, and two named engineers must sign off on every published claim.
Thirteen years later, the publication has 1,847 deep technical articles in the archive, a 42-person editorial collective, 30,000+ newsletter subscribers, and a benchmark repository on GitHub that has passed 48,000 stars. The original argument has not been resolved. It still drives the editorial calendar.
The five-stage pipeline every article passes through.
From first draft to published peer-reviewed piece takes a median of 11 days. No piece skips a stage. No stage is automated.
-
Chapter 01
Draft
A named senior engineer — averaging 14.6 years of professional experience — writes the first draft against an editorial brief. Code samples must run on a clean checkout; benchmarks must include raw CSV output, not just a chart.
~ 4 days -
Chapter 02
First peer review
A second named engineer from the editorial collective reads the full draft line by line. Reviewers challenge every load-bearing claim and request either a citation, a reproduction, or a removal. Disagreements go to the weekly editorial board.
~ 3 days -
Chapter 03
Benchmark validation
Our in-house runtime lab re-runs every published algorithm across ARM, x86, and WebAssembly on reproducible hardware. Raw benchmark data is pushed to the public GitHub repository alongside the article — not as an appendix, but as the primary evidence.
~ 2 days -
Chapter 04
Second peer review
After revisions, a third engineer — chosen for being unfamiliar with the topic — reads the piece cold. If anything requires domain expertise the reviewer cannot independently verify, the article is sent back to the lab for a fourth pass.
~ 2 days -
Chapter 05
Publication
The finished piece ships with a peer-review mark naming both reviewers, a reading-time estimate (the median across all articles is 11 minutes 40 seconds — the longest of any top-50 engineering blog tracked by Parse.ly), and a permanent link to the runnable code.
Day 11
Thirteen years of peer-reviewed technical publishing.
- Articles in the archive
- 1,847
- Average length 4,200 words — the longest continuously-run independent engineering publication online.
- Newsletter subscribers
- 30K+
- Crossed in Q3 2024. Organic month-over-month growth rate: 9.2%.
- GitHub stars on the benchmark repo
- 48K+
- Every published claim ships with a runnable, reproducible test.
- Editorial collective size
- 42
- Senior engineers from Google, Stripe, Mozilla, Jane Street, and Cloudflare. Weekly editorial board.
- Average author experience
- 14.6yrs
- No interns, no unnamed contributors. Every byline is a working engineer.
- Draft-to-published turnaround
- 11days
- Median across all 1,847 articles. Five-stage peer review, no stage skipped.
- Monthly unique readers
- 1.4M
- Similarweb verified, October 2024. Mid-to-senior engineers by audience composition.
- Founded in Berlin
- 2012
- By former Mozilla and Stripe engineers. Peer-reviewed every day since.
Required reading in three graduate distributed-systems courses.
The list below is not "trusted by leading universities." These three institutions have formally added TechProgramming articles to their required reading in distributed-systems curricula. The syllabi are linked from each entry.
-
Carnegie Mellon University
15-440 / 15-440B · Distributed Systems · School of Computer Science
Eleven TechProgramming articles appear on the required-reading list for the graduate section, including the consensus-series and the reference sheet on memory ordering. Adoption formally noted in the 2023 syllabus revision.
-
ETH Zürich
263-3800 · Distributed Systems Laboratory · Department of Computer Science
Seven articles on consensus, failure detection, and storage systems are assigned in the lab component. Co-author Priya Chandrasekar has guest-lectured twice on the editorial peer-review methodology.
-
Tsinghua University
70100143 · Distributed Computing · Department of Computer Science
Four long-reads on real-world consensus implementations are part of the graduate reading packet. The course instructor has cited TechProgramming benchmarks in two follow-up papers on BFT protocol evaluation.