sa46

That reason is no worse than the inverse reasoning: gleefully supporting the investigation because it threatens Google's future.

Also, I think the reasoning is independent of the specific situation. Working at $PLACE could benefit the poster. So the poster wants to see $PLACE continue to have a bright future. Seems like a standard argument for capitalism and the free-flow of human capital to better jobs.

I understand there are externalities that affect this specific situation, hence the investigation, but since it's not clear there's antitrust behavior, it seems premature to classify the reasoning as bad.

> have written negative things is not particularly relevant

I disagree. Everyone has a bias or agenda. It's useful to know what they are. Hence the common HN trend of including "Disclaimer: I work for $relevantThing". Isaac's book summary leads with: "A New York Times technology correspondent presents the dramatic rise and fall of Uber." He clearly has an agenda. If Uber does well, his book and its prediction of Uber's demise will be wrong.

Looking at the Isaac's NYT titles and summaries (https://www.nytimes.com/by/mike-isaac), the GP has a point. None of the articles are positive. That said, I think it'd be difficult to find anyone praising Uber over the last few years.

- How Uber Got Lost

The once-swaggering company is losing more money and growing more slowly than ever. What happened?

- Two Top Uber Executives Are Out as CEO consolidates power

A month after Uber’s rocky I.P.O., its chief executive laid off two members of his executive team: the chief operating officer and the chief marketing officer.

- How the Promise of a $120 Billion Uber IPO Evaporated

- Uber's Stock Disappoints, Capping a Rocky Path to Its IPO

- Uber IPO is Expected to be Priced at Midpoint

- With Uber's IPO, Dara Khosrowshahi Is Taking Travis Kalanick's Company Public

The C.E.O. wants to prove that the start-up has evolved past a raucous, and profligate, tech-bro culture. But Uber’s past is simply not that far gone.

A fun thought experiment: how would you go about incentivizing the clients who hire web developers to create fast loading pages but still have Javascript functionality? More importantly, who is in a position to incentivize clients who care more about tracking and marketing than performance?

> since law enforcement has (successfully!) argued that they have no legal duty to serve and protect you

IANAL. My understanding is police have a duty to the public at large, not to an individual person outside of a special relationship (i.e. witness protection). If the police did have a duty to individuals, the state would be unable to allocate police resources to best serve the public. Essentially, individual priorities would DDOS police resources. In the case you reference:

> a government and its agents are under no general duty to provide public services, such as police protection, to any particular individual citizen. [...] A publicly maintained police force constitutes a basic governmental service provided to benefit the community at large by promoting public peace, safety and good order. [...] Publicly furnished police protection may accrue to the personal benefit of individual citizens, but at all times the needs and interests of the community at large predominate.

It's the biggest by relative percentage difference but in absolute terms it's second to salary. I'm not sure it's a useful measure. It exaggerates the effect when one number is small as seen with autonomy. I agree with GP, it looks peculiar.

Inclusive workplace has an absolute difference of 10% but has a relative difference of 171%.

Salary has an absolute difference of 15% but has a relative difference of 43%.

Presumably the relative difference for flat organization (0% and 2%) would be larger.

Ada was the intro programming language at my college and I have a soft spot for it.

> prevent things like race conditions

Rust can prevent all data races but not all (any?) race conditions. Related question: can you use the type system to catch a subset of race conditions?

https://stackoverflow.com/questions/49023664/could-software-...

The compression technique to achieve the 11x compression ratio is pretty clever and is detailed in the Gorilla TSDB paper. Timestamps are encoded with a delta of delta encoding scheme which allows 96% of all timestamps to compress to a single bit within a compressed block.

Gorilla paper: https://cs.brown.edu/courses/csci2270/papers/gorilla.pdf

Somewhat off topic, how would one go about getting good technical editing for something like a blog post or for a book like the OP? Is it expensive?

Used to be a Googler and worked on an ACL model built on top of Zanzibar. I didn't work directly on Zanzibar so listen to ruomingpang over me.

