The other issue with linking is that the "best" in the windows market is that it's heavily dependent on current promotions. It's easy to find windows laptops discounted >20% which really throws off the direct comparisons at retail prices.
I like and recommend this one, but I also think he pulls a lot of sleight-of-hand... a lot of it is based on the premise that the client is willing to share (or can even get, in big enough companies...) numbers that inform the value created. For a tech consultant bopping between companies and industries, it's really challenging to come up with these numbers. Likewise, I found that even if you can prove a number, getting a big company to bite on it (unless you are truly talking to a Cx0) is nearly impossible... case in point... a major west-coast health care company had a crisis. I found the problem and laid out a path for a few million dollars to solve the problem. It was somehow way easier to pay IBM $50MM to "solve" the problem rather than the $10MM or less by actually fixing the problem. You run into a lot of that at the Fortune 500, which makes it clear it isn't about "value". Weiss seems to gloss over a lot of this.
I was and I wasn't - and in fact we knew we didn't really have a shot at getting to the economic buyer who made the choice to spend stupid money. But that's kinda my point - most of us are talking to mid-level management and down when we are interacting as solo operators / small consultancies into larger clients. That Director you are interacting with likely doesn't have the authority to authorize anything beyond a consulting contract at $xxx /hour as they are going to have someone in finance scrutinizing their spend.
I'd agree with this - Weiss covers really everything he has to say in this book and many of his other books like Value Based feel like a way for him to capture additional book sales as much as having something new to say.
A couple years ago I switched from Google Docs to Obsidian.
Unfortunately, as other have mentioned, Google Docs omits some seriously impactful features.
All it would've taken, at the time, was collapsible/foldable headings for me to stick with Docs.
But since then, I've grown to appreciate the millions other things Obsidian has to offer, like the ease of developing plugins which, to me, make Obsidian feel like it's an OS within my OS.
There are great places to work in-person, for example, any of Musk's companies which have missions that require extreme levels of communication and dedication that can only be achieved through colocation. This makes it worthwhile.
And it's great for other people to be able to choose something more flexible, whether for family or some other desire, and be able to leverage the benefits that remote work provides.
But even in small company, it's absurd to think that there's a single answer to "which is better" for every employee.
What's more absurd is that the executive-level positions tend to be more flexible. If anyone's to benefit from in-person communication and spontaneous interactions it's those making decisions that impact those people.
As an outsider, neither employee or employer, to me the whole thing looks like an abusive relationship, particularly egregious on the employer side, but not without problematic actions from the employee side either.
And while HN is an outlier, most people work to survive, not the other way around. Imagine if the same energy that went into promoting RTO, or even WFH for that matter, went into "enabling individuals to make worthwhile contributions and feel good about what they do."
Queue the "people are lazy and can't be trusted" and "basic income is the only answer" choir.
Ironically, I think ensuring that people don't starve and become homeless during durations they are unemployed (which unemployment insurance/payments doesn't really do in many locations), is actually a good idea.
It'll be nice to move away from "work because if I miss it we'll be homeless" to "work because I enjoy what I do, and can contribute positively in the field."
There are people who actually enjoy doing those things.
eg: I have a friend who hates this post covid trend of walmarts closing at 11 now, because he used to genuinely enjoy overnight stocking shifts while working on school during the daytime.
> for original art to flourish, there comes a time for the artist to seclude themselves and create without market pressures, the influence of popular culture and daily distractions. Us devs can learn much from him.
What irks me is its default behavior. A function should do safe operations by default. Compared to `JSON.stringify()`, 'structuredClone()` throws an error when it encounters values that cannot be cloned, which is a much saner approach. Probably because they learned from the mistake.
I understand your point and I can’t deny that Javascript continues to introduce weird, silent failures and quirks even today when everything is a bit more thought out than “the bad old days”.
But I think in the case of JSON.stringify it’s more about use case. 99% of the time, users of this method are taking some data and serialising it to a JSON compliant form to send to the server. JSON doesn’t support functions, or complex objects like a Date, so I tend to think it’s a reasonable default that functions disappear and Date’s are converted to an ISO standard. To insist that every single user runs a preparation step that strips out unserialisability data and chooses how to handle Date objects sounds laborious, error prone, and ripe for another npm dependency everyone suddenly normalises for every project.
Maybe a “strict mode” of some sort where you could have it throw on anything for cases where you need to guarantee everything is being sent?
OTOH, I have to concede that while this method has silent failures, they then implemented JSON.parse to throw at the slightest issue. So I have to admit there’s consistency even within the API.
I guess there's some good reason nobody ever did it, but what about throwing an UnhandledType kind of error and letting the catch() decide how to deal with the object in question?
On top of the compatibility issue mentioned in sibling comment, the existing behavior also matches the principle of keeping simple things simple without making complicated things impossible. If you want stringify with a check for unhandled elements, that's easily specified in a replacer (that does not really replace).
You might prefer some well established standard implementation over ad hoc roll your own, but that's a discussion about npm culture, not about stringify.
The problem I see with this is that whatever you’re sending this to must have knowledge of the meta information superjson produces, so at that point you’re investing in it as a wrapper library. The fact you can extend the types it serialises also complicates things and means the receiver needs further implementation specific knowledge.
I think in my original comment, I was imagining a world where JSON.serialize threw errors on unknown types and we needed a wrapper just get basic JSON out of it.
