DEV Community: Aaron Maxwell

If You Are Overwhelmed, It's Because You Are Not Setting Boundaries

Aaron Maxwell — Sun, 31 May 2026 14:09:08 +0000

Do any of the following describe you:

Working longer hours than you expected
Agreeing to things you do not want to agree to
Accumulating technical debt, because new tasks eat up all your time
Feeling manipulated into taking on responsibilities you do not want
Feeling pressured to accept deadlines you do not think are realistic
Getting burnt out, without any clear sustainable solution
Feeling disempowered, like you do not have the autonomy and self-direction you expected you would have

If so, you are in good company. Many of my colleagues, and I would say many people who work in technology, have the same issue.

I could write thousands of words on the root cause of this, and the strategy of what to do about it.

But instead, I will cut to the chase:

The reason you have these problems is that you do not know how to set boundaries properly, in your interactions at work, and without causing negative consequences.

The solution is to learn HOW to safely set those boundaries, and then set them.

To do this, get the book titled:

"When I Say No, I Feel Guilty"

Written by Manuel J. Smith. You can find it anywhere, but make sure you buy it new, not used (it is extremely cheap). And buy the print version, not digital or audiobook.

Skip the front matter and chapter 1; go directly to the first page of chapter 2. Read chapters 2, 3 and 4. They will teach you something called the "Broken Record" technique.

Then pause reading, and write in a journal (paper or digital) about how you can use Broken Record in specific situations at work.

For extra impact: over the next week, write a quick note in that journal every day, about how you were able to use Broken Record, and what the results were; AND any opportunities that day where you could have used Broken Record, but did not realize it in the moment. This will help you use it when that situation repeats.

If you do this, you will have a lifelong skill that will increase your dominion over your own life, and help you avoid feeling overwhelmed in the future.

How To "Market" Yourself As A Tech Pro

Aaron Maxwell — Fri, 22 May 2026 15:30:00 +0000

As you build your technical skills, your next step is to create your own open-source software project, to demonstrate those skills to the world.

Ideally it will be a project that is fun for you to create, and also will teach you about a new technology you are interested in...

But its primary purpose is to be marketing asset. An asset that is marketing YOU.

I call this your Artifact. Your Artifact is a dynamic marketing asset which efficiently signals your elite status to the job market, and attracts the opportunities you want.

Every word of this matters:

It is an asset. Meaning something you create, which generates more of what you want, as a side effect of its existence.
It is a marketing asset. Its purpose is to market you. It is a tool for professional self-promotion.
It is dynamic. As technology and the world evolves, you refine your Artifact to adapt to new job-market conditions.
It signals your value. It demonstrates your expertise, communicates your skills, and broadcasts your value to the job market. As your goals change (and you learn to think bigger for yourself), you pivot the Artifact to signal differently.
It signals efficiently. What your Artifact communicates about you is communicated immediately. It is instantly believed with little or no skepticism. Just like an author of a book is assumed to be an expert in that book’s topic, so your Artifact creates instant and powerful first impressions of you.
It signals status. Your professional status, your industry reputation, and the esteem in which others at the top of your profession perceive you.
It attracts the opportunities, the professional relationships, and ultimately the career you want.

Your Artifact takes the form of an ongoing project. This Artifact can be

A software tool, used by your peers to do their work
A software library, used by your peers when they write code
A web application, useful to people in your domain of technology
It can also be a book, though that is much harder (speaking from experience). I recommend you do one of the above first.

Creating your Artifact does NOT need to be difficult, or require a lot of work. The notion that success can only come from extreme exertion is a limiting belief. The career-boosting results of your Artifact are largely independent of the effort and time you put into it.

It's more of a mindset. Asking yourself: what Artifact can you create, that will attract the opportunities you want?

If you liked this, you will enjoy the Powerful Python Newsletter.

First Principles

Aaron Maxwell — Wed, 20 May 2026 15:30:00 +0000

Every domain of human activity has its own first principles. These are the foundational concepts, distinctions, ideas, and mental models upon which that domain is based.

And in my experience, the most useful first principles are not generic and hand-wavy. Instead, they are precise and specific.

One example: Python's "function object" abstraction.

In Python, functions are objects. That means you can store them in a variable. Like this:

