TL;DR / Key Takeaways

Corporate engineers regularly hide their own automation because being efficient can feel like a liability.
The fear of being seen as replaceable keeps skilled people doing work that a 50-line script handles better.
The mental shift from "I need approval" to "I just built it" is the most important thing you can do for yourself.
The Predict & Profit trading bot exists because I stopped waiting for a product roadmap and just wrote the code.

I automated a reporting job at work sometime around 2019. Took me two evenings. Saved probably four hours a week of copy-paste nonsense that I had been doing manually for months.

I did not tell anyone.

I kept the script in a folder with a forgettable name. I still opened the spreadsheet at the right time every week so it looked like I was working. I submitted the output as if I had done it by hand.

That is insane. I knew it was insane. I did it anyway.

The Fear Is Real, Even If It Makes No Sense

Here is what you are actually afraid of when you hide automation at work.

You are afraid your manager figures out the job takes you twenty minutes now instead of four hours. And instead of thinking "great, Steve is efficient, let's give him more interesting work," they think "great, Steve is replaceable, let's give his hours to someone cheaper."

That fear is not irrational. I have watched it play out. I have watched people get reorganized out of roles because they were too good at making themselves efficient. The system does not always reward optimization. Sometimes it just rebalances the load and pockets the savings.

So you learn to be quietly fast and visibly busy. You learn to pace your output. You learn that competence is something you ration carefully in a corporate environment.

That is a miserable way to spend your career.

What Four Hours a Week Is Actually Worth

Four hours a week is 200 hours a year. At a senior engineer salary, that is somewhere between fifteen and thirty thousand dollars of labor, depending on where you sit.

The company captured that value. Not you.

You did the intellectual work of understanding the problem well enough to automate it. You wrote the code. You tested it. You maintained it quietly. The company got the output either way and paid you the same salary.

This is the fundamental transaction of employment that nobody says out loud. You sell your time and your skills. The surplus value from your efficiency belongs to them.

I am not trying to make this political. It is just math.

What Automating for Yourself Actually Feels Like

The first time I wrote a script for my own benefit, not for a ticket, not for a sprint, not because a product manager asked, something shifted.

Nobody had to approve the PR. Nobody had to review the architecture. Nobody had to sign off on the tech stack. I just built the thing, tested it, and ran it.

Here is a version of the script that started this whole mental shift. It was a dead-simple file watcher that reformatted and renamed downloaded reports before I ingested them into a pipeline.

import os
import time
import shutil
from datetime import datetime
from watchdog.observers import Observer
from watchdog.events import FileSystemEventHandler

WATCH_DIR = os.path.expanduser("~/Downloads")
OUTPUT_DIR = os.path.expanduser("~/data/reports/processed")

class ReportHandler(FileSystemEventHandler):
    def on_created(self, event):
        if event.is_directory:
            return
        filename = os.path.basename(event.src_path)
        if not filename.startswith("weekly_export") or not filename.endswith(".csv"):
            return

        timestamp = datetime.now().strftime("%Y%m%d_%H%M%S")
        new_name = f"report_{timestamp}.csv"
        dest = os.path.join(OUTPUT_DIR, new_name)

        time.sleep(0.5)  # let the file finish writing
        shutil.copy2(event.src_path, dest)
        print(f"[{datetime.now()}] Captured: {filename} -> {new_name}")

if __name__ == "__main__":
    os.makedirs(OUTPUT_DIR, exist_ok=True)
    observer = Observer()
    observer.schedule(ReportHandler(), WATCH_DIR, recursive=False)
    observer.start()
    print(f"Watching {WATCH_DIR} ...")
    try:
        while True:
            time.sleep(1)
    except KeyboardInterrupt:
        observer.stop()
    observer.join()

That is it. Drop it in a systemd service and forget it exists. The renamed files show up where you need them, timestamped, ready to ingest.

Took maybe ninety minutes to write. Ran for two years without touching it.

Nobody approved it. Nobody reviewed it. It just worked.

The Difference Between Corporate Automation and Your Own

When you automate at work, you are automating someone else's problem. The output belongs to the company. The institutional knowledge lives in a repo you will lose access to the day they let you go.

When you automate for yourself, the output belongs to you. The knowledge compounds in your own head. The system runs on your infrastructure, on your schedule, for your benefit.

That distinction sounds obvious. It took me until my late fifties to really feel it.

Building the Kalshi trading bot was the clearest version of this I have ever experienced. Nobody assigned it to me. There was no ticket. There was no sprint. There was no architecture review board.

I identified a market inefficiency, built a signal pipeline, wired it to an API, tested it in dry-run for weeks, and then turned it on. The bot placed its first real trade and I watched the fill notification show up in the log.

That feeling does not exist inside a corporation. You cannot manufacture it with a promotion or a bonus. It only comes from building something that is entirely yours.

The Cron Job Version of Permission

One of the small, concrete things that signals the mental shift is how you think about scheduling.

At work, you schedule things through approved infrastructure. Jenkins, Airflow, whatever the platform team manages. You submit a request. Someone reviews it. It goes on the approved job list. Every step requires a human to say yes.

On your own machine or a cheap VPS, you just write a crontab entry and move on.

# Run the weather bot every 6 hours
0 */6 * * * /home/steve/bots/weather/venv/bin/python /home/steve/bots/weather/auto_trader.py --dry-run >> /home/steve/logs/weather_bot.log 2>&1

That is the whole thing. No ticket. No approval. No change management form.

The first time you run crontab -e, save it, and watch the logs populate at exactly the time you specified, the abstraction becomes real. You are the platform team. You are the DevOps team. You are the product manager.

That is either terrifying or liberating depending on where you are in your career. For me it was both, for about a week, and then just liberating.

What Took So Long

I spent thirty years asking for permission to build things.

Some of that was reasonable. Enterprise systems have real constraints. Compliance matters. Security reviews matter. Coordinating with other teams matters.

But a lot of it was just learned helplessness. I had internalized the idea that code needs to be approved before it runs. That architecture needs to be reviewed. That someone above me in the org chart needs to sanction the technical approach.

That is useful training for building reliable systems at scale. It is a terrible habit when you are trying to build something for yourself.

The trading bot does not need an architecture review. The cron job does not need a change ticket. The SQLite database I use to log trade decisions does not need a database review board.

It just needs to work. And it does.

The Actual Mental Shift

You stop asking "is this approved" and start asking "does this solve the problem."

The second question is faster to answer and leads to better software. You build it, run it, watch it fail in interesting ways, fix the failures, and ship the improved version. The feedback loop is tight because there is no committee between you and the system.

The Weather Bot went from a 31-member GFS ensemble to a 164-member grand ensemble pulling from four independent forecast systems, including NOAA's own operational AI model on their public AWS S3 bucket. That upgrade happened because I identified the limitation, built the fix, tested it, and shipped it.

No sprint planning. No stakeholder alignment. No approval.

That is the whole point.

The automation you are hiding at work is making someone else rich. The automation you build for yourself is the only kind that actually accumulates into something.

I stopped asking for permission somewhere around 2024. The bot is the result. Thirty years late, but here we are.

Why I Stopped Asking for Permission to Automate My Own Job