Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Software Engineering at Google (2020)

abseil.io

Post reply on HN
Print view View original

121–130 of 352 posts

Re: Software Engineering at Google (2020)

#121

Post by biztos »

outside1234 wrote: post #30
NoMoreNicksLeft wrote: post #12

Earlier quoted context omitted.

> Additionally, critics of Google may point out that their engineering culture may not be great on its own terms -- every time Google launches a new feature, people post links to the Google product graveyard. It is personally scary when they develop new products. What if it is a brilliant idea, one I cannot live without? If Google develops it, then I am looking at this stillborn thing, mewling for life when I know it…

The inventions are to keep the talent stream coming ... to work on ads. The inventions are the small tax they pay to pretend to candidates that they could work on inventions when the vast majority of them will be "allocated" to ads.

You need Shiny Inventions so you can divert the talent stream away from your competitors, more than to actually work on the ads.

I'm sure there's some Shiny Invention Corner in the ads business -- let's call it "AI" -- and some of the top people can be motivated to work there.

But isn't the ads business by its very firehose-of-money nature something that will get on fine with that average level of talent that is sufficiently motivated by cash and doesn't need Inventions?

And isn't the top talent able to make the same money doing interesting things elsewhere? (I keep hearing this is happening with AI, but I hear it on Xwitter so who knows.)

Re: Software Engineering at Google (2020)

#123

Post by jacobr1 »

fractalb wrote: post #53
lapcat wrote: post #34

Earlier quoted context omitted.

> I don't understand your argument - why does the lack of a diversified business have imply a lack of quality for systems and processes for writing code? That wasn't the argument. The argument was simply that having a profitable monopoly doesn't imply the presence of quality.

How did they achieve monopoly if it weren't for the quality?

I think you hit on a key part of the debate in this thread. There clearly is some sort of functional quality floor, in the sense that poor enough quality means something doesn't actually work to do its job. But beyond that, what is "quality"? Some would consider it to mean elegance of algorithmic and architectural design, or readability of code, or some other more abstract measure. Some consider it suitability to purpose, with low-bug count.

I've give one example I observed commonly early in my career. The unexplained memory leak. Some process is running and the memory usage continues to grow. Eventually it will use the entire memory of its machine and die. You have a few options: 1) debug the issue and address the root cause 2) debug the issue and workaround it in some way 3) Give up and rewrite the code using some other kind of tooling 4) wake up people when the process dies and have them restart it 5) write a cron-job that restarts the process periodically.

What is the right answer? The best from a QA perspective is probably to identify the root cause and fix the underlying issue. Tools like valgrind have made this much easier in recent years, but it still can be a challenge. Pragmatically, my own answer (speaking generally, there are more different cases for different contexts) would be to time-box and investigation and fix, and if that wasn't achievable in reasonable time, just write the cron-job and work on the next problem. You can imagine very successful operations filled with kludges like that. Is that low quality?

Re: Software Engineering at Google (2020)

#124

Post by compiler-guy »

flohofwoe wrote: post #21

Probably a bit off-topic, but since I'm a bit triggered by the 'abseil' in the domain name: I wish Google would relax their 'guidelines' when it comes to software that's also published outside of Google. Case in point: the Dawn C++ library (Google's native WebGPU implementation) has a dependency on abseil, and from what I've seen when glancing over the code, the only reason seems to be some minor string-related stuff…

Many of the authors of abseil are on the C++ committee and contribute to its progress--this is especially true of the string library, where abseil convinced the standards committee to adopt string_view.

The dependency here almost certainly predates C++ adopting the features it has had for a decade.

Re: Software Engineering at Google (2020)

#125

Post by syngrog66 »

When I see the font and color contrast scheme on that page I nope aborted fast.

and dont tell me I can override it in my browser. Neither my Android phone or Android Chrome honors my expressed wish to override everything with a high contrast, dark theme. A few honor it, many apps and docs do not. That article does not.

Re: Software Engineering at Google (2020)

#126

Post by aatd86 »

UncleMeat wrote: post #104
water-your-self wrote: post #67

Earlier quoted context omitted.

>most tools are exactly the same sort of thing that you'd create in any other place, we just have more of them Why? Why reinvent the wheel 10 times?

Google has 180,000 employees. There's an org that is responsible for internal tooling, but they are an org with priorities and challenges like any other. So sometimes Search needs a thing and Core won't do it so some people in Search build a tool. Maybe later somebody in Ads needs a similar tool but has never heard of the thing that Search built. So there is an organic force to this sort of complexity. There are syst…

Should be easy nowadays to have a chat-based AI which, given some provided requirements, suggest similar tools that have been built by other SBUs. Even if only to look at the code.

Re: Software Engineering at Google (2020)

#127

Post by [deleted] »

ye-olde-sysrq wrote: post #11

"As far as this outsider can tell, the systems and processes for writing code at Google must be among the best in the world, given both the scale of the company and how often people sing their praises." Is this really the case? In high school I sure thought Google was a magical software heaven us mortals could but dream of working for, but now (and increasingly as of late) I'm strongly under the impression that 20 ye…

[deleted]

Re: Software Engineering at Google (2020)

#128

Post by ajross »

londons_explore wrote: post #28
ye-olde-sysrq wrote: post #11

"As far as this outsider can tell, the systems and processes for writing code at Google must be among the best in the world, given both the scale of the company and how often people sing their praises." Is this really the case? In high school I sure thought Google was a magical software heaven us mortals could but dream of working for, but now (and increasingly as of late) I'm strongly under the impression that 20 ye…

Google search was 1998. Google Maps was 2005. Gmail was 2004. Android was 2008. Youtube was 2005. Chrome was 2008. Docs was 2006. Translate was 2006. Yet in the last decade, they really haven't had many successes (perhaps with the exception of Google Photos - 2015) One would imagine that with nearly 200,000 employees at least one of them would have a good enough idea for a new product people like. But management and…

> Google search was 1998. Google Maps was 2005. Gmail was 2004. Android was 2008. Youtube was 2005. Chrome was 2008. Docs was 2006. > Yet in the last decade, they really haven't had many successes

I don't think this kind of analysis is really giving a good answer. I mean, by these standards, look what a disaster of a dinosaur legacy vendor Apple Computer is! Haven't had a successful product launch since the iPad 13 years ago! (Perhaps with the exception of Apple Watch - 2015).

Re: Software Engineering at Google (2020)

#129

Post by biztos »

foldr wrote: post #106
biztos wrote: post #96

Earlier quoted context omitted.

The hardware people certainly aren't: I think they're reveling in their newfound freedom to make the best, not just the thinnest, computers. But the software side? There seems to be a massive variance in both ability, and giving-a-shit across the software orgs, and no leadership filter on the output of these disparate groups. Perhaps they have the opposite of the resting-on-laurels problem: a smattering of very senio…

The Apple Silicon transition also involves software (Rosetta), which works absurdly well given the complexity of what it's doing.

Exactly my point: the same company wrote Rosetta and the new Settings. Clearly not the same level of talent and commitment in those two teams.
Post reply on HN