Where I Started: When I began my Mainframe journey as a developer, I was focused on “my” first product running on z. I threw myself into every aspect of the product with full enthusiasm, trying to understand every little detail and using my work to make the product better and better. Over time, my knowledge and skills continued to grow. I became an expert. Or at least, that’s what I thought.

Here’s what happened next: One day, my boss at the time called me into his office to tell me that my work was needed elsewhere. I switched teams—and with that, the product as well. I quickly realized that these new requirements had demoted me from an expert back to a beginner. Much of my knowledge was purely product-specific. So, in a way, I knew a lot—but at the same time, I knew nothing at all. I had to painstakingly start almost from scratch.

What I did differently this time: I didn’t just settle for knowing every detail of the product; I asked myself what was going on behind the scenes. How things ACTUALLY worked. What role did the operating system play, and what about the interfaces to other software? Our internal documentation was no longer enough for me—I started reading the IBM manuals to build up my background knowledge. I read posts in the forums, talked to colleagues working on other products, and tried out a lot of what I’d learned.

What I Learned: A good developer knows their product inside and out and understands how the details work. But a great developer also understands the bigger picture—how things are connected and function on a broader scale. The broader you can apply your knowledge, the more valuable it becomes—whether in new tasks or when facing new challenges in the job market.

 
My Best Tip:
 Here’s the tip I always share with others: Your work is not an island. Look beyond it. Don't let your curiosity end at these boundaries—your journey toward knowledge goes beyond them.

Here’s how you can apply it:

•       Often, superficial knowledge is enough to successfully complete a task. Don’t settle for that. Read the relevant manuals in their entirety. Try to find articles on standards and background information (online) and aim to fully understand the topic.

•       Don’t just understand your routines and functions up to the next API. Ask yourself how they’re implemented. How do they ultimately work within the operating system? What does the hardware do for you?

•       Talk to others about their topics. Exchange ideas! Learning together is better and faster!

The Impact: Applying this approach helped me become a better developer. I also worked on many other projects, products, and with other technologies. As a project leader and later as a manager, I was able to put the knowledge I had gained to good use in many projects.

With my knowledge of many different fields and topics, I was able to understand the teams’ work and the challenges they faced much better, and I was often able to help them by drawing on my experience.

Encouragement for Others: Remember: you don’t need to know everything, but a certain curiosity about details is essential. Start where you are, stay curious, and lean into the community. Growth in this space is continuous — and incredibly rewarding.