If you live in Germany, you have been treated like live­stock by Deutsche Bahn (DB). Almost all of my friends have a story: they trav­eled with DB, got thrown out in the mid­dle of the night in some cow vil­lage, and had to wait hours for the next train.

I have some­thing bet­ter. I was kid­napped.

I am tak­ing the RE5 (ID 28521) to my grand­moth­er’s house in Meckenheim. Scheduled de­par­ture: 15:32. Scheduled ar­rival in Bonn: 15:54. From there, the S23 to Meckenheim. A jour­ney of 35 kilo­me­ters, or, in DB units, some­where be­tween forty-five min­utes and the heat death of the uni­verse.

I wanted to ar­rive early to spend more time with her. My fa­ther, who lives near Troisdorf, was sup­posed to join us later.

I board the train. It is twenty min­utes late. I con­sider this early. At least the train showed up. In DB’s of­fi­cial sta­tis­tics, a train counts as “on time” if it’s less than six min­utes late. Cancelled trains are not counted at all. If a train does­n’t ex­ist, it can­not be late.

The train starts mov­ing. The dri­ver an­nounces there are “issues around Bonn.” He does not spec­ify what kind. No one asks. We have learned not to ask. He sug­gests we exit at Cologne South and take the sub­way, or con­tinue to Troisdorf and catch a bus from there.

I de­cide to con­tinue to Troisdorf. My fa­ther can just pick me up there and we drive to­gether. The plan adapts.

The dri­ver an­nounces the full de­tour: from Cologne South to Troisdorf to Neuwied to Koblenz. The en­tire left bank of the Rhine is un­avail­able. Only then I no­tice: the dri­ver has been speak­ing German only. If you were a tourist who got on in Cologne to visit Brühl, thir­teen min­utes away, you were about to have a very con­fus­ing Christmas in Troisdorf.

A woman near me is hold­ing choco­lates and flow­ers. She is on the phone with her mother. “Sorry Mama, I’ll be late.” Pause. “Deutsche Bahn.” Pause. Her mother un­der­stood.

Twenty min­utes later. We are ap­proach­ing Troisdorf. I stand up. I gather my things. My fa­ther texts me: he is at the sta­tion, wait­ing.

The dri­ver comes back on: “Hello every­one. Apparently we were not reg­is­tered at Troisdorf sta­tion, so we are on the wrong tracks. We can­not stop.”

He says this the way some­one might say “the cof­fee ma­chine is bro­ken.”

I watch Troisdorf slide past the win­dow. Somewhere in the park­ing lot out­side the sta­tion, my fa­ther is sit­ting in his car, watch­ing his son pass by as live­stock.

I was try­ing to travel 35 kilo­me­ters. I was now 63 kilo­me­ters from my grand­moth­er’s house. Further away than when I started.

There are fif­teen sta­tions be­tween Troisdorf and Neuwied. We pass all of them [^6].

At some point you stop be­ing a pas­sen­ger and start be­ing cargo. A cow trans­porter. Mooohhhhh. A cow trans­porter go­ing to a cow vil­lage. (Germany has a word for this: Kuhdorf. The cows are metaphor­i­cal. Usually.) I reached this point around Oberkassel.

DB once op­er­ated a bus to Llucalcari, a Mallorcan vil­lage of sev­en­teen peo­ple. I wanted to take it home.

An English speaker near the doors is get­ting ag­i­tated. “What is hap­pen­ing? Why did­n’t we stop?”

“We are not reg­is­tered for this track.”

“But where will we stop?”

“Fifty-five min­utes.” He said it again, qui­eter. “I am be­ing kid­napped.”

My seat­mate, who had not looked up from his book in forty min­utes, turned a page. “Deutsche Bahn.”

I had been kid­napped at a loss.

It’s anec­do­tal, I know, but my main en­ter­tain­ment busi­ness rev­enue is down 50% over the past 3 months. Our main paid source of leads was Google Ads, which have served us well over the past 10 years or so — I think I know what I am do­ing in ad­words by now.

Once per month I check the an­a­lyt­ics, up­dat­ing key­words and tweak­ing ad cam­paigns. Over the past year we in­creased our bud­get, and then I started look­ing at it once per week, run­ning si­mul­ta­ne­ous cam­paigns with dif­fer­ent set­tings, just try­ing to get SOMETHING.

Last month Google gave us a bonus — free money! This was 5x our monthly ad spend, to spend just when we needed it most — over the December hol­i­days. I added an­other new cam­paign, up­dated the bud­gets for the ex­ist­ing ones. Still no change. The last week there was money to burn, left over from un­used ad spend. I in­creased our bud­get to 10x. ZERO RETURN.

The money ran out. I am not putting more in. Where do we go from here?

Research shows that many young peo­ple are get­ting their in­for­ma­tion from short video plat­forms like TikTok and Instagram. We are try­ing ads on there.

