“Internal ICE ma­te­r­ial and tes­ti­mony from an of­fi­cial ob­tained by 404 Media pro­vides the clear­est link yet be­tween the tech­no­log­i­cal in­fra­struc­ture Palantir is build­ing for ICE and the agen­cy’s ac­tiv­i­ties on the ground.”

“Internal ICE ma­te­r­ial and tes­ti­mony from an of­fi­cial ob­tained by 404 Media pro­vides the clear­est link yet be­tween the tech­no­log­i­cal in­fra­struc­ture Palantir is build­ing for ICE and the agen­cy’s ac­tiv­i­ties on the ground.”

This is racial pro­fil­ing on a grand scale:

It ap­par­ently looks a lot like Google Maps, but de­signed to show the rich­ness of an area for “targets”, pop­u­lated in part by den­sity of im­mi­grants. And then you can dig in:

The Nazis could only dream of hav­ing such a ca­pa­bil­ity.

Imagine work­ing for this com­pany, on this prod­uct. Every day, you go into work, in what I as­sume is a beau­ti­ful of­fice with pine fur­ni­ture and a well-stocked kitchen, and you build soft­ware that will help to de­port peo­ple us­ing what you know are ex­tra­ju­di­cial means with­out due process. You prob­a­bly have OKRs. There are cus­tomer calls with ICE. Every two-week sprint, you take on tasks that help make this en­gine bet­ter.

What do you tell your­self? What do you tell your fam­ily?

Are you on board with this agenda, or do you tell your­self you need the job to pay rent? To get health­care?

You re­ceive stock as part of your pay pack­age. It’s go­ing up! You can use it to buy a home, or to build a com­fort­able re­tire­ment, or some com­bi­na­tion of the two.

Your co-work­ers are val­ues aligned and work hard. They’re tal­ented and smart. Man, you might think to your­self, I love work­ing with this team.

Or, you might think, man, I’ve got to find an­other job.

Either way, you’re proud of your prod­uct work. You’re happy to take the salary, the free lunches, the espresso. And re­gard­less of how you feel about it, the thing you do every day is pow­er­ing an armed force that is kid­nap­ping peo­ple on the street and shoot­ing civil­ians, that shot a mother in the face, that is tar­get­ing peo­ple to dis­ap­pear us­ing a beau­ti­ful, mod­ern map in­ter­face.

Following a re­cent se­ries of com­mits by Helg Bredow (helg@) and Stefan Fritsch (sf@), OpenBSD/arm64 now works as a guest op­er­at­ing sys­tem un­der the Apple Hypervisor.

List: openbsd-cvs

Subject: CVS: cvs.openbsd.org: src

From: Helg Bredow

Date: 2026-01-12 18:15:33

CVSROOT: /cvs

Module name: src

Changes by: helg@cvs.openbsd.org 2026/​01/​12 11:15:33

Modified files:

sys/​dev/​pv  : viogpu.c

Log mes­sage:

viog­pu_ws­mmap() re­turns a kva but in­stead should re­turn a phys­i­cal

ad­dress via bus_d­mamem_mmap(9). Without this, QEMU would only show a

black screen when start­ing X11. On the Apple Hypervisor, the ker­nel

would panic.

Also add calls to bus_d­mamap_­sync(9) be­fore trans­fer­ring the frame­buffer

to host mem­ory. It was work­ing for me with­out this, but this en­sures

that the host run­ning on an­other CPU will see up­dates to the

frame­buffer.

Thanks to ket­te­nis@ for re­view­ing and pro­vid­ing feed­back.

ok sf@

List: openbsd-cvs

Subject: CVS: cvs.openbsd.org: src

From: Stefan Fritsch

Date: 2026-01-15 9:06:19

CVSROOT: /cvs

Module name: src

Changes by: sf@cvs.openbsd.org 2026/​01/​15 02:06:19

Modified files:

sys/​dev/​pv  : if_vio.c

Log mes­sage:

vio: Support MTU fea­ture

Add sup­port for the VIRTIO_NET_F_MTU which al­lows to get the hardmtu

from the hy­per­vi­sor. Also set the cur­rent mtu to the same value. The

vir­tio stan­dard is not clear if that is rec­om­mended, but Linux does

this, too.

Use ETHER_MAX_HARDMTU_LEN as up­per hardmtu limit in­stead of MAXMCLBYTES,

as this seems to be more cor­rect.

If the hy­per­vi­sor re­quests a MTU larger than ETHER_MAX_HARDMTU_LEN,

redo fea­ture ne­go­ti­a­tion with­out VIRTIO_NET_F_MTU.

With this com­mit, OpenBSD fi­nally works on Apple Virtualization.

Input and test­ing from @helg

ok jan@

This de­vel­op­ment will be most wel­come for those of us who run with newer Apple Silicon Mac mod­els.

As al­ways, if you have the hard­ware and the ca­pac­ity, please take this for a spin (in snap­shots now), and re­port!

