Twelve Years with Python
and Counting

In 2012, I was deep in the world of competitive programming: writing C++ solutions to algorithmic problems, optimising for time and space, measuring success in accepted submissions. It was satisfying in a narrow, precise way. But I had not yet built anything I could actually show to someone.

That changed in 2013, when a friend introduced me to Python 2.7. I remember following a tutorial to build a Battleship game in the terminal. It was rudimentary by any measure, with grids printed to stdout and user input read from the keyboard, but it was the first time a program felt like something I had made rather than something I had solved. The gap between idea and working code was suddenly much shorter.

Why Python Feels Different

Every language has a philosophy, but Python's is unusually explicit about it. The Zen of Python, readable in a single sitting, says things like "Readability counts" and "There should be one obvious way to do it." These are not just aphorisms; they shape how the language is designed and how its community writes code.

What makes Python genuinely beautiful to work in is the combination of a few properties that rarely coexist so cleanly in one language:

These properties compound. A language that is readable is easier to review, easier to onboard colleagues into, and easier to revisit six months after writing it. That has real value in professional settings where code outlives the people who wrote it.

From Tutorials to Real Applications

After Battleship, something shifted. The competitive programming problems I had been solving in C++ suddenly felt like puzzles for their own sake. Python made me want to build things people could actually use.

The first real application I built was a Chess desktop app: a full GUI implementation using Python's Tkinter library, with move validation, check detection, and a working two-player mode. It was not polished, and the AI opponent was barely an opponent. But it was mine in a way that a solved LeetCode problem never could be. I had designed the board state, the piece logic, the event handling. Python made all of that manageable for someone who was still, fundamentally, learning.

What Python Powers Today

By the mid-2010s, Python had already moved well beyond academia and scripting. Today it is one of the foundational languages of the modern technology stack:

The StackOverflow Years

Around 2017 and 2018, I noticed something had quietly changed. I was answering Python questions on StackOverflow, not occasionally but regularly. Decorators, metaclasses, async/await, descriptor protocols. People asked; I knew. That is a different kind of signal than passing an interview or shipping a feature. It meant the language had become intuitive enough that I could reason about other people's problems from first principles.

That period also coincided with Python 3 finally winning the transition from Python 2. The community coalesced, the tooling stabilised, and the language stopped feeling like it was in two minds about itself. Type hints arrived with PEP 484, and suddenly large codebases became more maintainable without sacrificing the dynamic nature that made Python worth using in the first place.

Professional Years: Scale, Reliability, Observability

With over eight years of professional experience now behind me, the problems I work on with Python look quite different from a Battleship game in a terminal. Scalable data pipelines that process millions of events. Services that need to stay up under load. Observability stacks that surface failures before users notice them.

What has not changed is the language's fundamental character. Python still gets out of the way. It still reads like structured thought. And its ecosystem has grown to meet the demands of production engineering in ways that would have been hard to predict in 2013. The type system, the async runtime, the packaging tooling: they have all matured.

The language I learned by following a browser tutorial is now responsible for a significant portion of the world's machine learning infrastructure, its data pipelines, and its scientific computing. That trajectory does not feel like coincidence. It feels like a language designed with the right priorities.

Where Python Goes from Here

Python's future is both exciting and, in some respects, a solved question. The language is not going anywhere. The harder and more interesting questions are about how it evolves:

But there is a bigger question sitting underneath all of this. AI coding tools like Claude Code are changing what it means to write software. We will likely see Python 3.14, 3.15, and beyond. The language will keep improving. Yet the more pressing question is not what the next version brings, but whether we will be writing it ourselves at all. When you can describe what you want in plain English and have working code produced in seconds, the syntax of a language starts to matter less than the intent behind it.

That is either a threat to everything that made programming feel personal, or it is the logical conclusion of what Python always stood for: getting closer to human thought and further from machine instruction. I have not fully resolved which one it is. But after twelve years of writing Python, I find it telling that the tools most capable of replacing it were themselves largely built with it.