Your Project Is Not Your Learning Plan
Customers pay for business value, Staying technically relevant is your responsibility
There is an excuse I have heard from developers for years:
“I haven't had the opportunity to work on that technology because my current project is legacy”
At first, it sounds reasonable, It isn't.
A project can give you opportunities to learn. A good project often does. But your project is not responsible for keeping your skills relevant → That responsibility belongs to you!
The Myth: I Learn What My Project Gives Me
Software changes fast. Languages evolve, frameworks mature, architectural approaches change, and better engineering practices emerge constantly.
Yet many developers allow the technology stack of their current project to define the boundaries of their knowledge.
If the project uses technology from ten years ago, they continue working with technology from ten years ago.
Then, a few years later, they say:
“I never got the opportunity to work on the newer stack.”
That is not really an opportunity problem → It is an ownership problem
Your Customer Is Not Funding Your Learning Roadmap
Dan North captured this distinction very clearly:
“I’m not paying you to learn. I’m paying you to deliver business value.”
Learning absolutely matters. In fact, continuous learning is one of the basic responsibilities of being a software professional.
But we should not confuse our responsibility to learn with the customer's responsibility to fund that learning.
A customer hires a development team because they have a business problem to solve.
They are not paying us to experiment with every new framework, architectural pattern, database, messaging platform, or cloud service we want to explore
When Learning Starts Driving the Solution
This is where things become dangerous.
Developers discover a new framework, pattern, architecture, or technology and immediately start looking for somewhere to use it.
Suddenly:
a simple application needs microservices,
a straightforward operation needs event-driven architecture,
a small abstraction needs several design patterns,
an existing capability gets rebuilt from scratch,
or a stable technology gets replaced mainly because something newer looks more interesting.
The technical decision quietly stops being:
“What is the simplest appropriate solution to this business problem?”
and becomes:
“What would I like to learn or put on my résumé?”
That is backwards.
Mosh Hamedani described learning this lesson the expensive way. Instead of spending roughly a day learning an existing workflow framework, he built his own and spent nearly two weeks on it:
“I didn’t get paid a penny for those 14 days designing my super-duper workflow engine.”
The lesson is not that developers should stop learning.
The lesson is that customer projects should not become personal technology laboratories at the customer's expense.
Working on Legacy Software Is Not an Excuse
You may spend years maintaining a legacy application with little opportunity to use modern tools, frameworks, or architectural approaches.
You may spend years maintaining a legacy application with little opportunity to use modern tools, frameworks, or architectural approaches.
That can limit your hands-on experience with newer technologies. It should not limit your knowledge.
Learn outside the project. Build small proofs of concept, read documentation, experiment with new approaches, and stay aware of how the industry is evolving.
You do not need your current project’s permission to stay updated.
Learn outside the project. Build small proofs of concept, read documentation, experiment with new approaches, and stay aware of how the industry is evolving.
Separate Learning From Applying
A mature engineer understands this distinction:
Learn broadly. Apply selectively.
Experiment freely in your own learning environment. In production, be selective.
Learn new patterns, frameworks, and tools, but use them only when they genuinely solve the problem better.
Your curiosity should improve customer outcomes, not become a cost the customer has to carry.
The Mindset to Unlearn
Stop saying:
“I don't know it because my project never gave me the opportunity.”
Replace it with:
“My project determines what I use today. It does not determine what I am capable of learning for tomorrow.”
A project can contribute to your growth.
A company can support your growth.
A manager can create opportunities for your growth.
But none of them can own your growth.
Deliver business value in the project. Build your competence continuously outside its boundaries.
As after five or ten years -> “Limited exposure can not be an excuse for limited growth”
References
Daniel Terhorst-North, discussion on delivering business value versus treating learning as the primary value of software development, in The Origins Of Behaviour Driven Development (BDD) | The Engineering Room Ep. 39
Mosh Hamedani, Not Invented Here Syndrome Explained.
