while history: continue
This is an edited transcript of the keynote I delivered at PyCon UK in 2019. I'm still grateful to the organisers, and I still treasure my memories of visiting Cardiff for the first time that year. I've edited the transcript only to make it readable, fixing sentences and removing filler words – but the content and structure remains unchanged. I also left in audience reactions, for flair (and because I'm a bit proud to have made people laugh). See the end notes for corrections and other remarks – you can also see the full slides including speaker notes here.
Back in the day when Julius Caesar returned from his honeymoon with Cleopatra – yes, this is going to be about Python, I promise! – he decided, because he was a great man and great men want to do great things, to end the Years of Confusion. The Years of Confusion were a feature of the Roman calendar, which had 355 days to a year. As you will have noticed, that's ten days short of our calendar. The Romans, not being stupid, noticed that their calendar rotated away from the solar year. To compensate, they occasionally inserted another whole month after February. Now, "occasionally insert a month" is fairly lax, and came with several problems, as you might imagine.
Not the least of which was that the Internet was very very slow back in the day. laugher The decision to add this so-called intercalary month was made rather spontaneously a couple of weeks or even just days ahead – so, often citizens of the Roman empire didn't actually know which month they were living in. Since the Romans had invented bureaucracy at that time, that led to even more problems down the line. More crucially though, this rather spontaneous decision of whether to add another month was made by the ruling class, in particularly by the consuls. The two consuls were only in power for one year at a time, and could not be directly re-elected – it was expected that they took around ten years off at least. Imagine: you're in power for a year, but you can decide how long the year is going to be by inserting another month – what a temptation! There times when there were intercalary months for several years in a row – and on the other hand, sometimes Rome would go to war, and everybody would just … forget about calendars and odd intercalary months because they had better things to do.
An unpredictable year length made the administration quite unhappy. So Caesar went ahead and invited the best available mathematicians and astronomers – experts in their fields who knew what they were doing. We don't know their names, their lives aren't recorded, but their proposal is: It was adopted as the Julian calendar. The Julian calendar changed the year to a be 365 days long, and then added another day every four years. Which should sound somewhat familiar to you, because it's nearly the same as the system we're still using!
The trouble is, the Julian calendar assumes that your year is 365 days and six hours long, which isn't quite correct. It's off by a total amount of nearly eleven minutes. That's an error rate of .002% over the course of a whole year, which might sound like it's negligible. I'm a humble web developer and I know that .002% sounds like an excellent error rate to me. [laughter] And even much better developers, I think, would agree that this sounds reasonable. Unfortunately, they left the Julian calendar on running in production for a long time, rather unsupervised. [laughter] I don't want to know what's going to happen when somebody leaves my programs running for a thousand years. But this is what happened! Europe proceeded to become medieval, had its hand full trying to retain general literacy, and calendars were the furthest from everybody's mind.
Short disclaimer: this talk will be European centric, because talking about just the mess we ended up with at home can comfortably fill the hour I'm allowed to talk for. Accounting for the impact European calendars had on the rest of the world over time would take a lot more than that – just keep in mind that no matter how complex things may sound, reality is even worse than that!
Medieval times gave way to the renaissance and the Early Modern period, and in the 1500s people got round to being
interested in calendars again. They discovered that the year had rotated off the solar year by about ten days. You
might say: who cares? Ten days don't mean that winter is in summer suddenly, after all. A sensible answer would be that
people might value consistency in their calendars, especially for matters of agriculture. The actual answer is that
the date of Easter is, as you probably know, inconveniently not a fixed date. It is computed (the calculation was
literally called computus) as the first Sunday after the first full moon after the spring equinox. Stunningly
intuitive!
The crucial point in all this is that the spring equinox was just assumed to be March 21st. But if your calendar rotates off the solar year by ten days, that's not true anymore! So suddenly, your date of Easter is wrong, and that was a big deal at the time. Who cared? The Pope cared about that, and what the Pope cared about, all of Europe cared about, too. Pope Gregory XIII, just like Caesar, again invited mathematicians and astronomers. (This time we actually know their names, but I'm not going to bore you with them.) They talked and they calculated, and they came up with a formula that describes the length of a solar year: 365 + ¼ - 1/300. Incidentally, with this formula they rediscovered what the ancient Greek mathematicians had known a hundred years before Caesar. But the Romans had a tendency to take only parts of Greek culture, and ignore the important bits.
If you put this formula in a form that people can actually use, it's a set of rules that goes like this: A year is a
leap year (a year with an additional day inserted in February), if it divisible by four, unless it is divisible by 100
(then it is not a leap year), unless it's divisible by 400 (then it is a leap year). The new rules fit in three lines,
which is nice. They have great application for day-to-day life, because if you're teaching new programming students,
this is what you use to teach them if-else statements. They didn't really express it as three lines back in the day, of
course, as scientists, they were a bit more verbose: The Pope published a law, a Papal Bull, called Inter Gravissimas,
because those are the first words in that document. They have absolutely no bearing on the content, but that's how Papal
Bulls were named. Imagine if we named programs like that: you'd get sick of files called int main within ten minutes.
Although there are schools of variable naming that are not fundamentally different, come to think of it …
The year is 1581, and the law is published describing how the new calendar is going to work. It also described how the existing calendar was going to be fixed – having a new calendar is great, but it would still be ten days off the solar year, which needs to be used to find the date of Easter. The solution Rome (that is, the Pope and his advisors) came up with, was both simple and absurd: They proposed to just silently drop ten days, jumping from one day to ten days later, and pretending that nothing had happened.
All this sounds like they had a solid, if odd, plan going. But things aren't ever easy: Pope Gregory was just a bit late. In the 1580s, the Catholic Church was in big trouble. The preceding decades had seen the Church splinter into different Protestant Churches, plus the Anglican Church, and so on. So other than 80 years prior, the Pope suddenly didn't have the absolute say over all of Europe. In 1581, some countries – the Catholic countries – adopted the new calendar: Spain, France, Poland, the Lithuanian Commonwealth, and so on. I tried to draw up the borders, but it's fiendishly complex – European history is terrible. Anyhow, towards the end of the year, those countries jumped ahead by ten days, which is why the Holy Theresa of Avila, Spain, died on the night from October 4th to October 15th, which sounds like a really protracted long death, when you don't know that it was just a single night.
Sound familiar yet? Let's put it a different way: We had a fairly technical system that many people were using, and that worked well for everybody involved. But there were technical issues with it that needed to be fixed sooner or later, from the point of view of people who were highly involved in the technical side of it. So the person most responsible, the BDFL (benevolent dictator for life) of the Catholic Church decided after consulting a lot of advisors to unilaterally change the system and update it to a better system – one that looked superficially the same, with minor technical details updated to reflect the current state of the art. The switch in itself proved to be very, very painful despite the underlying similarity, and people who were either not on board with the new mission or just sceptical, did not agree. (Fun fact, the Protestant countries actually thought this was a ploy of the Pope to get them back to the Catholic Church.) So people who were not politically involved with the decision makers, decided to resist this change. Which then led to one continent, separated by two systems that look very much the same but at the same time can't work together. Any similarities with the transition from Python 2 to Python 3 are absolutely intended. [laughter]
How did people deal with this back then? My favourite example comes from the fact, religion was a good cause as any to go to war, and the closer something is to you, the more important the differences seem. If you go to war, sooner or later you come up with a peace treaty. Now, what do you put on the treaty when one country has one date, the other country has another date? It turns out, there was a fairly pragmatic solution to that. Pictured below: You just put in both dates. Today is the 16th of September according to the new Gregorian calendar, but if we were still living with the Julian calendar, which has gone off by three more days (because that continues happening over time), it would be the third of September. Again, if this looks like the conversion between Python 2 and Python 3 to you: it should.
Europe continued to be split on the matter for a terribly long time. It took over 100 years for the first other countries to come around to the new calendar. One hundred years of divided days! And some countries proved to be more stubborn than others, which was mostly about their relationship to the Catholic Church.
We don't have to look any further than this island: The Kingdom of Great Britain made the switch in 1751. 1751 is nearly 200 years after the first conversion. But the interesting fact is not that it's 200 years later or that they were the last country in Western Europe to make the switch. The interesting part is that their long new law, receiving Royal Assent in 1751, doesn't mention the Catholic Church, the Gregorian calendar or Pope Gregory at all. It's a complete standalone argument for switching to a new calendar that does a better job of conforming to the solar year! What an impressive example of the things politics and human stubbornness can do. [laughter] The law does mention, though, that there was a lot of confusion when dealing with mainland Europe, because, for example, communicating payment and delivery dates with European merchants led to frequent problems.
Talking about centuries of different calendars, we also need to talk about Eastern Europe. Eastern European countries were less likely to like the Catholic Church than the Protestant countries in Western Europe. The Orthodox Church split off the Catholic Church way earlier than the Protestant Church by 500 years, after all – so naturally, it also took them nearly 500 years to get around to the Roman calendar. For example, Russia only made the switch after the October Revolution in 1918. Which, incindentally, was a November Revolution according to the calendar everybody else was using at the time! The last European countries to use the Gregorian calendar within Europe were Greece in 1922 and Turkey in 1927. And a spending 350 years with a different calendar produces plenty of funny or absurd stories around the fault lines. Like when the Olympic Games were still fairly new (at being reintroduced, not in ancient times) and were a rather unnoticed and small event that took 80 days, in 1912, the Russian delegation arrived 12 days late – because somebody messed up the invites.
To see more serious consequences, we need to talk about Napoleon. When Napoleon steamrolled all of Europe (excepting, again, this island), an alliance arose between Austria and Russia (plus others, who are not important to this story). They made plans to coordinate to resist Napoleon – and, as you can guess, from this context, they messed up the dates. The Austrian army marched to meet up with the Russians, and found that the Russians had only planned to get there ten days later, and so were too far away to support the push forward. This advance part of the Austrian army was decimated and Napoleon just rolled on, conquered Vienna, and went on to the big decisive battle at the time, the Battle of Austerlitz. By that time, the Russians had finally arrived, but since their forces were weakened so much, Napoleon won and carried on. Which is a bit more serious a consequence than missing a sporting competition.
One last example, and I promise we'll leave calendars alone after that: Sweden was a Protestant country, so they resisted the new calendar for a time. But when parts of what-would-later-become-Germany and the Netherlands made the switch in 1700, they decided to follow suit. But they didn't like the whole idea of dropping 10 days – it seemed to them that continuity was important. So they decided to defy conventional wisdom, and instead to start ignoring all leap days for 40 years, until their calendar aligned with the new Gregorian timeline. Which was a horrible, horrible idea, of course! [laughter] It might be good for internal continuity, but it would also result in their offset to both established calendars changing every four years.
So in 1700, they didn't have a leap day, just as planned. Unfortunately, that was the only part that went according to plan, because shortly after, they crowned a new, young king. All the surrounding countries took the existence of an inexperienced ruler as a formal invitation to go to war (not even using religion as a pretext). 1704 came and went, and just like the Romans, the Swedes forgot all about calendars while dealing with war, so the Swedish 1704 had the regularly scheduled leap day. 1708 comes and goes, and the war is still going on, and nobody really remembers the whole plan, so another leap day takes place – putting Sweden on a 1-day offset to the other Julian calendar countries.
Then, the war ended, and Sweden was quietly embarrassed and looked for a way to fix their predicament. And what's the most logical fix? … Well, it's not in the history books, that's for sure: Sweden opted to go back to the Julian calendar, by inserting a second leap day, [laughter], making for the one and only February 30th. They then carried on like that for another 40 years, before they got just ahead of Great Britain in making the switch in 1750. Maybe you didn't run into adoption stories of Python 3 like that, which means I envy you greatly. "Let's try to switch slowly! Our systems are clashing and they can't talk to each other?! Let's go back! Now let's try it again!"
Switching between complex systems is a thing humanity has needed to deal with for ages. I'm not saying that, if only the Python core team had studied absurd European history, they would have known how to handle the Python 3 transition – events sadly don't translate that cleanly. And to be fair, it also doesn't look like we're in for 500 years of Python 2 support, because we're finally sunsetting Python 2, and there's a very real chance of it not taking 300 years. But most things happen to us because we are messy complex chemically charged animals who don't really know what they are doing – and so, we form patterns in history, which tend to repeat. Of course, we can't know ahead of time which pattern is going to repeat, which is admittedly a problem. But history is filled with stories like these, and I think we'd do well to pay attention to that.
It's easy to point at funny examples of humans screwing up, so let me counter that with an example of humans getting it right. I want to give Sweden a chance at redemption: You see, Sweden was a bit of a special case with regards to traffic in Europe when people started driving cars (or what passed for cars at the time). They drove on the left (no idea where they got that terrible idea from [laughter]), but also had their steering wheels on the left. Using cars from mainland Europe made trade and imports much easier – but of course, those are not meant to drive on the left. While it makes your life easier as a delivery person, because you can just park and jump out of the car, it's also more dangerous: If you've ever driven a car on the side of the road it wasn't intended for, you'll know that it's a weird experience. Of course, they had more problems with their direction of driving than an island nation would have, theoretically, because Sweden shares a very long border with Norway. There even was a road that passed from Norway into Sweden and back again, with a special exemption to keep driving on the right.
So ever since the 30s, people floated the idea of switching the direction of travel to align with the surrounding countries. Of course, these ideas were suspended during the war, and then postponed a bit more, but in the 50s, people started to take an interest and to form committees. No committee is ever fast, so it took until the 60s until concrete plans were made. They held a referendum – and as you can imagine, everybody was strongly against the idea. Who in their right mind wants to spontaneously start driving on the other side of the road? The populace voted "no" with a stunning 85%, though admittedly with a fairly low 50% attendance rate. Naturally, they ignored the referendum result, and made the switch regardless. (Insert Brexit banter here.) Spoilers for the outcome: There were absolutely no spikes in accident rates due to that switch, and I want to examine how they did that, because that sounds unlikely at best. Changing a whole country, even in the 60s, when you had less traffic than today, to another system of driving seems like it would produce a huge amount of accidents.
They combined several approaches to make this work. First off, they figured out what they were dealing with: They tested people on their actual knowledge of the rules of the road, how competent they were at driving, and how they would react to driving on the other side. Which yielded totally surprising results, like: the better a driver you are, the better you cope with driving on the other side of the road. Which may sound obvious in hindsight, but it's important to check these assumptions! What if an experienced driver is so set in their ways that they can't cope with being on the other side, and newer drivers perform better? They also took this opportunity to introduce other traffic rules, which could get distributed to all drivers with the rest of the educational material – in particular, they introduced global speed limits and special rules for right-of-way.
Next, they set up practice areas on separate stretches of road for the people who would interact with people on the road the most (mostly the military and the police), so that they would be proficient by the time they switched. They had also learned from their 40-year calendar switch plan, and decided to … not do that, and instead switch on a single day. They spent an inordinate amount of time and money and effort to record training materials for the radio, the TV, written materials and instructions.
And took care of every small detail – for example, when selling new cars. Back in the day, cars just started having asymmetrical headlights. Your headlights are not exactly the same, because you want to look far ahead, but you don't want to blind oncoming traffic. So the outside headlight is a bit higher, and the inside headlight is just a bit lower – which would of course be problematic after changing the direction of traffic. Thankfully, they noticed this potential complication, and started adding a bit of masking tape to new cars, to avoid blinding oncoming traffic – with instructions to remove the tape when the day of the switch arrived.
All of this was a centralised effort: the training materials, the considerations about how to build and sell cars – they even had a logo! But then they deferred to more local, regional and decentralised processes by handing things over to local communities. They would distribute the educational materials, with door-to-door visits and at gas stations (because that's where everybody comes through!) They even distributed things like special drivers' gloves (because back in the day we were stylish and had drivers' gloves), where one was red and the other was green to remind people which side to drive on. They also had lessons available everywhere, and all of them available for free. There were six months of a strong information campaign. There even was a radio hit called "Keep right, Svenson" – it was a huge national effort.
On the big day, they had a ton of people on the ground. At night, 20,000 people unveiled new road signs on the right side of the road – because you expect your road signs on your driving side – and additional signs reminding people to drive on the right. Then there were nearly 10,000 people from the military and the police with cars and even some aircraft standing by, just being available to jump in and help. And even more impressively, 150,000 volunteers were around in cities and towns to guide pedestrians – because the planners were very aware that traffic includes pedestrians, who will be confused and in danger when cars suddenly come from the wrong side.
The actual switch happened at 10 to 5am on a Sunday morning, at a time when there were few people were on the road. Everybody had to stop, and then slowly and carefully drive to the other side or the road. There they waited until ten minutes were over, so that everybody had a chance to do so. There was a countdown on the radio, and then you were allowed to continue driving, slowly and carefully. And as spoilered above: there was no spike in accidents, and no accidents related to this at all.
We can take from this that careful planning coupled with actual research and active education can help you switch from one system to another that are nearly the same, but utterly incompatible, requiring a painful switch … am I repeating myself here? [laughter] My point is, we can take things from the past – especially things that refer to us humans being weird and complex and communication being hard. People in the software industry (and I mean this inclusively: we people in the software industry) somehow tend to think that we are the first to encounter things. This is maybe because we're working with a new medium – but not even everything you encounter on a computer screen is new. There are so many examples for this that it was hard to pick and choose!
For instance, the saying "The Internet does not forget" feels very much like an information age artifact at first glance. Well, first off, isn't true! If you ever tried to retrieve something that you saw twenty years ago on the Internet, you'll know that's nearly impossible, unless you get lucky. But also, consider that the Internet remembering forever is a horrifying concept! If the Internet does not forget, these huge amounts of misinformation on the Internet are like nuclear waste in their persistence and their potential danger down the road. Are we the first to deal with this problem, though? You know my answer!
My proof, this time, lies in the German language. It may be a pain to learn, but we can do one thing really well, and that's finding words describing concepts that you otherwise would have to explain in a whole sentence. One of those words is verballhornen. It means to take something and to garble it so that it's still vaguely recognisable and funny, but also unusable. The textbook example is how in the Latin Roman mass, the priest says "Hoc est corpus" – which subsequently got turned – verballhornt – into "Hocus pocus". Now, where does "verballhornen" come from? We're time-traveling again, but this time we're going back to the days of the Hanseatic League, a confederation of cities and merchants in Northern Europe around the Baltic Sea.
They had their own laws, and even their own army – they went to war with Denmark, and sure did not lose! They had different laws in different cities, but one important set of legislation was the Law of Lübeck, which was reused in nearly 100 other cities and towns. In the 1500s, German changed from something that sounds archaic to us to something that sounds basically like what we're speaking now. The change was fast enough that we needed translations from older works to newer works over a fairly short amount of time. The city of Lübeck decided to translate their laws, which was done and published by the city council. After printing the new version and distributing it to all those towns using the same laws though, it turned out that the translation was horrible. It was useless. Parts were wrong, parts were missing, it was obvious that something had gone very wrong. Maybe knowing what they were doing, the city council hadn't put their own names on the book. The only name to be found on the title page of the book was the name of the printer: Johann Balhorn. The poor man (and all his descendants, who still live in Germany) had done nothing wrong, and yet his name is a synonym for garbling words. So, yes: the Internet does not forget. But neither does humanity as a whole, and we've always been great at retaining misinformation, too.
Now sure, human memory gets things wrong, that's not new. But all this applies to other concepts, too! Here is another thing that sounds very technical: High-frequency trading. People are using the fact that computers are extremely fast and can make decisions on new information in times we can't even begin to blink at – to make money at the stock exchange. The faster you are, the higher are the chances that you can make a profit out of it. The speed we are talking about here is unique to our time, but the whole concept is very much an old hat:
When the telegraph was introduced, one of its first uses in France was to send messages faster than your competitors. A strange arms race started, to the point that they used typos in messages to convey coded information that only some people at the stock exchange would understand (and, of course, follow the advice to make profit). Things got even worse when the telegraph was adopted across Europe - and in particular, at the London stock exchange.
The London stock exchange and the London Telegraph Office were really close together: just 200 yards apart. People soon discovered that it could take a bit of time to send a message to the stock exchange, because all traffic within London was routed through the central telegraph office, which meant somebody had to transcribe it off the wire, route it to another wire, then put it on the wire again. It was faster to just take the message at the central telegraph office, and run over to the stock exchange. But of course, once somebody knew, soon everybody knew, and the (now literal!) race continued and let, in turn, to a pneumatic tube system being installed between those two locations. Pneumatic tubes are both faster than running and easier to monopolise, so this version got to stay for a long time – and incidentally gave us the first news ticker.
Or another example, a favourite of mine: One of the oldest building in Central Germany that is still standing is a castle in the middle of nowhere. We're not quite sure how old it is, but it's definitely older than a thousand years old. If you read the history of this castle, in the 1300s, the nearest city tried to take the castle. It's all very heroic and medieval, just as you'd expect: they besieged the castle for years and years, until they finally had to give up. So, fifty years later, they just bought. They acquired the castle. It's the definition of a hostile takeover, really. And this, again, is so present in the current startup world that it's easy to forget that this, too, is not a new concept. People don't change much, and as a result, our actions don't change that much, either.
Which is my point: most novel events are novel only at the surface, but not conceptually. (Which is not a new thought itself, of course: There were ancient Greek philosophers as well as the Bible telling us that there's nothing new under the sun.) Things of course do change, and there are new things, but we tend to overestimate how much of the things we encounter are actually new, and how much has been done before.
In recent years, there has been some reflection on this and adjacent thoughts in the software industry. In particular, people have highlighted the "Not Invented Here Syndrome": the pattern where people will write their own solutions to problems instead of using existing tools, because those are not quite a perfect fit. I know this very well: I wrote pretalx, which is used to submit talks to conferences (in fact, this one!), and then schedule them. It's not that there wasn't any other system around before that. It's not even that there wasn't any Open Source system around before, either. I used those, and I wasn't happy – and improving the existing tools was hard, both technically and socially.
As a community, we need discuss what we can and should do about that. Reimplementation has valid uses. For one, it's great for learning things. The Python Standard Library gives us tons of functionality that is tremendously useful – and much of it you find in old text books as regular teaching tasks. Determining if a string is contained in another string used to be an effort (or, more realistically, required you to include external libraries), whereas in Python, we don't have to think about what's going on, most of the time. And for production systems, you wouldn't consider reimplementing this substring check. But trying to implement it yourself to learn about it is an excellent idea: it might seem simple at first, but it really isn't. A lot of clever people have written a lot of clever papers about optimising substring checks. (And that's ignoring related problems, like counting repeated occurrences or regular expressions, which are absolutely terrifying! [laughter]) But even when we re-implement things to study and understand them, one of the best use of our time is to check other people's solutions, to learn from their approaches and to understand their tricks.
Another reason for implementing things again instead of using existing solutions is a matter of cost: finding and evaluating other solutions is not always worth it, and adapting existing solutions is even more costly. Take into account how ill-defined our requirements often are while looking for existing tools, and how problem complexity makes evaluation time soar – for every potential solution we're looking at! At which point is it not worth your time to look through other people's solutions, and just build your own? How does your answer change when taking into account future maintenance (either because you'll have to do it, or because you'll have to trust tool of choice to stay maintained?)
When people reinvent the wheel, it's never out of malice. It's also rarely out of ignorance. It's often because they have pain points that wouldn't be solved by other people's solutions – either because they'd be too expensive in time, effort or understanding, or for other reasons. Ignoring all this, and high-handedly telling people that their current project has "been done before" will rarely go well. It pays off to instead ask them if they have seen prior art for their project, and in which ways that doesn't fit the problem.
How can we deal with all this? In an ideal world I'd tell you to read all the books, consume all of human knowledge, and then you might (maybe!) know what to do. Sadly, our lives are constrained by time and space, and this doesn't seem like a practical solution. Resolving ourselves to imperfection, my best suggestion is to broaden your horizons. The more you know about parallels/prior art/previous experiences of people, the more you have even just vaguely heard of, and the more people around know and have heard of (provided you talk to them!), the more ability you will have to place those problems in a wider context.
In practical terms: Find a mediums of choice that work for you. For example, go to meetups and talk to people there. Or: Go to conferences like this one – talking to people here is as easy as it gets, because everybody is here to talk to you. Walking up to somebody and saying "Which talks did you see? What did you enjoy most" can be hard, but it's much easier than in most other places. Or: read blog posts! There are so many good blogs hidden in the Wild Internet. Ask people, again, for recommendations. And among blog posts, look into different styles: reference works, interactive posts, problem-oriented posts, etc. Or: Read books, if that's your thing – but don't forget that there's so much more out there. Or: There are podcasts that are tremendously helpful, because they can convey what people actually know and feel in terms of contextual knowledge (which is often lost in books). Or: There are video series, that lean more towards replicating a complete curriculum. Or: some people stream their coding on Twitch and talk about what they are doing, and they will happily answer your questions directly. And it doesn't stop there, of course – finding a medium that feels effortless to you isn't easy, but it's so worth it.
And that's just the medium! The more important part, that I really want you to consider, is to explicitly broaden your horizons in all directions, by communicating across professional and cultural boundaries.
For example: If you are, like me, a web developer, you'll have a preference for frontend or backend work – make a point of talking to people who prefer the other side. If you use Python for data science side: talk to the web people, whose face different problems, but whose solutions may be relevant to you in the future. If you work in the software industry, find out what a research software engineer does and is, to learn more about the academic side of things.
If you are part of the Python community, make sure to interact with other communities – the Rust community is a great example because they are really good at talking about their community governance and how they move their language forward in a way that people can work with them and join working groups. Off the top of my head, I wouldn't know what I would do if I wanted to get a new feature into Python – I know there are mailing lists involved, and PEPs (Python Enhancement Proposals), but that's the extent of my knowledge. The Rust community is very explicit in many ways, and very inviting, and they spend conscious effort and dialogue on their community management. The JavaScript community talks a lot about packaging (because they do a lot of packaging). We don't have to agree with how they do that, but it's definitely interesting to learn from their decisions, and from the problems they encountered as a result.
As a programmer, talk to the people you interface with, and try to understand their problems, struggles and solutions: talk to your manager, and your technical writers, to your office managers and your sales team. See if they have favourite blogs, podcasts, conferences, and so on – I attended the WriteTheDocs conference for technical writers recently, and found a huge payoff in just from learning basics and observing the general attitudes of the audience. And then, take one more step and do the same for people you currently have no overlap with – Civil engineering is fascinating! People in healthcare face unique challenges in their line of work which are interesting to us, if we only think to talk to them.
And it goes further than that: If you are a structured person, it is good and helpful to talk to creative people, because they think differently, and they come up with cool stuff, which will be super useful to you. And the other way around, if you are a creative person, it can be useful to talk to people who are structured, because it will give you different insights into the work you're doing.
Of course, the generalisation is: You should interact with generally people who are not just copies of yourself, with one or two minor differences. Talk to people from different backgrounds, upbringings, countries, continents, genders, and so on. If you make sure to broaden your horizons in these ways, you'll not only have a lot of contextual knowledge in your head, but also in your community to draw on, when you encounter a problem.
Wrapping up: history repeats its patterns, even though we can't know ahead of time which patterns are going to be repeated. But if we pay a bit of attention and talk to one another, and find out what has been done before, we focus even more on the aspects of our work that are actually new. Let's go and try that.
I gave this talk two years ago, and as is always the case, Past Me was not as well-informed as I would wish for. There were no major mistakes, but I took the liberty to correct some misconceptions in this version of the talk. In particular, I overstated the lack of general knowledge in medieval Europe: people were very aware of the shortcomings of the Julian calendar system even around the year 1100 and probably earlier, down to knowing how much the solar year shifted over time. It just took another 400 years for the Pope to decide to do something about it, and we would have been spared a lot of this sorry mess if he had done something just 100 years earlier.
Images were taken from the public domain uploads by the British Library on flickr. You can see the full slides with all the images and speaker notes here, where the images are also provided in much higher quality. Individual sources: