_greim_

Those technologies aren't examples of formats succeeding purely on their merits, so much as being established safe paths through a legal minefield.

> Even though LED bulbs have no such limitations, a color temperature of only 2700K is often chosen.

I think there's a reason for this, which is that sunlight supplements indoor lighting during the day. People rely on indoor lighting more at night when those warmer tones are most desirable.

> The ethanol extraction process leaves a mash which is then fed to cows.

Do analyses typically factor this sort of thing in, or do they assume corn is grown solely for the purpose of ethanol extraction?

> When code calls for a maximum distance between electrical outlets, that's partially for convenience, and partly because of unsafe practices with extension cords, so there's some blood there, but if you miss the mark by a foot, it's not disasterous.

I mean, it could be disastrous, couldn't it? That foot could be the threshold of someone saying "Aw screw it, I'll just use my parent's frayed extension cord from the 70s."

> But you have to care about the type with unknown?

It's better to say `unknown` is a promise that you won't care about the type. When you write `obj.value`, you're caring about the type. TypeScript sees that and says "hey, you promised you wouldn't care about this type."

> While calling it on an ant is valid typing

It's still invalid, same as if you'd used `unknown`. It just suppresses the type error. The presence of `any` in a codebase is a very real risk. The only reason it exists is to allow incremental porting from JavaScript to TypeScript.

There's plenty to be afraid of, but legit applications as well, for example automated announcements and voice menus where you can't pre-record every possible combination of things to be said.

Anecdotally, range anxiety drove me to pay an electrician to run a 50 amp circuit to my garage for faster charging, which has gotten us out of many "oh crap we have to leave in an hour and only have 10% charge" tight spots. It was crazy expensive since the electrician had to run a conduit around the entire house, but still an order of magnitude cheaper than buying a higher-range car.

This is probably not for every website, but an interesting trick is to set your root element font size to 1vw, which is 1% the width of the viewport.

Then size everything using rems, including the width of your layout. The whole design scales with the width of your browser.

It's unclear what "serving the center 80% means" but I doubt it means banning the remaining 20%.

This is good advice, but it shouldn't stop you from reaching out to people during and after a crisis. Sometimes you don't find out who your allies are until the road gets bumpy.

I've found generators to be a great way to keep separate concerns separate. Now you can have a function whose job is to figure out what the next thing is, then consume it eslewhere as a simple sequence.

In the past I'd have a function accept a `visit(x)` callback, but then I had to invent a protocol for error handling and early cancellation between the host and callback.

The ability to just `yield x` and have done with it is a breath of fresh air.

Cover your ass.

My theory is that devs often trade pretense-now for research-later. This habit allows them to gain ~0.002 status points here and there. But now combine that with unknown-unknowns. The thing they're hearing—if they actually understood it—ought to cause them to abandon or completely rethink a change they're currently working on. But because their takeaway isn't new knowledge, but a placeholder for potential new knowledge, they end up losing 15 status points when it blows up, in a way that was utterly unforeseeable.

Yes, I'm for sure describing a perverse incentive structure, but one that's easy to fall into, almost a default state. If you get enough well-intentioned people together they can break the cycle, and then you have a healthy team.

> Bottom right should be "points lost" imo.

There's a certain breed of hot-shot dev who truly believes they're gaining status by making cryptic, in-the-know references, and there's another breed who falls for it. When it comes to social status games, if enough people believe it, it becomes true.

> Understanding something doesn't mean you know how to explain it to someone else.

Too true. Explaining things is hard. My gripe is mainly people's tendency to pretend they understand in perpetuity, instead of expressing a modicum of curiosity about it. "What does 'TPS' stand for actually?" As mentioned, explaining things is hard, and I think I'm not alone in needing help identifying gaps in my explanations.

That said, I also understand that there are huge social barriers to admitting a lack of understanding in the tech industry, especially for juniors.

It's definitely a coping mechanism. When you've been burned repeatedly by people nodding vigorously in understanding, then turning around and revealing a complete lack of comprehension, forcing you to either intervene or allow the error to propagate, it's tempting to fall into a habit of pre-emptively explaining everything.

> The biggest problem I see in developer communication is what I call the "assumed context" problem.

Ah yes, the "shouting up from the rabbit-hole problem".

> people "on the spectrum" often having low "theory of mind" capabilities.