Our cus­tomer base is com­prised of 50% re­turn­ing cus­tomers (I am proud of that sta­tis­tic!). We have an email newslet­ter, we started send­ing them reg­u­larly over the past 2 months. Remember us?

We also plan to do some ac­tual phys­i­cal ad­ver­tis­ing — I am go­ing to a mar­ket next week­end, do­ing a free show or two, hand­ing out cards.

Also, we are branch­ing out — I have some pro­jects I want to make, re­lated to the Magic Poi pro­ject, and hope­fully sell. We or­dered sup­plies last week.

Right now, though — I’m broke. Anyone need a web­site or IOT pro­ject built? I am AI as­sisted, very fast!

Today, Michał Kiciński, one of the co-founders of CD PROJEKT, and the co-founder of GOG, has ac­quired GOG from CD PROJEKT.

We be­lieve the games that shaped us de­serve to stay alive: easy to find, buy, down­load, and play for­ever. But time is an­noy­ingly good at eras­ing them. Rights get tan­gled, com­pat­i­bil­ity breaks, builds dis­ap­pear, and a nos­tal­gic evening of­ten turns into a trou­bleshoot­ing ses­sion. That’s the dif­fer­ence be­tween “I’m play­ing to­day” (the game lives on) and “I’ll play some­day” (the game dies).

As Michał put it: “GOG stands for free­dom, in­de­pen­dence, and gen­uine con­trol.”

GOG has al­ways been built on strong val­ues and clear prin­ci­ples. When Marcin Iwiński and Michał Kiciński first came up with the idea for GOG in 2007, the vi­sion was sim­ple: bring clas­sic games back to play­ers, and make sure that once you buy a game, it truly be­longs to you, for­ever. In a mar­ket in­creas­ingly de­fined by manda­tory clients and closed ecosys­tems, that phi­los­o­phy feels more rel­e­vant than ever.

This new chap­ter is about dou­bling down on that vi­sion. We want to do more to pre­serve the clas­sics of the past, cel­e­brate stand­out games of to­day, and help shape the clas­sics of to­mor­row, in­clud­ing new games with real retro spirit.

First of all, DRM-free is more cen­tral to GOG than ever. Your li­brary stays yours to en­joy: same ac­cess, same of­fline in­stallers, same sense of own­er­ship. Your data stays with GOG, and GOG GALAXY re­mains op­tional.

We’ll keep our re­la­tion­ship with CD PROJEKT. CD PROJEKT RED games will con­tinue to be avail­able on GOG, and up­com­ing ti­tles from the stu­dio will also be re­leased on the plat­form.

If you’re a GOG Patron, or you do­nate to sup­port the Preservation Program, those funds stay within GOG. Your sup­port has been huge this year, and we think that with your help, we can un­der­take even more am­bi­tious res­cue mis­sions in 2026 and 2027. We’ll have more to say about that some­time in 2026.

GOG will re­main  in­de­pen­dent in its op­er­a­tions. We will con­tinue build­ing a plat­form that’s eth­i­cal, non-preda­tory, and made to last, while help­ing in­die de­vel­op­ers reach the world. We’re also com­mit­ted to giv­ing the com­mu­nity a stronger voice, with new ini­tia­tives planned for 2026.

Thanks for be­ing the rea­son this all mat­ters.

A lot of com­pa­nies sell games. Fewer do the unglam­orous work of mak­ing sure the games that shaped peo­ple’s lives don’t qui­etly rot into in­com­pat­i­bil­ity.

Thanks for car­ing about this mis­sion with us. We’ll keep you posted as we ship, and in the mean­time, you can dig into the full FAQ for the de­tailed an­swers.

A ma­jor link in Tesla’s 4680 bat­tery sup­ply chain has just snapped. South Korean bat­tery ma­te­r­ial sup­plier L&F Co. an­nounced to­day that the value of its mas­sive sup­ply deal with Tesla has been slashed by over 99%, sig­nal­ing a cat­a­strophic drop in de­mand for the au­tomak­er’s in-house bat­tery cells.

This is ar­guably the strongest ev­i­dence yet that Tesla’s 4680 pro­gram, and the ve­hi­cle that re­lies on it, the Cybertruck, is in se­ri­ous trou­ble.

In early 2023, L&F an­nounced a $2.9 bil­lion con­tract to sup­ply high-nickel cath­ode ma­te­ri­als di­rectly to Tesla.

At the time, the in­dus­try saw this as a ma­jor move by Tesla to se­cure ma­te­ri­als for its ramp-up of the 4680 bat­tery cell, which Elon Musk had touted as the key to halv­ing bat­tery costs and en­abling cheaper elec­tric ve­hi­cles, a plan he later scrapped.

Right now, Tesla’s Cybertruck is the only ve­hi­cle us­ing the au­tomak­er’s own 4680 cells.

In a reg­u­la­tory fil­ing to­day, L&F re­vealed that the con­trac­t’s value has been writ­ten down to just $7,386.

