Bloating HTTP and its implementations for REST-specific use-cases
I have no idea what are you talking about. Setting a request/response header is not bloating HTTP. That's like claiming that setting a field in a response body is bloating JSON.
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.
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.
Anyone in software development who was not born yesterday is already well aware of the whole FOMO cycle: