legacy

New projects are rad, but for new to exist we must deal with old. These are some notes on how to deal with the old.

notes

Create a notes directory. Notes are indispensable as it will prevent you from asking the same questions over and over. Not only does it provide head space, it also makes you more attentive than 95% of all other people attending. Don't sweat getting all details though, just make sure the broad picture is annotated. I generally like starting out with the following sections:

• README.md - introduction what you're annotating
• Terminology - terminology used by the company; writing down terms as you encounter them will allow you to streamline the process for them, as chances are large that common terminology is not up to snuff. Don't be a dick about terminology though, understanding is more important than correcting.

multi-service architecture

When working with a large company chances are that there are many moving parts to an application. It's impossible to comprehend what's all going on, so just annotate as you go. Pierce through acronyms and find out what the parts do. By writing it down from the get-go you'll have the knowledge later when you need it.

An important focus of architecture is to get the broad strokes, figure out which services talk to what other services. Also find out which services are within your scope, and which you can't do anything about. This will make your life easier.