solatic

The way the post is written, I wonder if the author is working for a company going through a growth spurt and where, through sheer size, everything is becoming more "corporate".

There's a huge difference between having AI clean up a text you send privately to someone you have worked closely with for years, versus a broad spectrum text sent by a VP to hundreds of people or more. The first case is reprehensible, for the reasons the author lays out. But as for the second case, corporate doublespeak has been a meme since long before the advent of AI and it would remain even in some AI-pocalypse. Just because your boss puts out sanitized language in a mass communication, doesn't inherently mean your boss won't still be present and real with you in a more private setting.

The larger you are, the larger the rounding errors are, the more money that can disappear due to a failure and explained away or extended or written off or whatever euphemism you want to pick. But the sum of rounding errors is less likely to itself be a rounding error. It works until it doesn't, and Evergrande collapsing with $300 billion in Chinese real estate debt will be a case study for years to come.

To add some context -

> Imperfect enforcement is too easy for law enforcement officers to turn into selective enforcement. By choosing who to go after, law enforcement gets the unearned power

This is by design, in an American context of building a free society. By default, you are allowed to do whatever you like to do in a free society. To constrain behavior through law, first a legislator must decide that it should be constrained, then they must convince their legislator peers that it should be constrained, then law enforcement must be convinced to attempt to constrain it de-facto, then a judge must be convinced that you in particular should have a court case proceed against you; a grand jury must be convinced to bring an indictment, a jury of 12 peers must be convinced to reach a verdict, and even afterwards there are courts of appeal.

The bar to constrain someone's freedom is quite high. By design and by wider culture.

