I can see how that could be useful in contexts where the work is about mulling over concepts, trying to uncover some hidden patterns. Philosophy, sociology, psychology come to mind. But looking at my large cache of notes on well known technology, I have a hard time seeing where the value would be.

I think it's worth pointing out because ZK pops up quite often on HN, as if it's the pinnacle of note taking. In reality, a lot of people here may just be wasting much of their time.

I'm no expert, but looking from afar it seems to me that complex note-taking systems are an optimization on some anticipated theoretical future problem that seldom materializes in practice, and I think trying to squeeze those promised extra 10% of efficiency might possibly qualify as diminishing returns.

That's an amazing stretch.

The lack of accountability paired with the celebration of the "hero" are the problem. Not the fact of her testimony.

EDIT: Some people who have similarly testified acknowledged the part they played in the situation they later denounced. So, it is possible for the story to be told and for the teller to also say "I knew what was up. I said nothing. I did nothing. I'm sorry."

Data is map, not terrain. It can explain some of the quantifiable world, not all of it. Common sense can also fill some of the gaps, some of the time. And there remains plenty still that's too entropic for our grasp. Waiting for data to speak is not always the best move. Heck, it might even sometimes be the worst. It seems this is a lesson we collectively keep forgetting over and over, despite the endless list of data-backed "facts" that, in hindsight, it turns out we were wrong or short-sighted about. Apparently, that too is human nature.

There was never any value in simply the ability to invert a binary tree from memory. First, contrary to popular belief, this particular challenge is quite trivial, even easier imo than fizzbuzz. The value of testing candidates with easy problems is their usefulness in quickly filtering out potentially problematic coders, not necessarily to identify strong ones.

Second, another common take on coding challenges is that they're about memorization. Somewhat, but only to a point. Data structures and algorithms are a vocabulary. A big part of the challenge of using them "creatively" in real life is your ability to recognize that a particular subset of that vocabulary best matches a particular situation. In many novel contexts an LLM might be able to help you with implementation once the right algorithm has been identified, but only after you yourself have made that insightful connection.

Having said this I generally agree with the philosophy [0] that keeping things simple is enough 95+% of the time.

[0] https://news.ycombinator.com/item?id=47423647

My current guess about the future is that the age of SaaS is coming stronger than ever. I expect many vibe coders to come up with half-assed prototypes that will be copiously replicated and improved by more qualified devs aided by LLMs. In a similar way, I also expect smaller qualified teams (3 to 5) to leverage LLMs to become more relevant competitors of medium to large SaaS players. By 2029, we'll have more, but smaller SaaS companies.

