Editor’s Note: This is the second article in SHARE’s series highlighting the mainframe career journey at different stages. Read the “late in career” and "mid-career" pieces, and stay tuned for future installments. If you would like to participate in this series, reach out to editor@share.org.

When I first started studying computer science at Northern Illinois University around the turn of the century, I never thought I’d be working at one of the 10 largest companies in the world. Through a few unexpected turns in my career, I’ve ended up at Broadcom, and I’m having a great time working on their mainframe storage products CA 1 Flexible Storage, Disk Backup and Restore, and Allocate. Despite spending a little more than a quarter century on the mainframe, it often feels like I’m closer to a recent college graduate than a subject matter expert because there are many areas on the platform I still haven’t explored.

I’m often reminded of what my mentor senior developer and database team lead Claudia Ho at IBM told me about her level of knowledge on the mainframe: she might have known half of what IBM Distinguished Engineer and chief architect of database management software  Vern Watts knew. At the time, it was hard to comprehend how someone with deep knowledge could feel like they didn’t know everything about z/OS, but it slowly made more sense as I spent more time on the platform and was humbled many times by its complexity.

Every Role Brings a New Puzzle to Solve

It all started simply when, after my sophomore year, I landed an internship at IBM in IMS, working from San Jose, California. It was a challenging opportunity that helped me learn what it took to be a software developer. My projects with more complicated and vague projects than I got in college.  It was also my first time working with a team of people of vastly different skill levels.  It caused me to spend time thinking of different solutions to a problem. Also, I started to build diagnostics into my code that could be enabled to determine if it was working well and trace unexpected errors. When I came back to college, I had a completely different mindset and the classes were much easier, even data structures and algorithms in assembler.

When IBM made me an offer to join the company, I jumped at the opportunity. Over almost two decades at IBM, I moved across different teams within IMS and had various software developer roles. I remember my first role as a technical support engineer, and it was one of my favorite roles.

My peers used to debate the merits of working in technical support versus development, and I always agreed with the sentiment that diagnosing customer issues and creating solutions was fun because every case was a new puzzle to solve. Taking that sentiment more broadly, it was true across my career: every new role was an opportunity to solve a new problem with new obstacles to overcome.

Reinventing Yourself Without Leaving the Mainframe

During my career, the technical challenges and projects varied, but the most difficult obstacle has been life. IMS was a great product, and I worked with many wonderful teammates and customers who helped make the job very rewarding. The downside of working on IMS was that I had to live in Silicon Valley, one of the most expensive places to live and raise a family. Keeping up with the cost of living while it increased exponentially proved too difficult, and I had to leave IBM. Leaving IMS behind was one of the most difficult decisions I made because I had found a job I loved and thought I’d be there until I retired.

I was anxious when I made the leap from IBM to BMC and their AMI Ops infrastructure products, but that feeling quickly faded because I ended up working with another excellent team at BMC. As hard as it was to leave IBM, working at BMC was a great opportunity, and I got to learn an entirely new area of the mainframe that I never would have known if I had remained at IBM.

Everyone I’ve worked with is trying to do a great job with almost no exceptions. As an old millennial who grew up with video games, I can’t help but think about my teammates as NFL or MLB players or Role Playing Game (RPG) style characters: some people have different skills and strengths. Some of those skills align to their current role, and some do not. If someone isn’t doing a good job on a particular task, then it might just not be in their wheelhouse, so you try to find them an area where they can excel.

For example, I knew a developer who couldn’t debug things from dumps and traces, but if they could recreate the problem they could solve it. They had a unique skill for recreating a problem from a client’s external description. When they shifted to work in quality assurance, they were able to leverage their knowledge and during design descriptions of a function into functional tests and find defects no one else would have found.

As for myself, I found that I could pivot in my career by taking these actions:

• Reading product documentation and reviewing any educational materials on the products.  If the product is using some IBM functionality under the covers, then reading about those functions was also required. 
• Building test scenarios to understand the interfaces that I needed to exploit.  Sometimes this could be as simple as JCL but later in my career it was often more complicated with scripts interfacing with various functions or even using distributed environment interfaces to interact with the mainframe.
• Building scaffolding code to get to the most challenging and unknown issues quickly.  For example, when creating code to exploit zEDC, it was important to quickly get to calling the code to learn how to interact with the API.

  Not every interaction in my career was positive. Some of the most challenging people on my teams were outstanding programmers. Unfortunately, it was common for them to hoard attention for themselves and rarely acknowledge the work of others that made their projects successful. In these circumstances I usually spend time testing functions that I didn’t understand fully and bring solutions forward for review.  When presented a solution wasn’t quite right because I was missing information they’d fill in the gaps and share some knowledge with me. 

Despite the difficulty, I learned you should share credit and knowledge with others who help you along the way because you are not going to solve every problem by yourself.

Appreciating your peers helps improve team morale and makes work fun. Having fun offsets those difficult days when you can’t find a problem’s solution. For example, when we had a wave of customer defects, I gave our senior software quality assurance engineer Clayton Westphal  a box of small green stuffed creatures to represent all the bugs we were working on.

One key thing I’ve learned about the mainframe is that it’s built on generations of knowledge, and it’s very resilient. I’ve worked with amazing people.

At BMC, I was lucky to work with lead product developer Bill Blair, who amazed me with his knowledge of z/OS. At IBM, base primitive environment (BPE) architect and senior software developer Bruce Naylor could explain anything, simplify any concept, and create amazing code, but he wasn’t above drafting a quick solution to get around a design issue.

Similarly, at Broadcom, Master Engineer – Tape Storage and Management Russell Witt can explain various tape configurations and environments to always be delivering continuous enhancements to customers. They are all great, but eventually they will retire, and it’s daunting to consider having to fill their shoes. That’s when I remember what my mentor Claudia Ho said, “You can’t replace them.” But I also learned that you can’t let that stop you. You need to dive into problems to solve them.

Here were some steps that worked for me during my career:

• Read the product documentation and educational materials or as people told me when I was getting started “Read The Fine Manual” (RTFM). 
• Talk to the last few people that got hired and ask how they learned about the product.  Everywhere I’ve worked people have had similar getting started questions and issues.  Some people will have documented what they’ve learned on internal documentation or wiki pages that you can read.
• The most difficult one for me was learning how to read the IBM documentation.  IBM communicates with a specific style that isn’t always clear, it can take a while to learn how to read their documentation and educational materials to extract all the value.
• Learn how to use your product by testing it and trying different scenarios.  Get sample JCLs and scripts from your peers that have been doing it for a long time.
• Learn how people debug and perform diagnostics on their product.  I’ve seen people use XDC/SLD and others get by with CP trace.  If you’re lucky there will be some type of flow tracing or at worst maybe nibble traces.
• Find time to keep up to date with the new trends and directions on the mainframe, even if you can’t exploit them now on your product because they could make you more productive in the future to make up for your lack of knowledge.       

Working on the mainframe is a continuous challenge, and one I’ll never master because the platform is so large and complex. I’ll never be bored because there’s always a new challenges around the corner. I will also always be recruiting more people to help build a strong team of contributors to keep the platform going strong after I eventually retire.

Jeff Fontaine is a lead software developer currently working at Broadcom on CA 1, Disk Backup and Restore, and Allocate. Jeff has previously worked at BMC AMI Ops (MainView) Infrastructure and RTCS, as well as at IBM on IMS.

Learn more about working in a multigenerational workforce with "Creating a Thriving Multi-Generational Workforce."