peterkos

This reminds me of those videos where the bar staff try blind pouring a shot, and it's wild how good some people are. Would love to see a similar competition, re: can the most senior store members be accurate to 1° :)

I'm imagining a spectrum between "has to be slow" and "needlessly slow", with a middle slider for that one razor where things take as much time as you give them.

Intentionality is a big theme in math research (so i've heard), where solving "useful" problems isn't the ideal goal. The goal is to solve interesting problems, which might seem useless, but along the way achieve results with much wider implications that would have been impossible to discover directly. Or, how inventions like toothpaste came from space travel research.

(rhetorically) Does an indirect result "justify" a longer, slower project? Is speed an inherent property of the problem, or is it only knowable once it's complete? Or both, in the cases of misused funds?

After reading this, I am now of the belief that software is, actually, a good thing. And that programming can be enjoyable.

Seriously, this does such a good job of capturing the feeling of MAGIC that code is capable of -- both in its process and in its output. Textbook "craft". It's hard to experience that sometimes when surrounded by dependency hell, environments, build systems, certain dynamic programming languages, and the modern web ecosystem.

That's a pretty egregious mistake for a designer to make -- and that's not even mentioning the lack of accessibility. WebAIM's contrast checker says it's a 1:1 contrast ratio!

If someone is releasing a model that claims to have a level of reasoning, one would hope that their training dataset was scrutinized and monitored for unintended bias (as any statistical dataset is susceptible to: see overfitting). But if the graph on the announcement page is literally unreadable to seemingly anyone but the creator... that's damning proof that there is little empathy in the process, no?

> It may not sound like much, but this was a lot of work. I spent days just thinking about this problem, trying to understand what is happening now and how to improve it.

I find these kinds of problems the most fun and the most educational! I tried building a grid layout system from scratch in SwiftUI, and it was similarly tricky to map out:

- what the "ideal" behavior one expects is,

- what edge cases exist,

- how to handle the edge cases,

- maintaining ideal behavior while handling edge cases.

(It was tricky b/c SwiftUI lays out its children, then its parent -- so the parent needs to ask its children for its view size, and iterate and set rows/columns that way.)

Maybe because the problem seem simple, it is that much more fun to dig into. Some good ol' time with a whiteboard.

I'm reminded of a time that an intern took down us-east1 on AWS, by modifying a configuration file they shouldn't have had access to. Amazon (somehow) did the correct thing and didn't fire them -- instead, they used the experience to fix the security hole. It was a file they shouldn't have had access to in the first place.

If the intern "had no experience with the AI lab", is it the right thing to do to fire them, instead of admitting that there is a security/access fault internally? Can other employees (intentionally, or unintentionally) cause that same amount of "damage"?