Note-Taking for Engineers: The System Matters Less Than Having One
I'm going to say something that might sound harsh but comes from a genuine place of wanting engineers to succeed: if you're asking the same question twice because you didn't write down the answer the first time, you're spending social capital that doesn't regenerate automatically. Senior and staff engineers have finite patience for repetition, and that patience correlates directly with how much they're willing to invest in your development going forward.
This isn't about intelligence. It's about systems. The engineers who grow fastest aren't the ones with the best memories. They're the ones who recognized early that memory is unreliable and built a capture system to compensate.
The Actual Problem
In infrastructure work, the information density is high. A 30-minute pairing session with a senior engineer might cover architecture decisions, environmental quirks, historical context about why something was built a certain way, and procedural steps for a specific workflow. That's a lot of information delivered conversationally, often without repetition, often while both people are looking at a terminal.
If you walk away from that session with nothing written down, you've retained maybe 40% of it by the next day and 15% by next week. That's not a personal failing. That's how human memory works under cognitive load. The fix isn't "try harder to remember." The fix is writing things down in real time so your future self has access to what your present self just learned.
The Medium Doesn't Matter
I want to be explicit about this because I've seen engineers get stuck on tooling choice and never actually start the practice: the specific tool you use for notes does not matter. What matters is that you use something consistently and can find what you wrote later.
| Tool | Works Well For | Watch Out For |
|---|---|---|
| OneNote | Visual thinkers, mixed media (screenshots + text), searchable | Can become disorganized without intentional structure |
| Physical notebook | People who retain better through handwriting, meeting contexts where laptops feel rude | Not searchable, not sharable, lost if the notebook is lost |
| Obsidian/Markdown | Engineers who think in linked concepts, version-control friendly | Over-engineering the system instead of using it |
| Excel/Sheets | Structured data (IP tables, environment mappings, comparison matrices) | Doesn't handle narrative context well |
| Plain text files in a repo | Minimalists, people who live in their terminal | Requires discipline to organize |
I've used most of these at different points in my career. Currently I lean toward structured digital notes, but I spent years with a physical notebook and it served me fine. The system that works is the system you'll actually use under time pressure, not the system that looks best in a productivity YouTube video.
What to Capture
Not everything said in a meeting or pairing session is worth writing down. The skill (which develops with practice) is identifying what's novel, non-obvious, or unlikely to be documented elsewhere. In my experience, the highest-value things to capture are:
The "why" behind decisions. The technical "what" is often documented in code or configs. The reasoning that led to that choice (why this approach over the alternatives, what constraints were active, what failed before) is almost never written anywhere and lives exclusively in the heads of the people who were there.
Environmental specifics. IP addresses, service account names, non-obvious file paths, the specific order of operations for a manual procedure. These are the details that feel memorable in the moment but evaporate within days.
Corrections to your mental model. When a senior engineer says "actually, it doesn't work that way, here's why," that's a gold-plated capture moment. Your incorrect assumption was plausible enough to hold, which means it'll come back if you don't explicitly record the correction.
The Leadership Angle
As a manager, I've started being direct about this in one-on-ones when I notice the pattern. If an engineer asks me the same thing twice, the first time is free. The second time, I'll answer, and then I'll ask: "Do you have a place to capture this so it's accessible next time?" Not punitively. Just as a nudge toward building the habit.
I've also started encouraging my team to take notes visibly during meetings and pairing sessions. Not because I'm monitoring their note-taking quality, but because the visible act of writing things down signals to the person teaching that their time investment is being respected and preserved. It changes the dynamic. A senior engineer explaining a complex system to someone who's actively capturing it will often slow down, offer more detail, and volunteer additional context they wouldn't have otherwise shared. The note-taking itself improves the quality of knowledge transfer.
The Compound Effect
The engineers on my team who've maintained consistent notes for a year or more have something the rest don't: a searchable history of everything they've learned, every decision they've participated in, every environment detail they've encountered. When a question comes up in an incident or a design review, they can reference their notes rather than relying on recall or re-asking (the personal equivalent of making work visible at the team level). That capability compounds. It makes them faster, more reliable, and more independent over time, which is ultimately what growing engineers looks like in practice.
The investment is small: a few minutes per meeting, a brief capture after each pairing session, a habit of writing down what surprised you today. The return is a personal knowledge base that grows with your career and makes every subsequent year more efficient than the last. Start now. The medium doesn't matter. Just start.