Average daily USD-NIS trading volume (per Bank of Israel: https://www.boi.org.il/en/communication-and-publications/pre... ) is on the order of magnitude of about $15 billion.

There are multiple founders getting billions of dollars each. It's not so unreasonble to fear what could happen if daily trading volume suddenly had a significant increase from them collectively dumping billions of dollars onto the market on the same day to settle the tax bill.

> laptop for a computer science student ... most likely outgrow 8 GB RAM faster than laptop CPU

A couple years ago I would have agreed with you. Today I'm not sure how reasonable it is to try to future-proof via expandable RAM. Imagine a hypothetical point a few years in the future where RAM factories have ramped up production and manufacturers are pumping out laptops with 512 GB RAM to enable running local LLM. You couldn't expand a current laptop to have enough RAM if you wanted to, so I'm not sure how reasonable it is to try to prepare for that future.

Agree that AI is a force multiplier in small-cap and a better search at best in large-cap due to internal bureaucracy.

The bigger question (that remains to be seen and played out) is whether AI will be a forcing function towards small-cap. If smaller companies can build the same products as larger companies with fewer people then they can compete on price and win, hollowing out the revenue base of large-cap companies and leading to their downfall due to the dwindling workforce not having the culture to adapt. Of course reality is more complicated (moats, larger companies making too-good-to-be-true offers to acquire smaller competitors to prevent the emergence of genuine competition, boys-club who-you-know-not-what-you-know corruption via lawfare ...) so, yeah, remains to be seen.

> 120Hz refresh rate would be nice to have, but there is no display I’m aware of that meets the macOS pixel density requirement while also providing faster refresh rates.

Is this still true, meaning, is the new Studio Display XDR the only option that is also Retina/HiDPI and also 120Hz? I've seen a lot of commentary dumping on the price, but if they're really the only option then they can charge whatever Apple Tax they want.

This is Netflix, they have thousands of engineers. So you have two approaches to solve the problem: either write enforced policy-as-code to prevent people from deploying images with too-high layer count (and pray they never need to rollback to an image from before the policy was written), thus incurring political alignment costs around the new policy and forcing non-compliant teams to adapt (which is time not spent on features); or, solve the problem entirely at the infrastructure level.

It's hardly surprising that companies consider infrastructure-level solutions to be better.

Hypothetically, the amount of money that could be negotiated away is something like the sum of net incomes of US pharma/med device/insurance/healthcare, which is something like $100 billion annually. which sounds like a lot but it's only about 2% of annual $5+ trillion spend. You can't negotiate prices to be lower than the associated costs, the companies will just close up shop instead of being forced to take a loss.

At the end of the day, the fundamental drivers of high healthcare costs are (a) high labor costs of high-skilled doctors, pharmaceutical researchers, etc. (b) high cost of procuring land and construction of new hospitals in major metro areas. The first requires you to fix education first so that doctors etc. do not need to take out and later pay back what can now easily exceed $500k in combined tuition and living expenses. The second is politically unpalatable.

> Is it this MBA idea that management itself is a profession

I don't think that you can take somebody with a finance background, take them straight out of their MBA, and drop them in an EM position. That's a bad fit. Good EMs need to come from software engineering backgrounds, mostly for the reasons you cite.

But management truly is a different profession with a different set of skills and a different set of challenges.

Even on the IC track, there's languages and frameworks that I touched early in my career (e.g. Java/Spring) and haven't touched in, I don't know, a decade, and I have not been keeping up with whatever is most recent best practice there. If I were to go into an IC role for one of those frameworks, I might as well be going into an IC role for a language I haven't learned before, ever. I expect someone who has been working with that language on a daily basis to really, really know it - having the standard library practically memorized, knowing common pitfalls, doing a lot of stuff from muscle memory, someone who you give them a PR that "looks OK" and they start reading and immediately can say "well that's just not even remotely idiomatic".

EMs are almost guaranteed to lose that touch because their day job is talking to people, not writing code. That's not to say that they couldn't go back to the IC track and start to sharpen those skills again, but EMs with FOMO who try to stay in the code are spending that time not talking to people. The lack of focus makes them bad EMs.

No priest will feed sufficient context about their community into the context window - even if they were skilled enough to do so, unless the model was locally hosted, doing so would be a violation of their vows of silence.

Good homilies are written with the particular community in mind. If it were more effective to write a homily for a generic public, the Vatican would have started publishing standard homilies long ago.

Perhaps, but the larger question is whether the price of hydrogen itself can be sufficiently reduced. $36/kg is not justifiable for distance trucking or planes. If the price of hydrogen dropped sufficiently, then there's more demand to build hydrogen infrastructure, which increases demand for hydrogen in smaller vehicles, etc. in a positive feedback loop.

That theory didn't play out, mostly because the price of electrics kept dropping year after year, undercutting any appeal in early investment in hydrogen.

OpenAI is dependent on same hyperscalers (most specifically Microsoft/Azure) as everyone else, and even have access to preferential pricing due to their partnership.

A better explanation is to point out that ChatGPT is still far and away the most popular AI product on the planet right now. When ChatGPT has so many more users, multi-tenant economic effects are stronger, taking advantage of a larger number of GPUs. Think of S3: requests for a million files may load them from literally a million drives due to the sheer size of S3, and even a huge spike from a single customer fades into relatively stable overall load due to the sheer number of tenants. OpenAI likely has similar hardware efficiencies at play and thus can afford to be more generous with spikes from individual customers using OpenCode etc.

I have no idea how you got that from my comment. How much you make, how much you save, how much you spend, and how much you give away are all independent, and neither is it a zero-sum pie (for example, sometimes investments go down in value, and sometimes the line between giving away and spending is blurry).

To answer your question directly, $70k income is independent of the cost of living in high cost of living cities (like NYC or SF) vs. low cost of living areas. If you make $70k/year in NYC, no you don't have the spare income to max out 401k/HSA. If you make $70k/year working for Walmart in Bentonville, Arkansas, then yeah, I expect that you ought to be able to max them out.

Sure, but if the economics of hydrogen motors worked out for planes and shipping, the argument is that it would also economically work out for cars.

I sympathize with the author, and in principle I find myself nodding along with his prescriptions, but one of the benefits of Dependabot (and Renovate) are that they are language-agnostic. Depending on how many repositories, and how many languages, and upon whom the maintenance burden falls, there's a lot of value to be had. It may not really be feasible to add "the correct" CI workflows to every repository, and the alternative (nothing) inevitably ends up in repositories where dependencies have not been updated in years.

It's good optimization advice, if you have the time, or suffer enough from the described pain points, to apply it.

There are three things you can do with your money - save it (e.g. investments), give it away (e.g. charity), or spend it (e.g. housing, vacations). Whether or not somebody's investment strategy (i.e. saving) is optimal for their income level has nothing to do with the frugality of their lifestyle (i.e. spending).

A lot of people are often surprised at how non-frugal their lifestyles are. I'm not suggesting that people living on $50k/year aren't already frugal, but yeah, there's definitely people who take out car loans, take out mortgages for the full amount they were approved for, and all sorts of random things like buying chicken parts instead of whole chickens, buying small grocery store containers instead of bulk pricing for shelf-stable items, keeping your speed down to save gas, etc.

You really just need to build an innate understanding that the hedonic treadmill doesn't make you happier long-term and develop a resolution to get your expenses down and stay disciplined about it.

The RFC wording is a little weird. If the zone has DNSSEC configured, then the wording should be stronger and use MUST wording, and not imply that CAs will be compliant if they choose to avoid verifying signatures despite the presence of signstures. Likewise, these TXT records for dns-persist-01 ideally "SHOULD NOT" be deployed when DNSSEC is not configured.

I'm surprised that this doesn't require DNSSEC or at the very least actively encourage configuring DNSSEC. While I used to be fully in the camp that DNSSEC was way more trouble than it was worth, in particular when access was de-facto secured by trusted CA certificates, more and more DNS record types (CAA, CERT, SSHFP, these TXT records) are responsible for storing information that can be manipulated in MITM attacks to seize control of a root of trust.

Of course, this has little applicability to anyone who is small enough not to have nation-state level actors in their threat model. But when I look behind the curtain of even Fortune 100 companies that really ought to have nation-state level actors in their threat model, too often you find people who are just not operating at that level or are swamped with unrelated work. So I'm starting to become of the opinion that guidance should change here and at the very least be documented recommendations - if it's not encouraged down the organizational size scale, too often it's not applied further up where it's needed.

> tents don't need to be strong in compression - there's no weight on the roof

But there is on the floor, unless you expect the inhabitants to sleep more or less directly on the ground, including themselves, whatever is used as a mattress, belongings, small appliances, etc. Emergency habitation is not the same as a camping tent, it needs to be able to service populations that have difficulty with camping's limitations, like the elderly.

> Paper is not a material that scales up

Citation needed? It's made from a renewable resource (wood) and there's some 400+ million metric tons of paper production yearly (source: Gemini, so feel free to take with a grain of salt).

> Or would be practical for outdoor use

If exposed directly to the elements, sure. But what if the paper is laminated or otherwise enclosed within plastic, rubber, or other synthetic material well-recognized as hydrophobic?

> a footgun is a surprising defect that's pointed at your foot and easy to trigger

Close, but not the way I think of a footgun. A footgun is code that was written in a naive way, looks correct, submitted, and you find out after submitting it that it was erroneous. Good design makes it easy for people to do the right thing and difficult to do the wrong thing.

In Rust it is extremely easy to hit the borrow checker including for code which is otherwise safe and which you know is safe. You walk on eggshells around the borrow checker hoping that it won't fire and shoot you in the foot and force you to rewrite. It is not a runtime footgun, it is a devtime footgun.

Which, to be fair, is sometimes desired. When you have a 1m+ LOC codebase and dozens of junior engineers working on it and requirements for memory safety and low latency requirements. Fair enough trade-off in that case.

But in Zig, you can just call defer on a deinit function. Complexity is the eternal enemy, and this is just a much simpler approach. The price of that simplicity is that you need to behave like an adult, which if the codebase (hotpath optimization) is <1k LOC I think is eminently reasonable.

> The point is, even if I were Jesus Christ himself, someone would find a flaw that makes me undateable in their opinion.

Well yeah, Christ isn't really dateable because he would never be able to be vulnerable with you (after all, if he died for your sins, you can't really repay the favor, can you?). People want to take celebrities to bed, they don't want to date them. It's a different kind of relationship - more shallow.

