Keep a Learning Log That Actually Helps

Why Bookmarks Fail and Logs Succeed

You find a great article on prompt engineering. You bookmark it. Six months later, you've bookmarked 200 articles. You search for "prompt engineering" and find 12 links you half-remember. You don't know what each taught you. The bookmarks cost nothing and deliver almost nothing.

A learning log is different. It's a record of what you learned and what you still don't know, written in your own words at the moment you learned it. It takes 3 minutes per entry. Over a month, 12 entries become a personal reference—useful for interviews, for spotting patterns in your learning, and for spaced repetition.

Most people skip it because it feels like extra work. But it's not extra work; it's replacing vague, forgotten learning with retained, indexed learning.

Bookmarks vs. Learning Log: Real Comparison

| Metric | Bookmarks | Learning Log | |--------|-----------|--------------| | Time to create | 10 seconds | 3–5 minutes | | Searchability | By URL/title only | By keyword, date, topic, question | | Retention 1 month later | ~20% (can't recall content) | ~80% (can recall and explain) | | Usefulness in interview | "I read about transformers" (weak) | "I studied fine-tuning vs prompting, here's the tradeoff" (strong) | | Evidence of learning | No | Yes | | Can reference for projects | Weak (forgot why you bookmarked it) | Strong (documented your reasoning) | | Compounding value over 6 months | 0x (bookmarks are static) | 10x (logs form a personal curriculum) |

Example: You learn about LoRA (low-rank adaptation). Six months later:

• Bookmark approach: "Oh, I bookmarked something on LoRA. searches Found 3 LoRA articles. I don't remember which was best or what I learned."
• Log approach: "I logged LoRA on 2026-03-15. It said 'trades 2% accuracy for 90% fewer parameters.' I noted 'useful for multi-user fine-tuning.' That's exactly what I need for my current project."

The log saves you weeks of re-learning.

The Anatomy of a Good Log Entry

A good entry has five parts:

1. Date and source. When did you learn this? What was the source? "2026-07-20, LLM Bootcamp course, Week 3: Fine-tuning." This makes your log searchable and forces you to credit sources.

2. One-sentence takeaway. What's the idea in one sentence? "Fine-tuning on a small dataset (500 examples) with low learning rate (1e-5) often outperforms prompt engineering for domain-specific tasks." Not a summary of the entire lesson—the one thing you're taking away.

3. Why it matters to you (optional but useful). One sentence on relevance. "I'm building a medical chatbot, so understanding when to fine-tune vs prompt-engineer is directly useful." This helps you remember why the idea was important, not just what it is.

4. One question you still have. "What learning rate is right for a 10K-example dataset? The course only covered 100 to 10K examples." This question becomes your next study prompt. It's the gap the Feynman Technique would surface.

5. An artifact or output. What did you produce while learning? "Implemented a fine-tuning script (linked) and compared on a toy medical dataset." This is evidence. In interviews, "I read about fine-tuning" is weak; "I implemented fine-tuning and compared loss curves between 1e-4 and 1e-5 learning rates" is strong.

A Template

Date: YYYY-MM-DD
Source: [Title, Link, Author]
Duration: X minutes

Takeaway: [One sentence with the core insight]

Why it matters: [One sentence on relevance to you]

Artifact: [Link to code, notebook, or written explanation you produced]

Question: [What don't you understand yet?]

Here's a concrete example:

Date: 2026-07-15
Source: Papers with Code, "LoRA: Low-Rank Adaptation of Large Language Models"
Duration: 45 minutes (skim + implement)

Takeaway: Instead of fine-tuning all weights, you fine-tune low-rank decompositions (A and B matrices), reducing parameters from 7B to 1M while matching accuracy within 1%.

Why it matters: I'm building a system that fine-tunes models for 100+ customers. Memory efficiency and cost directly determine feasibility.

Artifact: Implemented LoRA from scratch in 120 lines of PyTorch (repo link), compared memory usage and loss curves to full fine-tuning on a 5K-example dataset.

Question: How does LoRA degrade on very small datasets (<100 examples)? Does rank selection matter more when data is scarce?

This entry takes 5 minutes to write. It's now indexed by date, searchable by keyword, and useful for:

• Spaced repetition: Turn the question into an Anki card.
• Portfolio: Reference this entry when explaining your technical choices in interviews.
• Project decisions: Six months later, you're choosing fine-tuning vs LoRA vs prompting. You've got a log entry with cost/accuracy tradeoffs you measured yourself.

Building a Weekly Review Habit

The log is only useful if you revisit it. Weekly review (15–30 minutes) turns scattered entries into actionable patterns.

Weekly Review Process (25 minutes)

Step 1: Read the week's entries (5–10 minutes).

• Read each log entry from the past 7 days
• Ask: Did I actually use this knowledge? Is my question answered?
• Mark entries that were particularly useful or unanswered

Step 2: Spot patterns (5 minutes).

• Did you log 3+ entries on the same topic? That's your "theme for the week"
• Did you ask a question that's still unanswered after 2 weeks? Prioritize studying it
• Are entries from different weeks connecting? (e.g., "Entry on LoRA" + "Entry on memory efficiency" = "LoRA for low-memory fine-tuning")

Step 3: Plan next week (5 minutes).

• Count topics: 5 on LLMs, 2 on vision, 1 on RL. Are you balanced or drifting?
• Questions: logged 8 questions, answered 2. This week, answer 3 before adding new.
• Pick 1 unanswered question as this week's deep dive

Step 4: Review for spaced repetition (5 minutes).

• Find entries from 4 weeks ago. Are you still remembering them?
• If not, convert the most important ones into Anki cards

Weekly Review Template

# Weekly Learning Review

**Week of**: [Date]

## Entries This Week
[ ] Entry 1: [Topic] – Status: [Resolved/Pending]
[ ] Entry 2: [Topic] – Status: [Resolved/Pending]
[ ] Entry 3: [Topic] – Status: [Resolved/Pending]

## Patterns Noticed
- Topic distribution: LLMs (60%), Vision (30%), Other (10%)
- Unanswered questions: [List]
- Cross-entry connections: [If any]

## Deep Dive for Next Week
Question to answer: [Pick 1 pending question]
Time budget: [2–4 hours]
Resources: [Paper? Tutorial? Project?]

## Learning Pace Check
- New entries: [Count] per week (sustainable if <4)
- Questions/entry: [Count] (should be 1–2)
- Artifacts: [Count] (should be >50% of entries)

## Confidence Check
Topics I'm confident on: [List]
Topics I'm still weak on: [List – prioritize these next month]

This 25-minute weekly review is where the log becomes a study tool and career compass, not just a diary.

Learning Log vs. Other Organizational Methods

If you're deciding between different logging systems, here's a comparison:

| Method | Setup Time | Maintenance | Searchability | Retention | Interview Value | |--------|-----------|-------------|---------------|-----------|-----------------| | Scattered notes | 0 min | None (chaos) | Poor | 20% | None ("I read stuff") | | Bookmark folder | 2 min/entry | None (dead) | Medium (by title) | 10% | Weak ("bookmarked it") | | Simple markdown files | 3 min/entry | Grep to search | Medium | 60% | Medium (proof of learning) | | Spreadsheet (CSV) | 3 min/entry | Sort/filter | Medium (columns only) | 65% | Medium | | Notion / Obsidian | 5 min/entry + setup | Linked search | Excellent | 75% | Excellent (sharable) | | This guide's template | 3 min/entry | 25 min/week review | Medium (tags, grep) | 80% | Strong (artifacts + narrative) |

Recommendation: Start simple (markdown files). Graduate to Notion or Obsidian if you outgrow it (100+ entries). Don't let tool choice paralyze you; consistency matters more than the tool.

Using Your Log for Interviews and Portfolio

When you interview or build a portfolio, your log is evidence.

Interview scenario: "Tell us about a time you learned something complex."

Weak answer: "I took a course on transformers."

Strong answer (backed by your log): "I learned about sparse attention from this paper [link]. I implemented it in PyTorch and compared training time and memory usage against dense attention on CIFAR-10. I discovered that sparse attention with a fixed block pattern generalizes worse on small datasets, which surprised me. I then read [another paper] to understand why, and I logged my findings here [link]. I would apply this learning by choosing dense attention for small datasets and sparse attention when I have 100K+ examples."

Your log is the bridge between "I studied something" and "I understand something deeply enough to explain it and apply it."

Anatomy of a Month-Long Log

Over one month, assume you do 2–3 entries per week. Here's what emerges:

Week 1:

• Entry 1: Attention mechanisms (course)
• Entry 2: Positional encoding (paper)
• Entry 3: Transformers overview (tutorial)

Week 2:

• Entry 4: Multi-head attention implementation
• Entry 5: Comparing absolute vs relative positional encoding
• Entry 6: LoRA fine-tuning

Week 3:

• Entry 7: Prompt engineering strategies
• Entry 8: RAG vs fine-tuning comparison (this answers a question from Week 1)
• Entry 9: Mixture of Experts (new topic)

Week 4:

• Entry 10: Implementing inference optimization (LoRA + quantization)
• Entry 11: A bug you fixed (artifact: the fix and explanation)
• Entry 12: Interview prep (linking entries 1–10 into a narrative)

After 4 weeks, you've got 12 entries. When you revisit, you see:

• You went deep on transformers and fine-tuning
• You asked 12 questions; you answered 8
• You've got 4 artifacts (implementations, comparisons, bug fixes)
• You can now tell a coherent story: "I learned transformers, then applied them to fine-tuning, then optimized for inference."

This narrative is what hiring managers and interviewers are looking for. Your log is proof.

Common Structures

Different learners prefer different structures. Here are three:

Markdown file per date (simplest):

2026-07-15-lora.md
2026-07-20-rag.md
2026-07-25-prompting.md

Grep or search your logs locally. Works great if you don't have many entries (<100).

Spreadsheet (for quick lookup): Columns: Date | Topic | Takeaway | Question | Artifact Link Sorts and filters easily. Scales to 200+ entries before getting unwieldy.

Note-taking system (Obsidian, Notion, etc.): Bidirectional links let you connect entry about "fine-tuning" to entry about "LoRA" automatically. Scales well; more setup overhead. Use if you like that style.

Choose whichever you'll actually use. A consistently-maintained markdown file beats an abandoned Notion vault.

When to Log and When to Skip

Don't log everything you learn.

Log if:

• You spent >30 minutes learning it
• You built something (code, notes, explanation)
• You're likely to need it again
• You're unsure about something and you want to flag the gap

Skip if:

• It's a 5-minute answer to a quick question
• It's part of a larger project you're logging separately
• You understood it completely and have no remaining questions
• It's not relevant to your goals

A typical learner logs 2–4 entries per week. More than that and the log becomes a burden. Fewer than that and you're losing useful documentation.

Log Entry Checklist

Use this to ensure your entries are high-value:

# Learning Log Entry Quality Checklist

For each entry, before saving, ask:

[ ] Source documented? (Title, link, author, date)
[ ] Takeaway is one sentence? (Not a paragraph)
[ ] Why it matters to YOU? (Relevance stated)
[ ] Question that's still open? (Gap identified)
[ ] Artifact created? (Code/notes/explanation)
[ ] Is it searchable? (Can you find it by keyword in 3 months?)

Score: ___/6 (4+ is good, 6 is excellent)

If score < 4: Expand the entry or skip logging this one.
If you can't answer "Why it matters": Skip it (not relevant to your goals).
If you can't identify a question: The learning was too shallow; go deeper.

High-quality entries are:

• Concise: 3–5 minutes to write
• Specific: Not "learned transformers"; "learned attention uses Q/K/V projections"
• Actionable: Next person (or future you) can understand and apply it
• Complete: Source, takeaway, question, artifact all present

Four-Week Cycle: Using Your Log to Adjust Course

Every four weeks (on the Feynman Learning Path cycle), review your entire month of logs and adjust.

Questions to ask:

1. Am I going too deep or too broad? Count entries by topic. If 80% are transformers and 10% are vision, you're going deep. Is that intentional? If you wanted 50/50, adjust next month.

2. Am I answering my own questions? Count questions logged vs questions answered. If you answer <50%, you're moving too fast and not consolidating. Slow down.

3. What's missing? Look at topics you didn't log about. Was there a skill you needed (like "how to debug a model") that you learned but didn't log? Add it to the log retroactively.

4. What do I want to go deeper on? Which artifact was most useful? Which question is still bugging you? Make that your focus for next month.

Your log becomes a self-feedback mechanism. It tells you what you're actually learning (vs what you think you're learning) and what you should focus on next.

Interview Prep: Mining Your Log

Three months into keeping a log, you have ~30 entries. Each entry is a story waiting to be told.

In an interview, when asked "Tell us about a project where you learned something new," don't say "I took a course on LLMs." Instead:

"I reproduced LoRA from a paper. I built it in PyTorch (artifact: code repo), compared it to full fine-tuning on a 5K-example medical dataset, and found that LoRA used 90% less memory while matching 99% of accuracy. That taught me the memory/accuracy tradeoff. The gap in my original understanding was learning rate—I initially used the same learning rate as fine-tuning and got worse results. I discovered via grid search that LoRA needs 10× lower learning rate, which I documented in my log. That insight shaped how I approach hyperparameter tuning now."

That's a story. Your log made it possible—without logging, you'd have just memory of the project. With logging, you have evidence: the artifact (code), the measured results, the discovered gap, the solution.

Interviewers hire based on stories. Your log is proof that you can convert learning into understanding.

Building Your Portfolio from Your Log

After 6 months of logging, you've got 50–100 entries covering 20–30 topics. That's your portfolio foundation.

Pick your 5 strongest artifacts (code, notebooks, comparisons, explanations). Write a one-page project narrative for each, grounded in your log entries. This becomes your portfolio or your GitHub README.

Example narrative from logs:

Project: Comparing Fine-Tuning Strategies for Medical Chatbots

I explored three approaches: prompt engineering, supervised fine-tuning, and LoRA-based fine-tuning. I logged my learning for each strategy. I built a comparison script that trained each approach on the same 2K medical Q&A pairs. Results: prompt engineering (baseline, free); SFT (2% accuracy improvement, 6GB GPU memory); LoRA (1.8% improvement, 1.2GB memory). Key insight: for medical domain adaptation, LoRA offers 95% of the benefit at 20% of the cost. I would recommend LoRA for production deployment. (Artifacts: repo link, loss curves, methodology notebook)

That's a portfolio piece. It required no novel research, just systematic exploration and logging. But it demonstrates thinking, measurement, and decision-making—the actual skills hiring managers care about.

Common Mistake

The biggest mistake is making log entries too long. You write a 500-word summary and, naturally, you don't want to do that every day. You skip entries. Your log dies.

Keep entries to 3–5 minutes of writing. Use bullet points if you want. The goal is to capture the idea, the question, and the artifact, not to re-explain the entire concept. You can always read the source again if you need details.

Another mistake: logging without artifacts. A log entry with no code, no experiment, no written explanation is weak evidence. Even a 50-line script counts. Even a 200-word explanation of why a method failed counts. The artifact is what makes the entry credible and memorable.

A third mistake: never revisiting your log. If you write entries but never review them, you get no compounding benefit. The magic of a log is that it becomes a study tool and interview resource over time. If you don't touch it again, it's just digital clutter. Commit to weekly review. It's 20 minutes per week; it unlocks everything else.