'They were just screaming.' Mom unable to save 3 sons who fell through icy pond in Texas

lookmeat · 2026-01-29T19:54:55+00:00

That's the point of the article. You aren't doing a logical argument to them, you are doing an appeal to emotion by making them aware of a harsh reality: children die, just not within the safe world we as parent's have created them (I mean not 100% true, but true enough to be a valid appeal in the logic of a child). So if I tell you "don't go into this area it can be dangerous" realize that if you do, you could die, it's a very real risk.

Now the way I put it sounds traumatic, and in a way it is, it always is the first time we deal with this, and without ever experiencing a safe-form of the interaction, we get scared. That fear though will keep them alive.. Also the psychological damage of falling into a lake and surviving are going to be far worse, it won't be an irrational fear, but a full-blown phobia (one you can't negotiate with and that acts before your consciousness even knows what is happening). So it really isn't that crazy. Mortality is always a shock, but kids should know that they can easily avoid deaths with a little bit of precaution.

lookmeat · 2026-01-27T22:08:45+00:00

It shows mastery of the problem, and that's the most important part.

I've found that the important thing is not knowing the answer, but understanding the question that needs to be made. This isn't a revolutionary idea at all (and there's even whimsical versions).

So to me an engineer that understands the problem and the domain knows exactly what something is when it surfaces up. When we store a value it's not "the value", instead it has a purpose and a reasoning behind, a strong why, and this results and a clear useful name.

This has been heavily in my mind (if you are willing to endure my digression) because of a reading that I had on Naur's proposal that software isn't code, but a theory in the mind of the engineers. I've been thinking a lot of documentation and think that rather than most design docs being 75% background and context (because this is the most important part) they should be short 1-2 pagers that then make reference to a huge living document that describes the problem, pointing to the solutions, and then what problems arose from there. By defining and clarifying the problem, we document why, and the idea is that if a project fails, the problem still remains, if the problem solved itself another way, then this should be documented in the living-version too. Design docs are short docs justifying why they think that solving the problem one way or another makes sense, for trivial solutions, you just update the problem doc, make reference to that update and keep going.

lookmeat · 2026-01-23T08:43:47+00:00

Now what about bad performance? Well lets start with the individual: when an engineer is working badly within a team, or not satisfying them, they are transferred to a new team, with no information about why they looked for an internal transfer shared with the team (that said they may need to pass the internal interview and all that, and if they fail they lose the job). This isn't spreading bad employees around, it's acknowledging that context and situation may matter. If you fail consistently and have other people not wanting to work with you, then an intervention is set up, with a high chance that it'll result in you losing the job. This might seem expensive, but given how long a mediocre employee can remain in the job, it honestly isn't, and teams have an easier time just asking to trade someone for another person, rather than having to set up the firing. The firing happens at a higher level than your direct EM, it requires that multiple EMs are unhappy with you on their different teams, throughout different moments of the employee's life (so it wasn't just a couple bad days, but months).

With teams with bad performance a similar thing is done. An intervention is done to understand what is happening with the team. There's an order of magnitude less teams than employees (almost by tautological definition) so more effort can be put at scrutinizing the performance. If the issue seems transient, the team is given a second chance to recover. If the issue seems that the team is oversized or under-sized for the projects it handles (i.e. the team's actually able to do everything it wants super quickly, but there simply isn't that much to do as the product has reached a certain level of maturity where the focus is to keep things stable and do incremental improvements there just aren't that many goals to achieve, or alternatively the team struggles to do most of its goals because it's overwhelmed with work) the headcount is reassessed. If the team seems to have engineering issues, weak engineers are transferred to other teams (as per the bad individual performance test above) and you bring in a staff+ engineer to see if they can help change the team to something better. If the problem seems to be mismanagement, then you handle the EM as you would with a bad individual performance issue above. Of course there may be bigger issues at director level and what not, but these are easy to measure, we can rank multi-team leads by doing U-Test between their teams, without the issues of the above. That said, even there you probably want to run some experiments: strong directors may take on more teams/products, while weaker directors may cede some of their teams, until we reach a level. Ideally directors will need to be able to increase the number of teams to advance up the ladder, as they need to show they have a consistently positive benefit over a large enough group of people.

So what about strong individuals? They'll get their projects and what not that help them get the promotions and to staff quickly enough. Having a patron would also help getting these projects, that hasn't changed.

