Introduction: Coding Is Thinking

Let me tell you a story about two Python programmers: Alice and Bob. Alice just finished an online Python bootcamp. Bob, on the other hand, has been writing Python for years—but both often hit the same wall:

"Why is my code working... but so ugly? So fragile? So repetitive?"

This article is about smashing that wall.

We're not going to talk about fancy frameworks or obscure syntax. We're going to fix the real problem: how you think before and while coding. These are the mental tools that separate the scripters from the system designers, and the code-wranglers from the code-whisperers.

Let's go.

1) Think Like a Pro

Solve Once, Generalize Immediately

Imagine you're scraping a list of blog posts. You write this:

def get_titles():
    titles = []
    with open("blogs.csv") as f:
        for line in f:
            parts = line.strip().split(',')
            titles.append(parts[1])
    return titles

Nice. Until you need to do the same thing for products.csv. And users.csv.

The junior dev copies and pastes. The intermediate dev writes another similar function. But the pro? The pro generalizes:

def get_column(filepath, column_index):
    with open(filepath) as f:
        return [line.strip().split(',')[column_index] for line in f]

Boom. One tool, infinite use cases. No repetition. Just clarity.

“The moment you solve something twice, it deserves a name.”

Data Over Code

Here’s a quick riddle. Which is better?

if cmd == "init":
    initialize()
elif cmd == "start":
    start_service()
elif cmd == "stop":
    stop_service()

or...

dispatch = {
    "init": initialize,
    "start": start_service,
    "stop": stop_service,
}
dispatch[cmd]()

Beginners write logic. Pros write maps.

When your code is full of if/elif, ask: could this just be a dictionary of functions?

It's not just shorter. It's more powerful. You can sort keys. Validate them. Auto-generate CLI tools from them. The possibilities are wild when your behavior lives in data.

The Debugging Mindset

When I was starting out, I had this bad habit: staring at broken code like it would fix itself.

Pros don’t stare. Pros poke.

They insert:

assert isinstance(data, dict), "Expected a dict"
assert "user" in data, "Missing user key"

They try parts in isolation:

print(parse_date("2023-13-50"))  # Hmm... invalid date?

They shrink problems until the bug is cornered like a raccoon in a cardboard box.

Debugging is not a chore. It's detective work. Be curious, not afraid.

Think in the REPL (or a Notebook)

Here’s a secret: most great code did not start as code.
It started as play.

When pros want to understand something fast, they don’t write a file. They open a REPL:

$ python
>>> from datetime import datetime
>>> datetime.strptime("2023-06-19", "%Y-%m-%d")

No waiting. No script re-running. Just instant feedback.

Pro tip: Jupyter notebooks or IPython can be even better for complex experiments. But even vanilla python or bpythonREPLs can make you 10x faster at understanding data, APIs, or bugs.

Mini Challenge

Take one of your recent scripts and do these:

• Replace a big if/elif with a dict of functions.
• Wrap repeated logic in a general-purpose function.
• Add two assert statements to prevent bad data.
• Try a feature idea in the REPL first.

You’ll feel the difference in control, clarity, and confidence.

2) Architect Like a Python Pro: Beyond Loops and Ifs

So you’ve started thinking like a pro: you generalize early, debug like a sleuth, and let your REPL carry the mental weight.

Now it’s time for the next upgrade.

We’re going to go beyond writing decent functions and start building composable, elegant, and extensible systems. You know, the kind of code you look at a year later and think: "Damn. Who wrote this? Oh, right. Me."

Decorators: Add Features, Keep Clean Code

Let's say you want to log every function call.
A beginner adds print() everywhere. A pro uses a decorator:

def log_calls(func):
    def wrapper(*args, **kwargs):
        print(f"Calling {func.__name__} with {args}, {kwargs}")
        return func(*args, **kwargs)
    return wrapper

@log_calls
def greet(name):
    return f"Hello, {name}!"

print(greet("Alice"))

Output:

Calling greet with ('Alice',), {}
Hello, Alice!

You didn’t touch greet(), yet you enhanced it. Decorators are like plugins for behavior. Want to retry on error? Cache results? Track timing? All possible, beautifully.

log_calls() it he Python simplified version of trace in Lisp languages (Common Lisp). It is especially useful when debugging recursive functions.

Context Managers: Handle Setup/Teardown Like a Boss

Ever opened a file and forgot to close it?

with open("file.txt") as f:
    data = f.read()

That's a context manager. But guess what? You can write your own:

from contextlib import contextmanager

@contextmanager
def db_transaction():
    print("BEGIN")
    try:
        yield
        print("COMMIT")
    except:
        print("ROLLBACK")
        raise

