jasongi

Nobody willingly reads docs. Docs don't exist for the reader, they exist for the writer(s) - because it saves them having to explain the same thing over and over again. Having docs is nice for continuity and for the people who take initiative to seek them out instead of just asking others, but their real value is turning daily (or hourly) 30 minute explanation into a link and a "let me know if you have any questions". The doc pays for itself the second time someone asks you about it.

If they can tell it is written with AI, then the docs are slop. If you're writing something lots of people will use, don't skimp on model or reasoning level, and front load with style guides and examples.

The new key for documentation is that it doesn't need to be was by humans. Good docs are just as valuable whether people read them, or just ask an LLM and the LLM RAGs the information from your docs. The main difference you have to focus on nowadays is ensuring your documentation, even internal documentation, has good "SEO" that it gets looked up.

Closing social security off to new workers doesn't help, because current workers pay the bulk of current benefits

You don't have to reduce the taxes. Just phase out the concept that you are paying into a retirement account and call a tax a tax. That means you don't calculate how much an individual receives based on the amount they input.

In Australia, we started a sovereign wealth fund[1] to cover the future liabilities from existing workers eligible for government defined-benefits pensions and closed them to new members. I guess that wouldn't make a lot of sense in the US though given the amount of government debt the US has.

Nowdays in Australia people just have accumulation accounts (super) and the backstop of the universal aged pension.

[1] https://en.wikipedia.org/wiki/Future_Fund

This is the confusing thing, the way it is described is like a hybrid of government welfare and a defined-benefit pension.

How can you simultaneously be "paying into" social security but also have describe it as current workers paying for current retirees?

The only way you really find out which one it is is what happens when it runs out of money - if the government backs it up to give you the full "entitlement" you paid into it, then you were in-fact "paying into it". But if they don't, or change the rules then it sounds like you were just being taxed.

The beauty of cat is that streams are the universal interface.

Program A might accept a file as the last positional arg. Program B might accept it as a named arg, where the name/flag could be anything from --input or -f or --file etc.

But a program will read from STDIN, which all good unix programs do, then piping cat into it works every time. I can write the cat foo.txt part before I even know what command I'm piping it into.

Can someone explain the legal structures in place in the US that make Social Security "run out"? Because it just sounds like deliberate indirection put in place by the government to cut funding for pensions?

In Australia, we have a universal, means-tested pension funded through consolidated revenue (i.e taxes). The pension can't "run out", because it is just a law that says that the government will pay you $X after you turn a particular age, if your assets are below a threshold. But if X were too high the Government would need to raise taxes, borrow money or print money to fund it, like all government spending.

Separately, we have superannuation - which I think is similar to 401k except compulsory for employers to pay 12% of your salary into, which are personal retirement savings held in trust to be released at your retirement, but generally these are account-based and in addition to the pension if you are eligible (i.e what you put in is what you get out).

There are older "defined benefits" superannuation funds where payouts aren't account-based (I think based on years of service in government roles or something like that) but they have been phased out to avoid the moral hazard of something government-adjacent having pension liabilities they cannot meet with their member's funds.

So what exactly is Social Security if it can run out? It sounds like a defined-benefits fund that is run by the government - in which case why has nobody closed it off to new members like Australia did when the writing was on the wall?

Perhaps a quirk of the implementation - maybe the site doesn't server-side render links that lead to these items (though many bots run a full browser now), maybe they only track usage client-side or only in their mobile app.

There is such a dissonance between all this talk of safety and the tendency for models to, without any prompting, do very dodgy things to achieve their goal when presented with barriers.

Luckily in my experience it usually ends up only doing it to achieve the task set to it as opposed to anything "malicious", but boy it is scary reading back at how quickly the chain-of-thought pivots to attempts at privilege escalation or searching your disk for secrets when a tool doesn't work.

I don't know if it's the same in the US, but every job in Australia generally comes with a 3-6 month probationary period where employment can be terminated for basically any (non-protected) reason with little notice. I've observed that the option to do so is seldom used - probably because there is not usually much incentives for managers to decrease their number of reports unless there's serious problems.

