DEV Community: Hossam Assadallah

"Boredom Isn't the Enemy of Creativity — Knowing When to Stop Is the Skill

Hossam Assadallah — Sun, 13 Sep 2026 03:26:46 +0000

The second English piece from "Psychology of the Keyboard," a series I write about the mental side of being a programmer — the part nobody puts in the documentation.
I was standing at the sink, mid-wudu — not in front of a laptop, no editor open, not a single line of code in front of me — and the solution just jumped into my head. I'd been stuck on a bug for two days: an integration issue between FastAPI and Oracle. I'd tried everything — changed the query, dug through the documentation, asked everyone I could think of. Nothing. Then, while washing my hands, with zero warning, I suddenly understood: the problem wasn't in the code at all. The connection pool wasn't closing properly before it reopened. Something embarrassingly simple — but my mind couldn't see it while I was sitting there forcing focus.
That's not a coincidence. In cognitive psychology it's called the Default Mode Network — the part of your brain that activates when you're not demanding conscious focus from it: washing dishes, walking, showering. In those moments, your brain isn't off. It keeps working quietly in the background, connecting pieces of information that were scattered while you were focused, which is exactly what produces that "sudden" solution.
The problem is that we're trained, as programmers, to believe the answer comes from pressure — the harder you focus, the faster you'll find it. That's true, up to a point. Past that point, it works in reverse. When your brain sits on the same problem for two hours straight, it drops into a narrow tunnel of focus that shuts out every other possibility, and just keeps circling the same idea that already failed.
Boredom isn't the enemy of creativity. Boredom is the door that opens that space — when you let yourself get distracted for a bit, without a phone, without a screen, not to be lazy, but to give your brain the chance to work in a completely different mode than the one you're used to at your desk.
Take this as a rule, not a luxury: when you're stuck in front of a problem and can't move a single step forward, step away. Not just to rest your body — to give the other half of your mind room to work.
Has a coding solution ever come to you while you were nowhere near a computer? Tell me where, and when.

The 3 A.M. Moment Every Programmer Lies to Themselves About

Hossam Assadallah — Sat, 12 Sep 2026 20:27:28 +0000

The second English piece from "Psychology of the Keyboard," a series I write about the mental side of being a programmer — the part nobody puts in the documentation.

It was around three in the morning. I'd been in front of the screen since nine at night, staring at the same line of code for what felt like the hundredth time. The function looked perfect on paper — no visible issue — but the result kept coming out wrong. I tried everything I could think of: changed the condition, dug through Stack Overflow, asked an AI. Nothing changed.

I still remember exactly what I felt in that moment. It wasn't physical tiredness. It was something else entirely — a feeling that I wasn't good enough, that maybe the problem was in my own head, not in the code. That if my colleagues saw me stuck like this, they'd assume I was a beginner, not someone running a company that builds systems handling real data.

That's the thing almost nobody talks about in programming. We talk about algorithms, best practices, the newest framework — but nobody tells you this profession takes as much from your mental health as it does from your time.

In that moment of being stuck, something happens in your brain called tunnel vision. Your mind locks onto the same path you already tried and failed on, and keeps pulling you back to it — not because the answer is there, but because a tired brain finds it easier to repeat the same move than to open a new path. The dangerous part of that moment isn't failing. It's staying seated, convinced that continuing in the same direction is the answer — which is exactly what turns one exhausting hour into two or three wasted ones.

The fix isn't to be "strong" and push through. The fix is giving yourself real space away from the screen — even five minutes. Walk. Drink water. Look at something completely different. The mind isn't a machine; it needs to reorganize itself. And when you come back, you'll often find your eyes suddenly see something that had been sitting in front of you for two hours, unseen.

One more thing worth saying clearly: your value as a programmer isn't in solving everything fast. It's in continuing even when a lot of things don't get solved on the first try. Every professional programmer has been through the exact moment I just described. The difference is learning when to stop and when to keep going — not that they stopped getting lost altogether.

Have you had a moment like this? What actually helps you find your focus again?

What Training an AI Agent Taught Me About Letting Go of Control

Hossam Assadallah — Sat, 12 Sep 2026 18:25:21 +0000

his is the first English piece from "Psychology of the Keyboard," a series I write about the mental side of being a programmer — the part nobody puts in the documentation.

I was training the AI agent behind Amin, the product I've been building, and I had the exact reply mapped out in my head for every question it should get. I wrote the prompt, reviewed it, tuned it, ran the test. The reply came back — not wrong, exactly, just not phrased the way I'd already decided it should be. I went back, adjusted, tried again. A third reply came out, different from the first two. And I felt something strange. Not frustration at the model's performance — a feeling that I was losing control over something I had built from scratch.

I paused the training. Not because the model was wrong, but because I couldn't tolerate a system I'd built with my own hands producing responses I didn't control 100%. That made me think — this wasn't the first time I'd felt this. It shows up in everything I build, from the database layer to the UI: I want every detail under my control, completely.

And that instinct makes perfect sense in our profession. We're trained to believe that one point outside our control can break the whole system, so we've been conditioned to treat total control as the only real safety. The problem is that mindset doesn't stay inside the code. It follows you out. You catch yourself wanting to control an employee's reaction, a client's decision, even your own kid's mood mid-conversation — because your brain has learned that "no full control means danger."

But an agent, like any AI system, is built on probability, not fixed rules. It's not supposed to give you the exact same wording every time — that's not a flaw, that's its nature. The real lesson wasn't figuring out how to make the output 100% consistent. The lesson was learning to separate "controlling the general direction" from "controlling every word." I needed to tune the framework and the rules, not micromanage every small detail inside it.

Once I let the agent take up more space inside the framework I'd set, the responses got more natural and closer to each customer's actual tone — not because I'd gotten less precise, but because I'd gotten confident that the framework itself was enough.

Have you ever caught yourself trying to control something that was never meant to be fully controlled, at work or outside it? How did you know it was time to let go?