Copyright ©

Daniel Hartmeier. All rights re­served. Articles and com­ments are copy­right their re­spec­tive au­thors, sub­mis­sion im­plies li­cense to pub­lish on this web site. Contents of the archive prior to

as well as im­ages and HTML tem­plates were copied from the fab­u­lous orig­i­nal

deadly.org with

Jose’s and

Jim’s kind per­mis­sion. This jour­nal runs as with

httpd(8)

on OpenBSD, the

source code is

li­censed. un­deadly \Un*dead”ly\, a. Not sub­ject to death; im­mor­tal. [Obs.]

Opus 4.5 is out and peo­ple can­not stop rav­ing about it. AGI is nigh! It’s a step-change in ca­pa­bil­i­ties!

Don’t get me wrong. It’s very im­pres­sive. But af­ter try­ing it out in a real code­base for a few weeks, I think that view is overly sim­plis­tic. Claude is now in­cred­i­bly good at as­sem­bling well-de­signed blocks — but it still falls apart when it has to cre­ate them.

To demon­strate, I’ll run through three real ex­am­ples: a Sentry de­bug­ging loop where Claude ran on its own for 90 min­utes and solved the prob­lem; an AWS mi­gra­tion it one-shot­ted in three hours; and a React refac­tor where it pro­posed a hack that would have made our code­base worse.

The same pat­tern ex­plains all three. And in do­ing so, it also demon­strates what se­nior en­gi­neers ac­tu­ally do — and why we’ll be safe from AGI for a long time.

The most im­pres­sive thing Claude Code has done for me is de­bug, on its own.

I was try­ing to at­tach Sentry to our sys­tem. Sentry is a won­der­ful ser­vice that cre­ates nice traces of when parts of your code run. This makes it easy to fig­ure out why it’s run­ning slower than you ex­pect.

It’s usu­ally very easy to set up, but on this day it was­n’t work­ing. And there were no good de­bug logs, so the only way to fig­ure out what was go­ing on was to guess-and-check. I had to send a test mes­sage on our fron­tend, then look into the Sentry logs to see if we suc­cess­fully set it up, then ran­domly try an­other ap­proach based on the docs. It was frus­trat­ing and te­dious.

So I had Claude write a lit­tle test­ing script with Playwright that logged into our web­site and sent a chat. Then I had it con­nect to Sentry by MCP, and look for the ex­act code­path I was try­ing to de­bug. Finally, I gave it the Sentry docs and told it to keep plug­ging away un­til it fig­ured it out.

It took about an hour and a half, but Claude fi­nally got it. This was pretty cool! The core loop of per­for­mance en­gi­neer­ing is straight­for­ward: make a code change, test, check trac­ing logs, re­peat. With this tool­ing, Claude could do that work for us.

I’ve used Modal hap­pily for a year. It has the best UI for spin­ning up con­tain­ers in the cloud on-de­mand. But last week we hit its lim­its, so I had to mi­grate us onto AWS.

I wanted to set up an au­toscal­ing, con­tainer­ized work­flow on Amazon’s Elastic Container Service, since I knew this was the ‘right’ thing to do. I’ve set up plenty of Linux servers by hand, so I knew what to do. But I’ve never be­fore touched Kubernetes or ECS. The pain of learn­ing AWS’s ter­mi­nol­ogy al­ways put me off.

This time, I asked Claude to do it. I gave it Terraform and ac­cess to the aws com­mand line tool. It one-shot­ted cre­at­ing Dockerfiles for our code. Then it pushed them to AWS’s con­tainer reg­istry, and set up the cor­rect per­mis­sions us­ing the cli, and set up the nec­es­sary AWS ECS con­figs in Terraform.

And it all worked on the first try! Amazing!

This is a straight­for­ward task, but it would have taken me a day or two. I would have made a dozen mis­takes and would have had to read through pages of AWS doc­u­men­ta­tion. Claude crushed it, and got it all work­ing in three hours late at night.

Both these use-cases are re­ally im­pres­sive! They re­quired a lot of de­tail and care. They each prob­a­bly saved me a day and a half of low-value, te­dious work. And Claude’s abil­ity to track its own state and keep go­ing was great! I can see why folks can­not shut up about Opus 4.5.

I once knew a dis­tin­guished en­gi­neer named sweeks. Sweeks was leg­endary for his good code. People whis­pered about how he had sin­gle-hand­edly in­vented many of my em­ploy­er’s par­a­digms for pro­gram­ming in OCaml.

Sweeks was­n’t a god. He wrote nor­mal, bug-prone code, like you and me. He was good at cod­ing be­cause he was a gar­dener. Every time he walked into his code­base, he picked up his shears and man­i­cured a bit of stray code. Over time, he rewrote every line of code over and over, tight­en­ing it down to only the per­fectly-ab­stracted es­sen­tials.

