Yeah, I can imagine it being annoying that sqashing in that case wipes the author attribution, when not everybody is doing PRs against the main branch.

However, calling all squash-merge workflows "stupid" without any nuance.. well that's "stupid" :)

The ecological win definitely looks nice on paper, but whenever people talk about compost the carbon footprint / gas emissions is always at the front of people's minds, and I don't really see that discussed in the article.

The article does say

> Especially since, in addition to the double-win of dealing with waste and revitalising barren landscapes, richer woodlands also sequester greater amounts of carbon from the atmosphere – meaning little plots of regenerated land like this could ultimately help save the planet.

How long will it take for it to cross the CO2-neutral mark? Maybe a silly question, definitely not my area of expertese.

I don't necessarily interpret the comment you replied to as saying that "taste is not important", which seems like what you are replying to, just that it's not the only remaining thing.

I agree that taste gets you far. And I agree with all the examples of good taste that you brought up.

But even with impeccable taste, you still need to learn, try things, have ideas, change your mind etc.. putting all of that in the bucket of "taste" is stretching it..

However, having good taste when putting in the effort, gets your further than with effort alone. In fact, effort alone gets you nowhere, and taste alone gets you nowhere. Once you marry the two you get somewhere.

you seem pretty convinced that intelligence plays an important role in natural selection. I'd argue that decisiveness, confidence, looks, social skills all play a more important role. (I'm not saying that's a good thing)

I'm interested in understanding your point of view, can you elaborate on what you mean by "There is no joke in that"?

edit: nm, rtfm, it was on the landing page: Horizon Europe programme

the upside this is a great opportunity to do an early bed time

But it's weird to me to call this a "ratchet", and not just a custom lint rule. Since it sounds exactly like a lint rule.

The hard-coded count also sounds a bit like something that I would find annoying to maintain in the long run and it might be hard to get a feeling for whether or not the needle is moving in the right direction. - esp. when the count goes down and up in a few different places so the number stays the same.. you end up in a situtation where you're not entirely sure if the count goes up or down.

A different approach to that is to have your ratchet/lint-script that detects these "bad functions" write the file location and/or count to a "ratchets" file and keep that file in version control.

In CI if the rachet has changes, you can't merge because the tree is dirty, and you'd have to run it yourself and commit it locally, and the codeowner of the rachet file would have to approve.

at least that would be a slightly nicer approach that maintaining some hard-coded opaque count.

Though, I generally run these scripts using bun (and the corresponding `$` in bun) - basically the same thing, but I just prefer bun over deno

The biggest differentiator of design thinking is really addressing the XY problem. In 95% of cases clients will come to you to design their solution. Ie they already think they have a solution to their problem and now they want it to look good.

Design thinking is basically more like root cause analysis, or the 5 why's.. and an emphasis on taking to end users (the people with the problem) without having a solution.

Once you understand the problem more fundamentally is only when you start cooking up with a solution.

And the result of that process might not even be a traditional design, but perhaps just a tweak to something, like moving your onboarding to later in the ca process..

In practice however.. 95% of designers who say they practice design thinking disregard this, and just want to design wherever the client asks for

> They are bad at deciding requirements by themselves.

What do you mean by requirements here? In my experience the frontier models today are pretty good at figuring out requirements, even when you don't explicitly state them.

> They are bad at original research

Sure, I don't have any experience with that, so I'll trust you on that.

> for example developing a new algorithm.

This is just not correct. I used to think so, but I was trying to come up with a pretty complicated pattern matching, multi-dimensional algorithm (I can't go into the details) - it was something that I could figure out on my own, and was half way through it, but decided to write up a description of it and feed it to gemini 2.5 pro a couple of months ago, and I was stunned.

It came up with a really clever approach and something I had previously been convinced the models weren't very good at it.

In hindsight, since they are getting so good at math in general, there's probably some overlap, but you should revisit your views on this.

--

Your 'bad at' list is missing a few things though:

- Calculations (they can come up with how to calculate or write a program to calculate from given data, but they are not good at calculating in their responses)

- Even though the frontier models are multi-modal, they are still bad at visualizing html/css - or interpreting what it would look like

- Same goes for visualizing/figuring out visual errors in graphics programming such as games programming or 3d modeling (z-index issues, orientation etc)

In practice, that is not really viable and should not be a motivating factor when choosing technologies.

Also:

> Exploitation of this vulnerability requires an attacker to first gain authenticated access to your Redis instance.

Yes, everybody would love it if every PR was small enough. In reality that is not a good way to build substantial features.

Often, fully building out a substantial feature, causes you to change your mind and completely changing your approach the further along you are. You don't want to be muddying up the PR pipeline with a bunch of half-assed changes.

Doing that just makes reviewers less inclined to give good feedback on a PR, because they "know it's going to change so much anyways".

If you are building a substantial feature, it is reasonable that the PR is large and reviewers will have to dedicate substantial time to reviewing it. Reviewing it is work on its own and hopefully your engineers have dedicated time to review substantial features.

Of course, you should make sure your substantial feature is as minimal as possible, for whatever is needed to ship the feaure - but not any less than that.

I think a big part of the negative sentiment derives from the fact that detailed documentation and reference documentation almost non-existant. The documentation mostly tells you what exists, but not how to use them, how they get executed, common pitfalls and gotchas etc etc.

The documentation is written to be easy and friendly to newcomers, but is really missing the details and nuances of whatever execution context a given api is in and does not touch on derived complexities of using react in a server environment etc.

This is a trend across a lot of projects these days - often missing all the nuances and details - writing good documentation is really hard. Finding the balance between making things user friendly and detailed is hard.

Keep it up