>>> def praise(name):
...     print(f"{name} is tall and handsome!")

>>> describe = praise

>>> describe("Aaron")
Aaron is tall and handsome!

This has some big implications. You can write a function that creates and returns a different function. You can pass functions around just like you might pass around an int or a list or an instance of a class; as far as Python is concerned, a function is just another value.

That lets you do some very powerful things.

One example: the Strategy design pattern.

Do you remember this one? It lets you select an algorithm at runtime. And in most languages, you need to write a special class with a special method to make it work. But in Python, you can just pass a function object instead. Like this:

>>> numbers = [7, -2, 3, 12, -5]

>>> # Sort the numbers.
>>> sorted(numbers)
[-5, -2, 3, 7, 12]

>>> # Sort them by absolute value.
>>> sorted(numbers, key=abs)
[-2, 3, -5, 7, 12]

See the last line, where it says "key=abs"? Notice there is no open parentheses after "abs". You are passing in the "abs" function, not calling it.

And this is without even opening the metaprogramming can of worms, filled with vibrantly wriggling features like decorators.

Again, this function-object thing is just ONE of the first principles of programming in Python. There are many more; other languages and technologies have their own, uniquely valuable first principles too. And it goes far above the language level, to the system design level and beyond.

When you learn to recognize, leverage and apply first principles in your own work, you find you can do things you just couldn't do before.

If that doesn't give you an unfair advantage in this frenetic age of AI, setting you apart from the drooling vibe coders, then nothing will.

If you liked this, you will enjoy the Powerful Python Newsletter.

Is Python High Level Or Low Level?

Aaron Maxwell — Mon, 18 May 2026 15:30:00 +0000

Imagine you need to fill a list with square numbers - or more complex objects, but we'll just use square numbers to keep it simple. Here's one way to do it:

MAX_ROOT = 100
values = []
for x in range(MAX_ROOT):
    values.append(x**2)

print(values)

Does the job, and much easier to follow than the C version:

#include <stdio.h>

#define MAX_VALUE 100

int main() {
    int values[MAX_VALUE];
    for (int i=0; i < MAX_VALUE; i++) {
        values[i] = i * i;
    }
    for (int i=0; i < MAX_VALUE; i++) {
        printf("%d %d\n", i, values[i]);
    }
    return 0;
}

What makes it easier to follow? Several things, which I would summarize as: "the Python code is higher level".

'Higher Level' means it abstracts over details of HOW to accomplish what you want... so you focus more on specifying WHAT you want, and the language figures out how to make it happen.

But we can go higher level than this. For example, a list comprehension:

values = [ x**2 for x in range(MAX_ROOT) ]

This is more 'declarative', which is one way to make a language higher level. You design the language so you can declare what you want, rather than spell out how to assemble it.

But what if you want to create your own high-level, declarative syntax? Not a list comprehension, but something else entirely?

In fact, Python provides a way to do this:

OOP.

This may be surprising. You know the benefits of OOP already, such as:

Code becomes more reusable
More organized, so your code is easier to reason about
More encapsulated, thus de-inter-twining the logic
Code is more testable

But there is one underappreciated benefit of OOP. Which is that - when you do it right - you can make your code more high level.

For example, this class that represents a range of dates:

class DateRange:
    def __init__(self, start, end):
        if end < start:
            raise ValueError(f"End date {end} must be after start date {start}")
        self.start = start
        self.end = end

    def __contains__(self, when):
        return self.start <= when <= self.end

    def __len__(self):
        return 1 + (self.end - self.start).days

Use it thusly:

>>> from datetime import date
>>> date_range = DateRange(date(2050, 3, 1), date(2050, 3, 15))
>>> len(date_range)
15
>>> date(2050, 3, 10) in date_range
True
>>> date(2050, 7, 1) in date_range
False

Do you see how this abstraction called DateRange is higher level than mucking about with datetime.date() objects? That it is cleaner, which means it is easier to reason about; and common operations are encapsulated in simple methods, some of which even merge with the baked-in Python syntax.

You can extend these ideas further, for example to create domain-specific languages. Like the filtering in square brackets that Pandas provides for DataFrames:

import pandas as pd
df = pd.read_csv('/path/to/big/file.csv')
df[df.A + df.B == 19]
df[d.B - d.C >= 3]
df[(df.A > 0) & (df.B >= 12)]
df[(df.A >= 3) | (df.B == 11)]

And even if you have been writing classes in Python for years...

Consider there may be more to OOP than you realize. Especially when writing high-quality, engineering-grade code you are proud of.

If you liked this, you will enjoy the Powerful Python Newsletter.

Dark Python Patterns

Aaron Maxwell — Sat, 16 May 2026 15:30:00 +0000

Here are some terrible ideas you should avoid at all costs:

Import Everything

Avert your eyes from this dangerous code:

from somelib import *

The "import *" will import EVERYTHING contained in that module, and dump it right in your current namespace.

What makes it dangerous is that you won't know there is any problem right away. The problem comes when somelib, or even your own code, gets updated...

Weeks, months, years later...

And suddenly you have a namespace collision that breaks your code, in the most confusing way possible. This create bugs that take ages to even figure out what is going on.

Better: write "import somelib", or "import somelib as sl" (or some other short, handy abbreviation).

That makes all the components in somelib available, safely contained in their own namespace.

Blanket Except Clause

Look away, from the most self-destructive code a Python developer can write:

try:
   do_something()
except:
   pass

What it does is execute the code in the try block.

And if an error is raised - ANY exception whatsoever...

You won't know. You can't know. Until it's too late.

Because the "except: pass" will not only silently suppresses the exception. It will hide from you the fact that there was an error AT ALL.

It does not just hide normal exceptions, like TypeError if you accidently add an integer to a string. Or ValueError, if you convert a string like "not a number" into an int(). If you mis-type a variable name? That's a NameError. And it is COMPLETELY HIDDEN by this diabolical dark pattern. Creating the worst kind of bug, that is almost impossible to detect in development, and will wreak mayhem in production.

Better: pin-point the except clause to the specific exception type you want to ignore. For example, "except ValueError: pass".

Or if that is not appropriate, at least call "logging.exception()" in the except block. Look that up; it gives you a full stack trace in the logs.

Those are two dark Python patterns you should strike from your mind, so you never even think to do them.

Have you found other dark Python patterns? Comment and tell me.

If you liked this, you will enjoy the Powerful Python Newsletter.

So Does AI Boost Coding Speed Or Not?

Aaron Maxwell — Thu, 14 May 2026 14:45:00 +0000

Marc Andreessen, a former revolutionary software engineer and now venture capitalist at Andreessen Horowitz (aka a16z), said this in a recent interview:

"At our leading edge companies, estimates are the leading edge programmers are like 20x more productive than they were a year ago. It's like the most dramatic increase in programmer productivity in like ever."

He's not the only respectable voice claiming this. Silicon Valley veteran Naval Ravikant, Brian Chesky (founder of AirBNB), and many other credible folks have made similar claims recently. And this is ignoring the less-credible claims of people who run AI companies.

So is this 20X thing real?

Or even 10X, 5X, maybe 2X?

I think it only makes sense to look at long-term productivity, over a time scale of a year or more.

So "20X" means that an individual, or a team, gets 20 years of pre-AI work done in a single year. Because if the long-term increase falls short of that, it's not really 20X, is it?

And if you look for verifiable, objectively measurable evidence of those 20X (or 10X or 2X) productivity gains...

Well, there just does not seem to be any.

That does not mean it is not happening. Maybe I just do not know about it. If you know of an example, tell me, please.

But it seems like there should be at least one clear, widely-recognized, and uncontested example by now, if that 20X (or 10X, 2X, etc.) claim is true.

What I think is happening:

AI tools speed up development in proportion to:

Your baseline of software development expertise,
How well-characterized the problem is among open-source codebases, and
Your ability to evaluate the quality of the AI tool's output.

And for certain particular tasks, that can certainly 2X, 10X, even 20X productivity.

A good example from my own experience: configuring a Django web service that used nginx, reversed-proxied into gunicorn (which is a Python-specific webapp server), and integrating another tool called uvicorn (with a "v") to enable websockets, all interfacing with the configuration of something called ASGI in the Django config.

Don't worry about what all those words mean.

The point is that it was a realistic, complex, production-grade task.

