YouWhy

TL;DR: There're few global incentives for a LinkedIn app developer to make an overall good app, as opposed to making their PM happy.

In detail: This is how death by a thousand papercuts looks like.

I've had the (dubious) pleasure of observing a roughly similar BigTech app project.

There are likely 100s-1000s of app developers involved in the LinkedIn app, and they are likely under immense pressure to Just Ship Already (tm). Some of them consider it conscionable to do weird things like statically linking to an asset library - whether through unawareness/incompetence or just by wanting to make it through the next performance review.

In smaller projects, there's some kind of a feedback that can make it through the system to make sure local and global incentives are aligned, but at the LinkedIn scale that would have required the people in charge to be engineers and not suit types.

One interesting solution to this very problem that I actually saw in action was employing a team of top-tier systems hackers (in this case: people with a security research background) to hack through the build process. This solution naturally premises on such individuals wanting to work for an app project, incentivizing them along the right global metrics and giving them the go ahead to push back on egregious violations.

The article is well written, but I am annoyed at the attempt to gatekeep the definition of a filesystem.

Like literally any abstraction out there, filesystems are associated with a multitude of possible approaches with conceptually different semantics. It's a bit sophistic to say that Postgres cannot be run on S3 because S3 is not a filesystem; a better choice would have been to explore the underlying assumptions; (I suspect latency would kill the hypothetical use case of Postgres over S3 even if S3 had incorporated the necessary API semantics - could somebody more knowledgeable chime in?).

A more interesting venue to pursue would be - what other additions could be made to the S3 API to make it more usable on its own right - for example, why doesn't S3 offer more than one filename per blob? (e.g., a similar to what links do in POSIX)

The scenario at hand is data leakage; accordingly the prevention strategy is by having a more secure storage system.

