Consistency is NOT the most important thing. Correctness is.

What point do you think you're making? I mean, do you think anyone looks at a PR and says "this PR is clearly wrong, but it's so consistent that I must approve it." That's obviously not the point, is it?

There would be no other incentive for companies to buy it.

A company might want to extend it's service offering with a build pipeline/CICD system, and buying GitLab would get them the best-in-class service.

Microsoft bought GitHub for much of the same reasons, and GitHub didn't went to hell after the acquisition.

If anything, I thing Stack Overflow replaced Usenet as the source of informal technical advise.

Never heard of Experts Exchange beyond the jokes.

I've submitted this link because the topic is interesting to me, and !functional_programming@programming.dev is practically dead, with the last post dating back over 10 days.

For those who are down voting the contribution, be my guest and do better: submit interesting content.

We have a client which is MAD cause the project is riddled with bugs, but the solution somehow is paying more attention. Except that it clearly isn’t feasible to pay more attention when you have to check, recheck and check again the same thing over and over…

By definition, automated testing means paying more attention, and doing it so well that the process is automated.

They say it’s a waste cause you can’t catch UI (...)

Show them a working test that's catching UI bugs. It's hard to argue against facts.

but they somehow think they are smarter than google or any other small or big company that do write test

Don't sell a solution because others are doing it. Sell a solution because it's a solution to the problem they are experiencing, and it's in their best interests to solve it. Appeals to authority don't work on everyone.

Also worth mentioning, Ubuntu 23.10 already ships with .NET 8.

https://packages.ubuntu.com/mantic/dotnet8

From the article:

(...) but recently, another type of criticism seems to be on the rise.

The code that I suggest is too verbose. It involves too much typing.

This reads like a one-sentence strawman. Describing code as "too verbose" is really not about the risk of carpal tunnel syndrome. It's about readability and cognitive load.

The blogger seems to almost get the point when he writes the following:

In short, the purpose of source code is to communicate the workings of a piece of software to the next programmer who comes along. This could easily include your future self.

The purpose of source code is to communicate (...) to the next programmer who comes along.

If you make the mistake of going the "enterprise quality java code" meme approach, you're making the next programmer's life needlessly harder.

The blogger then tries to make his case with verbose code, and makes the following statement:

Which alternative is better? The short version is eight lines of code, including the curly brackets. The longer version is 78 lines of code. That's ten times as much.

I prefer the longer version. While it takes longer to type, it comes with several benefits. (...)

This is yet another strawman. The longer version is awful code, not because it's longer but because it's needlessly jam-packed of boilerplate code. Ignorign basic things like interfaces and contracts, It's been proven already that bugs in code are directly proportional to the number of lines of code, and thus the code the author prefers is likely to pack ten times more bugs.

The shorter code in this case would not be the 78-loc mess that the author picked as the thing he prefers. The shorter code in this case would be something like onboarding the project onto Project Lombok to handle all-args constructors, property methods, and even throw a builder in for free. This requires onboarding Lombok to the project, and add two annotations to the short example. Two lines of code, done.

After the blogger fails to make his case, he doubles down on the typing non-sequitur:

Perhaps you're now convinced that typing speed may not be the bottleneck (...)

This is a blog post that fails to justify a click. It's in the territory of "not even wrong".

The optimization I'm the most proud about was when I worked on a legacy project whose end-to-end builds took around 1 hour. After spending some time working on its architecture, project layout and build system, I managed to get the full end-to-end builds to take 10 minutes, and incremental builds to be almost instant.

What makes me the most proud about this project is that the technical debt plaguing the legacy project was directly and indirectly the reason why half a dozen of my team members burned out and quit the company. After that point my remaining team members started to be far less stressed and team velocity skyrocketed, just for the fact that the thought of iterating over a bugfix and posting a pull request didn't cost at least one hour, and sometimes two or three.

I don’t think it’s a stupid thing to want to have code in the kernel, especially after spending all my time debugging this issue.

The way that you jumped straight onto broadcasting drama when your very first Linux kernel patch stumbled on the code review stage is a major red flag.

I would hate to work with you because I would feel that I would be risking being subjected to a very public character attack each time I had to review one of your patches.

Java 8 LTS

but if it’s not readable it’s garbage.

Readability is often in the eye of the beholder, but knowing that a component implements a design pattern is all you need to know how it's used without even having to peek at the code.

I think the most vocal critics of design patterns are those who are clueless about design patterns, and they are criticising their use just because they are scared of stuff they don't know.

Having fun when programming should be much more important than having correct or fast code (...)

That's only remotely reasonable if you're a weekend warrior that messes with coding as a pastime. Even so, I'm not sure what fun you can extract from dealing with slow, broken code.