What is historical thinking and how does it help me to be a better programmer
Sometimes I am asked how I managed to transition from the humanities field and immerse myself in such a seemingly distinct area like programming. The short answer is: “believe it or not, many skills required to be a historian are equally valuable in programming.”
I admit that this answer raises more questions than it answers, so here’s this article to explore the bridge between what most people in both fields see as two islands of knowledge. I believe this confusion originates from the association people make between a history degree and teaching; the research aspect of history is not very visible to those on the outside.
For those who don’t know me, my name is Igor. I’m a developer today, but before that, I graduated with a bachelor’s and teaching degree in History. In the following lines, I will share what I felt during my career transition and what I observe daily regarding research, communication, and a concept called historical thinking, and how each competence interacts in a mental model that can be replicated in both fields.
Soft Skills?
A term that is always in vogue in the tech industry is that of soft skills, which we could define as non-technical skills that make our work more organized and productive, in addition to facilitating our interaction and teamwork. This term hasn’t (as far as I’m aware) infected historians, and one reason for this, it seems, is that some things considered soft skills for developers are hard skills for historical research.
Below, I will discuss the translation of each mental model skill and its general application to both areas. Let’s start with one that is on the borderline between hard and soft skills for programmers but is indispensable for any self-respecting historian.
Research
The ability to research — understood as efficiently extracting information, substantiating arguments, and/or solidifying knowledge — is important for any developer but crucial for a historian.
We can express it like this: while an experienced developer, mastering the language and the problem, can deliver a reasonable product without new research, for a historian, this is impossible. A (good) historical work requires piles and piles of research, engaging with various perspectives on the same subject before writing about your own. Throughout this process, a good historian will internally list (in their mind or in their notes) the possible paths their research can take.
I take this opportunity to remind you that, since most programmers don’t work on already solved projects, research becomes a very important part of this area too. Often, we need to learn more about how our systems work under the hood to solve unusual problems, or, when we are early in our careers or have recently embarked on a new project, it makes a big difference to learn how everything works.
The main complaint about junior professionals comes from those who don’t have the autonomy to research and try to solve problems before asking for help. This is the reason that leads me to understand this as a skill on the border between hard and soft skills for programmers.
Communication
I will classify communication here as the set of two related but distinct competencies: verbal communication and written communication. Let’s assume the first as the competence used when conversing synchronously with peers and leadership, while the second is used in asynchronous communications (for developers: emails, Slack messages, documentation writing, etc.).
For those immersed in the world of technology, the idea of improving communication is widely discussed. To be honest, this skill is seen as the epitome of soft skills, except, in certain perspectives, when applied to writing documentation, a skill whose value varies according to the environment.
For whatever reason, there is the cliché of the “antisocial programmer” who only thinks in code, not knowing how to coexist, let alone talk to other human beings. It may have been real at some point, but today it’s nonsense. The vast majority of projects today are developed in teams, so the ability to communicate is no longer optional. Still, it is not something prioritized either by individuals when studying to enter the field or by educational institutions when training people.
Good communication is more than a word matching game. It is the ability to minimize the gap between what is said by one party and what is understood by the other. Contrary to what is done in the technology field, in the training of historians, communication has the highest possible priority. In addition to written exams, other common assessments are seminars and monographs, which explore the student’s ability to communicate ideas both verbally and in writing in a clear and well-founded manner. And, of course, for an individual who graduates and works with research, these skills continue to be part of daily life.
Historical Thinking
With these two admittedly more common concepts out of the way, I want to turn to what will be a new notion for most of those reading this article and even inspires its title. After all, what is historical thinking? And how on Earth can a concept from the humanities help anyone to program? My point of view may come as a surprise: I think good developers instinctively develop historical thinking. To explain why I think so, I will explain what I understand by this idea and how it applies in the field of History.
I must be transparent and say that there is no single universal concept of what historical thinking could be. However, I can bring the concept that has been ingrained in me, which would be as follows: the ability to organize a series of events chronologically, relating them in various layers from that. For the historian, historical thinking is a soft skill that prevents them from falling into contradictions caused by anachronisms (the equivalent of dividing by zero in this field).
Every historical research seeks to answer some question. To answer it, a historian will interpret the knowledge they have of events in that historical moment, establishing relationships between these events. Event A may have a direct influence on event B, which in turn indirectly influenced event C. The ability to abstract this timeline is indispensable for a valid reading and interpretation in this research.
A developer who reads the previous paragraph may not understand how this applies to them. Let’s abstract this skill again, now from what I see as the perspective of a good developer. Every program generates, in its compilation or execution, a timeline. A good developer has the ability to understand how each event that forms this timeline interacts with each other. The only difference is: we programmers have some degree of control over how this timeline will be formed.
Consider for a moment what our most common techniques for debugging code are: breakpoints in a debugger or print statements and the like. In general, we try to understand how what we write is being interpreted, by which paths the code passes, and by which it needs to pass for the logic we are targeting to materialize.
In general, a good ability of historical thinking will translate, for a developer, into more efficient debugging, as well as greater ease in architecting complex solutions, because they can think ahead of the journey that the program — or a user — will undertake.
Mental Model
In this section, let’s briefly explore what the mental model I referred to in the article introduction is. Thinking of a historian’s workflow: assuming there is already a question that needs to be answered, they will need to research — discover sources, statistics, read works by other historians on the same subject — before writing. When writing, they will need the critique of a supervisor or their peers to improve the work. Receiving this feedback, they return to research and writing. This cycle repeats until the completion of this work. Historical thinking will be applied in the research and writing stage, ensuring the validity of what is being developed.
Mental Model — Historian
Analysis → Research → Writing → Feedback → Research/Writing (…) → Completion
Comparatively, a developer may have a very similar workflow when developing a feature. Knowing the current state of the system and what the desired state is, they will think about how to move from one state to another, leveraging the knowledge they have about the existing solution to think about the best way to adapt it. You could think of it like this (and already applying historical thinking): which moment in the system’s timeline needs to be altered?
Once the solution is drawn, we move on to writing the code, which will later undergo code review in most companies. Throughout the writing process, the programmer may need to research various information, whether language syntax or solutions to common problems. Depending on the scope of the change, this process may be finished here or repeated.
Mental Model — Developer
Analysis → Writing/Research→ Feedback → Writing/Research (…) → Completion
Conclusion
I wrote this text to make it clear why I think there is a closer relationship than most people believe between the humanities and software development. At least, an intersection large enough that the barrier between them is not insurmountable.
With all of that said, I want to make it clear that it is not my intention to say that anyone from one area can easily enter the other. I believe each area of knowledge has a high degree of value to contribute to society; many still need to recognize that.
So, thank you for reading. If you have any comments or suggestions, feel free to post them below, in the comments. And before I go, I leave you with a question: what is your mental model when approaching a problem?
Thanks!
