> Having half of the company’s engineers enmeshed in an endless loop of proposing changes and being told no was totally fine - they didn’t need to be productive anyway, and this way they weren’t impacting business-critical systems.
There are many stories of FAANG hiring during that era for the purpose of denying talent to competitors. But now that you hired them, what will they do? And how will you keep them from creating problems?
It sounds cynical in retrospect; at the time the same set of facts were explained differently, in a way that didn’t hurt people feelings.
At the FAANG I was at, we were pushed to interview interview interview, and the company tripled in size in two years.
We constantly questioned the motive for more engineers, when we had plenty already, constantly seeking alignment. The rationale was more engineers meant we could make more products more quickly.
It never worked, and caused huge headaches that never really went away. It didn't help that team size was made a specific goal of a number of VPs. So it because a goal to grow team size, rather than a business need
And because the VPs were doing it, a whole bunch of people down the hill started copying then, using team size as a forcing function for power.
That's a bit silly. Presumably you wanted to deny competitors use of these engineers, because they would build something useful. Just have them build that stuff for you instead?
And if competitors were in the same boat, why bother hiring these people at all?
It's about denial of labour leading to denial of broader competition, rather than a true intent to build a competing product.
If you were actually to follow through with building the product you would need a lot more than just engineers to roll out a successful product, effectively an entire company is needed, which would spread the company focus out and the lead to investor questions about your focus and commitment. Then if it's an unproven idea there's significant risk in going to market etc etc.
Cheaper to just lock up the talent and burn the wages. Bit of a ding to your books, big ding to your competitor's capability.
In saying that, it's a terrible practice. Massive waste of time, opportunity, talent and money.
>And if competitors were in the same boat, why bother hiring these people at all?
Suppose an established org (N) got disrupted by a startup (N+1) because the startup was able to do things faster and cheaper. Once the startup becomes the established org themselves and slows down a bit, they are exposed to the same risk, unless they hire all the smart people (who would otherwise be hired by N+2 startup) and buy out all the N+2 companies who actually managed to do something despite having less money. Eventually it becomes too expensive and there is a good excuse to fire all those people. I don't think it's 100% of what is happening, but it could be.
Right, and it’s just the wrong, maybe weirdest correlation to suggest, and I’m someone that loves to find unexpected connections between things. ZIRP had nothing to do with this “no-man” phenomenon, it predated ZIRP.
As someone else said, much about the post is simply not testable.
Is someone at Facebook working on the Metaverse a crucial part of prototyping new business models, or are they doing busywork? It'll only be clear in hindsight.
Regardless, even if you think its not a neccesary expenditure (obviously there is a big gap between bare minimum and healthy), its still an expenditure on hosting the site. The person i was responding to was claiming it wasnt related to the website.
I don't think that's true at all. I have to go pretty far up the Org tree at my corporate job to get to 300 engineers and that encompasses functionality easily broader than "running Wikipedia" in scope and scale.
I don't think you understand the scale of "running Wikipedia". I do. I worked there for years when there were 100 engineers and they were severely understaffed.
Wikipedia is: mediawiki (and its development), wikimedia cloud services (which I built) that runs tools and provides services for developers (including volunteers and tool authors), server/network infrastructure, wikidata, search, etc.
Mediawiki itself is extremely complicated to build and run, and it's running for numerous languages across multiple projects (wikipedia, commons, wikidata, wiktionary, etc etc).
I'm leaving out a lot of the other things handled by the engineering teams, but it's considerably more complex than you think it is.
> and that encompasses functionality easily broader than "running Wikipedia" in scope and scale.
I highly doubt that the totality of your corporate employers output is even close to the scope and scale of wikipedia. I’m pretty sure you and I both know that if your employer was gone tomorrow, most would not notice, and only the most severely bookish scholasts (they are likely to be wikipedia editors) will be able to recall what exactly was done there 5 years after the books are closed.
What kind of expenses are covered by that? I can only think of garbage collection and collapses of the street that affect your property.
Where I live I pay rent on a relatively small ~150000 $ house and have no idea how much the property taxes are as the landlord pays them but if they were ~1/5th of 500 $/month, I'm sure my rent would've been higher than what it is now.
To be clear they had explicitly written in the contract from the start that death didn't count. And they paid out the full amount - just not to the same betters they would have if he had left office alive.
There are a lot of things short of death that we don't want to encourage either. There is a huge grey zone here that I frankly don't want to entrust to private entities.
C++ you get templated generic algorithms that in practice no one really does with C because macros suck too much. So in C typically you'd have a runtime generic routine that doesn't inline. A classic example here is qsort() vs std::sort().
> So in C typically you'd have a runtime generic routine that doesn't inline.
With LTO you get many of the same advantages as C++ template code, there's nothing magic about C++ template optimizations, it's all about whether the compiler can see all function bodies in a call hierarchy.
LTO cannot change the layout of structs. For something like a hash map implementation, it matters whether inner nodes store a pointer to the key and value, or whether it stores a pointer to each. To achieve this in C, you have no other options than emulating templates using macros.
The question is whether a hash-map implementation that works on a general `[key, index]` item and where index references at separate array of values isn't actually better for some access patterns ;)
And of course the other alternative to macros is code-generation (but macros are actually often fine).
But this also only matters for actually reusable generic code. If I'd implement a super-hot-path hashmap in C, I would stamp out a specialized version by hand instead of relying on a generic implementation. But for 90% of cases, a solution like in stb_ds.h is probably good enough.
Sure, but now you're actually moving the goal posts. We're talking about the practicalities - you can always achieve the same by doing more work, but it makes a difference that Rust gives you `HashMap` in the standard library that you can just use and get best-in-class performance, every time, with zero work, zero maintenance. The only choice you have to make is which hash function you want to plug into it, and since it is generic, that gets optimized and inlined as well (even with LTO disabled).
> The only candidate is using virtualization and void* pointers instead of monomorphized generics which some C code does for the lack of better options, but that's not a problem in Rust as well.
But in fact, if speed is a concern to you, even in C you will use "templated" sorting (via macros or code generation).
Neither codegen nor macros (they are a part of the preprocessor) are really a part of C.
For the latter, the lack of integration becomes more noticeable if you try writing a macro in which the compare param can accept a function identifier. As the preprocessor doesn't have the knowledge of the contents of the referred function, it can't inline it. In C++ and Rust, their compilers do, so they can.
A codegen tool could overcome this, but you could also make a codegen tool to write Zig/D/C#/Swift in C, or any other language for that matter :). By this point, one could say you are programming in a superset of C, not strict C.
Indeed Rust's standard library provides much better sorts both in terms of performance and in terms of resistance to abuse than those provided in the big three C++ implementations.
reply