CipherThrowaway

If I took this attitude then I'd be excluding myself from relationships that are a net positive in my life. Mismatched sex drive is genuinely not a big deal for me. Often we're both on the same page and that's great. But when we're not, it's not a huge deal for me to have sex I don't want just to keep the peace. In my view, it's no different to other forms of compromise and sacrifice in relationships. Furthermore I think this is common in relationships. To maintain a stable relationship, low libido partners often do have to "make an effort" and manage some of the pressure that comes from dating a higher libido partner.

IMO in an ideal world there would never be any pressure or obligation associated with any interaction. But in the real world, "okay" must have a wide enough margin to include situations that aren't ideal but are limited in terms of harm caused and moral responsibility of participants. It can't be that I am a rape victim for not wanting to hurt my partners feelings by sexually rejecting them. Some pressure is surely okay.

I have the lower sex drive in my relationships and experience a concomitant pressure to have sex when I don't want to. I'll often say yes to avoid a fight, avoid upsetting my partner or to stop them from nagging me. This has never seemed like a big deal to me although it is sometimes a nuisance. How does this square with your PoV? Is it rape? Maybe it doesn't count as "real" pressure?

I'm not trying to minimize the issue or trip you up here. There is obviously enough coercive and violent SA taking place for it to be a major social issue no matter how broad the definition is. I'm trying to figure out how pressure as a sufficient condition for rape squares with the lived experience of people like myself who do frequently feel pressure to have sex.

Depending on where you are in the world, the salmon you eat raw isn't the same as the salmon you eat cooked. There are extra requirements around sashimi grade salmon such as flash freezing to kill parasites.

The risk profile is not the same as eating undercooked salmon that is not intended for raw consumption.

Just found that out the hard way.

Back up for me

>Despite my technical ignorance, my contribution to the debugging exercise came in two forms. For one, to look for blind spots, areas that a developer would normally not look.

My condolences to whichever dev had to debug this problem with this architect hanging over his shoulder giving "helpful" suggestions and taking credit for the result. What a rort.

Lame take. Especially given the author's own use of adverbs. "My superiority complex is superior to your superiority complex" inter-nerd contrarianism.

From the other half of that sentence:

> underestimates how quickly an investment in doing things "the right way" pays off.

What time horizon should a startup optimize delivery for? Minutes, hours, days, weeks? Say you're a startup dev in a maximalist "get shit done now" mindset so you're skipping types, tests, any forethought or planning so you can get the feature of the week done as fast as possible. This makes you faster for one week but slower the week after, and the week after, and the week after that.

Say a seed stage startup aims for 12 months runway to achieve some key outcomes. That's still a marathon. It still doesn't make sense to sprint the first 200 meters.

Totally agree. That's why I clarified:

> I'm sure Rust was the wrong tool for the job in your case but I find this type of get shit done argument unpersuasive in general.

Unless you're working on a fire-and-forget project with a tiny time horizon get shit done arguments are blatantly short-termist.

The entire point of doing things the right way is that you end up delivering more value in the long term, and "long term" can be as soon as weeks or even days in some cases.

Business owners definitely prefer less bugs, less customer complaints, less support burden, less outages, less headaches. Corner cutting doesn't make economic sense for most businesses and good engineering leadership doesn't have much trouble communicating this up the chain. The only environment where I've seen corner cutting make business sense is turd polishing agencies whose business model involves dumping their mistakes on their clients and running away so the next guy can take the blame.

At some point, every engineer has heard this same argument but in favor of all kinds of dubious things such as emailing zip files of source code, not having tests, not having a build system, not doing IaC, not using the type system, etc.

I'm sure Rust was the wrong tool for the job in your case but I find this type of get shit done argument unpersuasive in general. It overestimates the value of short-term delivery and underestimates how quickly an investment in doing things "the right way" pays off.

This isn't a Netflix sci-fi. A single startup is not going to diametrically reverse climate change by planting some GMO trees.

Yes, I use this regularly. It is a basic necessity for night driving now.

Halogen headlights were significantly lower lumens, lower color temperature and more diffuse. That's not rose tinted glasses. It's fact.

No one is forgetting that there were badly adjusted halogen headlights or misused high beams. The point is that despite this we didn't have anything close to the blinding landscape of the modern road.

Of course the solution must be some swiveling IoT Rube Goldberg light. We simply don't have the technology to dim the lights or adjust the hue.

Truly sick of hearing about "misalignment" and other nonsense from LEDsplainers and apologists. No alignment is going to fix the issue of giant trucks and 4WDs tailgating other drivers and blasting thousands of lumens into the cabins of their cars. The fact that modern LED headlights need to be within a Goldilocks zone of multiple operating parameters simply to avoid blinding other drivers is an inherent problem of these headlights.

The amount of ink spilled over LEDs is incredible when you consider how simple the situation really is. For decades we managed to have cars with headlights that didn't constantly blind and dazzle other drivers. Now we don't. Regulators need to sort it out.

I think it will go in the opposite direction. If the over-application of junior engineers is the cause of distributed spaghetti architectures then AI is set to make this much worse by driving the business cost of (virtual) junior engineer labor to near-zero.