I judge "failing to keep up" by my ability to "catch up". Right now if I search for paying courses on AI-assisted coding, I get a royal bunch for anything between 3$ to about 25$. These are distilled and converging observations by people who have had more time playing around with these toys than me. Most are less than 10 hours (usually 3 to 5). I also find countless free ones on YouTube popping up every week that can catch me up to a decent bouquet of current practices in an hour or two. They all also more or less need to be updated to relevancy after a few months (e.g. I've recently deleted my numerous bookmarks on MCP).

Don't get me wrong, LLM-assisted coding is disruptive, but when practice becomes obsolete after a few months it's not really what's keeping you employed. If after you've spent much time and effort to live near that edge, the gap that truly separates you from me in any meaningful way can be covered in a few hours to catch up, you're not really leaving me behind.

Also known as PTSD-induced amnesia, haha. We all tried to forget.

> The web is special in this sense, it's intentionally long-lived warts and all. So the fundamentals pay outsized dividends.

Fundamentals pay dividends, but what makes you think that what you learn as an early adopter are fundamentals? Fundamentals are knowledge that is deemed intemporal, not "just discovered".

The historical web and its simplicity are as available to anyone today as it was back then. People can still learn HTML today and make table-based layouts. HTML is still HTML, whether you learned it then or today. But if back then you intended to become a professional front-end developer, you would still have to contend with the tremendous difficulties that some seem to have forgotten out of nostalgia. You'd soon have to also learn CSS in its early and buggy drafts, then (mostly non-standard) JavaScript (Netscape and IE6) and the multiple browser bugs that required all kinds of hacks and shims. Then you'd have to keep up with the cycles of changing front-end tools and practices, as efforts to put some sense into the madness were moved there. Much in all that knowledge went nowhere since it was not always part of a progression, but rather a set of competing cycles.

Fundamentals are indisputably relevant, but they're knowledge that emerges as victorious after all the fluff of uncertainty has been left behind. Front-end development is only now settling into that phase. With LLMs we're still figuring out where we're going.

"Front-end professional" and "no tooling" have been exclusive propositions since the early 2010s. You either learned to use tools or you were out of the loop.

> which will be outdated "tomorrow" just like grunt/bower... are looked at today

Not really. Historically, the main problem with front-end development has not been change, but the pace of it. That's how it ties in with the current discussion regarding the (now) ever-changing terrain of LLM-assisted coding. Front-end development is still changing today, but it's coalescing and congealing more than it's revolving. The chasms between transitions are narrowing. If you observe how long Webpack lasted and familiarity with it carried over to using Vite, it's somewhat safe to expect that the latter will last even longer and that its replacement will be a near copy. Someone putting time to learn front-end skills today might reap the benefits of that investment longer.

> if you learned Javascript early, like really learned it, that mastery gets you far today.

I did. I got a copy of the Rhino book 4th ed. and read it cover to cover. I would not advise to learn JS today with historical references. JS was not designed like most other languages. It was hastily put together to get things done and it had a lot of "interesting", but ultimately undesirable, artifacts. It only slowly turned into a more sensible standard after-the-fact. Yes, there are some parts that are still in its core identity, but a lot in the implementation has changed. Efforts like "Javascript: The Good Parts", further standardization, and TS helped to slowly turn it into what we know today. You don't need to travel back in time for that mastery. Get a modern copy of the Rhino book and you'll be as good as the best of them.

Many developers who picked up the web in the early years struggle with (front-end) web development today. It doesn't matter if they fetched jQuery or MooTools from some CDN as it was done in the mid 00s. Once the tooling became too complicated and ever changing they couldn't keep up as front-end dilettante. It required to commit as professionals.

If you started today, you'd simply learn the hard way, as it's always been done: get a few books or register for a course. Carve some time every day for theory and practice. All the while prioritizing what matters the most to get stuff done quickly right now, with little fluff. You will not learn Grunt, Bower, and a large array of historic tech. You'll go straight for what's relevant today. That applies to abstractions, frameworks, and tooling, but also to the fundamentals. You'll probably learn ES6+ and TS, not JS WAT. A lot of the early stuff seems like an utter waste of time in retrospect.

This is true for all tech. If you knew nothing about LLMs by the end of this year, you could find a course that teaches you all the latest relevant tricks in 5 to 10 hours for 10 bucks.

The software identified the person as Angela Lipps. According to the court documents, the Fargo detective working the case then looked at Lipps' social media accounts and Tennessee driver's license photo.

In his charging document, the detective wrote that Lipps appeared to be the suspect based on facial features, body type and hairstyle and color.

The software worked exactly as intended. It's a filtering tool that sifts through data for common patterns to provide leads, not matches. It raises a flag on persons of interest. You can be a "match" anywhere between 0 and 100% and only relative to some specific input (like that picture taken from the top of the woman at the teller). In that sens mismatches are within acceptable parameters and have been known to happen.

A "match" is a pronouncement ultimately made by the humans that uses the tool, after they've checked out the leads. Someone slept at the wheel here.

Of course, it could also be argued that some day we may decide that it's no longer necessary at all for code to be written for a human mind to understand. It's the optimistic scenario where you simply explain the misbehavior of the software and trust the AI to automatically fix everything, without breaking new stuff in the process. For some reason, I'm not that optimistic.

You mean full of AI spectators.

The phrase does not make more sense even if we go all the way back to Beers. I certainly don't feel alone in not understanding how he went from his (fair) observation that "[There's] no point in claiming that the purpose of a system is to do what it constantly fails to do" to his more controversial conclusion: "The purpose of a system is what it does (aka POSIWID)".

Surely, there were many more sensible (but perhaps less quippy) stops between the two.