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

341–350 of 352 posts

Re: Software Engineering at Google (2020)

#341

Post by UncleMeat »

nostrademons wrote: post #325
UncleMeat wrote: post #253

Earlier quoted context omitted.

There's a lot of external complaining about perf at Google. My experience is that most of these complaints are wrong. I've personally had two reports fail to get promoted to L6 off of projects that were very difficult and executed well but for various reasons did not have the impact that we expected.

The problem is at the VP level, not the L6 level. It's not that impact isn't considered, it's that impact is relative to the current org goals of the moment, because it's evaluated by your peers that have presumably all bought into the current org goals of the moment (if they haven't, they will probably be fired or sidelined soon). However, there's very little feedback between things users care a lot about and things…

I do agree with this criticism. There are impactful things that go unrewarded because of org mismatch and that's dumb. My team has been affected by this very problem and it is very frustrating to look at a list of things that I know to be very valuable and be told "don't do that, it is misaligned with org priorities."

But this is "some impactful stuff is unrewarded" rather that "hard stuff that isn't impactful is rewarded", which was the complaint in the post above mine.

Re: Software Engineering at Google (2020)

#342

Post by UncleMeat »

nonethewiser wrote: post #340
UncleMeat wrote: post #252

Earlier quoted context omitted.

What I am describing is not code review and test coverage. What I am describing is the ability to run all of the tests for the entire company in one go so you can safely make absolutely massive changes to the codebase.

So having a monorepo?

A monorepo and TGP plus a culture where changes are okay when they don't break tests.

Re: Software Engineering at Google (2020)

#343

Post by badlucklottery »

Espressosaurus wrote: post #169
badlucklottery wrote: post #158

Earlier quoted context omitted.

This. Someone dropped the ball. There's a form to get your corner of the codebase exempted from readability temporarily. This gives your team a quarter or two to build up readability.

A quarter or two isn't going to be enough for a drastic realignment of a large codebase. It's a start, but only a start.

The 1-2 quarters is just to "realign" the SWEs, not the codebase.

Old code can usually be left as-is unless there some particularly egregious security hole or the like.

Re: Software Engineering at Google (2020)

#344

Post by fizigura »

emodendroket wrote: post #331
londons_explore wrote: post #268

Earlier quoted context omitted.

I read that as "strong preference for having Carplay/Android Auto over the car manufacturers own UI". And everyone is just frustrated with laggy UI's in cars. But in reality they'll probably still just use Waze with a 10 buck phoneholder suction-cupped onto the windscreen.

Why on earth would you do that instead of using Waze on the larger, built-in screen? Especially if you are a buyer who "strongly prefers" having that in the first place? Nobody is using that kind of holder on a car with Android Auto or Carplay.

Security-concious people like to keep the complexity low of things that are involved in their day-to-day activities. Having your car mingle with your phone is kinda the opposite of this.

Re: Software Engineering at Google (2020)

#345

Post by emodendroket »

fizigura wrote: post #344
emodendroket wrote: post #331

Earlier quoted context omitted.

Why on earth would you do that instead of using Waze on the larger, built-in screen? Especially if you are a buyer who "strongly prefers" having that in the first place? Nobody is using that kind of holder on a car with Android Auto or Carplay.

Security-concious people like to keep the complexity low of things that are involved in their day-to-day activities. Having your car mingle with your phone is kinda the opposite of this.

I don't think this describes any significant portion of users.

Re: Software Engineering at Google (2020)

#346

Post by hn_throwaway_99 »

nostrademons wrote: post #326
hn_throwaway_99 wrote: post #281

Earlier quoted context omitted.

Re: monorepos, I think we're talking about 2 different things. I usually hear the term "monorepo" discussed in the context of how it is practiced at places like Google and Facebook: having the code for all the company's services (micro or not) stored in a single source control repository . A monorepo really doesn't have anything to do with how code components are deployed - your comment seemed to be contrasting a mon…

I was fast & loose with terminology, but I'm thinking of the organizations where every binary and every library is its own Github repository, and you make copious use of git submodule to build anything. I think that's the same thing you're talking about, right? It's impractical (particularly when the project is young) for the same reason having separate binaries is impractical: it makes it very difficult to do refact…

Yep, we're talking about similar things but in slightly different ways:

1. When you're small enough, and only have a few teams and/or deployed binaries, you keep everything in a single repo.

2. As you grow with more teams and more products/binaries, often companies will split into having separate repos per team/product, and then use some sort of dependency management tooling (either something like the git submodules you discuss, or a private package repository, e.g GitHub's Package Registry, Nexus, or Artifactory). I totally agree with you that a lot of companies do this prematurely.

3. What distinguishes "monorepos", in my opinion, is that this was an innovation at either Google or Facebook I think (not sure who was first), where they realized exactly what you point out - it makes it really hard to do refactorings across lots of dependent projects in different repos. So they decided to keep everything in a single source control repository, with a single commit history. But in order to do that and have things be sane with lots of teams and thousands of developers, they needed to invest a ton in custom tooling to make these giant monorepos usable by individual developers and teams. E.g Facebook has Sapling, Google has Piper, and there are open source tools like Lerna for JS monorepos.

So, in my experience, just having everything in a single repository but without any special tooling (because you're small enough to not need it yet) is just a repo. Monorepo IMO implies that you've grown to the point where it's difficult to keep everything in a single repo without special developer workflow support tools.

All that said, I definitely agree with your main point - a lot of companies can just keep everything in a single repository a lot longer than they think they can, even without special tooling beyond some separate build targets.

Re: Software Engineering at Google (2020)

#347

Post by hn_throwaway_99 »

ryandrake wrote: post #323
hn_throwaway_99 wrote: post #199

Earlier quoted context omitted.

Perhaps, but to me everything you put in your comment above just sounds like bad engineering practices in general and not something particularly related to Google processes. E.g. things like "do feature work on a branch and then code review/run PR checks before merge", "have unit test coverage (being a hard balance to judge what is sufficient coverage)", "have useful comments" - absolutely none of these things I asso…

Yea--I've found it surprisingly difficult to get plain vanilla medium-sized companies to adopt obvious, time-tested best practices. I'm not talking about "Google engineering practices" but basic table stakes practices like using source control and a bug tracker. So-called "Joel Test"[1] items. The most common excuses are: "We don't have time/money to do infrastructure/process, we need to write shipping code!" and the…

It is honestly baffling, totally baffling to me that in this day and age there are companies that don't use source control or a bug tracker (but trust me, I believe you).

With these companies I think it's just best to walk the other way. Some of them may state that "yeah, we know we need to improve our engineering practices, so we're willing to learn" but they usually just have so much of a different mindset of what it takes to actually run a software company that it's just a waste of time. There are many more companies that have a modicum of understanding about what they're doing.

Re: Software Engineering at Google (2020)

#348

Post by nostrademons »

UncleMeat wrote: post #341
nostrademons wrote: post #325

Earlier quoted context omitted.

The problem is at the VP level, not the L6 level. It's not that impact isn't considered, it's that impact is relative to the current org goals of the moment, because it's evaluated by your peers that have presumably all bought into the current org goals of the moment (if they haven't, they will probably be fired or sidelined soon). However, there's very little feedback between things users care a lot about and things…

I do agree with this criticism. There are impactful things that go unrewarded because of org mismatch and that's dumb. My team has been affected by this very problem and it is very frustrating to look at a list of things that I know to be very valuable and be told "don't do that, it is misaligned with org priorities." But this is "some impactful stuff is unrewarded" rather that "hard stuff that isn't impactful is rew…

The "hard stuff that isn't impactful is rewarded" is relative to the overall marketplace, including conditions outside of Google. Starting a new chat client that replaces Google's other half dozen chat clients may be challenging, but it has little benefit to either users or Google.

Good entrepreneurs go into markets where the existing alternatives suck, and make them radically better. Most Google executives and PMs (most executives, period) go into markets that their company and all of their competitors already have pretty decent alternatives for, so the true impact is pretty limited.

Re: Software Engineering at Google (2020)

#349

Post by fizigura »

emodendroket wrote: post #345
fizigura wrote: post #344

Earlier quoted context omitted.

Security-concious people like to keep the complexity low of things that are involved in their day-to-day activities. Having your car mingle with your phone is kinda the opposite of this.

I don't think this describes any significant portion of users.

Maybe, maybe not. But it describes an answer to your "why on earth" question.

People may have different preferences from yours.

Re: Software Engineering at Google (2020)

#350

Post by OkayPhysicist »

hn_throwaway_99 wrote: post #347
ryandrake wrote: post #323

Earlier quoted context omitted.

Yea--I've found it surprisingly difficult to get plain vanilla medium-sized companies to adopt obvious, time-tested best practices. I'm not talking about "Google engineering practices" but basic table stakes practices like using source control and a bug tracker. So-called "Joel Test"[1] items. The most common excuses are: "We don't have time/money to do infrastructure/process, we need to write shipping code!" and the…

It is honestly baffling, totally baffling to me that in this day and age there are companies that don't use source control or a bug tracker (but trust me, I believe you). With these companies I think it's just best to walk the other way. Some of them may state that "yeah, we know we need to improve our engineering practices, so we're willing to learn" but they usually just have so much of a different mindset of what…

These rarely are "software companies". They're companies in other industries, that happen to need some software. Sometimes it's a pretty plumb gig: Good, but not great, pay, often in relatively lower cost-of-living areas, a relatively light workload, a good amount of autonomy as one of a maybe a handful of software devs, and in their blindness to good practices (like source control), they're also untouched by common bad practices in software, like whatever bastardized version of agile/scrum that your bosses heard through an extremely lossy telephone game.

But there's also the bad: Software isn't the company's focus, so you aren't the company's focus. That means no "Senior FAANG" salaries, no best practices to keep things sane, and often you find yourself working on a codebase that was originally hacked together in a week by a chemist who may or may not have been deliberating huffing reagent fumes.

Post reply on HN