HaraldvonBlauzahn

HaraldvonBlauzahn @feddit.org 2mo ago

The best solution could be to install Windows in a VM. Dual booting can be very annoying if you need to access the same files from both systems. Especially since Windows does not power down, but hibernates by default, and it is not safe to access file systems loaded into a system that is not properly powered down - this will lead to file system corruption.

1

HaraldvonBlauzahn @feddit.org 2mo ago

This matches all too well with what Baldur Bjarnason writes in "The Intelligence Illusion".

HaraldvonBlauzahn @feddit.org 2mo ago

You are welcome!

9

HaraldvonBlauzahn @feddit.org 2mo ago

What is puzzling to me is there seem to be no companies which take a deliberate, measured, experimental approach.

No "You can use that but you have to report on difficulties or disadvantages".

No "you can use it but not when correctness is critical, errors could harm people, or it can directly affect things critical for our business".

No "Give us first an estimate in how long it will take, and then we will roll a dice, decide if it will be done using AI, and after 50 tries we will compare whether it makes a difference".

No "You can use AI, but you are responsible that the result works and is correct, no slack on this, and failure to do so gives you minus points".

No "You can use it, your max token budget is 100 USD per month".

No "You can use it, but do not input any company secrets, confidential data, medical records, or things like passwords and security-relevant data".

There seems to be zero risk management.

Imagine pesticides, radioactive substances, or highly toxic chemicals would have been introduced in such a manner.

See also this book chapter by Baldur Bjarnason.

2

HaraldvonBlauzahn @feddit.org 2mo ago

I think not yet. I was using magit in Emacs, but switched from git+magit mostly to jj+cli . What I would find useful is a patched-up gitk.

2

HaraldvonBlauzahn @feddit.org 2mo ago

Assuming we are not talking about rewriting published history – and nobody should ever really be doing that anyway, when multiple commiters are using the same branch – I presume this is a situation where the dev has multiple, unpushed features that are WIP, each in their own local branch and building on each other.

Yep. There are also situations where rewriting history on branches under review is ok and desired - systems like gerrit work that way. But not github (you can push to an own work-in-progress branch on github, or even push to a branch with a merge request, but the github ui is not designed to review that).

Especially large organizations favour history that is easier to read and mostly linear. This is not needed for a mom and pop web project of a company with three developers.

In respect to the number of commits per feature - one commit per feature can be good. But often changes can be compartmentalized in doing preparatory refactoring, adding the feature, adding tests, and his can be easier to review because the scope of each commit is smaller.

HaraldvonBlauzahn @feddit.org 2mo ago

This is about AI mania in coporate environments.

I posted this because it describes some unfortunate dynamics and also has, in the last section, suggestions to programmers which are affected by AI mandates, or tasked with fixing huge amounts of slop code.

HaraldvonBlauzahn @feddit.org 2mo ago

Both is the same. The only difference might be who is holding the bag in the end.

3

HaraldvonBlauzahn @feddit.org 2mo ago

What would be consequences of a crash?

One thing I'm thinking is that a crash would likely lead to higher interest rates for everything.... but fossil energy is also highly capital-intensive, too, and runs only on cheap borrowed money, too, therefore..... wait it is hard to grasp how that could turn out.

Anyone has tips for potato gardening?

HaraldvonBlauzahn @feddit.org 2mo ago

For beginners (which are not the target audience of the above blog post), I recommend Beej's Guide to git. (But, perhaps learn some jujutsu before - it might make a few core concepts clearer).

HaraldvonBlauzahn @feddit.org 2mo ago

true.

HaraldvonBlauzahn @feddit.org 2mo ago

I have not heard of the technical bankruptcy metaphor.

He also describes the analogon to financial restructuring of debt (giving up some products or features because you can't support them any more) and the massive costs in terms of trust that bankruptcy has as a consequence.

2

HaraldvonBlauzahn @feddit.org 2mo ago

The entire software industry will have a reckoning soon. AI maybe sped up its arrival but I don’t think sustainable business practices have been in vogue in silicon valley for decades.

That could be the case.

There is also the situation with tons of AI filtered CVEs. In theory, the EU cyber resilency directive should address that .... but it is not possible to address literally decades of technical debt with processes that only optimized for short-term revenue. Might turn out that some smart home technology was not so smart, and smart factory tech neither.

3

HaraldvonBlauzahn @feddit.org 2mo ago

I think at the lowest level, it is very similar.

But with a bit more abstraction, Rust is somewhat less verbose, especially when the same efficiency is required. Thinking im iterators / loops or generics, or enumerations / sum types. Also, the module system, build system, integrated unit tests, and compiler messages are huge gains for productivity.

1

HaraldvonBlauzahn @feddit.org 2mo ago

I still understand the argument of the C greybeard to Rust knowledge gap though.

The patterns that Rust enforces are usually good practice in concurrent C programs, too. Of course, there are things that you can express in C which Safe Rust would not allow - but the same is true for Assembly language. And this alone is little reason to use Assembly.

5

HaraldvonBlauzahn @feddit.org 2mo ago

Brilliant and nuanced description.

It also makes me pause when thinking about AI. AI-generated code, as it is commercially used, undoubtly increases technical debt. Companies want to use it because they see it as an advantage. But it can also lead quickly to technical debt bankruptcy. Which will likely be the outcome given the bone-headed way how many companies actually use AI.

But what drives them?

A lot of AI adoption seems to be driven by two things: Fear and greed. Fear, of becoming obsolete among the competition. Greed to not miss out on a perceived bonanza. This is not necessarily rational. It might be the cause why all these purported gains in speed are rarely actually measured.

But as Apenwarr (Avery Pennarun) points out, companies often behave more rational than it seems. Specifically, as he writes, they accept an unsustainable level of technical debt when it seems that they cannot compete any more. That makes actually sense: Why polishing a shiny, immacculate, well-designed code base, when you never have the chance to re-earn the money that you did spent for that? (People do the same: An aging person living in a run-down house with broken roof and heating might not want to invest in repairs or installing a heat pump, because that person will not see the gains from this investment - possibly their children, but will they keep the house?).

But how does all this match up with technical debt and AI? Are tech companies simply giving up business? Are they completely unaware on the level of technical debt it creates? Why does this happen?