And the way I would have done it before LLMs is to spend three days reading the manuals of nginx, gunicorn, uvicorn and Django in detail, until I figured out how to configure these completely separate systems to work gracefully together.

Instead, I wrote a prompt to ChatGPT about what I wanted, and had a production-ready solution in an hour. 1 hour, versus over 20 hours; a true and objective 20X boost in productivity.

But that was just one task. One step of many to creating, refining and deploying this complex web application.

I am increasingly convinced that those who claim 10X and 20X boosts to development productivity from AI are incorrectly extrapolating one boosted experience to their entire work year.

Again, if you know of a credible, objectively verifiable exception, please tell me.

In the meantime, the best strategy, in my view:

Continue to invest in your software development/engineering skills. I.e. your ability to write great software in the first place.

That way, whatever AI does or does not do in the coming months and years, you are positioned to excel and reap juicy rewards.

If you liked this, you will enjoy the Powerful Python Newsletter.

Deterministic AI

Aaron Maxwell — Sun, 10 May 2026 13:45:00 +0000

The enthusiasm around AI has been focused on large language models for years now. For quite a few folks, this is their first real experience with AI at all. And I am sure you have noticed something:

LLMs are non-deterministic.

In other words, repeated invocations of the algorithm with the same inputs typically produces different outputs.

You can demonstrate this yourself. Open a chat AI tool in two incognito tabs, asking it a substantial prompt like "explain LLMs to me", and you will see the responses are different.

With all the noise about generative AI like this in the past 5 years, it's easy to forget there is a whole universe of AI that is completely deterministic.

The simplest example is linear regression.

Lots of great info about this online, so I will not explain it here. But when someone asked me recently how to start learning AI - not just how to use AI tools, but actually understand AI from first principles - my suggestion was that he start by learning linear regression. It is tremendously useful in the real world today, and is simple enough that you can actually grok it without a PhD.

The relevant fact about linear regression here:

It is deterministic.

The nuance is that some algorithms used to train linear regression - for example, gradient descent - deliberately inject randomness, because it is useful to do so.

But once trained, linear regression models are completely deterministic. Every time you stuff the same input into one, the exact same output comes out.

This has implications for the software systems we design.

When a program needs an AI component, and you are able to use a deterministic algorithm:

You can write unit tests and have a good time doing it.
QA will have a much easier time nailing down any issues and making them reproducible (and thus much easier to fix).
You won't have bizarre surprising behavior pop up in production as often.
That part of the software system will behave in more consistent and understandable ways.

Of course, if your application actually needs an LLM - or any other form of nondeterministic AI - then that's what you have to use. But if and when you have a choice, these are some things to think about.

If you liked this, you will enjoy the Powerful Python Newsletter.

P.S. When we say "LLMs are non-deterministic", that is technically a lie. It is more correct to say that LLMs are chaotic, in the mathematical sense of sensitive dependence on initial conditions; and on top of that, deliberate randomness is injected into how the LLM is applied, via the temperature parameter.

But nobody understands all that. "Non-deterministic" does describe how LLM-based tools feel to people at the UX level, so I'll go with the crowd and use that term.

"Prime Testable" Code

Aaron Maxwell — Sat, 09 May 2026 16:30:00 +0000

What is the EASIEST Python code to test?

Because writing unit tests is a superpower. It's great. Completely changes what you are capable of as a developer.

Think of the last time you wrote an incredible piece of software... Literally surprising yourself with the beauty, the power, the sheer awesomeness of what you created.

Writing unit tests make that feeling COMMON. You want to live that life.

And part of using them effectively is learning how to make your code easily testable. Out of the bulging universe of different choices for how to organize your code, choosing a way that makes high-impact, high-value tests easiest to write.

In other words, working smarter, not harder.

And while easy-to-test code is not always practical... It often is. You want to learn how to discern.

The easiest code to test is what I call "prime testable" code, which has these two qualities:

The code has no side effects, and
The code is deterministic.

I'll explain:

"No side effects" means that the code does some calculation or look-up, and returns a value... and that's it.

It does NOT write to a database, create a file, or open your garage door. Those are all side effects.

"Deterministic" means that it ALWAYS returns the same outputs, when you feed it the same inputs.