> 3. There's nothing Zanzibar can do but "pointer chase", resulting in a large number of serial ACL checks?

Zanzibar enforced a max depth and would fail if the pointer-chasing traversed too deeply. Zanzibar would also fail if it traversed too many nodes.

> 4. How do clients consistently update ACLs alongside their "reverse edges"?

One of the recommended solutions was to store your full ACL (which includes a Zookie) in the same Spanner row of whatever it protected. So, if your ACL is for books, you might have:

    CREATE TABLE books (
      book SERIAL PRIMARY KEY
      acl ZanzibarAcl
    );

Alternately, you could opt to only store the current zookie instead of the full ACL. Then the check becomes:

1. Fetch Zookie from Spanner

2. Call Zanzibar.Check with the zookie

> but how do I consistently view which groups a user is a member of?

I remember this as a large source of pain to implement. Zanzibar didn't support this use-case directly. As rpang mentioned in a sibling comment, you need an ACL-aware index. Essentially, the algorithm is:

1. Call Zanzibar.Check on all groups the user might be a part of.

There's a bunch of clever tricks you can use to prune the search space that I don't know the details of.

If wikipedia is any indication, it doesn't work without plastering the top half of the screen begging for a donation.

I understand your point but to be fair, if we cherry pick all the terminology from React it also looks bad:

JSX, components, props, context, error boundaries, forwarding refs, fragments, higher-order components, container.

Once you add in concepts from the other libraries commonly used with React like mobx or redux I think the comparison isn't as clearcut.

> you're doing that while simultaneously claiming to represent a huge and varied field with absolutely no cited sources for that claim

I suspect it was phrased strongly because the GP made the same claim in the opposite direction: "Most software is grounded in an open source development and deployment tool chain".

Full list of occupations ranked by fatal injuries per 100k workers. The referenced article isn't that useful because it doesn't provide any numbers to do an absolute comparison.

                                           Fatal injuries per
  Rank  Job                                100k workers
  ====  ===============================    =================
  1.    Fishers                            100.0
  2.    Logging workers                     87.3
  3.    Aircraft pilots                     51.3
  4.    Roofers                             45.2
  5.    Refuse material collectors          34.9
  6.    Steel workers                       33.3
  7.    Truck drivers                       26.9
  8.    Farmers, ranchers                   24.0
  9.    Groundskeeping workers              21.0
  10.   Electrical power-line installers    18.6
  11.   Misc agricultural workers           17.7
  12.   Construction workers                17.4
  13.   Helpers, construction trades        17.3
  14.   Maintenance and repair workers      16.6
  15.   Grounds maintenance workers         15.9
  16.   Construction laborers               14.3
  17.   Mechanics                           13.1
  18.   Police                              12.9
  19.   Construction equipment operators    11.8
  20.   Mining machine operators            11.7
  21.   Taxi drivers                        10.5
  22.   Athletes                             9.5
  23.   Painters                             8.9
  24.   Firefighters                         8.9
  25.   Electricians                         8.4

> Elite-level women can beat 90% of all men.

I was curious about this so I looked at the percentiles for the Boston Marathon since the data is readily available.

Roughly speaking, the top 1% of women times lines up with top 10% for men so the data backs up your statement. After that, there's a pretty consistent 20% difference.

    %           Male Female
    0.00 02:09 02:21
    0.01 02:38 03:03
    0.10 03:00 03:27
    0.20 03:12 03:37
    0.30 03:22 03:45
    0.40 03:31 03:53
    0.50 03:41 04:00
    0.60 03:51 04:10
    0.70 04:04 04:22
    0.80 04:22 04:39
    0.90 04:50 05:05
    0.99 05:50 05:56
    1.00 07:58 07:19

Kaggle link: https://www.kaggle.com/jschaf/kernel3166aa9b08

In the ballpark of 140.

Depends on the company. At our 6 year old startup, email is dead except for external communication. Everything is on slack including ops, stand ups and informal communication. At Google, hangouts was lightly used but everything was on email.

