Code archeology. A study of how the code got to its present state.

What happened in your team’s code last year? Why was a feature built? What where people thinking at that time? How do other people do the kind of thing I want to do? What’s the industry standard for working with a certain library?

Being comfortable with code archeology is a super power. This post will provide an overview of some strategies I’ve learned along the way.

Go exploring without a goal

First up, don’t be afraid to go exploring without a goal in mind. If you work at a big company, chances are there will be an awesome wealth of history to dig through. This is a great way to learn your companies project management stacks.

Shopify had custom built wiki software that meshed with stakeholder management/project management software. This combined with a public, dynamic org chart allowed anyone to see what projects someone was currently working on, had worked on in the past, and dig into those projects to see how the project developed over time.

They also recorded many meetings, town halls and AMA’s. Searching this history is neat.

If you don’t work at a big company, go explore the open source world. Have a favourite project you like to follow? Chances are it’s developed in the open. Go checkout the code at the time a certain feature was released. What issues happened after launch? How was the feature released? How did it come about?

Here are some neat ones:

• Two developers compete to improve hash map performance in Ruby
• The Readme from the first public release of React
  • It’s kinda wild that they used jekyll and depended on Ruby for their initial documentation site

Master code search

What better way to learn how to implement something new to you than by studying how others have done it? Tips:

• Learn some regex. This is especially useful if your company has a company-wide code indexer setup allowing you to search all of its code via regex.
• Use github’s advanced search
  • Imagine what you would type when filling out an issue: implement simple authentication language:TypeScript
• Use your company’s code search
  • Work at a big company? Chances are they have a lighting fast, regex capable company wide code search just ready for you to use. I used to use this judiciously every time I encountered something new. My flow would go like this:

Use AI

Want to parse a lot of information from the above? GPT-4’s new larger context window makes this extra fun. Dump all the data you’d like into an AI chat bot and ask questions about it. Could you imagine a world where your entire company’s code is searchable via embeddings, enabling contextual queries… ‘whistles’.

Talk to humans

Find someone who has done something you want to do at your company? They Still work here? Ask them for help. It’s common for developers to be hesitant to do this. Remember that the more senior the person you are talking to is, the larger a part of their job it is to empower others. Similarly, the more junior a person is, the more chances they have a less ridged schedule and can often jump on a call to the same day to point you in the right direction. Just do some of these other strategies first to make sure you know what you don’t know.

Why?

With a little elbow grease, you can quickly discover not just what the code looked like last year, but gain insight into what the team was thinking, what bugs existed, what experiments did they try before deciding what to build? What did the prototype look like? How much time did they have to ship? Learn from history, or be doomed to repeat it’s failures 🙂.