undefined | Better HN

0 pointsjrockway3y ago0 comments

The "while balancing on a ball while holding a cane in their mouth..." thing really resonates with me.

Something that really surprised me at Google is how many core services had very thin test suites. I'm the kind of person that sees 100% code coverage and thinks "that's a good starting point". If I don't have that, I'll definitely break something important in 6 months. There were a lot of people at Google, though, that definitely didn't need those guard rails. The entire team could read a changelist and know exactly what the consequences are; they could just read the diff and run the complete test suite in their head. So there was no need for them to spend the time actually typing in a test suite.

It wouldn't work for me but there were a lot of people at Google that absolutely didn't need to follow "good engineering practices" to do good engineering. I was impressed. A lot of people less smart than them try this and fail, but they made it work.

0 comments

2 comments · 2 top-level

teaearlgraycold3y ago

After 3 months at Google I've come to realize the high hiring bar is there because you need to be particularly smart just to get basic shit done in their environment. I spent 3 hours the other day trying to authenticate to one of Google's own internal APIs from within the Google network using their bespoke IDE. In the end the code necessary was pretty simple. But I'd tried many incorrect solutions before that. The API library itself is "deprecated" but the API is still very much in production and not changing any time soon.

1 more reply

Willish423y ago

This rings true to me as well.

> The entire team could read a changelist and know exactly what the consequences are; they could just read the diff and run the complete test suite in their head. So there was no need for them to spend the time actually typing in a test suite.

I think testing at Google is excessively complicated for a myriad of reasons, and the unit-test-style "coverage" doesn't really map well to how things work together in a larger system. That system-wide thinking is where the "read a code change and know exactly what's wrong" intuition becomes invaluable. *Integration* testing is especially hard for some reason (probably complexity in the serving stack, at least for many teams I've worked with), so you end up getting this pattern where people get better at other production health stuff like canary systems, release management, etc.

j / k navigate · click thread line to collapse