NickGerleman

PCHs give a sour taste in my mouth after working on a project which very liberally added commonly imported headers to a huge one. In practice, it meant each TU was indirectly including many more headers than needed, and it was harder for humans (or IDEs) to reason about the real dependency chain. While builds were faster, they also started using much more memory.

You also can end up needing to rebuild the world, if touching a header that is part of the PCH, even if it isn’t really needed by all the targets.

Modules and header units were supposed to solve these a lot more cleanly, but is still not well supported.

A company using React Native recently used bounties to solicit bug-fixes to RN issues their app was hitting.

A lot of positives came out of it, and it did improve framework quality. There are challenges with the model though. More changes than not are high quality, but some aren’t, or are just inherently risky, and it’s especially tricky to discern when first time contributors touch systems that might no longer have an active maintainer. Unlike someone employed full-time, there isn’t the opportunity to establish long term trust, and the contributor might not be around to support their change if something goes wrong.

A lot of changes fell through the cracks, or needed maintainer time that wasn’t there, which creates a bad situation where someone could have done great work, but isn’t getting paid. Knowing that someone is losing money if you don’t accept a PR can also trend towards guilt-inducing as a maintainer.

Beyond the other grains of salt, it seems awfully inorganic that the same user advertises this database 6 times as their only submission history.

It's a good question well above my pay grade :). Changing culture isn't an easy problem.

I suspect the way Microsoft does interviewing and performance management (very local to the specific team) contributes to the inconsistency.

MSFT has also been fairly open to its employees that it does not try to compete with competitors like Google, Meta, or even Amazon, in terms of compensation. So it isn't really trying to get the best engineers, so long as it can continue to print money.

There are still folks there who are incredible, but the floor is shockingly low at times. Folks will self-select, so you will then get teams which are more homogeneously good or bad.

I previously worked at Microsoft in an unrelated area, but had a friend who worked on CosmosDB, and later a different part of Azure.

There are some Microsoft products I genuinely love, but some are terrible. To an extent it is a reflection of the inconsistency in internal teams. Culture, values, skill level, and quality bar are all over the place depending on who you talk to, even compared to other large companies.

From what I had heard, CosmosDB was not a healthy team, and I would not consider using it as a product.

Code signing makes that pretty tricky. System DLLs will have integrity checks against msft certs.

How did Qualcomm get on the "naughty companies list"?

I haven't touched Ruby in a while, but are there any common multithreaded use cases? It seemed like the direction was to go multi-process for web workloads (E.g. with Unicorn).

I until very recently worked on Microsoft Word. The whole problem gets even more complicated when you add support for richer content like formatting, images, comments, etcetera. Sprinkle in requirements for things like three-way merge, simultaneous editing from multiple authors, undo behavior on top of that, and the amount of cross-cutting complexity for something seemingly simple can be absolutely astonishing.

I work on Office and am glad someone brought up this point. Writing a C++ business logic layer is probably too much for a simple CRUD style app, but the equation changes once the view/platform layers are a tiny minority of the logic in your app.

I’m a bit surprised Chrome developers went the route of an in memory filesystem instead of trying to sandbox and clear real disk access. Silently using up to 120MB without realizing sounds pretty bad.