(fast-paced electronic music)
- [Eleanor] Hi, or,
nice I'm gonna taking a bit
of a trip to the past today.
(speaking in Greek)
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. (laughs)
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's 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 duck-billed 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
like one of the only animals
that can make its own
custard that's kind of weird
but whatever.
(audience laughs)
And this is a koaka, and
it, 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
that make up The Conversation.
So The Conversation is a non-for-profit.
We're an independent
source of news and views.
An academic newsboard, basically.
Our editorial staff work
with academic experts to
report on a huge range of topics from
economic trends, politics, climate issues,
and also like 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 purport.
This is particularly important
in our current political climate.
We have an onsite readership of 10 million
and 30 million readers
through republication 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 U.S. edition
and I promise you we
don't publish fake news.
But I wasn't always 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 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
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 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 change
from archaeology and classics to coding
suddenly didn't seem so dramatic.
And although there are 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
(speaking Greek) meaning
to steer or to govern,
and frequently referring
to a helmsman or captain,
with (speaking Greek)
of the first declension masculine heir.
But, known most likely to
use as deployment containers.
The recent project Aristotle,
which was 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 program as an IDE,
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
archaeological 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 will be a few history
lessons along the way,
of course.
So.
How often do you dig
through a 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.
(audience laughs)
You all have 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?
(audience laughs)
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-trapped tomb.
Adventure stories like these
are 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 the 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 time stamp on a commit.
But yet when I first began programming
and frequently when pair programming,
I'd hear my colleague exclaim things like,
"Ugh, 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 see the individual in the code,
I could not see the quirks
that made one speck 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 all this 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 B.C.,
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
decipher 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 practices
are derivatives of it.
Praxis itself derives from
the Attic Greek feminine noun
hepraxis, meaning fact or action,
and the verb pratto or prasso,
which means to do or to perform.
Now, what I love about this word,
and the idea of this word,
is its innate reflexivity.
You, as the actor, are the
one making the decisions.
When you write a method, a class, 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 observation
or in a more 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 archaeology being
an interpretive window
into the past.
So, archaeologists 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 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 made 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 to
interpret the reasoning,
the meaning, the story behind the code,
something 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
archaeological record.
And these traces of individuality
that we leave behind in our code,
they personify it, and
they're all expressions
of human decision-making,
and in the same way that
the individual is present
in the archaeological record
in a pottery fragment
ostracizing 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.
Okay.
So let's talk about context now.
Context and stratigraphy.
So, as programmers,
we are lucky to be able to create 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 git gives us
to view historical
snapshots of a code base
at any point.
An archaeologist 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 the
second being revealed.
So think about this destruction
in a programmatic sense,
from a developer's perspective.
This is why you do not
force push into master.
So, in archaeology these reference frames
are called stratigraphy,
and stratigraphy provides
a fundamental basis
for understanding
chronological relationships
in the archaeological 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 chronological 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
within the archaeological 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 archaeological sites
are formed in complex ways.
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.
Um, 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 B.C.
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 the precise location
where an object is found and recorded
before it is removed from its site.
So the architectural
fixtures of the temple
place it in the Arcade period,
which is broadly from the
eighth to the fifth century B.C.
Yet the only external evidence
for the date of the temple
so far, consists in part of
a middle Corinthian Krater,
which is a pot, basically.
And this was found
among the chips 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 seventh
century B.C. 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 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 know, archaeologists know
that the temple was dedicated to Apollo,
again, thanks to context.
Context and association.
So, just quickly.
This is Apollo, the son of Zeus and Leta.
He's been recognized variously
as the God of light, sun,
truth, prophecy, healing,
music, poetry.
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 Kouhe
that I showed you earlier.
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 how it was in the past,
and the archaeological record
is formed in complex ways.
In the same say that the
current iteration of master
is not what it was an
hour, a week, a month ago.
So we know that Corinth
was sacked by Romans
and razed to the ground,
and although there are
few surviving fragments,
which could have been
sculpture of dedications,
they do offer no indication
to the identity of the cult
to which it was dedicated.
But, just north of the temple
a deposit of Aryballos was excavated.
These are perfume or oil flasks.
And they are generally considered
very suitable dedications to Apollo.
And Pausanius, who was a
Greek traveling geographer,
he visited Corinth in 175 A.D.
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 that record
that has allowed archaeologists
to date and dedicate the temple.
And without that evidence we
still might not have a date
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 git
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 B.C.
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 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 B.P.
It's the first epoch of
the quaternary period
between the Pliocene
and the Holocene epochs,
and it also corresponded to the end
of the Paleolithic age,
meaning old stone age,
a 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.
Archaeologically, 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.
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 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 (mumbles)
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 couldn't confirm that
my change wasn't the problem.
But at some point in the past,
god knows how many years,
five.
(audience laughs)
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 bisect,
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 fix was introduced
all the way back in 2012.
So where did it go wrong?
I grabbed the shard of the commit
that introduced the feature
and checked it out.
Since I suspected that this
was an authorization error
I did the git log on
the five year old commit
and looked for relatable but
suspicious commit messages
or branch mergers at around the time
this feature was introduced.
I'd gone a week or two back,
and this suspicious little
commit caught my eye.
Says the authorization
had been broken for years.
And once I 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 lodged into Indonesia
as its eighth region and third language.
Their first language was English,
the second was French,
and the third was Indonesian.
I'm just gonna have some water.
So preparing a platform to
support multiple languages
is no small feat.
And it requires code changes,
cyrillization changes,
changes in sentences construction,
and import 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 Indonesia's
just kept on growing.
Until this.
We began to see Indonesian
leaking into our specs.
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 at the locale
instead of using the 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 on my biset
and in the previously,
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 tests.
And I knew that the issue
had to do with I1A to N.
So all these three things
meant that isolating and
identifying a 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 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,
and 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 cause I'd been left
with 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've taken a lot
more time trying to see
where the change was made
if the codebase was
riddled with things like
fix or whip or
Odysseus being a bit tricky.
So although tinker mentions may differ,
my team generally follows the
github recommended guidelines.
Our commit is a short, 50-75 summary,
50-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 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 everyday
and its roots are fascinating,
so this is definitely
the last one, I promise.
The word technology itself
comes from the Attic Greek
feminine noun tekne,
meaning skill with art
or skill with craft.
Aristotle again had a focused
but simple restricted concept of tekne.
He defined it as a
rational faculty exercised
in making something,
a productive quality.
The suffix, ology, is the
first declension of logia,
meaning to study or collect knowledge,
and we can then trace that to logos,
ho logos 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 the 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.
(audience applauds)
(digital zoom)
(high pitched bell)
