Skip to main content

Command Palette

Search for a command to run...

The Junior Dev Who Taught Me Something New

Learn: The Junior Dev Who Taught Me Something New

Updated
6 min readView as Markdown
T

Welcome to TopperBlog! 👋

I'm a tech content creator passionate about helping developers level up their careers and master cutting-edge technologies.

🎯 What I Write About: • AI/ML Engineering & LLMs • Web3 & Blockchain Development
• System Design & Architecture • Interview Preparation (FAANG) • Freelancing & Remote Work • Modern Tech Stacks (Next.js, React, Rust, TypeScript) • Performance Optimization & Best Practices

💼 Mission: Sharing practical, actionable insights that accelerate your tech career and maximize your earning potential.

📚 15+ In-Depth Guides covering everything from earning $10k/month as a freelancer to cracking FAANG interviews.

🌐 Let's connect and grow together in this amazing tech journey!

#TechBlogger #SoftwareEngineering #CareerGrowth #WebDevelopment #AIEngineering

The Junior Dev Who Taught Me Something New

Or: How I Learned to Stop Worrying and Love Being Wrong

I've been writing code professionally for twelve years. I've architected systems handling millions of requests. I've mentored dozens of developers. And last Tuesday, a 22-year-old junior dev—three months out of bootcamp—made me realize I'd been doing something inefficiently for half a decade.

His name was Marcus, and he was terrified to tell me.

The Setup

We were pair programming on a data processing pipeline. Nothing fancy—just parsing CSV files, transforming records, and bulk inserting into Postgres. I'd written this pattern a hundred times. My fingers moved on autopilot:

def process_large_csv(filepath):
    records = []
    with open(filepath, 'r') as f:
        reader = csv.DictReader(f)
        for row in reader:
            records.append(transform_row(row))

    # Bulk insert all at once
    db.bulk_insert(records)
    return len(records)

"Um..." Marcus started, then stopped. His cursor hovered over the Slack message box. Deleted text. Started again.

"What's up?" I asked.

"Nothing, just... never mind."

The Moment

I've learned that "never mind" from a junior dev usually means one of two things: they're confused, or they've spotted something. I stopped typing.

"Seriously, what were you going to say?"

Long pause. Then: "Wouldn't that... use a lot of memory? If the CSV is really big?"

My first instinct—and I'm not proud of this—was to explain why it was fine. We had plenty of RAM. The files weren't that big. This was the standard pattern. I'd literally written it in our team's documentation.

But something made me pause. "How would you do it?"

def process_large_csv(filepath):
    count = 0
    batch = []
    BATCH_SIZE = 1000

    with open(filepath, 'r') as f:
        reader = csv.DictReader(f)
        for row in reader:
            batch.append(transform_row(row))

            if len(batch) >= BATCH_SIZE:
                db.bulk_insert(batch)
                count += len(batch)
                batch = []

        # Don't forget the last batch
        if batch:
            db.bulk_insert(batch)
            count += len(batch)

    return count

"Batch processing," he said quietly. "We learned it in bootcamp. For memory efficiency."

The Reckoning

I stared at his code. It was... better. Objectively better. Not just for theoretical edge cases—we had files that were 500MB+. I'd just never thought about it because the server had 32GB of RAM and the problem never surfaced.

But that's not engineering. That's luck.

"How much memory does your version use?" Marcus asked.

I did the math. My version: loaded entire file into memory. For a 500MB CSV, that's 500MB+ in RAM, plus Python object overhead, plus the transformed records. Easily 1-2GB.

His version: ~1000 records at a time. Maybe 2-3MB in memory, regardless of file size.

"Marcus," I said, "this is way better than what I wrote."

He looked genuinely shocked. "Really? I thought maybe I was missing something. You're the senior dev."

The Lesson I Didn't Expect

Here's what hit me: Marcus was scared to suggest an improvement. Not because I'm an asshole (I hope), but because of the implicit hierarchy we create in tech. Senior dev = knows more = is right. Junior dev = learning = probably wrong.

I'd been on both sides of this dynamic, but I'd forgotten what it felt like to be on the junior side. That stomach-drop feeling when you think you've spotted something but you're probably just missing context. The self-doubt. The "never mind."

