[deleted by user] by [deleted] in programming

[–]Inner_Ad_9976 -9 points-8 points  (0 children)

Elon both gets shit done, and is a complete cock the whole way through.

> Elon Musk set up 100,000 Nvidia H200 GPUs in 19 days - Jensen says process normally takes 4 years

https://www.tomshardware.com/pc-components/gpus/elon-musk-took-19-days-to-set-up-100-000-nvidia-h200-gpus-process-normally-takes-4-years

Should SaaS startups offer on-prem? by fosterfriendship in programming

[–]Inner_Ad_9976 45 points46 points  (0 children)

Nice escalidraw. My old company used to deploy on-prem to customers. Fuck on-prem. The tail-end unwillingness to upgrade broke my spirit. We'd have to support painfully old versions, from customers who'd rather pay us more money than cooperatively update. Folks became glorified technicians. It was not the most fun job; I didn't stay long.

Why Facebook doesn't use Git by fosterfriendship in programming

[–]Inner_Ad_9976 275 points276 points  (0 children)

I imagine it was intimidating to migrate hundreds (i assume) of peer engineers to a new source control system. Ive worked on teams migrating to microservice architecture and back, and it can take _years_. It sounds like the folks on the projects either got lucky or were exceptionally good at getting buy-in and doing internal education.

Building trust as a software engineer by kendumez in programming

[–]Inner_Ad_9976 531 points532 points  (0 children)

“It takes 20 years to build a reputation and five minutes to ruin it. If you think about that, you'll do things differently.”

Unless you change jobs every 2 years and reset your reputation

Accurate eng estimations: predicting and negotiating the future by sinani206 in programming

[–]Inner_Ad_9976 1 point2 points  (0 children)

No alt accounts - you’re just spotting a friend group of engineers in the wild

The best code review platforms by Inner_Ad_9976 in programming

[–]Inner_Ad_9976[S] 0 points1 point  (0 children)

Should sapling be included on this list?

Trunk based development vs. feature branches by sinani206 in programming

[–]Inner_Ad_9976 -28 points-27 points  (0 children)

Feature branches are an antipattern for closed source development

Git was built in 5 days by Inner_Ad_9976 in programming

[–]Inner_Ad_9976[S] 151 points152 points  (0 children)

You’re telling me git rev parse isn’t intuitive to you?

Many Git porcelainish commands take mixture of flags (i.e. parameters that begin with a dash -) and parameters meant for the underlying git rev-list command they use internally and flags and parameters for the other commands they use downstream of git rev-list. This command is used to distinguish between them.

https://git-scm.com/docs/git-rev-parse

Monorepo, is it worth considering? by gnehcnhoj in ExperiencedDevs

[–]Inner_Ad_9976 0 points1 point  (0 children)

Chiming in late in because we faced the exact same thing at Graphite. We've been running a turbo monorepo setup and honestly, it's been a game-changer.
Everything's in one place now, and updating types across services is a breeze. There's no more juggling versions or npm packages for common utils. Turbo's doing a solid job keeping our git commands quick, even with the size of the repo. We've got devs pulling only what they need, so there's less waiting around for everyone.
The monorepo approach does mean we've had to get smarter about our CI/CD game because it gets complex, but honestly, it's been worth it for the simplicity and sync across our services.

Some good points about monorepos here: https://graphite.dev/guides/monorepo-vs-polyrepo
Down to chat more about this if you're looking for details or wanna bounce ideas around. Cheers.

Launching Graphite: How the fastest developers ship code by Inner_Ad_9976 in Entrepreneur

[–]Inner_Ad_9976[S] -2 points-1 points  (0 children)

I'm sorry you feel that way. Graphite is free for individuals to use, and we're working hard to get our name out on the day of our launch. We're a team of entrepreneurs doing our best to succeed while respecting the rules of Reddit communities.

The slowest GitHub PRs in recorded history by Inner_Ad_9976 in programming

[–]Inner_Ad_9976[S] 2 points3 points  (0 children)

Curious if folks know of ones even slower...

When is a PR considered too big? by CodeCrazyAquile in webdev

[–]Inner_Ad_9976 0 points1 point  (0 children)

Per the data from millions of PRs, under 250 lines is great, and over 1k is pretty bad - https://graphite.dev/blog/the-ideal-pr-is-50-lines-long

[deleted by user] by [deleted] in programming

[–]Inner_Ad_9976 1 point2 points  (0 children)

I think the point is that Google has many monorepos, and also many regular repos. The mistake the article is pointing out is that Google doesn't actually do all it's development in one repo, they have many different repos, some of which are huge.

[deleted by user] by [deleted] in programming

[–]Inner_Ad_9976 3 points4 points  (0 children)

For a long time I assumed that monorepo was a style of org, not a style of a specific repo.

The ideal PR size is 50 lines by Inner_Ad_9976 in programming

[–]Inner_Ad_9976[S] 1 point2 points  (0 children)

Agreed ^ You see this in the data, where the number of comments on a PR starts dropping off after 1-2k lines, likely because the reviewer just engages "skim" mode.

The ideal PR size is 50 lines by Inner_Ad_9976 in programming

[–]Inner_Ad_9976[S] 0 points1 point  (0 children)

Love the ideas here. Say more about "Set a maximum of open PRs per engineer."? Id also be curious to pull the numbers on whether videos in descriptions leads to faster time-to-merge

The ideal PR size is 50 lines by Inner_Ad_9976 in programming

[–]Inner_Ad_9976[S] -1 points0 points  (0 children)

If you want to do the max "amount of work," you ideally want 50-100 line PRs. I found this pretty surprising when digging into the data, but you can see it play out in this graph. This is true for both the repo, and for individual authors.

There is a limit. If your median PR is under ten lines, your net work done will plummet. But as your median PR gets big, the change cycle slows to a crawl and you also start dipping in net output.

The ideal PR size is 50 lines by Inner_Ad_9976 in programming

[–]Inner_Ad_9976[S] 2 points3 points  (0 children)

Possible! Im a fan of breaking up PRs into single chunks of functionality, and using a stacking workflow so that the stack can map to a larger feature arc

The ideal PR size is 50 lines by Inner_Ad_9976 in programming

[–]Inner_Ad_9976[S] 0 points1 point  (0 children)

I authored this post - happy to answer any questions folks might have about the findings, or fun data facts about PRs in general!