That bubble also funds giant amounts of commercial disinformation around ai, which is doing a lot of damage. You simply do not want such error-prone systems manage patient health data and such.

See the linked Wikipedia article. The value is defined as the estimated hypothetical costs to re-create it, and these costs would be salaries. There exist estimation models for the value of large Software systems, which are e.g. used in company takeovers and mergers. And of course, that’s hypothetical, the Linux kernel is not for sale.

A really beautiful and touching story!

I think we owe these inventors and engineers who created our electricity system so much.

Their effort are today more important than ever, much more than they would have dreamed of. Consider this: Humanity is in a race for survival, a race to escape climate change. With 3 or 4 K of warming, civilization cannot survive. If we make it, electrical infrastructure will be a big part of the solution.

If you ever have grand-grand-grandchildren, five generations from now, they will likely be alive to a big part because of their efforts.

Thank you!

Yeah! But don’t forget to use Dvorak layout when typing this incantation … don’t let your productivity be hampered by stuck fingers ;->

edit: Or perhaps use these voice input systems to whisper your code directly into the AI’s transistors.

It largely depends on at what price you sell your soul.

It seems a lot of words that say exactly nothing.

I don’t know if the last part “What do these software developers actually do all day? ;->” is ironique or not.

It is actually a mix of two things:

1. Ironic about the idea of what AI companies promote - and many managers in tech believe - that you can speed up the work of developers by speeding up code generation. The fact that typing in code costs way less than 0.1% of developers work time shows that the time to type in code is /not/ the bottleneck.

2. Interested in what it is actually that costs time. I think most time I work on larger projects is reading code and trying to understand how different parts are related, what invariants it has, etc. It is actually a form of /learning/ because it uses material to build a useful long-term collection of related concepts in my brain.

Anything that’d help us to do and understand the second part better would be extremely useful for this work. I think that literate programming, also tools that can transparently put code into a form of interconnected hypertext (like the LEO editor), inline doc tests and so on, are helpful for that.

Personally, I also think that wikis like gollum are powerful tools for that kind of learning, but not many people seem to agree with this (except the fossil and forejo authors).

(It’s a whole story, I don’t remember exactly)

I’d be delighted to read it!

That will be a greater number, by the way: say the kernel is 100 lines, somebody may have written 50, but they may have all been replaced by future patches, so The number of lines written is greater than the number of existing lines.

Some parts are rewritten, but most of the kernel code is actually in device drivers which usually do not need to be re-written.

Is that salary estimate also from 2011?

I got 60K as a mid-level C++ developer in industry in 2009.

THANKS!

Well, show me any job ads that tell this.

Or is this somehow hidden in some kind of cat whistle?

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.

You are welcome!

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.

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.

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.

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.

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).

true.