jkaptur

If you offer a programmer a deal where you make their code x% faster on average, never slower, and the actual speedup depends on a huge number of factors making it really hard to reason about, they'll take it 99.99% 0f the time.

It seems to me that the entire stack is built on this assumption, making life incredibly difficult the other 0.01% of the time.

Every New Yorker short fiction: our protagonist, a slightly dislikable person, suffers from a medium-high amount of ennui.

Lego should provide a way to check whether the machine will stop for a given input, so that kids don't get frustrated turning the crank forever.

Donald Trump is strongly against Section 230.

https://www.cfr.org/in-brief/trump-and-section-230-what-know

Some context that sometimes gets lost: this sort of research is, to put it crudely, content marketing for an investment bank.

So when the article says "the firm began hosting private bull-and-bear debates" we can be sure that each attendee was met shortly thereafter by their friendly Goldman salesperson to talk about how to trade whichever way they wanted.

Strong https://xkcd.com/793/ vibes here, though it's a cool way to approach this model of a problem.

Work closely with UI designers at the company. Make sure their design process (sticker sheets or whatever) uses the components you're building and vice versa.

If developers have to twist and contort your components match mocks, then they'll start thinking "you know, this would be a whole lot easier if I just did it myself...". But if the developers get a mock that's obviously just YourDialog containing a YourRadioButtonGroup, YourValidatingInputField, and YourSubmitCancelButtonSet, then they'll just use them.

"IT will tell you what the new process has to be" is usually a pretty tough sell.

Now you have two problems: rolling out the new system and changing the business process. And you'll solve them simultaneously, and if anything goes wrong, you'll roll both back...

I think that would require calculating the hash, which was ruled out as too slow.

They're probably as critical as ever at Barclays :)

The idea is that it is acceptable to rely on test automation, and that teams should apply the "Beyonce Rule" - if you like it then you should've put a test on it.

Some other interesting points here: Ballmer works hard to de-emphasize and diplomatically move away from discussing this exact question once it becomes clear that Chang's not approaching it by thinking explicitly about binary search and expected value.

Which is not surprising, because she's a professional journalist! It's amazing that Ballmer (like so many technical interviewers) is so pleased with this question that he couldn't help bringing it up, even though it's not really that relevant to Chang's question.

I recommend the book "Automating Inequality" by Virginia Eubanks for a deeper dive here.

I think that article buries the most interesting part! It's true that "bug" in that sense dates back to the 19th century, but before that, it didn't necessarily mean "insect" - it could mean something like "malevolent spirit", as in Hamlet's "bugs and goblins".

I wrote a little more about this: https://jkaptur.com/bugs/

The spec has an answer for the "transient element" issue: https://developer.mozilla.org/en-US/docs/Web/Accessibility/A.... Of course, this doesn't eliminate the possibility of bad UX.

Very interesting interpretation! I see your point.

It's on the beaten path, but how can you resist (and how did the New Yorker resist?) "The Devil Went Down to Georgia"? https://en.wikipedia.org/wiki/The_Devil_Went_Down_to_Georgia

Most of the deals in the article do not end well for the human, but here there's no lesson about hubris, nor the curse of knowledge, or anything else. No, Johnny's just a better fiddle player, he beats the devil, and he wins a golden fiddle fair and square.

(The article might allude to this story: "Satan is not the real God, because there is only one God; the Devil doesn’t have the best tunes.")

That setup cost in the neighborhood of five thousand dollars (adjusted for inflation). Spreadsheets are amazing.

Yep: https://english.stackexchange.com/questions/241379/what-is-t...

I know nothing about promotional email, but I'm curious if you ever provided links so that the user didn't have to type an answer in order to provide a bit of information - something along the lines of "I'm using this for a personal project" or "I'm considering this for my company".

That's counterintuitive, though - often, the whole point of a hash is that it's one-way.

Any system will have some limit on the length of names - if nothing else, the budget for storage.

A non-lazy programmer will determine an appropriate limit, document it, continuously test that the entire system can handle that length correctly, and continuously test that helpful errors are returned when too-long names are input.

My hypothesis would be that companies with poor operational practices are more likely to underperform the index and have data breaches - in other words, that the study confuses cause and effect.

This wouldn't be that hard to test. I suspect that the breached companies underperformed in the six months before the breach as well as the six months after.

Sounds like this person: https://en.wikipedia.org/wiki/Richard_Ragan

This is a really interesting topic, and it has complexity I didn't consider until I became deeply involved in some similar systems.

For example, in code, you can generally use feature flags, A/B testing, etc. to show different things to different people quite flexibly, but (depending on how the documentation is actually published) you might have very different capabilities.

"View of the World from Ruta 70"

> I feel uneasy about design patterns. ... they solve problems that a choice of programming language or paradigm creates.

I don't understand the ambivalence. I have to make some choice of language and paradigm, and then I have to solve problems using it.

Great article and description of the plan-execute pattern, though!

I think this is basically true in moderation.

I certainly agree that a lot of problems (including a lot of very difficult problems!) are not amenable to purely technical solutions.

But sometimes you have a difficult, technical bug to fix, and the "people problem" is making sure that someone has the knowledge, context, time, and incentive to fix it. This is not necessarily easy!

... especially if enough people have bought into "everything is a people problem", because then the technical work of fixing the bugs isn't valued or incentivized. Why would it be? It's not solving a people problem.

I think the viewpoint "everything is a people problem" can create a feedback loop that leads to poor incentives - which, ironically, is a people problem.

I love this!

Quick feature request: the die-roll is really cool, but can you make a lower-latency version so I can play more games in less time?