April 8th, 2020
I've recently stumbled upon articles (like this one or this one) about the need for COBOL developers created by the coronavirus outbreak. I've been working as a COBOL developer for one year and I'll talk about my experience and what you need to know before investing time to learn the language and looking for a job.
Let's be honest, it is not for everyone. If you love welcoming environments with table tennis, a great company culture and autonomy, you might not want to go work for banks and insurance companies. If you feel like you have something new to bring to the table like ideas or development practices this isn't for you. If you are more of a t-shirt guy than a formal suit person, you might prefer startups.
Environments using COBOL are stuck in the past. Do you think they would still be using COBOL in the first place if they were open to change?
The wages for working in COBOL are not much higher than the one you would get anywhere else as a developer. If they were, candidates would line up at their doors. Any developer can learn COBOL. It's not impossible to get started with. If it's easy cash, why do you think they struggle to hire people? Why are developers so reluctant to take these huge amounts of money? Maybe the working conditions don't outweigh the proposed salaries.
Once you are bored from your current COBOL job and want some change, what will you do? COBOL means only working for banks and insurance companies. Let's say you know Javascript or PHP, chances are you will have lots of opportunities. I have plenty of jobs offerings for React jobs in my LinkedIn inbox. If you have some years of javascript in your resume it should be the same for you.
Recruiters are competing for you. It drives wages up. If you lock yourself up in the COBOL dying ecosystem for too long, you'll have a restricted pool of employers and much less leverage to negotiate a raise. The situation for COBOL developers might be beneficial now but it won't last forever.
Lots of custom solutions and proprietary software. Lots of custom software too. I spent time working on a custom versionning software that was only used where I worked. Not time well spent.
COBOL is old.
When I worked with mainframes, we had to plug an ethernet cable directly connected to the mainframe on our work computer. That means no internet (for security reasons).
The development part happened in an 80 columns, 20 rows shell with a limited amount of colors. This is fun and makes you feel nostalgic for a minute or two but imagine having to develop on this for the rest of your career. What I love in development is using my brain to find solutions to a problem. I like when the tools I use help me focus on this task (things like syntax highlight, a linter, IDEs, etc.) I know that modern tooling exists for COBOL but you might be stuck in a job where no one uses this tooling (like I was) and it is very difficult to push new tools on older teams. You might struggle so much that you end up giving up because the fight is too exhausting.
Releasing code is also painful. To "deploy" your code, we had to copy and paste our source code to an in-house intranet platform that only worked on Internet Explorer 6. That's right, It was less than 10 years ago. On this platform we had to recreate our JCL cards USING DROPDOWN MENUS.
I'm not saying every company works like this. There might be some teams doing agile development and TDD (Test Driven Development) in COBOL. But you might have bad luck and land a gig in this kind of environment.
If you don't mind dealing with this kind of Rube Goldberg machinery of nonsense, then maybe that's a job for you.
I'm pretty sure you are not dreaming of accounting software. I see a lot more excitement from developers doing machine learning on bone fracture X-Ray pictures than from people coding simple math operations for accounting. You might actually enjoy it but be aware of that if you decide to go work in COBOL: it's only amounts, debits and credits.
The technical debt has been piling up for years. I've seen SQL tables with hundreds of fields. Lots of them were unused but no one would take the risk to remove them so they stay. I've seen unnecessary or inefficient chunks of programs still running, filing these unused fields. Rather waste computer time than take developers time to fixe it, right? If it is not broken, don't fix it.
If you like well-architectured software, are sensible to technical debt and want to take steps to clean the code base, you might not feel well in an environment like this.
You might be tempted to learn COBOL and go work for banks. The pay might be great (it can as well not be that great) but choosing this career path is far from being a no-brainer. Maybe that's the perfect job for you but if you value well-crafted software, like to learn re-usable skills, enjoy taking initiatives, then I suggest a hard pass on COBOL.