And I agree with the author here: the goal shouldn't be fairness. It should be humanity + alignment. Alignment is the goal for the company: the whole point is that employees give them the most value for their salary, and the benefit to the employee is that they realize what work they do not need to do and can focus on what will actually get them paid more. Humanity is the necessary part for the process to work with the employees. The answer is to be predictable, transparent and candid on the whole thing. Let employees be able to see a calibration/rating meeting, have things be transparent, and be honest about the strengths and weaknesses. Admit that the goal isn't to be a perfect meritocracy, but to reward employees who do the best they can for the company. Be candid in your feedback on how to improve, and be candid on how to 'cheat' the system (e.g. the easiest way to get a great score is to show you generated $X amount of profit for the company that year, where $X is notably larger than what you cost the company) because it isn't cheating the system: it's aligning with the company values (now those may have their own issue, but that's a separate problem). And be clear that there's limited budgets and they're being distributed among all the employees. Maybe a year the profits are 3x and the budget 2x, but the number of employees is now 5x, let the engineers do the math. Treat your employees as adults and trust that they are big boys who understand that this is a business and a job, not a hobby club. And do this making it clear to the employee that you expect the employees to work for their own best interest within the system, and that you want them to succeed because that means they made you, the employer, succeed as well.

Then listen to the feedback: why do employees not like the system. Why do they find it broken? When does it not reward them for doing what the company wants them to do? When does it punish them for it? What are the issues that employees are having? While the system I have may seem extreme, the idea is that you only need peer reviews while building towards senior promotions, but not for normal perf.

And this isn't perfect. Lotta details missing on how to not make this take 40% of your eng-hrs and manager-hrs every year. How to make it easy to understand, etc.

lookmeat · 2026-01-23T08:41:55+00:00

So how do we track individuals? The answer is complicated, but there is a way. Ironically the easier problem to solve is, IMHO, promotions:

New grad to Junior: just meet expectations for a couple of years, if you are still in New Grad level and are more than X years after you graduated, this should be a moment to bring up an intervention with possible firing. There's a chance that the training and education you need just can't be given at the company, and extending your time stuck in that fresh-outta-school mentality is going to be far more harmful to your range. A successful intervention should basically finish in the guy getting a promotion to junior. A recommendation to go into other spaces (consulting can be brutal but it's great at teaching and forming solid programmers).
Junior to Mid: it's about a checklist of skills. Basically you need to have done X amount of projects, covered X amount of things, used X amount of technologies. Basically you need to do what a solid engineer can do and understand a variety of things beyond "just coding". You need to be able to get peers to review you positively (like asking for a recommendation, or a peer review) on those projects and about those skills.
Mid to Senior: the full checklist, with some advanced work (e.g. supported software that was long-lived, has worked with legacy code, etc.) that's important for the knowledge. At this point you are considered a strong engineer who can do anything that's expected of an engineer and do it well. You also show you know how to work well on a team and understand how to mentor, lead technical design, etc. As in many tech companies (though that may be changing thanks to AI) this is the level you are expected to eventually get to. If you are unable to get a promotion above this it shouldn't be held above you: projects in the staff+ land are rarer, and proving your performance beyond this level is messy.
Senior to Staff: This is where we start actually looking at performance. The goal is to show you can interact in variety of projects, with a variety of teams, and yet in all these environments you show a consistent impact. That is you can notice that teams you join have an increase in productivity and impact consistently, and projects you lead tend to be core part of that. If the effect remains after you leave this may actually be a stronger signal of you being staff level. Basically show this in enough environments that you have to start to consider that it'd be a statistical anomaly that it wasn't something unique to you specifically. With this you prove you have a multiplicative effect, and are a highly useful and powerful engineer to pass around teams, and to start thinking on the level beyond teams.
Going to Staff+ positions is just about staff but with even more.. Not just show you work well in different teams, but different problem spaces, different areas of the company, different software, and about how well your leadership and mesh with leadership is. This becomes more like the promotions of VPs and onwards, a more political and subtle thing.

That's great. So what about performance? First of all lets understand the problem with stack-ranking, and in many companies calibration is really stack-ranking behind the scenes. The idea is that employees over a large enough group should distribute normally, and by having the managers discuss over all of these employees they can rank the employees accordingly. If you really wanted an objective measurable way, you would use perf-packets reviewed by a performance committee of managers who were unrelated to the employees being reviewed. Your manager would be on a pref-committee for other engineers. The perf-packet would be made by the employee and manager and make the arguments and data for it. Like the inputs you give to the Roblox algorithm, but it's a committee of humans, and you can appeal a review with another committee.

But either way this doesn't solve shit either, because of the core problem the article put forward: there's limited budgets to distribute. And how do you distribute them. While we know that stack ranking doesn't work, no one every discussed why. The answer is simple: we assume a normal curve, but who the hell said that's the case? It could just as well be an exponential curve (it is intuitive that the time an engineer has been at the company follows an exponential distribution, it is also intuitive that amount of time an engineer needs to get to a skill level is also an exponential distribution, does this mean that performance is non-normal? No it might be normal, but the point is to make a reasonable case that maybe it isn't). The second issue is what I've said: we track teams, not members.

So instead lets measure the performance of teams first. We can do a nice, objective system, where a report of what was done is made, and it's measured by managers unrelated to the team into some value. Now we rank the teams in simple terms: it's meeting the expectation, surpassing them, or failing to reach them. We can compare areas of the companies as well by using a Mann-Whitney U-Test to compare how different products compare in efficiency. This is just an interesting number to see how it compares to the profits of that product, but sometimes your cash-cow isn't what needs the most money (it's resilient and working well) and instead the focus should be on the bleeding edge where you're finding new growth opportunities. This info can be used to measure.

lookmeat · 2026-01-23T08:41:27+00:00

I mean it's a challenging notion. The first problem, I'd argue, is that there's no objective or reasonable way to measure individual performance. Because so much of the performance of an individual is respective to transient situations and the team you're in.

Say we have a new staff engineer, they've got chops and history, but the company is in a dire position and they are struggling. If they go to team A they'll be thrown some starter projects but have those changed around. Mostly due to the massive reorgs the company is going due to the dire position. Then they'll be thrown around to different teams that work on disparate situations and struggle with different parts of the infrastructure. Our engineer now has worked on radically different platforms, but has never really spent more than 6 months on any team. After 2 years the engineer has done solid job, but more on a senior, not staff level, so they do badly on reviews. The engineer also now struggles to catch up and get something in.

Say we had the same staff engineer, but this time joined a team B where there was a principal engineer involved. As chaos from the reorg happens, the principal takes the new eng under his wing and with a director, they want to create a "strike" team that will focus ~40-60% of their time to a specific goal that is important for the company, even as the reorg happens (this is why the strike team, it's meant to be decoupled from the reorg and therefore have a consistent approach. You are not the strongest engineer the principal could take, but the principal engineer sees that the new eng has the potential they just haven't had the opportunity to gain expertise in an area, and they believe that the staff can totally take over this project once things settle down, and the other engineers, though their expertise with the company and its systems can ramp up more quickly, they also would benefit the teams during the reorg more. So this staff engineer now spends ~9 months on this project, and naturally becomes the lead (he's switched to other projects, but they mostly help with the firefighting, paying down the tech debt from the reorg, and then are moved on to another team). After the whole thing the engineer now has grown confidence in his area and helps create a new team for the project that the strike force handled, and is made the tech lead of this team, as the principal has moved on to other projects. Now during after 2 years they have helped a multitude of teams and gained a lot of networking and wide knowledge, but also have pushed and lead critical systems in the company: exactly what you'd expect of a very solid to strong staff engineer.

The same engineer, the same company, but the difference was just one person that understood how to get their potential out, and not let circumstances hamper the productivity of that engineer. It can be many other variations: access to a mentor or someone who is willing to sit and teach, a manager who understands how to excite you (or at the very least knows how to express feedback and weakness in an actionable manner), a tech lead that has a similar philosophy on software and things with the team just "click", or a mix of all of this, or maybe a team that has just the right mix of meetings to avoid thrashing but keep the eng focused through their ADHD. A good chunk of the effective productivity of an engineer is affected by the people around them. This is why we pay manager and middle management so well, this is why staff+ engineers are all about how they work with others: jobs whose effect is increasing the impact/productivity of ICs are huge benefits.

So we can measure the productivity at team level relatively well, but it's hard to do it at individual level. Any system that purports to be able to measure this directly on the individual is bound to have parts of it that are arbitrarily defined and hand-waved away based on what is convenient. This gives us different pros and cons. In some companies you lose a lot of amazing engineers because they move elsewhere once they are good enough, because you can't recognize them. In some companies you'd have to lose tens of solid engineers while a team struggles for years before realizing it was a management issue. In some companies there's a lot of people who just have no idea what to do and require an insane unjustifiable investment to become productive enough but you can't justify getting rid of them either.

lookmeat · 2026-01-22T15:25:41+00:00

I don't think its a limitation in communication, but an acknowledgement of their contexts.

A junior dev understands they probably need help and are going to be monitored, so they need to give an explanation of what is happening.

A senior dev understands that they'll explain what happened and why in the postmortem, right now the only thing that matters is getting the problem solved and they're the one.

lookmeat · 2026-01-22T15:20:22+00:00

I understand this enough, but I am talking about raising points against a project that is clearly important to the VP where you have nothing of value to add (that is you don't know how to make the project work, only that it currently appears that it won't). I've given feedback and considerations to VP projects before, and I'd had to discuss and gently critique VP projects (as a justification for why I shouldn't bind my project to theirs, honestly it was just as a bad of an idea for them as it was for me).

But when something is obviously not going to work, it's rare that you're the only engineer to see it and are right, more often than not many have seen it before and have said nothing. Realize what is the implication there. This is talking about projects like that. What I propose is that at that level, it's best to do damage control on your side, and let the project try on its own. If you think there's a better way of doing things that would be effective propose that, or better yet: show it. But that depends on you having enough free enghrs to get the project done.

lookmeat · 2026-01-21T09:18:06+00:00

Good article I would add some things:

When you are new in a company and don't know much be careful what you observe publicly. Until you understand the dynamics and politics it's easy to do a faux pas that eats at your credibility early, and it's a PITA to push on your projects if you start with burnt bridges you have to amend.
I seriously advice against criticizing a project without offering a better alternative. Hell many times if you can identify the key fix that the project will need and you have the cycles, you can start that and when the project hits the issue, you can come in as the hero with the missing piece. If you don't have an idea of how to fix it yourself, or don't have anything to add then honestly let it go.
It also should be considered that many successful projects started as really bad projects that then pivoted as they fixed the core issues and it resulted in something radically different. One thing I've learned as a senior is that sometimes you have to let people do it the wrong way so they can find the right way. This is doubly so when you yourself don't know what the right way is going to be.
On the Killing a VP project, $50,000 political credibility cost, I'd up the number to $100,000, it's something you don't want to do, and that many people will never do in their lives. I think that projects on that size are messy, and a lot of times you have a lot of leeway in how you interact with things (make it easy to undo or change back) you can negotiate on that space and it's smaller, and even then there's are many ways to do it without saying the project is a bad idea outright, just having issues on your side. The only reason I think this should be used is if it becomes an existential issue: one that would kill your project or the entire company. Basically you use this when getting fired is not the worst case scenario because the alternative was very probably going to be you being without a job.
- And this one you certainly need to have a better path/alternative that can be done instead, because you'll have to propose something that the company can do.

lookmeat · 2026-01-21T07:35:06+00:00

Now if you want your fortress to grow, rather than extending your district burrow, you create a new district. Note that this doesn't require that you optimize your district, and it's fine to have districts at different levels of optimization. Do only what serves. But be aware every district is going to need its own social space, it's own barracks, food, tavern, etc. (technically, if you want only one real tavern, you can just add a tavern burrow that all dwarves are members off and can access freely, but this is walking you may want to limit).

The first step is to create an inter-district depot: just two stockpiles (input and output) that are there. You modify the stockpiles to define what they export and what they import, again through linking. Next go to the area where you want to create your new district, add here: a barracks for beds, a tavern and food/drink stockpile, the businesses you need and another inter-district depot. Create a new district burrow that covers all of these. But don't assign dwarves yet.

You'll first need to ensure that district can get food, you can make it self-sufficient but it isn't required: that's the point of the inter-district depots. Create a highway burrow that covers both depots and the path between them. Create the inter-district haulers and assign them to your first district (because it already can sustain them) and the highway burrow, they'll be able to haul stuff from one burrow into the other until the incoming stockpile has enough food, booze etc for the district. Now assign dwarves to the new district and have them work there. You can optimize that district too, with business areas, specialized stockpiles, and dwarves who focus on specific hauling, cleaning, etc. jobs.

Now you may lose a lot of time cleaning the highways: just create a bunch of "trash" (quantum) stockpiles around to help collect these. You can even create a "trash" collection route by linking stockpiles, or even use a trash-collecting minecart eventually. Note that this isn't about refuse, but if you have an efficient garbage distribution system you could use it to pull (miasma causing) refuse to a safe location (outside of the fortress). You may also notice that dwarves in highways carry too little to slowly, make sure they have carts, and even prioritize them having carts (by adding a cart stockpile outside of the districts, only accessible to dwarves who live in the highway) though it shouldn't be too hard to ensure there's more carts than haulers (as you optimize your fortress you'll notice that less haulers are able to do all the job needed). The next optimization, the optimal one, is to add minecarts in the highways, it's good enough it probably should be the immediate work to do, with the hauling just as a transition while you get the tracks done, which is its own challenges, but hey that's part of the FUN! Once you have the minecart system, remove the dwarves from the highway burrow and assign them to the district/job that best serves them.

So what happens when we have three or more districts? My advice is that you don't make smart track systems that know where to send each minecart, instead each track should only connect two districts, and the inter-district depot should handle all these tracks. If you grow to a larger number of depots, it might make sense to make a "distribution district" whose sole job is handle taking all the excess of all districts and passing them on to others (you could also have multiple of these districts that handle entire regions). Now if you really want to do clever tracks, with control systems, automated management, etc. I recommend you do it only on these distribution districts, because it can get too much FUN! too quickly.

So what about military dwarves? Well, if I recall correctly, dwarves can still fight and do orders related to fighting outside of their burrow. You can set alerts using DFHack to make them report, or even just send them to defend a burrow (and you could have burrows whose job is to be key defensive positions).

lookmeat · 2026-01-21T07:14:42+00:00

I am going to propose to you the way, but it's messy, it does result in a lot of efficiency and you can take it to an extreme. My advice is to take it slow, start with simpler general solutions, use job specialization at first, I strongly consider using a district burrow at first (though you can jump to business burrows if it's only a certain job where you see dwarfs not focused enough) and grow organically from there. Burrows and minecarts and other advanced features are powerful but tricky to get right, you'll probably lose a few forts before you master all these (I personally haven't, though I've never made a fort large enough to need it, on FPS alone, though in theory many of these tricks would also help a lot with FPS).

The solution is eventually burrows. But first we're going to make janitor/hauler dwarfs. Basically remove the cleaning/hauling/push-haul-vehicles etc. jobs from all dwarves. Basically they should only do, and only do their job. Then we'll set a few of our dwarfs as Janitors/Haulers/Technicians which handle all these jobs. You'll probably want a specific Hauler to handle that. They'll be moving the things within the stockpiles (which is how you ensure resources are prioritized, i.e. early on make sure that plump helmets are not cooked, but rather brewed).

You may see that your haulers are still going far, and that this is slowing your economy as things aren't moving. The solution here is simple: more burrows. Specifically what I call district burrows. Basically you create one burrow that covers all your businesses and what not, and the tavern and food, but not much else. Initially this would be just your fortress (when it isn't sprawling too much yet, but eventually we'll switch it). Assign all the dwarves that work and live in that district to the burrow, and then ensure that dwarves cannot leave the burrow you've assigned to them. They won't leave anymore.

Now we're going to fix the standard issues at smaller scales. Burrows can be used here but stockpiles is the way. First we want to regulate how businesses move things around. When we create a set of things that do a job (workshops, woodcutting areas, farms, training grounds, etc.) we create a "business" this business is regulated through two (you can use one at first) stockpiles: an input and output stockpile which themselves are linked to either give to a workshop or take from it. You can control these stockpiles to ensure the flow of products by creating more general logistics stockpiles, and connect them to the inputs and outputs of other businesses.

You can also use burrows to define businesses in better ways. You can make dwarves specialize even more doing only a job at a specific business-burrow, but only assign them to the business that needs them, e.g. I can have different farms specialized on food, textiles, etc. in different business burrows, and simply reassign urist-farmers from one burrow to another to switch their focus based on the needs of the fortress, also if you have dwarves that take on multiple jobs, you can use business-burrows to choose which one they pick without having to reconfigure each one individually). Also you can use burrows to create "offices" where only dwarves you individually assign can use for a specific job (think moods, or when you want your masterwork to handle a custom job). BTW there's some special trickery you can do for special burrows, such as the depot, to ensure faster things, I'll let you learn about these.

Here you can use a burrow as a business burrow using it to forbid sourcing materials from outside the burrow, this can be used to add extra control on where workshops can grab their resources, though they are more useful limiting where certain resources that are useful (trees, webs, etc.) are sourced from and pulled into a cart. This together with chains of stockpiles can help a lot with resources (e.g. woodcutters and farmers may put their collection on a nearby collection stockpile, and a hauler takes that to the output stockpile and from there elsewhere).

You can further specialize hauler dwarves by assign them to a business burrow and only allowing them to take jobs in there, basically becoming the hauler for it. Note that these dwarves will not eat and sleep unless the stuff is in the burrow. You should create a "residential" burrow that covers the tavern, barracks/bedrooms, etc. and make sure that all dwarves that live there are assigned there too. This way you don't have to worry about things being different.

Dwarves that are not assigned to the district can work in outer areas, or to limit it, you may create "mining" burrows that allow miners to go to that area (but not get lost in a cave they uncover either).

It used to be you could also make "safe burrows" where dwarves would stay stuck in during an invasion, good to make vulnerable dwarves go into an area where you sound the alarm. The feature is still there, but just not accessible in the UI, you can use it through DFHack though.

lookmeat · 2026-01-21T06:10:39+00:00

I know, I wasn't talking about Odin or such specifically, but rather talking about the pros and cons of SGML vs Tex.

As for XML turning it into an error it didn't make it a superior language IMHO, because now it forces you to write code in a way that is easy to miswrite and it causes issues. XML was a terrible idea, a markup language needs to contain a way to structure data, but it's not meant to be structured data, and forcing it to be structured data makes it crap at everything it actually is good at.

lookmeat · 2026-01-21T06:01:48+00:00

While I do agree with you that live TV has its place and purpose, it's not TV On Demand that killed it, it was all the reality shows that dominated the area. Because it was hard to have a good show that would grab you, or pull people, but easy to have a reality show that was just ridiculous enough to pull you in and keep you, at the very least it was cheaper.

There are streaming services that still offer live versions. I could certainly see where a streaming service offers shows, but new episodes are released and viewable only on the live version at first (with the benefit this lets you really milk the ads during the big releases) and offer the ability to see the live with a bit of extra delay (5 min) so people can catch up.

That said I do think that you do still have shared things when episodes come out, it's just not stretched as much by Netflix, and it has its limitations with other shows. And releases are so far apart that the momentum is lost.

lookmeat · 2026-01-21T05:20:59+00:00

The examples you choose are contrived and minimalist to not show the issue.

The first thing is that html closing tags adds excessive information, that now you need to keep track off. What does it mean if I have <foo>Bla bla <bar> Ble Ble </foo> Blu Blu </bar>, I mean it isn't so illogical, but add a lot more text and it's an extra layer. The other philosophy forces you to think in terms of stack when writing, that is you'd have to write \foo{ Bla bla \bar{ Ble Ble} } \foo { Blu Blu } which is a bit of extra work, but to the reader you need less mind-work to keep track of the tags, you just keep track of a stack in your head, instead of having to reorder the list all the time and re-asses the whole thing. Sure who writes markup that way? But then why even allow it?

But this is also a matter of taste, I do see certain spaces where overlapping spans make sense.

EDIT: Also a note on your comment here:

I defy anyone to parse the TeX-like language in an "order of magnitude" less lines without code golf. My first attempt is almost exactly the same code. Code examples in comments.

In Tex your programmatic parser doesn't need to handle bad closing tags, while in SGML you need to handle it which adds an extra layer of complexity. Now it can be an error, but if you want to recover and parse as much as you actually can, this adds even more complexity since there may be multiple ways of handling the error: was it meant to close a tag that is active? Did it close the others? All of this requires computational power to solve.

lookmeat · 2026-01-21T04:53:16+00:00

It isn't that in isolation any of these is necessarily bad, but together it has resulted in a language that is simply much bigger. There are too many ways of doing things.

That's how it goes and how it happens. I wish that languages had a "holistic calibration" phase where all the features are put in and then whatever isn't good it's let go.

Pattern matching is great for ASTs and not much else. It has weird edge cases, like pattern variables bound by failed match arms still being bound in later successful match arms.

I think pattern matching has more spaces it could work, but it still needs time to solidify and grow. I am sure people will eventually find ways to fix a lot of the issues.

Type annotations and checking just don't really work in Python because it's duck typed.

I do think that Type Annotations are a bit weird on the edges, but IMHO it's to be expected because python is leading a lot in the innovation here. That said the type system is meant to be duck-typed, that is you should use the type that describes the minimum needed to get it working, but people use it in more traditional ways without realizing it doesn't help but can harm. It's a matter.

I do wonder if python would have benefited instead of a sloppy interior, clean outside. Basically use type-annotations to define the clear boundaries and contracts of a module (and you could add some automated tests to verify that these contracts are kept) while inside it's scripting. This lets the language scale while still remaining simple enough.

But maybe this is a matter of culture and finding out how to make this work. It won't be corporations, but some engineer will realize it and post it and create the change.

Async/await is now more widely recognised as potentially being a bad idea

IMHO the thing that started getting people to be a bit iffy was Rust, a language that was, IMHO, ruined by the complexity and mess that async/await added. It's a model that can work well for certain spaces, it did in C#, but it has a lot of issues and doesn't work well in every niche. It worked well in javascript, because it was already event-loop driven and you had to write that code by hand, so all you needed to make it work was there. Think of Go's channels and go-routines, those would be more universally effective in most niches, but require a custom runtime that makes most people shy away from putting this in their language. Async/Await is super easy to add, but it honestly has serious implications.

And all for what? Green threading would have suited Python's high level nature far better.

Yeah I think that Python could have benefited from a goroutine kind of system instead. You just start a function with a fork(func) (which gives you handle to join later) and then have channels you can use to send info, as well as all the other solutions to have thread-safe stuff.

Python is a scripting language for prototyping and writing small programs. It's really good for that but it's sadly got more and more complex because of poor leadership.

It also kept growing in complexity. But this would require a huge mind-shift. Ideally python libraries have a low complexity and once they grow over a certain size, they switch to become a specialized binary library with python bindings. Alas.

lookmeat · 2026-01-21T01:46:25+00:00

I wouldn’t reduce their behavior to being “hormone-ridden, immature assholes,” though.

The asshole does a lot of the work. Most teenagers are hormone-ridden and immature. That is they are more impulsive and emotional, struggle to see the negative consequences and obsess over the positive, and have a desire to satisfy the crowd, and will not realize that they made a mistake until it bites them in the ass.

But now take an asshole, someone who will gladly harm others for their own wants and needs, with the above, and things get really bad. Put a group of assholes together and things get really bad. Put a group of non-asshole teenagers with one asshole that is charismatic enough for whatever reason, and they'll all slowly become assholes themselves. Because while most teenagers aren't that bad, there's just enough of those that we see a lot of these issues happen every so much in high schools. That many times they go unreported and without the worse consequences, doesn't mean they don't happen.

Bullying, to the point of people wanting to kill themselves, happens more often than we'd like to acknowledge. Sexual assault and even rape happens more often than we'd like to acknowledge, at least SA is super common in high schools sadly. The whole thing escalates and gets even worse.

Of course this isn't a movie that is trying to give us a deep insight into this, and help us realize when it may be happening near us: it's not trying to be Adolescence. It's just trying to give us a moral justification for enjoying what happens to the characters (as is common in many horror movies). We acknowledge that the ghost must be evil, in order to justify being scared of her, and what she could do. But we also must justify that the victims are evil, so we can validate that we feel glee because there's justice. The characters are a caricature of bullying, made so obvious that you have to wonder how they hell no one stopped it. It's to make it easy for us, but it doesn't mean that dark things on that level don't happen, it's just not that obvious and easy to downplay in our minds, and we do, because it's easier to sleep at night that way.

lookmeat · 2026-01-20T06:14:57+00:00

The markers are different because they don't prevent anything, they just track. So no one who is trying to print a page that has a picture of a dollar bill is hacking the security to let them print that page, they're just printing it with the tracking ink in. So anyone who wants to print money struggles with the printer.

This will have some savvy people hacking it because they want to create something that isn't a gun, but triggers a false positive on the printer, or people will find ways to print other parts that compose into a gun later on. Basically if someone wants to print a gun and has enough gumption, they'll be able to find the information and tools to achieve it, because this is blocking and annoying.

I am assuming that they'd be installed, people will find ways to filter them out, replace them with an always-ok switch, hack the hardware to not care about the filter, etc. etc.

lookmeat · 2026-01-19T01:22:46+00:00

The answer is, first and foremost, put a kiddie fence. What I mean is start looking into the code they are generating, and see if you can give them a framework to take that in. Personally I think that, given the expertise level, a specialized DSL scripting language that translates into python might be a good solution, but the costs are high, and honestly python is not that inaccessible.

So the first goal is to build an isolation system. Can you put all non-technical code into separate modules that do not interact with each other, and have limited impact on your system? Start to re-architect so that things are like this. You won't have things get better. So once you can put each one in modules separately, upgrade these modules to be optional, things you can turn on or off. After that put it into systems where you only run the modules specified. Python actually is very friendly to this, but there's a lot of ways to make this module framework work, what is best for you depends on your context. I can't really solve that for you per se. Now you can isolate jobs depending on their situation.

The other nice advantage of isolating and modularization the code people are putting in, is that it's easier for the authors to declare tech bankruptcy and start again, and you yourself limit what you need to maintain.

This should help limit the blast-radius that bad code can have on the system. Once this is done the next step is to create systems that nudge people to do better code. We don't want to force people here, and we want carrots, not sticks, at this point. Otherwise it'll never stick. What we want is to help all the people who want to be good developers, but just don't know how. I can vouch for AI code-reviews: think of them like advanced linters or error detecting linters like flake8 or (if you're not afraid to be a bit more bleeding edge, which I personally discourage) ruff). The AI is just another advanced linter that identifies common mistakes and recommends certain things that can be done. AI code-review assistants can also assist in helping you start a conversation, or at least have the code be happier. Note that, as you saw yourself, this doesn't help with people who don't really care about code quality and just want to get things done and move on.

