Monument Monitor; an overview halfway through

Last October I made the alarming decision to turn my back on the world of tech, and the very enjoyable life of a software developer, and scuttled back to academia to pursue a PhD.

It was a decision I did not take lightly. I know many people who are completing/completed a PhD and the vast majority faced incredible challenges which affected both their mental health and general wellbeing. Several didn’t enjoy the process at all and some completely regretted the decision to start one in the first place. It was with their dire warnings ringing in my ears that I agreed to join the SEAHA CDT 2018 cohort, signing up for a 3 year PhD, and expect to finish after my 30th birthday in 2021. That’s right, I will still be a student when I am 30.

What’s SEAHA? What’s a CDT?

SEAHA stands for ‘science and engineering in arts, heritage and archeology’ – essentially all the things that I’m interested in rolled into one research group. CDT stands for ‘centre for doctoral training’. In order to secure large amounts of funding for research projects, universities now often club together to provide better and wider support for PhD students. SEAHA is made up of people/departments from UCL, which focuses on chemistry and imaging; Oxford, which focuses on archaeology/geography and Brighton, which has a focus on computer science.

So what are you doing?

My research area follows on from the MRes I completed in 2017, in which I attempted to establish to whether we could monitor remote heritage sites, using visitor photographs. Large heritage organisations such English Heritage and Historic Environment Scotland look after hundreds of sites over the country, but cannot be at every site all the time. It seems logical therefore to utilise tourists, who frequently visit heritage sites and use their images to get an idea of what happens around historic monuments when conservators are not there. Around 70% of us visited a heritage site in 2018, that’s a lot of untapped data potential.

During my masters I looked at wether measurements taken from a variety of smartphones were reliable enough to measure colour. In short the answer was ‘yes, sort of – if you have enough images to mitigate margins of error introduced by uncalibrated images’. This lead to some pretty cool graphs and resulted in this paper:

Alongside this work I set up two small pilots at Machrie Moor on the Isle of Arran and at Holyrood House Palace to try and collect images to monitor groundwater levels and vegetation growth respectively.

The publication and the success of the pilot project led to my current PhD research, with the Monument Monitor project being scaled up across 20 sites around Scotland. You can find out more about it on the website here or this blog.

So, halfway through – how are things going?

Overall, really well, I could go into minute details about every aspect of my research life, but for brevity I will break it down into the ‘Good’ and ‘Not so good’


Working with heritage – I bloomin love history, always have always will, and now I get to visit them for work.

Working with tech – My skills as a software dev have been indispensable to this project, being able to write data analyst scripts, throw together a quick website or interact with APIs is immensely useful when creating a Citizen Science project from scratch.

Managing my own project – I always said I would either do a PhD or create a startup, just as soon as I could think of the right one. With Monument Monitor I feel like I have hit both these goals.

Solo working – Whilst I am based at UCL, I live in Bristol and rent a co-working space, which gives me a professional space to work in away from both my bedroom, smelly ol’ London and the nastier side of academia. I highly recommend this for any PhD student that can manage it!

Ease of explanation – By it’s nature, a PhD is an incredibly niche thing and a nightmare to explain to PhD-muggles. The concepts behind my research are really easy to convey, which is really nice. This may seem like a silly thing, but being able to get others engaged in what you spend nearly all your energy thinking about is really nice

Me at the northernmost case study site, Ness of Burgi, in Shetland

Not so good

Time Management – Whilst managing my own time is great, strict discipline is sometimes challenging in nice weather!

A continual fear of failiure – I think this is a shadow that follows most of us around, not just postgrad students. The constant assumption that my work is either ‘not enough’ or that I am not working ‘hard enough’

Not being around Academia – My office space is both a blessing and a curse. Whilst it’s lovely to be around normal working adults, I do miss being able to ask people about ‘academic stuff’ that I invariably know nothing about, due to not working in Unviersity.