I see, the argument is that monorepo facilitates tight-coupling because it's easy to add dependencies. The multi-repo doesn't have the same problem because it's more difficult to have cross module dependencies.

There's a number of solutions to prevent tight-coupling.

1. Language-level visibility modifiers. 2. Build system visibility. Bazel offers fine-grained visibility. I'm not sure about others. 3. Using RPCs as the primary interconnect between services.

My view is that disadvantages of tight-coupling in a mono-repo is a much better problem to have than the disadvantages of having logic spread across different repos.

I don't understand how avoiding bitrot is better in a multi-repo setup. With a multi-repo, if you're changing a core-library you can make the change quickly but you can't upgrade clients until they upgrade on their own. You still have bitrot. The difference is that the bitrot isn't visible because it's compartmentalized into separate repos.

> Imagine, for example, the vast public good that would arise from Google or Microsoft opening up their entire code bases for free.

Why stop with code? If code is always better in the open, then why not require all business communication in the open.

> in any business there exists a tension between private profit and public good

I don't think there is always a tension. If not by profit, how do you motivate people to develop new technology and fund the support system necessary for development?

> that's because businesses act unethically -- ie, for private profit over public good

Are you suggesting it is morally wrong to earn a profit if it would better serve the public good? How and more importantly who defines public good? A major theme from The Wealth of Nations refutes your point by arguing that the greatest economic benefit occurs when people act in their own self-interest:

> It is not from the benevolence of the butcher, the brewer, or the baker that we expect our dinner, but from their regard to their own interest.

It sounds like you're arguing for a socialism model where a central authority decides how to use capital.

I left Google about a month ago and use Github now. Things I miss:

- the ability to batch all comments in a single send. GitHub has the problem where replies are immediate and don’t necessarily represent the PR state.

- built-in fixes and lints that show up as comments

- the ability to diff between snapshots instead of losing all previous context every force push to a Github PR.

- Github’s diff is really bad for code moving or changing indentation.

- auto submit if tests pass and you have an lgtm. It’s frustrating having to wait for tests that will probably pass.

So 1 full time software engineer on open source projects? Looks like they vastly exceed that already https://aws.amazon.com/opensource/

> Entirely non-surprising that devs are the ones who left because by hard capping their pay you are reducing their reluctance to go work somewhere else with higher pay.

The surprising part is that their dev retention (article notes small sample size) of ~3 years matches Google at 3.1 years and surpasses Uber, Dropbox, Tesla, Facebook and Airbnb. [1] That suggests that the culture created by the one-salary experiment increases the motivation to stay enough to offset the incentive to leave.

[1]: https://www.businessinsider.com/average-employee-tenure-rete...

I think most of the suggestion aren't realistic. You can project the same desire for customizability to any software product. For Hacker News:

- Let me configure the order of posts based on voting patterns (hot, newest, controversial)

- Let me adjust the weighted score of posts based on the age of the account.

- Let me configure the home page.

> Let me replace the recommender entirely with something of my own devising, called back through a webhook.

Is there any popular consumer product that allows custom recommendation based on a webhook? Opening up a core part of your product to an untrusted and probably unreliable third-party is not a good idea.

> why am I stuck with their recommender that only cares what it thinks will cause me to spend the most time on YouTube.

This is addressed by the article:

> The first is this notion that it’s somehow in our interests for the recommendations to shift people in this direction because it boosts watch time or what have you. I can say categorically that’s not the way that our recommendation systems are designed.

One of the more interesting facts about Rogers' Rangers is that they fought for the Crown in the American Revolution. It's a tad ironic that the we named our premier light infantry after them.

The submission differs from the U.S. Army Ranger School Handbook [1] (PDF - page 2). The Ranger school variant is more down to earth.

> The Rangers still use these rules today.

