10 interesting stories served every morning and every evening.




1 542 shares, 31 trendiness

A high quality TTS that gives your CPU a voice

...

Read the original on kyutai.org »

2 470 shares, 27 trendiness

راهنمای کاربری Briar

...

Read the original on briarproject.org »

3 411 shares, 17 trendiness

The Palantir App ICE Uses to Find Neighborhoods to Raid

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.

...

Read the original on werd.io »

4 400 shares, 17 trendiness

The Long Now of the Web: Inside the Internet Archive’s Fight Against Forgetting

...

Read the original on hackernoon.com »

5 336 shares, 23 trendiness

OpenBSD-current now runs as guest under Apple Hypervisor

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.]

...

Read the original on www.undeadly.org »

6 290 shares, 12 trendiness

Claude is not a senior engineer (yet)

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 AWSs 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 AWSs 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!

...

Read the original on www.approachwithalacrity.com »

7 262 shares, 65 trendiness

Just the Browser

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.

...

Read the original on justthebrowser.com »

8 255 shares, 12 trendiness

Instant Linux Boxes via SSH

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

...

Read the original on shellbox.dev »

9 237 shares, 12 trendiness

Why Senior Engineers Let Bad Projects Fail

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 VPs 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 VPs 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.

...

Read the original on lalitm.com »

10 208 shares, 15 trendiness

Boeing knew of flaw in part linked to UPS plane crash, report says

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 NTSBs 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 NTSBs 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.

...

Read the original on www.bbc.com »

To add this web app to your iOS home screen tap the share button and select "Add to the Home Screen".

10HN is also available as an iOS App

If you visit 10HN only rarely, check out the the best articles from the past week.

If you like 10HN please leave feedback and share

Visit pancik.com for more.