School walkouts typically have nothing to do with the school itself, and certainly do not ask for it to be allowed. It is the kids who walk out. The schools typically treat it like any other unexcused absence.
OK, cool, but... why? If your goal is release notes with content meaningful to the user, not just tech details, wouldn't it be even easier/better/cheaper to just send the content of Jira tickets instead of all the code into your context? (Or whatever PM system you use to track your product work)
After all, that would include user-meaningful content already as well as priorities and other business context. Why guess information from code when there is probably already a system that has those answers?
Edit: I just saw where you posted this a month ago, too. From that post: "I'm a PM at Arthur. Every release I'd spend hours combing through commit logs and PRs trying to write something coherent for our users. "
Now I'm doubly confused. You are a PM who doesn't track the work? You comb through code? This makes so little sense. That isn't at all typical of how PMs work?
No, I have the opposite reaction. A new company with funding to me just implies a runway that will run out, and no profitable business attached to it. Show me a balance sheet that is self-sustaining on their own revenue, and I'll work with them over VC-funded startups any day.
Are you joking? The cost of writing code is practically free. Some basic hosting is very cheap. Find just a couple of paying customers and you are self-sustaining. Hire only when the revenue supports it, and you remain that way.
I think it is a lower level problem than that. "Founders" fall into the trap of thinking that getting funding is a fundamental aspect of building something new, when it is not. Instead of building a solid business plan, then applying funding if and where needed to resolve constraints of carrying out the plan, they make their plans with funding as the primary goal, and only later determine whether or not it is actually a viable business.
This is exactly right and there's a tell that I've noticed after reviewing hundreds of decks and talking to a lot of founders.
You can figure out pretty quickly whether a founder has been forced to actually sell something or whether they've been living in pitch mode. And the difference shows up in a really specific way.
Ask them about their customers. The founders who had to sell to survive talk about specific people. They know the person's name, what their actual objection was, why the third conversation went differently than the first two, what made them finally sign. The detail is almost uncomfortable sometimes.
The pitch mode founders talk about personas. "Our customer is a mid-market ops manager who struggles with workflow inefficiency." Technically an answer. Completely useless information that tells you they've been reading about their customer rather than talking to them.
The brutal thing is that early fundraising success can actually mask this for a long time. A founder who raises a seed round before they've had to sell anything gets 18 months of runway to stay in pitch mode. They raise the seed talking about potential. They raise the A talking about momentum. By the time you're at the B someone finally asks a hard question and there's nothing underneath.
The founders who couldn't raise early and had to go find a paying customer instead got the most important feedback the startup world has. Someone who has no obligation to be nice to you decided your thing was worth money. That's it. That's the whole game early on and most of the ecosystem is set up to let founders avoid finding that out for as long as possible.
A database is a file system when you get down to it. The reason people use them is to abstract up a layer so you can query the data and get the results you want instead of having to iterate through direct reads of a disk, then having to read, parse, and filter what you want from those reads. You could always write code to help do those things direct from disk, but you know what you have just written if you do so? A database!
It would be straightforward, for instance, to implement a lot of the functionality of a filesystem in a database with BLOBs. Random access might be a hassle, but people are getting used to "filesystem-like" systems which are bad at random access like S3.
> You could always write code to help doing those things direct from disk, but you know what you have just written if you do so? A database!
Yes, but that's my point. Why is this not a part of the standard library / typical package with very little friction with the rest of the code, instead of a separate program that the standard library / typical packages provide in an attempt to reduce the friction?
Or are you making the general point that databases already existed prior to the standard libraries etc, and this is just a case of interfacing with an existing technology instead of rebuilding from scratch?
Because a reasonably well optimized database with support for indexes, data integrity enforcement, transactions, and all the other important things we expect from a good (relational) database is complex enough that it takes a rather large codebase to do it reasonably well. It’s not something you slap together out of a handful of function calls.
ETA: look at SQLite for an example — it’s a relatively recent and simple entrant in the field and the closest you’ll find in the mainstream to a purely filesystem based RDBMS. How would you provide a stdlib that would let you implement something like that reasonably simply? What would be the use case for it?
Actual Title: How to Delete Yourself from the Internet in 2026 (The Real Version)
Welcome to HN, where the guidelines can be found here: https://news.ycombinator.com/newsguidelines.html, and which include both using the actual title and participating in the community, not just popping in for self-promotion.
That seems like an acceptable constraint to me. If you need a structured query, LLMs are the wrong solution. If you can accept ambiguity, LLMs may the the right solution.
And at the same time, professional woodworkers still exist, and people really hate on IKEA desks.
So I agree - the number of professional software engineers may decrease, but it isn't going away. And based on what I'm seeing in my consulting gigs, the senior folks won't ever be replaced - they may spend more time fixing slop than doing greenfield work, but the jobs will be there.
That is a really poor sampling of scores, though. That makes their "Beethoven" example an outlier from someone who wouldn't even be in the top if you included the full spectrum of scores. There was also no link to a study, just a tweet saying there was a study and a URL that doesn't work. This smells a lot more like someone trying to push their own agenda than objective data analysis.
reply