bschne

I wonder if you could come up with some incentive scheme where if you upvote something you get karma or a different set of points based on a) how early you were to the party, and b) how many upvotes things gain after you, sort of like the internet community version of a Keynesian beauty contest, or a prediction market.

This is obviously a bit convoluted and not really hashed out, but I got curious how the incentive scheme might look like.

> A downside is that although normally you'd want to remove old feature flags that become obsolete, this hasn't been done very often.

I figure this should be somewhat automatable since the relevant bits of code have references to the exact flag's identifier. Was it not done b/c nobody was incentivized in any way to spend any kind of time on cleanup?

edit: OK that might be a bit naive on the organizational side. Force everyone to give every flag an expiry date for review or something maybe?

I once had a job where I somehow didn't get assigned much work for a long period of time right after starting — something about no projects having open staff positions, and them not being able to use me anyway because they were using up all the budget with the existing staffing already and didn't want to do "free work" for the clients.

For a while, I spent my days mostly doing tutorials, reading ebooks and papers, watching lectures, ...

Don't get me wrong, it's an incredible luxury to get a consistent salary and be able to do that! But the thing is, you can't help but feel utterly useless after a while. It's especially bad if everyone else has their projects, so you also don't really feel like part of a team.

Wow, I need to check that out, thanks!

That's the crux of it — visions aside, day-to-day, nobody is going to suddenly "solve aging" for everyone. Progress comes gradually, in the form of everyone's loved ones dying and suffering less often and less early — and very few people are opposed to that.

You hear about older people fall ill and think things like "I've lived long enough, I don't want to go through the ordeal of treatment X for a .05 probability of living for one more year in bad health" — but would they see it that way if the treatment were to become much better and safer?

What got me started was probably this from "The Thought Emporium", and other videos on his channel: https://www.youtube.com/watch?v=J3FcbFqSoQY (obvious don't try this at home disclaimer).

What I'm reading right now is "Molecular Biology of the Cell" — it's a dense textbook and I'm taking my time, so only about two chapters in, but I love how it focuses on a lot of fundamental principles and occasionally points out astonishing facts.

There's also this series which might be a nice, casual primer: https://www.youtube.com/playlist?list=PL3EED4C1D684D3ADF

James Somers also lists some other books in his post I linked to above, might be worth checking out.

That reminds me (tangentially) of this piece I read a while back: https://jsomers.net/i-should-have-loved-biology/

I felt mostly neutral about biology back in high school (mostly due to the fact that I didn't find it that much to remember, so it was hardly a struggle, but the teaching was less than awe-inspiring to be diplomatic). When I read the piece above, I mostly thought it was well written and matched how school had killed a lot of curiosity for me about many a topic.

Then I recently started reading up on molecular biology basics after stumbling across a bunch of youtube videos, and I have to say I don't think I've ever been this thoroughly, viscerally fascinated by anything I've learned about. Much of what I'd read or studied so far was either "here's a neat model that explains a lot of things concisely", or "here's a way practical problems like x, y, and z can be solved". With the foundational mechanisms of biology, on the other hand, it was like suddenly opening my eyes to incredible levels of complexity all around and inside me I had completely neglected before.

I'm not sure it's entirely correct to refer to this instance by the term of "anthropic reasoning" too, but:

The viruses we see are common because they reproduce, it's not that they reproduce because they have some drive to become common.

Thus prions are less common because they aren't as successful in spreading (for some reason(s) I don't know either).

With the GIT thing my usual stance is that there's no need to make this a hill to die on. Some people feel better about it, it's next to zero effort, so it's no big deal wether I personally think it's absolutely necessary or not. I don't think it's a high priority or high leverage thing to do against racism or for inclusion, but I don't mind when GitHub goes "you know what, main is nicer for some people, let's switch".

But the ant colony thing in the SA piece sounds a bit like saying software engineering is a "problematic" field that should be critiqued because it often uses a VCS that at some point in the past opted for a very common set of terms that some may now consider offensive.

I could try to rack my brain for all the more or less charitable interpretations of what she is actually trying to get at with that sentence, but viewing it in the context of the whole piece, I think there's not much of a there, there.

From the op-ed in question:

> And the descriptions and importance of ant societies existing as colonies is a component of Wilson’s work that should have been critiqued

Is she... drawing a connection between the term "ant colony" and human colonialism?

Ah, now you could build that CPU up to a point where it could emulate a eurorack synthesizer. Which you could then use to emulate a CPU.

Maybe I should finally read GEB...

Tufte can be quite dogmatic and not all of his principles should be taken as gospel at all times (then again, nothing should, probably). But one thing that stood out to me is that some of his examples remind you not to get too smart — just put the labels directly with what they label, annotate directly on the graph, etc., the kind of stuff you can easily forgot to do when the default is to just use chart templates in whatever software your data lives.

If you want to get into reading some CS papers, I can also recommend these sources:

1. The unfortunately defunct blog "The Morning Paper" that provides a short write-up/explainer of each paper. https://blog.acolyer.org

