In Saudi Arabia and the other Gulf states, the wealthy class pays out a fair bit of money to citizens (IDK the exact parameters of who counts as someone who receives this money, but you get the idea--at the very least, the Arabs whose ancestors had been living in the country when oil was found are receiving something).
> In Saudi Arabia and the other Gulf states, the wealthy class pays out a fair bit of money to citizens
In the gulf states, the usual pattern is that the citizens are rewarded with a share of the wealth extracted by exploitation of vast hordes of noncitizen laborers, so that they are invested in the exploitation, from which, on a per capita basis at least, the wealthy class receives much more.
The disconnect between very "FAANG-focused" people and reality is always interesting to me.
1. There are a ton of good, well-paying software engineering jobs out there, especially in the startup world. Maybe not as high total comp as your Bigtech job, but still plenty adequate, esp if you've already made a good pile of money from Bigtech.
2. Not everyone in Bigtech has as unhappy a job as you seem to have; maybe you could switch teams within your company, or hop to a different "FAANG"
3. "I dreamed for years to get into FAANG" <-- I just don't comprehend this. Like, I would personally like to work at one of these at some point for the numerous benefits it would offer, but I can't comprehend it as holding the level of value that I have seen many people ascribe to it.
> There may have been people arrested, but it had nothing to do with the people the mainstream media would lead you to believe.
It had every bit to do with that investigation.
In my experience, people like you have this thing with "can't trust the mAinstrim meDia", but will gullibly accept things from "alternative news sources" with basically no skepticism or critical thinking.
You know so little about the team, the organisation, the codebase, other concurrent obligations (e.g. prod support), and the way the project is run. The only way I can imagine one having confidence in a statement like "nothing should take that long" is naïveté.
It really depends. Honestly 6-9 months would have been an optimistic estimate even if it were 2-4 devs intimately familiar with the existing codebase. Permissions is a very cross-cutting concern, as you might imagine, and touched a huge amount of the monolith code. A big problem was that permissions checks weren't done in a consistent layer, instead scattered all over the place, and the team responsible for the rewrite, being new to the code, was starting from scratch and finding these landmines as they went. Scoping was also unclear and kept changing as the project went along, at first to pull in more scope that was peripherally related, then to push stuff out of scope as the project went off track. And during all these changes you have to keep the existing auth system working with zero downtime.
The devs were good developers, too! Two people on the team went off to Google after, so it's not like this was due to total incompetence or anything; more just overambition and lack of familiarity with working on legacy code.
At a large enterprise, 6-9 months is blazingly fast.
Everything takes longer than you think and this sounds like it involves at least 2 teams (the php team and the scalar team). Every team you include increases time line factorially in the best case.
It takes a lot of time to have meetings with a dozen managers to argue over priority and whatever. Especially since their schedules are full of other arguments already
authorization and access control is an awfully difficult problem, as soon as you derive from user defined ACLs on all persisted objects and user/groups based granting data. Each access can have an arbitrary rule that must be evaluated with all dependant data, that will end up being anything in the persisted data. How to you make this long rule list maintainable, without redundancy, ensuring that changing re-used rules won't introduce regressions on all call sites ?
> Am I naive for thinking that nothing like that should take as long as 6-9 months in the happy case and that it's absurd for it to not succeed at all?
Bluntly, yes. And so is every other reply to you that says "no this isn't naive", or "there's no reason this project shouldn't have finished". All that means is that you've not seen a truly "enterprise" codebase that may be bringing in tons of business value, but whose internals are a true human centipede of bad practices and organic tendrils of doing things the wrong way.
> whose internals are a true human centipede of bad practices and organic tendrils of doing things the wrong way
Currently there. On one hand: lot of old code which looks horrible (the "just put comments there in case we need it later" pattern is everywhere). Hidden scripts and ETL tasks on forgotten servers, "API" (or more often files sent to some FTP) used by one or two clients but it's been working for more than a decade so no changing that.
On the other: it feels like doing archeology, learning why things are how they are (politics, priority changes over the years). And when you finally ship something helping the business with an easier to use UI you know the effort was not for nothing.
No, you’re not naive. If it’s done by one-two people that know what they’re doing, it should be done much faster.
If it’s a big new team that doesn’t know what they’re doing, working separately from existing codebase, with lots of meetings… I see no reason why it would finish at all.
Only in the sense that you seem to not understand how terrible big companies, big teams and big code bases are for efficiency and productivity. It pushes the bar for reaching desired results way up, and the time it takes to get there even more. No one should ever want to be part of organizations, teams or code bases like this, for their own sake.
I am not qualified for your current hiring needs, but this is extremely interesting to me.
Right now, I am currently learning Rust and have some side projects planned writing interpreters and compilers therein, and would love to take you up on the offer to have "conversations with anyone interested" so I can learn more about what you're building and learn some things.