Getting stuff to ‘done’ – This is a term we used to use in my old dev team that referred to a stage where it could be shipped. Of course, in an evnrionement where everyone has opinions of how code should be written (or in my PhD case, how things should be written, and just how many things should be done by one person) that can be quite a challange.

Writing – I’m dyslexic and I hate writing. This will be an issue next year when I have to write a thesis. Damm.

I will be writing a series of articles over the coming weeks to dive deeper into the subjects I am working on. Be prepared to hear a lot more about Citizen Science, Heritage Science and all things AI in the future!

^ A selection of submission from February ^


Brexit – an analogy using git

One of my lectures from today was invited to a round table discussion with the secretary of state last week to discuss the impacts of Brexit within cultural heritage. The way she explained the Brexit process immediately made sense to me through a git analogy, so I thought I may write it down and share it.

Currently the laws of the UK and the laws of the EU exist in two different repositories. However, the UK repo has a dependancy on the EU repo. This is a fairly important and powerful dependancy, and the methods (laws) in the EU package have the power to override the methods outlined within the UK.

Ok – so lets break this down.
The UK repo is pretty confusing; it is an unwritten constitution and is thus in a state of continual evolution. It pulls it’s methods (laws) from statues passed in parliament (high law) and judgments from judiciary courts (common law). However, there is no one document which lays out the law, like the constitution in the USA. This is because of how the UK has evolved; absolute monarchy,  magna carter, civil war, commonwealth, the restoration of the monarchy etc. I could into great detail about the evolution of this repo and it’s dependancies but that is not necessarily the subject of this discussion.

The point, is that the UK repo is huge, difficult to imagine in full and is constantly changing.

The EU repo, on the other hand, is younger an yet more complex. The UK repo only has one organisation contributing to it; the EU has 28. One of the reasons that the UK voted to leave the EU is because of the sheer size of the EU repo; it’s complex and carries a horrific amount of technical debt. This means getting new methods implemented takes a years of never ending pull requests, which go back and forth between all different contributors who all want the pull request to do different things. It promotes this process as open and democratic but in reality the complexity of it makes the repo seem private rather than public.

Another reason the UK voted to leave is because people get really pissed that the EU methods automatically overwrite the UK methods.


So that’s the current status, what happens when we leave?

The day the UK leaves the EU, the UK will fork at the EU repo into the UK account, merging all of the methods within the UKs. Therefore, the methods will still be implemented, but we will escape the nightmarish system of creating new ones.
From this point, our forked EU repo will no longer be updated from source.

Then the pull requests will start.

Once we’ve pulled this the EU repo into our own organisation, all the UK contributors will fall upon all of the EU methods they do not like and they have not been able to change up till this point.

I am sure there will be good and bad things that come from this process, irritating and pointless legislation will be removed. However, be warned that companies with a lot of developers, with a lot of power in industries will crack down on methods they don’t like (e.g. large scale development firms will try to get rid of environmental laws and measures currently safeguarded by the EU).

Therefore it is crucial that after the repo is forked, we keep an eye on what pull requests are being made and what methods (or laws) are being changed by who.


So that is my take on the current situation – it’s is very hand-wavy and terribly vague and probably incorrect in large parts. Let me know if you found it useful, you agree/disagree with it or can find a way to improve it. Comment away!

Easter Eggs Galore!

It’s no secret that I love easter eggs, be it real and virtual. So, seeing that I can’t be at Brigham Towers beating the rest of my family in our annual East Egg hunt (which I totally won last year, I’m going to remind everyone – with a healthy margin of 15 eggs) I thought I’d write a quick post about easter eggs we can enjoy outside of Cornwall!

My favourite is perhaps the one on the main Vouge website. On the homepage, simply type in the komani code, and enjoy!

The keys for the konami code are as follows:


For extra fun – just keep pressing that ‘a’ key… see how many you can get up.
(n.b if you are viewing this down under it will redirect you to an oz one – it only works on the US one)