No, that is not a typo. $2.9 bil­lion to roughly $7,400.

L&F did not ex­plic­itly state the rea­son for the cut, cit­ing only a “change in sup­ply quan­tity,” but the dots are easy to con­nect. The high-nickel cath­ode was des­tined for Tesla’s 4680 cells, and the pri­mary con­sumer of those cells is the Cybertruck.

We have been re­port­ing on the Cybertruck’s de­mand is­sues for the bet­ter part of this year. In March, we noted that the truck was turn­ing out to be a flop as Tesla be­gan of­fer­ing dis­counted fi­nanc­ing to move in­ven­tory. By June, Tesla be­came des­per­ate, launch­ing 0% APR in­cen­tives as in­ven­tory piled up in lots across the US.

Despite a pro­duc­tion ca­pac­ity of 250,000 units per year at Giga Texas, the Cybertruck is cur­rently sell­ing at a run rate of roughly 20,000 to 25,000 units an­nu­ally. We even saw Tesla dis­con­tinue the cheap­est Cybertruck in September be­cause, frankly, no one wanted a gut­ted ver­sion of a truck that was al­ready strug­gling to find buy­ers.

If Tesla is­n’t build­ing Cybertrucks, it does­n’t need 4680 cells. And if it does­n’t need 4680 cells, L&F has no one to sell its cath­ode ma­te­r­ial to.

This is not a good look Tesla’s 4680 pro­gram.

For years, we’ve been told that the 4680 cell was the “holy grail” that would al­low Tesla to pro­duce a $25,000 elec­tric car. But five years af­ter Battery Day, the cells are still re­port­edly dif­fi­cult to man­u­fac­ture at scale due to the dry elec­trode process, and their only ap­pli­ca­tion is a low-vol­ume pickup truck that has be­come a com­mer­cial fail­ure.

The math here is bru­tal. A 99% re­duc­tion in a sup­ply con­tract ba­si­cally means the con­tract was can­celled. It means Tesla is not ramp­ing 4680 pro­duc­tion; if any­thing, they might be wind­ing it down.

The ‘Cybercab’ is also sup­posed to be us­ing the 4680 cells, but we will have to wait and see how that goes.

It’s also a ve­hi­cle pro­gram that could go the way of the Cybertruck. CEO Elon Musk is in­sist­ing that it will launch in early 2026 with­out a steer­ing wheel, but Tesla has yet to solve level 4 au­tonomous dri­ving.

If it does launch with­out a steer­ing wheel, it will be a pro­gram even more lim­ited in vol­ume than the Cybertruck.

The bat­tery sup­ply sit­u­a­tion and the crit­i­cal min­er­als be­hind it are evolv­ing fast, and China con­trols most of it. In a new Substack, I shared a full list of the years of re­serve re­main­ing for each min­eral.

This post went un­ex­pect­edly vi­ral on Hacker News. There’s an in­ter­est­ing dis­cus­sion there if you want to take a look.

I own more books than I can read. Not in a charm­ing, as­pi­ra­tional way, but in the prac­ti­cal sense that at some point I stopped know­ing what I owned. Somewhere around 500 books, mem­ory stopped be­ing a re­li­able cat­a­log.

For years, I told my­self I would fix this. Nothing elab­o­rate, noth­ing wor­thy of a startup idea. A spread­sheet would have been enough. I never did it, not be­cause it was hard, but be­cause it was te­dious.

The gap be­tween in­ten­tion and ex­e­cu­tion was small, but it was enough to keep the pro­ject per­ma­nently parked in the some­day pile.

By the end of 2025, I had been work­ing with AI agents long enough that this kind of pro­ject fi­nally felt pos­si­ble. Not be­cause they made things more im­pres­sive, but be­cause they re­moved the part I al­ways stalled on. Execution.

The book­shelf pro­ject is where I clearly un­der­stood what my role be­comes once ex­e­cu­tion stops be­ing the bot­tle­neck.

I tried the ob­vi­ous tools first. ISBN scan­ner apps failed on Romanian edi­tions, and Goodreads could not iden­tify ob­scure pub­lish­ers or an­ti­quar­ian finds. Anything even slightly non­stan­dard came back in­com­plete or wrong. Partial data felt worse than no data at all, so every at­tempt ended the same way: a few en­tries filled in, fol­lowed by aban­don­ment.

What I needed was not a bet­ter app, but a way to tol­er­ate im­per­fec­tion with­out the whole sys­tem falling apart.

Every pro­ject starts with bad data, and this one started with worse data. One af­ter­noon, I pho­tographed every book I own: spines, cov­ers, du­pli­cates, and the oc­ca­sional blurry thumb. Four hun­dred and sev­enty pho­tos in to­tal. Once the im­ages were on my lap­top, I opened Claude.

