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.

[delayed]

> Is it bad for [...] people to have too much money or not?

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?

I'm quite happy it didn't keep going, though not for lack of trying.

I'm excited about the title, but I have to say that my initial impression has left me frustrated. The main README on GitHub[1] smells of corporate-speak. So far I've learned that:

- 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

* * *

It depends on the state of the market. During the banking crisis, 157 banks were closed in one year[1].

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

I think that these kind of reviews can potentially be squashed by building consensus around what kind of feedback is right for PRs, what conventions you agree upon using, etc. Far too often, these kind of "best practices" only exist in the senior's head (if they're even truly best practices at all), so it becomes a very frustrating moving target for a junior.

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.

I would argue that this too is part of software development. You ought to have a robust process that can accommodate hotfixes while minimally impacting ongoing work. That fix requires you to get buy-in from all of the right stakeholders, and the deployment requires you to follow the same processes as the development team.

I'm not sure if I see the value in making such distinctions though.

> But breaking down tasks provides (1) some certainty that you know a thing is achievable, (2) gives you a strong idea of what can be started immediately, and what can be run in parallel, and (3) hidden dependencies on other teams. This in turn leads to a better estimation.

I very much agree. I think the key in the OP article is "to the smallest details." In order to truly know how to build something, you need to build it in the first place. Worse, you'll end up with a load of outdated documentation that will either be abandoned, or take up more developer time to update when it inevitably conflicts with what's produced.

I tend to stop planning once I hit some "unknown horizon," meaning that any further planning is more or less built on well-intentioned speculation, or is bikeshedding at best. Past that, and I think you end up creating more problems for yourself.

I've been using act[1] as a tool to develop/test actions locally, which has helped a lot for creating new actions and debugging existing ones without incurring additional build costs.

There does appear to be some solutions on the marketplace that will allow you to ssh into a runner, but I haven't had a need for them as of yet.

[1] https://github.com/nektos/act

Github Actions supports heavy parallelization and fan-in/fan-out jobs just like CircleCI does, so I'm curious if there's some limitations that I haven't ran into yet. I'd go farther to say that their documentation is much richer and easier to search for.

From a development perspective, Stripe is by far the fastest/easiest to integrate with, the most featureful, and has the best documentation. As I understand it, other payment providers will often require underwriting up front before you can even begin, which can take a while.

I'm no expert here, but I wonder about the economics around the 13MW of heat that it outputs. There are certainly applications around the world where that could be hugely beneficial. Take Reykjavik[1] for example. How much are they paying for their system now on a yearly basis? How would they like an extra 5MW of energy along with it?

[1] https://vahterus.com/resources/cases/10-mw-heat-pump-system-...

I don't think that this is always possible. For one, I've yet to meet anyone who can meaningfully predict:

a. What features are going to be added over the course of your application b. What features are going to be popular c. How these features scale, independently of the overall application

Architecting for reasonable performance should always be a goal. Architecting for scalability, however, is often wishful thinking that from my experiences has lead to more harm than good.

I agree with this, mostly. I've worked at many a company where I've inherited the work of developers who built towards an expected view of the future. That expected future, of course, never quite lined up with the future that did come to pass. So a lot of extra work building out the wrong abstraction lead to a lot more work to undo it.

I would disagree with you only that I'm not familiar with a time when premature monitoring was added that caused me a lot of pain. If anything, the opposite has been true. Can you explain what you mean there?