I Thought I Was Lazy or Had ADHD. Then, AI Explained: I Have a Builder Brain.
Why do you happily fix bugs at work but quit your own projects after 3 weeks? A Tech Lead’s personal diagnosis.
I was looking at my public GitHub profile the other day.
It was a graveyard.
Page after page of repositories: circle-camera, gh-advisory-security-dashboard, pixel-art-game-browser, aibrainstormer-tiktok-landing.
Every single one of them started with a burst of energy. I could remember the exact weekend I started them. I remembered the excitement of choosing the tech stack, the thrill of getting the first “Hello World” on the screen, and the rush of solving the core architectural puzzle.
And I remembered exactly when I stopped. It was always around the 3-week mark. Right when the “fun” part was over and the “real” work began.
For years, this public list filled me with guilt.
I looked at other developers on Twitter shipping polished SaaS products. I watched my colleagues finish complex tickets. And I looked at my own profile, a public testament to all the things I’d abandoned.
- “Am I just lazy?”
- “Do I lack discipline?”
- “Do I have undiagnosed ADHD?”
- “Maybe I’m just not a ‘real’ developer.”
The guilt was eating at me. I felt like a fraud. A Tech Lead who couldn’t even finish a simple side project.
So, being an engineer, I decided to stop guessing and start debugging. I gathered my data — my personality test results, my general intelligence scores, and my history of unfinished projects — and I fed them into an AI model.
My prompt was simple: “Analyze this profile. Why does this person quit every side project they start?”
The answer wasn’t a medical diagnosis. It wasn’t a judgment of my character. It was a mechanical explanation of my operating system. And it changed everything.
The diagnosis
The AI didn’t say I was broken. It said I was a builder.
It explained that my brain is wired to seek the dopamine hit of creation and discovery.
When I start a project, I am solving a puzzle. “How do I structure this?” “Can I make this API work with that library?” “How do I architect this data flow?”
This phase is pure brain candy. Every problem solved is a hit of dopamine.
But then comes the dopamine cliff.
Visualisation of the developer dopamine cliff.
Once the core puzzle is solved — once I know how it works and I’ve proven the concept — the discovery phase ends. The project shifts from “architecting” to “maintaining.” It becomes about writing documentation, fixing CSS bugs for mobile, setting up authentication, and writing unit tests.
For a builder brain, this isn’t just boring; it’s chemically unrewarding. The dopamine tap turns off instantly.
My projects didn’t die because I was lazy. They died because I had unknowingly solved the puzzle I came for.
The work paradox
This explanation made sense, but I had one big counter-argument.
“If I’m incapable of doing boring maintenance work, why am I successful at my job? I spend weeks fixing bugs, refactoring legacy code, and doing administrative tasks. I don’t quit there.”
The AI’s answer to this was the final piece of my puzzle.
It’s called external regulation.
At work, I am not relying on my internal dopamine system to drive me. I have powerful external motivators:
- A salary: I get paid to endure the boredom. My paycheck is the “maintenance fee” for my brain.
- Social pressure: I have teams relying on me, and I rely on them. I have a boss. I have deadlines.
These external forces act as a bridge over the dopamine cliff. They carry me through the boring parts that my natural brain chemistry would abandon.
But at home, on a Saturday night, those external forces don’t exist. No one is paying me. No one is watching. The only fuel I have is internal interest.
So, the moment the interest dies, the engine stops. And that is not a moral failure; it is simple economics.
The solution
This insight didn’t just explain my past; it fixed my future.
I realized I had been lying to myself. I was starting every project with the goal of “launching a product,” when in reality, my brain’s goal was “learning a technology.”
I was judging a fish by its ability to climb a tree.
Visualisation of the learning and product project.
Now, I have a new system. Before I type mkdir new-projectI ask myself one question:
“Is this a learning project or a product project?”
If it’s a learning project: My goal is to solve the puzzle. I play with the new tech. I built the prototype. And the moment I feel that dopamine cliff approaching? I stop. I archive the repo. I don’t feel guilty. I feel proud. I came to learn, I learned, and now I’m done. Mission accomplished.
If it’s a product project, I know what’s coming. I know that in 3 weeks, I will hate it. I know the dopamine will vanish. So, I prepare. I treat it like a job. I accept that the “maintenance valley of death” is the price I must pay. I don’t wait for motivation; I rely on discipline.
You are not broken!
If your GitHub profile looks like mine, stop beating yourself up. You are likely a builder 
.
The world needs people who start things. The world needs people who can stare at a blank page and see possibilities.
Your graveyard of projects isn’t a list of failures. It’s a library of lessons learned. It’s proof that you are curious, that you are experimenting, and that you are growing.
So go ahead. Start that new project. Solve the puzzle. And if you get bored in three weeks?
It’s okay to quit. You’re just a builder doing what builders do best.
originally published on Medium by:
Written by RayRay
Tech Lead 
. Debugging code, teams, and developer brains. Sharing lessons from 18 years of building software