Most places still interview. Because hiring someone for 3-6 months is still an expense. For large companies, onboarding can take many weeks before you're even thinking about being productive. Interviews don't need to be 100% accurate. They need to be time-efficient and an ok filter to prevent hiring the worst people.

I don't see how a bad job market is going to make skilled people be willing to intern in order to get employment. Employment is a market, if demand goes down, then the reaction will be that price goes down.

The reason students are willing to intern is because the supply is so high and demand so low that you can effectively hire them for nothing (or next to nothing). The interns know that on completion the internship will upgrade them to a new category with new supply/demand. It's the same reason they are willing to pay large amounts for a university degree.

So interviewing will stay the same. If demand collapses, we will see wages drop, and I imagine the supply of software people will react through early retirement, career switching and reduction of people choosing it as a career before we see an upheaval of hiring methods.

Well... in normal times they would be entering at the bottom of the index due to the company beginning to grow, the purchase of which is being funded by a firm exiting the index due to shrinking, so assuming you have bought and held units in the fund, most of the time an index fund is buying low and selling low.

And then when you sell your units, hopefully in aggregate the index is worth more than it was when you entered...

First sigmoid was transformers allow us to rapidly scale to our already abundant data until we tapped it out, the second is/was reasoning, allowing us to scale to our available compute (and compute manufacturing capacity). Correct me if I'm wrong but we don't have candidate for the third sigmoid, and scaling inference is hitting real-world supply chain constraints - electricity and chips.

Short of a third sigmoid appearing in the ML CompSci space, perhaps in the form of ongoing, repeated step-optimisations which will also have diminishing returns, intelligence growth is now limited a few scaling problems that have already been worked on for a very long time.

Transistors, which have been doubling for almost a century now, but Moores Law has already plateaued and reached limits on energy efficiency, and simply building new fabs is not something that we can do exponentially. And the other growth limiter is electricity - there is no exponential supply of fossil fuels or power plants. Although manufacturing has scaled, PV tech improvements are also plateauing - and while storage is getting cheaper, it's still not economical vs fossil fuels (meaning: when we have to switch to it, the growth slows down further) and we are unlikely to see battery efficiency sigmoid enough to maintain the AI sigmoid.

I don't mean to be bearish here. There's so much money sloshing around that we can afford to put the smartest people, using unlimited tokens, on the task of finding small, incremental gains on the CompSci side of things that will have large monetary payoffs - hopefully allowing further scaling and increased emergent abilities of LLMs. Maybe we can squeeze the algos for quite a while. But I don't see that maintaining the same level of exponential as unlocking unlimited data or maxxing out the world's energy/fab capacity for long.

And I don't see why this is a massive issue except for the people who want to have some god-like super AI? Frontier LLMs are genuinely magic. Not "won't delete your production database" magic, but definitely a massive productivity gain for competent knowledge workers.

It is for now.

But I'm sure the scanning operations will start scouring the earth even harder for any books unaffected by slop containing niche knowledge and text in order for their models to have an edge over the ones trained only on pirate collections and the Internet.

I wonder if secondhand bookshops and deceased estates are seeing bulk buyers of their stock suddenly appearing. Maybe broke governments/municipalities will start selling them entire libraries and archives to ingest.

I find it hard to believe that the knowledge to manage a bunch of dedicated servers is that arcane that people wouldn't choose it for this kind of gigantic saving.

Managing servers is fine. Managing servers well is hard for the average person. Many hand-rolled hosting setups I've encountered includes fun gems such as:

- undocumented config drift.

- one unit of availability (downtime required for offline upgrades, resizing or maintenance)

- very out of date OS/libraries (usually due to the first two issues)

- generally awful security configurations. The easiest configuration being open ports for SSH and/or database connections, which probably have passwords (if they didn't you'd immediately be pwned)

Cloud architecture might be annoying and complex for many use-cases, but if you've ever been the person who had to pick up someone else's "pet" and start making changes or just maintaining it you'll know why the it can be nice to have cloud arch put some of their constraints on how infra is provisioned and be willing to pay for it.