One way of addressing that is by using a secure vault for sensitive data storage. This is beyond the skillset of most backend engineers, but new products such as Piiano may bridge the gap (proper disclosure: I'm a friend of one of the people behind Piiano)

The most useful construct I am aware of that I wish became more popular in backend languages is strongly typed tree literals. (Introduced by Meta in Hack as "XHP")

Consider this pseudocode expression:

:Div{Hello :Span(style='bold'){world}} # expression type: HTMLDOMNode.Div

This is immensely powerful and saves a ton of time/bugs especially when compared to the alternative of string interpolation.

I know somebody once did XHP on Python, but regrettably this work was abandoned.

My reading of the text is as a foreigner's critique of the American trope of asserting an ideal purpose to everything.

An example from my own experience: an org leader proclaiming the need for "laser sharp focus". Amigo, you're running an organizational metrics p-value hacking campaign, which is by definition not a "focused" play. Could have said something useful like "let's be effective about our experimentation", but no, you must go through the motions of blabbering as if you're an action movie hero.

I think we have a case of survivorship bias.

A considerable majority of the science-non-SWE crowd are de facto incapable of writing more than 100 lines of runs-in-my-notebook code.

Hence, if a change/bug is necessary, it is much likelier to fall under a SWE jurisdiction, and hence is much more likely to be industrial code.

Add to that a further confounder (tiptoeing a "no true Scotsman" here): academia is not a first choice of workplace for strong SWEs.

Design iteration is typically a long tail phenomenon - new issues keep coming up as the system (car) faces new scenarios.

Even a high-resource prototyping program can only go so far with scenarios like - wear and tear/part fatigue, adverse environmental conditions, local peculiarities (e.g. regulatory requirements for uncommon configurations), unintended but common maintenance mistakes etc.

For example, a Fiat car my family owned suffered a cascade drivetrain failure after about 9 years on the road. I don't think a prototyping program could have captured that ahead of time.

The fact that the showroom RR parts look fine only indicates that the parts are ok immediately after manufacturing; it does not promise they'll work fine after several years even if treated will.

I would not expect RR to be particularly high quality, due to:

1. Small production batches,

2. Low typical usage - most RR owners do not use it to commute on a daily basis, hence do not face high reliability requirements,

3. The ability of the typical buyer to overspend on maintenance, whether preemptively or on-demand.

I'm yet to see a single business case of money entering the QC value chain outside of (a) other QC businesses and (b) moonshot investments.

After ~15 years of literally the world's smartest people trying to come up with exactly that (some of which are dear friends), the only way conscionable way I can regard QC is as a vapor bubble.

I think the OP (hat off!) needed a way to transfer data to the front-end of another application. Since there's no back end involved, the only available channel is the request URL

Quite the opposite.

Piracy (more precisely: systematically and arbitrarily attacking vessels in the open seas) is not considered legitimate for any government - not the US, not China and certainly not Israel. The violation of this rule by itself is grounds for war by the injured governments (which, by the way include most of the EU and the US).

The extraordinary claim here is exempting the Houthi extreme actions from the rule of not practicing piracy just because they are hostile to Israel.

The above line of thought also begs the question of what other extreme actions are supposedly justifiable if the perpetrator happens to be hostile to Israel. Is it a get-out-of-jail card of some kind?

> deliver "enough" food and medicine to people in gaza?

You assert that this case of piracy is driven by noble causes, as opposed to literally any use of force by any government in human history.

Assuming that the Houthi demands are complied with, what should prevent the Houthis from using their military force to promote other causes, perhaps less noble, like enriching their own leaders (a.k.a., privateering and collecting ransom)?

With respect to Chan Zuckerberg Science:

As an engineer who had worked for a number of years in biotech and med-tech, I find fault with the underlying assumption that one can build an organization out of bio-PI types and get anything out of it beyond a bunch of papers.

My hard-earned experience is tha the biology PI track selects against the technocratic leadership style necessary for the coordination of a large-scale effort.

My own stint in the field found most value with a small subset of fresh PhDs who were still mentally flexible enough to figure out how to do their research in a stackable and incremental way.

Unsurprisingly, most of these people stood very little chance of being hired as PIs, because their focus on efficiency made for worse short-term splashing.

Thank you for the clarity and precision of your writeup.

The organization you described exhibits a fundamental attitude of learned helplessness when it comes down to software development, as opposed to operations (tech or otherwise).

I saw this pattern in various manifestations across the board, and it frequently boils down to an inability to trust engineers and their leaders.

As an engineering leader, I wonder what kind of a culture shift needs to happen around the business-tech interface to make waste of this kind not as frequent.

The IDF is a negligible source when it comes to reporting on Israeli civilian casualties.

The tally of multiple hundreds of civilians murdered is easily verifiable - for about 400 civilians, names have been published [1].

One reason for the considerable delay in victim identification has been the burnt and fragmentary state of recovered human remains. This has been reported by dozens of forensic workers, including Dr. Chen Kugel, head of Israel's Institute for Forensic Medicine. [2]

A piece by a social worker published a day ago at Haaretz casually mentions a meat truck filled with children's bodies at the triage site, in particular mentioning the remains of a fetus. [3]

[1] https://www.haaretz.co.il/news/2023-10-12/ty-article-magazin...

[2] https://www.i24news.tv/en/news/israel-at-war/1697531028-they...

[3] https://www.haaretz.co.il/opinions/2023-10-19/ty-article-opi...

0. Realistically, any mature MFA app needs to have a cloud backup option enabled by default.

1. Google did not message their induction of Authenticator cloud backups as having a massive impact on their clients' vulnerability surface.

2. It appears a bit from the post-mortem that Retool was considering itself as a SW company, rather than a security-critical infrastructure provider.

3. All of that adds up to - organizations that have much to lose from a compromise need to do their own security thinking and assessment. Corporate-style thinking along the lines of "if it has an enterprise offering, it must be up to scratch" was never enough, and it will never be.

Marie Curie died of acute aplastic anemia [1], at age 66, after decades of working with radioactive materials and operating an unshielded X-ray machine thousands of times during World War I.

While long term radium exposure has been known to be hazardous by the 1930s, and Curie's work had been suspected at the time to have affected her health, I estimate that contemporary thinking would have been to avoid exposure to radium.

Conversely, I do not think that acute exposure to radiation happened enough before World War II to have any kind of safety thinking around it.

[1] https://en.m.wikipedia.org/wiki/Marie_Curie

TL;DR: Good step for the entire market, productization is the harder problem.

I had been formerly involved with Kemtai, which built a fantastic physical therapy/fitness experience (in my biased view) using motion tracking.

If anyone's interested, it is running well and quickly over WebGL on a pretty impressive share of regular phones and laptops across all platforms with WebGL (not just Apple)

My learnings is that the hard part is the productization on top of motion tracking: what constitutes an exercise? What is a "good" performance? How to build the authoring workflow for the many hundreds to low thousands of exercises necessary to reach a typical user base?

In any case, that's awesome news. There are literally billions of people whose condition is going to be better via motion tracking based health and fitness. May it grow there, and quickly!

Proper disclosure: I had been formerly involved with them.

Try Kemtai.com.

There's a demo section at https://app.kemtai.com/sample-workouts

We took workout experience super seriously, and in my biased view, got it to be a usability joy.

You're fully right! I added them both - E.A. was the original toolmaker, and A.S. worked more down the chain. He definitely was the person who walked me through the finer points of retrieving the data.

Wow! So this is actually a drama I had a secondary role in.

A few remarks:

1. Team: Nitzan (the blog author, and an awesome dude!) was at the time the Production Engineer monitoring the top-line capacity metrics. The Java heapdump tooling was hacked together by E.A., with some tough bits by A.S., who's a force of nature. The bulk of the mitigation was carried out by Y.B. over several months. I was the person who analyzed a couple of memory dumps and framed URL strings as a worthwhile 80/20 goal.

2. The main difficulty in the mitigation project was that the pathological strings were accessed over hundreds of callsites using some semantics like

semanticallyUsefulURL = decodeURLString(urlStoredInStringForm)

What Y.B. ended up doing was

2.1. A lengthy build-up very carefully constructing an API to represent URLs in as compact a way as possible, and plugging it in where convenient,

2.2. Carrying out a massive automated rewrite at the source level ("codemod"), which is possible in Java but not for the faint of heart. I think he used some JetBrains tooling to get that going. I consider his work a tour de force.

I vaguely recall there being some modest CPU improvements in the process.

3. Organizational dynamics: the codebase was originally written by very competent people who did not work through that specific detail because it was not important for their original use case. However subsequently the code underwent several years of almost solely rewarding improvement in end-user metrics, leading to an overall inadequate state that was hurting the organization as it was hitting hard scaling limits. In fact, "engineering excellence" was not even a category for recognition at that time. In this climate I could not find my own voice as a SW professional and chose to quit after a little bit more than a year.

I have a pretty good memory, I'd be happy to give more context if appropriate, just ping me.

(Edited - added one more due prop!)

I am trying hard to see who could be the target audience for such a thing.

My best guess is engineers who are not currently employed, but who would like to up specifically their Oracle skills, as opposed to other valuable alternatives like Postgres.

Am I missing something?

While the basic technique is sound, SQL recursive queries' no-side-effects character means a huge number of basic graph traversal strategies (e.g.: pruning, shortest path first/Dijkstra) are beyond reasonable engineering.

In addition to that, Postgres is difficult as a computational platform - the execution strategy for recursive queries is not necessarily intuitive, and their performance is hard to assess (for example: how soon will you run out of "stack"?)

While the "incompetent youth" trope is trite, I do feel we're past "peak learning curve" on systems for youth.

I think photography is even a better example than scanners: so many things that were super hard once are now literally point-and-click. However what was once an easy growth path now requires a large upfront investment, which most people pass on.

The unfortunate casualty is the hobby-ness of the occupation. If doing things requires so much premeditation, people start treating it as a job/chore, and lose an opportunity for joy. There's nothing wrong with that, but it is a shame.

Towards the end of my tenure in a team, a new boss instituted mandatory viewing sessions of Martin's training videos; I grew somewhat averse of them.

While the heart of Martin's teachings are about expressivity and semantics, the praxis is much more about recipes than about what matters to me as a professional, which is:

1. Well-definedness of the computation being done (in a mathematical sense of the word),

2. Engineering, that is establishing of a connection between human narratives about what the SW should do with the program's structure.

Overall, it seemed to me that Martin is first and foremost trying to sell to sell a certain paradigm of competency to corporate cookie-cutter-culture organizations.

My issues with this paradigm of competency are that:

1. Doing it properly requires a massive investment, which does not make business sense.

2. As is often the case, this paradigm makes it easy to feign competence without actually being competent, which is damaging to organizational trust.

Wow, a blast from the past! I first stumbled on these some time in the early 2000s.

During my stint in Big Tech, I would often times reflect how much of what I was seeing was an instance of:

> With sufficient thrust, pigs fly just fine.

I think of the difference more as a Kuhnian paradigm shift, rather than than as clan warfare.

The whole value chain changed. PSTN is a highly fragile, highly standardized, high expertise technology that was possible using very rudimentary but custom hardware.

IP telephony is essentially a repurposing of commodity IP connectivity, that uses modern commodity hardware (highly complex but well encapsulated) and requires a fraction of the personnel with a lot less years of expertise to work.

I think the name was a play on both "Ericsson Language" and the name of Agner Krarup Erlang, who pioneered queuing theory (before it was known as such) to address the fundamental question of inter-exchange capacity planning.

The unit "erlang", for "1 busy circuit/resource" is named in honor of that research.

https://en.m.wikipedia.org/wiki/Agner_Krarup_Erlang

I can't access the article due to the paywall, but I do have a take worth sharing.

I think there's a perfect synergy between:

1. Corporates being an immensely near sighted form of human interaction,

2. Creation of massive, high-maintenance assets when relevant labor and money was cheaper,

In the two senses above, core business software is not that different from e.g. the NYC train system or indeed virtually any other utility in the US.

I like where this is headed.

A lot of application frameworks have some kind of a security policy engine, but all of these invariably are inadequate - because modern policy management is about interfacing outside of systems, and that they don't do.

Exactly in the same way that load balancing should not be a part of an application framework, neither should authorization.

A coherent, formalized, well manageable policy engine can go a great deal for practical organization security