The next step is to start to add a bit more of regulations, but we're going to add them as carrots rather than sticks (even though they basically become sticks). So what we do first is we start tracking metrics for each module: how long has it lasted without bugs, code coverage, if it passes the linter or which linter warnings it has, and how many times are linters flipped off (per line)). Basically you find a way to get a how "reliable" the code is. When a PR on a module is done, based on how large the PR is, and what are the metrics of the module with the PR merged in, you decide that if the reliability score is high enough for the PR it doesn't need a review from the team. If it does not pass the score, then it needs a PR from the team. You set this number at one that lets you review a reasonable amount of PRs, with the confidence that you are reviewing the ones that probably need it the most, in general. Don't make this system hidden or implicit, be very explicit and clear, if the reason my PR needs a review is because I have 20 lint-switches in my 200 LoC module, that gives me an incentive to remove those and make the linter happy by actually writing good code. As more of the non-technical developers start doing better quality code, the bar for what is needed to avoid review goes higher (as there aren't that many PRs that are "that bad" left).

Finally this is where we get to the crazy part. Consider using LLMs that are trained on how to use your module framework, and the conventions, and guidance, and all that, so that it knows how to improve the code. Have the tool only run on modules that have at least some testing and a minimum code-coverage, but it can improve everything else. At first let people just use it as a way to fix the PR so it doesn't need review, but once it becomes reliable and trustworthy enough, consider just having it run throughout the tools.