The first steps were me­chan­i­cal. Renaming files. Converting HEIC to JPG. Then I asked for some­thing real: a script that sends each im­age to OpenAI’s vi­sion API, ex­tracts au­thor, ti­tle, and pub­lisher, nor­mal­izes names, re­sizes im­ages to avoid wast­ing to­kens, and writes every­thing to a JSON file.

Claude wrote the script and ran it. It worked. Not per­fectly, but well enough to mat­ter.

“id”: “ZfEPBCMZDaCKm6k0NVJ8F”,

“title”: “Simulacre și sim­u­lare”,

“author”: “Jean Baudrillard”,

“publisher”: “Colectia Panopticon”,

“source”: “dataset/83.jpg”,

Roughly 90 per­cent of the books came back cor­rect. The fail­ures were pre­dictable: poor light­ing, dam­aged cov­ers, un­read­able spines. One novel was con­fi­dently iden­ti­fied as a 1987 Soviet agri­cul­tural man­ual.

I fixed the rest by hand. That de­ci­sion was not tech­ni­cal, it was judg­ment. Ninety per­cent ac­cu­racy was enough. Chasing the re­main­ing ten per­cent would have meant days of edge cases for very lit­tle ad­di­tional value. That was the first mo­ment where my role be­came clear.

Later, when I re­ceived a few books for Christmas, we added a sec­ond script that runs the same pipeline for new ad­di­tions. Photo in, meta­data and im­ages out.

With meta­data sorted, cov­ers were still miss­ing. My pho­tos showed spines, not art­work, and I wanted a clean vi­sual rep­re­sen­ta­tion. Claude sug­gested us­ing

Open Library’s API to fetch cov­ers, which mostly worked. Half the cov­ers were low qual­ity or in­cor­rect, and Romanian edi­tions barely ex­isted in the data­base.

We it­er­ated. Claude wrote a sec­ond pass, an­other model call that scored cover qual­ity and flagged bad matches. For flagged books, it fell back to Google Images via SerpAPI. That han­dled most cases. A few re­mained: an­ti­quar­ian finds and ob­scure Soviet box­ing man­u­als that no data­base was ever go­ing to have clean as­sets for.

I opened Photoshop and fixed ten cov­ers by hand. For a col­lec­tion of 460 books, ten man­ual ed­its felt like a win.

Once the data and cov­ers were in place, the UI came next. The ob­vi­ous so­lu­tion was a grid of cov­ers. It was cor­rect, and it was life­less. I kept look­ing at my phys­i­cal book­shelf in­stead. What makes it in­ter­est­ing is not the cov­ers, but the spines. Different widths, un­even pres­sure, col­ors blend­ing into a sin­gle tex­ture.

That was the thing I wanted to recre­ate.

Claude did not in­vent that idea. It ex­e­cuted it. It wrote a script to ex­tract dom­i­nant col­ors from each cover us­ing color quan­ti­za­tion, then com­puted con­trast­ing text col­ors for read­abil­ity. The re­sult was bet­ter, but still wrong. Every book had the same width, and real books are not like that.

Open Library had page counts. We mapped page count to spine width and added slight vari­a­tion to break the uni­for­mity. At that point, it fi­nally looked like a book­shelf.

“id”: “ZfEPBCMZDaCKm6k0NVJ8F”,

“title”: “Simulacre si sim­u­lare”,

“author”: “Jean Baudrillard”,

“backgroundColor”: “#f0f0ff”,

“color”: “#1f1f2e”,

“paddingLeft”: 13,

“paddingRight”: 13,

“height”: 384,

“cover”: “/images/bookshelf/simulacre-si-simulare@2x.webp”,

“source”: “dataset/83.jpg”

Visually, the shelf worked, but it felt sta­tic. A real shelf re­sponds to touch. When you run your fin­ger along the spines, they tilt slightly. I asked Claude for an an­i­ma­tion, and it came back with a scroll based tilt us­ing

Framer Motion.

It was close, but wrong. The move­ment snapped in­stead of flow­ing. I did not know why, I just knew it felt off. That was enough.

Claude ex­plained the is­sue im­me­di­ately. We were up­dat­ing React state on every scroll event, caus­ing un­nec­es­sary re ren­ders. The fix was to use mo­tion val­ues and springs that an­i­mate out­side React’s ren­der cy­cle. Two min­utes later, it was fixed. I spent the next few min­utes scrolling back and forth, just watch­ing it move. This was the mo­ment my cau­tion dropped, not be­cause the tool was al­ways right, but be­cause the cost of try­ing ideas had col­lapsed.

That con­fi­dence had a down­side. I started ask­ing for things I did not need. Infinite scroll seemed sen­si­ble. Why ren­der 460 books at once? Claude im­ple­mented it, and tech­ni­cally it worked. Memory stayed flat, and the DOM up­dated cor­rectly.

But scrolling broke. The con­tainer height de­synced, the last books were un­reach­able, and every at­tempted fix in­tro­duced new jank. The fea­ture worked, but the ex­pe­ri­ence did not. So we re­moved it. Not be­cause it was bro­ken, but be­cause it was un­nec­es­sary. Four hun­dred and sixty books is not a scale prob­lem. Knowing when to delete work­ing code is not some­thing an AI can de­cide for you.

