Wearing Many Hats: Projects, Programming, and the Chaos In Between

Sometimes I feel like my life is just a massive codebase. Different modules, running in parallel, sharing memory they probably should not, with the occasional bug that pops up at the worst possible moment. Right now I am balancing several programming projects at once. Each one has its own deadlines, its own difficult people, its own learning curve I did not ask for.

Let me give you a real example. There was a stretch last year where I had three clients live at the same time. One was a SaaS platform at Neuron Nest that absolutely could not go down. One was a photography studio that needed its culling pipeline fixed before a wedding shoot on Saturday. And one was a freelance ERP module for a client who messaged me on WhatsApp at hours that suggested he never slept.

The 2am server

The thing nobody tells you about running infrastructure in Nepal is that the problems are rarely the interesting ones. It is not some elegant distributed systems puzzle. It is the power going out during a deploy. It is a DNS change that propagated for everyone except the one client who happened to test it.

One night a production server went down at 2am. I woke up to seventeen messages. Half of them were the client, half were my own monitoring. I sat on the cold floor of my room with a laptop and a phone hotspot because the home internet had also chosen that exact moment to die. Two hours later it was back. Nobody thanked me because nobody knew. That is the job.

Context switching is a skill. People treat it like a flaw. I treat it like a muscle I trained whether I wanted to or not.

The guilt of saying no

Here is the part I am still bad at. Saying no. A friend referred me to a project last month and it sounded good and the money was fine and I said no because I knew, deep down, that I had nothing left to give it. I felt guilty for a week. I kept opening the chat to reconsider.

But the truth is that every yes you give is a no to something else, usually to sleep, or to a project you already committed to. I learned this the hard way by overcommitting and then doing mediocre work on all of it. Mediocre work everywhere is worse than great work in one place.

• Every project teaches you something, even the ones you regret taking.
• You do not have to do it all perfectly. You have to ship it working.
• Bugs happen. In code, and in life. The skill is not avoiding them. It is responding without falling apart.

What I actually believe now

Wearing many hats is not a strategy I picked. It is a thing that happened to me because the market here is small and you survive by being useful in more than one way. The developer who only writes React does not eat as well as the developer who writes React and can also fix the server and talk to the client and design the thing in Figma when the designer disappears.

I do not romanticize it. It is exhausting. But there is a strange clarity that comes from working across so many domains. You start seeing the same patterns everywhere. A scheduling bug in a photography pipeline looks a lot like a race condition in a SaaS queue. A difficult client and a flaky API both want the same thing: clear boundaries.

So I keep wearing the hats. I try to take them off at night. Most nights I forget at least one of them on. That is fine. The codebase compiles. It ships. The bugs get fixed eventually. And tomorrow there will be new ones, which honestly is the only thing I am sure about.