The koonami code works on buzzfeed as well – it used to be sloth based, but they have recently changed it, not sure why.

Next up, google image search. Hope over there and type in Atari Breakout.

On the subject of google, the dinosaur on the error loading page of course needs a mention. If you haven’t worked out this is a game yet – either your internet connection is super reliable or you are… well just silly. You should get on that, it’s great. (hint – press space bar)

Also, if you type ‘do a barrel roll’ into google search – things get acrobatic. A simpler one is to type recursion into the search bar, or I’m feeling curious for fun facts or Google in 1998 for the old school feels.

Facebook next – this is not really an easter egg but it’s WELL COOL. If you go to the general settings – you can select English (upside down) or, even better, English (Pirate). OOHH ARR ME MATEYS! The title of the page turns to ‘Ye Olde Facebook’. Whats not to love?!

Youtube of course is in on this as well. Try searching for ‘Do the Harlem Shake’…

Unsurprisingly, the guys over at Wool and the Gang have some cracking ones. (Now I wonder how that happened…) Try clicking the aeroplane up next to ‘we ship worldwide’. When that gets dull, maybe try typing ‘YARN BOMB!‘ into the search bar.

Still not enough? Well then, head over the the party page and type in that old konami code again… it’s all about the party spirit! (I wonder how that got there? Probably a good bye present from some awesome developer…)

East eggs are AWESOME and if you have a website you should definitely include one. Here look, I’ve done all the work for you to get a simple penguin pop up on the go (though you can use other pictures!)

Focusing on empowering women and girls: why it is acceptable and why it’s important

Yet again today I was faced with the comment that organisations such as Code First: Girls and Chayn were wrong and immoral. This is because they are focused only on women and girls (as well as other underrepresented genders)  which is in itself sexist. It is an interesting argument to say that in targeting one gender, you will alienate another, and thus programs such as CodeFirst:Girls, Ada’s List, Women Who Code (this list goes on…)  are a contradiction in terms and can only detriment gender equality.

It is an interesting argument, but it’s wrong. It is also something that I, along with many of my peers, often face, and so I asked around to see what their separate responses were. I was not disappointed.

So here is the argument for why female focused programs are positive for gender equality. (I warn you now – that this is my polite version)

So let us start off with this metaphor:

Imagine that you have a class, which the professor splits in two, group A and group B. For 75% of the year the professor favours group B far above that of group A. He helps them, supports them and gives them extra tuition. Suddenly, the professor has an epiphany, and they realise that they are completely wrong in favouring group B over A and that his discrimination was wrong. As a result he decides to give fair treatment and equal opportunities to all, does this lead to an immediately fair situation?

Hell no. Group A has been so discriminated against it is far behind it’s counterpart – as such the students have no way of achieving the same results in the end of year test. They will need extra tuition and opportunities to reach the same skill level as the favoured group.

And, it is the same with women and girls.

In an ideal world we would not need organisations like those mentioned above, but an internationally ingrained patriarchal system means that these organisations are sorely needed. Many women are not in a position to empower themselves because they simply do not know of the opportunities available to them, or they are unable to take those opportunities due to other factors (such as cultural based expectation).

In previous conversations with leaders of organisations there is apparently a noticeable difference in behaviours between genders. Often you’ll find men will ask for pay rises, negotiate more heavily and place a strong emphasis on skill whilst a similarly skilled women will undervalue their skills and not push for the same recognition. Why is that?

Beyond the career, children are treated completely differently according to gender. It has only been through watching my 6 nieces and nephews grow up that I have noticed how outstandingly gendered children’s toys are; Lego Friends make me feel physically nauseous. We teach our children from birth that they are to expect different things from life, pink and blue.

Organisations such as CodeFirst: Girls would only negatively affect gender equality it there was parity in the first place. Imagine it like a see-saw; if one side is heavier than the other, you don’t get balance by putting the same weight in both sides. We would all like nothing better than for there to be a time when there is no need for the charities and organisations in question. But sadly, today is not that day.