The shelf looked great on desk­top, but on mo­bile, hor­i­zon­tal scrolling felt cramped. I wanted an al­ter­na­tive lay­out: books ly­ing flat, stacked ver­ti­cally, read­able with­out tilt­ing your head. I pointed Claude at the shelf im­ple­men­ta­tion and asked for a stack view.

It read the code, in­ferred the pat­terns, and reused them: an­i­ma­tion tim­ing, color ex­trac­tion, scroll based opac­ity, the same data shape. It built the new com­po­nent and wired up a tog­gle be­tween lay­outs. It worked with­out ex­pla­na­tion. That sur­prised me more than any­thing else.

Claude wrote all the code. So what did I do?

* I de­cided that 90 per­cent ac­cu­racy was enough.

* I fixed the ten cov­ers no API could find.

* I deleted in­fi­nite scroll be­cause I did not need it.

* I kept scrolling the an­i­ma­tion un­til it felt right.

After years of false starts, my book­shelf fi­nally ex­ists. Four hun­dred and sixty books, cat­a­loged and dis­played at book­shelf. I al­most dis­missed Claude Code as hype. Now, the times when I wrote every­thing by hand feel dis­tant, al­most strange.

Execution keeps get­ting cheaper. Taste still does not.

Only the en­gi­neers who work on a large soft­ware sys­tem can mean­ing­fully par­tic­i­pate in the de­sign process. That’s be­cause you can­not do good soft­ware de­sign with­out an in­ti­mate un­der­stand­ing of the con­crete de­tails of the sys­tem. In other words, generic soft­ware de­sign ad­vice is typ­i­cally use­less for most prac­ti­cal soft­ware de­sign prob­lems.

What is generic soft­ware de­sign? It’s “designing to the prob­lem”: the kind of ad­vice you give when you have a rea­son­able un­der­stand­ing of the do­main, but very lit­tle knowl­edge of the ex­ist­ing code­base. Unfortunately, this is the only kind of ad­vice you’ll read in soft­ware books and blog posts. Engineers love giv­ing generic soft­ware de­sign ad­vice for the same rea­son that all tech­ni­cal pro­fes­sion­als love “talking shop”. However, you should be very care­ful about ap­ply­ing generic ad­vice to your con­crete day-to-day work prob­lems.

When you’re do­ing real work, con­crete fac­tors dom­i­nate generic fac­tors. Having a clear un­der­stand­ing of what the code looks like right now is far, far more im­por­tant than hav­ing a good grasp on gen­eral de­sign pat­terns or prin­ci­ples. For in­stance:

* In large code­bases, con­sis­tency is more im­por­tant than “good de­sign”. I won’t ar­gue that point here, but I wrote about it at length in Mistakes en­gi­neers make in large es­tab­lished code­bases.

* Real code­bases are typ­i­cally full of com­plex, hard-to-pre­dict con­se­quences. If you want to make your change safely, that typ­i­cally con­strains your im­ple­men­ta­tion choices down to a bare hand­ful of pos­si­bil­i­ties.

* Large shared code­bases never re­flect a sin­gle de­sign, but are al­ways in some in­ter­me­di­ate state be­tween dif­fer­ent soft­ware de­signs. How the code­base will hang to­gether af­ter an in­di­vid­ual change is thus way more im­por­tant than what ideal “north star” you’re dri­ving to­wards.

In a world where you could rewrite the en­tire sys­tem at will, generic soft­ware de­sign ad­vice would be much more prac­ti­cal. Some pro­jects are like this! But the ma­jor­ity of soft­ware en­gi­neer­ing work is done on sys­tems that can­not be safely rewrit­ten. These sys­tems can­not rely on “software de­sign”, but must in­stead rely on in­ter­nal con­sis­tency and the care­ful­ness of their en­gi­neers.

What does good soft­ware de­sign look like, then?

In my ex­pe­ri­ence, the most use­ful soft­ware de­sign hap­pens in con­ver­sa­tions be­tween a small group of en­gi­neers who all have deep un­der­stand­ing of the sys­tem, be­cause they’re the ones work­ing on it every day. These de­sign dis­cus­sions are of­ten re­ally bor­ing to out­siders, be­cause they re­volve around ar­cane con­crete de­tails of the sys­tem, not around gen­eral prin­ci­ples that any tech­ni­cal per­son can un­der­stand and have an opin­ion on.

The kinds of topic be­ing dis­cussed are not “is DRY bet­ter than WET”, but in­stead “could we put this new be­hav­ior in sub­sys­tem A? No, be­cause it needs in­for­ma­tion B, which is­n’t avail­able to that sub­sys­tem in con­text C, and we can’t ex­pose that with­out rewrit­ing sub­sys­tem D, but if we split up sub­sys­tem E here and here…“.