But more to the point, a flaw is not what makes somebody undateable. We all have flaws. I have flaws. My partner has flaws. Some kinds of flaws make people undateable, others do not.

> Someone who still believes in Santa Claus

I mean, my partner makes me happier than Santa Claus ever did, and I don't have to wait until Christmas for her to pay me a visit, so....

> point to money as an example of an advantage of being in a relationship, not emotional support

Emotional support was literally the first example I gave ("feel good, warm, and fuzzy inside"). I added the economic argument to address your framing. The emotional aspect is the #1 most important reason and I would be in my relationship for that reason alone, even without any economic benefits; the economic benefits are a silver lining and insufficient on their own to justify a relationship. But no, I'm not going to pretend that the silver lining doesn't exist.

Eh, I'd say that Rust has a different set of footguns. You're correct that you won't run into use-after-free footguns, but Rust doesn't protect you from memory leaks, unsafe code is still unsafe, and the borrow checker and Rust's language complexity are their own kind of footguns.

But I digress. I was thinking of Zig in comparison to C when I wrote that. I don't have a problem conceding that point, but I still believe the overall argument is correct to point to Zig specifically in the case of writing code to optimize a hotpath behind FFI; it is much easier to get to more optimal code and cross-compilation is easier to boot (i.e. to support Darwin/AppleSilicon for dev laptops, and both Linux/x64 and Linux/arm64 for cloud servers).