I suppose there is an argument that if you just give all genders equal opportunities, eventually it will event out. Eventually. Honey, if you expect me to sit on my laurels and wait for gender equality to just even out – you have another thing coming. Considering the centuries of disparity – it will take centuries again without direct action, and I am not going to live for centuries. I want the gender I identify with to be seen as equal now, why should I expect anything less?

Big thanks to Madeleine, Ruby, Amali , Hera, Eleonora, Chiara, Nida and Maryam for all your contributions. You fabulous inspiring women.

Code == Knitting?

FullSizeRender (2)

“Knitting is basically coding”. Its a comparison I have heard banded around by a couple of senior tech experts and one that I frequently use myself to either tech scared knitters or craft scared coders; but how true is it?

A knitting pattern is essentially a computer program: it defines what you need to do in the correct order to achieve something. The difference between the computer program and a knitting pattern is the thing that carries out the pattern. In one it is a computer (with no knitting needles), in the other, a human (with knitting needles).

Really? It’s that simple?

Yes, and to demonstrate this, I will now write out two different knitting patterns, in pattern style and ruby style, so you can see that there is very little difference!

Knitting Pattern:
“Cast on 126sts.
Work in K 1, P 1 rib for 1.25ins.
Work in stocking stitch for 3ins, finishing at end of a P row.
Next row: K two stitches together, K across row.
P two sts together, P across row.
Rep until you have 10 sts.
Cast off.
Thread yarn through top 10 sts, pull together and stitch down the side to finish piece.”

FullSizeRender (1)

Computer Program:
hat =
hat.cast_on(stitches: 126)
hat.rib_stitch(length: 1.25, knit: 1, purl: 1)
hat.stocking_stitch(length: 3)
until hat.stitches == 10
hat.decrease(increment: 1)


And in human language:
Cast on 126 stitches onto your needle
Work in 1X1 rib stitch until your work measures 1.25 inches
After this, work in stocking stitch (purl one row, then knit the next) for a further 3 inches
On a knit row, knit the first two stitches together and knit to the end of the row.
On the next row, purl the first two stitches together, and continue along the row.
Repeat this (decreasing) until there are only 30 stitches left on your needle
Then cast off
Thread the yarn through each of the top stitches and pull tight to gather the top of the hat. Then stitch the two sides together to finish the hat.

The result – ONE HAT!

So – can people who knit code and vice versa?

Yes! It’s all about taking it one step at a time and not being put off by the big picture. Tell me to knit a jumper and I will run a mile – tell me to just knit one stitch – then if I repeat that a gazillion times to make a jumper – much easier to deal with!

Its the same with programming:
“Can you build me a website?” – “Errr…”
“Can you just take a couple of these lines of code and repeat them until you have a website?” “Yes!”

Continue reading

My Guide to Git, Part 1


When I first started at my current company I soon discovered there is nothing more dangerous to a codebase than a inexperienced dev with git access keys. On my second day I accidentally deleted my entire days work because of some command.  Of course I have no idea how I did it and I was far too scared to admit it to my boss and so I promptly did the whole days work that night amongst many frenzied google searches and silent prayers that no one in the team would realise the fraud of a developer I was.

Of course – it was fine, after a couple of days I worked out how I had deleted everything and made several notes to never do it again. Which I did. The next day.

Undoubtedly one of the hardest things to get to grips with when you start learning to code is Git. Unlike markup and programming languages, version controlling is not visual. Therefore, if you are unused to working from a programmatic viewpoint, it is incredibly hard to conceptualise. There are tools that can make this easier (git guis – I’ll get onto them in a future post) but even these require a fairly good knowledge of what on earth is going on in order to understand.

In this post – I’m going to take you through the metaphors I developed when I was first trying to get my head go with git, and in the following posts I detail my git toolbox – a nice little dictionary of my favourite git commands.

