There is Only Code

1 Oct

There is just Code. It is either Shiny or it is not.

‘Legacy Code’ is another term, along with Technical Debt, that I would rather we in the software development community would retire. In a recent conversation the following possible definitions of Legacy Code were tossed out:

Legacy code is valuable code that we are afraid to change

Code I wrote yesterday is “legacy”

The code I wrote a minute ago and checked in is legacy

The comment I threw into the mix was:

There is just Code. It is either Shiny or it is not. If not, either throw it away or polish it.

Some of the conversation went around classifying it based on whether it needed to change:

I liken that to the junk drawer. You keep throwing stuff in it. It will hold it all. It only matters when you need something from it.

Whether the code was written last year or earlier this morning, if it is providing the value it needs to provide there is little need to bother with it. If there is a need to mess with it, either to add new functionality or to repair something not-quite-right, it does not matter whether it was written a decade ago or a minute ago. In either case, when you look at that code with a new view, you will see possible places to add some shine or throw out some cruft.

A question was raised as to whether these classifications only matter “when you need something from it.”

Some analogies to ‘junk drawers’ and ‘silver dishes’ were brought into the conversation. The junk drawer as a place where odd bits are tossed and which you only care about its ability to hold the odd bits until you need something from it. The silver dishes as a lovely collection of items that are fine on the shelf until they must be put into service. For both, there is probably a good argument that there is some value in cleaning them up occasionally even when you have no specific use for them. 

So, perhaps there is more than “need something from them” needed for the definition.

Or, perhaps, it is just all code. Code that you polish when you are actively updating it and that you frequently sweep through to remove cruft and cobwebs. 

Strong Opinion on git Workflow

7 Feb

Strong Opinion

Whether working in trunk-based style or feature-branch style, the main (or trunk, also known as master) branch, along with any release branches if doing that thing, SHOULD NOT have merge-commits.


I do not like to see merge commits in the main/trunk branch. I prefer a straight, unblemished history line.

* d589966 -(17 hours ago) (HEAD->main, origin/main,origin/HEAD)
* 5f3c420 -(17 hours ago) Merge branch ‘main’
| * 4650c10 -(17 hours ago)
| * ae51497 -(17 hours ago)
| * b45fa11 -(18 hours ago)
* | d532336 -(17 hours ago)
* 3d7bb50 -(18 hours ago)
* 6851949 -(18 hours ago)
* 28a191b -(19 hours ago)
* 01f6be2 -(19 hours ago)

Merge commits make reviewing the history more difficult for humans and source control tools to understand, explore, and resolve issues. Other than the visual part, they introduce complexities to reverting any issues that come up which cross the merge-commit line.


I have these settings in my global .gitconfig to fail any merges that are not fast-forward. This forces me to resolve those with a proper rebase before merging into main.

    ff = only
    ff = only


The workflow I use to resolve such problems is:

  • Create a branch at the current state git branch wip
  • Reset the main branch upstream head either by resetting it then pulling or fetching then resetting it.
  • Change to the wip branch git checkout wip
  • Rebase wip onto main get rebase main (resolve any merge conflicts the usual way)
  • Change to the main branch git checkout main
  • Merge the wip branch into main (since it will fast forward now) git merge wip
  • Delete the wip branch git branch -d wip

As with anything that I do more than a couple of times, I have automated this workflow. The scripts below are in the set that I source into my current terminal. When I git pull and it fails because it cannot fast forward (see the .gitconfig settings above), I can just repo_wip_rebase.

The script stops at the rebase step if there are merge conflicts to resolve. I use the normal git mergetool and get rebase --continue to handle those and then repo_wip_merge to finish up.

Note that when there are no merge conflicts, repo_wip_rebase does all the work.

function repo_wip_merge()
    git checkout main || return $?
    git merge –ff-only wip || return $?
    git branch -d wip || return $?

function repo_wip_rebase()
    git branch wip || return $?
    git reset –hard origin/main || return $?
    git checkout wip || return $?
    git rebase main || return $?
    # if there are merge conflicts, it stops here. Resolve them and then do this separately

It is possible to do this as get aliases instead so that the commands might be: git wip_rebase.

I tend not to create git aliases for two reasons. The most important is to keep custom stuff clearly custom. I do not want to get in the habit of using git xx short cuts and erode my memory of the raw git commands. Having scripts with the prefix repo_ makes it clear to my brain that this is a custom thing. The second reason is that having these in a script separate from my home folder that is under source control is easier for me to manage.


I know there are other options for both of these. This is what works for me.

I hold no strong opinions on how you should automate your work. I only hold that you should automate as much as you can in whatever way works for you.

Set Up New Mac

18 Dec

I got a new Mac to go with the new job. Here’s rough notes on what I did to set it up.

Open the box and plug it in.

Get it booted.

Create a new apple id for the new job along the way. Get annoyed at Apple for not allowing a letter to be used more than 2 times in a row e.g. a password with ‘AAA’ anywhere in it is not allowed. Just let me use whatever password I want.

Upgrade the OS

Update the OS from Catalina to Big Sur.

Configure Some Things

  • Make the touchpad NOT click on finger taps
  • Get my standard set of images for the screen saver and set it up to show them
  • Put the power saver settings the way I like them

Install All the Things


Install Chrome and set it as the default browser. Don’t @ me. This is the browser I use because it is the browser I use. I am not interested in browser wars.)

Create two user profiles in Chrome. One for work using the work email and one for personal using the personal email. This makes it easier to keep things with things while still making it not-too-bad to get at all my common tools using the chrome-synced manus, toolbars, and settings.

Password manager

Install my favored password manager because remembering passwords is hard work that no human should do.


Install VSCode. Install the key extensions.

  • EditorConfig
  • C/C++
  • CMake Tools
  • Docker

Realised I did not have all the extensions I expected on my personal machine. There are many that I used on my old work machine that are not yet there either. Awesome. Let’s guess what they are and install some of them on both machines.

  • Python
  • shellcheck (this will need some other things installed below)

That’ll get the most likely ones. Others can be installed as I go along.

Configure VSCode to allow code on the command line to open files.


Install ITerm2 and make its configuration match what’s on my personal machine.

Set Shell

Recall as some point that the newer MacOS versions default to zsh. Nothing against it, but I am sticking with bash.

Big Sur still has bash in the /etc/shells so I just need to change the default shell

chsh -s /bin/bash

I will have to change this when I install the newer version of bash below.


Putting this here even though I actually did it after brew install pyenv because I realized I would need the command line tools pretty soon.

Use the App store to install XCode. Which required setting up the App store with the new Apple ID.

Start XCode to click all the agree buttons.

This version of XCode installed the command line tools by default so xcode-select --install did not have to do anything.

(Carry on with the Brew installs…)


Install homebrew.

brew install all the things I use on my personal machine that look to be useful on the work machine.

brew list to get the list the cut it down to likely things
These are the important ones. These will get installed and configured now.

brew install magic-wormhole

Wonderful tool for moving things securely from one machine to another

brew install pyenv

(stop here uninstall it and go back two steps to install XCode and then the command line tools)

use pyenv to install the most recent python (3.9.0 now) and set it as the global python

pyenv install 3.9.0

This failed with an ugly python error. After consulting the googles I found this that worked:

LDFLAGS="-L$(xcrun --show-sdk-path)/usr/lib" pyenv install 3.9.0 
pyenv global 3.9.0 

brew install bash

Big Sur comes with bash 3.2 installed. I want something at >= 4.x. The personal machine has 5.0. After the install add the new bash to the /etc/shells file and set it with chsh -s /usr/local/bin/bash

brew tap homebrew/cask-fonts
brew install --cask font-fira-code

I like ligatures in editors. This is the font for that. Install the package then configure VSCode to use it and update settings for fonts

Font Family: Fira Code

To enable ligatures, add this to the settings.json "editor.fontLigatures": true,

brew install git

Cannot live on a computer without it

brew install hub

hub makes working with Github nicer from the command line

brew install git-crypt

Which I use to encrypt secrets on some of my repositories

brew install shellcheck

shellcheck is a lint tool for bash scripts. I very much like running lint and other static checks on code I write in any language. shellcheck has proved itself in both catching subtle errors in my bash scripts as well as teaching me better ways to write bash. This package needs to be installed so the shellcheck extension of VSCode will work, which is where I use it most of the time. It also has a command line which lets it be added to build scripts. I highly recommend using it.

There are some others that I will install later or as I find I need them:

  • ccache
  • gcc
  • ninja
  • xz
  • cmake
  • gdbm
  • jq
  • kdiff3

Dot Files

I have a repo full of dot files to bootstrap a bunch of configurations. I’ll get that down and put them where they belong.

Create a ~/projects/ folder, because that’s what I do.

Clone the dotfile repository.

Which requires telling GitHub about my new machine. Which means creating a new ssh key and putting it in all the places.

mkdir ~/.sshcd ~/.sshssh-keygen -t ed25519 -C ""
eval "$(ssh-agent -s)"
# update the ~/.ssh/config file with a Host 
blockssh-add -K ~/.ssh/id_ed25519
# add the key to Github
git clone <dotfiles repo>`

From the dot files:

  • Copy the ssh config parts that a generic into the ~/.ssh/config file.
  • Copy The bash files that are useful. There might be bits in these that don’t apply yet because something is not install, but it should be harmless to have it there early.
  • .bash_profile
  • .bashrc
  • Copy all of the git config files that are useful (some are specific to old git repositories that are no longer needed)
  • Copy all the other dotfiles that are there (vim, input, kdiff)

There are also some VSCode settings files cached here, but I will look at those and probably manually echo the settings instead of risking copying them blindly.

Utility Scripts

I have a big pile of utility scripts, mostly in bash, in a git repository. Clone that repository down.

Sundry Tools

Rogue Amoeba Tools

  • Loopback
  • Hijack
  • SoundSource

I have found these to be very useful for managing sound and sound-devices on the Mac.

Enough for Today

That gets the machine into basic working shape. That took about 4 hours.

Still left to do are things like

  • get gcc installed (so I can keep working on my Advent of Code)
  • get java installed (i’ll probably wait to make sure I get the one needed for the client gig)
  • getting the desktop apps for some of the office tools (outlook, miro, etc.)

I’ll write about those if anything special happens during the installs.