Three Problems with a Tool

One of my favorite Podcasts, Podcast.__init__, always makes sure to ask one question towards the end of every episode: when should you not use the tool or technique introduced in this episode? This is a great question. When people have a poor answer I assume that the tool is not good, or at least that it is not mature enough.

If you use a tool for long enough, and enough circumstances, you will have some cases where it is a poor fit. Not just a poor fit: a painful mistake that you will regret.

This does not mean the tool is bad. This is true for the some of the best tools I have used, and some of the ones I have the most experience with.

If a tool is not fundamentally useful, it will not get to the point where it is causing problems. It will be dropped long before it is used in a place or in a way where it is a mistake that makes people regret.

A good rule of thumb for when you really understand how a tool works is that you can point out at least three big problems with it. Try it now with some of your favorite tools and tecniques. List three big problems with them.

For example, it is no secret that I like, and have plenty of experience in, Python. There are more than three problems, and sorting by how big they are is subjective.

Regardless, here are three big problems in Python:

• Packaging: It is hard to produce a standalone package for a Python applications. All of the ways to do it end up failing in one of several ways.
• Fractured tooling: Properly developing in Python requires understanding setuptools, venv, pip, and pip-tools. These are all separate projects, the documentation is in different places, and understanding how they interact takes a while to master.
• Crufty standard library: The standard library is full of essential things, like sys, useful things, like heapq, useless things, like urllib.request, and poor substitues for third-party packages, like dataclasses. Knowing which is which is mostly folklore,

All of this is not to say I think Python is bad: I use it every day! It is to show how harsh you should be when talking about the problems with something you like. Until you can do that, avoid using the tool anywhere important, unless someone else, who can articulate the tool's problems, is guiding the project.

Thanks to benny Vasquez and Alex Scammon for their useful comments on an earlier draft of this post. Any mistakes that remain are my responsibility alone.