Let me be honest with you. I have been writing Python for over four years, and I still have nights where I stare at a bug for two hours only to realize I caused it myself, three weeks ago, with eight confident lines of code. This article is not a highlight reel. It is a confession. Each mistake on this list cost me real time, real credibility, or real sleep, and I want to make sure it does not cost you the same.

1. Hardcoding credentials like they were invisible

In 2022, my first production script had an API key sitting directly in the source file. I pushed it to GitHub. Public repo. The key was rotated by the provider in six minutes. Six. I felt like I had left my front door open and someone had already rearranged the furniture.

The fix is embarrassingly simple and takes thirty seconds.

import os
from dotenv import load_dotenv

load_dotenv()
api_key = os.getenv("OPENAI_API_KEY")

Put your keys in a .env file, add that file to .gitignore, and never think about it again. The python-dotenv library is one import away.

2. Writing scripts instead of functions

For a long time my automation scripts were just a wall of code running top to bottom. No functions. No structure. Just vibes. The first time I needed to reuse a piece of that logic somewhere else, I copy-pasted it. Then I had two bugs in two places. Classic.

Wrapping logic into functions is not just good style. It is how you build things that scale.

def extract_text_from_pdf(path: str) -> str:
    import fitz
    doc = fitz.open(path)
    return " ".join(page.get_text() for page in doc)

def summarize_text(text: str, model: str = "claude-sonnet-4-20250514") -> str:
    # your API call here
    pass

Each function does one thing. You can test it, reuse it, and replace it without touching anything else. It sounds obvious until you have spent an afternoon untangling a 300-line script.

3. Ignoring error handling until production broke

My early automation tools worked perfectly, until they ran into a PDF with a corrupt page, or an API that returned a 429, or a folder that had been renamed. Then they crashed silently, left half-processed files everywhere, and I had to figure out what happened by reading a blank terminal.

try:
    result = call_external_api(payload)
except requests.exceptions.Timeout:
    print("API timed out. Retrying in 5 seconds...")
    time.sleep(5)
    result = call_external_api(payload)
except Exception as e:
    logging.error(f"Unexpected error: {e}")
    result = None

Defensive code is not pessimism. It is professionalism. Every external call, every file operation, every user input deserves a safety net.

4. Using print statements as a logging strategy

I used to litter my scripts with print(“got here”) and print(response). Then I would delete them before sharing the code, then add them back when something broke again. It was a cycle of chaos. The logging module exists for exactly this reason and it is built into Python.

import logging

logging.basicConfig(
    level=logging.INFO,
    format="%(asctime)s [%(levelname)s] %(message)s",
    handlers=[logging.FileHandler("run.log"), logging.StreamHandler()]
)

logging.info("Processing started")
logging.warning("Rate limit approaching")

Now your script writes to a log file and the terminal at the same time. When something breaks at 2am on a server you cannot access, you will thank yourself for this.

5. Automating the wrong thing first

There is a specific kind of trap that gets enthusiastic developers every time: automating something just because it is technically interesting, not because it saves meaningful time. I once spent a weekend building a system to auto-sort my browser bookmarks. I had 40 bookmarks. It would have taken four minutes to do it manually.

Before you automate anything, ask yourself one question: how often does this task actually happen, and how long does it take? If the answer is “rarely” and “not long,” close the laptop and go outside.

6. Never using virtual environments

I installed everything globally for the first year. Pandas, NumPy, Selenium, all sitting in the same environment like strangers at a party who do not get along. The moment I worked on two projects with conflicting library versions, everything broke in ways I could not explain or reproduce on someone else’s machine.

python -m venv .venv
source .venv/bin/activate   # Mac/Linux
.venv\Scripts\activate       # Windows
pip install -r requirements.txt

One project. One environment. Non-negotiable. Your future self will not have to spend an afternoon debugging an import error that should not exist.

7. Treating the first working version as the final version

There is a dopamine hit the moment your script runs without errors. I know it well. For a long time, I took that hit and called the project done. Then a colleague tried to run my script, hit an edge case I never considered, and the whole thing fell apart like a badly assembled chair.

The first version that works is a proof of concept. The real work is making it work for everyone else, in every edge case, with clear error messages when it does not.

8. Reinventing wheels that already existed

I once wrote a custom PDF text extractor from scratch. Took me three days. Then a friend pointed me to PyMuPDF, which did everything I built and ten things I had not thought of, in a single import. Three days for something that was one pip install away.

Before building anything non-trivial, spend twenty minutes searching PyPI and GitHub. The Python ecosystem is enormous. The wheel you are about to reinvent probably has racing tires on it already.

pip search your_idea        # check PyPI first
# or just: pip install fitz requests openai pandas
# and build on top of what already works

9. Not documenting while the code was fresh

Six months after writing a clever script, I could not understand my own variable names. What did df2_final_v3 hold? No idea. What did the function process_chunk actually return? A mystery. I had assumed future-me would remember. Future-me did not.

def extract_keywords(text: str, top_n: int = 10) -> list[str]:
    """
    Returns the top N keywords from a given text string
    using TF-IDF scoring.

    Args:
        text: Raw input text
        top_n: Number of keywords to return

    Returns:
        List of keyword strings sorted by relevance
    """
    ...

A good docstring takes three minutes to write. It saves thirty minutes of confusion six months later. Write it while you still know what the code does.

Every mistake on this list was made by someone who was moving fast and feeling confident. Confidence is good. Slowing down just enough to do the boring stuff right is better. The developers who are still building things two years from now are not the ones who never made mistakes. They are the ones who made them once, wrote them down, and never made them again.

Drop your worst coding mistake in the comments. I promise mine are worse.