array(1) { ["header_image"]=> string(60) "https://mayden.academy/wp-content/uploads/2018/11/colis1.jpg" }

How can Freud’s philosophy of Ancient Rome and memory help developers to improve their use of Git? Mayden Academy developer-in-training Oliver investigates.

“Now let us make the fantastic assumption that Rome is not a place where people live but a physical entity with a similarly long, rich past, in which nothing that ever took shape has passed away and in which all previous phases of development exist beside the most recent”

Sigmund Freud, Civilisation and its Discontents

What have the Romans ever done for us?

Freud famously talked of Rome as a metaphor for the human memory.

The old buildings of Ancient Rome held nostalgia and history, and were occupied by both the great and the lowly. Set upon the crumbling structures of the past, new buildings would tower up whilst interplaying with the historic foundations below. Occasionally an old building would be restored for modern use, or a building of significant heritage would be renovated to retain its part in the historic flow of the city.

Old and new memories

Our minds are very similar. Older memories can be blurred, the brickwork crumbling and edges softening. Occasionally we refurbish the building; we imbue it with some new materials, or we are reminded of facts that restore its former glory. Amongst these older rubbled memories, we have the new, clear buildings of thought that emerge between and amongst the old, offering a scene that allows old and new to complement each other.

Git, as a version control system, can also be used as a metaphor for Rome and/or memory. Each commit we make is like a new building. Each branch we create is a new base or plan for what is to come. What is finally held in the master branch may well be, like the city of Rome, an entity that lasts for far longer than we do in an organisation. Some code bases may well even exceed our own lives.

Mayden Academy, as an industry focused development course, prioritises teaching us the tools which we need to progress and succeed as junior developers in the workplace. Git and GitHub are central to this requisite knowledge. They offer a system that will underpin much of our work in our future careers.

Git outta town

GitHub is a tool which many new coders, myself included, struggle with. There are dangers; taking shortcuts on the command line may change the status of entire codebases. Worse, you can lose entire blocks of code in the depths of tangled Git branches, never to be found again. Then there is the added time required to use Git effectively. With that in mind, it is easy to perceive it as a necessary evil, instead of something that is practical and useful for us as developers.

But since relating GitHub to Freud’s view of Ancient Rome, I have started to see it in a different light.

Code base as foundation

Using Git and adhering to detailed and clear committing structures prevents loss of data, and can also help us to code in an effective manner.  

It keeps the ‘City’, our code base, in one readable store from the foundations up, mapping any new improvements and structures. It allows us to look back in time to see how something was created. We can improve and update. We can connect and disconnect structures. We can even entirely replace. Used correctly, within Git is every small change of a build.

It is in these small changes that I have found Git most revolutionary to the way I am actually coding, in real time.

Signposting your code

Each time we commit to GitHub we leave a message, a signal to those who might review or develop on top of the buildings we have previously constructed. These architectural plans make it easier for those who follow our code to develop alongside us and after us. The way in which we commit, and the size of each commit, can make a huge difference to the continuing life span of our code.

For many people starting out with coding this can seem like an unnecessary stress when there is already so much to learn. It is tempting to skip the process. But by committing regularly and with description, our coding will prosper.

By making smaller commits, with describable added features, and by doing our best to follow the mantra of separations of concern, Git actually focuses our coding. Developing discreet and working small parts of code, paralleling the agile system, helps to focus a developer on the task they are completing.

The key is to work with small, easily testable steps that create one large body of work. The blocks that make up a building, the buildings that make up a city.

Coding in chunks

Part of what I have found working with other new coders is that when we encounter a problem, we often end up reviewing the whole system to find the bug. We are effectively searching the whole city of Rome, old and new, to find a single error. It is a massive task.

But by coding in small chunks, and by committing working code often, we signal where the errors in our code might be. Furthermore, with each tiny piece of additional code comes the possibility of reuse, contributing to time-savings later down the line. We are also able to go back in time and see where we found our issues, which can feed into future decision-making.

Git as a coding philosophy

When renovating the Sistine Chapel in Rome in 1979, every single stage of the restoration was recorded in detail with photographs, starting with Michelangelo’s lunettes. This meant they could continue to use the same methodology on each new section being restored. This code, these small commits of restoration, were reused and referred to consistently. The success of the method set a precedence for future restorations.

I hope that we all begin to think of Git as the same kind of tool. By coding with Git in mind, all discreet and simple additions to our code give us a schema for our future code. Not only a version control system, but an entire coding philosophy.