In my experience a lot of hiring in those big or publicly traded companies is to "build the structure to get promoted".
When you're big, investors and banks and auditors don't like flat structures with a lot of individual contributors. A vertical structure is a must to go public. The rest is people playing the game they're forced into.
> When you're big, investors and banks and auditors don't like flat structures with a lot of individual contributors. A vertical structure is a must to go public. The rest is people playing the game they're forced into.
Might be the first time I've heard this hot take out. What makes you think banks care what the org structure is for a public company? Banks don't care for size as long as the company is fiscally prudent and can prove it. They do check silly metrics sometimes like revenue per employee, but they really don't give a damn how your company is structured. By that metric, 2012 frat club Facebook wouldn't have been touched - yet they had like 10 investment banks frontrunning their book. In fact, I'd say 2012 Facebook IPO was the trigger for a lot of banks not caring about such silly things.
As a counterpoint to your argument, there are 200-500 employee biotechs not generating meaningful revenue that are trading publicly (and which went public without a SPAC play). The decision on who gets to go public falls on the exchange, not on the banks - they simply sell your stock to their investor list, and a flat structure with fewer than needed employees is actually a great selling point for a bank.
>In my experience a lot of hiring in those big or publicly traded companies is to "build the structure to get promoted".
This comment should be at the top. Not just at the top of the thread, but at the top of HN homepage.
It's how during the pandemic many companies just suddenly doubled their headcount without any extra output in products or quality, and now we're seeing somewhat of a correction to that with all the layoffs.
It's how you see people in tech hubs climb to the top of some large companies despite never having worked longer than a year at any company. Nothing against job hopping but I ask myself what skills and value people like that actually bring, who have 10x 1-year of experience, as they're never in a place long enough get to see the end results of their work and decisions, if they're good or bad, they barely pass the onboarding stage.
It's also how many of these large orgs end up failing long term. Look at Intel now, or german auto makers, as the goal of each worker there becomes gaming the system to getting yourself a promotion at the cost of the org as a whole, instead of adding value to get a promotion, since the org is very bad at setting the right goals and incentives for the workers. Google and the like who have a monopoly with an impossible moat or an infinite money cheat can resist this enshitification much much longer than the rest of the companies.
I'm not even mad, in the end most people are just playing the game, they don't get to write the rules of the game, and the ones who do are out of touch with reality so they can't be mad when people try to game it for their personal advantage.
Very much the same. Visual representations are just a translation of whatever happens within the brain to be able to articulate it somehow to other people.
I think that's the beauty of it, though. It's never really there, even the code itself is a translation.
Agreed. I was expecting a technical justification on why they're not the same. After all the buzzwords and empty statements, I'm now more than convinced that they are.
I would say react server components are fundamentally different.
PHP starts off powered by the state on server (database etc) and ends there when it hits the client unless you hand it off to a completely different language/system: JavaScript.
It would be really nice if you could instead keep writing PHP-for-the-client which would let you reuse your templates/PHP code/etc but keep all the state on the client so you can instantly do things without round trips to the server.
That's what RSCs are and they are pretty great IMO.
I didn't know the guy but he clearly knows what he's doing, it's unbelievably entertaining to read the details of achieving an impossible task with the most underpowered tool possible.
This is what's happening in my org, talented people was leaving consistently (5-6/month), things are currently maintained with skeleton crews -- the ones that are maintained, the rest are accidents waiting to happen.
Quality inertia is what's preventing stuff from crashing down instantly, but it'll eventually be the case. It's just a matter of when the last guy that's worth their role leaves.
Most "SDEs" attracted by past big money have below-minimum reading skills, can't write code, can't troubleshoot, can't debug anything even if they life depends on it. They were hired to form a particular structure for the manager two levels above to be promoted.
This is true. Not only management, but a bunch of the so-called SDEs that are only there to say "we're investigating" every time there's an issue while they all wait for the guy who knows the system to wake up in his timezone.
There's people that's overworked and stressed out, tho, but those are the minority that do the actual work. I'd say it's an 1 out of 10 ratio at best, being conservative.
This is all because every single project is scoped, designed and implemented with the only goal in mind: your own promotion. Same applies for hires, you don't hire roles, you hire _the structure you need to be promoted_.
Lovely, but my main problem with these tools is that they're unidirectional and aim to be the central authority. But they're a picture, no the database.
I understand why people uses them, I just don't need a tool like that.
So every tool "exports to SQL" expecting all changes in the database are reflected in the diagram. But the diagram is not the database. So we've got two jobs now.
Not ex-Stripe but in "close relationship" with them since its inception and there's a clear mark in my calendar circa end of 2018 when their decisions and output started to become... weird, or ill-designed.
I don't think it has to do with the dev environment itself, but I'd blame such thing for allowing to deliver "too fast" without thinking twice. Combine that with new blood in management and that's an accident waiting to happen *
They're the best in business still, but far from the well-designed easy-to-use API-first developer-friendly initial offering.
Though I am under the impression that things have gotten more sensical internally over the last year or so.
Note also that the devprod team has largely been shielded from the craziness, and may still be making good decisions (but I don't know what they are in this realm personally).
When you're big, investors and banks and auditors don't like flat structures with a lot of individual contributors. A vertical structure is a must to go public. The rest is people playing the game they're forced into.
reply