Can We Still Find Joy In Programming?
Over the last year or maybe just over the last few months our industry went through a significant transformation. Our industry may not have changed this much since high-level programming languages emerged in the late 1950s.
What has changed?
We write less code by hand and increasingly orchestrate it through agents. At some companies, they even expect us to become AI-first developers. Whatever that means.
This transformation brought up a probably unexpected problem. The problem isn’t productivity.
The problem is:
Many of us find it difficult if not impossible to enjoy our craft.
Something we loved, something we aspired to often from an early age suddenly became not boring, but worse, overwhelming, sometimes outright irritating.
But why?
The joy in programming often comes from solving puzzles, seeing code compile, making something finally work — and, if we’re lucky, entering that rare state of flow where hours disappear unnoticed.
AI, however, disrupts this rhythm.
You context-switch constantly.
You evaluate instead of create.
You react to a machine’s output instead of generating something from first principles.
Supervising machines doesn’t feel like building things and the joy of “flow” is just a distant memory now.
Do you remember that in the beginning of a sprint you took on a ticket, took time to read it, think about the - hopefully existing - requirements and started to think about how you’d solve it. Probably you wrote some tests and started to iterate towards a solution. You used automated tests and manual verification. You spent a lot of time analysing logs or stepping through the debugger. You might paired with your colleagues or just jumped on a call to discuss some matters. Or if not, after a while, you entered the so called flow and the world outside stopped to exist until you realised it’s time to call it a day and take on some other duties of life.
That changed. Now you take on a handful of tickets, and instead thinking deeply, you open up several sessions of your coding agent and feed them prompts to solve problems. You give them permissions to do whatever, to test on their own, to iterate on their own. Then you test the code and tell them what is STILL not working and jump over the next terminal. Once one seems done, you start reviewing the code and you might find some joy in correcting some details, proudly using a new feature of your favourite language. Or as a next step, you simply complain about tests or throw away the code and ask write a better prompt based on your observations of the generated output. You count the hours until the day ends.
Unless you bought Bitcoin a decade ago, won the IPO lottery, or simply don’t need to work anymore, this isn’t a philosophical problem. It’s practical. You still have to show up tomorrow. You probably don’t want to abandon a well-paying profession you invested years into. And deep down, you don’t even want to leave.
You just want to enjoy it again.
So the real question isn’t whether AI is good or bad. The question is: how do we rediscover meaning and joy in a job that no longer looks the way we fell in love with it?
This discomfort surfaces a fundamental misunderstanding about our profession.
Programming was never about typing code. It was about shaping behaviour. It was about translating messy human intent into deterministic systems. Code was the medium — like clay for a sculptor or notes for a composer.
For years, we confused the medium with the craft.
We thought the joy came from the keystrokes. From the syntax. From watching the compiler turn green.
But maybe what we truly loved was the feeling of agency — the sense that through careful thinking and deliberate action, we could bend complexity into order.
AI hasn’t removed the problem-solving. It has removed much of the manual construction.
And that shift is uncomfortable because it forces us to confront what we actually valued.
If code is no longer the bottleneck, clarity becomes the bottleneck.
If generating implementation is cheap, understanding the problem becomes the real scarce resource. It’s not something we can toss on product owners anymore.
This increases the value of the product-minded engineer — the one who asks “why” before “how”. The one who questions the ticket. The one who understands both trade-offs, constraints, user impact, and long-term maintainability.
In an AI-assisted or AI-first world, coders focusing only on the technical aspects become replaceable faster.
Deep thinkers do not.
Different Options Ahead Of Us
Let’s talk about the different options ahead of us if we want to keep our sanity, find joy again also grow in our careers. Beware, these are not mutually exclusive.
Embrace the Shift
Accept that the job has changed.
You are no longer primarily a builder. You are becoming a director of builders — except your builders are stochastic parrots with impressive pattern-matching abilities.
Your leverage shifts from speed to judgment.
The growth path becomes:
Designing better systems
Writing clearer constraints
Spotting architectural flaws early
Reviewing critically instead of rubber-stamping
Understanding trade-offs at a higher level
This path requires maturity. It requires restraint. It requires not being dazzled by output.
The joy here does not come from implementation.
It comes from impact.
From seeing a system behave correctly at scale.
From knowing that your decisions prevented months of future pain.
From shaping direction rather than files.
But this path demands that you let go of part of your identity.
And that is never easy.
Carve Out Craft Time
Industrialization didn’t eliminate craftsmanship.
It separated it.
Musicians use digital production tools professionally, yet still pick up acoustic instruments for the joy of it.
Developers can do the same.
Use AI where it makes sense.
But protect spaces where you think deeply, implement carefully, and enter flow.
That might mean:
Building side projects without AI
Diving into performance-critical systems
Writing something from scratch just to understand it
Learning a low-level language
Contributing to open source in a deliberate way
Not everything needs acceleration.
Sometimes slowness and learning through pain are the main point.
This option acknowledges that joy — and pain — matters, not just productivity.
Specialize Where AI Is Weak
AI is strong at pattern replication.
It is weaker at:
Navigating messy legacy systems with undocumented assumptions
Untangling production incidents at 3 a.m. with partial logs and conflicting signals
Understanding political constraints inside organizations
Making architectural trade-offs that will echo for years
Leading humans through uncertainty
Large language models are impressive synthesizers of what already exists.
They are not accountable for consequences:
they don’t carry long-term system ownership,
they don’t sit in postmortems,
they don’t defend trade-offs six months later.
The further you move toward ambiguity, the harder you are to replace.
Ironically, the more complex and human the problem, the more valuable you become. This suggests a deliberate career strategy:
Move closer to systems.
Move closer to ambiguity.
Move closer to responsibility.
The safest place is no longer at the keyboard.
It is at the intersection of technology, business, and people — where judgment matters more than generation.
Resist, But Consciously
Some engineers will choose to avoid AI-heavy environments.
They might:
Work in regulated industries
Focus on embedded systems
Join companies that value craftsmanship
Stay in niches where control matters more than speed
This is not denial.
But it must be intentional, not nostalgic.
Choosing craft over scale is valid.
But pretending the shift isn’t happening is dangerous. And you still have to stay prepared. Regulations change. What is restricted today may become mandated tomorrow.
What does this mean to juniors?
For junior developers, this shift is even more disorienting.
If AI can generate CRUD features in seconds, where do you get your repetitions? Where do you build intuition? Where do you struggle enough to grow?
The answer is uncomfortable: you cannot outsource your fundamentals.
If you let AI think for you before you have built mental models yourself, you will stagnate. You might ship features. You might look productive. But your depth will remain shallow.
Use AI as a mentor instead of a substitute for thinking.
As they say at the gym, no pain no gain. Struggle is always required if you want to grow. The learning process hasn’t changed, just the medium and we’re still trying to figure out how to deal with the change.
Conclusion
We are not losing programming.
We are losing a version of programming that we grew attached to.
The tools changed.
The craft evolved.
The identity is shifting.
The question is not whether we will adapt.
The question is whether we will do it consciously — and whether we will redesign our careers and daily life in a way that still allows us to feel agency, growth, and meaning.
Because in the end, the joy was never in the keystrokes.
It was in the mastery.
And mastery is still available, just at a different layer.