 So I'm going to be taking a bit of the trip to the past today. Hello, this is hello in ancient Greek. And that's hello in Australian, which is where I'm from. Now, ancient Greece might seem like a really long way away, and well, that's because it is. And I've also traveled a really long way to get here today, too. All the way from Australia, which is all the way over there. And I'm from Melbourne, which is at the bottom. Some people think it's a little upside down on the other side of the world. Maybe it is, maybe it's not. Many of you know Australia for our wildlife. These are regular photos that my mom sends to me. If you'd like regular Python updates, feel free to follow me on Twitter. Not about the language, I'm afraid. Generally more related to the reptile. Australia is also known for its other animals, like kangaroos. This is a marsupial known by most as something that young children like to ride to school. We also have this little thing called a platypus, which is also referred to as a duckbill platypus. What makes him so interesting is that he's a semi-aquatic egg laying mammal, which means it's a mammal that lays eggs instead of giving birth to live young. And it can also produce milk. So I think they're actually one of the only animals that can make it so encustered. That's kind of weird, but whatever. And this is a coca, and look, it's just adorable. This is just really cute. So I work at a place called The Conversation. And most of our small team of droolipers are based in Australia, but we have some in London and we have some in Brazil at the moment, too. We also have 150 editorial staff spread around the world for the eight different regional editions that make up The Conversation. So The Conversation is a non-for-profit where an independent source of news and views, an academic newsboard, basically. Editorial staff work with academic experts to report on a huge range of topics, from economic trends, politics, climate issues, and also cultural reviews and things. One of my favorite parts of The Conversation is called Fact Check, where we strive to tackle misinformation and test claims made by political leaders against the evidence that they report. This is particularly important in our current political climate. We have an on-site readership of 10 million and 30 million readers through republication a month. Currently, there's 1.1 billion readers recorded in our data warehouse, and we're continuing to expand. And yes, we do have a US edition, and I promise you we don't publish fake news. But I wasn't aware of the programmer, and it was just over two years ago that The Conversation gave me a wonderful opportunity to learn on the job. Before that, I'd very briefly dabbled in Ruby and written a few small programs here and there. But I generally spent my time working with artifacts in antiquity and heritage museums, as well as studying classical language. So this is generally what you first learn when you learn a modern language. Here's the Hello World for Learning Ruby. And here's when you first learn for classical Greek. So the Greeks did tend to be a little bit dramatic. Yeah, this is from Homer's Lot of Sea, if you're interested. So when I first began programming, one of the first things I learned about was the law of Demeter. And I remember this specifically, because I thought it must have been a coincidence that something in programming and something prevalent enough to learn so early could have ties to Greek mythology. Now, the law of Demeter was named for the origin in the Demeter project, which was named in honor of Demeter herself. Demeter is, or was in Greek mythology, the distribution mother, Mother Earth, if you will, the goddess of agriculture, of fertility. And she's also known for her association with sacred law and legislators. And yes, it is pronounced Demeter, although this does depend on which dialect of Greek you are speaking. So thanks to Demeter, this career king from archaeology and classics to coding suddenly didn't seem so dramatic. And all the links between these two disciplines, they may seem tenuous at best. They suddenly weren't. And over time, I found that there's some really strong parallels between the two. And now I'm finding myself identifying many facets of programming with history. Kubernetes, which comes from the Attic Greek, tekubernau, meaning to steer or to govern, and frequently referring to a helmsman or captain with Kubernetes are the first to claim masculine noun, but known most likely to you as deployment containers. The recent project, Aristotle, which was a study by the people analytics team at Google, to help answer what makes a team effective. With the project taking its name from Aristotle as a tribute to this very loosely translated quote, the whole is greater than the sum of its part, meaning we can achieve more if we work together. Zeus, of course, as God of the sky and thunder and also ruler of the gods, but also known in programming as an IDE, an integrated development environment. So we've got Demeter, we've got Kubernetes, we've got Aristotle, and we've got Zeus. So although we don't realize it, we are surrounded by history, but I'd like to go a little bit deeper than that today. And today I'm gonna talk to you about human intention in the archeological record and what this means for us as programmers, stratigraphy in context and technology itself. And although you've already had a small one, there'll be a few history lessons along the way. So how often do you dig through or commit history, peeling away layers of complexity, sifting for clues, trying to answer why? Why does this code do what it does? You're seeking to separate the important from the unnecessary or irrelevant, only to be stopped in your tracks, derailed by historical debris, an ill-defined method with an amusing but uninformative commit message. If you've all been there, I know that I certainly have. Every day we write code and we commit it, and those commits, for better or worse, preserve a piece of history, our reasons, our approach, and often our emotions. And this history lives on throughout the life of a project. And yet often the whole story, the reason why certain decisions were made is very rarely clear. The obvious decision may not have always been the best one. And when we finally manage to peel back the complexity, we sometimes find ourself in a worse state of confusion than where we began. So how can we make sense of this? What can we do? And to me, the answer is clear. And it lies in archaeology. So what is archaeology? What does an archaeologist do? This, this, this. Thanks to popular culture, you may have thought that maybe one of these represented archaeology. And that's totally okay. But I'm afraid that these are common misconceptions. Archaeology is not dinosaurs. It's usually not piles of gold, but it is definitely not Indiana Jones busting into a booby trap too. Adventure stories like these prevalent in popular culture, and they ignore the painstaking work involved in carrying out excavations and analysis. Does that sound familiar? Archaeology is instead a study of cultural history, of material culture, of people and the traces that they left behind. It is a never-ending detective story. And often, code is also a never-ending detective story. Yet archaeology is also the science of the past using observations and evaluations to test ideas and theories about what happened in antiquity, providing us with a fascinating and frequently beautiful window into the past. Now, I know that this sounds rather romantic, a window into the past to interpret as you will, but using strong scientific principles to ground interpretation. But it is also important to remember that the archaeological record is a distorted version of past events. Artifacts are broken, buildings burn and collapse. Food remains are usually only partially preserved if you're lucky. Not all sites, and in fact, barely any, with the exception of Pompeii, are perfectly preserved. But once archaeologists recognize that these processes influence the preservation and evolution of a site, they are able to look for reliable ways to reconstruct past human behaviors, to interpret these behaviors, these traces of individuality. So let's talk about that, human intention in the archaeological record and what that means for us as programmers. One of the most frequent cliches heard is that you cannot see the individual in the archaeological record, but it does contain very direct evidence of individual action and human intention, the digging of a rubbish pit, the construction of house foundations, the scratchings on a piece of ceramic to exile your least favorite politician. And we can often see such individuality with the first glance at a code base, how certain tests have been structured a certain way or the timestamp on a commit. But yet when I first began programming and frequently when pair programming, I'd hear my colleagues claims things like, oh, that's certainly something that Mark wrote or this class has written James all over it. And this is how I saw it. I couldn't, I couldn't see the individual in the code. I could not see the quirks that made one spec stand out as being written by one person instead of the other. I could not see intention, purpose, individuality. And I couldn't fathom how my colleagues possibly could. Now, for those of you that have been programming and working with others for a long time, this might seem like a really small thing. But the realization that you could actually see the individual within lines of code, it made me comfortable because it reminded me of how I would search for traces of individuality from antiquity. Now, there's this beautiful Greek word praxis, the main discussion of which comes from Aristotle. Aristotle, again, was a philosopher in the fourth century BC, which was at the height of classical Greece. He was a student of Plato and tutor of Alexander the Great. So Aristotle's politics and ethics treated praxis as an activity performed for its own sake, an activity which is undertaken as a realization of the intrinsic high capabilities of the human psyche. I'm not sure if you could decide for exactly what I just said, Aristotle can be a bit like that. This is what I meant, praxis. This word praxis sounds a lot like our modern practice. And that's because practice and praxis are derivatives of it. Praxis itself draws from the Attic Greek feminine noun, hepraxis, meaning fact or action, and the verb prato or praso, which means to do or to perform. Now, what I love about this word and the idea of this word is it's innate reflexivity. You, as the actor, are the one making the decisions when you write a method, a class, a model, you are making a decision to write it a certain way. Now, archeologically, I like to think about praxis as gaining knowledge about the world through observation or in a physical sense through excavation, the result of which being an examination of the relationship between humans and structures of society or an interpretation of these relationships. So let's think about interpretation as constructing a story of past behavior, a story that has a potential for alternate explanation. And think back to what I said earlier about archeology being an interpretive window into the past. So archeologists don't just find artifacts, describe or identify patterns of behavior and put them in time and space in the way that they want. They do it in a way that best suits the perceived interpretation. So we write code that fits into particular times and particular spaces. We write certain patterns of behaviors certain ways, be it language convention, team convention, or personal preference. We are writing code for the future to potentially come back and excavate, to interpret. Now, it's common human behavior to take your cuts. Many people do it all the time. And as programmers, we frequently do too because we are human. But there are many reasons why we may need to do this to write a particular piece of code a certain way. You might be under time pressure at work or the code itself might be forcing something to be written a certain way. And it can be easy to forget these things when you're the one in the future looking back, trying to reconstruct this story and not knowing how to interpret it. Not knowing how interpret the reasoning, the meaning, the story behind the code. Sometimes forgetting that there are alternate explanations and interpretations for things. Different circumstances require different actions and acknowledging these actions can help guide understanding the idiosyncrasies that form the whole picture. So this relationship between praxis and excavation, between interpretation, it puts individual intention and desire into the picture, into the code, into the archeological record. And these traces of individuality that we leave behind in our code, they personify it. And they are all expressions of human decision-making. And in the same way that the individual is present in the archeological record, in a pottery fragment, ostracizing again from Athens or the precise brush strokes that form a pattern. So are we within the code that we write and the decisions that we make to do it. Okay, so let's talk about context now, context and stratigraphy. So as programmers, we are lucky to be able to create a history that remains flat and readable. We have the luxury to rewrite and sanitize history. In the interest of a clean history, manipulating a single commit is easy. Manipulating two commits is easy. But it's essential to be aware that history isn't polluted and context isn't lost. So think about the ability that gives us to view historical snapshots of a code base at any point. An archeologist rarely sees more than a single reference frame at any one point. Portions of sites are uncovered. Everything is recorded as data. And a new reference frame is revealed. The first layer is forever destroyed by the virtue of this second being revealed. So think about this discussion in a programmatic sense from a developer's perspective. This is why you do not force push into master. So in archeology, these reference frames are called stratigraphy. And stratigraphy provides a fundamental basis for understanding chronological relationships in the archeological record. Think about stratigraphy in terms of a layer cake where the top layers are the youngest and the bottom, the oldest. Okay, maybe not a handbag, but more like a book on its side with layers of information, one on top of the other. A sequence from start to end. Now, I feel like I almost don't need to say this, but when you type git log, you've got your commits in that repo made in reverse conlogical order. A sequence, a story from end to start with the most recent commits first. So in order to understand the why of how events occurred, we can use chronological relationships when in the archeological record to get from static material to dynamic behavior. And we can do the same to understand events in the history of our repos. So, our git logs are generally formed in a fairly straightforward way. Our commits are instantaneously preserved, yet archeological sites are formed in complex ways. They are not instantaneously formed and preserved with the exception of Pompeii, of course. The archeological record forms slowly as a cumulative record, like a git log, but with a few more Romans thrown in. So, let's take a look at the Temple of Apollo at Corinth. The temple and Corinth itself has had a tumultuous history, much like most of ancient Greece. Periods of prosperity, followed by seemingly unending wars and conflicts to being ransacked by Romans and razed to the ground in 146 BC. Walls dismantled, territory given to a neighboring city. So, Corinth started again and rebuilt. And almost all of what remains of ancient Corinth is the Roman version. So, how do we date what there is that predates the Roman era? Well, we can do that with context. Context is a place and association of artifacts. It is the relationships that we can infer from such associations. It is a precise location where an object is found and recorded before it is removed from a site. So, the architectural features of the temple placed in the archaic period, which is broadly from the 8th to the 5th centuries BC. Yet the only external evidence for the date of the temple so far consists of part of a Middle Corinthian crater, which is a pot, basically. And this was found among the ships of stone lying between the cuttings for the foundation walls of the temple. And this means that the Temple of Apollo can be accurately dated to the middle of the 7th century BC at 625. So, we can understand the why of the temple, the when of the temple, but not the why. How do we know that it's a temple dedicated to Apollo? If not such much of a site remains and there's only two features that mean what we can accurately date it, how can we possibly determine its dedication to a particular deity? In this case, we know archaeologists know that the temple was dedicated to Apollo, again, thanks to context and association. So, just quickly, this is Apollo, the son of Zeus and Leto. He has been recognized variously as the god of light, sun, truth, prophecy, healing, music, poetry. He was an miraculous god, the prophetic deity of the Delphic Oracle, and considered the leader of the muses and thus the patron god of music. Depictions of Apollo were really, really common throughout the Greek and later Roman worlds. And he was sought to have been the characterization of this popular archaic chaos, the male version of this kure that I showed you earlier. So you couldn't imagine that the iconography of a temple dedicated to a god like this would be prolific. But remember, what we see today is not an accurate reflection of how it was in the past, and the archaeological record is formed in complex ways. In the same way that the current iteration of Master is not what it was an hour a week a month ago. So we know that currents were sucked by Romans and raised to the ground. And although there are a few surviving fragments which could have been sculpture of dedications, they do offer no indication to the, indication to the identity of the cult to which it was dedicated. But just north of the temple, a deposit of Arabalo was excavated. These are perfume or oil flasks. And they generally considered very suitable dedications to Apollo. And Porzanius, who was a Greek travelungeographer, he visited current in 175 AD, which was after the destruction of the city by the Romans. And he described a temple dedicated to Apollo located in the exact same spot that we find it today. So it is the complementary evidence of both written and archaeological records and the context of items within a record that has allowed archaeologists to date and dedicate the temple. And without that evidence, we still might not have a date for it or dedication for it. We may not understand, just like how working out how a big class is very frequently impossible until you can see how and where it's used. Understanding the where and the when something has come from is the main challenge of archaeology. And we are lucky that it gives us this ability, the ability to decipher where things belong. This innate desire to belong has been a driving force throughout human history. We want to know where we've come from and how we got there. And it is often context and association between artifacts, between code that allows us in the future, looking back to be able to decipher such belonging. Now from the late 1800s to the early 1900s, there was a debate raging in anthropological, scientific and cultural circles in North America. When did human beings first arrive in North America? At the time, the generally accepted time for occupation was between 9,000 to 8,000 BC. But then in the 1920s, a stone spear point was found lodged between the ribs of a bison. And this is significant because this particular species of bison had been extinct for thousands of years. In fact, thousands and thousands of years. It went extinct at the end of the last biceach in the Pleistocene. So the Pleistocene was the geological epoch which lasted from about 2.5 million to 11 and a half thousand years, BP. It is the first epoch of the equiternary period between the Pleistocene and the Holocene epochs. And it also corresponded to the end of the Paleolithic age, meaning old stone age term you may be more familiar with. So this particular spear point is characterized as a Folsom point. And Folsom points are found very widely across North America. And it is this context, this direct association between the bones of an extinct species and a spear point that was crafted from human hands and flung into a bison that conclusively proved that human beings were in North America during the last ice age, which was thousands of years earlier than previously thought. So remember, archeologically, context has to do with place and association among artifacts and the relationships we can infer from such associations. Context allows us as programmers, archaeologists, historians to build up webs of associations. So think about how methods all are about defining behavior so that you can apply them easily to different situations or like how you use modules for groupings to add context. Not all knowledge about a site can be found in its history, in its issues, in its pull requests. Remove an artifact from a site without properly documenting it means it has lost all context. It lost its age, its use, and its perceived meaning. It has little to no scientific or cultural value. So I recently ran into a surprising issue at work where I had to make a small change to a view. All I had to do was change the error on an error message. It was simple, it was easy. And then I went to check my change in situ. Although I could trigger the action to show the message, I wasn't seeing the error. I couldn't confirm that my change was okay. Logged to showing me a 404 and yet I was expecting a 403. So I flicked back to master, still 404s. So I could confirm that my change wasn't the problem. But at some point in the past, God knows how many years, five, the status code, the status code when making an XHR request changed from a 403 to a 404. I added a regression test and then I began a biosect. But after I'd gone back a year, I had to bring out the Git blame or context. I definitely recommend using an alias for blame. So with that, it didn't take me very long to realize that the feature was introduced all the way back in 2012. So where did it go wrong? I grabbed the share of the commit, the introduce the feature and checked it out. Since I suspected that this was an authorization error, I did a Git log on that five year old commit and looked for relatable, but suspicious commit messages or branch mergers around the time the feature was introduced. I'd gone a week or two back and this suspicious little commit caught my eye. So this authorization had been broken for years. And once I'd finally isolated where the problem originated, implementing a fix didn't take very long at all. So this small little change, this very minor adjustment to a view, it snowballed into an epic excavation of the code base, leading me all the way back to the beginning of its history. So mid last year, the conversation logged into Indonesia as its eighth region and third language. The first language was English, the third second was French and the third was Indonesian. So preparing a platform to support multiple languages is no small feat. And it requires code changes, realization changes, changes in sentences construction and input from translators. The list just goes on and on. But the Indonesian launch went really smoothly. We were happy, the team in Indonesia was happy and readership from them, Indonesia's just kept on growing. Until this, we began to see Indonesian leading to aspects. And this was noticeable in acceptance specs that use rack test, where the test and the app code were running on the same thread. So a spec that ran at some point earlier would change the locale instead of using the fullback English. And it was just a few here and there, so we kind of didn't really worry about it too much. We had more important things to do until this. And pretty soon, our build hygiene began to deteriorate and enough was absolutely enough. I got out of my biosec and unlike the previous example, I had three very specific pointers to guide me. I had a timeframe of where the issue began. I knew where the problem was isolated in acceptance specs that were using rack test. And I knew that the issue had to do with I-18N. So all these three things meant that isolating and identifying the problem didn't take me very long. But also like the previous example, I had a good commit message and history to guide me to that point. So while these are both fairly standard workflows to identify problems like these, such problems, such changes, such solutions, they appear straightforward enough. Just a small change to overview. This is simple, this is easy. And then suddenly you can't trigger an exception. You can't see a change in situ. And this is why leaving developers good context is important. Otherwise maybe you've got a method whose name doesn't accurately reflect its purpose and an unhelpful commit message. You aren't able to decipher what's going on. You aren't getting the whole story, the whole context. Your code is an undated, unexamined pot on a dusty shelf in a museum. It is a temple without a fragment. It is a spear point lying alone. No one knows where it's come from or what its purpose was. And changing code like that is dangerous. So isolating and identifying those two problems, it didn't take very much because I'd been left with a really good history. I had a clear and concise commit message and well yes, I was lucky because I knew what sort of change to look for. It was still enormously helpful. I would have taken a lot more time trying to see where the change was made if the code base was riddled with things like fix or whip or ODSCS being a bit tricky. So although team conventions may differ, my team generally follows the GitHub recommended guidelines. Where a commit is a short 50 to 75 summary, 50 to 75 char or less summary of the changes followed by a blank line and more explanatory text below. The imperative noted on my last slide means a direct verb, basically a command. So the summary should always be able to complete this sentence here. So it's important that the commit message doesn't rely too heavily on assumed knowledge because you can't always assume that the code itself is self-evident of the original problem. And this is why context is important, archeologically and programmatically, but all is not lost. Remember, as developers, we have the ability to create history, a history that is flat and readable that we can sanitize and improve. Now to finish, I'm just gonna talk a really little bit about technology itself. We work with technology every day and its roots are fascinating. So this is definitely the last one from us. The word technology itself comes from the Attic Greek feminine noun, heitechni, meaning skew with art or skew with craft. Aristotle, again, had a focused but simple restricted concept of techni. He defined it as a rational faculty exercise in making something, a productive quality. The suffix oligy is the first collection of logia, meaning to study or collect knowledge. And we can then trace that to logos, hologos as a masculine noun or lego as a verb, broadly meaning discourse, expression, history, thought, and interestingly enough, reckoning and computation. So we can be a bit more fluid with our interpretation of technology. I like to think of it as an idea of outwardly expanding yet nested set of actions and relationships. Human intent and desire of making and creating. And of course, a study of that. So in a broad sense, technology has defined us as a species. And I don't mean this because we are the sole users of tools because we aren't. I mean this because we have all interacted with some form of technology. We have a dependence on technology and this has led to an unprecedented complexity in technologies. And this underwrites the confidence that technology can iron out many problems which lends itself to a dependence on technology for mundane tasks. And for some, this can create a sense of despair. Individuals are no longer able to understand or reproduce society's technology. And this negative side of technology is becoming more and more apparent. So let us look to the past where archeology focuses on technological changes as an adaption. An adaption to problems. Problems like population growth, perceived needs. From stone technologies, manipulation of natural materials to the first computer, progressing to how we use technology today. And a lot of programming is merely an adaption to problems. And code is a way of fixing problems. Humans throughout history have taken pride in their technological achievements. And we as programmers are no different. It's important to take pride in what you do. No matter how small your contribution may seem or appear. Take pride in your code, in your intentions, in your decisions, in your commits. Your history will thank you for it. Thank you.