To each his own, but while I can certainly understand the hesitancy of an architect to pick Zig for a project that is projected to hit 100k+ lines of code, I really think you're missing out. There is a business case to using Zig today.

True in general but in the cloud especially, saving server resources can make a significant impact on the bottom line. There are not nearly enough performance engineers who understand how to take inefficient systems and make improvements to move towards theoretical maximum efficiency. When the system is written in an inefficient language like Python or Node, fundamentally, you have no choice but to start to move the hotpath behind FFI and drop down to a systems language. At that point your choices are basically C, C++, Rust, or Zig. Of the four choices, Zig today is already simplest to learn, with fewer footguns, easier to work with, easier to read and write, and easier to test. And you're not going to write 100k LOC of optimized hotpath code. And when you understand the cost savings involved in reducing your compute needs by sometimes more than 90% by getting the hotpath optimized, you understand that there is very much indeed a business case to learning Zig today.

> friendly, responsible, honest, not poor... keep the house clean

Even assuming I take you at your word, this describes a good roommate, not a good romantic partner.

> do sports, learn new things

Has negligible if any effect on romantic relationships. Both fat and stupid people still find romantic partners (and sometimes end up happy with them nonetheless).

> Then the fuck more you want

Somebody who is fun to be with, who makes me feel good, warm, and fuzzy inside, who at times makes me feel safe and at other times dares me to go farther. Somebody who is willing to go to new depths of vulnerability together, so that I can trust that they see me, the whole me, even the crummy parts, and I can see them, the whole them, even the crummy parts, and be loved and accepted nonetheless.

> The value of "a relationship" has dropped through the floor

This is transactional language. Strong, fulfilling romantic relationships are not transactional. Part of working on yourself is learning how to develop non-transactional relationships without getting hurt / getting exploited in your attempts to do so (i.e. by lemons on the market).

> more convenient to live single than to deal with the inconvenience of living with another person

I highly disagree, assuming that you find the right person to live with, which is the whole challenge. Living with another person who you enjoy living with, economically speaking, means splitting at least rent and electric bills (water bills are more linear with the number of people in the house), sometimes splitting a car payment (if you are a one-car household); when you split rent, you split the rent of the kitchen, the bathroom, the living room, and at least one bedroom, that are all shared. You eat better by cooking for two and sharing. The absolutely most economical arrangement is usually Dual-Income No Kids (DINK).

People who have difficulty on dating apps want to find a scapegoat, so they scapegoat the app.

