During my undergraduate studies in the mathematics department at Sharif University, there was a math professor who emphatically urged us to practice good writing. She advised that if we spent one hour solving a problem, it was reasonable to invest an additional two hours in crafting a well-structured proof. I recall her words: “If you aspire to be a mathematician, you need to be a proficient writer as well as a skilled problem solver. Without the ability to write effectively, you cannot communicate effectively in the world of mathematics. Generating new ideas and solving problems is valuable, but only if you can articulate and preserve them.” Remember, you can now read what Fermat wrote, but not what he was thinking!1
In high school, I enrolled in a web development course taught by a school graduate who was a self-proclaimed nerd at the time. He consistently emphasized, “Technology is always lagging behind Science! As time passes, we can explain how things happen better over time, but progress in constructing things is another challenge.” I sought to explore one reason why technology often lags: writing. Consider a good airplane developed in the ’80s that has since been discontinued. It is almost impossible to produce the exact same plane with that quality. Numerous design decisions and technical details made during the creation of the Airbus are now lost since the team disbanded. Because most ideas were conveyed verbally, and even by reading the papers they left behind, we still cannot precisely discern their process. Numerous design decisions, technical details, and assumptions made during the creation of the Airbus are unknown to us today. In short, progress is not well documented in the industry as in academia. Not being able to recreate the exact same plane leads us to this question: Are subsequent airplanes really superior in every aspect? The thing is that many industrial achievements become obsolete when the teams behind them disband. When the working team leaves a project, the project dies, and it is really hard to recover the project.
Four years ago, I worked for a company developing maps and a navigation app. Despite the product’s quality, the company closed after three years due to financial issues. Now, the source code has been open-sourced, but without the original development team, it has diminished value. You cannot recreate that product solely with the source codes. Many discussions and agreements among people involved are undocumented. I want to emphasize that documentation in the industry is not as thorough as in academia, and most documents are insufficient for reproducing results without the involvement of the original authors.
There have been revolutionary accomplishments in computer science where designers had constraints and ideas in mind to create incredible software: ALGOL 58, UNIX, C, Go… It is truly fascinating to delve into the thoughts of these designers when creating these tools. It is good for all programmers to read these to really stand on the shoulders of giants.
Here are some links that I find captivating:
- Unix Philosophy
- Go is the most recent and very well documented. Reading Go proposals provides insight into how adept designers shaped history.
- Reflections on Trusting Trust, Ken Thompson’s ACM award lecture. ALso read this post by Ross Cox.
- Process of designing Algol by a team of excellent computer scientists.
- Generally reading about history of programming languages. This is a short nice genealogical tree.
- Dennis Ritchie works in Bell labs. It is nice to read about how Ritchies’s thesis was produced and how it was lost for years.
- Read more about Fermat’s Last Theorem. ↩︎