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

GitLab announces workforce reduction and end of their CREDIT values

about.gitlab.com

Post reply on HN
Print view View original

611–620 of 750 posts

Re: GitLab announces workforce reduction and end of their CREDIT values

#611

Post by u_fucking_dork »

phoronixrly wrote: post #478
wiseowise wrote: post #455

Earlier quoted context omitted.

Why would you scrape HN when they offer free, generous API?

Autocomplete only 'knew' how to output a scraper...

Not true, I tried just now. Took 30 seconds of due diligence. You could have done this too. Do better.

The problem is they’ll do what you ask. And if you are the type of non-curious person who replies “ Autocomplete only 'knew' how to output a scraper...”, then you’ll tell it to make you a scraper instead of ask what your options are for getting HN data.

Re: GitLab announces workforce reduction and end of their CREDIT values

#612

Post by u_fucking_dork »

argee wrote: post #428
usef- wrote: post #403

Earlier quoted context omitted.

I sure hope you're not mocking the classic "Microwave cooking for one" book! The mallard reaction is very possible in microwaves, but they use microwave-specific crockery. I think the vision was possibly killed by people not wanting to maintain a second set of crockery. See here for a fun write-up: https://www.lesswrong.com/posts/8m6AM5qtPMjgTkEeD/my-journey...

That book came out much later than what I am talking about, when many workarounds like turn tables (and indeed, specialized crockery) were made available. This thing [0] for example, did not even have a turn table, and yet was created in an "all in" form factor for the American home. It was in production for nine years. Perhaps we can liken these auxiliary advances to agents and harnesses in the analogy. In the end,…

They sure are great for reheating food though. The problem is that a lot of developers think they are Michelin chefs when in reality they are Olive Garden cooks reheating frozen meals.

Re: GitLab announces workforce reduction and end of their CREDIT values

#613

Post by antongribok »

KaiserPro wrote: post #576
oblio wrote: post #553

Earlier quoted context omitted.

What's wrong with Ceph?

Whats right with it? Its slow, large, excessively complex and not that resilient to failure. You either want a bunch of NFS machines backed on to ZFS on nvme, with a central jumping off point that allows sharding (this is critical to allow one or more NFS server to fuck up and not kill access to everything else.) Or, pay the money and use GPFS

As someone who's in charge of close to an exabyte on Ceph, I couldn't disagree with you more.

Done correctly, Ceph is extremely reliable, resilient, and fast. Once you get over the initial learning curve, dare I say, even a joy to work with.

Re: GitLab announces workforce reduction and end of their CREDIT values

#614

Post by hombre_fatal »

vultour wrote: post #515

GitLab could be the perfect case study on AI-powered efficiency improvements. I have never interacted with a piece of software that, for every single problem I found, there was an open issue always at least 4-7 years old that was just being shuffled around by managers adding and removing random labels. Surely with all of these ridiculous developer productivity gains enabled by AI, they should finally be able to fix a…

On the other hand, most issues rot due to process overhead, not because the ticket is hard.

For example, why are you working on a four-year-old issue, and a trivial one at that, when you're already behind schedule on the tasks assigned to you? Now someone else who has their own things to get done has to review it? And even trivial changes can be annoying to truly review beyond a blind LGTM.

Just one of the many ways that pressure builds against the utopia of burning through old tickets.

Aside, watch out for the double standard we have for AI on forums like this. AI is expected to be so good that it can magically overcome the forces that keep engineers from working on old tickets (which were never related to engineer productivity) and, when AI can't, well of course it couldn't because AI sucks.

Re: GitLab announces workforce reduction and end of their CREDIT values

#615

Post by 2ndorderthought »

wiseowise wrote: post #468
2ndorderthought wrote: post #64

Earlier quoted context omitted.

Basically "screw any part about employees working together do what I say fast". What a shame. I love the AI bros who think utopia is coming, 4 day work weeks, etc. more like "get screwed, work more, for less, in worse environments".

> I love the AI bros who think utopia is coming, 4 day work weeks, etc. more like "get screwed, work more, for less, in worse environments". Where do you find those, seriously? That might’ve been the case a couple of years ago, where they’ve gaslighted people and played on their feelings, but now gloves are off. AI bros are literally posting about lack of sleep, dopamine hits, vibe coding on a toilet/walk/watching TV…

I've seen it on here even.

Re: GitLab announces workforce reduction and end of their CREDIT values

#616

Post by Someone »

DeusExMachina wrote: post #597
sesm wrote: post #578

Earlier quoted context omitted.

The reason for this is: the only way to show productivity gains enabled by AI is to lay off people and pretend you are doing the same amount of work (while in reality you are severely dropping quality and accumulating technical debt).

Also, when most work is unproductive, like managers shuffling around and relabeling issues, you can remove those managers without affecting output.

Quite possibly while improving output. Managers that are gone will not require attention from developers.

Re: GitLab announces workforce reduction and end of their CREDIT values

#618

Post by duxup »

hombre_fatal wrote: post #614
vultour wrote: post #515

GitLab could be the perfect case study on AI-powered efficiency improvements. I have never interacted with a piece of software that, for every single problem I found, there was an open issue always at least 4-7 years old that was just being shuffled around by managers adding and removing random labels. Surely with all of these ridiculous developer productivity gains enabled by AI, they should finally be able to fix a…

On the other hand, most issues rot due to process overhead, not because the ticket is hard. For example, why are you working on a four-year-old issue, and a trivial one at that, when you're already behind schedule on the tasks assigned to you? Now someone else who has their own things to get done has to review it? And even trivial changes can be annoying to truly review beyond a blind LGTM. Just one of the many ways…

And who knows the fix to some of these issues might be a hell of a lot more worked now that the bug has been baked in and the "real" fix is herculean now.

Re: GitLab announces workforce reduction and end of their CREDIT values

#619

Post by ipaddr »

skeptic_ai wrote: post #453
tux wrote: post #372

Earlier quoted context omitted.

Yes, AI should be used as a tool for very specific things. Ones it’s trained on everything it’s completely useless. Anyone who is trying to use it for everyone will fail. I predict by 2030 (if not much sooner) ai bubble will burst. The only good outcome will be all this hardware used will be lequdated for pennies. Mark this prediction it will happen ;-)

If you’re so sure just make a leveraged bet and become a millionaire. Put your food where your mouth is if you’re so convinced

Knowing it will fail is one thing but knowing when and how things blow up is another.

Re: GitLab announces workforce reduction and end of their CREDIT values

#620

Post by lbotos »

morningsam wrote: post #563
skrrtww wrote: post #11

A lot of the conclusions they're drawing in this post about the "agentic era" seem quite misguided and some don't really seem to make sense. I have no doubt GitLab has too many employees and can benefit from being a more focused company, but it's tiring reading these layoff posts so chock full of buzzwords. I guess they're desperately hoping if they prognosticate about AI enough it will placate the investors.

>some don't really seem to make sense. This one stood out to me: >Machine-scale infrastructure. [...] Git itself wasn't designed for that load, and bolting AI onto platforms not built for agents is the biggest mistake of this era. [...] Git itself is being reengineered for machine scale. Git itself is so far down the list of bottlenecks that do or could hamper LLM-driven development, even projecting years into the fu…

I wholeheartedly disagree.

Git has always been one of the biggest perf bottlenecks inside of the product.

First for any scaled deploy we recommended NFS. We were young and dumb and it was too slow. (We’ve all been there)

Then we went to an RPC model with gitaly and even unwrapped some of the git calls inside of that to speed it up.

Just a few months ago we had a large customer with thousands of devs and a large monorepo ground their deployments to a halt because of a cloning strategy change that introduced an accidental 10x in git calls. Git itself was the bottleneck because it’s not designed for this scale and speed.

For enterprises where thousands of developers are contributing code via git to a centralized system of record, who are firing off 1000s of CI jobs Git is absolutely a bottleneck.

Now with LLM technologies we should easily expect a 5-20x code volume increase on the conservative side. Git is being stretched to its perf limits.

(Source: see my profile)

Post reply on HN