It also trusts your neighbor, your kid, your LLM, you, your dog, another linked list...

When I do use the agent, I inspect its output ruthlessly. The idea that pages of code can be written before being inspected is horrifying to me.

Pretty fun game you got here though. I would like a retry capability so I can try to find another (read: the real) solution.

It's as if you wish us to say, "I've figured everything out, let me show you the way." I don't find that particularly reassuring, and it's not exactly the kind of humility that I think you want to convey.

If your bar to helping others is ending all suffering within yourself, then I'm afraid we're all going to be living a very lonely existence if we followed your lead.

Now, I think your larger point is that folks in crisis should tend to that crisis, which I think anyone who has taken a plane ride would understand. Apply the mask on yourself first. But to extend that analogy, you can have a broken hand, or even a broken heart and still be able to help your neighbor.

I think this needs to be highlighted, because while I completely agree, I think it's often implicit, taken for granted, and neglected. Far, far too often I've seen code bases bloat because this never takes place. The sentiment at a lot of places seems to be, if the tests pass, ship it. Arguably, it may even be the right decision.

I don't think your code base needs to be very large, or very legacy in order for comments to be valuable or even the best way forward. If the decision exists between a somewhat large refactor or a one-off comment to account for an edge case, I'm likely to take the latter approach every time. Refactors introduce risk, add time, and can easily introduce accidental complexity (ie: an overengineered solution). Now once that edge case becomes more common, or if you find yourself adding different permutations, yeah I agree that an incremental refactor is probably warranted.

That said, perhaps that comment could — and certainly one should at least supplement it — be replaced with a unit test, but I don't think its presence harms anything.

Using object arguments is a great start, and I think using enums can also be powerful (if you're using string literal types). But often times I reach for explicit interfaces in these situations. IE:

type FooScenario = { arg1: true; arg2: true; arg3: true };

type BarScenario = { arg1: false; arg2: true; arg3: false; }

type Scenario = FooScenario | BarScenario;

...etc

This provides semantic benefits in that it'll limit the input to the function (forcing callers to validate their input), and it also provides a scaffold to build useful, complete test cases.

Yes, by definition. The question is, how much is too much money? And in what context?

Put another way, in a given economy, how much do the wages between the top and bottom earners need to differ in order for there to be not only a perceived inequity, but a genuine ethical imbalance?

- OrioleDB is a new storage engine for PostgreSQL

- PostgreSQL is most-loved (whatever that means)

- OrioleDB is an extension that builds on.. other extensions?

- OrioleDB opens the door to the cloud!

In the wake of crypto and other Web 3.0 grift, this is not the tact that I'd take to release something that extends and improves on something as important as PostgreSQL.

[1] https://github.com/orioledb/orioledb

[1] https://www.fdic.gov/bank/historical/bank/ [2] https://en.wikipedia.org/wiki/List_of_bank_failures_in_the_U...

[1] https://www.fdic.gov/bank/historical/bank/

I agree you should push back against this as a manager, but it can be hard to do so tactfully from my experiences. You either have to say, "no," or engage in protracted debates on subjective ideas around readability and maintainability.