3,488 contributions later, my laptop and I need to talk

“Just one more project” is not a harmless sentence

When I first drafted this story for LinkedIn, my GitHub profile showed 2,890 contributions. By 11 October 2026, that number had reached 3,488 over the previous year. Somewhere along the way, my laptop started asking for a meeting.

This year I kept building, learning, breaking things, and fixing them. Some projects worked. Some needed another attempt. Occasionally, a deployment made me question every decision that had led me there.

My usual stack was Python and FastAPI, Next.js, PostgreSQL, Docker, Redis, and Celery. Each new project gave me another reason to understand how those pieces connect. It also gave my laptop another reason to turn on its fans.

My laptop discovered it had feelings

Running several full-stack projects together sounded reasonable. Then the CPU got hot, the RAM disappeared, and the fans started preparing for take-off. My contribution to the situation was saying, “It’s fine.” It was not fine.

Even with 24 GB of RAM, I eventually met the blue screen of death. At one point, I actually put my chips behind the laptop exhaust to keep them crispy. If the laptop was becoming an oven, I thought it could at least contribute to lunch.

The joke was funny. The friction was real. Building an application and running several applications together turned out to be different problems. I was learning about the environment around my code as much as the code itself.

Port already in use: the unofficial soundtrack

Port 3000 was taken. Port 3001 was taken. Port 3002 was somehow also taken. I spent far too much time changing ports, mapping ports, and restarting containers.

A frontend, an API, a database, and background workers are manageable individually. Put several versions of them on one machine and the boundaries start to matter: which process owns a port, which service talks to which address, and what is still running after I think I have stopped it.

It was an unglamorous lesson, but a useful one. “I’ll sort out the environment later” has a way of becoming the entire afternoon.

Localhost agreed. The VPS did not

Then came the classic developer experience: everything worked on localhost. I deployed it to a VPS, and the server responded with the technical equivalent of “Absolutely not.”

When I started, I barely knew what a VPS or cloud server was. Now, deploying to VPS machines and working with Docker, networking, reverse proxies, and production infrastructure are regular parts of how I build.

That changed the questions I asked. It was no longer enough to know that a feature worked on my machine. I had to understand how the application would run somewhere else, and why that environment behaved differently.

My mindset moved from “What if I break production?” toward “If something breaks, we can understand it and fix it.” The confidence is in learning to diagnose a problem and taking responsibility for the fix. The dramatic version still sounds better as a meme.

AI joined the team. We immediately had disagreements

At first, I thought I should write everything myself. Then Claude Code, Codex, and Antigravity became part of my workflow. Claude Code started feeling less like a tool and more like a coworker.

I guided the workflow; it helped with the code. When the tokens ran out, I went back to coding manually, fixing mistakes, and waiting for the limit to reset.

The funniest moments came when an assistant returned, decided my changes looked like an older version, and removed a fix. My response was usually: “That was my fix. If it was unnecessary, why did you write the original version?”

Sometimes I found myself asking whether it was daydreaming while working. Apparently, arguing with a coworker now includes arguing with a language model.

Faster output still needs someone to make the decisions

Working with AI has made one thing clearer to me: getting code quickly and knowing what should change are separate skills. I still need to understand the problem, review the result, and decide whether the proposed fix belongs in the project.

The useful part is having help while I explore unfamiliar tools or work through an implementation. The frustrating part is when a confident answer misses context, introduces a mistake, or rewrites something that already solved the problem.

I am still figuring out that balance. AI is part of my workflow now, but understanding the application cannot become somebody else’s job.

The number records activity. The projects tell the story

Those 3,488 contributions are a record of activity, not a score for code quality. What matters more to me is the work behind them: projects that became real applications, unfamiliar technologies that became useful tools, and problems I can now approach with more confidence.

Not every day was productive. Not every project worked. Not every deployment went smoothly. But I kept coming back, trying again, and learning from the result.

A year ago, I was asking what a VPS was. Today, I am deploying applications and thinking about how their interfaces, services, data, and infrastructure fit together. That is the growth I want this portfolio to show.

Still building. Hopefully not replacing the laptop

There is plenty left to learn. That is part of what keeps me interested: a new project rarely lets me stay comfortable for very long.

I am still learning, still building, and still occasionally breaking things. The laptop is still involved, although I am not sure it agreed to all of this.

And, as a Python developer, I remain attached to the joke: 3,488 contributions. Zero semicolons. I will leave the Next.js files out of that calculation.

What is one technology you learned this year that changed how you build?