abanoub-ashraf/learn-while-building

Learn While Building

Framework for transforming project work into deliberate skill acquisition.

Core Principle

The goal is not just shipping—it's shipping while becoming measurably better. Every project should leave you more capable than when you started, with specific skills you can name and demonstrate.

The Learning-Shipping Paradox

Problem: Pure shipping optimizes for speed, often reusing familiar patterns. Pure learning optimizes for depth, often at the expense of delivery. Neither alone produces expert practitioners.

Solution: Deliberate integration—structuring projects to include targeted learning challenges while maintaining shipping velocity.

Deliberate Practice Integration

What Deliberate Practice Is

Practice that is:

• Purposeful: Targeting specific, named skills
• At the edge: Just beyond current ability (struggle zone)
• Feedback-rich: Immediate knowledge of results
• Repetitive: Multiple attempts at the same challenge

What It Is NOT

• Reading tutorials (consumption, not practice)
• Copying code from examples (no struggle)
• Repeating comfortable patterns (no growth edge)
• Building without reflection (no feedback integration)

The 70-20-10 Application

Research shows skill acquisition comes from:

• 70% Hands-on project work (building real things)
• 20% Social learning (code review, pair programming, mentorship)
• 10% Formal instruction (courses, books, documentation)

Optimize for the 70% while strategically adding the 20% and 10%.

Project-Based Learning Framework

Phase 1: Skill Scoping (Before Building)

Before starting any project, explicitly identify:

1. Ship Skills: Things you already know well (use to maintain velocity)
2. Stretch Skills: Things you know somewhat (push depth here)
3. Spike Skills: Things completely new (learn just enough to unblock)

For each Stretch Skill, define:

• Current level: "I can do X but not Y"
• Target level: "After this project, I will be able to..."
• Specific practice opportunities the project provides

Phase 2: Challenge Embedding (During Planning)

Structure the project to include deliberate challenges:

Architecture Decisions: Choose one area to experiment with a new pattern

• If comfortable with MVC, try MVVM or TCA
• If always using REST, try GraphQL for one feature
• If using third-party libraries, implement one thing from scratch

Implementation Challenges: Pick 2-3 features that stretch capabilities

• If comfortable with UIKit, implement key screens in SwiftUI
• If always using Combine, try async/await for one data flow
• If relying on tutorials, implement one feature from documentation only

Quality Gates: Add one new quality practice

• If no tests, add unit tests for one critical path
• If no CI, set up basic automation
• If no documentation, document one complex module

Phase 3: Micro-Learning Loops (During Building)

Apply the debugging prediction technique:

When debugging, before checking a variable value:

1. Predict what the value will be
2. Check the actual value
3. If wrong, understand why before moving on

Generalize this to all development:

• Before running code, predict the output
• Before reading documentation, predict what you'll find
• Before testing a feature, predict edge cases

Wrong predictions are learning opportunities. Right predictions confirm understanding.

Phase 4: Reflection Rituals (After Building)

Daily (5 min): What did I struggle with today? What's one thing I understand better?

Weekly (15 min):

• What Stretch Skills did I actually practice?
• What would I do differently with current knowledge?
• What patterns am I seeing across problems?

Project End (30 min):

• Did I hit the target levels for each Stretch Skill?
• What unexpected skills did I develop?
• What should I stretch next?

See references/reflection-templates.md for structured prompts.

Skill Progression Tracking

Competency Levels

Level 1 - Awareness: Know it exists, can recognize it Level 2 - Literacy: Can read and understand code using it Level 3 - Application: Can implement with heavy reference to docs Level 4 - Fluency: Can implement from memory, handle common edge cases Level 5 - Mastery: Can teach it, know tradeoffs, optimize for context

Progress Indicators

Moving from Level 3 → 4:

• Time-to-implementation decreasing
• Fewer doc lookups needed
• Anticipating edge cases before hitting them
• Code reviews reveal fewer gaps

Moving from Level 4 → 5:

• Can explain tradeoffs to others
• Know when NOT to use the skill
• Can adapt patterns to novel contexts
• Recognized as resource by others

Tracking Method

Maintain a simple skill log:

Skill: [Name]
Current Level: [1-5]
Evidence: [What demonstrates this level]
Next Target: [Specific capability to develop]
Practice Plan: [How upcoming work will develop this]

Learning Acceleration Techniques

Interleaving

Don't master one thing before touching another. Interleave related skills:

• Day 1: SwiftUI layouts
• Day 2: Combine data flow
• Day 3: SwiftUI + Combine integration
• Day 4: Back to layouts with new context

Interleaving feels slower but produces better long-term retention and transfer.

Spaced Repetition

Revisit learned concepts at increasing intervals:

• Same day: Use it immediately
• Next day: Recreate without reference
• One week: Apply in different context
• One month: Teach to someone else

Elaborative Interrogation

When learning something new, always ask:

• "Why does this work this way?"
• "What would happen if I changed X?"
• "How does this connect to Y that I know?"

Answering these questions creates deeper memory traces than passive reading.

Retrieval Practice

Instead of re-reading documentation:

• Close the docs and try to recreate
• Write down everything you remember
• Only then check what you missed

Retrieval strengthens memory more than review.

Career Visibility Add-ons

See references/career-learning-principles.md for learn-in-public and writing practices that compound skill growth.

Balancing Learning and Shipping

The 80/20 Rule for Projects

• 80% of code uses familiar patterns (maintain velocity)
• 20% of code stretches into new territory (ensure growth)

If a project is 100% comfortable, you're not growing. If a project is 100% stretch, you won't ship.

When to Learn vs. When to Ship

Optimize for Learning When:

• Building foundational skills needed for future work
• Timeline is flexible
• Building a portfolio/learning project
• Early in a new technology/domain

Optimize for Shipping When:

• Users are waiting / deadline is real
• Core skills are sufficient for the task
• Learning can happen post-launch via iteration
• Team depends on delivery

The "Learn It Twice" Pattern

For complex new skills:

1. First pass: Quick spike to understand the shape (don't worry about quality)
2. Build the feature: Use what you learned, accept imperfection
3. Second pass: Refactor with deeper understanding (after shipping)

This separates exploration from production while ensuring you eventually develop mastery.

Common Anti-Patterns

Tutorial Hell

Symptom: Completing tutorials but unable to build independently Fix: After any tutorial, immediately build something original using only docs

Premature Optimization of Learning

Symptom: Researching the "best" way to learn for weeks Fix: Start building today. Optimize learning process after you have data

Comfort Zone Camping

Symptom: Projects feel easy, you're very productive, but skills plateau Fix: Deliberately add one unfamiliar element to each project

Learning Without Shipping

Symptom: Deep knowledge, empty portfolio Fix: Set shipping deadlines even for learning projects

Shipping Without Learning

Symptom: Large portfolio, skills haven't grown in years Fix: Before each project, explicitly name what you'll learn

See references/anti-pattern-diagnosis.md for self-assessment questions.