Exact Instructions Challenge PB&J Classroom Friendly | Josh Darnit

It’s a reference to a famous YouTube video[0] about how to write instructions that can be followed. One of the most important things a programmer needs to do is learn how to tell a computer how to do something. It’s a surprisingly hard skill because each step is way more complicated and has way more variables to go through. ▶ this video

> why do you not program in assembly? There's a balance of levels of abstraction. Abstraction is a great thing. Abstraction can make your programs faster, more flexible, and more easy to understand. But abstraction can also make your programs slower, more brittle, and incomprehensible. The point of code is to write specification. That is what code is. The whole reason we use a pedantic and somewhat cryptic schema is that natural language is too abstract. This is the exact reason we created math. It really is even the same reason we created things like "legalese". Seriously, just try a simple exercise and be adversarial to yourself. Describe how to do something and try to find loopholes. Malicious compliance. It's hard, to defend and writing that spec becomes extremely verbose, right? Doesn't this actually start to become easier by using coding techniques? Strong definitions? Have we not all forgotten the old saying "a computer does exactly what you tell it to, not what you intend to tell it to do"? Vibe coding only adds a level of abstraction to that. It becomes "a computer does what it 'thinks' you are telling it to do, not what you intend to tell it to do". Be honest with yourself, which paradigm is easier to debug? Natural language is awesome because the abstraction really compresses concepts, but it requires inference of the listener. It requires you to determine what the speaker intends to say rather than what the speaker actually says. Without that you'd have to be peda

No. Natural language is vague, ambiguous and indirect. Watch these poor children struggle with writing instructions for making a sandwich: ▶ this video

I don't think you're wrong but I think you're being too quick to attack the gp. They're not wrong either. The point you brought up doesn't contradict theirs but adds nuance. I'm all for nuance. Its also why I'm biased towards long form media as it's more likely to contain nuance, but not guaranteed. The gps specific example of lectures is quite narrow and more likely to have depth. Which is the entire problem of short form media, that we live in a complex world where we can't distill everything into 1-2 minute segments. Hell, even a lecture series, which will be over 10hrs of content is not enough to make one an expert on all but the most trivial of topics. You're right that we need nuance but you're not right in arguing for it while demonstrating a lack of it. A major issue is we need to communicate, something we're becoming worse at. We should do our best to speak and write as clearly as possible but at the end of the day language is so imprecise that a listener or reader will be able to construct many, and even opposing, narratives. It is more important to be a good listener than a good speaker. I'd hope programmers, of all people, could understand this as we've invented overly pedantic languages with the explicit purpose of minimizing ambiguity[0] [0] ▶ this video

Do you know certain shoes are banned in running competitions? There's a really fine line here. We make shoes to help us run faster and keep our feet safe, right? Those two are directly related, as we can't run very fast if our feet are injured. But how far can this be taken? You can make shoes that dramatically reduce the impact when the foot strikes the ground, which reduces stress on the foot and legs. But that might take away running energy, which adds stresses and strains to the muscles and ligaments. So you modify your material to put energy back into the person's motion. This all makes running safer. But it also makes the runner faster. Does that example hack the metric? You might say yes but I'm certain someone will disagree with you. There's always things like this where they get hairy when you get down to the details. Context isn't perfectly defined and things aren't trivial to understand. Hell, that's why we use pedantic programming languages in the first place, because we're dealing with machines that have to operate void of context[0]. Even dealing with humans is hard because there's multiple ways to interpret anything. Natural language isn't pedantic enough for perfect interpretation. [0] ▶ this video

> as originally envisioned This was never the core problem as originally envisioned. This may be the primary problem that the public was first introduced to, but the alignment problem has always been about the gap between intended outcomes and actual outcomes. Goodhart's Law[0]. Super-intelligent AI killing everyone, or even super-dumb AI killing everyone, is a result of the alignment problem when given enough scale. You don't jump to the conclusion of AI killing everyone and post hoc explain through reward hacking, you recognize reward hacking and extrapolate. This is also the reason why it is so important to look at it from engineering problems and from things happening on the smaller scales, * because ignoring all those problems is exactly how you create the scenario of AI killing everyone...* [0] link [Side note] Even look at Asimov and his robot stories. The majority of them are about alignment. His 3 laws were written as things that sound good and have intent that would be clear to any reader, and then he pulls the rug out on you showing how they're naively defined and it isn't so obvious. Kinda like a programmer teaching their kids to make and PB&J Sandwich... ▶ this video

> TEST YOUR DOCS Yes. > But this works better if you have someone else try it out instead 1000x yes. Yoz, you are wise and while what you say may seem like an obvious thing, it isn't. I was once in the unfortunate position of having to write manuals for software I did not design, so I went through it thinking I was the "average user." As it turns out, I was under the false impression that my documentation was perfectly understandable to anyone, to the point where they could sit down, rtfm and go. Boy was I wrong. I later got into an area of work where I had to help individuals with cognitive disabilities adapt to new workflows in factory settings. One of the exercises I had to do to earn my certification in this field was to imagine an individual that had never seen a broom or dustpan before, then use only photos to explain how to sweep a floor. It's far more challenging than you think. I realized that not only was I making the mistake of explaining things to myself, but I was also assuming that I could put myself in someone else's shoes and interpret my own instructions with fresh eyes. This, as it turns it, was folly. That experience propelled my documentation forward by leaps and bounds, though. In my current position, I came up with over a dozen single-page instructions to resolve issues customers were having with our products that, previous to my working here, generally took an hour-long phone call, eating up time and resources on both ends. Each page was tested with a c

I’m not sure why you need to do any research. Just look at how hard it is to drag software requirements from a business person. Or how hard it is to explain to a “pedantic asshole” how to make a sandwich ( ▶ this video ).

Part of the problem is that context is something AI is bad at and instructions are highly context dependent. ▶ this video