spectraldrift

That's totally feasible, and works for small to medium traffic (SQS scales seamlessly from 1 message per year to millions per second).

In practice, I've never seen this implemented correctly in the wild- most people don't seem to care enough to handle the transactions properly. Additionally, if you want additional features like DLQs or metrics on stuck message age, you'll end up with a lot more complexity just to get parity with a standard queue system.

A common library could help with this though.

People often forget a message queue is just a simple, high-throughput state machine.

It's tempting to roll your own by polling a database table, but that approach breaks down- sometimes even at fairly low traffic levels. Once you move beyond a simple cron job, you're suddenly fighting row locking and race conditions just to prevent significant duplicate processing; effectively reinventing a wheel, poorly (potentially 5 or 10 times in the same service).

A service like SQS solves this with its state management. A message becomes 'invisible' while being processed. If it's not deleted within the configurable visibility timeout, it transitions back to available. That 'fetch next and mark invisible' state transition is the key, and it's precisely what's so difficult to implement correctly and performantly in a database every single time you need it.

It's scary and sad how well this works.

Here’s how you can tell the letter's argument is dangerously empty: change one phrase, from 'The United States' to 'The Third Reich.' The fact that the entire letter still reads completely coherently, and suddenly sounds like authentic WW2 propaganda, shows that its core logic was never about America in the first place.

For example:

> "The Third Reich is not, and should not be permitted to become, a soft compromise and amalgam of global values and tastes. A reticence or perhaps incapacity to pronounce and to prefer... has had costs."

I don't believe it is common for most vaccines. The pharmacists are typically qualified to help you make this decision for yourself.

Yikes. You’ve mistaken sociopathy for strategy. “Do the absolute minimum” only sounds rational if you’ve already decided other people’s lives have no value. The real pitchfork crowd isn’t coming for innovators; they’re coming for people who think dead teenagers are an acceptable cost of beating Google’s press release by a day.

In general, I agree with the author's presumption that simplicity is better in system design. The frequent and tired allergy for managed queues, however, does not follow.

> Sometimes you want to roll your own queue system.

I have never wanted to do this.

> For instance, if you want to enqueue a job to run in a month, you probably shouldn’t put an item on the Redis queue.

This specific requirement sounds more like a cron job use case, not a queue case.

> In this case, I typically create a database table for the pending operation with columns for each param plus a scheduled_at column. I then use a daily job to check for these items with scheduled_at <= today, and either delete them or mark them as complete once the job has finished.

At this point I've decided the author doesn't understand when or why to use a queue. For a strictly scheduled event which must occur on day = (today + N), the proposed approach seems fine. However if you use this for a typical queue use-case you will end up reimplementing a queue in your database (poorly). This is typically far more complex than just using a managed queue service if it's available to you. By more complex, I mean more lines of code and more oncall burden. Furthermore, if you grow, a managed queue is often something that needs very little hand holding. Queues are great because they are simple- both at low and high volume. They are a technology that "just works", and often provide a lot of helpful features out of the box.

I don't know the author, but I've encountered this engineering philosophy before. It's a perspective often held by engineers whose ideas haven't been stress-tested by the long-term realities of a successful business.

It's the kind of advice you can sell to the 99% of startups that fail, and because they fail for other reasons, you never have to be proven wrong.

Very cool! I am curious how the scientific community views this situation, as it's quite rare to detect something like this. I read the JWST might be able to image it, but couldn't find that information. Can you share more?

Respectfully, that's a strawman and not what happened. Realistically the inverse happens more, and we often only interview people from certain backgrounds even though qualified people exist in other walks of life. Just look at the racial and wealth backgrounds of people who eventually become CEOs.

I disagree with the actions of the rogue employee who leaked those instructions, that's clearly wrong and illegal, and it's right to call that out. However, I believe there is some misunderstanding because sharing those answers doesn’t mean the FAA lowered the bar. What happened was akin to someone unethically telling people how to cheat to get an interview referral at google- yet the actual subsequent qualification process, the rigorous training and certification, including the AT-SAT remained unchanged. The FAA still demands the same high standards from all candidates once they enter the pool.

Let's focus on the article and evidence rather than personal details or dismissive labels. Personal attacks don't add to the discussion and go against HN guidelines for civil and substantive debate.

That’s not exactly what happened. The article shows that an FAA employee leaked guidance on answering the biographical questionnaire to members of the NBCFAE. This wasn’t an official FAA policy but a rogue action.

Every candidate still had to pass the same rigorous training and certification process, which is extremely difficult and selective.

The bar wasn’t lowered at all. What happened was that the FAA stopped giving preferential treatment to a separate group—namely, CTI graduates—by replacing their streamlined path with a flawed biographical screening. Every candidate still has to pass the same rigorous training and certification.

The article presents a dramatic narrative that implies the FAA deliberately lowered its hiring standards by replacing the traditional system with a biographical questionnaire. It’s clear from the account that many qualified CTI graduates (note: CTI schools are third parties) were unfairly filtered out from the applicant pool, and there’s documented evidence of a cheating scandal that casts further doubt on the process. However, the reality is nuanced. Although the new process may have altered who got to start the journey, every candidate still had to pass the FAA’s rigorous and extremely selective training and certification— which remain the true measure of an air traffic controller’s capability. In an ideal world, we could put everyone through this process to see who passes.

Critics argue that this change, driven in part by diversity goals, compromised the quality of candidates entering the pipeline, but the actual FAA hiring and training criteria remained exactly the same as before. It's an extremely difficult and selective program. The ongoing issues in air traffic control, such as understaffing and controller fatigue, stem from a range of systemic challenges rather than a simple lowering of the qualification bar.

This isn’t a straightforward case of DEI lowering standards; it’s about how changing the initial screening affected a well-established pathway. The FAA aimed to broaden the applicant pool, and while that decision led to unfair outcomes in unusual directions, controversy, and discontent among CTI graduates, it doesn’t translate to less competent controllers.