Deep philo­soph­i­cal points about de­sign are rarely im­por­tant to the dis­cus­sion. Instead, the most crit­i­cal con­tri­bu­tions point out small mis­un­der­stand­ings of con­crete points, like: “oh, you thought B was­n’t avail­able in con­text C, but we re­cently refac­tored C so now we could thread in B if we needed to”.

Generic soft­ware de­sign ad­vice is not use­ful for prac­ti­cal soft­ware de­sign prob­lems, but that does­n’t mean it’s to­tally use­less.

Generic soft­ware de­sign ad­vice is use­ful for build­ing brand-new pro­jects. As I ar­gued above, when you’re de­sign­ing a new fea­ture in an ex­ist­ing sys­tem, con­crete fac­tors of the sys­tem dom­i­nate. But when you’re de­sign­ing a new sys­tem, there are no con­crete fac­tors, so you can be en­tirely guided by generic ad­vice.

Generic soft­ware de­sign ad­vice is use­ful for tie-break­ing con­crete de­sign de­ci­sions. I don’t think you should start with a generic de­sign, but if you have a few can­di­date con­crete path­ways that all seem ac­cept­able, generic prin­ci­ples can help you de­cide be­tween them.

This is par­tic­u­larly true at the level of the en­tire com­pany. In other words, generic soft­ware de­sign ad­vice can help en­sure con­sis­tency across dif­fer­ent code­bases. This is one of the most use­ful func­tions of an of­fi­cial “software ar­chi­tect” role: to pro­vide a set of gen­eral prin­ci­ples so that in­di­vid­ual en­gi­neers can all tie-break their con­crete de­ci­sions in the same di­rec­tion.

Generic soft­ware de­sign prin­ci­ples can also guide com­pany-wide ar­chi­tec­tural de­ci­sions. Should we run our ser­vices in our own dat­a­cen­ter, or in the cloud? Should we use k8s? AWS or Azure? Once you get broad enough, the con­crete de­tails of in­di­vid­ual ser­vices al­most don’t mat­ter, be­cause it’s go­ing to be a huge amount of work ei­ther way. Still, even for these de­ci­sions, con­crete de­tails mat­ter a lot. There are cer­tain things you just can’t do in the cloud (like rely on be­spoke hard­ware se­tups), or that you can’t do in your own dat­a­cen­ter (like de­ploy your ser­vice to the edge in twelve dif­fer­ent re­gions). If the con­crete de­tails of your code­base rely on one of those things, you’ll be in for a bad time if you ig­nore them when mak­ing com­pany-wide ar­chi­tec­tural de­ci­sions.

Those are all good rea­sons to do generic soft­ware de­sign. One bad rea­son com­pa­nies do generic soft­ware de­sign is that it just sounds like a re­ally good idea to peo­ple who aren’t work­ing soft­ware en­gi­neers. Once you’re do­ing it, the in­cen­tives make it hard to stop. Many tech com­pa­nies fall into this lo­cal min­i­mum.

Why not have your high­est-paid soft­ware en­gi­neers spend their time ex­clu­sively mak­ing the most ab­stract, high­est-im­pact de­ci­sions? You want your struc­tural en­gi­neers to be draw­ing, not lay­ing bricks, af­ter all. I don’t know if struc­tural en­gi­neer­ing works like this, but I do know that soft­ware en­gi­neer­ing does­n’t. In prac­tice, soft­ware ar­chi­tec­ture ad­vice of­ten has to be ig­nored by the peo­ple on the ground. There’s sim­ply no way to ac­tu­ally trans­late it into some­thing they can im­ple­ment, in the con­text of the cur­rent sys­tem as it ex­ists.

However, for a prac­tice that does­n’t work, “have your top en­gi­neers just do generic de­sign” is sur­pris­ingly ro­bust. Architects don’t have any skin in the game, be­cause their de­signs are handed off to ac­tual en­gi­neer­ing teams to im­ple­ment. Because those de­signs can never be im­ple­mented per­fectly, ar­chi­tects can both claim credit for suc­cesses (after all, it was their de­sign) and dis­claim fail­ures (if only those fools had fol­lowed my de­sign!)

When work­ing on large ex­ist­ing code­bases, use­ful soft­ware de­sign dis­cus­sions are way, way more con­crete than many peo­ple be­lieve. They typ­i­cally in­volve talk­ing about in­di­vid­ual files or even lines of code. You thus can’t do use­ful soft­ware de­sign with­out be­ing in­ti­mately fa­mil­iar with the code­base (in prac­tice, that al­most al­ways means be­ing an ac­tive con­trib­u­tor).

Purely generic ar­chi­tec­ture is not use­less, but its role should be re­stricted to (a) set­ting out paved paths for brand new sys­tems, (b) tie-break­ing de­ci­sions on ex­ist­ing sys­tems, and (c) help­ing com­pa­nies make broad tech­nol­ogy choices.

