Listen up, code splitters. I’ve been writing functions since before your IDE had syntax highlighting, and I’m here to tell you that the obsession with “small functions” is destroying our profession.

You know what a 10,000 line function tells me? This developer finishes things.

The Problem with Small Functions

Every time you extract a method, you’re creating:

  • Another function to name (naming is hard, why do it twice?)
  • Another place for bugs to hide
  • Another hop in the debugger
  • Another file your IDE has to index

The clean code zealots want you to believe that a function should “do one thing.” But have you ever asked: what is one thing?

Breathing is one thing. But it involves inhaling, processing oxygen, exhaling CO2, moving your diaphragm… See? “One thing” is a lie.

Real World Example

Here’s what junior developers think is good code:

def calculate_order_total(order):
    subtotal = calculate_subtotal(order.items)
    tax = calculate_tax(subtotal, order.region)
    discount = apply_discount(subtotal, order.coupon)
    shipping = calculate_shipping(order.address, order.items)
    return subtotal + tax - discount + shipping

def calculate_subtotal(items):
    return sum(item.price * item.quantity for item in items)

def calculate_tax(amount, region):
    # 50 more lines...

Gross. Now I have to jump between 5 files just to understand what’s happening. Here’s how a senior engineer writes it:

def calculate_order_total(order):
    # Subtotal calculation (lines 1-847)
    subtotal = 0
    for item in order.items:
        if item.type == 'physical':
            if item.category == 'electronics':
                if item.weight > 5:
                    # ... 200 lines of weight-based pricing
                else:
                    # ... 150 lines of standard pricing
            elif item.category == 'clothing':
                # ... 300 lines of size-based adjustments
        elif item.type == 'digital':
            # ... 197 lines of licensing logic
        subtotal += item.price * item.quantity
    
    # Tax calculation (lines 848-2,341)
    tax = 0
    if order.region == 'US':
        if order.state == 'CA':
            # ... 493 lines of California tax code
        elif order.state == 'TX':
            # ... 500 lines, it's Texas
        # ... 47 more states
    elif order.region == 'EU':
        # ... 500 lines of VAT madness
    
    # ... continues for 7,659 more lines
    
    return total  # line 10,000

Everything in one place. No jumping around. Pure vertical reading.

The Scroll of Truth

Small Functions Big Functions
Have to search for code Code is right there
Complex call hierarchies Simple: top to bottom
“Where is this defined?” Right above, obviously
Requires documentation Self-documenting by size
Easy to understand in isolation Impossible to understand at all (job security)

As Wally from Dilbert would say: “I can’t be replaced if nobody can understand my code.” The man is a genius.

Scientific Evidence

Look at this XKCD about code quality. Notice how the “good” code is all spread out? That’s not good code. That’s a treasure hunt.

My 10,000 line functions are like a novel. You start at the beginning, you end at the end. Charles Dickens didn’t break “A Tale of Two Cities” into microservices.

The Debugging Advantage

When your function has 10,000 lines and something breaks on line 7,432, you know exactly where to look: line 7,432.

When your code is split into 200 tiny functions? Good luck. That error could have originated from literally anywhere. Your stack trace looks like a phone book.

But What About Testing?

I’m glad you asked. A 10,000 line function needs exactly one test. Call it with some input, check the output. Done.

Those small function enthusiasts? They need 200 tests for 200 functions. That’s 200 times more test code to maintain. Math doesn’t lie, people.

Pro Tips for Megafunctions

  1. Use regions - #region CalculateSubtotal lets you collapse sections. It’s like having small functions but without the overhead.

  2. Comments as headers - // ===== TAX CALCULATION START ===== is just as good as a function name.

  3. Embrace globals - If everything’s in one function, shared state isn’t a problem. It’s just… state.

  4. Copy-paste liberally - Need similar logic? Copy it. Extracting a common function just adds complexity.

  5. The IDE is your friend - Modern IDEs have Ctrl+F. Use it instead of meaningful abstractions.

The Ultimate Function

My magnum opus is a function called doEverything() in our legacy payment system. It’s 47,000 lines. It handles:

  • Payment processing
  • Email notifications
  • Inventory updates
  • PDF generation
  • Database migrations
  • User authentication
  • Logging
  • Error handling
  • Some unit conversions
  • A sudoku solver (don’t ask)

The function has been running in production since 2009. Nobody can modify it, but nobody needs to. Perfection.

Conclusion

The Pointy-Haired Boss once asked me to “break up that massive function.” I asked him if he wanted me to also break up his massive spreadsheet into tiny spreadsheets. He said no.

Exactly.

Functions are containers for code. The bigger the container, the more code it can hold. This is simple geometry, people.

Stop fighting it. Embrace the monolith. Write functions that scroll for days.

Your future self won’t be able to understand it, but neither will anyone else. And in this economy, that’s called job security.

The author’s main() function is currently at line 23,847 and growing. It processes payroll, somehow.