Hacker Newsnew | past | comments | ask | show | jobs | submit | solatic's commentslogin

The issue I have with these pieces is that AI will not affect the whole economy evenly. The disruptions come in bursts and fits: first digital artists were disrupted (e.g. Adobe Firefly), then junior engineering roles were disrupted, currently "measurer" roles (to quote Matthew Prince's piece on Cloudflare layoffs) are being disrupted, and it's rather foreseeable that occupations like lawyers and accountants are also at risk. But the key is that the disruption is not happening all at once. And that's a key fact because political disruption doesn't happen when a relative few people are laid off (like coal miners and factory workers were) but when a relative majority of people are hungry.

For such doomsdayer opinions to be correct, we'd see it in massive unemployment figures. US unemployment sitting at 4.3% does not bear that out. Finland and Spain are currently at >10+% unemployment. US youth unemployment may be at 9.5%, but British and Chinese youth unemployment are higher than 16%.

Is there some Finnish, Spanish, British, Chinese civil unrest that I'm not seeing in my media outlets?


Also our youth unemployment rate is still historically low https://fred.stlouisfed.org/series/LNS14024887

I’m not sure on the quality of work though


> But then why is it structured in that manner? What's the purpose?

This is bizarre. When you agree to take a $100k base salary, you don't get all $100k on the first day; your salary is split into pay periods, and if you leave earlier (voluntary or not) then you don't get the rest of the year's salary by default (severance aside).

I'll agree with you that RSUs for public companies should not have cliffs. But the idea that you agree to a large amount of compensation up-front (so that re-negotiation is infrequent) which is then paid out in portions on a regular basis is very standard, for both cash and equity.


I don't think this is actually anything new. In large-enough companies, even before AI, it was and is quite common for executives to lose touch with base reality. I don't think anyone is under any delusion that people like Mark Zuckerberg intimately know the entirety of their corporate codebases. Everything is filtered through layers and layers of middle management whose summaries, cherry-picked statistics, and perpetually up-and-to-the-right graphs make it difficult to have an objectively informed opinion. Companies would, are, and will have mass layoffs that unintentionally (or, intentionally but with indifference to the consequences) fire key engineers whose loss results in "familiarity debt" within the systems those engineers owned.

Calling this "psychosis" is maybe a neologism but it's apt in perspective.

All that's actually new with "AI psychosis" is an acceleration of that phenomenon. The agents will summarize status faster than any middle manager. Claude will happily draw you any "up-and-to-the-right" graph you please, with the most common contemporary examples being "tokens burned" and "lines of code written". And vibe coding doesn't even require paying the cost of a mass layoff to get the "familiarity debt".

There have always been both good and bad engineering leaders. No tool will magically make a bad leader into a good leader overnight. There is nothing new under the sun.


Why does the voice need to be sent to the server? Why not perform speech-to-text on-device? Is the p10 phone/laptop not capable of this yet, despite every "dictation" feature I see in every modern OS?


An eventual goal is likely to allow interacting with the LLM directly via audio tokens in input/output skipping tts and stt completely.


> Code is a liability

You're over-simplifying. Code in and of itself is neither an asset nor a liability. The minimal amount of code needed to solve business needs with no additional complexity is an asset with some maintenance liabilities attached (same as how a farmer's tractor is an asset that needs to be maintained), with depreciation if unmaintained (bitrot). Any code used to build unnecessary complexity is pure liability.


A liability isn't an inherently bad thing.

A loan is a liability, but you might take one out regardless because you know you can use it to make more money than you'll have to pay back in interest.

That said, I think it's more correct to characterise code as a depreciating asset, as another commenter did.


I would term it a Depreciating Asset, like a car or a building. Bitrot is real.


Yes, if code is only a liability then just delete the code and poof liability is gone.


Would it be fair to say that complexity is a liability, and LOC is an (approximate) measure of complexity?


That’s just the same statement with an extra step.


Guess this is an unpopular opinion:

If you run more than one service/codebase, you might be better suited to using a proper container orchestration platform. Doesn't have to be Kubernetes. AWS ECS, GCP Cloud Run, Kamal are all modern options here.

If you run a single codebase in production, why are you even containerizing? Language ecosystems have done a phenomenal job of improving their dependency management since Docker was released. Python has uv. Go has modules. NodeJS has pnpm. Do you actually get benefit from containerizing if you're deploying to a single production host somewhere?


> people will choose fresh over canned, for obvious reasons

Not at all obvious. A lot of "fresh" produce in the US was refrigerated for more than a week before it arrived in the supermarket, from varieties that were designed to hold up to transport rather than flavor. Fruit that was canned at the height of the season is often much more flavorful than "fresh" off-season fruit.

The US has a problem with packing fruit in added sugar, which is sad but not inherent to canned fruit.


Not all alerts are created equal. You should generally have three levels of alerts: critical (which pages somebody, time-to-fix should be ASAP), warning (creates a ticket, time-to-fix should be within a few days), and suspicious (does not notify, appear only on an alert dashboard). The suspicious alerts are there to help guide your investigation on a critical or warning alert.

Each critical and warning alert should link to an "interactive runbook" - a dashboard that combines text instructions along with graphs showing real-time data.

