
Ask HN: How to transition to mainframe development - jetti
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&#x27;t know how to make the transition to a full time COBOL gig. It isn&#x27;t as easy to pick up COBOL like C# is since the ecosystem is very limited. I have a MS in CS but didn&#x27;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?
======
taylodl
I'd look into GnuCOBOL ([https://open-cobol.sourceforge.io](https://open-
cobol.sourceforge.io)) or try a free download of MicroFocus
([https://www.microfocus.com/products/visual-
cobol/](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.

