Large monorepos have tradeoffs that may or may not make sense for a particular use case. Google's monorepo--in its form as a monorepo, not just the software it contains--is one of its biggest assets and creates enormous leverage.
And an enormous set of problems that must be managed. But multirepos have their own set of issues, and which set of problems you want is highly situation dependent.
I have always had this itch to work on some real life serious system programming projects, with the most recent wave OS kernels. I completed the MIT xv6 labs (a very small repo) and did a few Linux device driver labs (very large repo and it was the first time I experienced compilation time > 5 minutes).
I got burnt out after a while, so that kinda wrapped up my experience working on large repos.
You have to be very careful in management to not create perverse incentives. I like to use change control processes as an example. In theory, a super strict change process for every single change is great, because it'll ensure everything gets reviewed thoroughly. In practice, that leads to people flouting the change process as much as they think they can possibly get away with, because it becomes a serious impediment to getting work done. A more moderate change process would have higher compliance, and actually lead to more oversight, than a super strict one.
Jam is more popular than jelly, in my experience, but (as OkayPhysicist said) many people use the word "jelly" incorrectly to mean any kind of fruit spread.
This is very much a personal preference thing, I suppose. When I make a PB&J, I want no pieces of fruit whatsoever. Jam is acceptable but not preferred, while preserves are too chunky and I would just not make a PB&J at that point. Marmalade I do not use for anything because I find the bitter flavor to be extremely unpleasant.
Companies are trying. The Wendy's by me has an "AI" ordering process in the drive through. Consequently, I don't go to Wendy's any more because I hate talking to the clanker. But I imagine a lot of people just do it.
The rest of your comment suggests tney have yet to fully succeed.
McDonalds tried for 3 years. They found that roughly one in five orders required human intervention. AI created bigger problems than it solved --- like driving away customers.
Now at first brush, while I don't think that AI could replace fast food workers, McDonald's obviously also went Hard Mode when they partnered with IBM to provide the AI.
Stupid things that work are still stupid. There's a reason we have the expression "a broken clock is right twice a day". Moreover, evidence so far seems to suggest that this AI push is not working for Amazon.
I've been hearing "the new model is so much better than the one from 6 months ago" every few months since 2023. It's never been true to date, so please understand why I am skeptical that it suddenly became true this time.
It is completely unreasonable to assume that. Tech people are so hungry for productivity gains that they regularly will defy management forbidding them from using a tool, because the tool is so good they feel they have to have it.
If LLMs truly are as good as their proponents say, engineers will use them even if management outright forbade it. The fact that people aren't using them, and have to be forced, is extremely strong evidence that they are not in fact that useful.
> extremely strong evidence that they are not in fact that useful.
Surely you can't argue in good faith today that LLMs aren't useful? It was a valid argument a year ago, but the latest models are absolutely useful at solving whole classes of problems.
They're not perfect, need to be carefully monitored, can cause weird gambling like dopamine rushes and can cause lazy development habits to creep in. But none of those things negate the fact that, in many situations, they are useful.
> That said, if you can't figure out how to use AI in a software job you should look into it. Not using AI at this point is a lot like not using CAD as an architect.
When LLMs are capable of actually doing a good job, then it might be like that. We are not there yet, and we may never be.
reply