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?

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.

Edit: just noticed this post is over 10 years old.

It would be helpful if the title was edited to feature the release date. Context is king. So many things are absurd with regards to the current state, but are sorely lacking a few years ago.

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.

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.

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.

Anonymized data as a concept has always been a joke. With enough data points, the origin can usually be traced.

The design goal of anonimized data is that it is processed to explicitly disallow tracing. This means not only removing personally identifiable information but also disallow session data.

I think it is common knowledge by now that the kernel community is a rather toxic space where abuse and elitism are the norm rather than the exception.

Even in the blog post's very one-sided account of the issue, there isn't even a hint of elitism or toxic behavior. There was a bug report, the reporter submitted a patch, the patch was faulty and unusable, and the maintainer stepped in to put together a working fix. That's it.

Interesting viewpoint, but I think the applications aren’t at fault: The operating system should ensure that the user has control of the computer at all times.

The whole point us that the OS does ensure that the user has control of the computer, at least as far as a time-sharing system goes. The problem is that the user (or the software they run) often runs code on the main thread that blocks it.

The real-time mentality towards constraints on how much can be executed by a handler is critical to avoid these issues, and it should drive the decision on whether to keep running a handler on the main thread or get it to trigger an async call.

I remember the first time I read about that concept and immediately thought “you mean the way we’ve been writing websites since the 90s?”

This is a poorly informed take. Your pop's dynamic html server side rendering has nothing to do with the problem of rendering DOMs generated by JavaScript running in a browser according to the client's state and leave it in a coherent state. Trying to pass off React's SSR for the same thing that was done in the 90s is like trying to pass off an Android app as the programs written for DOS.

but we can agree on which of two implementations is shorter.

Shortness for the sake of being short sounds like optimizing for the wrong metric. Code needs to be easy to read, but it's more important that the code is easy to change and easy to test. Inline code and function calls are renowned to render code untestable, and introducing abstract classes and handles is a renowned technique to stub out dependencies.

You don’t have guarantee nobody touched your file, we should database that keep structure information instead.

What is your definition of file and database? For example, do you think SQLite is a database, and a SQLite database file counts as a file? Do you think that editing SQLite or PostgreSQL with a third party client counts as touching a file?