Your comment feels half-baked at best. You start to talk about "best editors" but you proceed to present your two best examples and neither has anything remotely related to editors.

CLion is undoubtedly the absolute best IDE for C++ projects, and it's multiplatform on top of it. It's not even a competition, specially if you're using CMake. Using Git integration as your best and single example to refute this is extremely puzzling by how silly it is.

the whole point of agile is to be short term

Not really. The whole point of Agile is to iterate. This means short development cycles which include review and design rounds to adapt to changes that can and will surface throughout the project. The whole point of Agile is to eliminate problems caused by business, project, and technical goals not changing because planning is rigid and can't accommodate any changes because the process does not have room for those.

This is why this whole "things need to be planned" crowd are simply talking out of ignorance. Agile requires global planning, but on top of this supports design reviews along the way to be able to face changing needs. This requires planning in short-medium-long terms.

Don't blame Agile for your inability to plan. No one forces you not to plan ahead.

Push notifications that aren’t specifically topically opted into get blocked so fast on my phone. I have no patience for wasting my time earning someone else advertising dollars.

I agree. The article also points out this fact. Quoting the article:

Another challenge is that irrelevant or unwelcomed pushes risk having the user disable notifications, uninstall apps, or start ignoring them due to low usefulness. This results in a permanent loss of a channel for sharing timely, useful information, leading to reduced app usage. Unfortunately, as Twitter found, most recommendation engines take a myopic view, over-optimizing on immediate user responses at the cost of long-term satisfaction.

Personally, this problem is so pervasive that I kind of developed a pavlovian reflex to notification dialogs to cancel all without thinking about it.

They’ve not been closed as duplicates or anything, just no answers.

This suggests your questions are a factor. Perhaps the topic is too niche? Perhaps the questions are too specialized?

Recently I gave SO a try with a tricky but low-hanging fruit question, and the problem I faced was the exact opposite of yours: I received too many comments and answers. The problem was that 99% of those replying were clearly clueless newbies and seemed to be piling on to try to farm reputation points. Some of them were even not reading the question at all, using a strawmen of sorts to dump the answer they had, and even presenting code snippets that were broken.

For the article-impaired,

Using OFFSET+LIMIT for pagination forces a full table scan, which in large databases is expensive.

The alternative proposed is a cursor+based navigation, which is ID+LIMIT and requires ID to be an orderable type with monotonically increasing value.

This guy 3Dprints.

What a treat of a post. This is why I subscribe to !3dprinting@lemmy.world. Thank you.

The commit history I looked through has multiple commits for something that should realistically be a single “linted the project” commit. It’s valid criticism in this case.

I don't agree. The trunk features multiple typo fixes and whatnot, but they are days apart and spread over weeks on end.

If anything, this shows that no one is contributing to the project, and people like the blogger wasted more effort writing posts on how no one is doing anything while they themselves do nothing at all, and to make matters worse they criticise the ones actually contributing something.

If the blogger really feels strongly about this, he should put their money where their mouth is and lead by example.

From the perspective of hiring people he turned this from a “nice work debugging a problem, might be a useful candidate” to “tries getting low quality code merged for vanity reasons, let’s avoid that guy”

The shit storm he brew up in response to getting feedback on his very first pull request is way more concerning than churning out low-quality code.

Coding skills can be improved, specially from the first pull request onward. Toxic behavior such as putting up very public smear campaigns in response to getting feedback on his very first patch submission is a major red flag, and is as toxic as it gets.

Style points for the a-bun-dance of puns.

There is a lot of doubling. Why the heck is there Dart/Flutter? Just use Javascript/TypeScript.

This blend of comment was once targeted at TypeScript. Still is.

The truth of the matter is that the purpose of tools is to help people achieve their goal. JavaScript is awfully broken, and many people have been investing their time to come up with solutions to fix it. TypeScript is one of the approaches, but Dart is another one. JavaScript doesn't go away because it's the de facto standard to run arbitrary code in a browser, and it carries decades of legacy code. Thus people try and try. TypeScript is now on its 5th major release, and there's still plenty of work to improve upon the mess that's JavaScript. No wonder corporations like Google invest their resources building alternatives.

Focusing on code coverage (which doesn’t distinguish between more and less important parts of the code) seems like the opposite of your very good (IMO) recommendation in another comment to focus on specific high-value use-cases.

The usefulness of code coverage ratios is to drive the conversation on the need to track invariants and avoid regressions. I agree it's very easy to interpret a metric as a target to optimize, but in this context coverage ratios is primarily used to raise the question on why wasn't a unit test added.

It's counterproductive to aim for ~100% but without this indicator any question or concern regarding missing tests will feel arbitrary. With coverage ratios being tracked, this topic becomes systematic and helps build up a team culture that is test-driven or at least test-aware.

Code coverage is an OK metric and I agree with tracking it, but I wouldn’t recommend making it a target. It might force developers to write tests, but it probably won’t convince them.

True. Coverage ratios are an indicator, and they should never be an optimizable target. Hence the need to keep minimum coverage ratios low, so that the team has flexibility to manage them. Also important, have CICD pipelines export the full coverage report to track which parts of the code are not covered.

The goal is to have meaningful tests and mitigate risks, and have a system in place to develop a test-minded culture and help the team be mindful of the need to track specific invariants. Tests need to mean something and deliver value, and maximizing ratios is not it.

This could be a good opportunity to introduce the concept of test-driven development (TDD) without the necessity to “write tests first”. But I think it can help illustrate why having tests is better when you are expecting to make changes because of the safety they provide.

I doubt that by now the concept of TDD is unheard of to any professional team. Name-dropping concepts actually contributes to loose credibility of any code quality effort, and works against you.

Also, TDD's credibility is already low as it piles on the requirement of spending unordinate amounts of extra work effort on aspects of a project which don't deliver features, and thus it's value-added is questionable from a project management perspective.

One aspect that does work is framing the need for tests as assurance that specific invariants are verified and preserved, and thus they contribute to prevent regressions and expected failure modes. From my experience it's far easier to sell the need for specific tests if they are framed as "we need assurances that this component does not fail under conceivable usecases" and specially as "we were screwed by this bug and we need to be absolutely sure we don't experience it ever again."