Hacker News Reader

Comment by siliconc0w | Hacker News Reader

I can imagine a project that successfully replicates the entire google developer environment (distributed build system w/ caching, monorepo with presubmit checks, code review, testing, etc) would be successful since ex-googlers would be likely to advocate for it inside their own organizations and most orgs don't have the engineering time to build all this themselves.

Without this tooling large organizations tend to silo which creates high engineering costs (every project starts from scratch, no shared frameworks/libraries, no standardizing around best practices, etc).

View on HN

A surprisingly hard sell even if your organization has a supermajority of ex-Googlers. There's a really strong meme out there that if you are smaller than Google, which is almost universally true, then you shouldn't adopt their practices even when they are zero-cost and obviously superior.

For me the "obvious" part of "obviously superior" is worth interrogating. Googlers have a very particular way of thinking of things. Which works well enough for Google, I guess. But there are a lot of ways to to good work, and not all of them are compatible.

Sure, I think thought needs to be put into any development decision. I think a new project should carefully consider, for at least several hours of research and discussion, what revision control system to use, instead of just using git without consideration of the consequences.

There are already book-length arguments that I like to refer to for specific topics, such as trunk-based development.

https://trunkbaseddevelopment.com/

I agree. A big missing link at my organization is a VCS that can make it easier to checkout and operate on only a subset of a large (many GBs) monorepo.

Unfortunately, microsoft had to move away from VFS for Git to some a more limited-in-scope approach: https://github.com/microsoft/scalar

Silo’d development isn’t a matter of tooling, it’s a matter of communication.

There's an interplay between them. Communication always has a cost; there are certainly things you can do to the constant factors, but in a 100-person engineering organization with 20 teams, it's fundamentally going to be much easier for an engineer on one team to write a build system (or pre-merge CI flow, or whatever) that meets the needs of their four teammates working on the same code than one that meets the needs of all 20 teams.

The advantage of a running, pre-existing system (and the theoretical advantage of an off-the-shelf system like this that you can supposedly turn into a running system) is that it's been built to satisfy most of the needs of a wide variety of developers working on all sorts of things, and so each engineer on each of those teams that says "All right, I'll spend some time thinking about how we build and release code" is incentivized to start from the common starting point, even if they have to customize it. That means that if two or three teams end up working on similar-enough projects down the line, the shared tooling can actually support communication between the teams. Without the shared tooling, they can communicate all they want, but it won't be rational for any team to abandon its existing tooling. (And of course you need the communication too - both are required.)

I hear you. I do. How do you get 20 teams working on disparate codebases, and probably languages, to share their knowledge across teams? How does a team working on Java benefit from something someone found in Django from another side of the company? Organizations need standards. Developers require it. We want the thing we are programming against to not change right? We want our codebase to build when we say build. All tests green. Happy. Productive. Engineering leadership needs to organize standards around engineering culture and tooling, it could be championed by a team that did it, or by research. It doesn't matter. What matters is that leadership facilitates communication into what is working, what isn't, why, and what can we do about it?

At the micro-level, tools help, no doubt about it. At an org level, communication helps (documentation is a form...). Even if using different tooling, concepts and strategies are the same. This isn't to take away from the argument that this tool the OP posted is pretty awesome.

If you want change, be the change. Evangelize the tool through your org, not just your team. If your org is silo'd, break those barriers down with a friendly lunch-n-learn or lightning talks session. We tout empathy for our customers, how about empathy for our coworkers too? Others may have the same pain...

And tooling. If tooling is consistent engineers feel much more confident crossing borders. No one speaks up or contributes without confidence.

Reply on news.ycombinator.com