evantbyrne

You might be right, and I think tech professionals should be expected to use industry terminology correctly.

How am I supposed to know what specific niche of AI the author is talking about when they don't elaborate? For all I know they woke up one day in 2023 and that was the first time they realized machine learning existed. Consider my comment a reminder that ethical use of AI has been around of quite some time, will continue to be, and even that much of that will be with LLMs.

Being broadly against AI is a strange stance. Should we all turn off swipe to type on our phones? Are we supposed to boycott cancer testing? Are we to forbid people with disabilities reading voicemail transcriptions or using text to speech? Make it make sense.

I wouldn't group it with Django. It's a very simple but also well-done CMS. It is not as capable as something like Wagtail, Payload, or Craft.

Congratulations, you just reinvented slavery.

But if you take the government out of the equation, and instead mandate contribution via project licenses, that might be worth a try.

> Absolutely, but everyone makes time for Zoom meetings and finds a way to make it work, or people like me will hire someone else who can get it done.

So we are in agreement that work cannot be fully async.

There are clearly some forces at play that are changing how immigration works in the short-term. I think where we differ is mostly this: our anecdotal experiences are radically different (I would say competency is increasing not decreasing as a general trend) and I would never bet against the momentum of the US long-term, nor do I believe that quality tends to remain steady or increase with offshoring. Maybe things are different in your niche. I appreciate being given a view into a different perspective!

> No one wants to leave their families, and the upper tier of salaries in alternative geos are high enough to capture the higher talent tier because their salary expectations are based on their domestic condition.

For 2x the salary young men have proven time and again they are willing to take the risk.

> On top of that, the US immigration system is severely backlogged. It can take decades for Chinese and Indian nationals to become green card holders, and we as employees increasingly expect foreign nationals to pay the filing costs - not us.

A challenge for sure. This and what you go on to describe could certainly shift some junior labor from H1B to remote contract. I would expect that shift to have a mostly net zero impact on other American exployment.

> > other is simply that these companies exist in the US, which means collaboration needs to be done in US time zones, which makes overseas workers far less efficient and having major negative impacts on worker morale

> Not anymore. WFH proved async work models can ensure business continuity.

Every non-US team I've worked with and everyone I know that works with offshore still have meetings. It would be incredibly dysfunctional to not have any collaborative time.

> Ideally we need to build a domestic talent pipeline, but universities failed severely by watering down curricula in an attempt to compete with bootcamps, which burnt a lot of employers disincentivizing them from hiring early career, and state and local jurisdictions in the US just don't give us the support or pipeline needed to build a competitive early career hiring pipeline.

Is that really what is happening? Because based on everything I can see, hiring standards are the highest they have ever been. As we get older, we have a bias towards underestimating the capabilities of younger generations, because we can see them making familiar mistakes in real-time.

I think you make some solid points, but there are major tradeoffs some of the data is not totally convincing. If US workers are so much more highly paid than foreign workers, then we can reasonably expect the best workers to migrate to the US whenever possible. It's pretty easy for Canadians to cross the border. So one reason to hire American developers is for quality. The other is simply that these companies exist in the US, which means collaboration needs to be done in US time zones, which makes overseas workers far less efficient, not to mention the major negative impacts on worker morale. So there can be reasons to hire out of country, but the tradeoffs are significant even when well executed.

London and Toronto give people healthcare. And I was in Michigan.

I was making $50/hour fresh out of college back in 2014. And I worked remotely. $45/hour today is not great given the cost of living.

$10 is the cash price. Your doctor diagnoses, not insurance, and you don't need a specialist to get diagnosed regardless of what your insurer wants. Even a nurse practitioner can prescribe you a statin.

90 day supply of Atorvastatin costs $10. Running costs a pair of shoes.

They are all like this to a degree because controversy creates engagement. If a platform is not making you money, is not making you smarter, and not helping you form IRL connections, then I highly recommend disabling it.

