Today's edition covers three kinds of change: swapping a database primary safely, adjusting to smaller DDoS attacks, and migrating a codebase while people keep working in it.
Picked from 72 new articles across 34 sources · arrow keys for other days
Today in 30 seconds
30s left
PlanetScale's Neki keeps the old Postgres primary running read-only during a switchover, so a stalled promotion can be undone with a config reload. story 1 ↓
Neki keeps the write outage short without losing acknowledged commits, which matters because switchovers happen on every upgrade, resize and pod move. story 1 ↓
Cloudflare's Q3 report shows attacks above 1 Tbps fell from 805 to 251 after four big IoT botnets were taken down. Short floods became far more common. story 2 ↓
CLDAP reflection nearly disappeared and DNS amplification tripled. Typical services should now plan for five-minute floods under a gigabit, not terabit-scale ones. story 2 ↓
Titus Winters describes how Google refactored 250M lines of C++: old and new APIs coexist, edits ship in shards, then new uses of the old API are blocked. story 3 ↓
Winters also explains why Google made tests mandatory around 2007 and argues most of the undergraduate CS curriculum is out of date. story 3 ↓
1/3PlanetScale· Shlomi Noach· Oct 29
How PlanetScale's Neki promotes a new Postgres primary without failing queries
PlanetScale's Neki moves a Postgres primary role to a replica by holding writes at its routers, making the old primary read-only, and fixing a final log position. A failed switchover can then return to the old primary.
Why it matters · A planned primary switchover happens on every upgrade, resize and pod move. This design shows how to bound the write outage without losing acknowledged commits or giving up a quick way back.
Know this first
Context from the editor, not the article · 36 sec
1 · Postgres WAL and replicas
Postgres writes every change to a write-ahead log (WAL) before applying it. Replicas stream this log from the primary. Each position in the log is an LSN (log sequence number). A replica first receives the WAL, then flushes it to disk, then replays it into its data. Each step has its own LSN.
2 · Synchronous replication
With synchronous replication, the primary doesn't tell a client its commit succeeded until a standby confirms it has flushed that commit. ANY 1 (a, b, c) means any one listed standby can confirm. You can't easily tell which standby confirmed a particular commit.
3 · Switchover versus failover
2/3Cloudflare· Cloudforce One· Oct 29
Cloudflare Q3 2026 DDoS report: many more short attacks, far fewer huge ones
Cloudflare stopped 18.2 million network-layer DDoS attacks in Q3 2026, triple the count a year earlier. Almost all were short and small. Attacks above 1 Tbps fell by about 69% after police dismantled four big botnets.
Why it matters · An ordinary service is now far more likely to face a 5-minute, sub-gigabit flood than a terabit one. That changes what your detection, rate limits and upstream protection need to handle.
Know this first
Context from the editor, not the article · 33 sec
1 · What a DDoS attack is
In a distributed denial-of-service (DDoS) attack, many machines, usually hijacked devices in a botnet, flood a target until it can't serve real users. Network-layer attacks (layers 3/4) exhaust bandwidth or packet processing. HTTP-layer attacks (layer 7) send floods of application requests.
2 · Reflection and amplification
UDP needs no handshake, so an attacker can forge the source IP on a small query. A public server, such as a DNS resolver or LDAP domain controller, then sends a much larger reply to that forged address. The victim receives traffic many times bigger than the attacker sent.
3 · Mirai and IoT botnets
3/3The Pragmatic Engineer· Gergely Orosz· Oct 29
How Google refactored 250 million lines of C++ without stopping work
Titus Winters, lead author of Software Engineering at Google, describes a 2010 cleanup of 250 million lines of C++ driven by parsing tools, Google's mandatory-testing rule, its code-readability program, and what CS degrees miss.
Why it matters · The migration pattern of coexisting APIs, sharded edits and blocking the old usage works for any large codebase, and the testing story shows what a missing safety net costs.
Know this first
Context from the editor, not the article · 31 sec
1 · Google's single giant repository
Google keeps most of its code in one shared repository, a monorepo, and builds everything from head. A change to a widely used library therefore affects thousands of projects at once. That makes cleanups possible in principle and very hard in practice.
2 · Who Titus Winters is
Winters spent over a decade at Google. He led its C++ readability program and built Abseil, Google's open-sourced core C++ libraries. He co-wrote the book Software Engineering at Google and now works on developer productivity at Adobe.
A failover promotes a replica after the primary dies unexpectedly. It must first confirm the failure to avoid having two writable primaries ("split brain"). A switchover is planned: the primary is healthy and steps aside on purpose, for example during an upgrade.
Image: PlanetScale
What changed
Shlomi Noach of PlanetScale explains how 1, PlanetScale's system for running sharded, highly available Postgres, hands the primary role to a replica during routine work such as pod replacement, kernel upgrades or moving between 2 (isolated failure zones). This is a planned switchover. During it, writes briefly can't go to either the old or the new primary. Neki's goals are to keep that window short, hide it from applications, and back out cleanly if it fails.
Why it's hard
Before promoting a replica, you must know it has applied all of the primary's 3 (write-ahead log). But a running primary keeps writing WAL, so any position you sample can go stale. 4, a popular open-source Postgres cluster manager, solves this by shutting the primary down, which gives an unambiguous final position. The drawback is that if promotion then fails, getting the old primary back means restarting it and possibly rewinding it, and nothing accepts writes in the meantime.
Neki's approach
Neki keeps the old primary P running. Admin, Neki's control plane, tells the Routers (query proxies) to hold primary-bound queries, then makes P's new transactions read-only by default. Some WAL can still trickle out, so Admin:
samples P's WAL position and picks target R2, which has already flushed past it;
disconnects the other replicas and records the last position each received;
takes the highest of these positions and waits for R2 to replay through it.
Once cut off, the other replicas can't receive anything newer, so the target position stops moving. Neki uses synchronous replication in ANY 1 mode, where any one replica's confirmation lets a commit succeed. The procedure covers every replica that might have confirmed a commit. Noach states the result: with the default synchronous_commit = on, every commit Postgres acknowledged is on R2 before promotion. Admin also refuses to promote unless at least one replica is attached to R2 for synchronous replication. Otherwise the new primary would hang on its first commit.
What applications see
Routers buffer only primary-bound queries, and they start before anything changes. Afterwards they re-plan the held queries against the new topology. Applications see slower queries rather than errors, unless the finite buffer fills or a query passes its deadline.
Rollback and gaps
Preflight checks cover shard state, replication lag, logical failover slots and capacity settings such as max_connections. If a later check fails or R2 misses its deadline, a configuration reload makes P writable again and the other replicas reconnect. The post includes no measurements of how long the disruption lasts or how often rollbacks happen.
The news
Shlomi Noach of PlanetScale describes how 1, PlanetScale's system for running sharded, highly available Postgres, performs a planned switchover. That is the routine handoff of the primary role from one Postgres server to a replica, needed when a Kubernetes pod is replaced, a kernel is upgraded, or the primary moves to another 2 (an isolated failure zone). Each Neki shard has one primary that accepts writes and several replicas that don't. Neki has two main components. Admin is its control plane, which orchestrates the cluster. Routers are proxies that send each application query to the right Postgres server.
A switchover always has a cost: for some window, writes can't reliably go to either the old primary or the new one. The post covers how Neki keeps that window short, hides it from applications, and backs out when the switchover can't finish.
Three phases, and only two hurt
Noach splits a switchover into three phases:
Preflight validation. Admin checks the shard and picks a viable replica.
Convergence and promotion. The chosen replica is brought fully up to date and promoted.
Client recovery. Queries meant for the old primary find the new one.
Preflight runs while the primary is still serving normally. Only phases 2 and 3 count as disruption. A planned switchover also skips the slowest part of an unplanned failover, which is deciding whether the primary is really dead or just cut off by a network partition. Admin knows the primary is about to step aside, so it can use that time for checks and simply reject the operation if any check fails.
The hard part: a moving target
To promote a replica safely, you need to know it has applied all the 3 (Postgres's write-ahead log) it should have. But the primary keeps producing WAL. If you sample its position and wait for a replica to reach it, the primary may have moved ahead in the meantime.
The obvious fix is to stop Postgres on the primary. 4, a widely used open-source Postgres cluster manager, does this. Noach calls it a well-considered design: a clean shutdown gives an unambiguous final WAL position, there is less state to track, and it is proven at scale. The cost is availability if something goes wrong. To return to the old primary you have to start Postgres again and possibly 5 it (resynchronize its diverged history). Until that finishes, nothing accepts writes.
Neki instead keeps the old primary running. Admin first tells the Routers to buffer primary-bound queries, then changes the primary's default for new transactions to read-only. Noach notes that neither step stops all writes. Transactions already in progress can still commit, sessions can override the default, and background processes still write WAL. The algorithm is built to tolerate that leftover WAL. With primary P, replicas R1, R2 and R3, and target R2, Admin:
Samples P's WAL position and its replicas' replication state.
Selects R2, which has already flushed through that sampled position.
Disconnects R1 and R3 from P and records each one's final receive_lsn, the last WAL position it received.
Takes the higher of the sampled position and the highest recorded receive_lsn.
Waits for R2 to replay through that position.
Worked example (illustrative numbers): Admin samples P at LSN 5000. While it disconnects the others, an in-flight transaction commits and streams out. R1 stops at 5100 and R3 at 5080. The final target is 5100. R2 is still streaming from P, so it can reach 5100. R1 and R3 are cut off and can't receive anything newer, so the target can't move again.
Why no acknowledged commit is lost
Neki uses synchronous replication in ANY 1 (...) mode across all eligible replicas, so one slow replica can't block commits. The catch is that any of them may have confirmed the latest commit. The steps above handle this. Any commit confirmed before the sample is at or below the sampled position, and R2 has flushed past it. Any commit confirmed by R1 or R3 before they were disconnected is at or below their recorded positions, which R2 must replay. After the disconnect, R2 is the only synchronous standby still streaming, so no new commit can be confirmed unless R2 has it. The stated guarantee: with Neki's synchronous durability policy and Postgres's default synchronous_commit = on, every commit Postgres acknowledges is on the target before it is promoted.
The new primary must also be able to replicate synchronously. Admin sets up R2's 6 (server-side records that track what each consumer still needs) and its synchronous configuration, then attaches the other replicas. At least one attached replica must appear in that configuration. Otherwise R2 would become primary and immediately hang, waiting for an acknowledgement nobody can send. In that case Admin rolls back. After promotion, P is rebuilt as a replica of R2 through Neki's normal replica-creation flow and joins the synchronous set.
What applications see
Routers watch for Admin's buffering signal. While it is set, primary-bound queries wait in the Router instead of going to Postgres. Reads served by replicas continue. When the switchover finishes, Admin clears the signal, and Routers re-plan each held query against the new topology and send it to R2. The application sees a slower query, not an error. Noach calls this proactive buffering. In an unplanned failure, buffering can only start after some query has already failed against the dead primary.
There are limits. Admin doesn't wait for every Router to acknowledge the signal, because buffering lowers disruption but correctness doesn't depend on it. The buffer has finite capacity and each query has a deadline, so queries fail if the buffer fills or the switchover runs long.
Checks, deadlines and rollback
Before touching the primary, Admin checks:
Shard state. Only states on an explicit allow-list may proceed. Replication lag or divergent timelines block the switchover.
The target. A replica named by the operator is still checked for viability.
7. These are slots that let logical-replication consumers continue after a failover. Admin waits for them to be copied to the candidate.
Some checks can only run mid-switchover: the target's flush and replay positions, slots created since preflight, and the attached synchronous replica. If any fails, or R2 doesn't catch up before a deadline, Admin rolls back. P is still running, so a configuration reload makes it writable again and R1 and R3 reconnect. Noach says this restores service immediately.
What's left open
The post gives no measurements: no typical length of the disruption window, no buffer sizes, no deadline values, and no record of how often rollbacks happen. It doesn't say how long reads on the disconnected R1 and R3 may be stale. It also doesn't explain what happens to WAL the old primary wrote after the final position, such as unacknowledged transactions, beyond saying P is rebuilt as a replica. The trade-off against Patroni is clear but qualitative. Neki gets a fast rollback path, and pays for it with more state to reason about while the switchover is in progress.
Remember
Keeping the old primary alive as read-only makes rollback a configuration reload instead of a restart and rewind.
Cutting off the other replicas fixes a final WAL position even though the primary keeps writing.
Buffering at the router can start before anything changes, so a planned switchover shows up as latency rather than errors.
Mirai is malware from 2016 that takes over poorly secured internet-of-things devices like cameras and routers. Its source code leaked, so many variants descend from it. These botnets produce the largest volumetric floods, sometimes several terabits per second.
How attacks were spread across duration and bandwidth: almost all were short and under 1 Gbps (inferred from surrounding text).1 / 4
Cloudflare's 1 report for Q3 2026 (July to September) shows attacks getting smaller and far more numerous. A DDoS (distributed denial-of-service) attack uses many machines to flood a target until real users can't reach it. Cloudforce One, Cloudflare's threat intelligence team, wrote the report from traffic seen on Cloudflare's network.
The volume
Cloudflare says it automatically mitigated 18.2 million 2 attacks this quarter. These are floods at the packet and connection level. The count is up 208% from a year earlier and works out to roughly one attack every 0.44 seconds. It also blocked 14.4 trillion malicious HTTP requests. Attack traffic totaled 272.6 PB at the network layer and 95.1 PB at the HTTP layer.
Swarms, not giants
96% of network-layer attacks lasted under 10 minutes, and 98% stayed under 1 Gbps. That is still enough to saturate a typical server's uplink. The report links this pattern to "3" services, which rent out short DDoS attacks for a small fee. The main targets were software companies, gambling sites and IT firms. Cloudflare argues that attacks this short end before a human can respond, so mitigation has to be fully automatic.
Attacks above 1 Tbps fell from 805 in Q2 to 251, a drop of about 69%. This followed early-2026 police takedowns of four large botnets made of hijacked IoT devices: Aisuru, KimWolf, JackSkid and Mossad. The capacity hasn't disappeared. New variants keep appearing, and traffic from Mirai-family botnets (descendants of leaked 2016 malware) peaked at 57.23 PB in August. That was 46.5% of all network-layer attack bytes in the quarter. One 4 attack ran for 49.7 hours.
Attack techniques
Reflection attacks send small queries with a forged source address. Public servers then send much larger replies to the victim. 5 (Connectionless LDAP on UDP port 389) was a popular protocol for this in the first half of the year, but it fell 99.5% to just 0.05% of attacks. The report doesn't say why. Attackers moved to 6, which rose 215% to 3.43% of attacks and uses open DNS resolvers as reflectors. Plain 7 also grew, from 14.06% to 31.31% of attacks.
Targets
Media and publishing stayed the most-attacked industry, but its share fell to a quarter of its Q2 level as attacks spread to Internet, consumer services and adult entertainment. The US took the most-attacked spot back from China. Canada jumped from #16 to #6 and Israel rose to #10, amid trade disputes and pre-election tensions respectively.
Caveats
This is one vendor's data, and the report doesn't describe how it counts attacks. Its explanations, including the role of the takedowns, are stated as correlations rather than proven causes.
Cloudflare published its 1 threat report for the third quarter of 2026 (July to September). The report is written by Cloudforce One, Cloudflare's threat intelligence team, and draws on traffic across Cloudflare's network, which the company says sits in front of more than 20% of the web. This is the 26th edition and the first quarterly one since a combined first-half 2026 report. Two things changed this quarter. Small, short attacks grew sharply in number, while very large attacks became much rarer. Attackers also moved off one reflection protocol and onto others.
The raw volume
A DDoS (distributed denial-of-service) attack uses many machines to flood a target until legitimate users can't reach it. Cloudflare says that in Q3 it automatically mitigated:
18.2 million 2 attacks, meaning floods at the packet and connection level (OSI layers 3 and 4). That is up 208% from Q3 2025.
14.4 trillion malicious HTTP requests at the application layer.
272.6 PB of network-layer attack traffic and 95.1 PB of HTTP-layer attack traffic.
Averaged over the quarter, that comes to about 8,226 network-layer attacks per hour, or roughly 197,400 per day: one every 0.44 seconds.
Swarms: the 3 signature
Most of that growth came from small attacks. Of the network-layer attacks:
96% ended in under 10 minutes
98% stayed under 1 Gbps
Cloudflare points out that 1 Gbps is still "more than enough to overwhelm a server or website." An origin server on a 1 Gbps uplink is saturated by a flood that a large network barely notices.
The report links this pattern of short, mid-sized, high-count attacks to "booter" (or "stresser") services. These are DDoS-for-hire sites where anyone can pay a small fee to aim a few minutes of traffic at a target. The most targeted industries for this kind of attack were computer software, gambling and casinos, and IT.
The duration matters for defense. An attack that lasts four minutes is over before an on-call engineer has read the page. Cloudflare uses this to argue for fully autonomous mitigation: detection and filtering have to happen in software at the edge, with no human in the loop. That is a vendor making the case for its own design, but the numbers support it. A defense that depends on someone noticing an alert and changing a firewall rule will miss nearly all of these attacks.
Fewer giants, but the botnets aren't gone
At the other end, "hyper-volumetric" attacks (Cloudflare's term for floods above 1 Tbps) fell from 805 in Q2 to 251 in Q3, a drop of about 69%. The report connects this to law-enforcement action in early 2026 that took down four of the largest IoT DDoS botnets: Aisuru, KimWolf, JackSkid and Mossad. 4 are networks of hijacked cameras, routers and other embedded devices. Cloudflare says the timing matches, not that the takedowns definitely caused the drop.
The capacity has not gone away. New variants such as Dysphoria and Evooo1Bot are appearing. Traffic Cloudflare classified as 5 (the leaked 2016 IoT malware many of these botnets descend from) peaked in August at 57.23 PB. That was 46.5% of all mitigated network-layer bytes in the quarter. On four August days (the 16th, 19th, 23rd and 25th), Mirai traffic topped 3 PB per day. The longest continuous Mirai attack ran 49.7 hours, from August 19 to 21. So the largest attacks are fewer in number but still account for close to half of all attack bytes.
Vector shifts: 6 collapses, DNS and UDP rise
The biggest change was in attack technique. CLDAP (Connectionless Lightweight Directory Access Protocol) is the UDP version of LDAP, served on port 389, often by Windows domain controllers exposed to the internet. In a CLDAP reflection attack, the attacker sends a small query with the victim's IP address forged as the source. The server sends its much larger reply to the victim.
A simplified illustration, with made-up numbers: if a 60-byte query produces a 3,000-byte reply, that is a 50x amplification. An attacker with 1 Gbps of spoofing capacity can then send up to 50 Gbps at the victim, and the traffic arrives from thousands of legitimate servers instead of the attacker's own machines.
CLDAP attacks rose 580% quarter-over-quarter during the first half of 2026. In Q3 they fell to just 0.05% of attacks, a 99.5% drop. The report doesn't say why. Possible explanations include reflectors being patched or filtered, the botnets that used CLDAP being taken down, or attackers simply moving on. None of these is confirmed.
Attackers shifted to other connectionless protocols:
7 rose 215% to 3.43% of network-layer attacks. It works the same way, using open DNS resolvers as the reflectors.
Generic 8 grew from 14.06% to 31.31% of network-layer attacks. These don't use reflection. Bots send large numbers of UDP packets to random or specific ports. For each packet, the target's kernel has to check for a listening socket and often send back an ICMP "port unreachable" reply, which uses up both bandwidth and CPU.
Who got hit
Media, Production & Publishing remained the most-attacked industry, but its share fell to about a quarter of its Q2 level. Attacks spread across more sectors. "Internet" moved from outside the top 10 to #6, Consumer Services to #8, and Adult Entertainment to #9.
By location, the US overtook China as the most-attacked country. China was #1 and the US #2 in the first half of the year. Indonesia came third with 2.93% of attacks. Canada rose from #16 to #6, with attacks on retail, telecoms, service providers and marketing. Israel rose seven places to #10 after sustained attacks in mid-September. Cloudflare places both against a background of geopolitical events: trade disputes for Canada, and pre-election tensions plus a broader wave of hostile cyber activity for Israel. These are associations, not attributions.
Caveats
This is one vendor's view from its own network, and the report doesn't explain its methodology: how a single "attack" is counted, how attacks are split or merged, or how bytes are assigned to a botnet family. Some of the jump in attack count could reflect changes in detection or in Cloudflare's customer base, not only attacker behavior. Most explanations are stated as correlations ("possibly a reflection of", "coinciding with").
The report closes with promotion: free unmetered DDoS protection in 330+ cities backed by 500 Tbps of capacity, and a free botnet threat feed that more than 800 service providers use to find and take down infected hosts. The useful engineering point is that the typical attack is now a short, sub-gigabit UDP or reflection flood, and only automated defenses can respond to it in time.
Remember
96% of network-layer attacks ended within 10 minutes, faster than any human-in-the-loop response can act.
Terabit attacks dropped about 69% after four botnet takedowns, yet Mirai traffic still carried nearly half of attack bytes.
Attackers abandoned CLDAP reflection almost completely and moved to DNS amplification and plain UDP floods.
The ACM and IEEE, the two big computing professional bodies, publish model undergraduate computer science curricula about once a decade. Universities use them to design degrees. The 2023 edition, CS2023, was produced together with AAAI, an AI research society.
Image: The Pragmatic Engineer
Titus Winters, lead author of Software Engineering at Google, talked to The Pragmatic Engineer podcast about how Google changed a huge codebase safely. Winters spent over a decade at Google, where he led the C++ 1 program and built 2, Google's open-sourced core C++ libraries. He is now at Adobe.
Refactoring 250 million lines of C++
In 2010 a dozen volunteers set out to clean up old C++ code in a codebase of about 250 million lines edited by about 10,000 engineers. Winters compared it to replacing the Empire State Building's foundation without closing the building, and then finding nuclear waste in the basement.
At that scale you can't make one atomic change: it would conflict constantly and need sign-off from every team. The team used compiler tooling in stages:
Parse every build target into an 3 (the compiler's structured view of code), using 4, Google's framework for spreading work across many machines.
Match exact call patterns and generate edits automatically.
Coexist: keep the old and new APIs working side by side so each file can move independently.
Shard the edits by directory into batches each team can review.
Block new uses of the old pattern, then delete the old API.
The coexist and block steps carry the strategy. The first removes the need for one big change, and the second makes sure the migration finishes. According to Orosz, 5, the C++ formatter built on the Clang compiler, exists because this project needed it.
Why tests became mandatory
Around 2007, Google Search, which nearly every change in the company touched, could only ship quarterly instead of monthly. Google ruled that every change must come with a test, and Search's release cadence eventually recovered. The write-up gives no figures on the recovery. Winters's principle: fear is not an acceptable basis for engineering. If you can't make a valuable change safely, the codebase is unsustainable.
Readability reviews
Every Google change needs two approvals: a code owner with domain knowledge, and a readability reviewer certified in that language. It began with Craig Silverstein, Google's first engineer, walking new hires through their first change. When Winters left, more than 10,000 engineers were enrolled in the program at any time.
The CS curriculum
Winters was the only working engineer on the steering committee for 6, the ACM/IEEE/AAAI undergraduate curriculum guidelines. He says the curriculum has barely changed since about 2000 and leaves out testing and verification. He predicts that without reform, practical software engineering degrees will draw students away from computer science.
He also passes on anecdotes from other companies: much more code being written, outages up about 30%, and no more features shipped. That comes from conversations, not data.
The summary leaves out how long the refactor took and how the old patterns were blocked.
The Pragmatic Engineer podcast spoke with Titus Winters, lead author of Software Engineering at Google. He spent more than a decade at Google, where he led the C++ 1 program and built 2, Google's open-sourced foundational C++ libraries. He is now a Senior Principal Scientist at Adobe. Host Gergely Orosz's write-up lists twelve takeaways. The most useful for practitioners cover how Google changed a very large codebase safely, both mechanically and culturally. Below are those, plus Winters's critique of computer science education.
The 2010 C++ cleanup
A few months after Winters joined Google in 2010, an internal email asked for volunteers to clean up old C++ code. Some of it dated back to the first Googlers. About a dozen people signed up. At the time the codebase held close to 250 million lines and was edited by about 10,000 engineers. Winters describes the job like this: "We were replacing the foundation of the Empire State Building. We were not allowed to close the building or block traffic. Oh, and we discovered nuclear waste in the basement."
The difficulty is that you can't change a widely used API in one commit at this scale. Thousands of files depend on it, engineers are changing those files all day, and each team's code owners have to approve changes in their area. A single giant change would conflict constantly and would never get through review. The team instead used a staged pipeline built on compiler tooling, long before LLMs existed:
Here is an illustrative example, not taken from the episode. Say OldSplit(str, ",") must become absl::StrSplit(str, ','). The matcher finds every call node for OldSplit with a literal separator, and the generator rewrites it. Because OldSplit keeps working, the changes for /search/ and /ads/ can land weeks apart. A check stops new OldSplit calls from appearing. When the count reaches zero, OldSplit is deleted. Steps 4 and 6 do most of the work. Coexistence removes the need for one big atomic change, and blocking makes sure the migration actually finishes.
According to Orosz, 5, the widely used C++ code formatter built on the Clang compiler, exists because the team needed it for this refactor. Machine-generated edits have to come out formatted to the house style, or reviewers can't read them. Orosz asks whether this was the largest refactoring ever. Nobody can really answer that, but the scale is unusual.
Why tests became mandatory
Around 2007, Google Search could no longer ship monthly. The best it could manage was a quarterly release. Almost every change anywhere at Google touched Search's code, including something as unrelated as a Gmail change. So breakage from all over the company landed in Search. Google's response was a company-wide rule: every change must come with a test. Over time Search went back to a faster release cadence. The write-up gives no timeline or measurements for the recovery.
Winters puts the principle bluntly: fear is not an acceptable basis for engineering. If you can't make a valuable change to a codebase safely, that codebase is unsustainable. Safety nets that catch errors are strategic, in his view, because they let teams change things without fear. The refactoring pipeline depended on this too. You can only send out thousands of automated edits if tests will catch the ones that break something.
Readability as a training program
Every change at Google needs two sign-offs in code review:
an owner, someone with domain knowledge of the file or project;
a readability reviewer, an engineer certified as an expert in the language the change is written in.
The practice started informally. Craig Silverstein, Google's first engineer, walked each new hire through their first change. Java teams turned this into mentoring, with experienced reviewers assigned to all changes in rotation. Later it became a formal program for every language. When Winters left Google three months ago, more than 10,000 engineers were enrolled in readability at any given time. Orosz suggests it may be the largest educational program in tech. The program also matters for large-scale changes: a shared, enforced style is what lets machine edits and unfamiliar reviewers work across the whole codebase.
Burning down the CS curriculum
Winters was the only working engineer on the steering committee for 6, the 2023 undergraduate curriculum guidelines from the ACM, IEEE and AAAI. He calls the curriculum hopelessly out of date and says it has barely changed since around 2000, while the industry has changed a lot. He points to testing and verification as an example. They matter more and more for new engineers, yet they are absent from the curriculum. His forecast is that without major changes, CS enrollment could fall and practical software engineering programs will draw students away. He also argues that students should be graded on their thinking, meaning how they build and validate software, rather than only on the code they turn in.
The AI remarks, briefly
The conversation also turns to AI. Winters says engineers at other companies report much higher code output than a year ago, outages up about 30%, and no more features shipped than before. That is anecdote, not a study, and the write-up gives no sources. He is still optimistic overall, arguing the value lies in projects that used to be too ambitious to attempt. Professors also tell him that students below roughly a B grade now often don't understand code at all.
What's left open
This is a podcast summary, so the details are thin. It doesn't say how long the C++ cleanup took, how the "block the old" step was enforced, how much the testing mandate improved Search's release speed, or what Winters's ideal curriculum actually contains. The full episode and the free online edition of Software Engineering at Google cover more of this.
Remember
Large migrations work when the old and new APIs coexist, edits ship per directory, and new uses of the old API are blocked.
Google mandated a test with every change after Search fell from monthly to quarterly releases around 2007.
Winters says CS curricula have barely changed since 2000 and still omit testing and verification.
Capacity settings. A replica can't follow a primary with larger max_connections or max_worker_processes, so the candidate's settings must be compatible with every replica.
Parse. A 3 job, Google's framework for spreading a computation across many machines, ran over the whole codebase. Each mapper parsed a build target into an 4 (AST), the compiler's structured representation of the code.
Match. Find the exact call patterns to change in those trees. Matching on structure rather than text avoids false hits in comments, strings and look-alike names.
Generate. Produce the edits automatically.
Coexist. Make the old and new APIs work side by side, so any file can move over independently.
Shard. Split the edits by directory and send them out in batches small enough for each directory's owners to review.
Block the old. Stop anyone from adding the old pattern back while the migration runs.
