> If you know what you're doing you don't need AWS support.
Some big companies have massive monolith code bases. This is not a generalization you could apply universally. There are a lot of other considerations. What kind of features are we talking about, what kind of I/o patterns are planned, what is the scale of data expected, etc.
Coming from a world of acquisitions, I see almost every startup make the same decision of having a single database for everything. Can’t stress enough how big of a problem this becomes once you scale even a little bit. Migrations are expensive and time consuming. And for most teams, moving an application to a different db almost always becomes an urgent need, when they are least able to.
Most startups don’t need a dba, just competent full stack/backend engineers. That being said, I understand why many startups prefer having a dba. Not exactly fun when your only staff engineer likes to just store everything in a jsonb column in Postgres.
> If you know what you're doing you don't need AWS support.
Hard disagree. I have to engage with AWS support almost once every 6 months. A lot of them end up being bugs identified in their services. Premium support is extremely valuable when your production services are down and you need to get them back up asap.
While I agree, US is still the top destination for research, I don’t agree with “Brain Drain is not a concern” nor do I agree with “We need fewer PhDs”. The real risk of drain is people leaving their fields of expertise to never return. Pretty much all AI startups at the moment are coming from and being built by PhDs. The pace of innovation slows down and it can have huge long term economic impact. Having fewer PHDs also exacerbates that problem. If fewer people are looking for funding in the first place, you’d have even fewer ideas that could end up contributing meaningfully to society. The only solution to funding problems is more funding.
>The real risk of drain is people leaving their fields of expertise to never return.
That is happening right now, all the time! Especially in the biomed field! Many, many PhDs spend 5-8 years getting their degree and receiving minimal pay, then 4+ years being nomadic postdocs, also making terrible money, only to eventually arrive at the end of the road and realize they have to do something completely different.
It is unsustainable for every professor to train 10 PhDs in their career, because there aren't going to be 10 professorships (or even 3) for those PhDs to fill. Funding has to grow at the same exponential rate as the number of researchers. It did, from roughly 1950s to 1980s, as the university system expanded to accommodate the Boomer generation. It has slowed since, and the PhD to professorship pipeline got longer and leakier. It's doing a tremendous disservice to the bright, well-intentioned young people who join PhD programs.
> if you are going to do something for a living, make sure it is NOT scalable
You need to consider both horizontal and vertical scaling. Being a bespoke tailor may not scale vertically, but it can scale horizontally. If you have too many people pick up tailoring, you might run out of neighborhoods without competitors.
> What will the economy consist of when there are no more paychecks?
I joked with my manager when we were having a conversation about everyone being asked to use more AI, as an obvious precursor to keeping fewer employees to do the same amount of work: the end state of AI will be an AI manager having career conversations with the AI employee, discussing raises and bonuses.
The ironic part really is that the average middle management job is probably among the more simple jobs you can automate away with AI at scale. Tell it your metrics, your targets, and other relevant info, and it can feed directions down to employees at scale.
I don't buy this at all. There's significantly more to management than tracking and hitting metrics. You have to actually do the hard part of interacting with people and understanding their needs and so on within the context of work.
I'm sorry, but vomiting up another bulleted list is NOT management. Its giving orders and then culling the % that don't comply. Wildly different things.
> You have to actually do the hard part of interacting with people and understanding their needs and so on within the context of work.
Which is why it’s surprising that management is salivating at the idea of replacing employees and expecting 1 employee to do the work of 10 with the help of AI agents. If the value you bring is to manage people, you shouldn’t be happy at the idea of fewer people having jobs.
Again, what exactly are their jobs? You can’t automate them but you won’t need them either. If an org shrinks from 1000 engineers to 500 or worse, do you really keep those managers/directors/VPs around?
> You have to actually do the hard part of interacting with people and understanding their needs and so on within the context of work.
How many human managers actually do that, though? How many websites performed satisfactorily before AI arrived? How well has technology matched what consumers really need or want? Maybe, as a society we have underperformed and nescient AI performs well enough (or even better) in comparison.
> but there is robust evidence of widespread underemployment and it taking 6-12 months for the unemployed to find jobs
A really ignored aspect of this is that gig work is pretty prevalent once someone loses a stable job. This masks the unemployment with underemployment. There were headlines a while back about booming small business registrations as a sign of a booming economy. Turns out it was just a bunch of people registering businesses so that they can DoorDash
Culper Research had a thesis that a material amount of DoorDash gig workers were undocumented, I'm unsure how it panned out. I agree gig work platforms are a contributing factor to masking economy health indicators as well as underemployment.
Some big companies have massive monolith code bases. This is not a generalization you could apply universally. There are a lot of other considerations. What kind of features are we talking about, what kind of I/o patterns are planned, what is the scale of data expected, etc.
reply