Professional work shifted from history to backend engineering, driven by interest in problem-solving and design. The work environment often involves legacy code with few written explanations of what components do or why they were built that way. Documentation may exist as outdated design notes, incomplete wiki pages, or code comments that mainly warn against changes. As a result, engineers face more questions than answers and must seek guidance from other developers. Experience as a historian supports this process by training reconstruction from fragments rather than relying on neat records. Collaboration becomes essential for understanding and safely making changes in unfamiliar systems.
"Software development is an oral tradition. Especially when you're just starting out as an engineer, you're not working on brand-new code; you're probably in a legacy code base. You're going to face more questions than answers about what stuff does or why it was written the way that it was, and when you go looking for answers, there's not going to be much written down. Perhaps there's an early design doc, but then it turns out that everything was substantially revised before work began. Maybe there are a few wiki pages explaining known issues, some of which were solved a long time ago and others that have been left to molder in the codebase."
"Somebody might have left a comment in the code itself, but typically it's a warning not to change something or else something else will break. At this level, being a historian turned out to be an unexpected cultural advantage. Historians are used to reconstructing stories from fragments rather than finding neat explanations in the archive. So when it comes time to make a change in an unfamiliar codebase, you usually wind up finding another developer to ask for help."
"They've been there long enough to understand what's happening under the hood, and they might be able to explain why changing one seemingl"
Read at Fast Company
Unable to calculate read time
Collection
[
|
...
]