2. Will Larson's favorite CS papers. https://lethain.com/some-of-my-favorite-technical-papers/

w/o paywall: https://archive.is/OyUfo

I wonder if, in some ways, this might also lead to more centralization. If your answer to "control == liability" is decentralized protocols, the answer is obviously no. But if these protocols either don't exist for your use case, or are not practical, I could also see these efforts leading to things being centralized in the hands of a few large providers who take some of the control and are better positioned to shelter the associated liability.

We already see this with hosting on cloud services, or external auth providers and the like — for small players, it is very unlikely that they're better at e.g. security or availability than google, aws, et al. The downside is obviously that this clusters a lot of the risk and when something does go wrong, it takes many more people down in its wake.

Wouldn't things that are some combination of continuous variables be called a "space", and not a "spectrum", in the common usage of those terms? To use the color example in this post, we for instance talk about the RGB or CMYK color space if we mean to say that a color is a combination of those primary colors.

Additionally, there was an ACX post a while back [1] talking about how to model psychiatric conditions (the author of which is a psychiatrist) which did talk about spectrum meaning that it is along a continuous axis of severity instead of being something you either have or don't. While it didn't talk about separate symptoms, I'd venture a guess that they are usually reasonably correlated if something is assigned it's own diagnosis, and in many cases it may be more meaningful to reduce dimensionality to a 1D spectrum instead of looking at every variable in isolation?

1. https://astralcodexten.substack.com/p/ontology-of-psychiatri...

While you could create infinite amounts of money, that's not very meaningful if it serves as an abstract means of exchange for goods which are ultimately somewhat constrained/scarce.

Also, I am pretty sure it'd be a challenge to find a single economist who claimed the amount of money was fixed. What they do think (many of them, and probably somewhat reasonably, anyway) is that you can't create infinite amounts of it without things going awry — see above.

> As you may know, Vermeers are so few and far between that it's entirely possible to see every one (~36) if you're able to travel the world.

As someone has actually done and made a website about:

https://jlord.us/vermeer/about.html

> 4. Rich editing similar to Google Doc is very very complicated subject with lot of landmines

They (Ink & Switch) are actually working on that too, see https://www.inkandswitch.com/peritext/

Can you give some pointers to said literature? It's a topic I keep coming back to but haven't really read about much...

For those wondering "but separation of concerns!" or "but code reuse!", the dev behind Tailwind wrote a post about his thinking around this, which IMO makes quite a lot of sense, a while back:

https://adamwathan.me/css-utility-classes-and-separation-of-...

There's something interesting about the way we as a species think about death. Say you're working on "immortality" or on "solving aging", and most people outside a small subset of the tech/SV crowd will think you're a megalomaniac or just plain crazy -- death is obviously a fact, and to attempt to overcome it pure hubris. Yet we spend an incredible amount of resources on prolonging life in various ways through lifestyle interventions, treatments, cures -- and handsomely reward and revere those who succeed in pushing our life expectancy ever so slightly upwards.

My recollection of the story is a bit spotty and I can't re-read in full right now, but:

I think the point this is trying to make is that we accept death of old age as a natural fact and think it is odd to want to "solve" it, but wouldn't accept it at all if it were caused by some personified actor?

Of course we don't "just accept" it, we have long considered a large fraction of deaths "too early" and worked on postponing them with various treatments.

Wait, is that what that set is supposed to look like? The cacophony of colors makes it look almost like it was built from a random bin of parts lying around.

Reminded me of this I read recently and found quite fascinating — http://knowingless.com/2021/11/27/frame-control/

> “Now Spotify is the winner in music streaming, Klarna is the winner in buy-now-pay-later and UiPath is the winner in robotic process automation—they’re all European,” he says.

Between the various keywords in the title and the domain, it took me about a minute and a resigned click to figure out whether this was about browsers or rockets

> I asked him about his decision-making, and he listed a combination of serious statistical errors and small red flags adding up. I was pretty uncomfortable with most of these studies myself, so I will err on the side of severity, and remove all studies that either I or Dr. Meyerowitz-Katz disliked

From further up, though we don't _quite_ know the details, but it's not like he went "Oh well some random person disagrees with them so better throw them out"

Started reading Smil‘s „Energy and Civilization“ recently and the sense of acceleration as you enter the last two centuries is almost palpable, absolutely mind-boggling once you start noticing it.

As an aside, IIRC there‘s a „timeline of the universe“ on the outside of a spiral ramp at NYC‘s museum of natural history that does a similarly good job at driving this home.

Granted, this was also in the context of mechanical engineering and manufacturing (cf. remarks in sibling comment), but Elon Musk has talked about his engineering philosophy in five steps in a starbase tour/interview video:

1. Make the requirements less dumb 2. Try deleting the part or process 3. Simplify and optimize the design 4. Accelerate cycle time 5. Only then: Automate

I think this touches upon the same issues, namely that you shouldn't automate something if you don't have to, and even less if you don't need it in the first place.