Here's to history: programming through archaeology
This is a modal window.
The media could not be loaded, either because the server or network failed or because the format is not supported.
Formal Metadata
| Title |
| |
| Title of Series | ||
| Number of Parts | 88 | |
| Author | ||
| License | CC Attribution - ShareAlike 3.0 Unported: You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal and non-commercial purpose as long as the work is attributed to the author in the manner specified by the author or licensor and the work or content is shared also in adapted form only under the conditions of this | |
| Identifiers | 10.5446/37306 (DOI) | |
| Publisher | ||
| Release Date | ||
| Language | ||
| Producer | ||
| Production Year | 2018 | |
| Production Place | Pittsburgh |
Content Metadata
| Subject Area | ||
| Genre | ||
| Abstract |
|
RailsConf 201854 / 88
9
14
16
19
20
22
23
26
27
28
34
35
36
37
38
39
41
42
46
47
53
57
60
62
63
64
69
72
80
85
87
00:00
BitDiagramComputer animation
00:31
Active contour modelScale (map)Greatest elementRegular graphDigital photographyFormal languageComputer animation
01:04
Chromosomal crossoverEvent horizonInfinityOval
01:44
Computer virusStaff (military)Data conversionPhysical lawFormal languageWhiteboardSource codeIndependence (probability theory)Multiplication signComputer programmingData warehouseSoftware testingMereologyBookmark (World Wide Web)Process (computing)Software developerProgrammer (hardware)Ocean currentRange (statistics)Expert system
04:03
Associative propertyProjective planeDistribution (mathematics)Classical physicsMathematicsPhysical law
04:31
Computer programmingMultiplication signLink (knot theory)Observational studyAnalytic setProjective planeParallel portComputer programming
05:12
Projective planeSound effectArithmetic meanMereologySummierbarkeitGodIntegrated development environmentComputer programmingRule of inferenceComputer animation
05:45
Decision theoryBitDecision theoryTrailComplex (psychology)CodeContext awarenessVideo gameMessage passingProjective planeState of matterComputer animation
07:38
Booby trapMathematical analysisComputer animation
08:08
Observational studyComputer programmingObservational studyCodeTracing (software)State observerPerformance appraisalSoftware testingTheoryComputer animation
08:39
Row (database)Event horizonWindowInterpreter (computing)BuildingComputer animation
09:04
Group actionWebsiteException handlingEvoluteProcess (computing)Programmer (hardware)Direction (geometry)Constructor (object-oriented programming)Row (database)Group actionComputer animation
09:54
CodeSocial classComputer programmingDampingSoftware testingTimestamp
10:26
WordMultiplication signLine (geometry)Tracing (software)CodeSource code
11:09
Library (computing)Student's t-testJames Waddell Alexander IIDecision theoryVector potentialGroup actionWordInterpreter (computing)Exterior algebraBitReflexive spaceResultantState observerData structure
12:44
CodeWindowInterpreter (computing)Multiplication signSpacetimePattern languageSuite (music)CodeFormal languageComputer animation
13:29
ForceCodeVector potentialProgrammer (hardware)ExpressionDecision theoryRow (database)Multiplication signCodeDifferent (Kate Ryan album)Group actionTracing (software)PressureExterior algebraInterpreter (computing)Computer animation
14:45
Context awarenessCodeCodeDecision theoryWebsiteContext awarenessPoint (geometry)Single-precision floating-point formatFrame problemProgrammer (hardware)
15:48
Frame problemDescriptive statisticsSoftware developerTerm (mathematics)Row (database)Basis <Mathematik>Computer animation
16:21
HTTP cookieMaxima and minimaSequenceLoop (music)Control flowSoftware bugCodeComputer fileMessage passingGreatest elementSequenceSoftware repositoryOrder (biology)Type theoryComputer animation
16:55
Event horizonSoftware repositoryLoginWebsiteException handlingRow (database)Event horizonForm (programming)
17:33
FrequencyRevision controlContext awarenessSource codeMeeting/InterviewComputer animation
18:14
Associative propertyUniform resource locatorObject (grammar)Associative propertyContext awareness5 (number)MereologyFrequencyComputer animation
18:40
ArchitectureContext awarenessFilm editingAssociative propertyContext awarenessCASE <Informatik>Website
19:29
Coma BerenicesMusical ensembleDepictionGodOracleRevision controlComputer animation
20:01
CodeLoop (music)Control flowSoftware bugComputer fileMessage passingMoment (mathematics)Reflection (mathematics)MereologyGodOcean currentIterationRow (database)Computer animation
20:28
Identity managementPrice index
20:56
Context awarenessRow (database)
21:25
Context awarenessContext awarenessSocial classAssociative propertyForcing (mathematics)CodeXMLComputer animation
22:11
CircleCategory of beingMultiplication signSpherePoint (geometry)SpeciesComputer animation
22:51
FrequencyArithmetic meanTerm (mathematics)Point (geometry)SphereAssociative propertyComputer animation
23:20
Associative propertyServer (computing)SpeciesSpherePoint (geometry)Category of beingError messageMathematicsMessage passingArithmetic meanView (database)CodeGroup actionWebsiteContext awarenessGodLinear regressionAssociative propertySoftware testingWeb 2.0Module (mathematics)LoginComputer animation
25:17
Game controllerComputer programmingCodeLoginContext awarenessFormal languageMultiplication signMathematicsFAQAuthorizationData conversionComputing platformElectronic mailing listError messageBranch (computer science)2 (number)Constructor (object-oriented programming)outputTranslation (relic)Computer animation
27:07
Level (video gaming)Block (periodic table)Pay televisionEmailMobile appThread (computing)SubsetPoint (geometry)Software testingLocal ringCode
27:32
Line (geometry)Context awarenessSoftware developerIdentifiabilityMessage passingMultiplication signView (database)Pointer (computer programming)Exception handlingGoodness of fitFrame problemSubsetMathematicsComputer animation
28:50
Line (geometry)Imperative programmingContext awarenessCodePoint (geometry)Message passingQuicksortBitInterpreter (computing)RootCountingSlide ruleAdaptive behaviorNatural numberNeuroinformatikNegative numberMathematicsContext awarenessLine (geometry)Confidence intervalArithmetic meanTask (computing)Multiplication signObservational studyRational numberComplex (psychology)Faculty (division)Set (mathematics)WordGroup actionSpeciesComputer animation
32:35
Adaptive behaviorComputer programmingCodeDifferent (Kate Ryan album)Computer animation
33:04
Decision theoryRow (database)Coma BerenicesBlock (periodic table)Data typeCommitment schemeComputer animationXML
Transcript: English(auto-generated)
00:14
going to be taking a bit of the past trip to the past today. Hi team, 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
00:26
long way away and well that's because it is and I've also travelled 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
00:43
of the world, maybe it is, maybe it's not. Many of you know Australia for our wildlife, these are regular photos that my mum sends to me. If you'd like rather regular Python updates feel free to follow me on Twitter, not about the language I'm afraid, generally more related to the reptile.
01:04
Australia is also known for its other animals like kangaroos. This is a marsupial and known by 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 duck-billed platypus. What makes him so
01:24
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 like one of the only animals that can make its own custard, that's kind of
01:40
weird but whatever. And this is a quokka and look it's just adorable, it's just really cute. So I work at a place called The Conversation and most of our small team of developers are based in Australia but we have some in London and we have someone in Brazil at the moment too. We also have 150 editorial staff spread around the world for the eight different regional editions
02:06
that make up The Conversation. So The Conversation is a non-for-profit where an independent source of news and views, an academic news board basically. Our editorial staff work with academic experts to report on a huge range of topics from economic trends, politics, climate issues
02:28
and also like cultural reviews and things. One of my favourite 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
02:45
political climate. We have an on-site readership of 10 million and 30 million readers through re-publication a month. Currently there's 1.1 billion reads 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
03:04
news but I wasn't away as a 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
03:21
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 what you first learn for classical Greek. So the Greeks did tend to be a little bit dramatic. Yeah this is from Homer's
03:46
Odyssey 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
04:01
to learn so early could have ties to Greek mythology. Now the law of Demeter was named for their origin in the Demeter project which was named in honour of Demeter herself. Demeter is or was in Greek mythology the distribution mother, mother earth if you will, the goddess of agriculture or fertility and she's also known for her association with sacred law and
04:24
legislators and yes it is pronounced Demeter although this does depend on which dialect of Greek you are thinking. So thanks to Demeter this career change from archaeology and classics to coding suddenly didn't seem so dramatic and although the links between these two disciplines
04:41
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 Te Kubernete meaning to steer or to govern and frequently referring to a helmsman or captain
05:05
with Kubernetes as a first declension masculine noun but known most likely to you as deployment containers. The recent project Aristotle which was the study by the people analytics team at Google to help answer what makes a team effective with the project taking its name from Aristotle
05:25
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 knowing programming as an IDE integrated development
05:45
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 going to talk to you about human intention in the
06:07
programmers, stratigraphy in context and technology itself and although you've already had a small one there will be a few history lessons along the way. So how often do you dig through a
06:23
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
06:42
an ill-defined method with an amusing but uninformative commit message. Sure we'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
07:03
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
07:21
we sometimes find ourselves in a worse state of confusion than where we began. So what 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?
07:43
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 it's usually not piles of gold but it is definitely not Indiana Jones busting into a booby trap too. Adventurous stories like these prevalent in popular culture
08:04
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
08:23
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
08:42
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
09:06
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 recognise that these are processes that influence the preservation and evolution of a site they are able to look for reliable
09:24
ways to reconstruct past human behaviours, to interpret these behaviours, 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
09:46
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 favourite politician
10:04
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 exclaims things like oh that's certainly something that Mark wrote or
10:23
this class has written James all over it and this is how I saw it. 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
10:41
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 realisation 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
11:01
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,
11:26
an activity which is undertaken as a realisation of the intrinsic higher capabilities of the human psyche. I'm not sure if you can decipher exactly what I just said, Aristotle can be a bit like that but this is what I meant. This word praxis sounds a lot like our modern practice
11:43
and that's because practice and practices are derivatives of it. Praxis itself derives 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
12:04
is its 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 archaeologically I like to think about praxis as gaining knowledge about the world through
12:23
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
12:42
behaviour, a story that has a potential for alternate explanation and think back to what I said earlier about archaeology being an interpretive window into the past. So archaeologists don't just find artefacts, describe or identify patterns of behaviour and put them in time and space in the way that they want. They do it in a way that best suits
13:04
the perceived interpretation. So we write code that fits into particular times and particular spaces. We write certain patterns of behaviours certain ways, be it language convention, team convention or personal preference. We are writing code for the future to potentially come back and excavate,
13:27
to interpret. Now it's common human behaviour to take shortcuts. 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
13:41
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,
14:00
not knowing how to 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
14:23
praxis and excavation, between interpretation, it puts individual intention and desire into the picture, into the code, into the archaeological record and these traces of individuality that we leave behind in our code, they personify it and they are all expressions of human decision
14:41
making and in the same way that the individual is present in the archaeological record in a pottery fragment ostracising a general 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.
15:01
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
15:22
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 archaeologist rarely
15:44
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 the second being revealed. So think about this
16:03
description in a programmatic sense from a developer's perspective. This is why you're not forced to push into master. So in archaeology these reference frames are called stratigraphy. As stratigraphy provides a fundamental basis for understanding chronological relationships in the archaeological record. Think about stratigraphy in terms of a layer
16:25
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
16:43
type git log you've got your commits in that repo made in reverse canonical 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 using the archaeological record
17:04
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 archaeological sites are formed in complex ways.
17:23
They are not instantaneously formed and preserved with the exception of Pompeii of course. The archaeological 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
17:44
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
18:02
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 the place and association of artifacts. It is the relationships that we can infer from
18:20
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 place 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 middle Corinthian crater which is a
18:44
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 century BC at 625. So we can understand the why of the temple,
19:02
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 the site remains and there's only two features that means we can accurately date it how can we possibly determine its dedication to a particular deity? In this case we can we know archaeologists know that the temple was dedicated to Apollo again thanks
19:23
to context, 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.
19:41
He was an oracular 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 thought to have been the characterization of this popular archaic kouros, the male version of this koure that I showed you earlier.
20:06
So you could 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 parts how it was in the past and the archaeological record is formed in complex ways in the same way that the current
20:23
iteration of master is not what it was an hour a week a month ago. So we know that currents were sacked by Romans and raised to the ground and although there are a few surviving fragments which could have been sculptural dedications they do offer no indication to the indication to the identity of the cult to which it was dedicated.
20:44
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 Pausanias who was a Greek traveling geographer he visited Corinth in 175 AD which was after the
21:04
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 the record that has allowed
21:21
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 it 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
21:44
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
22:02
association between us, 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
22:26
accepted time for occupation was between 9000 to 8000 BC but then in the 1920s a stone sphere point was found logged between the ribs of a bison and this is significant because this
22:40
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 ice age 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's the first epoch of the Quaternary period
23:03
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 sphere 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
23:25
of an extinct species and a sphere 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 archaeologically
23:44
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 behaviour
24:02
so that you can apply them easily to different situations or like how you use modules for groupings to add context. Now 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
24:21
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
24:41
on an error message. It was simple, it was easy and then I went to check my change in situ and while I could trigger the action to show the message I wasn't seeing the error. I couldn't confirm that my change was okay. Logs are showing me a 404 and yet I was expecting a 403. So I flicked back to master, still 404s. So I could confirm my change wasn't the
25:06
problem but at some point in the past, god knows how many years, five, the status code when making an XHR request changed from a 403 to a 404. I had a regression test and then
25:22
I began to bisect but after I'd gone back a year I had to bring out the blame or context. I definitely recommend using an alias for blame. So with that it didn't take me very long to realise that the FAQ was introduced all the way back in 2012. So where did it go wrong?
25:41
I grabbed the shire of the commit that introduced a feature and checked it out. Since I suspected that this was an authorisation 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 FAQ was introduced. I'd gone a week or two back and this suspicious little commit caught my eye. So this authorisation had been broken for years. And once I'd finally
26:07
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.
26:25
So mid last year the conversation logged into Indonesia as its eighth region and third language. The first language was English, the second was French and the third was Indonesian.
26:44
So preparing a platform to support multiple languages is no small feat and it requires code changes, pluralisation 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,
27:03
the team in Indonesia was happy and readership from Indonesia has just kept on growing. Until this, we began to see Indonesian leaking into our specs. And this was noticeable in acceptance specs that use racktest where the test and the app code were running on the same thread. So a spec that ran at some point earlier would change locale instead of using
27:25
fallback 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 my bisect and
27:42
in the previously unlike the previous example, I had three very specific pointers to guide me. I had a time frame of where the issue began. I knew where the problem was isolated, acceptance specs that were using racktest. And I knew that the issue had to do with I18n.
28:01
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,
28:22
they appear straightforward. Just a small change to a view. 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. An unhelpful commit message. You
28:44
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 laying alone. No one knows where it's come from or what its
29:02
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 while yes, I was lucky because I knew what sort of change to look for, it was still enormously helpful. And would have taken a lot more time
29:22
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
29:41
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.
30:02
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, archaeologically and programmatically. But all is not lost. Remember, as developers, we have the ability to create history,
30:25
a history that is flat and readable, that we can sanitize and improve. Now to finish, I'm just going to 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, I promise. The word technology itself comes from the Attic
30:45
Greek feminine noun, hetekne, meaning skill with art or skill with craft. Aristotle, again, had a focused but simple, restrictive concept of tekne. He defined it as a rational faculty exercise in making something, a productive quality.
31:01
The suffix ology is the first declension 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.
31:26
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, the study of that. So in a broad sense, technology has defined us as a species. And I don't mean this because
31:45
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 led to an unprecedented complexity in technologies. And this underwrites the confidence
32:01
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. Let us look to the past,
32:23
where archaeology 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
32:45
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,
33:01
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.