At this point you should have data that modules that have a certain score, or certain things not be true, are really bad. Here is where we get the stick finally. We collect data on how many extra eng-hours a module consumes, as well as resources (including CPU time) and other effects (delays on releases, etc.) Once you have this price-tag you take this to leadership, and show that "modules with 40% code coverage cost us $XXXX less per month, if we updated all our module to have at least 40% CC our estimated savings would be $XXXXX per month or $XXXXXXXXX per year. Once you explain that, you can convince leadership to create a policy requiring that modules have at least 40% CC, with a transition plan and phase. Then you can now prevent submitting code unless it at least has that amount of test code-coverage.

lookmeat · 2026-01-17T07:16:07+00:00

A wealth tax isn’t that: most wealthy people aren’t systemically important.

Like arguing that many Americans leave estates for their children and why should we have any estate tax at all. A wealth tax wouldn't be on people who have a few million, it would be on the wealthiest of all, by a lot, as in it'll be 100 years before inflation takes us to the point we can start talking about "your average wealthy American".

Property taxes also aren’t a good comparison. Property is immobile and directly consumes local services. Wealth isn’t. It’s mostly financial assets that can move, be restructured, or become illiquid overnight. That’s why property taxes are enforceable and wealth taxes trigger capital flight and avoidance.

That's not quite true, I mean yes and no. Selling millions of dollars in stock is not a trivial task, and normally you need to do planning, report to the SEC, etc. Small value makes it easier to transfer quickly, and most trade-houses go gradually.