Calculating the 217th prime number, or splitting a string into a list of words, or sorting a sequence - these are all deterministic.

Fetching the number of visitors to your website in the past hour? Not deterministic at all.

If a function or method you write has these two qualities, it is prime testable. And it is the easiest thing in the world to quickly write powerful tests for.

Which means you will write more tests for it. Which means your life is BETTER.

Often, if you have some code that must be non-deterministic or must have side effects - and every real program has code like that - then you can spin out the prime-testable part in a separate function, method or class.

Shove as much of your program's error-prone complexity as you can into that spun-out component. Test the heck out of it. Then any code using it will be reliable and solid.

If you are struggling to write a test, step back and see if you can organize your application code differently. The more of your code you stuff into prime-testable methods and functions, the easier the tests will flow.

If you liked this, you will enjoy the Powerful Python Newsletter.

Emergent Abstractions

Aaron Maxwell — Fri, 08 May 2026 14:28:19 +0000

Here's an interesting class, from a program I wrote:

from datetime import (
    date,
    MINYEAR,
    MAXYEAR,
    timedelta,
    )

class DateInterval:
    BEGINNING_OF_TIME = date(MINYEAR, 1, 1)
    END_OF_TIME = date(MAXYEAR, 12, 31)

    def __init__(self, start=None, end=None):
        if start is None:
            start = self.BEGINNING_OF_TIME
        if end is None:
            end = self.END_OF_TIME
        if start > end:
            raise ValueError(f"Start date {start} must not be after end date {end}")
        self.start = start
        self.end = end

    @classmethod
    def all(cls):
        return cls(cls.BEGINNING_OF_TIME, cls.END_OF_TIME)

    def __contains__(self, when):
        return self.start <= when <= self.end

    def __iter__(self):
        num_days = 1 + (self.end - self.start).days
        for offset in range(num_days):
            yield self.start + timedelta(days=offset)

Use it like:

>>> interval = DateInterval(date(2050, 1, 1), date(2059, 12, 31))
>>> some_day = date(2050, 5, 3)
>>> another_day = date(2060, 1, 1)
>>>
>>> some_day in interval
True
>>> another_day in interval
False

Classes are abstractions. Some of these abstractions are concrete nouns. If you wrote code for an online shopping website, you may have classes named

Customer
Product
Coupon
ShoppingCart

Or your role-playing game may have classes for

Player
HealingPotion
Goblin (which inherits from Monster)
Sword (which inherits from Weapon)

And so on.

Notice these classes are all something you can visualize. Each is something you can at least imagine to be real, that you could pick up, move around, put in a wheelbarrow.

But other abstractions are, well, abstract. Like DateInterval. Have you ever held a DateInterval in your hand? Could you put THAT in a wheelbarrow? No way. It's a pure abstraction, an idea, that only exists and only makes sense inside the ethereal context of a running program.

I find that in real software, many of my most useful classes are non-tangible in this same way.

And perhaps because of that, I sometimes don't imagine them at first. Instead, they EMERGE.

That's what happened with DateInterval. Originally I didn't have it in my code. But at some point, I had a more or less working program, that did 80% of everything it was supposed to do. It wasn't done, but it was starting to get close.

And as I thought about how to add the next feature, I realized there were a lot of methods taking "start" and "end" date arguments, scattered around many different classes. And many of them needed to check whether a date was in a certain range, defaulting to certain behaviors if one or both of those boundaries were omitted.

So I asked myself: how could I simplify the code? The code that already exists, as well as the remaining code I know I'm going to write?

And in that moment, between my ears, DateInterval popped into being.

This is what I mean by "emergent abstraction". The abstraction, DateInterval, wasn't part of any bottom-up design of the system. It wasn't something I realized was needed early on in the process. The need for it emerged.