In my opin­ion, for­mal “big-picture soft­ware ar­chi­tect” roles that spend all their time lay­ing out the ini­tial de­signs for pro­jects are doomed to fail­ure. They sound like a good idea (and they’re a good deal for the ar­chi­tect, who can claim credit with­out risk­ing blame), but they pro­vide very lit­tle value to the en­gi­neer­ing teams that are tasked with ac­tu­ally writ­ing the code.

Personally, I be­lieve that if you come up with the de­sign for a soft­ware pro­ject, you ought to be re­spon­si­ble for the pro­jec­t’s suc­cess or fail­ure. That would rapidly en­sure that the peo­ple de­sign­ing soft­ware sys­tems are the peo­ple who know how to ship soft­ware sys­tems. It would also en­sure that the real soft­ware de­sign­ers - the ones that have to take into ac­count all the rough edges and warts of the code­base - get credit for the dif­fi­cult de­sign work they do.

edit: this post got some com­ments on Hacker News. I was sur­prised to see some com­menters dis­agree­ing with my point about con­sis­tency. I re­mem­ber the re­cep­tion of Mistakes en­gi­neers make in large es­tab­lished code­bases be­ing quite pos­i­tive. I was not sur­prised to see some com­menters make the “haha, this is hyp­o­crit­i­cal be­cause it is it­self generic ad­vice” point. I ad­dressed this in the “when generic de­sign is use­ful” sec­tion above.

This page gives you di­rect ac­cess to all 1,038 delisted Steam ti­tles on the site. Below each ti­tle are the com­pa­nies it re­lates to. An * in the ti­tle de­notes a place­holder page that con­tains ba­sic de­tails.

I switched to eSIM in 2025, and I am full of re­gret

Swapping SIM cards used to be easy, and then came eSIM.

NanoSIMs are tiny, but phone mak­ers still want to get rid of them.

NanoSIMs are tiny, but phone mak­ers still want to get rid of them.

SIM cards, the small slips of plas­tic that have held your mo­bile sub­scriber in­for­ma­tion since time im­memo­r­ial, are on the verge of ex­tinc­tion. In an ef­fort to save space for other com­po­nents, de­vice mak­ers are fi­nally drop­ping the SIM slot, and Google is the lat­est to move to em­bed­ded SIMs with the Pixel 10 se­ries. After long avoid­ing eSIM, I had no choice but to take the plunge when the time came to re­view Google’s new phones. And boy, do I re­gret it.

SIM cards have ex­isted in some form since the ’90s. Back then, they were credit card-sized chunks of plas­tic that oc­cu­pied a lot of space in­side the clunky phones of the era. They slimmed down over time, go­ing through the min­iSIM, mi­croSIM, and fi­nally nanoSIM eras. A mod­ern nanoSIM is about the size of your pinky nail, but space is at a pre­mium in­side smart­phones. Enter, eSIM.

The eSIM stan­dard was in­tro­duced in 2016, slowly gain­ing sup­port as a sec­ondary op­tion in smart­phones. Rather than hold­ing your phone num­ber on a re­mov­able card, an eSIM is a pro­gram­ma­ble, non-re­mov­able com­po­nent sol­dered to the cir­cuit board. This al­lows you to store mul­ti­ple SIMs and swap be­tween them in soft­ware, and no one can swipe your SIM card from the phone. They also take up half as much space com­pared to a re­mov­able card, which is why OEMs have be­gun drop­ping the phys­i­cal slot.

Apple was the first ma­jor smart­phone maker to force the use of eSIM with the re­lease of the iPhone 14, and it makes use of that space. The in­ter­na­tional iPhone 17 with a SIM card slot has a smaller bat­tery than the eSIM-only ver­sion, but the dif­fer­ence is only about 8 per­cent. Google did­n’t make the jump un­til this year with the Pixel 10 se­ries—the US mod­els are eSIM-only, but they un­for­tu­nately don’t have more of any­thing com­pared to the in­ter­na­tional ver­sions.

In ad­vance of the shift, Android got sys­tem-level sup­port for down­load­ing and trans­fer­ring eS­IMs. But what­ever can go wrong will go wrong, and it’s ex­tremely an­noy­ing when eSIM goes wrong.

There have been times when I swapped be­tween phones on an al­most daily ba­sis—such was the na­ture of re­view­ing phones back when there were a dozen of them com­ing out every month. Never once in all those count­less de­vice swaps did I have a prob­lem with my SIM card. As such, I man­aged to avoid con­tact­ing car­rier sup­port for years at a time.

In the three months since Google forced me to give up my phys­i­cal SIM card, I’ve only needed to move my eSIM oc­ca­sion­ally. Still, my phone num­ber has ended up stuck in limbo on two oc­ca­sions. Android’s built-in tools work bet­ter than they used to, and I can’t say what is re­spon­si­ble for the eSIM cor­rup­tion. However, car­ri­ers bear the re­spon­si­bil­ity for how an­noy­ing this is to fix.