Once AI is good enough to fully replace juniors, it will become impossible for senior developers to compete in productivity on code alone. Almost all code will be written by AI and senior talent will be operating at the higher level of wrangling AI code and containing it in some sprawling microservices spaghetti ball.

Honestly this isn't so different to the general trend of the last 6 decades. We cheaply "outsource" code to compilers and third party libraries and end up with systems that are globally inefficient but much more economical to build. AI is just going to be the new ultra high-level programming interface.

Surely exposure from composite resin falls off quickly over time and pales in comparison to our constant environmental exposure to plasticizers. Any data on this?

Although it is certainly written by a human being, this article gives me a similar feeling to ChatGPT essays. The tone is compelling and plausible. But when I thought about it, I realized it didn't make much sense.

> Rarely do we even consider that the cost of doing something might outweigh the benefits.

Cost vs benefit is the main thing that people consider when making decisions. It's a core decision making framework taught as early as elementary school social studies. Institutional decision making is rife with processes for assessing risks and performing cost-benefit analysis.

> Intervention—by people or governments—should only be used when the benefits visibly outweigh the negatives.

This advice is the decision making equivalent of "just don't write code with bugs." Easily achievable but pretty useless and completely impractical. Real world decision making involves operating under uncertainty at almost all times. If it didn't, the topic wouldn't be worth writing articles about.

Non-ADHD weaker clutter tolerance means that lots of people need to hide stuff to keep it from bothering them.

Clutter intolerance can have a profound impact on daily life for sufferers. Many will engage in maladaptive coping strategies such as ritualistic tidying and avoiding cluttered rooms or spaces. Whether tolerance can be improved through therapy is an area of active research. Unfortunately, clutter intolerance is thought to be neurobiological.

Hard to see how this meshes with published evidence about the role and importance of environmental and lifestyle factors in stress, well-being and burnout.

If anything, getting older is strongly moving me away from your mindset. To the extent that well-being is intrinsic it seems to be more about the causal relationship to environmental factors. Some people are better at managing workload, setting boundaries, avoiding stressful situations and finding a "scene" that fits their values and abilities. I've seen these people do very well.

There are plenty of people out there ready to tell you that happiness and well-being are all about attitude. But when I look at the people in my own life who have said this none of them have been particularly happy or seem to have figured things out for themselves. And it's no coincidence that some of the strongest advocates for "individual responsibility for happiness" are bad bosses and abusive spouses who have a vested interest in keeping people in bad environments.

To me, stories like this one read more true to life: https://news.ycombinator.com/item?id=34406760#34409368.

Deeper comparison doesn't solve the problem because input order is arbitrary. The order may be based on a user dragging items around in a list widget, for example.

The easiest way to transform an unstable sort into a stable sort is probably mapping input from T -> (Index, T) and including the index as a sort key.

Don't disagree there. Java support is less than a year old and the Java API is.. not great. TypeScript is the more popular and mature choice.

I was at a place 7-8 years ago with a hand-rolled JSON parser that had been written across a few afternoons by one guy without much ceremony. It was untouched after that aside from some renaming and other minor refactors. As usual with these things, the decision to hand-roll was made by one very opinionated dev who got his way because the business depended on him.

When that article was published it started an argument among the team. The guy ended up implementing the test suite to defend his decision. To my surprise the parser passed all tests apart from 3 or 4 unicodey-ones where it was more permissive than it should have been. There were plenty of production bugs at this place but none of them were due to the parser.

IMO parsing JSON really is simple. If you read through the article you'll see that most of the test cases are dead simple and hardly landmines.

For simple use cases like key-value style config you can use JSON or TOML without too many issues.

For IaC the alternative is general purpose programming languages using declarative infrastructure APIs. E.g. TS, Go, Python with CDK, CDKTF, Pulumi. For CI are stuck with YAML for now.

> Thinking that JSON is a suitable replacement, imagine writing Ansible or k8s stuff in it; that would be fun ;)

Writing in YAML doesn't feel much better. YMMV but I've been on teams using Pulumi for k8s and the developer experience has been significantly better. I can automate, type check, lint, click through to definitions the same way I do with other typescript.

Pulumi is a young product with many rough edges but it's already been a game changer for me.

>I believe that the that fundamentals of crypto are incredibly useful and will eventually be adopted, and have been in meany places, but all the web3/NFT/etc stuff (whatever that means) is just useless hype and ponzi schemes.

Could you elaborate? It's been 15 years since the bitcoin paper and I still don't see where the game changing commercial applications of crypto are beyond the black/grey market uses for which it has already been adopted.

I wouldn't put much stock in this. Sometimes people will say this and mean it and other times they won't and the only way to feel the difference is non-verbal + context. There is no book of hidden phrases, signals or cheat codes.

Honestly I would approach the entire article with skepticism. Guys like the author are mostly dogs barking at the mirror. The underlying philosophy that socialization has a fixed set of rules that can be gamed and optimized is faulty.

I've had good experiences with Google Cloud Scheduler. https://cloud.google.com/scheduler

Reducing mismanagement and fixing systemic issues will pay greater dividends than just having workers "step up."