(In this case, it emerged as I was coding the application. But there's no reason it could not have emerged during the design phase, had I chosen to be detailed enough there. The point is that it emerged as the system became more completely specified.)

Now, another question: what made it POSSIBLE for me to come up with DateInterval?

To recognize the situation where it would help, then actually write it to behave the way it's supposed to?

DateInterval is not "hello world" level stuff. It uses class methods, the iterator protocol, generator functions, magic methods, and a couple of important subtle design tradeoffs that aren't obvious until you stare really hard.

In most courses, books, etc., you learn about features of Python in isolation.

But real code isn't like that. In real code, you're ALWAYS using MANY language features, interlocked together, all the time. Like DateInterval.

And you can reach a level that lets you SEE a DateInterval-shaped hole in your code, and then suddenly, magically, know how to code the perfect piece to fill that hole...

And you do it again, and again, and again. Until you end up with a program that seems so beautiful and amazing, you can hardly believe it came out of you.

Your homework, if you choose:

Look over the code you wrote in the past week. Or the code that you're writing today.

And pay attention to anything that seems repetitive. Especially when you look just beneath the code, if you catch my meaning...

And ask yourself:

"What emergent abstractions can I see? What Something-shaped hole can I perceive, when I look at the code, in my mind's eye?"

Because when you truly SEE your code, you don't see it with your eyes. You see it with your mind.

In that space where you can gaze upon it inside of you, where the code REALLY lives.

If you liked this, you will enjoy the Powerful Python Newsletter.

What To Optimize For With Coding Agents

Aaron Maxwell — Wed, 06 May 2026 13:45:00 +0000

When you start to use agentic coding tools - like Claude Code, or OpenAI Codex, or OpenCode - it can be overwhelming at first.

Coding agents like these are overpowered Swiss-army chainsaws. They have a great deal of leverage, and that leverage is strange; it can be hard to know how to work with them in a way that doesn't cause problems later.

Let me suggest a good approach:

Optimize for understandability.

In other words, as you start using coding agents in new ways, experimenting with what works, the way you decide "what works" is that what the agent creates is understandable to you.

Because at the end of the day, you are responsible for what that coding agent produces. Whether it's creating new code, refactoring a mature codebase, adding a new feature, or fixing a bug.

And since you are held responsible for it, the only way to stay sane is to make that agent create changes that you can understand.

The great thing is that this aligns with normal best practices anyway.

Readability, maintainability, good code documentation, intuitive naming, a well-organized and comprehensive suite of unit tests, following SOLID principles and proven architecture patterns...

All of these things, it turns out, make the system easier for you to confidently understand.

And when you do, it's much more relaxing.

If you use the coding agent in a way that produces something you don't really understand.... well, that's kind of nerve-wracking, isn't it? Especially since, once again, you are responsible for what it does once it's deployed.

But if you learn to use the coding agent in a way that it produces changes you can understand well, that gives you a lot more confidence in what you are creating using this tool.

And as a result, you'll sleep better at night.

If you liked this, you will enjoy the Powerful Python Newsletter.

Levels of Python type annotations

Aaron Maxwell — Mon, 04 May 2026 16:30:00 +0000

Python has optional type annotations - also called "type hints". Like this:

def entry_to_dict(entry: Entry) -> dict:
    return {
        'title': entry.title,
        'num_likes': entry.num_likes,
        'url': entry.url,
        }

The annotations here being "Entry" as the type for the "entry" argument, and "dict" as the return type.

In fact, there are at least 3 ways type annotations can be used:

documentation
to configure libraries and tools
static type checking

These are so different, asking "do you use type annotations?" is really too vague. It's three separate questions.

The first is demonstrated by entry_to_dict() above. You are reading the code, and just by reading it, you know that entry should be an instance of a class called Entry, and entry_to_dict() should return a dictionary.

This by itself is really useful. And part of what makes it useful is how easy it is to include when you write the code. There's very little "friction" to dropping these types in as you bang out the method definition... And you can just skip them when they are too complex (or unknown) to specify.

(Bonus: if you're the type of developer who uses autocomplete in IDEs, type hints can improve its capabilities in some cases.)

The second case - configuring libraries and tools - is demonstrated in data classes:

@dataclass
class Entry:
    email: str
    when: str

    @classmethod
    def from_csv_row(cls, row):
        email = row['Customer email'].lower()
        when = parse_scheduleonce_date(row["Meeting date and time in Owner's time zone"])
        return cls(email, when)

    def __hash__(self):
        return hash( (self.email, self.when) )

See the "email: str" and "when: str"? @dataclass uses those annotations to do its magic.

The third use case, static type checking, is a different animal.

Because statically typed languages (like Java) have an advantage over Python: the type of every variable and expression is predefined, so the compiler can catch many errors at compile time that Python cannot...

In fact, Python itself cannot catch those until the line of code is actually executed...

And the promise of "static type checking" is to fix that. Using a tool called mypy.

To get the full benefits, though, requires an ongoing tax on your time.

You must essentially learn a new mini-language to specify types, with constructs like Optional[List[str]] and Tuple[_T, _T] that just look weird until you learn how they work. Then invest effort with every function, class, and method you write, to specify the annotations correctly, consistently, and thoroughly.

Which takes more effort than you would like, frankly. It becomes an ongoing tax on your codebase, paid in your attention while coding.

But the larger the Python application, the greater the payoff. And especially for larger, enterprise-grade software systems, the benefits start to greatly outweigh the costs.

If you liked this, you will enjoy the Powerful Python Newsletter.

Pandas' secret mini-language

Aaron Maxwell — Sun, 03 May 2026 12:45:00 +0000

The DataFrame class (from Pandas) is a work of art. Even if you never "do data", priceless lessons can be gleaned by studying this class.

It starts simple enough. Usually you will create a DataFrame by ingesting from a CSV file or database table or something. But you can whip up a small one like this:

import pandas as pd

df = pd.DataFrame({
        'A': [-137, 22, -3, 4, 5],
        'B': [10, 11, 121, 13, 14],
        'C': [3, 6, 91, 12, 15],
    })

This gives you a DataFrame with three columns, labeled A, B and C. With rows of data, like so:

>>> print(df)
     A    B   C
0 -137   10   3
1   22   11   6
2   -3  121  91
3    4   13  12
4    5   14  15

The first thing to notice is that DataFrame is a class. Once upon a time, there was no such thing as a DataFrame. Someone imagined it, and then coded it up. And just look how it changed the world.

If that is not an argument for learning OOP, I do not know what is.

But this article is about something else. Because once you have a DataFrame, you can 'filter' out rows that match certain criteria, by typing magick chars inside square brackets:

>>> positive_a = df[df.A > 0]
>>> print(positive_a)
    A   B   C
1  22  11   6
3   4  13  12
4   5  14  15

Breaking this down:

You can refer to column A of the DataFrame "df" by this handle: df.A
You can use square brackets, e.g. "df[...]", to say: "give me a new DataFrame with only certain rows, skipping others."
What rows are kept? Well, that gets defined by an expression like "df.A > 0" in the brackets. Meaning, in this case: keep those rows where the 'A' value is positive.

And it is interesting that you can go much more complex:

# Relationships between multiple columns:
df[df.A + df.B == 19]
df[d.B - d.C >= 3]

# Logical "and" and "or":
df[(df.A > 0) & (df.B >= 12)]
df[(df.A >= 3) | (df.B == 11)]

# Equation-like filters, e.g.:
df[df.C + 2 < df.B]

Which is super cool.

But it also makes no sense, when you think about it...

Because "df.A > 0" evals as boolean True or False. Right? Exactly one bit of information. So how in the name of Guido does this work?

It works because "df.A > 0" is not boolean. It sneakily does not return True, nor False. It evaluates to something else:

>>> comparison = (df.A > 0)
>>> type(comparison)
<class 'pandas.core.series.Series'>
>>> print(comparison)
0    False
1     True
2    False
3     True
4     True
Name: A, dtype: bool

Well how about that. Rather than bool, its type is something called Series. Which is kinda like a list of bool's, one for each row. Now it makes more sense, doesn't it.

This is the core principle which allows DataFrame's square bracket trick to work.

And while I do not have room in this little essay to fully explain the details...

I will point out that it relies on Python's particular object model. Meaning, it relies on OOP. But also on details of how Python uniquely does OOP. And when you invest in mastering OOP in Python, it helps you make powerful classes like DataFrame too.

Something to think about.

Of course, this is an advanced technique. But see what good ideas all this sparks for you. How can you apply what you learned today in your own code?

(To get a hint to how (df.A > 0) "returns" something other than a bool, search Python's docs for this magic method name: __gt__().)

If you liked this, you will enjoy the Powerful Python Newsletter.