So what on earth is going on?


So git is a ‘Versioning Control System’, (ohhh, thats some excitingly dull words right there). This basically means that it is a tool that, when you ask it to, makes note of the state of the folder or file you are working on.

So imagine you are playing a computer game – every time you reach a checkpoint, the game saves your progress to that point. That is exactly what git does – except it does more. It keeps a record of every checkpoint you have reached – which means you can go back to that point.

Say you reached a hallway in Hogwarts (yup, we are playing a HP PC game now) and saved the game, you proceeded down the left corridor. This turned out pretty well, you found a Wizard card and a caldron full of beans, but you also found a venomous tentacular and you fainted. So instead you decide to go back to the checkpoint and try the right corridor. This turns out well as you find a stamina boosting chocolate frog – giving you enough life to face the venomous tentacular.

Good that you got that frog - as getting past Peeves here is a bitch
Good that you got that frog – as getting past Peeves here is a bitch

Lets get more complex

So, we have established the idea of these check points (or ‘commits’ as they are really called) and the ability to navigate around them, however, this does not fully appreciate the ‘different version’ bit of version control!

So now lets imagine our file as a tree, with a main trunk of work with regular commits. The trunk is your ‘master’ branch, this includes all the changes are ready and safe to be in your finished website.

But say you want to develop a new part of your website? Maybe a brand new feature.

In this instance your website is a very simple site where you list your favourite people from history. Ah, but then you think: “There are simply not just enough reference to Isabella, the She Wolf of France, on the internet” so you decide to build a hall of fame for the most badass monarchs.

Centuries before Shakira there was Isabella. She was badass.

However, halfway through building your hall you realise that you don’t have a good way to assign images to entries in your website. These are two very different features your website needs, and so they don’t necessarily need to be worked on at the same time.

So – you create two branches from your master tree – a hall_of_fame branch and a better_images branch. You can work on both projects independently, switching between the two easily, then, when they are done – you can merge them into master and push it to live.

The great thing with this branch approach is that you can continue with the general day to day fixes to the site easily. Because the code for these new features is on a seperate branch – you can easily adjust the spelling mistake you made on your last entry (Joan of Arc and John of Arc are very different people) without polluting your codebase with half baked files relating to a hall of fame.

So – got that?

I hear your silence and take it as yes.

Next time – collaborating with branches!


Are we in Danger of being the Lost Generation in Tech?

I live and work as a software developer in one of the largest cities in the world, and there can be no hesitation to say that we are in the middle of a technological revolution.

But what exactly does that mean? I am aware that this is just background noise for most; London is often an intrinsically insular thinking city which pretty much fails to grasp the concept of human existence outside the M25. What does a tech revolution mean to everyone that lives outside this type of eco-systems?

Well, at least most of the time, not much. And it’s hard to, as away from the hype and the free beer, people have their own issues. Innovations in technology are pretty damn niche in comparison to ‘I have to work a double shift tomorrow and dammit I just want a G&T shut up about fancy watches already’. So why am I writing this? Because our generation has a lot to lose from not caring about tech.

We made mud pies when the Dot-com bubble burst, we survived the millennium bug, we mis-managed the delicate politics of teenage social groups over MSN messenger, organised uni life on Facebook and graduated into the ‘Internet of Things’. Technology has utterly shaped our lives; something that on the whole we have accepted without much argument. Our generation’s IT lessons were spent flagrantly ignoring our teachers pathetic efforts to make a powerpoint presentations and fights with the rubber balls from the mice. IT was dull and pointless.

Nowadays that is not the case. Programming is being taught from primary school level, and children are being encouraged to code. Next year the BBC will give a raspberry pi to every 7 year old in the country to train them to build and break things. We are training a generation of mini super hackers. Which is great…

But not for our generation. The world of startups today offers a preview of how large swathes of the economy will be organised tomorrow. This pattern is already emerging in such sectors as banking, telecommunications, electricity and even government. The future is tech driven and in almost any sector this will be difficult to avoid. People who ‘don’t get computers’ will be left behind when the generation below us graduates.

The industrial revolution produced countless inventions that immeasurable improved many people’s lives and transformed society to the cost of multiple jobs. However, it created new economic opportunities on a mass scale, with plenty of new roles to replace those that had been made redundant.

Whether the digital revolution will bring mass job creation to make up for its mass job destruction remains to be seen, but how do we avoid being part of the jobless in years to come?… learn how to ‘get’ computers, and learn now.

(For and interesting article about this – check out this special report from the economist

My Year of Code

It is now roughly one whole year since I started calling myself a ‘developer’ (or, more specifically, Art Historian-turned-developer) so I thought I would write a wee little post about my general experiences from my year of code. Specifically, my year of code with Ruby and Rails.

In the beginning, there was Ruby. This was an Object Orientated Language, and it was Good.

‘I love Ruby.’

‘I have no idea what Object Orientated means, but it’s definitely a Good Thing’

‘It’s semantic – which means I can read it almost like English’

‘Yay for not needing a maths degree to program, I love art’

‘Dammit I miss history’

“I wonder how much I can relate history of art to code…’


‘… bugger’

And on seeing the Ruby was Good, the Ruby was built on, with a Framework called Ruby on Rails.

This did things such as CRUD and other acronyms, and this was Very Good.

Totes got the hang of this now, TO RAILS!’

‘I have no idea what this is, but if ruby is a Good Thing, Rails must be a Better Thing.’

‘Failing that I guess I can talk to Dad about trains’


‘Apparently Rails has nothing to do with trains’

‘Fat models skinny controllers – well, thats the OPPOSITE of the Fat Controller in Thomas the Tank Engine’

‘Holy mother of all the things what the hell is going on’

‘I done a scaffold and now I have a billion files’

‘But, why – why is this not working? what is a migration – why do I have to rake it, are there leaves on the migration?’

‘Maybe I understand what’s going on…’

But then, the world was Plagued by Acronyms. And it was Bad.


Acronyms + Dyslexia == Bad

Model Controller View or Model View Controller? – for a brain that reads words in different orders, exactly the same thing. But apparently, for a program – very different thing

And then, the code had to be written Test First

‘So I write the test for the code, to test the code works, before writing the code I want to run?’

‘But I don’t know what code I want to write’

‘Well, maybe I do, but I definitely don’t know how to write it’

‘So how do I write a test?’

‘My brain hurts’


But then there was the front end, and the ability to get creative – and it was Good

‘Sod Ruby – I’m gunna play with Javascript, styling and semantically written HTML now’

‘Damm this page looks fine’

‘Damm thats a lot of css’

‘Oh god, what do I do with all this Javascript?’

‘Oh you want me to do Ruby? oh damm… I forgot how to code’

And then, there was a Big Monolithic App, and That was Bad.

I thought rails was simple, this is not simple’

‘Oh God where do I put this business logic? (What is business logic again?)’

‘I feel like I need a maths degree’

‘What the hell am I doing with my life? Why am I a programmer?

*checks internet for all history MA’s still open for application*

‘Who the hell is Sandi Metz?’

And then there were many Blogs

I love Sandi Metz’

‘Oh so that’s what Object Orientated means’

‘Though now my code no longer reads semantically’

‘But it has no dependancies, which apaarently is a Good Thing’

‘I also know what dependency means now, which is an Improvement’

‘I’ve totes got the hang of this…’

‘Is this still Rails?’

Wait, what is it you do again?

My life has taken a fairly dramatic turn in the past year, from History of Art and everything cultural heritage to web development and everything tech. To answer the increasingly bemused remarks from friends, family and passing pub randoms I have developed some particularly useful metaphors to explain what I do, what Ruby is, and how an Art Historian can change their career with such ease. I find myself repeating these so often I thought it may be good to write them down.

The Web App Metaphor

The web app I work on ( is written in Ruby, with Ruby-on-Rails and Spree frameworks, has a SQL type database whilst the front end is comprised of HTML, CSS and Javascript. This is great and could sound impressive, but lets be honest it is a sentence that means bugger all to the majority of people.

So lets think of the Wool and the Gang website as a building instead.

Ruby is the main language of the app: think of ruby as being the bricks with which the building is built. However, you need more than bricks to build a house.


This is where Ruby-on-Rails comes in. It is a blueprint that enables you to get your basic building up in no time at all, complete with roof, flushing toilets and electricity as automatic bolt ons (Sinatra is another example of this, but it builds more of a shed in comparison to a rails building). It’s a very simple, generic building and is relatively easy to build on it and turn it into whatever type of building you want.


This is where the Spree framework comes in as an optional extra. Wool and the Gang isn’t just a web app, its an eCommerce site. To translate this into our building metaphor, we don’t want a building, we want a mansion equipped with swimming pool, baroque garden and a secret passageway (which changes location every second Wednesday). Spree is the blueprint for this that can be plonked on top of our current Rails building blueprint. Remember, these things are only blueprints, so these frameworks allow you to adjust elements of the buildings, such as adding a turret or two, which will be bespoke to your building.


Then there is the database, this is the contents of all the rooms in the building. Using the database language you can ask the butler to fetch your parasol to the lawn, and he will go in, check its there, take it, bring it out, then hopefully return it when you’ve finished your afternoon tea. With luck, and if you have used the right language, he will be a very efficient butler, and make a note of your parasol at each stage of its journey to you and back, which makes it very easy to locate when you next need it to take a turn around the herb garden.


So what about the facade (front end)? Well, HTML (Hyper Text Markup Language) plots where the doors, windows, chimney stacks and columns will go. The CSS (Cascading Style Sheet) then decorates all these elements as directed. It will adjust the size of the door, the exact colour of the lawn and whether the columns are Ionic, Doric, Corinthian or even Composite (ooo, racy….). Then there’s Javascript, this makes sure the doors open, the fountain is flowing and the doorbell rings when rung.

And voila! One beautiful, stable building, bespoke to your every need and whim!

Your completed building!

Hopefully…. because as anyone who has bought anything from IKEA knows, there always that suspicious leftover screw….

The Esteemed Guild of [Code]Crafters

A week into CodeCraft and my mind is starting to wonder in the most logical non-linear way it would; combing coding theory and practice with History of Art. We had an interesting talk recently which compared a method of software development with guild apprenticeships, a system in which budding craftsmen would be extensively trained before becoming accomplished craftspeople in their own right. I found this to be a highly interesting metaphor and I believe deserves proper consideration, so here we go:

Throughout the medieval period and up to the early modern (around 1100 – 1700) the City of London was home to and run by a Guild system, a form of governance based on various European counterparts. These were the official bodies of various different trades, crafts and practices, many of which can still be found hidden in the city today if you look closely enough. The guild system covered almost all parts of professional life, but I shall restrict this post to briefly look at the Worshipful Company of the Painter-Stainers. Not only is this an excellent example of an organised guild and apprenticeship system, but its inherent flaws bring up some interesting points when we turn our attention back to computer programming.

The Painter Stainers

Whilst our European counterparts often had dedicated painting guilds, the best London could offer throughout this period was the Painter Stainers guild. They derived from heraldic painters (painting arms on shields, saddles and stuff) and stainers, who quite literally stained cloth as a cheaper form of tapestry. The two were joined in the 1200, they acquired a hall in 1532 and 1581 were granted a royal charter.

The painter-stainer guild was a million miles from the later training academies that developed in Europe. They were a reactive group and jealously guarded their membership rights. This was because being part of the guild was similar to a badge of honour and the company were often in conflict with the Royal College of Arms which employed heralds.

Of course, in the grander scheme of things, English early modern painting is not one that comes to mind when one considers fine art, why is this? As the subtleties of chiaroscuro and tromp d’oeil (painting in a realistic three dimensional manner) was being explored and expanded throughout Italy, English portraiture by contrast is incredibly flat, focusing more on heraldic style and decoration than realism. (see images) What mistakes did the painter stainers make that means their foreign neighbours created a more memorable legacy?

Painted in in the early 1600 this painting, although interesting, is incredibly flat and show nothing of the realism of Michelangelo's Ignudo painted over 100 years previously
The Cholmondeley Ladies

There are of course many factors involved in this, country politics and religious practice being high among them, but there is also a lot to be said for the way in which new artists were trained. The guild was fairly backward in its approach to learning; it offered little training and did not help artists market or sell their work. Only members of the Painter Stainers guild were permitted to employ and train apprentices within the City of London, greatly limiting the trade. As a result, creativity was significantly stagnant in England. Whilst there is evidence of great workmanship dating from this period, there was little chance to build effectively on it through the traditional avenues.

This gap created by a lack efficient training and obscurity was of course, soon filled.

Members of the guilds were incredibly hostile to émigré artists (who were often more skilled) which caused great tension in the city. These artists would set up their workshops just outside the city limits, in Southwark and Greyfriars, allowing them to benefit from London patronage but avoid the laws of the Guild. England benefitted hugely from these émigré workshops, which injected new practices into the profession.

The  Painter Stainer guild is therefore a fantastic example of bad coding practice. Much like painting, coding is a craft. When those who code do it in secret, behind closed doors and allow only a privileged few to access an education in it, the result will be much like a typical English Early Modern portrait. Whilst the artist may have talent and potential, he is doomed to replicate the mistakes of his only tutor and the result is a flat piece of work which fails to compete with the wider market.

So what does a successful apprentice system look like?

Let us turn to one of the most famous of the Early Modern émigré artists, the workshop of Anthony Van Dyke. He was described by his tutor, the great Peter Paul Rubens (Google and go and visit the Banqueting House in Whitehall for more information on this guy) as one of his best pupils. Van Dyke did not only benefit from the workshop of Rubens, but toured all around Europe. He learned from many different painters and paid pilgrimage to the masters of the Renaissance and classical world in Greece and Italy. As such, Van Dyke was able to combine all his experience of the best practices of painting within his own and, without a regulatory body controlling him, was able to use this to expand rapidly within his own workshop.

 As an apprentice under Van Dyke your first role would be to prepare the painting materials; grind pigments, make brushes, prepare paper, stretch canvas. As you progressed you were slowly allowed more interaction with the painting. Apprentices would paint in certain colours, the background or the body. Often only the face and maybe the hands would actually be carried out the master himself. We know this by some of the contracts which survive, which outline the amount of work the master was required to do on the painting.

As a result his workshop was the most successful seen in England up to that point. His style was incredibly successful and his new composition of equestrian portraits dynamically changed English portrait propaganda. It is common in paintings by Van Dyke to be wary of who actually painted the image, as more often than not it would be constructed by his workshop in a manner like his own. (This is why Art Historians use the term ‘The Workshop of…’ or ‘In the Style of…’ when the true painter is in question).

Anthony Van Dyke, Charles I
Anthony Van Dyke, Charles I

So what can we draw back to the practice of learning to code?

Both the Painter Stainers and Van Dyke employed apprentices which gradually trained young people to be masters themselves. However, it is only with the freedom to learn from others and implement a wide number of different practices that you can adapt a model to be successful, which is especially important when the market is a stagnant and two dimensional as the standard Early Modern portraiture scene. Success in this system can be found in transparency and sharing knowledge; learn, but not limit; teach but don’t stifle, and of course, be open and welcoming to new practices.

And that is how a painter from the early Seventeenth can teach you how to be the next Mark Zuckerbuerg.