Sort-of. The rules are still used in the same sense that Algol-68 is still used. It's not, but all the lessons are incorporated to into modern programming languages. If you're intereseted, the tactical doctrine for the U.S. Army is freely available as "Infantry Rifle Platoon and Squad" [2] (WARNING - large PDF). [3] (unofficial HTML version)

Here's the modern day interpretation for some of these rules:

> 2. In a small group, march in single file with enough space between so that one shot can't pass through one man and kill a second.

Everything is dependent on the mission variables, but you generally keep at least 5 meters in-between soldiers so a grenade can only kill 1 person and so it's harder for a machine gun to pin down multiple people.

> 4. Before reaching your destination, send one or two men forward to scout the area and avoid traps.

This is a leader's recon. Before conducting the attack, the leader will recon the objective to confirm that's it's actually the objective, verify enemy strength and scout out locations for machine guns and the main assault force. The leader's recon is on page 326 in [1].

> 13. When laying in ambuscade, wait for the enemy to get close enough that your fire will be doubly frightening, and after firing, the enemy can be rushed with hatchets.

This is a near-ambush. Ideally, you set this up as L-shaped ambush to achieve enfilading fires in the kill-zone. The "doubly-frightening" is initiating the ambush with a Claymore mine or an AT4 rocket. The "rushing with hatchets" is clearing the objective, taking prisoners and collecting intelligence. See page 7-10 in [1] for the step-by-step guide on how to conduct an ambush.

> 14. At a campsite, the sentries should be posted at a distance to protect the camp without revealing its location. Each sentry will consist of 6 men with two constantly awake at a time..

The minimum security at night is 33% and is bumped to 100% at dusk and dawn. The campsite would be a patrol base, usually arranged as a triangle with machine guns at the vertices.

> 16. Upon discovering a superior enemy in the morning, you should wait until dark to attack, thus hiding your lack of numbers and using the night to aid your retreat.

It is really difficult to fight at night, even with night-vision goggles. This is one of the primary advantages of first-world armies in a tactical setting.

> 19. Avoid using regular river fords as these are often watched by the enemy.

These are called linear danger areas and include roads, dirt paths and streams. See [4] for how to cross them.

[1]: http://www.milsci.ucsb.edu/sites/secure.lsit.ucsb.edu.mili.d... [2]: https://armypubs.army.mil/epubs/DR_pubs/DR_a/pdf/web/ARN1384... [3]: http://www.infantrydrills.com/ [4]: http://www.infantrydrills.com/fm-3-21-8-chapter-3-section-v-...

> Static typing is an ideology, almost a religion

Dynamic typing is also an ideology by your definition. The ideology is that you must never add static types to your source code.

> Because static typing could be easily left as an optional choice throughout the code base but no mainstream statically type PL I know of leaves it optional.

I thought TypeScript, Flow, and Python 3 (MyPy) all support optional static typing. Plus, most languages have an escape hatch to treat an object as untyped or as a general type.

>"See! A static type would have fixed this issue." and then from there conclude that static typing is a good idea.

Why is that not a good conclusion? In the context of the article, static types would have prevented 38% of bugs at Airbnb.

I agree with the sentiment but I'm not so sure about 100% and calling it night and day is exaggerated. I've had anecdotes both ways. I think there's some important factors to consider:

- Units send their best enlisted folks to become officers.

- For entry officer jobs like a platoon leader, the prior enlisted will have a massive knowledge advantage. Once an officer hits company command (~5-6 years), I'd say the difference evaporates as the focus should be at a higher level.

Some of the downsides of prior-enlisted officers are:

- Leaning to much on their experience and micromanaging enlisted subordinates.

- Focusing on low-level details rather than "officer-business" like long term training plans and orders preparation.

For an no-nonsense analysis of the battle of Alesia, see https://www.youtube.com/watch?v=SU1Ej9Yqt68 on the Historia Civilis channel.

Congrats! Google is still fantastic. You'll have a blast and learn a ton.

Sidenote, anyone have an extension to hide all HN headlines with a keyword filter?