Before starting tasks, developers forecast that allowing AI will reduce completion time by 24%. After completing the study, developers estimate that allowing AI reduced completion time by 20%. Surprisingly, we find that allowing AI actually increases completion time by 19%--AI tooling slowed developers down.

The gap and miss is insane.

Enable squash commits. Each PR should be squashed to a single commit. This makes the master branch linear and simple. This ensures each individual commit on master has been reviewed and is in a working state.

In non-minimal changesets, I would miss information/documentation about individual logical changes that make up the changeset. Commit separation that is useful for review will also be useful for history.

I prefer a deliberate, rebase- and rewrite-heavy workflow with a semi-linear history. The linear history remains readable, while allowing sum-of-parts changesets/merges.

It's an investment, but I think it guides into good structuring and thoughts, and whenever you look at history, you have more than a squashed potential mess.

Squash-on-merge is simpler to implement and justify, of course. Certainly much better than "never rebase, never rewrite, always merge", which I am baffled some teams have no problem doing. The history tree quickly becomes unreadable.

Do you see downsides to learning it?

If you can, do it. It's common enough to be [potentially] useful. If you don't have a concrete need, then it's not necessary, though.

It's also on Steam (Early Access) with Very Positive rating (92 %).

let us resurrect the ancient art of Bittorrent

haha

This is the first time I have seen a Wikipedia weblink that sets a display theme via parameter.

Is this a subtle campaign for everyone to use vector? /s :P

Maybe all bunnies are actually snails with a fur coat on.

🏃‍♂️💨

The dash emoji. Always looks like a fart.

I like that even here on Lemmy, with inline code format, colors.ini is not being colored but color.ini is. Great symbolism for your issue.

It good

I wouldn’t do that, too much tunnel vision and biases.

Absolutely not. Self-reviews are very productive. I can confirm this from my own work and my colleagues, who also find it so.

You're of course free to vary the degree and depth of self-review, but tunnel vision and bias is definitely not overbearing and diminishing in those situations for us.

Someone else will of course see more, what you may not see due to tunnel vision. But that's besides the point.

I think it's convoluted way to describe it. Very technically-practical. I agree it's probably because of historical context.

The argument I read out of it is that using goto breaks you being able to read and follow the code logic/run-logic. Which I agree with.

Functions are similar jumps, but with the inclusion of a call stack, you can traverse and follow them.

I think we could add a goto stack / include goto jumps in the call stack though? It's not named though, so the stack is an index you only understand when you look at the code lines and match goto targets.

I disagree with unit tests replacing readability. Being able to read and follow code is central to maintainability, to readability and debug-ability. Those are still central to development and maintenance even if you make use of unit tests.