Comment by landedgentry
Comment by landedgentry 2 days ago
Well, you're supposed to read the code and figure it out. And if you can't, you're not good enough an engineer. According to people at Meta.
Comment by landedgentry 2 days ago
Well, you're supposed to read the code and figure it out. And if you can't, you're not good enough an engineer. According to people at Meta.
No matter what, tools will be broken. Having access to the source and being able to land a diff to fix the issue is awesome imo.
Working around it is somehow is. A huge part of my work has been plumbing and hacking around limitations in mediocre-at-best OSS tools.
Lots of nonserious companies that take those issues as enough of a reason to move slowly.
Many fewer serious ones where bad tooling is expected to be fixed, smoothed over, or replaced entirely in the interest of future dev time.
> Having access to the source
Yes, thats great.
> being able to land a diff to fix the issue is awesome imo.
yes, if its a one off. but for my last project that would involve spinning up many "XFNs" (multi-team chat fests) to argue that actually they don't want to have that change because of reason x,y and z.
At which point you just give up and make a stupid fucking hack.
So much is not about engineering excellence, its about trying to get people to accept change.
Pfft.
"your type of company" sod off. Meta is only like this because its got a massive advertising revenue stream.
the sheer amount of engineering time wasted because we don't document stuff is astounding.
For example, how many message queue systems do we have?
how many half arsed message queues have been created because they didn't know about FOQS?
Yes lmao, the number of times I would start off on some nominally useful task only to find out 3 weeks later that there is actually already a solution to that created by team XYZ that nobody in my reporting chain has ever heard of…(3 weeks was optimistic case, I remember my team member getting like 2 months in to some new data pipeline before finding out some tables already existed that did what he needed…)
Same as Google. Many internal tools have painful interfaces and poor or documentation because the hiring bar was high and it was acceptable to assume that the user's skill level is high enough to figure it out. That attitude becomes a bigger problem when trying to sell tools to the public (e.g. Google Cloud Platform).
As an outsider, I was always under the impression that Google had a tradition of engineering excellence (robust tools, clean and while tested code following strict guidelines), while Meta has more of a Hacker culture (move fast and break things).
Google also has traditions that created Broccoli Man: https://www.youtube.com/watch?v=3t6L-FlfeaI
People probably think you’re exaggerating but it’s true. Sometimes when I would get blocked the suggestion was to “read the source code” or “submit a fix” on some far flung internal project. Huge fucking waste of time and effort, completely unserious.