marketers are not designers and vice versa. of course the press release is going to be melodramatic no matter what the designers thought, or were told

“Marketers are not designers” is fine, except it was the designers themselves pushing the marketing drivel in those videos.

Who was driving that, though? If the project has high-level management buy-in, the people in the scripted videos are going to be on message if they want to stay employed.

This reads like “ChatGPT is a better programmer than me, so I let it do all the work”

You have a real obligation to learn how to drive. Your examples indicate neglect to take the safety of your family and others’ seriously

I stopped at "this reads like ChatGPT" but maybe I'm old and cynical :/

Agree with your take 100%.

Other than yelling at people, how are you getting drunk drivers off the road? Even though it's not perfect this shit works better than those assholes. Don't let perfect be the enemy of the good. Unless you're volunteering to drive Uber for free for everybody everywhere, telling people to just be more responsible hasn't worked in the whole history of humanity.

(1) could be answered with container query units. Set `container-type: inline-size;` on the parent element (falls back to the whole viewport if unset), then use, e.g., `width: 50cqw; height: 50cqh` in children. The value is a percentage of the given axis

Isn't size of the parent element, what the percent values are relative to?

I don't think that works if you want to mix "proportion of available space" units with siblings that have a fixed size (a super-common use case for flexbox - having a fixed size box followed by another box that takes up "the rest of the space").

this issue was caused by a framework that's trying to do too much, relying on "magic" interfaces to supposedly reduce developer burden. the function is very unambiguously written and the language did nothing wrong

I also support using whatever language you and your team prefer when you can. that's the glory of backend: no restrictions on what you can run. but sometimes you need to write client software, and those are strictly easier to manage in the platform's native tongue: Swift, Kotlin, JS, and so on

> this issue was caused by a framework that's trying to do too much, relying on "magic" interfaces to supposedly reduce developer burden. the function is very unambiguously written and the language did nothing wrong

The function is unambiguously written, but the runtime functions differently, and this is not a language problem? This is incoherent; one of these statements is incorrect.

> the function is very unambiguously written and the language did nothing wrong

The language absolutely did something wrong, by trying to evaluate a non-boolean type as a boolean. That is a horrible footgun and JS is absolutely at fault for doing so.

I do this too. I’ve been led to believe it’s a symptom of OCD, which I absolutely express in other ways

The code, all of it, is just an implementation detail. All that matters is real world behavior and its consequences.

And if it doesn't perform as expected in the world, all human efforts should be on fixing the actual code. Anything else, especially non-technical conversations, is a waste of human time.

Sure, but the police or feds or FAA aren’t responsible for fixing it. They’re just enforcement

I've been my own manager more than once and on teams from a few folks to a couple dozen in size. Rigid schedules and expectations absolutely make me less productive. My last 2 startups were chock full of fast paced, high quality work that got us off the ground and up to hundreds of thousands of users with me as the single engineer building apps for web, iOS and Android by myself. That is, until we hired engineering managers who tried too hard to get a glimpse inside my head, after which productivity dropped off a cliff. My current startup now has around 10 app devs and it feels like we deliver fewer features over longer timelines at a lower bar for quality than ever.

Yep, I’ve seen this in Swift with a dozen overloads for functions and class initializers to support umpteen similar, but different, types as input. Sloppy schema design reveals itself in combinatorial explosions of type conversions

Yes. I don't understand why HN reacts with such froth to the suggestion that this problem runs deeper than type systems.

The rule is spaces on both sides of an en dash – like so – or an em dash without any spaces—like this. Important to note the US keyboard layout does not have either of these or the minus glyph, just the hyphen, and it’s unadvisable to mix multiple styles