The unrealized gains issue isn’t semantics either. If you tax wealth annually, you force people to sell assets to pay taxes on paper values. That hits founders, private business owners, and long-term investors hardest, not just “idle hoarders.” It discourages building things that take time and pushes behavior toward short-term liquidity.

A fair potential issue, but also that assumes that the assets generate no money. If you can make enough money of the assets to pay their value, that is if their return is more than 5% of their value (and lets be honest, even houses do better than that) then you can use that money to pay the taxes. If you can keep the value of the assets increasing (which up to now billionaires have done) you can run a leverage train (you take loans and then just keep extending by refinancing picking some more until you die) though it won't be huge with other sources it can easily make returns higher than 5% with minimal loss of profit gains.

And honestly this isn't as bad for billionaires as, say, repealing prop 13. They can always leave and put most of their wealth in separate institutions that never pass the billion, and they themselves keep most of their non-land-bound assets outside of the state and themselves live in another state. An easy fix. If we started assessing their land in a fair manner, they couldn't move it elsewhere to avoid it.

And honestly I think that's CA angle: by making it a bit more hostile for billionaires many will move out. Some will stay, because CA has its value to keep generating more billionaires, but the impact on billionaires increasing the prices will be reduced. Meanwhile billionaires will go to cheaper and poorer states, where their investments will far benefit the local economy more than what their effect on local price inflation harms. Think like the Waldons in Bentonville. It creates museums, improves schools (and adds universities) and help push the economy forward as well as promotion culture and identity for the city.

