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?
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 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.
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.
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
I have no doubt that this approach works better than recurring meetings, but I do want to point out the trade-off, which is that this approach requires much more management attention and energy to keep their finger on the pulse and ensure all concerns are handled, compared to their time management being on autopilot with recurring meetings.
So it's a bit of a tautology. Managers who manage time better are more effective. Who knew?
I’d also give some pushback based on scheduling: fixed meetings are a known quantity people can schedule around.
For coders and people with lives, knowing what their week looks like is critical to planning and stress management (ie in X work hours topic Y will be landed, I have X - 2 hours to have my facts in line; daily 9:15 meeting ends at 9:30, everything after 9:30 is a predictable block I manage).
Now, to the issues and whattabout’s that implies:
1) bruuuuutal meeting discipline: off topic gets killed, new topics insta-popped onto next agenda, scripts of expected responses prepared and shared (“we are green, need approval by X”). Stand if ya gotta, chess-clock if ya gotta, bring in a non-teammate for secretary duties as needed. Meetings are not gab sessions.
2) if that agenda isn’t lava hot with everyone actively getting something, W-O-W, end the meeting. Split off, 1-on-1, task-group it. Fixed project meetings are to make manager-me not have to chase anyone or anything, we are racing to get that done ASAP and the second we’re done it’s time to get the fu… <ahem> grab a coffee, and return to the activities everyone is being paid for. Gab sessions naturally follow, as needed, dynamically adapting to needs and pressures.
Managers who manage meetings manage to meet without meetings managing them. Manage time or time will manage you. The real MBA was the one inside you the entire time.
I think it seems tautological to us because it's obvious to us. But other people do not understand or care to understand or even care to think about it. You can see it in this very comment section that there are people swearing how amazingly helpful fixed standups supposedly are even on a whole org level. It's obviously absurd but they have different jobs and priorities, they don't have to understand the inner workings of the product and for them it's invisible that the meetings are almost entirely worthless for the actual workers. The meetings are helping them in their job and so it must be great for the org, that's how many people managers think.
I’ve been on both sides of this. Engineers who complain loudest about the waste of time from too many meetings will also complain the loudest about how they feel disconnected from the decisions and from the product IME.
Decisions rarely need to be made on-the-spot in synchronous meetings. You can have asynchronous approaches with shared documents and RFC processes, where you make everything available if people want to contribute to areas that they find interesting. This does not, of course, mean that decisions need to be made by committee, and people who provide feedback should understand that getting the privilege to provide input does not mean that they also get a veto.
It's quite rare to find companies that do this for the same reason it's quite rare to find companies willing to "do agile correctly" and really scope out work before sprints and not put additional work in the middle of a sprint. It takes too much effort and gives up too much flexibility for most managers to make the investment and see if it pays off.
No, it's a concern if you care about impact. Improving commercial profits is one kind of impact that is relevant to for-profit corporations, but there is also impact like "improving user privacy" or "helping lower-income people manage their finances with a free-as-in-beer product". This impact can be measured and the feedback can be used to improve the product according to non-profit, non-commercial goals.
There are also people who build open-source software as a hobby and couldn't give two shits whether other people use it or not. More power to them. For those people, you are correct. https://book.iced.rs/philosophy.html comes to mind.
Then there are projects like Streisand (maybe a bad example, I see it has since been archived, but it came to mind) that want to change the world in some way. Those projects very much do need to care about metrics like, how many people are downloading the software, are people opening GitHub issues, are we obscure or is our target audience talking about us, hopefully positively but if not, how can we improve that? Value must always be worth the cost (even when the code is free, it must be worth the time to download, give it a try, give it CPU/RAM, maintain/upgrade the installation) - are we giving users value or are they churning?
It might blow your mind but even non-profits hire people with MBAs (and universities offer programs for MBAs that focus on non-profit management), precisely because some organizations focus on non-financial impact.
> Even if you RAID them, there's not a good way to move that VM to another host if there's a RAM or CPU or other hardware issue on that host.
This is the critical point. All hardware fails eventually. The CPU and RAM are, in a real sense, also ephemeral. The only relevant question is what the risk tolerance of the use-case is. If restoring from async backup is sufficient, then embrace ephemerality and keep backups. If you need round-the-clock availability, pick an architecture that lets you fall over gracefully to another machine, and embrace the ephemerality when you inevitably need to do so.
reply