Sweeks is an in­spi­ra­tion. So when­ever I make a change in our code­base, I ask if it’s the most el­e­gant so­lu­tion. If not, I rewrite the code un­til it is. Putting in a hacky fix might take five min­utes; re­pair­ing all the code around a change might take me thirty. But un­less I’m in a rush, I al­ways do the lat­ter.

I bring this up be­cause it’s a mi­cro­cosm of what a se­nior en­gi­neer does. A se­nior en­gi­neer sees the non-ob­vi­ous im­prove­ments and ex­e­cutes them quickly. A se­nior en­gi­neer iden­ti­fies large step changes that are costly, but pay off in mul­ti­ples down the road, and fights to get them through.

I was re­cently work­ing on some gnarly React code. (In fact, it was gnarly be­cause I vibe-coded it over Christmas and pushed it with­out prop­erly clean­ing it up.)

We had two com­po­nents that both needed ac­cess to the same data: Component A had a ‘key’, and Component B had an ‘id’. And we had these data struc­tures:

Our prob­lem, at its core, was that Component A needed to look up data on-de­mand as well. What to do?

// Scan the list to find the match­ing idid = keyId­Pairs.find(pair => pair.key == key).id­data = id­To­Data.get(id)

But in con­text, this was ob­vi­ously in­sane. I knew that key and id came from the same up­stream source. So the cor­rect so­lu­tion was to have the up­stream source also pass id to the code that had key, to let it do a fast lookup.*

If you give Claude the pure data prob­lem, it comes up with the right so­lu­tion. But in our ac­tual code­base, it lost the plot. It could­n’t see the ac­tual data prob­lem amid all the badly-writ­ten React code. If I’d let it run wild, it would have made our fron­tend code­base worse.

Nowadays, I think of Claude as a very smart child — one that loves to put to­gether le­gos. Good in­fra­struc­ture and ab­strac­tions are the lego blocks you give it. The big­ger and bet­ter they are, the more you can do.

When I gave it Sentry, I could put it in a loop and watch it go. When I gave it Terraform and told it to go wild on the AWS CLI, it suc­ceeded be­cause Terraform is an ex­cel­lent ab­strac­tion over cloud com­pute re­sources.

But when you don’t have good ab­strac­tions — like in our gnarly React code — Claude gets lost, and it can’t res­cue it­self.

Grant Slatton put it very well:

Since Claude can’t cre­ate the good ab­strac­tions. Claude’s pow­ers are lim­ited by how good the blocks you give it are. Have no il­lu­sions; Claude can­not re­pro­duce Sentry and Terraform and Playwright. These are in­cred­i­bly com­plex and well-de­signed pieces of code. And since Claude can’t cre­ate good ab­strac­tions on its own, there’s a limit to how much any­one can do with Claude alone. Even though every­one on X thinks you can vibe-code all soft­ware, I think the op­po­site is true: the value of good ab­strac­tions and well-de­signed in­fra­struc­ture has never been higher.

If I had to boil down my crit­i­cism of Claude to one sen­tence, it’s this: Claude does­n’t have a soul. It does­n’t want any­thing. It cer­tainly does­n’t yearn to cre­ate beau­ti­ful things. So it does­n’t pro­duce good so­lu­tions. It does­n’t write el­e­gant ab­strac­tions where there were none; it does­n’t man­i­cure the code gar­den.

And this is all fine! It’s still a fan­tas­tic tool. But un­til it has a soul, we should all calm down a lit­tle. It’s nowhere near re­plac­ing all en­gi­neers. If any­thing, it makes us all much more im­por­tant.

Edited Jan 12: I rewrote the React sec­tion to ex­plain more clearly what Claude did wrong. Thanks to Konsti for point­ing this out!

Just the Browser helps you re­move AI fea­tures, teleme­try data re­port­ing, spon­sored con­tent, prod­uct in­te­gra­tions, and other an­noy­ances from desk­top web browsers. The goal is to give you “just the browser” and noth­ing else, us­ing hid­den set­tings in web browsers in­tended for com­pa­nies and other or­ga­ni­za­tions.

This pro­ject in­cludes con­fig­u­ra­tion files for pop­u­lar web browsers, doc­u­men­ta­tion for in­stalling and mod­i­fy­ing them, and easy in­stal­la­tion scripts. Everything is open-source on GitHub.

The setup script can in­stall the con­fig­u­ra­tion files in a few clicks. You can also fol­low the man­ual guides for Google Chrome, Microsoft Edge, and Firefox.

Windows: Open a PowerShell prompt as Administrator. You can do this by right-click­ing the Windows but­ton in the taskbar, then se­lect­ing the “Terminal (Admin)” or “PowerShell (Admin)” menu op­tion. Next, copy the be­low com­mand, paste it into the win­dow (Ctrl+V), and press the Enter/Return key:

& ([scriptblock]::Create((irm “https://​raw.githubuser­con­tent.com/​corbin­dav­en­port/​just-the-browser/​main/​main.ps1”)))

Mac and Linux: Search for the Terminal in your ap­pli­ca­tions list and open it. Next, copy the be­low com­mand, paste it into the win­dow (Ctrl+V or Cmd+V), and press the Enter/Return key:

/bin/bash -c “$(curl -fsSL https://​raw.githubuser­con­tent.com/​corbin­dav­en­port/​just-the-browser/​main/​main.sh)”

Start here if you don’t have your pre­ferred web browser in­stalled. You can in­stall the con­fig­u­ra­tion files af­ter­wards.

Not sure which link to use? Try the of­fi­cial down­load page.

Not sure which link to use? Try the of­fi­cial down­load page or Linux setup in­struc­tions.

Not sure which link to use? Try the of­fi­cial down­load page.

Got a ques­tion? Check here first, and if you still need help, cre­ate an is­sue on GitHub or join the Discord.

Just the Browser aims to re­move the fol­low­ing func­tion­al­ity from pop­u­lar web browsers:

* Most AI fea­tures: Features that use gen­er­a­tive AI mod­els, ei­ther on-de­vice or in the cloud, like Copilot in Microsoft Edge or tab group sug­ges­tions in Firefox. The main ex­cep­tion is page trans­la­tion in Firefox.

* Sponsored or third-party con­tent: Suggested ar­ti­cles on the New Tab Page, spon­sored site sug­ges­tions, etc.

* Default browser re­minders: Pop-ups or other prompts that ask you to change the de­fault web browser.

* First-run ex­pe­ri­ences and data im­port prompts: Browser wel­come screens and their re­lated prompts to im­port data au­to­mat­i­cally from other web browsers.

* Telemetry: Data col­lec­tion by web browsers. Crash re­port­ing is left en­abled if the browser (such as Firefox) sup­ports it as a sep­a­rate op­tion.

* Startup boost: Features that al­low web browsers to start with the op­er­at­ing sys­tem with­out ex­plicit per­mis­sion.

The ex­act list of fea­tures mod­i­fied for each browser can be found on the pages for Google Chrome, Microsoft Edge, and Firefox.

Yes. The browser guides in­clude steps for re­mov­ing the con­fig­u­ra­tions, and the au­to­mated script can also do it. The browser guides ex­plain each set­ting, so you can add, re­move, or mod­ify the files be­fore you in­stall them.

Just the Browser has con­fig­u­ra­tion files and setup scripts for Google Chrome, Microsoft Edge, and Mozilla Firefox. However, Chrome on Linux and Edge on Linux are not cur­rently sup­ported.

Not yet. See the is­sues for Android sup­port and iOS/​iPa­dOS sup­port.

No. Just the Browser uses group poli­cies that are fully sup­ported by web browsers, usu­ally in­tended for IT de­part­ments in com­pa­nies or other large or­ga­ni­za­tions. No ap­pli­ca­tions or ex­e­cutable files are mod­i­fied in any way.

Yes, as long as the web browsers con­tinue to sup­port the set­tings used in the con­fig­u­ra­tion files. Web browsers oc­ca­sion­ally add, re­move, or re­place the set­tings op­tions, so if the cus­tom con­fig­u­ra­tion breaks, try in­stalling the lat­est avail­able ver­sion.

No. If you want one, try uBlock Origin or uBlock Origin Lite.

The group pol­icy set­tings used by Just the Browser are in­tended for PCs man­aged by com­pa­nies and other large or­ga­ni­za­tions. Browsers like Microsoft Edge and Firefox will dis­play a mes­sage like “Your browser is be­ing man­aged by your or­ga­ni­za­tion” to ex­plain why some set­tings are dis­abled.

You can open about:poli­cies in Firefox or chrome://​pol­icy in Chrome and Edge to see a list of ac­tive group pol­icy set­tings.

You can do that! However, switch­ing to al­ter­na­tive web browsers like Vivaldi, SeaMonkey, Waterfox, or LibreWolf can have other down­sides. They are not al­ways avail­able on the same plat­forms, and they can lag be­hind main­stream browsers in se­cu­rity up­dates and en­gine up­grades. Just the Browser aims to make main­stream web browsers more tol­er­a­ble, while still re­tain­ing their ex­ist­ing ben­e­fits.

Persistent state: boxes pause on dis­con­nect and re­sume where you left off

HTTPS end­points: every box gets a pub­lic URL with au­to­matic TLS

Prepaid bal­ance with re­funds avail­able for un­used funds

Creating box…

Box ‘dev1’ cre­ated suc­cess­fully

URL: https://​dev1-a1b2c3d4.shell­box.dev

Connect with: ssh -t shell­box.dev con­nect dev1

Starting box…

Connected!

root@dev1:~# _

NAME STATE URL

dev1 run­ning https://​dev1-a1b2c3d4.shell­box.dev

myapp stopped https://​myapp-a1b2c3d4.shell­box.dev

Account Balance

Funds added: $30.00

Funds re­funded: $10.00

Usage costs: $1.50

Current bal­ance: $18.50

Remaining hours at cur­rent rates:

Running boxes: ~370 hours

Idle boxes: ~3700 hours

Add $10.00 to your ac­count

https://​pay.pad­dle.com/…

Scan QR code or visit URL to com­plete pay­ment.

Your ac­count will be cred­ited au­to­mat­i­cally.

List your boxes with sta­tus and URLs

When I was a ju­nior en­gi­neer, my man­ager would oc­ca­sion­ally con­fide his frus­tra­tions to me in our weekly 1:1s. He would point out a pro­ject an­other team was work­ing on and say, “I don’t be­lieve that pro­ject will go any­where, they’re solv­ing the wrong prob­lem.” I used to won­der, “But you are very se­nior, why don’t you just go and speak to them about your con­cerns?” It felt like a waste of his in­flu­ence to not say any­thing.

So it’s quite ironic that I found my­self last week ex­plain­ing to a mentee why I thought a sis­ter team’s pro­ject would have to pivot be­cause they’d made a poor early de­sign choice. And he right­fully asked me the same ques­tion I had years ago: “why don’t you just tell them your opin­ion?” It’s been on my mind ever since be­cause I re­al­ized I’d changed my stance on it a lot over the years.

The an­swer is that be­ing right and be­ing ef­fec­tive are dif­fer­ent.

In large com­pa­nies, speak­ing up about what you see as a “bad pro­ject” is a good thing. But only in mod­er­a­tion. Sometimes the mark of se­nior­ity is re­al­iz­ing that ar­gu­ing with peo­ple who won’t lis­ten is­n’t worth it; it’s bet­ter to save your coun­sel.

What I mean by a “bad pro­ject” is many things:

It’s im­por­tant to point out that for much of the life­cy­cle of a pro­ject, whether it’s “bad” is highly sub­jec­tive. Software en­gi­neer­ing is largely a game of trade­offs and mak­ing de­ci­sions which are not per­fect but the best pos­si­ble with the in­for­ma­tion avail­able. There of­ten can be dis­agree­ments on whether cor­rect choices are made and it only be­comes ob­vi­ous much later on, po­ten­tially years af­ter a pro­ject has shipped.

But as you be­come more se­nior, you’ll start to have “taste” when it comes to soft­ware pro­jects and that will cause you to look at some frac­tion of the soft­ware pro­jects and feel “this does­n’t make sense”. And this gut feel­ing is the sign to me of a “bad pro­ject”, one which you can see in ad­vance of when it’s ob­vi­ous to every­one.

Drawing on my per­sonal ex­pe­ri­ence, the most mem­o­rable ex­am­ple was a few years ago at Google . There was a high-pro­file an­nounce­ment in­ter­nally of a “game changer” pro­ject that sat right at the in­ter­sec­tion of two ex­tremely large or­ga­ni­za­tions. It was tech­ni­cally amaz­ing and el­e­gant, and full of clever ideas for re­ally hard prob­lems.

But I dis­tinctly re­mem­ber sit­ting in the room for the an­nounce­ment, turn­ing to my lead and whis­per­ing, “This pro­ject has no chance of suc­ceed­ing, right?” He turned to me and just said, “Yup.” We both re­al­ized the prob­lem im­me­di­ately. The pro­ject was en­tirely based on a plat­form team ask­ing a flag­ship prod­uct team to give up con­trol of their core user flow: tech­ni­cally the right move, but no lead or PM would ever cede own­er­ship of some­thing that cen­tral to an­other team. Politically, this pro­ject was a to­tal fan­tasy.

The pro­ject kept qui­etly chug­ging away in the back­ground for al­most two years. Every time it got close to launch, it would get pushed back as “not ready yet.” Over time, we heard less and less about it un­til, even­tu­ally, the in­evitable “strategic pivot” email ap­peared in my in­box. Resources were re­al­lo­cated and the code was deleted. We were told the com­pany “learned a lot from the ef­fort,” but to me it felt like it was doomed from the be­gin­ning. Politics and solv­ing the cor­rect prob­lem mat­ter just as much as tech­ni­cal beauty.

When I started notic­ing “bad pro­jects” and I felt that I had some ex­per­tise to share, the temp­ta­tion for me was to start call­ing them out. Reach out to the team do­ing it, tell them “this does­n’t make sense” and ex­plain to them why. Use facts and logic to per­suade.

And I did do this. But only for a very short time be­fore I re­al­ized that there are a lot of costs to do­ing this that I just was­n’t think­ing about.

Firstly, soft­ware com­pa­nies have an in­her­ent bias for ac­tion. They value speed and ship­ping highly. Concerns, by de­f­i­n­i­tion, slow things down and mean peo­ple have to look at things which they had­n’t bud­geted for. And so un­less your con­cern is big enough to over­come the “push for land­ing”, there’s lit­tle chance for any mean­ing­ful change to come from you say­ing some­thing. In fact, it’s very likely that you’ll be largely ig­nored.

Related to this, even if the team does take your con­cern se­ri­ously, you have to be care­ful not to do it too of­ten. Once or twice, you might be seen as some­one who is up­hold­ing “quality”. But do it too of­ten and you quickly move to be­ing seen as a “negative per­son”, some­one who is con­stantly a prob­lem maker, not a prob­lem “fixer”. You rarely get credit for the dis­as­ters you pre­vented. Because noth­ing hap­pened, peo­ple for­get about it quickly.

There’s also the prob­lem that every time you push back, you are po­ten­tially harm­ing some­one’s pro­mo­tion packet or a VP’s “pet pro­ject.” You are at risk of burn­ing bridges and cre­at­ing “enemies”, at least of a sort. Having a few peo­ple who dis­agree in a big com­pany with you is the cost of do­ing busi­ness, but if you have too many, it starts af­fect­ing your main work too.

Finally, there is also the psy­cho­log­i­cal im­pact. There is one of you and hun­dreds of en­gi­neers work­ing in spaces that your ex­per­tise might help with. Your at­ten­tion is fi­nite, but the ca­pac­ity for a large com­pany to gen­er­ate bad ideas is in­fi­nite. Speaking from ex­pe­ri­ence, get­ting too in­volved in stop­ping these quickly can make you very cyn­i­cal about the state of the world. And this is re­ally not a good place to be.

So if you can­not stop all the bad pro­jects, what do you do? You get strate­gic. Instead of try­ing to fix every­thing, view your in­flu­ence as a bank ac­count. You have a cer­tain amount of “influence” com­ing in every month as you do your job, help peo­ple, ship suc­cess­ful pro­jects, and gen­er­ally re­main low fric­tion.

Then, when it mat­ters, you should be ready to make “withdrawals.” Every time you block some­thing or raise con­cerns, no mat­ter how small, you are writ­ing a check against your bal­ance. But not all checks are the same size:

* The $500 Check: Challenging an ar­chi­tec­tural de­ci­sion or push­ing back on a time­line. Requires some sav­ings.

* The $50,000 Check: Trying to kill a VP’s pet pro­ject. This is a mas­sive spend. You might only af­ford this once every few years.

The prob­lem comes if you spend $5 on every mi­nor in­ef­fi­ciency you see. If you are con­stantly say­ing “no” to small things, your ac­count will be empty when you need to write the big check to stop a true dis­as­ter.

If you “go over­drawn,” you en­ter po­lit­i­cal bank­ruptcy. People stop invit­ing you to meet­ings, they stop ask­ing for your opin­ion, they es­sen­tially start work­ing around you. Once you are bank­rupt, your in­flu­ence drops to zero and you not only harm your abil­ity to in­flu­ence things but also start hurt­ing your own abil­ity to get things done.

Given that we’ve now ac­cepted that we can­not weigh in on every­thing, we need to fig­ure out when it does make sense to do so.

The most im­por­tant thing to do first is to be hum­ble and eval­u­ate whether you ac­tu­ally have the ex­per­tise to make a judg­ment. Seniority of­ten brings opin­ions, but those are not al­ways in­formed opin­ions. For ex­am­ple, while I have some fron­tend ex­pe­ri­ence, I do not feel qual­i­fied to give deep ad­vice on it be­cause my knowl­edge is “enough to get by” rather than deep ex­per­tise that comes from long term own­er­ship. It is easy to lose sight of the fact that high-qual­ity judg­ments re­quire in­formed opin­ions. If you find your­self in this po­si­tion, see your­self as an opin­ion­ated ob­server and stop there.

You must also in­ter­nal­ize the fact that just be­cause you say some­thing does not make it the truth. You are rais­ing aware­ness of a point of view, not is­su­ing a de­cree. So if some team does­n’t lis­ten to your con­cerns and de­cides to go ahead with what they were do­ing any­way, then you have to ac­cept that and move on: at the end of the day, you’re an en­gi­neer, not a CEO with au­thor­ity over them!

Given these points, I use three main fac­tors to de­cide when to speak up:

How close is the pro­ject to my team?If it goes wrong, how much im­pact will it have on my team?If it goes wrong, how big will the prob­lem be for the com­pany?

Proximity. If a pro­ject is close to you, the “price tag” of say­ing some­thing is lower. If it is within your own team, the cost is near zero be­cause you have high trust and a quick con­ver­sa­tion of­ten solves it. If it is in your broader or­ga­ni­za­tion, the price goes up; you have to spend so­cial cap­i­tal and po­ten­tially stake your rep­u­ta­tion. If it is out­side your org? The cost is of­ten pro­hib­i­tive. You have zero lever­age, dif­fer­ent re­port­ing chains, and stop­ping it would re­quire a mas­sive with­drawal.

Team Impact. Sometimes an­other org does some­thing that deeply af­fects your work. For ex­am­ple, be­cause Perfetto (the per­for­mance tool I work on) has users through­out Google, some­times a team will ask us to sign off on a very com­plex in­te­gra­tion. This is a clas­sic risk: if things go right, they get the credit, but if things go wrong, your lead­er­ship might ex­pect you to help solve a prob­lem you did­n’t cre­ate. In these cases, the pay­off of speak­ing up is high be­cause you are pro­tect­ing your team.

Company Scale. Finally, con­sider the blast ra­dius. Some pro­jects are self-con­tained; if they fail, they only take them­selves down. Others are so in­ter­twined with core sys­tems that their fail­ure causes wide­spread dam­age or cre­ates tech­ni­cal debt that per­sists for years. These can be deadly to the long-term health of a pro­ject.

It’s also not just about when you put your opin­ions for­ward but how you do it. There’s a very wide range of ac­tions you can take de­pend­ing on what you’re fac­ing.

The nu­clear op­tion is to di­rectly say “we should not do this” and try to shut the pro­ject down. This al­most al­ways re­quires es­ca­la­tion to your leads and the leads of the own­ing team, re­quir­ing great con­vic­tion in both the fact that you’re right and that this pro­ject will be ac­tively harm­ful. But on some oc­ca­sions, this is the right thing to do, es­pe­cially if the cost of not say­ing some­thing can be ex­is­ten­tial to your pro­ject or team.

A slightly softer but still quite risky vari­ant of this is, in­stead of do­ing a di­rect es­ca­la­tion, you raise con­cerns in di­rectly with the team. Usually this is done with a meet­ing with the team or a strongly worded “concern” or “rebuttal” doc. The goal is to speak in strong enough terms that the team them­selves con­clude that this the pro­ject might not be a good idea.

Then there are the smaller in­ter­ven­tions, nudg­ing things in the right di­rec­tion. These are per­fect for when a team is about to do some­thing that makes sense from a high level but they are go­ing about this the wrong way. I see this of­ten with Perfetto: a team sends a de­sign doc propos­ing a com­plex use of Perfetto that I know will cause them pain later. I sit down with them, un­der­stand their ac­tual prob­lem, and guide them to a bet­ter so­lu­tion. It costs an hour but saves them months. If you do it right, you can even be seen as a helper rather than a hin­drance, even if you do slow down the team.

Sometimes you con­clude that the ROI just is­n’t there to do any­thing di­rect: the po­lit­i­cal mo­men­tum is too strong, or the is­sue is too small to jus­tify spend­ing any in­flu­ence. At this point, what you do de­pends on how much your team is in­volved.

If it over­laps with your team’s work heav­ily then it might be best to make some sub­tle con­tin­gency plans: re­duc­ing your de­pen­dency on it or build­ing ab­strac­tions to cope if it goes away. There is also a long game trick here. Even a bad pro­ject usu­ally has an “essence” of a good idea, a spe­cific prob­lem it was try­ing to solve or an in­sight it was based on. If it fits with your job, it’s of­ten a good idea to take that essence and see if you can nat­u­rally in­cor­po­rate a bet­ter ver­sion of that spe­cific so­lu­tion into your own pro­ject. That way, if the bad pro­ject stalls or gets can­celed, you can be proac­tive in­stead of re­ac­tive to the fall­out.

Alternatively, if you’re not in­volved, it’s easy: just stay out of the pic­ture. Vent to friendly col­leagues in pri­vate, com­mis­er­ate, but in pub­lic, live with the re­al­ity.

Finally, you must man­age your own team through the process. If you can see the flaws in a pro­ject, other se­nior en­gi­neers prob­a­bly see them too. Don’t try to gaslight them or “walk the com­pany line” by pre­tend­ing a bad pro­ject is ac­tu­ally good. It de­stroys trust.

Instead, be hon­est about the facts on the ground with­out go­ing into un­nec­es­sary po­lit­i­cal de­tails. Tell them that you will do the best you can un­der these con­straints.

So what did I tell my mentee? “I’ve learned that be­ing right and be­ing ef­fec­tive are dif­fer­ent things. I could go tell them my con­cerns. They prob­a­bly would­n’t lis­ten. I’d burn some good­will. And in six months, no­body will re­mem­ber that I called it, they’ll just re­mem­ber I was the guy who tried to block their work”.

When you’re ear­lier in your ca­reer, you want to be­lieve that good ideas win on merit, that if you just ex­plain clearly enough, peo­ple will see rea­son. It took me quite some time to ac­cept that big com­pa­nies don’t work that way.

But this does­n’t mean you stop car­ing. It means you get strate­gic about when to spend your cred­i­bil­ity. Pick the bat­tles where you can ac­tu­ally change the out­come, where your team will be hurt if you stay silent, where the cost of be­ing wrong is low but the cost of the pro­ject fail­ing is high.

And for every­thing else? You vent to col­leagues, you make quiet con­tin­gency plans, and you watch. Sometimes you learn some­thing. Sometimes you’re wrong and the pro­ject ac­tu­ally works. And some­times you get to feel that grim sat­is­fac­tion of pre­dict­ing ex­actly how things would fall apart.

None of this is as sat­is­fy­ing as fix­ing every­thing. But it works and keeps me sane.

In an up­date re­port, the US National Transportation Safety Board (NTSB) re­vealed that cracks found in the en­gine mount­ing as­sem­bly had pre­vi­ously oc­curred on sev­eral other air­craft.

The plane briefly lifted off from the run­way, be­fore hurtling out of con­trol into an in­dus­trial area. Fifteen peo­ple died as a re­sult, in­clud­ing three crew and 12 on the ground.

The MD-11F freighter op­er­ated by UPS, crashed af­ter one of its en­gines sep­a­rated from the wing as it was prepar­ing to take off from Louisville.

An air­craft that crashed in flames in Kentucky in November had a struc­tural flaw that had been iden­ti­fied by Boeing on sim­i­lar planes 15 years ago, ac­cord­ing to in­ves­ti­ga­tors.

In an up­date re­port, the US National Transportation Safety Board (NTSB) re­vealed that cracks found in the en­gine mount­ing as­sem­bly had pre­vi­ously oc­curred on sev­eral other air­craft.

The plane briefly lifted off from the run­way, be­fore hurtling out of con­trol into an in­dus­trial area. Fifteen peo­ple died as a re­sult, in­clud­ing three crew and 12 on the ground.

The MD-11F freighter op­er­ated by UPS, crashed af­ter one of its en­gines sep­a­rated from the wing as it was prepar­ing to take off from Louisville.

An air­craft that crashed in flames in Kentucky in November had a struc­tural flaw that had been iden­ti­fied by Boeing on sim­i­lar planes 15 years ago, ac­cord­ing to in­ves­ti­ga­tors.

At the time the man­u­fac­turer re­spon­si­ble for the air­craft, Boeing, con­cluded that the is­sue “would not re­sult in a safety of flight con­di­tion”.

The MD-11 is a rel­a­tively el­derly de­sign that was orig­i­nally pro­duced by McDonnell Douglas. Boeing ac­quired the com­pany in 1997.

The last MD-11 came off the pro­duc­tion line in 2001, but Boeing has con­tin­ued pro­vid­ing parts and ser­vice sup­port.

In the af­ter­math of the Kentucky dis­as­ter, the NTSB is­sued a pre­lim­i­nary re­port which drew at­ten­tion to cracks in the en­gine at­tach­ment mech­a­nism. Its lat­est up­date goes fur­ther, de­scrib­ing frac­tures due to ev­i­dence of “fatigue” — or re­peated stresses - in a crit­i­cal bear­ing, as well as the mount­ing it is meant to sit in.

It points out that Boeing had pre­vi­ously found fail­ures of the same part on four oc­ca­sions, af­fect­ing three dif­fer­ent air­craft. In 2011, the com­pany sent a “service let­ter” to op­er­a­tors warn­ing them of its find­ings. This is a non legally-bind­ing doc­u­ment used to alert op­er­a­tors about im­por­tant safety or main­te­nance in­for­ma­tion.

In this case, Boeing rec­om­mended that the part be in­cluded in a gen­eral vi­sual in­spec­tion every five years. It also pointed out changes to the in­spec­tion pro­ce­dure con­tained in the air­craft main­te­nance man­ual, and drew at­ten­tion to a re­vised bear­ing as­sem­bly that could be fit­ted — al­though this was not manda­tory.

Tim Atkinson, a for­mer air ac­ci­dent in­ves­ti­ga­tor who now works as an avi­a­tion safety con­sul­tant, said the NTSB’s up­date made dis­turb­ing read­ing.

“The struc­ture con­cerned is not dec­o­ra­tive, it’s an es­sen­tial part of the mech­a­nism that at­taches the en­gine to the wing, and car­ries loads such as thrust and drag,” he ex­plained.

“It’s ex­tra­or­di­nary that Boeing con­cluded that a fail­ure of this part would not have safety con­se­quences,” he claimed.

Boeing’s in­ter­nal processes have come un­der fire on a num­ber of oc­ca­sions in re­cent years.

Criticisms have fo­cused on how the de­sign of its 737 Max in­cluded flawed soft­ware that was im­pli­cated in two ac­ci­dents, in 2018 and 2019, that to­gether cost 346 lives.

Quality con­trols in its fac­to­ries have also come un­der scrutiny, af­ter a door panel fell off a brand new 737 Max shortly af­ter take-off in early 2024.

In a state­ment, Boeing said: “We con­tinue to sup­port the in­ves­ti­ga­tion led by the NTSB. Our deep­est con­do­lences go out to the fam­i­lies who lost loved ones and our thoughts re­main with all those af­fected.”

The NTSB’s in­ves­ti­ga­tion is con­tin­u­ing. It has not yet is­sued any firm con­clu­sions about the cause of the ac­ci­dent, and is un­likely to do so un­til it pub­lishes its fi­nal re­port.