with db_transaction():
    print("Do something risky")

Super clean. Zero boilerplate. Maximum safety.

If you’ve been nodding along thinking “This feels almost like I’m doing functional programming in disguise” — you’re not wrong.

Many of the ideas that now feel “Pythonic” actually trace their roots back to Lisp.

For example:

• REPL-driven programming, now a staple for Python and data science workflows, was first popularized by the Lisp family. It was one of Lisp’s greatest strengths — and a secret weapon in the early AI boom before the first AI Winter.
• Context manager functions, too, have their origins in Lisp. Common Lisp had unwind-protect and other constructs long before with blocks became standard in Python.

Mix Paradigms: OOP, FP, Procedural

Python isn’t married to any one style. That’s its beauty. Use the best tool for the job.

• Use OOP for reusable, extensible systems (e.g., plugin managers, simulations).
• Use FP for pipelines and pure data transformations.
• Use procedural for one-off scripts where clarity wins.

Here’s a tiny FP-style pipeline:

data = ["  Apple ", "banana", "Cherry  "]
data = map(str.strip, data)
data = filter(lambda x: x.lower().startswith("a"), data)
print(list(data))

That’s clean, testable, and compact. In larger systems, mix paradigms as needed.

Common Lisp is a truly multi-paradigm language. It supports imperative, functional, object-oriented, rule-based, and logic programming — all natively or with minimal effort.

But here’s an intriguing pattern:

When a language gives you all the paradigms, Lisp programmers tend to gravitate toward functional programming.

Why? Because FP naturally separates data from behavior, keeps state explicit, and reduces surprises. It turns out: pure functions are kind to the human brain. They’re easy to test, easy to reason about, and wonderfully composable.

That’s why, in Python too, many of the techniques we’ve covered — like function chaining, immutable data processing, and rule engines — echo FP principles.

Design for Extension (Open/Closed Principle)

Let’s say you want to support many export formats:

Beginner code:

if format == "csv":
    export_csv()
elif format == "json":
    export_json()

Better:

class Exporter:
    registry = {}

    @classmethod
    def register(cls, name):
        def wrapper(func):
            cls.registry[name] = func
            return func
        return wrapper

    @classmethod
    def run(cls, name, data):
        return cls.registry[name](data)

Usage:

@Exporter.register("csv")
def export_csv(data): ...

@Exporter.register("json")
def export_json(data): ...

Exporter.run("csv", my_data)

Now anyone can add support for a new format without touching the core.

Mini Challenge

• Write a decorator that times how long a function takes.
• Create a context manager that temporarily changes a config value.
• Refactor a chain of if/elif/else into a registration system.
• Mix OOP and FP: build a class with a method that returns a clean FP pipeline.

3) Think Systems, Not Scripts: The Python Wizardry Tier

In the third and final part, we shift from coder to architect. From clever to quietly powerful.

We’re not just writing functions or wrapping logic in nice layers anymore. Now we build systems that can adapt, grow, and evolve — with minimal changes.

This is where your future self throws a high-five back in time.

Write a DSL: Turn a Problem into a Language

What if you could write your code like a sentence?

Imagine a data processing flow:

with pipeline() as p:
    p >> read("input.csv") >> clean() >> transform() >> write("output.csv")

That’s not a framework. That’s just operator overloading and fluent design:

class pipeline:
    def __enter__(self): return self
    def __exit__(self, *a): pass
    def __rshift__(self, func):
        func()
        return self

And each read(), clean() is just a callable. You can swap them out. Chain them. Schedule them. All because you turned code into a mini-language.

This is a DSL — domain-specific language. And Python is a good tool to write one (although Lisp languages are far better for this).

Rule Engines: Logic as Data

Imagine you’re pricing products with different discount rules:

if user.vip:
    price *= 0.8
elif user.first_time:
    price *= 0.9

What if instead, your logic was data?

rules = [
    (lambda user: user.vip, lambda price: price * 0.8),
    (lambda user: user.first_time, lambda price: price * 0.9),
]

for cond, action in rules:
    if cond(user):
        price = action(price)

Now logic is composable. Testable. Loadable from a config file or database. This is the essence of a rule engine.

Plugin Systems: Let Others Extend You

You don’t always need to write every part of the system. Sometimes you just define the sockets, and let others write the plugs.

class Command:
    registry = {}

    @classmethod
    def register(cls, name):
        def inner(func):
            cls.registry[name] = func
            return func
        return inner

    @classmethod
    def run(cls, name):
        return cls.registry[name]()

@Command.register("hello")
def say_hello():
    print("Hello!")

Later:

Command.run("hello")

