The whole idea to check the donations came from stumbling upon this post which discussed costs per user.

Things should be put into perspective. The cost per user is actually the fixed monthly cost of operating an instance divided by the average number of active users.

In the discussion you linked to, there's a post on how Lemmy.ml costs $80/month + domain name to serve ~2.4k users. If we went through opex/users metric, needlessly expensive setups with low participation would be a justification to ask for more donations.

Regardless, this is a good reminder that anyone can self-host their own Lemmy instance. Some Lemmy self-host posts go as far as to claim a Lemmy instance can be run on a $5/month virtual private server from the likes of scaleway.

Note that this is failure to deliver on time, not failure to deliver full stop.

It's also important to note that the Hallmark of non-Agile teams is de-scoping and under-delivering. It's easy to deliver something on time if you switch your delivery goals and remove/half-bake features to technically meet requirements while not meeting requirements.

I wholeheartedly agree: the article is just plain stupid.

What I find more amusing is that front-end work ends up being the most critical work in any user-facing application. Apps can still lumber around if big chunks of backing services are down, but if a page is rendered poorly or a button is showing up weird, or if text is missing in a place everyone looks at, that's automatically a SEV1 right there.

Unbelievable.

From the blog post, it sounds like the underlying motivation is not tied to technical aspects but control over the language. If I had invested any of my personal time onboarding onto D and migrated any of my projects to D, I would be concerned about the negative impact these political stunts have on the tech stack.

I understand. I have to admit I felt a little dirty after pasting that text.

As a counter balance to that though, interviewers need to understand what they are hiring for and tailor the questions asked to those requirements.

This does not happen. At all.

Back in reality we have recruiters who can't even spell the name of the teck stacks they are hiring for as a precondition, and asking for impossible qualifications such as years of experience in tech stacks that were released only a few months ago.

From my personal experience, cultural fit and prior experience are far more critical hiring factors, and experience in tech stacks are only relevant in terms of dictating how fast someone can onboard onto a project.

Furthermore, engineering is all about solving problems that you never met before. Experience is important, but you don't assess that with leetcode or trivia questions.

to add to this, id like standardization of qualification and competencies - kind of like a license so I don’t have to “demonstrate” myself during interviews.

I strongly disagree. There is already a standardization of qualification of competences in the form of cloud vendor certifications. They are all utter bullshit and a huge moneygrab which do nothing to attest someone's experience or competence.

Certifications also validate optimizing for the wrong metric, like validating a "papers, please" attitude towards recruitment instead of actually demonstrate competence, skill, and experience.

Also, certifications validate the parasitic role of a IT recruiter, the likes of which is responsible for barring candidates for not having decades of experience in tech stacks they can't even spell and released just a few months ago. Relying on certifications empower parasitic recruiters to go from clueless filterers to outright gatekeepers, and in the process validate business models of circumventing their own certification requirements.

We already went down this road. It's a disaster. The only need this approach meets is ladder-pulling by incompetent people who paid for irrelevant certifications and have a legal mechanism to prevent extremely incompetent people from practicing, and the latter serves absolutely no purpose on software development.

Should be titled, “demotivating a programmer with a specific personality type.”

The author talks about developers who are underpaid, aren't recognized by their work, and aren't even supported adequately with decent gear. This doesn't read like a list of developer traits. This reads like glorifying exploitation and terrible work conditions.

I think they were making a joke

The missing /s, coupled with some absurd comments on this thread, make it hard to tell apart the jokes from the activists.

What major Java supporting ide doesn’t support Lombok?

Why would everyone have to onboard a code generator just to be able to use data transfer objects without having to write tons of boilerplate?

Also, Java records allow the runtime to optimize how these instances are handled.

each system has it’s own dialect and quirks

That does not mean that SQL, as specified by one of it's standard versions, is not portable. It just means that some implementations fail to comply with the standard and/or provide their own extensions.

If an implementation fails to comply with the standard, that's a failure on the side of the implementation, not a failure of SQL.

Microservices are great if you have enough traffic that you can get an efficiency gain by independently scaling all those services. But if you aren’t deploying onto thousands of servers just to handle traffic volume, you probably don’t need 'em.

I don't think that's a valid take. Microservices have nothing to do with scaling or performance, at least for 99% of the cases out there. Microservices are a project- and team-management strategy. It's a way to peel out specific areas of responsibility from a large project, put together a team that is dedicated to that specific area of responsibility, and allow it to fully own and be accountable for the whole development life cycle, specially operations.

Being able to horizontally scale a service is far lower in the priority queue, and is only required once you exhaust the ability to scale vertically.