The first time, I was logged in to the mo­bile app for my car­rier (T-Mobile). After a few min­utes of back and forth with sup­port, I was able to use the app to au­then­ti­cate and get a new eSIM pushed to the phone. It was an­noy­ing but rel­a­tively pain­less. The sec­ond time a SIM trans­fer went side­ways, I was not logged in to the app, and that was a prob­lem.

When a mo­bile car­rier needs to ver­ify your iden­tity for an ac­count change, they all do the same thing: send a text mes­sage. And what hap­pens if you don’t have a work­ing SIM? That’s right—noth­ing. Without ac­cess to my ac­count or phone num­ber, I was stuck with no way to down­load a new eSIM. The only course of ac­tion was to go to a phys­i­cal store to down­load an elec­tronic SIM card. What should have been 30 sec­onds of fid­dling with a piece of plas­tic turned into an hour stand­ing around a re­tail store­front.

Many peo­ple have had the same phone num­ber for years—even decades at this point. These num­bers aren’t just a way for peo­ple to get in touch be­cause, stu­pidly, we have also set­tled on phone num­bers as a means of au­then­ti­ca­tion. Banks, mes­sag­ing apps, crypto ex­changes, this very web­site’s pub­lish­ing plat­form, and even the car­ri­ers man­ag­ing your num­ber rely on SMS mul­ti­fac­tor codes. And those codes aren’t even very se­cure.

So los­ing ac­cess to your phone num­ber does­n’t just lock you out of your phone. Key parts of your dig­i­tal life can also be­come in­ac­ces­si­ble, and that could hap­pen more of­ten now due to the fun­gi­ble na­ture of eS­IMs.

Most peo­ple won’t need to move their phone num­ber very of­ten, but the risk that your eSIM goes up in smoke when you do is very real. Compare that to a phys­i­cal SIM card, which will vir­tu­ally never fail un­less you dam­age the card. Swapping that tiny bit of plas­tic takes a few sec­onds, and it never re­quires you to sit on hold with your car­ri­er’s sup­port agents or drive to a store. In short, a phys­i­cal SIM is es­sen­tially fool­proof, and eSIM is not.

Obviously, the so­lu­tion is not to re­move mul­ti­fac­tor au­then­ti­ca­tion—your phone num­ber is, un­for­tu­nately, too im­por­tant to be un­guarded. However, car­ri­ers’ use of SMS to con­trol ac­count ac­cess is self-de­feat­ing and vir­tu­ally guar­an­tees peo­ple are go­ing to have bad ex­pe­ri­ences in the era of eSIM. Enshittification has truly come for SIM cards.

If this fu­ture is in­evitable, there ought to be a bet­ter way to con­firm ac­count own­er­ship when your eSIM glitches. It does­n’t mat­ter what that is as long as SMS is­n’t the de­fault. Google ac­tu­ally gets this right with Fi. You can down­load an eSIM at any time via the Fi app, and it’s se­cured with the same set­tings as your Google ac­count. That’s re­ally as good as it gets for con­sumer se­cu­rity. Between Google Authenticator, passkeys, and push no­ti­fi­ca­tions, it’s pretty hard to get locked out of Google, even if you take ad­van­tage of ad­vanced se­cu­rity fea­tures.

We gave up the head­phone jack. We gave up the mi­croSD card. Is all this worth­while to boost bat­tery ca­pac­ity by 8 per­cent? That’s a tough sell.

Ryan Whitwam is a se­nior tech­nol­ogy re­porter at Ars Technica, cov­er­ing the ways Google, AI, and mo­bile tech­nol­ogy con­tinue to change the world. Over his 20-year ca­reer, he’s writ­ten for Android Police, ExtremeTech, Wirecutter, NY Times, and more. He has re­viewed more phones than most peo­ple will ever own. You can fol­low him on Bluesky, where you will see pho­tos of his dozens of me­chan­i­cal key­boards.

I switched to eSIM in 2025, and I am full of re­gret

A quirky guide to myths and lore based in ac­tual sci­ence

Replaces the stan­dard Go run­time with one de­signed for the Dreamcast’s con­straints: mem­ory 16MB RAM, CPU sin­gle-core SH-4, no op­er­at­ing sys­tem. Provides garbage col­lec­tion, gor­ou­tines, chan­nels, and the core run­time func­tions.

Prerequisites: Go 1.25.3+, make, and git must be in­stalled.

go in­stall github.com/​dr­paneas/​godc@lat­est

godc setup

godc doc­tor # to check (optional)

Note: The godc CLI tool is a sep­a­rate pro­ject that han­dles tool­chain setup and builds.

mkdir mypro­ject && cd mypro­ject

godc init

# write you main.go and other *.go files

godc build

godc run

See the Quick Start Guide for your first pro­gram.

* hel­lo_screen — Hello World on screen us­ing BIOS font