stenecdote

Was this written by an LLM? I'm not highly confident, but there are some telltale signs. For example, the negative preceding multiple positive contrasting examples pattern is quite common in LLM-written text, and it appears multiple times throughout the text.

> They didn’t ask permission. They reverse engineered. They read RFCs like scripture. Their idea of “AI” was Eliza on the school computer lab’s terminal—and they probably rewrote it in Perl for fun.

> Today’s AI dev isn’t dropping shellcode into memory via a buffer overflow—they’re fine-tuning GPT on sentiment-labeled customer complaints for a mid-tier CRM startup. The tools are slick. The stacks are vast. The logs are in JSON. And the energy is… agile.

Also, I like em dashes still but the number here seems high. --- As an additional test, I asked Claude to write a post on the topic given just the title, so it couldn't copy the style from a snippet. Here's a snippet from the conclusion. Notice the similar style and structure between it and one of the OP's concluding paragraphs:

Claude:

> The hacker ethic hasn't died; it has evolved. Where once it meant breaking into systems, now it might mean breaking open black boxes. Where once it meant sharing code, now it might mean sharing compute. The tools and targets have changed, but the fundamental drive—to understand, to share, to democratize—remains.

OP:

> What the 90s hackers did with port scanners and punchy manifestos, today’s AI rebels do with open weights, privacy-preserving algorithms, and Git repos that mysteriously disappear from major platforms.

Look, I'm not in principle opposed to posting LLM writing, but it does seem like bad form to post an LLM's output on the topic of LLMs and not at least call it out as such. This is doubly true given that if I had to guess, not very much curation was done on top of this.

I don't think this is true having read some of the later chapters and not knowing measure theory. And if you don't trust me, Gelman doesn't know measure theory either (https://statmodeling.stat.columbia.edu/2008/01/14/what_to_le...) and he wrote the book...

