Hacker News Reader

Comment by posharma | Hacker News Reader

Disclaimer: these are anecdotal reports. I've heard from a lot of my friends how abysmal the quality of code is at Meta. Obviously, this may not be true in all teams/products, but that's the general sentiment. Why make it faster when you're already dealing with mess! This is abundantly evident from the constant fire fighting, duct tapes and a metric driven culture that incentivizes the number of diffs landed.

View on HN

I'd say local code quality is generally good but overall it's a big hodge podge of small features duct-taped together, so the whole app becomes a tangled mess. The metric driven culture tends to emphasize impact, not diffs landed.

> I'd say local code quality is generally good

Have you ever used facebook.com? At least the frontend is incredibly slow (on a thousands of € machine), so that's not synonym with quality in my experience.

From reading the comment thread I would say the front end would be macro, local would be like a specific function on the front end, like the friends list, that by itself could have "good code".

Like when I have a red number indicating I have a notification and then I click and it just loops forever on some grey animation because it doesn't manage to load the list of notification on my fiber connection?

You're thinking of features when the other person is thinking in code. Maybe some overcomplicated bloat is involved with whatever goes into clicking that.

They mean locally as in code scope and not necessarily client sided or the size of a feature

The little red dot is one microservers, message previews is another, 'load profile picture of message sender id' is probably another, etc.

How would you measure impact?

A change you made moved some metric a measurable amount (usually aligned with a team or product goal).

You put these little nuggets of impact on your performance review.

At first guess, landing/launching a new feature, and then possibly feature adoption.

Are there companies with a reputation for code quality?

Google places a pretty high emphasis on code quality and readability. It's not universally great, but it's a big part of the culture. You can catch a glimpse in their [style guides][1], [abseil totws][2] and [aips][3]. Almost every change is required to be reviewed for "readability" in addition to functionality. This can feel like a lot, but it leads to pretty consistent style across the codebase which makes it a lot easier to switch projects or read and understand an unfamiliar section of the code.

[1]: https://google.github.io/styleguide/ [2]: https://abseil.io/tips/ [3]: https://google.aip.dev/

I find Google's take on code reviews to be particularly good:

https://cloud.google.com/architecture/devops/devops-tech-tru...

I enjoy how they state like 3 times that code reviews should be synchronous, yet "industry-standard" (aka: what people really do) is to toss it over the fence in a PR and go back and forth for several days with stylistic bullshit.

Code reviews are usually synchronous at Google though, commenting and fixing things is like chatting with the reviewer so are usually done quickly. Not sure why this wouldn't be industry standard, is there any reason to make code reviews more painful than that?

I was kinda joking that places like Google might have good processes but most places just cargo cult it and do it incorrectly. My current job does reviews that are so useless I don’t even participate anymore and no one cares. I really want to work at a place where they care about code quality and an effective process.

Oh, Abseil is new to me. Thanks!

Do you know where the missing tips are? For example:

https://abseil.io/tips/110

The root page (parent's [2]) mentions this one as famous by name:

>Often they are cited by number, and some have become known simply as “totw/110” or “totw/77”.

Is totw/110 some Google secret sauce that we are forbidden from knowing or did they skip some weeks?

A lot of them are related to Google-internal practices or libraries, or are like too opinionated (Google has strong internal C++ opinions that aren't necessarily correct or even reasonable elsewhere) to be useful.

110 in particular probably could be public, but it looks like they stopped externalizing them in late 2020, which is kind of sad, so I assume they never got around to it.

Yeah, that sounds about right to me. I used to help edit Testing on the Toilet and there were a lot of internal-tool-specific ones that we never made public. When we were low on content, we would happily publish an issue about someone's internal service/project, for example. It's not that we were trying to hide something, it would just be completely useless to the outside world.

TIL TotT is externalized.

https://testing.googleblog.com/

I asked a Google friend to find totw/110 for me and apparently it's just some tips about construction and destruction of global variables.

These missing TotW's are usually about internal tools that aren't open source.

totw/110 was about safely initializing global and static objects. IIUC there was something missing in the open sourced version of Abseil so that it could not be published verbatim.

Yes. VMware's ESXi kernel was unbelievably rock-solid compared to other similar systems. Fantastic resilience against even hardware faults. I've heard that there was a culture of "doing things the right way" there.

Meanwhile in the same org, the group doing their GUI kept adding band-aids to a broken mess for years.

ESXi is a gem that few appreciate. It's been quietly chugging along as my home server hypervisor since 4.1 (2010). And it's free.

GitLab and Netflix come to mind.

If what you’re saying is true, I wonder how much of the quality issues is just a company getting really big over time. Harder to standardize or keep tabs on such a large number of developers.

Because making it slower won't improve anything.

Reply on news.ycombinator.com