18 October 2025
Why I keep reaching for Python first
Post about Python ease of use.
There’s a moment at the start of every new project where you choose a language before you’ve thought about it. For me, that language has too often been Python. Not because it’s the best tool, not because I’ve weighed the options. Just because it’s there. Familiar. Ready.
I’ve been thinking about why that is and whether it’s actually a problem. Python is fast to start with. There is no build system, no type declarations, no ceremony. You open a file, you write code and it runs. That frictionlessness is genuinely valuable when you’re exploring; when you don’t yet know what you’re building; when you’re prototyping an idea to see if it survives contact with reality. Python lets you think in code without the language getting in the way.
However, I’ve noticed something. The same properties that make Python great for starting make it easy to never stop starting. Projects that should have graduated to something more structured stay in Python because moving feels like work. The codebase grows, the lack of types starts to bite, performance becomes a concern and yet the switching cost feels too high. You’re stuck with your default.
The real question isn’t whether Python is good. It is. The question is whether you’re choosing it or just defaulting to it. Those are different things. A choice implies you considered the alternatives: that you thought about whether TypeScript’s type system would have caught a class of bugs earlier, whether C++ was worth the overhead for something compute-heavy, whether the language matched the problem.
I don’t think defaults are bad. Having a language you know deeply, that you can move fast in, is genuinely useful. But I’ve started trying to make the choice consciously rather than automatically. Sometimes I still pick Python. But now it’s a decision, not a reflex.