How many good ideas had I missed because someone was too intimidated to share them?

The Better Pattern

We refactored together. Here's what we ended up with—combining his memory efficiency with some error handling and progress tracking:

from typing import Iterator, Callable
import csv

def process_csv_in_batches(
    filepath: str,
    transform_fn: Callable,
    batch_size: int = 1000,
    on_progress: Callable[[int], None] = None
) -> int:
    """
    Process a CSV file in memory-efficient batches.

    Args:
        filepath: Path to CSV file
        transform_fn: Function to transform each row
        batch_size: Number of records per batch
        on_progress: Optional callback for progress updates

    Returns:
        Total number of records processed
    """
    total_count = 0
    batch = []

    try:
        with open(filepath, 'r', encoding='utf-8') as f:
            reader = csv.DictReader(f)

            for row in reader:
                try:
                    transformed = transform_fn(row)
                    batch.append(transformed)

                    if len(batch) >= batch_size:
                        db.bulk_insert(batch)
                        total_count += len(batch)

                        if on_progress:
                            on_progress(total_count)

                        batch = []

                except Exception as e:
                    logger.error(f"Error transforming row {total_count}: {e}")
                    # Continue processing other rows
                    continue

            # Process remaining records
            if batch:
                db.bulk_insert(batch)
                total_count += len(batch)

                if on_progress:
                    on_progress(total_count)

    except FileNotFoundError:
        logger.error(f"File not found: {filepath}")
        raise
    except Exception as e:
        logger.error(f"Unexpected error processing CSV: {e}")
        raise

    return total_count

# Usage
def transform_row(row):
    return {
        'user_id': int(row['id']),
        'email': row['email'].lower().strip(),
        'created_at': parse_date(row['signup_date'])
    }

processed = process_csv_in_batches(
    'users.csv',
    transform_row,
    batch_size=1000,
    on_progress=lambda count: print(f"Processed {count} records...")
)

What Changed

I made three changes to how I work:

1. I explicitly ask for feedback now. Not "any questions?" but "What would you do differently?" or "Does anything here seem off to you?"

2. I share my uncertainties. When I'm not sure about an approach, I say so. It signals that doubt is okay, that we're all figuring things out.

3. I celebrate being wrong. When someone catches a mistake or suggests something better, I make a big deal about it. "Great catch!" in Slack. Credit in commit messages. Making it safe to speak up.

The Uncomfortable Truth

The tech industry worships expertise. We have levels and titles and ladders. We do system design interviews and architecture reviews. We write "senior" and "principal" and "staff" on our business cards.

And all of that creates an environment where being wrong feels like failure.

But here's the thing: the best engineers I know are wrong constantly. They just recover faster. They're wrong in code review, wrong in design docs, wrong in Slack threads. And they say "you're right, let's change it" without their ego getting in the way.

Marcus taught me something that day, but not just about batch processing. He reminded me that humility isn't about downplaying your expertise—it's about staying open to being surprised.

The Takeaway

You know what Marcus said when I thanked him? "I almost didn't say anything. I figured you knew something I didn't."

How much collective intelligence are we losing to that sentence?

If you're a senior dev: make it safe to be corrected. Your job isn't to be right—it's to help the team build the best thing possible. Sometimes that means the junior dev has the better idea.

If you're a junior dev: speak up. That "stupid question" might not be stupid. That "obvious" improvement might not be obvious. You have fresh eyes and different experiences. Use them.

And if you're anywhere in between: remember that experience is just one form of knowledge. Marcus had three months of professional experience, but he'd also spent six months in an intensive bootcamp that covered modern best practices I'd never formally learned. Different doesn't mean less.


I updated our team documentation that afternoon. The new example uses batch processing. In the commit message, I wrote: "Improved by Marcus—better memory efficiency."

He sent me a Slack DM: "Thanks for listening."

I replied: "Thanks for teaching me something."

Because that's the thing about this industry—we're all junior devs in something. The moment you forget that is the moment you stop growing.

Stay humble. Stay curious. And for the love of god, listen to your junior devs.