I cannot reconcile that growth for non-technical users is going to explode, when most utility from agents is via the ability to execute arbitrary code, generally in yolo mode, with the fact that almost all corporate IT departments do not give users the ability to install anything on their machine, let alone arbitrary code. Even developers at many companies are subject to this despite the productivity impacts.

The culture of corporate IT would need to change to allow it, and I just don't see it happening.

Someone correct me if I'm wrong, but an LLM does not interpret structured content like JSON. Everything is fed into the machine as tokens, even JSON. So your structure that says "human says foo" and "computer says bar" is not deterministically interpreted by the LLM as logical statements but as a sequence of tokens. And when the context contains a LOT of those sequences, especially further "back" in the window then that is where this "confusion" occurs.

I don't think the problem here is about a bug in Claude Code. It's an inherit property of LLMs that context further back in the window has less impact on future tokens.

Like all the other undesirable aspects of LLMs, maybe this gets "fixed" in CC by trying to get the LLM to RAG their own conversation history instead of relying on it recalling who said what from context. But you can never "fix" LLMs being a next token generator... because that is what they are.

My favourite library from these folks is gum (https://github.com/charmbracelet/gum). The basic premise is simple - instead of using hardcoded variables or in addition/instead of using CLI flags, call gum and capture the STDOUT to get the selected input value(s). Great for turning a bash script into a TUI, uses these libraries under the hood.

I find the pattern of showing interactive TUI if required options/flags are omitted much nicer than showing an error/help output.

Future models know it now, assuming they suck in mastodon and/or hacker news.

Although I don't think they actually "know" it. This particular trick question will be in the bank just like the seahorse emoji or how many Rs in strawberry. Did they start reasoning and generalising better or did the publishing of the "trick" and the discourse around it paper over the gap?

I wonder if in the future we will trade these AI tells like 0days, keeping them secret so they don't get patched out at the next model update.

https://jasongi.com

Yes. But that is not what OP comment is asking for. They want one-click. And request based pricing. I was explaining why request based pricing is infeasible and one-click install would price people out (because it would imply a VPS per service).

And I said the same thing at the end of my comment about the way people would host things using docker on a VPS or home server.

Thing is, almost every self hosted app supports docker now and so if you like, install portainer on a VPS or NUC or raspberry pi and you’ll be able to set up most self hosted apps easily without touching the command line.

Because that’s not one-click setup or priced per request, which was the comment I was responding to was seeking.

And I did say at the end of my comment:

Thing is, almost every self hosted app supports docker now and so if you like, install portainer on a VPS or NUC or raspberry pi and you’ll be able to set up most self hosted apps easily without touching the command line.

The problem is that self hosted apps are rarely designed to be run serverless (why would they be?) and giving each app it’a own VPS or hosted container is going to price out the self-hosted crowd, to the point where you might as well be paying for some cloud software.

In particular, self hosted apps usually are using relational databases or SQLite which need persistent disk so can’t run serverless. They also sometimes require writing to physical disk instead of object storage like S3. Writing or rewriting apps to support serverless when they have no technical need to when self hosting would make things more complicated. Most CRUD frameworks used to write self-hosted apps do not work with NoSQL out of the box.

Thing is, almost every self hosted app supports docker now and so if you like, install portainer on a VPS or NUC or raspberry pi and you’ll be able to set up most self hosted apps easily without touching the command line.

Yet, this is also the tragedy of modern software. While a fancy SaaS POS system will be fast and easy to install, the legacy local database version is going to keep working throughout an internet blackout (with cash), a power outage (via backup power) or an outage of the remote server.

I doubt anybody is losing customers over a 1s delay in the till opening or a POS server syncing the day’s transaction after close. But having worked in retail - the one time you get a call from head office is when there’s “loss of trading” - it’s a bigger issue than theft.

I remember there being an entire tourist town that was suffering economically because during peak season, the mobile phone tower was saturated and merchants could not process card payments. You can’t even use click-clack machines anymore with modern credit cards.

Now… working offline is entirely doable in a modern tech stack too - but I somehow doubt most modern POS products support it well.

I would argue there is limited/no market for Database as a Service where the database isn’t hosted on the same cloud provider and region as your application. Egress costs way too much for that.

So you’d assume most people are already dealing with the AWS behemoth.

And if the cloud provider is providing a competing Database as a Service then it’s almost impossible to compete.

Almost every library that exists will have commercial usage.

Usage will likely be skewed to small companies and agencies though. Just like every framework that optimises for less complexity, the disadvantages start to outweigh the advantages when you have so many engineers you can afford to have backend/frontend specialisation and/or you need to support non-browser clients so you need to build services that transport JSON anyway.

Side note/rant: As professionals, we should understand the limitations of different approaches, communicate them to stakeholders and select something that is appropriate for the task.

The problem is, we seem to end up with evangelism where everything thinks their square peg fits in every hole at massive cost to the people they work with/for. Train yourself to recognise this and avoid becoming “that person” that isn’t able to pick the right tool for the task.

See also:

- RDBMS vs NoSQL for everything

- ORMs vs Raw SQL

- Everything is better in rust people

- anti-GC people

- functional programming zealots

- Citizens of the Kingdom of Nouns thumping GoF design patterns at every turn

- LLMs as a solution to everything

- the many flavours of anti JavaScript camp (including, vanilla JS only, HTML over wire, PyScript/ClojureScript)

- writing a SPA for your blog folks

- micro-services vs monolith

- the anti-cloud just give me a VM/cpanel traditionalists

- cloud maximalists provisioning masses of AWS services for a low traffic CRUD site

Picking fruit would have been incredibly meaningful if you had spent the year doing the variety of agricultural activities leading up to it. There’s a reason so many cultures had harvest festivals. But now rather than a whole area getting together to literally pick the fruits of their year-long labour and celebrate we’ve optimised the process by just bringing in some seasonal workers.

For accessibility, consider representing closeness without colour or shade of colour, maybe through a little number or something?

I think there might be too much information given away by disclosing how far away the letter is though. A more difficult mode could be just having three states:

1. Amber: Closest guess(es) so far 2. Red: Wrong guess that is not the closest 3. Green: Correct guess

So you only get new information after the second guess, assuming you don’t hit a green on the first go, and you don’t immediately eliminate most of the keyboard as soon as you are within 2-3 (haven’t quite worked out when the shading starts) characters away.

The whole point of a personal recommendation is you're introducing people you know are good to people you know and trust you. What's the value-add by inserting a new app into the process, that charges one side?

LinkedIn works because you attract supply (e.g professionals) with the draw of getting the personal recommendations/network effects for free and then make money off demand (e.g employers/recruiters) by letting them pay to win and send you spam.

Two-sided marketplace businesses are supposedly the hardest to get off the ground. Especially if you're trying to charge for something that is currently offered for free.

Why would you ditch react because you don’t need SSR? You can still use vanilla React without SSR and serve it statically. It’s not as if you’re forced to use nextjs if you want to use React.

I’m not against using Postgres for this. But I am against the rolling your own distributed task queue. It always seems like a simple task but snowballs in complexity. Any gains you get simplifying your stack will be wiped out by the fact that things like Celery (for example) don’t support using Postgres as a broker so now you have to do your own DIY Celery instead of say, just using Celery with the SQS broker (which… since we’ve established scale isn’t being considered here, SQS costs shouldn’t be an issue either).

Anyone know if there are Celery or Celery-like tools that support Postgres as a broker?

As a side-note, if you want a simple no-frills task scheduler ap-scheduler is a dead simple option. It’s even more limited than the solution described in OP (you can only run one worker so it’s not distributed at all) but often it is all you need especially for toy projects.

The concept of a “develop” branch here isn’t really a requirement to have a branch deploy. Most CI I’ve used let you pick any tag/commit/branch to run on - so nothing stopping you just deploying your feature branch without having a special branch for it.

The trunk (i.e main/master) is the only branch you should really be collaborating on, otherwise you’re going to end up with painful, long-live branches with that are messy to integrate.

An overblown estimate is arguably just as damaging as an overly optimistic one. The thing about estimates I’ve found is that the actual amount of time it takes to complete a task will never shrink to match an estimate, but it almost certainly will grow to match an estimate.

The reason planning poker exists is to create a sort of prisoner’s dilemma between developers to stop this getting out of hand.