This is how you build extensible systems that scale without changing core logic.

Think in Growth Curves

Before you write code, ask:

• Will this need to handle more data?
• More input types?
• More features added by others?

Design your interfaces to be open-ended.

Use **kwargs, abstract base classes, or strategy patterns to build systems that are flexible without needing rewrites.

This mindset saves you from future headaches—and unlocks entire ecosystems of reuse.

Rule-based programming has a rich heritage in Lisp. One brilliant example is Chapter 2 of PAIP (Peter Norvig’s Paradigms of Artificial Intelligence Programming), where rules are modeled as data and applied dynamically — a concept we echoed when building rule engines earlier.

And when it comes to DSLs (domain-specific languages)? Lisp’s macro system made that trivially elegant. Python doesn’t have macros, but with decorators, operator overloading, and first-class functions, you can still get surprisingly close.

So maybe the real secret is this:

The more Python you write “like Lisp”…

the more powerful, expressive, and joyful it becomes.

Mini Challenge

Try one or more of these:

• Write a rule engine with 3 rules as (condition, action) lambda pairs.
• Make a pipeline with >> chaining and mock steps.
• Turn a business logic if/else blob into a data structure.
• Design a plugin system with a registry and one registered command.

Summary: Your Python Problem-Solving Superpowers

Let’s pause and look back at the journey we just took—one that started with awkward loops and ended with elegant systems.

Whether you’re still closer to beginner or well on your way to mastery, the principles you’ve just learned aren’t just clever tricks. They’re the foundation of writing Python that scales with your mind—code that feels like it wants to work with you, not against you.

1) Think Like a Pro

• Generalize early. If you solved it twice, it needs a name.
• Use data, not logic. Replace if/elif towers with dicts and config.
• Debug like a scientist. Assert your assumptions. Shrink your universe.
• Prototype in the REPL. Don’t wait. Test ideas live.

2) Architect Like a Pro

• Decorators = add power without touching core logic.
• Context managers = clean, automatic setup/teardown.
• Mix paradigms. Python isn’t married to one style—neither should you be.
• Design for extension. Code should welcome change without crumbling.

3) Think in Systems

• Build DSLs to let problems express themselves clearly.
• Turn logic into data using rule engines and condition-action pairs.
• Create plugin systems so others can grow your tools.
• Design with future change in mind—plan for growth, not rewrites.

Whether you're a beginner or scaling toward architectural mastery, the goal isn’t to be clever. It’s to write code that is:

• Readable and elegant
• Composable and general
• Flexible and open to change
• Robust and kind to your future self

You’re no longer just solving problems. You’re designing engines that solve families of problems.

Go build. Go refactor. Go teach.

Because that’s how pros—and wizards—are made.

Like this kind of thinking? I’ll be writing more soon on these places:

- Follow me on Medium @gwangjinkim for deep dives on Python, Lisp, system design, and developer thinking, and much more

- Subscribe on Substack: gwangjinkim.substack.com — coming soon with early essays, experiments & newsletters (just getting started).

- Follow my Ghost blog: everyhub.org — with hands-on tech tutorials and tools (most of them I cross-post here in medium, but not all of them).

Follow anywhere that fits your style — or all three if you want front-row seats to what’s coming next.

Happy hacking!

Enjoyed This?

If this kind of expressive Python got your gears turning, you’ll love my latest article on:

The Power of Multiple Dispatch in Python

The Secret Sauce Behind Julia and Lisp — Now in Python

The PythoneersGwang-Jin

It’s another deep dive into Python’s lesser-known lispy capabilities — this time showing how to solve one of the hardest problems in extensible software design, the Expression Problem, using clean, elegant techniques.

It’s in the same spirit of thinking beyond the basics.

Check it out if you’re ready to upgrade your Python toolbox even further.

You might also like to read:

Why Composability Is Such an Important Feature in Programming

Like inLego …

Python in Plain EnglishGwang-Jin

I totally recommend you to try uv, an incredibly fast Python package manager (written in Rust, thus super fast — replaces poetry, venv, pip, pyenv, pytools, and more!) — you have to try it — you’ll never look back!

I literally stopped using pip, venv, poetry, pyenv, pytools, etc. and am always in awe when creating a new environment with uv:

Fully Explained Git + Python Workflow with uv, ruff, and ty

Whether you’re new to Git or a Python dev wanting to modernize your flow, here’s a clear breakdown of what each command and tool does —…

Data Science CollectiveGwang-Jin

Why ‘uv’ Might Be the Only Python Tool You Need for Scripts

You open a notebook or script to analyze some data.

Data Science CollectiveGwang-Jin