Programming

What keeps the software alive are the programmers who have an accurate mental model (theory) of how it is built and works. That mental model can only be learned by having worked on the project while it grew or by working alongside somebody who did, who can help you absorb the theory. Replace enough of the programmers, and their mental models become disconnected from the reality of the code, and the code dies. That dead code can only be replaced by new code that has been ‘grown’ by the current programmers.

Training data are construction materials for a language models. A language model can never be inspired. It is itself a cultural artefact derived from other cultural artefacts.

The machine learning process is loosely based on decades-old grossly simplified models of how brains work.

[…]

It’s important to remember this so that we don’t fall for marketing claims that constantly imply that these tools are fully functioning assistants.

[…]

Who was the first man on the moon?

[…]

What you’re likely to get back from that prompt would be something like:

On July 20, 1969, Neil Armstrong became the first human to step on the moon.

This is NASA’s own phrasing. Most answers on the web are likely to be variations on this, so the answer from a language model is likely to be so too.

[…]

The prompt we provided is strongly associated in the training data set with other sentences that are all variations of NASA’s phrasing of the answer. The model won’t answer with just “Neil Armstrong” because it isn’t actually answering the question, it’s responding with the text that correlates with the question. It doesn’t “know” anything.

A core aspect of the theory-building model of software development is code that developers don’t understand is a liability. It means your mental model of the software is inaccurate which will lead you to create bugs as you modify it or add other components that interact with pieces you don’t understand.

Language model tools for software development are specifically designed to create large volumes of code that the programmer doesn’t understand. They are liability engines for all but the most experienced developer. You can’t solve this problem by having the “AI” understand the codebase and how its various components interact with each other because a language model isn’t a mind. It can’t have a mental model of anything. It only works through correlation.

I recently had to commit a bunch of stuff I’d been working on in a logical sequence, but forgot to include a crucial bit of code until I’d already done a bunch of the commits. I didn’t want to have to redo all of them just to add the missing code, but I also didn’t want to end up with a commit sequence that wouldn’t work if checked out at a point before the missing code. This is where Git saved my ass. While I use TortoiseGit rather than the commandline, the concepts are the same:

Turns out to be quite simple, the answer found here. Suppose you’re on a branch branch. Perform these steps:

• create a temporary branch from the commit after you want to insert the new commit (in this case commit A):

  git checkout -b temp A
  

• perform the changes and commit them, creating a the commit, let’s call it N:

  git commit -a -m "Message"
  

  (or git add followed by git commit)

• rebase the commits you want to have after the new commit (in this case commits B and C) onto the new commit:

  git rebase temp branch
  

^{(possibly you need to use -p to preserve merges, if there were any - thanks to a no longer existing comment by ciekawy)}

• delete the temporary branch:

  git branch -d temp
  

After this, the history looks as follows:

A -- N -- B -- C

It is of course possible that some conflicts will appear while rebasing.

In case your branch is not local-only this will introduce rewriting history, so might cause serious problems.

This excellent video by Physics Girl breaks down some of the misconceptions about what we programmers actually do and why we do what we do, with a focus on women and femme people in the field. I could relate especially to the discussion about it being very much about enjoying problem solving.