Knuth has said that the story as told above is apocryphal. I quote from here (http://www.informit.com/articles/article.aspx?p=1193856): > Donald: The story you heard is typical of legends that are based on only a small kernel of truth. Here’s what actually happened: John McCarthy decided in 1971 to have a Memorial Day Programming Race. All of the contestants except me worked at his AI Lab up in the hills above Stanford, using the WAITS time-sharing system; I was down on the main campus, where the only computer available to me was a mainframe for which I had to punch cards and submit them for processing in batch mode. I used Wirth’s ALGOL W system (the predecessor of Pascal). My program didn’t work the first time, but fortunately I could use Ed Satterthwaite’s excellent offline debugging system for ALGOL W, so I needed only two runs. Meanwhile, the folks using WAITS couldn’t get enough machine cycles because their machine was so overloaded. (I think that the second-place finisher, using that "modern" approach, came in about an hour after I had submitted the winning entry with old-fangled methods.) It wasn’t a fair contest.

> As to your real question, the idea of immediate compilation and "unit tests" appeals to me only rarely, when I’m feeling my way in a totally unknown environment and need feedback about what works and what doesn’t. Otherwise, lots of time is wasted on activities that I simply never need to perform or even think about. Nothing needs to be "mocked up."

I like Andrew Ng's short article (https://www.linkedin.com/pulse/20140320175655-176238488-lear...) about this topic. Recommends taking short videos of elements of your speech and then watching them, tweaking, and repeating.

Yeah, this was me posting first, which ironically garnered much less interest than someone else's post (number 2 I believe).

I learned yesterday that Ken Thompson used to host readings of Unix source code at Berkeley where they would go through the code line-by-line (https://www.salon.com/2000/05/16/chapter_2_part_one/): >And from the very beginning, Unix benefited from a communal vibe that spread directly from its creators, Ritchie and Thompson. > > Fabry recalls grasping the hidden wonders of Unix one week in 1975 when Thompson conducted a "reading" of Unix over several successive nights. > >"The first meeting of the West Coast Unix User's Group had about 12 or 15 people," recalls Fabry, a mild man, now 60 years old, who clearly delights in his 25-year-old memories. "We all sat around in Cory Hall and Ken Thompson read code with us. We went through the kernel* line by line in a series of evening meetings; he just explained what everything did ... It was wonderful."

Upvoted for careful scholarship and a useful addendum (I'm OP)!

I sometimes wonder whether a lot of Knuth's greatness comes from doing more of the stuff everyone knows they should do but don't. If you read this interview (https://github.com/kragen/knuth-interview-2006) with Knuth, he talks about how he was nervous he wouldn't be able to learn calculus so just decided to do all the problems instead of just the assigned ones. Unsurprisingly, partly because he's Knuth and we all know Knuth can do math, he ends up really good at calculus: > But Thomas’s Calculus would have the text, then would have problems, and our teacher would assign, say, the even numbered problems, or something like that. I would also do the odd numbered problems. In the back of Thomas’s book he had supplementary problems, the teacher didn’t assign the supplementary problems; I worked the supplementary problems. I was, you know, I was scared I wouldn’t learn calculus, so I worked hard on it, and it turned out that of course it took me longer to solve all these problems than the kids who were only working on what was assigned, at first. But after a year, I could do all of those problems in the same time as my classmates were doing the assigned problems, and after that I could just coast in mathematics, because I’d learned how to solve problems. So it was good that I was scared, in a way that I, you know, that made me start strong, and then I could coast afterwards, rather than always climbing and being on a lower part of the learning curve.

To push back on this point a little bit, I think we agree that a map is one of the most useful things you can have but disagree on what the right type of map is.

While I'm not anti-abstraction, I think people often impose poorly chosen high-level abstractions on top of messy lower-level components (akkartik calls this Authoritarian High Modernism in a comment (https://lobste.rs/s/gtxi5y/nobody_s_just_reading_your_code_h...) on Lobsters). This approach leaves readers having to understand a bad abstraction and its internals, a map, its territory, and inconsistencies between the two.

As I understand it (please correct me if I'm wrong), you want people to do the work to find better high-level abstractions. I agree that it would be good if we could do this more often. I just also think we can find other ways to give people maps that work with our existing, messy codebases that don't have good, minimal abstractions already.

Hi kazinator, thanks for your comment (I'm the post's author). When I originally wrote the post, I actually had a whole section about "reading for questions", which discussed how the best way to read without modifying a program is to read to answer focused questions you have about the codebase. It kind of got lost when I shifted focus to active interaction versus passive exploration, but I agree that reading with questions in mind is far superior to just reading the code to understand it generally.

I wish one of these pull requesters would comment on this post! I'd love to hear how they're going about reading your code and whether they're actually using Redis or just reading it for enjoyment.

As the author of the post, just wanted to reply and say I'm totally open to the notion that the solutions I proposed will not solve the problem. I'm much more sure about the problem than I am about the solution.

A google maps zoom system for code sounds awesome, although I have no idea how that might work.

What about Beyond Good and Evil made such a big impact on you? I read it and enjoyed it a lot as well but struggle to put it into words how it has impacted me.

It only now occurs to me that the line of thinking I follow here is sub-consciously inspired by section 3 of this Marvin Minsky talk (https://web.media.mit.edu/~minsky/papers/TuringLecture/Turin...). If you're at all interested in the intersection of learning and computer science, I highly recommend taking a look.

> By the way, human already learn from experience by bootstraping their own understanding, teachers and experts exist to fast track the beginning phase so a kid doesn't have to play ten thousand games just to reach beginner skill level.

Yeah, I came part of the way to this realization in my reply to your other message.

I agree that AlphaZero's per-game learning efficiency is much shorter than a human's (as mentioned in my other reply). The part that interested me more was the fact that it bootstrapped its learning from the basic rules of each game.

Now that I think about it though, one might argue that human learning in a given discipline starts as isolated with feedback only coming from the outside world. This is what we typically call research. But the magic of our education system, when it works, is that we compress the output of this slow process into a faster one and feed it to learners, allowing them to build understanding of knowledge which originally took generations to discover. Riffing off Matt Might's illustrated depiction of a PhD (http://matt.might.net/articles/phd-school-in-pictures/), expanding the circle of knowledge is exponentially slower than getting close to the edge.

Thanks for being the first to reply. I was worried I'd just get upvotes and no replies!

I think you have two separate points, one with which I agree and one with which I disagree.

First, I agree (and other commentators about AlphaZero seem to as well) that human learning "algorithms" still beat AlphaZero's on per-game ROI.

On the other hand, I disagree that AlphaZero's self-play is no more interesting than a human playing someone better and learning from them. AlphaGo, AlphaZero's predecessor, followed a strategy more like what you described, learning from a large corpus of existing expert chess matches. AlphaZero, on the other hand, requires no training beyond an encoding of the basic rules of chess that it can understand. From there, it bootstraps its understanding of chess without input from experts.

This is the piece I find most interesting, see as potentially useful for the future of human learning, and believe differs from practice with an expert teacher. And so I wonder, can we design learning environments where the learner bootstraps their own understanding from a limited input without continuous feedback from an expert or teacher?

> These are mostly solved problems (minus omniscience or scale) with just handfuls of books that represent most parts of the solution.

Could you list some of those books? Would love to add them to my reading queue.

I've actually been actually working at this for the past few weeks. First, the caveat that I haven't implemented a good tracking system beyond casually jotting down Xs next to my task list to count the # of strict Pomodoros I allocated to each one. I'm also not strict about this and definitely don't compute statistics expect useful metrics. I'm much more interested in day-to-day rhythym improvements, interruption control, and focus training. For higher level scheduling, I've experimented following Cal Newport's recommendation to schedule every minute of my day (http://calnewport.com/blog/2013/12/21/deep-habits-the-import...). On days it works, it goes great, but I'm still working to integrate this method with the need for reactive changes of plans. With that, a few observations and outstanding questions about the Pomodoro side of things:

- Interruptions definitely affect my feeling of accomplishment and may affect my results. I find even the smallest external interruption or moment of weakness triggers my internal critic, resulting in an arguably more detrimental cascade of self-criticism. An avalanche of blog posts argue that these minor interruptions dramatically impact my productivity for other reasons. I totally buy this anecdotally but won't attempt to justify it since I suspect most people here agree anyway.

- Sometimes 25 minutes just doesn't cut it. I especially chafe at the forced 5 minute break during my 1.5 hour period pre-standup where I haven't eaten at all and am caffeinated. I know the creator of the technique and blog authors like Martin claim that I should be able to slice all of my tasks such that I don't need longer than 25 minutes, but I disagree. While I enjoy holding the state of a program in my head and occasionally finding the zone, I'm willing to acknowledge Martin's overstated but partly true point that the zone can induce tunnel vision and the downsides that go along with that. However, I've also observed that 3 break-interleaved chunks of work can zap my energy more one large block of work would have.

- How do people deal with waiting for things that take longer than a minute? I've recently been working with jobs that take multiple hours to run. It's difficult to both schedule my Pomodoros such that I have a free one to check the result of this job. Even worse, the validation of the job can take between a minute if it succeeded and hours if it failed. This makes budgeting hard.

- Should I budget Pomodoros for checking email and Slack or include that in my breaks? Ideally, I'd use breaks to recharge and not context-switch between communication platforms. But, while I'm not an always on, 10-minute to respond to any email guy, a consistent multiple hour time-to-respond to any communication is a recipe for face-to-face interruptions in the age of the open office.

- Should I include lower level planning in my break or 25-minute chunk? I often find going from high-level task statement to knowing exactly what I need to do requires a few minutes to orient myself. I'd be fine including this in my Pomodoros except this orienting can involve firing off a quick question to a colleague or searching through my emails / Slack messages. Maybe I just need to get better at gathering requirements beforehand...

To be clear, I'm not putting down the technique. I suspect any time management strategy would reveal the issues I described above and that we simply don't hear about the pains of actually implementing a system beyond a week of casual usage (see any blog post with a just-so title like "I Adopted <> and It Changed My Productivity Forever" as an example).

As I look back at my bullets, I've realized I'm mostly looking for wisdom from some seasoned Pomodoro veterans. I see one or two people on this thread who fit this description, but overall I'm disappointed with the ratio of people who want to sell the technique or have tried it to people who have used it consistently for months or years. This seems to be a common problem among productivity techniques.

Meta-comment: I recognize this comment could be condensed, and "if I had time I would have written a shorter letter" (http://quoteinvestigator.com/2012/04/28/shorter-letter/).

Off-topic: @hacker_9 just saw one of your recent comments (https://news.ycombinator.com/item?id=13267106) and you seem to be thinking along similar lines to me and akkartik (https://news.ycombinator.com/user?id=akkartik). You can read more about our work here (http://akkartik.name/about). Would love to hear any thoughts you have!

About the same for me as well. The only thing I'd add is that if the book has exercises and some of them are algorithmic in nature, I often require days of background thinking time.