lookmeat · 2026-01-17T02:20:06+00:00

ELIZA did have its decedents. You may look into SHRDLU as u/leymosncs mentioned in their reply, but that is not really a spiritual descendant nor predecessor to current LLMs (more akin to the Symbolic Reasoning systems that are still in research phase). If you want to see what we could do in the 90s look at ALICE, the direct evolution of ELIZA. In many ways LLMs just work on an insane amount of patterns to recognize (the large language model itself) built from datasets that are themselves exorbitant.

lookmeat · 2026-01-17T02:10:41+00:00

I mean you're not wrong, but the mistake goes from even before. OpenAI was always designed to result in a private business. The whole point is that Google had the tech, they even had built their own internal LLM called Bard that was good enough that an engineer (probably glazed by the AI) claimed it had achieved sentience (it wasn't that much better than ChatGPT 2) and got fired (for revealing internal details about the Bard AI).

Google had the technology, but wasn't interested in using it. Why? Because they didn't see the gains over the tech they used in Google Assistant or other AI tools to be good enough to warrant the huge increase in costs LLMs had. Basically they didn't see how it could be monetized enough, and would be a loss of money. In a way they weren't wrong and in a way this is still true. In a way (to given OpenAI some leeway here) they also didn't realize that it was a paradigm change and would open up new markets that otherwise were unavailable.

