Indeed! Skills and abilities matter a lot. So do personality and attitude. I'll attempt to condense this so it's not so long (and will probably fail)...
I've been a System Programmer since the mid 70's and I guess I've got a significant aptitude for it. However, very early in my career I personally struggled with self-confidence. I never allowed myself to think of myself as anything "special", in fact at the time I felt a little inferior to most. As a result, whenever someone came to me with a question, my internal dialog went something like this, "This is something that's really easy for me, not hard at all, therefore since I'm nothing special you must be asking me because you're lazy and can't be bothered to look for it yourself." I never actually SAID that out-loud, but others picked up on my attitude. Several years later, I was conversing with a friend who worked in network control and she shared something very eye opening with me. Apparently, among the operations staff, it was almost part of their on-boarding training to include something like, ".... and if you're ever working a problem, don't call Robert because he'll make you regret it." Whoa.. what a wakeup call that was. The thing that's really strange to me still, is that once I started to allow myself to think, "maybe I do have some skills and talents that not everyone has", things got much better. I stopped sending out those 'negative waves' (do you know that movie?) to people and became actually helpful. Now, one of my very favorite things to do is teach and try to pass on what I know, and I've been told I've got a talent for it. Go figure.
Fast forward a few years to the late '80s/early 90's and I was working as a consultant, doing mostly networking system programming (VTAM, SNA, NCP) for a client, and I needed to run a network trace to shoot a problem. Consulting is a favorite of mine, and it has some 'weird' properties both positive and negative that normal employees don't face. On the positive side, client management will listen to you when you tell them the very same things that their own staff has been telling them for years even though they had up to the time YOU said it, ignored them. I think that's probably because they realize they'll look pretty stupid for bringing you in and paying you "all that money" if they don't listen to what you say. On the negative side, the staff who know what's really going on will usually tend to not trust you and see you as somewhat of a threat to their jobs.
Anyway, back to that network trace. I ran it, found and fixed the problem. I was working with a staff sysprog there who was very much in the "I don't trust this guy" category when it came to his view of me. The next thing I did after fixing the problem, was I took him and walked him through everything I'd done, how I'd done it, and why. About halfway through that, he stopped me and straight up asked me, "Why are you showing me all this??" because in his prior experiences with consultants, they had never shared any details with him and had always tried to keep their "arcane magic" to themselves. I told him, "Well, a few months and I'm going to be on to the next gig but you'll still be here and things like this will be on you to handle, so you need to know how it's done." From that point on, he was my "best buddy" there.
I'm really proud of all the "magic code" I've cranked out over the years, I've written MVS (now z/OS) SVC's, Subsystems, done a lot with Cross Memory Services, Access Register Mode, Page Sharing (one of the best kept secrets in MVS), sleuthed out how to use undocumented system API's to solve specific business problems, and I consider Assembler to be my native tongue, but the things I tend to remember most are the interactions with people like the ones I've written about here.
Another thing my system programming mentor said to me back in the very early 1970's when I was still just a 'lowly' operator: He'd shared with me how much he'd charged a client to pull of a significant project over a weekend, and I was stunned by the amount. What he said was, "Oh, they'll gripe but they'll get over the money. However, what they'll never get over or forget is if you can't do the job."
------------------------------
J Robert Garrett
Garrett Family Enterprises
------------------------------
Original Message:
Sent: Fri March 14, 2025 10:25 PM
From: Lezlie Browder
Subject: Is Mainframe Culture better at Inclusion and Diversity than other Technology teams?
Since 1979, when was a Programmer Trainee in a large insurance company, it has been the mainframe, colleagues and me 24/7/365 coding, answering client questions and sometimes just having fun to release the tension. It was not an environment like a War Games movie! So, no really really smarter than everybody tech heroes existed. The environment was very hands-on. We all started in 'maintenance' (fixing bugs). Thus, reading code was a valuable skill. On Friday mornings, we (junior programmers) would have 'walkthroughs' with the senior (meanies) programmers. One junior programmer walking through logic to fix an issue with three to four senior programmers (the meanies) challenging their solution. If you could fix code, fast, quick and efficient, your identity was not part of the issue. ..so you colleagues would review your logic with you prior to the walkthrough.. everybody needed that reassurance when it was their turn.
Sometimes, you looked at the name of the last person whom updated the code and have an one-on-one with them! Just pop into their cubicle (at first there were NO Cubes). So just sit in the chair next to their desk and ask questions. I am a African-American female with a quick dry dry wit... sometimes condescending and sometime compassionate .... The dry wit was the issue. (I got much nicer after I started running marathons and learned to be humble.) We focused on the work because the code was a departmental goal. Thus, somebody's code had CALL statements to your colleague's code... No matter: who, what, where, etc. The only problems were if you used GOTOs instead of CALLS ... stuff like that than you have a big problem.
Mainframe is foundational with platforms resembling the NYC subway. The important issue is to know where you are going and how to get there. As challenges, wins and loses happened we were interconnected biases were not productive.
------------------------------
Lezlie Browder
Chief Solutions Architect
Original Message:
Sent: Thu February 20, 2025 02:26 PM
From: Lionel Dyck
Subject: Is Mainframe Culture better at Inclusion and Diversity than other Technology teams?
In my experience going back to 1972, the key things that anyone cared about was skillset and integrity. If you can do the job and are honest about things then you will be accepted. If you claim to have a skill and prove you don't, which proves no integrity, then you will not be accepted. Introvert or extrovert does not matter.
------------------------------
Lionel Dyck
Original Message:
Sent: Thu October 03, 2024 02:33 AM
From: Ruth Bonser
Subject: Is Mainframe Culture better at Inclusion and Diversity than other Technology teams?
I have been involved in the Diversity, Equity and Inclusion space longer than in mainframes and sometimes being one of the newer people in the team gives you a different perspective to offer. I think when it comes to diversity and inclusion in tech, something special is happening in our corner of Technology.
We thrive on teamwork. Unlike distributed systems that expect more isolated work, mainframe is a shared environment that necessitates collaboration. Changes can impact the entire system, requiring us to work together and consider various viewpoints. This naturally breeds inclusion. We don't just tolerate different voices; we rely on them for success. In our complex work environment, no single perspective can succeed alone. Here, diversity of thought isn't a buzzword – it's essential to getting things done.
In a world of laptops, mainframers are unconventional and this is a strength. Our experience as outliers has taught us to value differences. Mainframe technology excels in specific tasks, much like how diverse perspectives drive innovation further than what groupthink can achieve. Our niche position has transformed us into champions of unconventional technology, it is not so far to become a champion of unconventional choices for our people too.
We're currently facing a skills shortage in the mainframe world, but I view this as an opportunity for transformation. It's our chance to welcome fresh perspectives and diverse talents. When we need to replace someone who is retiring, we can look to individuals from underrepresented groups. We can benefit from having new voices, ideas, and approaches.
Do you agree that mainframe seems like an environment that will be better at embracing a diversity of people or do you think it is the same as other technology teams? Why do you think so?
------------------------------
Ruth Bonser
------------------------------