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.
(...) it was "because the organizer wants big names and it probably seemed like an easy way to address their diversity concerns.
Wouldn't it be easier to, say, invite real people to deliver real talks? How exactly is it easier to spend multiple years maintaining sock puppet accounts than simply sporadically extend an invitation to someone?
If a library or framework requires boilerplate code it’s a bad library or a bad framework.
I think this take is uneducated and can only come from a place of inexperience. There's plenty of usecases that naturally lead to boilerplate code, such as initialization/termination, setting up/tearing down, configuration, etc. This is not a code smell, it's just the natural reflection of having to integrate third-party code into your projects.
I was thinking of cross posting this to a Fortran community, but it looks like we don’t yet have one.
I'm sure everyone is still in comp.lang.fortran telling all kids to get off their lawns.
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.
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.
This is a good opportunity to state the fact that Raspberry Pi's value is not the hardware all on itself. The hardware actually lags behind some of the cheaper RPi clones out there, and misses some key features. Raspberry Pi's value lies on the software support for that platform. It ensures a best in class developer experience, which is key to actually serve it's purpose of an educational platform, and simplifies a great deal how to write software to run on it.
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.
Keep in mind that this is for « typical IEEE members », which I am pretty sure is not a great representative sample of programmers in general.
It's still way better than counting references in YouTube and twitter, and weirdly enough TIOBE's results are in line with this poll.
I'm inclined to interpret monorepos as an anti-pattern intended to mask away fundamental problems in the way an organization structures it's releases and dependency management.
It all boils down to being an artificial versioning constraint at the expense of autonomy and developer experience.
Huge multinationals don't have a problem in organizing all their projects as independent (and sometimes multiple) source code repositories per project. What's wrong with these small one-bus software shops that fail to do that when they operate at a scale that's orders of magnitude smaller?