And that’s how software development became just another profession.

I don't think that's a healthy way of framing things. Software development was always, from the very start, just another profession. What changed in the last decade or so was a) supply and demand in the job market, b) the quality of the pool of workers searching for jobs. Companies still look for developers, and most still pay handsomely well, but the hiring bar is currently met only by those who are far more experienced and/or paid attention to their career growth. You still see companies hiring people straight out of bootcamps, but they come out of the bootcamp pipeline with proper portfolios and they hit the ground running without requiring that much training or onboarding.

In contrast, the blogger states that "After more than a decade of sitting behind a single company's desk, my CV looks bleak." A decade is a very long time to stay idle by without updating their skills, isn't it?

I saw this phenomenon throughout the past decade in the hiring loops I was involved. In the demand peak I already saw a few developers with over a decade of experience interviewing for senior positions that started their interviews already defeated and broken, complaining that in their last roles they just went with the flow and never bothered to do anything relevant with their career. They claimed they could fit the role and do whatever needed to be done, but the truth of the matter is that that's true for each and every single developer called for a technical review. We needed to have some assurance that we were hiring the best candidate for the job, and these developers with a long experience of "sitting behind a single company's desk" gave us nothing to work with. So why would we hire them over those who could show off something?

Having said this, I'd say that OFFSET+LIMIT should never be used, not because of performance concerns, but because it is fundamentally broken.

If you have rows being posted frequently into a table and you try to go through them with OFFSET+LIMIT pagination, the output from a pagination will not correspond to the table's contents. Fo each row that is appended to the table, your next pagination will include a repeated element from the tail of the previous pagination request.

Things get even messier once you try to page back your history, as now both the tip and the tail of each page will be messed up.

Cursor+based navigation ensures these conflicts do not happen, and also has the nice trait of being easily cacheable.

"Appendable” seems like a positive spin on the (...)

I don't think your take makes sense. It's a write-only data structure which supports incremental changes. By design it tracks state and versioning. You can squash it if you'd like but others might see value in it.

It’s usually easier imo to separate them into different processes (...)

I don't think your comment applies to the discussion. One of the thread pools mentioned is for IO-bound applications, which means things like sending HTTP requests.

Even if somehow you think it's a good idea to move this class of tasks to a separate process, you will still have a very specific thread pool that can easily overcommit because most tasks end up idling while waiting for data to arrive.

The main take is that there are at least two classes of background tasks that have very distinct requirements and usage patterns. It's important to handle both in separate thread pools which act differently. Some frameworks already do that for you out of the box. Nevertheless it's important to be mindful of how distinct their usage is.

Is there a simple way to do a http web server or socket?

What's your definition of http web server or socket? Most frameworks nowadays provide you with tools to get a fully working project up and running with just a couple of clicks.

For instance: https://start.spring.io/

They used it because it was an established term

My graph theory is a bit fuzzy but I think that the definition of a branch in a directed graph corresponds to the path between two nodes/vertices. This means that by definition any path from the root node to any vertex is itself a branch.

I don't think Git invented this concept, nor did any other version control system.

I know that “branch” helps intuitively and visually when it’s actually an offshoot with one root and a dangling tip, like an actual tree branch…

I think that your personal definition of a branch doesn't correspond to what graph theory calls a branch. Anyone please correct me if I'm wrong.

From the article:

By library, I mean any software that can be run by the user: shared objects, modules, servers, command line utilities, and others. By service, I mean any software which the user can't run on their own; anything which depends (usually through an API) on a service provider for its functionality.

It looks like the blogger took a page out of Humpty Dumpty's playbook and tried to repurpose familiar keywords that refer to widely established concepts by assigning them entirely different meanings that are used by no one except the author. I'd also go as far as stating these redefinitions make no sense at all.

Perhaps the blogger might even have a point to make, but stumbling upon these semantics screwups is a major turndown, and in my case led me to just stop reading the blog post on the spot.

Java 10

I can also tell you without any shred of doubt, that there are many Amazon teams that absolutely hate Java

Irrelevant. What matters is what the company uses, not what some guy's personal taste.

Amazon standardizes on Java. There is no way around this fact.

It is branching away from Java, even if it still uses it primarily.

I'm sorry to tell you, but I assure you it is not. Some small subset of teams uses non-java tech stacks but that's because they have very particular requirements, such as being android apps or running on Linux devices. The bulk of the company heavily standardized on Java and has no plans to ever move away from it.

Unusually, off the top of my head, I happen to know more .NET developers working there than Java developers, and interestingly they develop one of the services on AWS.

First of all AWS is not Amazon.

Secondly, I can tell you for a fact that C# is one of the rarest tech stacks at Amazon. Even Amazon's internal build system does not support it.

I'm afraid you're talking about stuff you know close to nothing about.