Tips for someone with poor working memory?

Hey! Thanks for the question.

I'm sorry to hear you don't feel on-par with some of your colleagues in terms of this. However, it's not the worst thing. I don't have a great memory either.

So here's my solution to this: Take great notes!

I'm a fan of Notion but I use OneNote at work because it's what my company approves. Be diligent in writing down all the important information. Tag them so you can easily find and recall them.

If you're feeling dazed and confused, consult your notes. Have the wisdom to realize to write it down immediately, no matter how small. That's how I would start.

Additionally, most of these engineers have probably been there longer than you have, so they have a lot more context and have probably gone through it a few times.

Good luck!

As Xue mentioned, the solution is to write stuff down. The good news is that so much of software engineering has organic avenues to do this:

• Create detailed PRs - Make it so that whenever you blame a block of code, you can find a beautiful log of code reviews chock full of product context, implementation strategy, and test plan videos to help you understand it fast. Here's a good video to get started learning this: What A Test Plan Is And Why Every Code Review Needs One
• Write system design docs - System design helps you build better systems, but it also generates a high-quality artifact that you and everyone else on the team can use to quickly ramp up on how a specific product works - Super helpful to prevent people from getting lost in meetings! Check out my system design series to learn how to make an amazing one: System Design Masterclass: Taro Playlists
• "Javadoc" every file - At Meta, we were forced to have a top-level comment on every file explaining what it does at a high-level. I often combo-ed this with the prior point by linking the relevant system design doc (if applicable) in these comments. This is another way to make code super easy to understand. You can find an example of a class-level Javadoc here: Javadoc at Class Level
• Comment very complicated code-blocks - Ideally code is readable on its own with clean naming and abstractions, but sometimes you just need to write a spaghetti hack to make things work. In this case, I recommend writing a few sentences at least breaking things down and linking relevant resources like StackOverflow posts.
• Take meeting notes - Moving outside of the code realm, this is something I see so many engineers forget to do even though it can easily boost your productivity by 50%+, especially if you're a senior engineer with a ton of meetings. Well-written meeting notes let you quickly "download" all the necessary context to participate in a meeting, especially if the agenda is written into the doc beforehand. I recommend this video to learn more about this: Easily Level Up All Your Meetings By Taking Notes

In a nutshell, make it so that whenever you come into contact with anything (e.g. new code, old code, team tech review meeting, product discussion), there is a great chance there's some handy artifact attached to it that you can look at to quickly ramp up your understanding.

Depth of memory is a natural talent, but I 100% believe that it's something where a lack of it can be overcome with hard work and diligence 💪

I find that the top skill for staying organized is categorizing the information you're managing on behalf of your working memory.

What categories work for your needs & your brain is going to be different from other people's and they're going to change.

You're probably going to start off with categories that don't work for your needs. It's okay! Treat it like code:

1. You're capable of improving your skills.
2. Reiterating is necessary to see incremental progress.

Categorizing actual notes is great, but categorizing information mentally as you take it in is also helpful because it creates associations for long-term memory storage & retrieval.

So, how do you get better at identifying what categories work best for you?

• Meet yourself where you are. Recognize your strengths as well as your gaps. Over time, you'll get better at figuring out what you need to accommodate yourself.
  
  The goal isn't to turn yourself into someone you're not. Maybe you'll never be able to memorize context for each part of a system (or maybe you will!), but for right now you can create a system where you store the info you need to 1. jog your memory (retrieval from long-term memory to working memory) and 2. easily find that info again (manual retrieval). If your categories aren't working for either of those functions, then they're not working & you can create better ones. Nothing is wrong with you.
  
  For example, I compensate by building & relying on my understanding of bare concepts & my ability to transfer them across different contexts. The flip side is I know I need to 1. communicate those bare concepts upfront to build trust, and 2. utilize those bare concepts as a building block to keep track of details for each project or system.
• Document & review to find commonalities. It can be similarities between the knowledge the senior engineers have, similarities between the type of information you find new or confusing, or similarities between the types of situation that cause you the most confusion. Similarities are why categories work.
  
  For example, you mentioned senior engineers have an easier time grasping mental models. Do any of these models share similarities? I can guarantee you they do and that they can be distilled down to some core tenets. Are these mental models usually reflections of design patterns, business use cases, or something else? Try not to focus so much on some objective perfect truth, but rather on what would help you make sense of things in a repetitive fashion.
• Address your inner monologue. What comes up mentally during these working sessions with senior engineers? What comes up internally when you run into blockers that lead up to asking senior engineers for help? When we see others grasping things more quickly or more easily, those comparisons can be easy way for our inner self-talk to become concentrated on self-doubt.
  
  If there's a lot of internal chatter, that drain on your executive functioning can get in the way of you asking & answering self-learning questions like, "If I were in this senior's shoes, how would I have arrived to this understanding using what I have in front of me? What would that exploration look like for me?"
  
  You can ask them how they arrived to their understanding (& I encourage you to!), but I find that not everyone is good at recognizing all the steps they take in their own self-learning. Things can come a lot more naturally to some people than to others, which is just a part of having different brains that have different needs.
  
  I can, however, guarantee that you yourself have asked & answered these types of questions before in different, less overwhelming contexts if you've gotten to the point of becoming a mid-level engineer. You've been able to learn before & you can do it again! How can you transfer your past learning habits to this new situation of learning to be like a senior engineer who works on system-wide problems?
• Set reasonable expectations for your categorization system.* Whether it's what you're trying to achieve or how long it will take to create or tweak your system, make sure not to fall into perfectionism.
  
  A lot of workplaces will be willing to let you take some time out of your workweek to organize your notes, but when you're just figuring it out, you might need to take some personal time for reflection & organization.
  
  When you say seniors are "managing to remember a lot of context", is it context you should reasonably know? Is it context that you've been working in for a long time, or have been told multiple times before, or can easily figure out? Or do they just have a lot of experience that means they have built muscle memory over the YOE that we don't have? I find both things are usually true to some extent! So sometimes we just have to remember that more senior folks are there to know a lot of things we wouldn't know! :)

Hot take: my bad memory is a gift and it is for you too.

The reason is it focuses my learning on understanding fundamental principles, not memorization. That being said, take notes, create docs, and give yourself time to see things a few times. But ultimately it is NOT about having a lot of stuff memorized.

Example: Leet code

Someone with amazing memory might memorize 5000 problems and solutions and in the interview have amazing recall to pull up the right solution. Alternatively my strategy is to deeply understand the way 5 data structures and 5 algorithms are built and run.

Example: Learning a new code base

Its tempting to read every line of code and try to understand it. But on your team if there are 100 features they may still fall into three types. Then you need to know how each of the 3 types works and then you can see something new of that type and also quickly understand.

Example: Learning to be a manager

I was tempted to memorize and run by my manager a solution for every scenario I faced. I was overwhelmed and hesitant. Instead what worked is learning about what I value and should value as a manager: empathy, communicating (especially the bad), removing blockers, creating trust/trusting my team, and giving each person what they need.

Now I can solve thousands of scenarios (including new ones) by remembering a few principles.