mjlawson

I think what we're seeing here is the consequence of the word lobbying being used when we lack a better alternative. It's overloaded currently, because we lack the necessary language to describe what's really going on in the US post-Citizen United.

One one hand, lobbying means interfacing with government leaders directly; engaging in face to face communication, and building relationships so that your interests are heard. No one thinks that's bad.

However, the US has taken many steps since well before Citizens United to build a kind of legal fiction which has made bribes legal, which is wrapped in the same language as what I'll call "ethical lobbying." As the OP points out, as long as on the record there are enough levels of separation between the politician and the person or organization giving the money, it's completely fine. The fact that the CEO and the politician are having lunch together is just a coincidence as they are definitely old buddies who have a shared mutual friend.

This problem has existed for a while in the US, but the Citizens United decision and the expense of running re-election campaigns has made it far, far worse.

I can't speak for others, but there's no anxiety in my dislike of "LLM-voice." The writing is terrible, overly dense, and often needlessly self-congratulatory or hedged. Many times it reads as if someone rewrote a perfectly good sentence with an unimportant preamble and adjectives pulled at random from a thesaurus which, I suppose, is kind of what happens.

Do any of the books you read on the topic stand out as something you'd recommend?

Not sure if I read this the same way you did. At least, this didn't read at all to me as "talking shit," but rather sharing their professional opinion on the (un)likely success of the project. Keeping thoughts to yourself isn't professional, it's avoidant. Especially when it has the chance to directly affect you.

I think that misses the point though. C trusts you to design your own linked list.

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

Zero technical debt certainly is... ambitious. Sure, if we knew _what_ to build the first time around this would be possible. From my experience, the majority of technical debt is sourced from product requirement changes coupled with tight deadlines. I think even the most ardent follower of Tiger Style is going to find this nigh impossible.

I think the difference here is that Penn and Teller are just as much historians of magic as they are magicians themselves. Accepting the honor is also accepting that the history is still relevant and worth celebrating. Making this into an ego thing misses the point a bit, I think.

More like that it's politically defined when the numbers become inconvenient.

My rule with Cursor is that unless I know exactly what I want it to do, I have it stay out of my way. If I have a general idea, I may turn on auto-complete. I reserve the agent for things like tests, UX, and rote programming that saves me time.

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.

I played the second game, and your dictionary might need to be adjusted. Asse is certainly not a word.

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 rather telling that you group substance abuse together with rather common and generally benign human conditions such as anxiety and neuroticism, and I find that your rather heavy-handed generalizations of people's capacity to help others based on their conditions and indeed their trauma dilutes your point.

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.

> Either way you are going to throw it all away once you have settled on what should be the final iteration anyhow.

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 find myself agreeing with much of your point, but I feel the need to nitpick a bit of your comment myself :)

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.

My take is that maybe we shouldn't paint all of SV with the same brush. Not every SV company is Philip Morris.

One of the things that's often not considered with these kind of interfaces, is whether or not they're actually possible. For instance, arg3 might only be true if arg1 is also true. Or arg3 may not be false if both arg1 and arg2 are also false.

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.