Doing this at scale, correctly, requires both alerts-as-code and dashboards-as-code, which almost nobody does because nobody treats higher-level configuration languages (jsonnet, CUE...) with the attention and respect they deserve /cries-in-yaml


The most helpful tool here, I've found, is maintaining a personal finances spreadsheet.

It's one thing, without a spreadsheet, to have the emotion of "I'm not going to have enough and I need to save more to make sure I have enough." I'd argue it's even evolutionary; we want to make sure we have enough to get through the winter we know is coming.

It's quite another when your spreadsheet shows you saved X, your monthly cost of living is Y, and therefore you have enough money saved, even if your income went to zero and you made no changes to your lifestyle, to last you for Z years. Being able to take YouTube University rule-of-thumb advice like "of your take-home pay, use 65% for necessities, 15% for long-term savings, 20% for enjoyment" and seeing how much money that is per month for you in your personal circumstances, along with rules of thumb on things like what ratio you should have achieved by which age on net worth-to-income ratio (1x by 30, 2x by 35, 3x by 40, etc.) and seeing what your personal actual ratio is, to get a sense of benchmarking yourself.

I mean, the influencers could be totally full of shit, but it doesn't matter. Getting actual numbers for where you are, plus getting "generic" advice that you know wasn't directed at you personally, and seeing how those numbers make you feel, can do a lot to either tell you "you don't need to be so frugal anymore" or "yep, your emotions are totally justified, keep saving".


I need to get into building a PF spreadsheet and getting things in better order, but fwiw the way I sometimes frame the question of whether or not it's "okay" for me to buy something is 1) Will spending the money compromise or help my ability to pursue something else I want to do, based on the price and utility, 2) Could I buy 20 of them? Even better if I could buy 20 without tangibly hurting my wallet.

If you can buy 20, 1 is probably fine, don't stress too much.


I think in the case of pathological frugality the spreadsheet approach could make things even worse. A whole 20% spent on enjoyment? I bet I could drive it down to 15%, maybe 10%. In fact, do I really need these things? Why not go down to 0%, maybe 5% once every few months. After all, I might need that money in the future.


This is why I don't budget. I'm not immensely financially irresponsible: I make maybe 1/3 to 1/5 what the average person on HN makes (~50k), but I still contribute to my 401k enough to get my match, I could fairly easily tank about a 10k expense/probably live for 3-6 months on the money I have set aside with adjustments.

But whenever I've tried to budget, I run into the same problem anorexics do with counting calories. I will literally hurt myself in order to see the savings number go up. I can live on $10/week for food. All it will cost is my health. I can be in pain for 8+ months out of the year (MS muscle spasticity + heat intolerance ) so I don't use my heat or A/C because those cost money. Etc. I will literally berate myself to the point of a panic attack over buying a $25 book from an author I've loved for decades, believing it makes me a horrible human being to be so 'frivolous'.


That is good if you can count on your cost of living being predictable. It's not for many people, even for relatively well-off ones: you may earn a lot for your area but being an immigrant without a permanent enough status in your current country, and your home country which you always have a right to return to may be unsafe or highly undesirable for whatever reason. So you need to consider the emergency of moving somewhere in a political and legal climate not known in advance.

Thus it becomes a more difficult choice what proportion to bet on stability of the current living situation, and what on long-term savings for emergencies which look quite probable but still unmeasurable. And the latter is complicated by absence of reliable and relatively liquid investment opportunities. All in all, fun to be from a sanctioned country.


I think a spreadsheet is still helpful in this case.

> So you need to consider the emergency of moving somewhere in a political and legal climate not known in advance.

Fair enough. So do the financial planning, and ask yourself, how much does it cost to fly/travel to X place that is far away? Put in a risk premium - what if the cost became 2X or 3X because of a sudden catastrophe affecting everyone? What is the actual number that you need to save? Can you keep the money in a bank account, or are you concerned that banks will be inaccessible, and thus need something more portable? If you need something more portable, how much will it cost to protect it (vault/safe, weapons)?

I sympathize that life isn't fair, and that financial goals for some people need to be concerned first and foremost with personal safety instead of luxurious "nice-to-haves". But my point is that there are still actual numbers involved, and that you can put those numbers into a spreadsheet, and that the spreadsheet can help you understand your progress towards those goals. Financial planning is valuable regardless of what your goals are.


All you are saying is that some people have more volatile earning/spending scenarios. The advice is still the same, the knobs on the spreadsheet are just different.

It's not much different than a sales job where income can be highly variable, or go to 0 because the local market is dead.


Azure's management APIs break connections coming from outside Azure's network every time they use DNS to execute a blue/green swap on their public load balancers. Existing connections are not gracefully drained. Terraform state gets corrupted (it thinks the operation failed when it actually succeeded and the resource was actually created) and requires manual fixing.

This happened frequently enough at large enough scale we seriously considered building an automation to attempt to analyze the Terraform logs for the connection breaking and automatically import the created resource.

Azure support was completely worthless.


> Azure support was completely worthless.

It's quite incredible that a support bill in the >10k per month range from azure makes the public google (not even GCP with a support contract) support look not crap


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: