HN Explorer

Ask HN: How to transition to mainframe development

4 points by jetti ↗ HN
I am a sr software developer with 6 years of C# experience and am itching to get into mainframe development with COBOL or even assembly. I have a few months professional experience with COBOL but don't know how to make the transition to a full time COBOL gig. It isn't as easy to pick up COBOL like C# is since the ecosystem is very limited. I have a MS in CS but didn't touch any mainframe type content so I have no formal education in this either. Is the only option to really apply for entry level jobs and take a pay cut?

2 comments

[ 4.5 ms ] story [ 13.6 ms ] thread
taylodl
I'd look into GnuCOBOL (https://open-cobol.sourceforge.io) or try a free download of MicroFocus (https://www.microfocus.com/products/visual-cobol/). I work at a shop with legacy Cobol applications and more and more of those folks are preparing for retirement. Thing is, those applications are the bedrock for running the business. As such they are so starving for new blood so I don't think they'd immediately dismiss the idea of paying for Sr talent and getting someone who's still coming up to speed in Cobol.

But there's one question you'd better be prepared to answer and answer it spot-on, and frankly it's a question I have out of simple curiosity: why? Why do you want to do Cobol development? Why do you want to change tracks to one that appears to have a dead end in the not-too-distant future? How do I know that after incurring the effort and cost to bring you up to speed that you're not going to leave? How are you going to deal with experienced people who are very comfortable with the tools and processes they have in place and have little interest in changing how they do things?

I'm curious, but your interviewer is going to be serious.

jetti
Thanks for your response, I'll take a look at GnuCOBOL.

As to why I want to do COBOL development, I think there are interesting problems. I enjoy working on an existing product and all that comes along with it (bug fixes, enhancements, etc). I want to change domains because I want to be at the heart of a business's process. When I worked at a clearing company I volunteered for take over the COBOL development when the contractor suddenly left. It's hard to describe the rush that I got from learning the code base and working on it. Knowing that what I'm doing is vital to the company (it was the clearing engine that was written in COBOL) is a source of pride to me. Thinking about it now, learning COBOL and dealing with that code base was my favorite part of my previous job (and I liked the previous job too). How many people can point to their work and say they are critical to the operation of their organization? How many dev jobs really affect as many people as one can as a mainframe dev (of course, the number can depend on the organization. Chase is going to affect more than some small bank but it is still going to affect a large amount of people).

Sure, COBOL may be dying but the business knowledge gained while doing the COBOL development won't go away and that is an advantage. I have learned programming languages in the past and I will continue to learn more in the future. It is something I enjoy doing, so I would have no worries that if COBOL were to die out while I was working as a COBOL developer that I wouldn't be able to find work doing some other sort of development. As for dealing with experienced people who are comfortable with their tools and processes, that is no different than any other job. Some people are willing to learn other things and some people aren't. It is a matter of finding a happy medium and in the beginning I wouldn't have a leg to stand on when it came to tools and processes because I would be just learning.

Sorry, I think I started rambling but I it gives some insight as to why I want to make the switch.