I'd Rather Work 80 Hours Than Have Nothing to Build
When you own something completely - every decision, every line of code, every result - you get addicted to the feedback. Solving problems becomes who you are. Finishing work becomes your proof that you matter.
On ownership, attachment, and what happens when the work suddenly stops
Two weeks of paid break is killing me more than three months of working 70-hour weeks.
That’s not something to be proud of. It’s a warning about what happens when you mix up owning your work with being your work.
I’m a software engineer who just finished building two mobile apps. I wrote every single line of code. I made every design choice. I fixed every bug at 2 AM. For three months, this project was my life.
Friday: build the app. Saturday: fix bugs. Sunday: deliver to client. Repeat. Week after week.
Then the client took the apps to test them. Now I have two weeks where I’m supposed to rest and learn new things.
Instead, I feel empty.
“Each line of code was mine. That wasn’t pride — it was addiction.”
How I Got Here
I started coding for money in my third year of college. I was freelancing on the side. In fourth year, I got an internship where I learned a lot. Then I got a full-time job at a company that builds software for clients.
They gave me two mobile apps to build from scratch. I was the only developer.
September: project started. New team, learning how everyone thinks. It took a month just to understand each other. Then we broke the project into smaller pieces with deadlines.
Every Friday, we sent the app to our testers. Every Saturday, we fixed what broke. Every Sunday, we delivered.
For three months, this was my routine. My brain got addicted to it. The rush of solving a hard problem. The satisfaction of seeing things work. The pride in building something good.

I built a lot of things:
- Guest mode (lets people use the app without logging in)
- Custom payment system (when the normal one didn’t work)
- Push notifications that actually open the right screen
- Made images load 3 times faster
- Made the app start 2 times faster
- Cleaned up the code so it’s easier to add new features later
Every decision was mine. Every line of code came from me. It was like growing a plant from a seed — except I was the plant, and the code was feeding me.
When Pride Became a Problem
One Saturday night, our testers found bugs. I fixed them right away and sent the new version.
Then the client found more bugs after midnight.
The next day, my project manager sent a message in front of the whole team: “We expect you to work a little faster.”
That broke something in me.
I had worked late nights. I had solved problems at 2 AM. I had built systems they didn’t even understand. And now they were saying I wasn’t working hard enough?

I replied to everyone: “I don’t want this project to go on forever either. I get paid when we finish, not by the hour. I gave you a low price because this was my first project here. Don’t tell me I’m not working hard when I’ve given everything.”
Silence. Then they understood. Nobody accused me after that.
“They said I wasn’t working hard enough after I’d given everything. That’s when I learned — you have to set boundaries or people will walk over you.”
That moment taught me something: when you’re the only developer, people don’t see your work. They only see delays they can blame on someone. You have to speak up loud, or you become the person everyone blames.
But speaking up didn’t fix the real problem. I was still too attached to that code.
The Empty Feeling After Finishing
Mid-December: final delivery. The apps went to the client for testing. Two weeks of waiting while they check everything.
I thought I’d feel relieved. Instead, I felt empty.
The Friday-Saturday-Sunday routine was gone. The constant problem-solving was gone. The rush from fixing hard bugs — gone. I built something I’m proud of, and now someone else controls it.
Being bored is worse than working too much. That’s the uncomfortable truth.
When you own something completely — every decision, every line of code, every result — you get addicted to the feedback. Solving problems becomes who you are. Finishing work becomes your proof that you matter.
And when that stops, even for a short time, you don’t know who you are anymore.
My 7-Day Plan to Break the Addiction
I needed to do something. Here’s what I’m trying:

Days 1–2: Learn something new (I picked Phoenix and Elixir). Something that gives me that learning rush without the pressure of real work.
Days 3–4: Write about the finished project. Write down what I built, what I learned, what mistakes I made. This keeps me connected to the work without being stuck in it.
Days 5–7: Talk to people I ignored during those three months. Call friends. Spend time with family. Tell them my stories, but also listen to theirs.
It’s Day 4 as I write this. I still want to check Slack for bug reports. I still feel phantom notifications that aren’t coming. But I’m learning that code doesn’t define me — it’s just something I’m good at making.
The Questions I’m Still Thinking About
This whole thing made me ask questions I don’t have answers for:
Should I avoid old codebases, or is that hurting my career?
I’ve said no to many jobs where I’d work on someone else’s old code. I want to start from the beginning, make my own choices, own the work. Some people say that’s ego. I say it’s the difference between fixing things and building things.
But maybe that’s the problem. Maybe I need to learn to care about code I didn’t write. Maybe you only get too attached when you start from zero.
Should engineers feel pride, or is it healthier to not care?
Pride made me build something I’m proud of. But pride also made me work until 3 AM when I didn’t need to. Pride made me take criticism personally. Pride made me unable to let go.
Is there a middle way? Can you care about quality without tying your self-worth to it?
When does ownership become unhealthy attachment?
I think it crosses the line when you can’t stop thinking about work even when you’re supposed to rest. When every bug feels like a personal failure. When you defend your code choices like they’re your children.
But I also think ownership is what makes great engineers different from okay engineers. So where’s the line?
Your Turn
I don’t have all the answers. I’m writing this on Day 4 of my forced break, learning Elixir to fill the empty space, trying to remember that I’m more than the code I write.
But I want to hear from you:
- Have you felt this attached to a project? How did it end?
- Do you avoid old codebases for the same reasons, or do you think I’m wrong?
- How do you set boundaries without losing the pride that makes you good?
- What’s your relationship with downtime? Does it help you recharge, or does it feel like falling?
Leave a comment with your thoughts. If enough people share their stories about breaking this attachment, I’ll write a follow-up post collecting everyone’s advice.
Because right now, I’m still figuring out if this feeling is something I need to fix or something I should accept.
“The code doesn’t define me — it’s just something I’m good at building. I’m still trying to believe that.”
If this resonated with you, hit the clap button and share your story in the comments. Let’s figure this out together.