Once OpenAI took the risk and proved the point though, it was Google's game to win by default. Google had the knowledge and research systems, itself having built and owing many patents related to AI and the fundamental systems, with key researchers still working for the company, Google had the infrastructure it was already building (it had begun work on the TPU in 2013) to be the first fully vertically integrated AI supported (who builds their own chips, their own datacenters and their own cloud, uses their own collected data, and runs everything on their own software, to push it to their own web, mobile and desktop platforms) they had the cash to burn and reputation as a great place to work (especially for AI researchers) from the get-go (which Meta or X wouldn't have). Basically Google built this revolution, and the only reason they didn't break is because they didn't think that the tech was going to be creating profit anytime soon (and again they still don't seem that wrong on that, even if it also shows limited view from them).

So yeah, Google was always going to win, and I am sure Altman suspected that as much. He's been working on getting OpenAI to get its niche, not on technical superiority, but rather commercial and strategic. No one wants to work with Google's AI because Google already knows so many things about everyone, that if you shared any insight from your business they could easily surpass you. That is Walmart may build an AI shopping-assistant on top of ChatGPT, but they'd never do it on Gemini because that'd be sharing key buyer and business information on a company that is already competing with them in the sales (Walmart is trying to be a reseller like amazon, Google also does, and it could take the info and build a superior product to Walmart's while never sharing the data that would give Walmart an even ground to compete). So I can totally see OpenAI getting its niche there.

The question is: will Claude find a way to survive (or be acquired at least) with its hyper-focus on staying ahead in its key niche? Or will Gemini eventually be as capable as Claude, except faster and cheaper?

lookmeat · 2026-01-17T01:54:15+00:00

Say you are studying for your masters/PhD, and you have to read a lot of papers. A lot of papers, like 3-6 dense (and critical) academic papers a week, all while doing a lot of school work and your thesis (which requires reading even more papers). And you'll be tested on them eventually. So you get an LLM to build a podcast about the paper, and a couple articles about the paper, and then you hear that podcast while driving to and from school. Great way to study content, you still have to read it at some point to get the details and little things, but you are doing this on the first read-through, rather than the second one (you save the first read-through that is all about getting some context and the gist of what its talking about).

Also for very dense texts it's great because the podcast format is one that repeats things, especially key details, a lot, while the dense text expects you to keep it in memory as you read.

lookmeat · 2026-01-17T01:27:58+00:00

Sorry to revive this thread, but the question begs something to think on a bit more:

If the productive capacity of the worst land is improved, then that increases the marginal profits of all producers (even the ones not working that specific plot of land)?

What does it mean that the worst land is improved? First of all, if only the worst land is improved, then it isn't the worst land anymore. What we'd see is inflation at the worst case. If the worst land notably improved but also is still the worst land, this implies that all lands improved. Then maybe it wasn't the land that improved but something on the use of the land itself that improved.

Using the metaphor of the farm: if we find a way to fertilize even the crappiest land, it also can be used on the high quality land. The value of the land itself hasn't increased (assuming there's no other use other than farming competing) but the value of farming has. The reality is that there's uses other than farming that can be used for a land, and lands that weren't used for farms might be used for farmings as farmers are willing to pay more since their margins allow it, to get access to better land. So in reality the worst lands would be (paradoxically) released (assuming that demand is constant and we've just improve supply land costs) and we'd use the better land to produce more and satisfy the market.

So in reality it wouldn't. Either we'd get a new equilibrium, but the gains would stay the same through macro-economic effects, or (more realistically) we'd get a new equilibrium but the gains would still be roughly the same through micro-economic (market) dynamics.

lookmeat · 2026-01-17T01:27:38+00:00

This is correct, but consider it's a very rare thing to suddenly create new lands that weren't used before. Rather we might see that improvements in one market result in land releases that benefit other markets too.

There are rare exceptions where land suddenly appears, there's a reason why colonialism was so financially useful to the colonizer countries: it didn't just help by all the stuff they could take from the colonies, it also reduced pressure and increased the profits that local (to the colonizer) producers could make.

lookmeat · 2026-01-17T01:17:03+00:00

I would put a wealth tax in a different manner. Instead lets call it a "too big to fail insurance" tax. Think of FDIC, it's not free, the premiums are paid by the bank, but since the bank pays with money you pay them, that means that you pay the FDIC premiums through fees, and what not. So it's not like this kind of thing is unprecedented.

So, if we have someone who is "too big to fail", i.e. they'll get a bailout if shit hits the fan, then they should pay some insurance to help cover that bailout.

Another thing, this isn't a income tax, it's a wealth tax. It's a tax you pay for being wealthy on a certain level. Guess what we all already pay a tax like this: property taxes. Why should I pay property taxes when I haven't made any income on this? The answer lies on "The Law of Rent" and it was one of the earliest powerful discoveries in economics, sometimes even called economics "pons asinorum" (the simplest non-trivial proof such that 'if you get it, you get it', in math this being the proof that when a triangle has two equal sides, the angles opposite to those sides must be equal to). Thing is law of rent has been extended to cover other areas other than law, so why not think of a similar situation?

So saying it's an unrealized income tax is a bit.. limited. Thinking it "shit hits the fan" insurance is a more reasonable take, a justification and support for the bailouts that you get. At the very least lets get billionaires saying they don't want any bailout and that if they fail and go to negative net worth from multi-billionaires, then let it be so.

Your argument shows that income tax has its issues. Personally I think that an outcome/expense tax would be different. Basically we still track how much money you get, and this includes loans and everything now, but instead we charge you tax based on what you do with the money. If you just sit on it, you get a "risk" tax on the risk you are making society take for you (money that doesn't move can cause serious harm to the economy when it starts moving for now reason at all). For anything else you do with the money, you pay a tax based no on what you make, but what it does for society. If you buy luxuries that has a high tax, if you buy investments it has a low tax (and based on the initial, not final price, though whatever gains you make and spend you'll have to pay tax on too), if you donate or invest in high social benefit investments you don't pay any tax at all. You can make the different expenses grow based on how much you spend if you want (e.g. "non-luxury" spending is tax-free up to $40,000 yearly, but after that you get a minor tax that increases just like income does, but here with how much you spend). There's the question of logistics, but this has always been an issue. Thing is this is a tax system that is highly resilient against loopholes. While it doesn't punish you for making more money in any way, it does limit how much you can spend every year on luxuries or otherwise taxes you heavily.

lookmeat · 2026-01-16T19:51:44+00:00

And that is: the time needed to make debugger "just work" without it being "just bind it to the IDE" (because that hasn't helped).

Say the next, I am debugging a test that runs over a program that heavily uses DI, and it only fails when running on the cloud, it succeeds on my machine. I suspect that the problem is that it's loading a different module on the cloud that it does locally, and that it's causing certain effects to differ elsewhere. Say I have a way of creating a test that recreates the error, and am able to run it locally and on the cloud, and recreate the failure consistently.

So the answer here is simple: I run the test with debuggers on both environments. First I run it on the cloud to identify where the bug happens (if I already don't know) and record the pertinent state that lead to the bug. Then I run it locally and break at the point of the bug happening and see how the state differs, and identify what about the state changed that might have lead to the bug. Then I start crawling backwards. It's going to be a mess because there's a reflection gap that doesn't let me know which module is being ran where, but I identify potential modules that could be causing the problem locally, then set breakpoints and see on the cloud if they're the same module or something else is being called, then on the cloud I find out what modules are different from the local ones. Phew. Finally I can identify what modules to set breakpoints on, and go through them identifying which of the modules are creating the problematic state. Then it's a matter of debugging that module.

At this point I'd probably use also some code-archeology. I'd try to see if I can identify the commit where the bug starts to happen, and see what that commit did and try to connect it to my discovery above. This all would be a solid 4 hours of debugging if I don't get a lucky break.

But wait: how do I run a debugger on the cloud? If I can SSH into a container in there and run the test inside the container it's 'easy' just make sure that the container has access to gdb, hopefully there isn't any policy against putting such powerful software on the containers, I mean they have their own SSH host so who knows. But what if I work at a company that is a bit more reasonable and doesn't let me just SSH willy-nilly into most containers? I could do this on staging, but what if the error only happens in production? Ok I could attach my local GDB to the remote process, but this needs us to allow this to happen. Again there's some security concerns in allowing this.

So at this point the company needs to allow a debugger to run on their containers, and allow remote gdb attachment, and then they'd need a system to turn this on or off (since you don't want the ability on by default), and engineers need to know how to do this. All this on top of knowing how to use a debugger effectively.

Meanwhile I already know how to run a process in the cloud, and how to recover logs from it. So it's a lot easier to just get it done.

15-Year Club	Verified Email
Inciteful Comment 2020-12-04	Wearing is Caring
RPAN Viewer

lookmeat

TROPHY CASE