The truth is that dating markets are lemon markets. People who are "dateable" tend to find success quickly, and people who are "not dateable" tend to stay on the market. Hence over time, the market will be dominated by "not dateable" people. No dating app on the planet will magically make you a "dateable" person.

To find success on dating apps, you have to work on yourself first, and only afterwards make sure that work shows through both in your profile and in your texting.

Source: was on the apps, undateable for eight years (depression and low self esteem), went to therapy, after making huge changes to my life and getting to a point where I felt like things were going well in everything but being single, a month later I found my girlfriend (now two years together).

If employees get stock options and decide to exercise on exit, they count against the 500 unaccredited investor limit that would trigger reporting requirements. So companies that issue stock options do have an outside risk that enough employees will exit, exercise their stock options, and trigger a reporting requirement.

> I started dreading the monotony of it all... My days had become predictable: check the dashboards, respond to tickets, debug whatever broke overnight, push some Terraform, go home. Maintain the HashiCorp Vault clusters, manage the secrets pipelines, answer the same support questions. Repeat. The work that used to feel engaging had become routine.

Why are you checking dashboards (pull/polling) instead of building alerting (push), so that you do not need to check dashboards as a matter of routine? If the tickets are dealing with the same problem again and again, why aren't you building a self-service platform to let your users handle these problems by themselves (especially now that LLMs are making this much more trivial to build)?

Author sounds like he had poor technical management who didn't understand DevOps (let alone DevSecOps) and turned it into an operations role.

Everything that the author likes about Solutions Engineering, I get from a DevOps role, from collaborating with other engineers in my company to make them more agile, productive, and take better ownership in production. Too many engineering teams fall into a trap of not being allowed to focus on any non-functional work (gotta ship revenue-generating features!) and LOVE it when someone like me comes along, who doesn't answer to Product, and can help them out on the non-functional side. I get to talk to "customers" as much as I want, in a role where I can just walk up to them and not need to communicate over Zoom or with significant plane travel.

Author should have considered trying to just find a different Platform Engineering role.

> There should be some balanced path in the middle somewhere, but I haven’t stumbled across a formal version of it after all these decades.

Well, there isn't a formal version of it, because the answer is not formal, it is cultural.

In enterprise software, you have an inherent tension between good software engineering culture, where you follow the Boy Scouts' principle of leaving a codebase cleaner than you found it, and SOC2 compliance requirements that expect every software change to be tracked and approved.

If every kind of clean up requires a ticket, that has to be exhaustively filled out, then wait for a prioritization meeting, then wait for the managers and the bean counters to hem and haw while they contemplate whether or not it's worth it to spend man-hours on non-functional work, then if you're lucky then decide you can spend some time on it three weeks from now and if you're unlucky they decide nope, you gotta learn to work within an imperfect system. After once or twice or trying to work By The Book, most engineers with an ounce of self-respect will decide "fuck it, clearly The System doesn't care," and those with two ounces of self-respect will look for work elsewhere.

Or, you get together with the members of your team and decide, you know what, the program managers and the bean counters, they're not reading any of the code, not doing any of the reviews, and they have no idea how any of this works anyway. So you collectively decide to treat technical debt as the internal concern that it anyway was in the first place - you take an extra half hour, an extra day, however long it takes to put in the extra cleaning or polish, and just tack it on to an existing ticket. You give a little wink and you get a little nod and you help the gears turn a little more smoothly, which is all the stakeholders actually care about anyway.

You cannot replace culture with process. All attempts to replace culture with process will fail. People are not interchangeable cogs in the machine. If you try to treat them as such, they will gum up and get stuck. Ownership and autonomy are the grease that allows the human flywheel to spin freely. That means allowing people to say, "I'm going to do this because I think that it is Right And Good For My System Which I Own", and allowing them to be responsible for the consequences. To pass SOC2, that means treating people like adults and allowing them to sometimes say, instead of "can I get this reviewed because I legit need another set of eyes to take a serious look?", to say "can I get a quick rubber-stamp on this please?"