I somewhat take issue with this, as people on the spectrum are more likely to over-communicate, all other things being equal. Techies are rather caught in a web of social status pressures. Draw a 2x2 grid. On the top axis is the correctness versus incorrectness of your assumption. On the side axis is whether you assume ignorance or knowledge. The social calculus always favors assuming a prior understanding:

                       correct      incorrect
                  +--------------+--------------+
                  |              |              |
                  |              |     lose     |
        ignorance |   neutral    |    status    |
                  |              |    points    |
                  |              |              |
                  +--------------+--------------+
                  |              |              |
                  |              |              |
    understanding |    points    |    points    |
                  |    gained    |    gained    |
                  |              |              |
                  |              |              |
                  +--------------+--------------+

> ...they get the employee's commitment to stay for that long for free.

Hmm, I'm definitely not proposing people should work for free.

> It's an okay deal for managing the risk around hiring, say, an entry level employee...

This is what I had in mind. Mitigating risk on the employer side isn't such a bad thing if it helps more people penetrate the skillset barrier who'd otherwise be excluded. Rank-and-file who train new hires benefit as well. It's soul-draining to invest myself into someone who ends up just using that investment as a stepping stone to other things.

This resonates with me as a programmer who has refused the management path. However, I also think that the more experienced one becomes, and the more influence one wields in the org, the more gaps in one's skillset are amplified. So, grudgingly, I admit that with age and experience comes a certain expedience in learning to not completely suck at things that are outside of my normal areas of strength. As long as my boss understands that I may never be stellar at those things.

Wouldn't it make more sense to provide a contract saying that if you stay with the company longer than X months, your wage/salary goes up by a certain amount? Or even multiple such milestones? Seems like a much better incentive structure.

Posting bookmarklets on the web tends to be frowned on by forum admins, so here's the raw code.

    (function dammit() {
      setTimeout(dammit, 100);
      let els = document.querySelectorAll('object,embed,iframe,video');
      for (let el of els) {
        el.parentNode.removeChild(el);
      }
    })();

Feel free to make it into a bookmarklet using this guide:

https://gist.github.com/caseywatts/c0cec1f89ccdb8b469b1

It's interesting that the author would associate "frames, tables, and other fancy features" with a lack of interesting content. I assume tables are included because they were widely misused at the time, not because tabular data wasn't interesting.

I have a button in my toolbar called "dammit" which strips away every iframe, embed, object, audio, and video from the page, multiple times per second. These are considered foundational elements in the web platform and yet, when they disappear, pages seem to magically collapse into something readable.

With EADGCF tuning, barre chords wouldn't work so well, since the top and bottom strings would be a half-step apart (disregarding octaves) creating dissonance. Or rather, EADGBE tuning works well with barre chords because the top and bottom strings are the same note. An open-chord tuning works even better with barre chords, but only for that one chord shape. EADGBE gained predominance partly because it strikes an uneasy compromise between different chord shapes and barre-chord friendliness.

AI art is striking at first glance, but devoid of meaning once you really try to engage with it. It's the meaning people want, but an image's visual impact has been a reasonably cheap heuristic for finding it. The viability of this heuristic is now dead or rapidly dying, and AI generated art is degenerating into yet another form of spam. Relatedly, feeds full of visually-striking images, once impressive, are taking on a "spammy" tinge. New, harder-to-fake signals will be found, and social media will reorganize around whatever those end up being.

I've chosen to interpret TDD as "test driven design", based on the idea that systems designed to be easily unit-testable tend to also be easier to understand, maintain, extend, compose, repurpose, refactor, etc.

I deviate from some proponents in that I think this kind of TDD can be done while writing zero unit tests, but in practice they keep you sensitized to good design techniques. Plus the tests do occasionally catch bugs, and are otherwise a good forum to exercise your types and illustrate your code in action.

I don't think even young devs think this way. More likely the writer is just being lazy, and filled in gaps in their own knowledge with faux history-salad.

> Hard working and intelligent people are more likely to get rich.

> Most rich people are rich because they were born into it.

Both of these can be true at the same time!

Do I understand correctly that if I build an AI which invents something, this ruling wouldn't prevent me from simply listing myself as the inventor?

> ...JWST’s total costs account for 0.0095 percent of all US spending between 2003 and 2026.

I think it was a good investment, but 10 billion is a lot of money in absolute terms and comparing it to "all US spending between 2003 and 2026" just to make it seem small is disingenuous.

> How many factory or construction jobs does "hard-science" funding create?

An infinite amount, in the long run.