It's not the dev box with zero integrations/storage that's expensive. AWS was quoting us similar numbers for MSK. Part of the issue is that modern kafka has become synonymous with Confluent, and once you buy into those features, it is very difficult to go back. If you're already on AWS and just need queuing, start with SQS.

Managed hosting is expensive to operate and self-managing kafka is a job in of itself. At my last employer they were spending six figures to run three low volume clusters before I did some work to get them off some enterprise features, which halved the cost, but it was still at least 5x the cost of running a mainstream queue. Don't use kafka if you just need queuing.

Is it arrogance or is it experience combined with a different perspective? One developer may love React because of the component ecosystem and talent pool, and another developer may dislike it because they're writing custom HTML/CSS anyways and React requires them to write way more JS than their preferred approach. Would I ever choose backbone? No. But many developers may be surprised by how little vanilla JS that it takes to build modern web apps. More than ever the tradeoffs of different frontend stacks need to be evaluated on a project-by-project basis.

Definitely check out swarm. I've heard so many great things from engineers that use it on large projects, and it takes very little time to learn if you already know the docker cli.

It is worth learning to use Docker Swarm. Deployments are as simple as pushing a new container to your registry and running one command. I built a free CLI tool rove.dev that simplifies provisioning and does service diffing.

Either that or use a PaaS that deploys to VMs. Can't make recommendations here but you could start by looking at Semaphore, Dokku, Dokploy.

Their advertised sensitivity and specificity put them in the ballpark of what other liquid biopsies advertise. The ones I know of target high-risk cohorts where the benefits of other screenings already outweigh the risks of taking them. It doesn't make sense for the average person to be getting periodic full chest CT scans for instance, but it might for a decades-long smoker.

Not convinced the Grail approach is safe and effective for low-risk cohorts given the false-positive rate. Follow-up diagnostics are not risk-free.

Thanks for sharing! I'll bookmark that.

At first glance, I don't understand the design choice of appending HTML templates to the python controller files. Seems like a lot of complexity just to remove a template render call. What am I missing?

A lot of AWS requires way too much config. It is a mystery to me why AWS doesn't lean into extending the capabilities of App Runner. I actually built a whole continuous deployment PaaS for AWS ECS with a Heroku-like UX, ended up shutting it down eventually because although useful, their pricing is pretty awful. What I need to do is figure out how to bring it back, just minus the hosted service so I can use it on corporate projects that require AWS...

Yeah I haven't had any issues with Swarm. Heard good things from people running substantial clusters. Would be interested in hearing about what rough edges people have run into as well!

ECS is good, just expensive and still requires more devops than it should. Docker Swarm is an easy way to run production container services on VMs. I built a free golang tool called Rove that provisions fresh Ubuntu VMs in one command and diffs updates. It's also easy-enough to use Swarm directly.

Swarm never died. Kubernetes was designed for an entirely different level of scale and there is inherent complexity in that. Whereas starting a production-ready container service with Swarm only takes a few commands on a fresh Docker installation.

They do with app runner, but last I checked, for some reason services were capped at low CPU/Memory and didn't allow basic ECS features like attached storage. I think they also had another one... AWS is very fragmented and strange.

I built something very similar to this a few years ago, sold it for way less ($3/service), and ultimately decided not to spend money marketing it. Building the product made it super clear that AWS costs were grossly inflated, which they hid with dark UX, and I wanted to help small teams and hobbyists. Today, if you are a small team that doesn't really need more than one large VPS, you should seriously consider Docker Swarm. Not to say that Flightcontrol looks bad. In fact, it looks quite nice. Something like this could save you a lot of money if you would otherwise need full-time devops.

I have it on my shelf. Fascinating to read the perspective of regular citizens who organized themselves to do something terrible. Likely to remain relevant for as long as people can read it.

There are infinite ways to do this and we could riff all day on it. The simplest as I see it would simply be giving individuals with young children the autonomy to dictate their work schedules, allowing them the option to make up the hours later, or even choose not to. In a way this already happens informally in nicer companies.