←back to thread

Ask HN: Any active COBOL devs here? What are you working on?

234 points _false | 1 comments | 18 Jul 25 13:05 UTC | HN request time: 0s | source

COBOL legacy systems in finance and government are somewhat of a meme. However, I've never actually met a single person who's day job is to maintain one. I'd be curious to learn what systems are you working on?
Show context
mvdwoord ◴[18 Jul 25 14:40 UTC] No.44605163[source]▶
Not a COBOL developer, but working at a sizeable bank I witnessed the phasing out of their mainframes and AS400 systems. They ran some critical systems, both in retail and wholesale banking. They either converted to java, and optimized that code, but some COBOL code from the mainframe, and all of the AS400 stuff was converted into Micro Focus COBOL, which runs on Windows, which could be hosted on our Private Cloud. I worked on helping them migrate to our cloud infra, which was an interesting exercise. There was a very tangible cultural gap between the people maintaining and developing these applications and the rest of the organization.
replies(1): >>44605197 #
datpuz ◴[18 Jul 25 14:43 UTC] No.44605197[source]▶
Can you describe the cultural gap? I haven't really met these folks in the wild, so I'm curious what the programmers of yore were like.
replies(4): >>44605308 #>>44605640 #>>44605650 #>>44613965 #
FL410 ◴[18 Jul 25 15:17 UTC] No.44605640[source]▶
In my experience, it's usually lack of awareness about modern security risks, and lack of familiarity with modern infrastructure paradigms. The latter really isn't a problem since these systems are usually standalone, but the former does become a problem - they often are from a time where this just wasn't something to consider. As a result, these legacy systems are often using default passwords, have tons of crazy stuff exposed to the network, and are comprised of custom code written specifically for the business purpose (so the documentation is only as good as what they made).

On the other hand, these guys generally write pretty neat, lean code that is quick, reliable, and directly responsive to the business. The really fun thing is watching the users fly through the keyboard-only screens, sometimes with muscle memory that is faster than the terminal emulator can update - they're literally working ahead of the screens.

replies(4): >>44605695 #>>44605842 #>>44606216 #>>44607120 #
james_marks ◴[18 Jul 25 15:56 UTC] No.44606216[source]▶
Reminds of the DOS order management software I used in the 90’s.

ASCII tables, text only, with F key shortcuts. Hard to learn but blazing fast once you did.

Nothing modern approaches it.

replies(2): >>44607643 #>>44609650 #
deepsun ◴[18 Jul 25 17:39 UTC] No.44607643[source]▶
Reminds me of modern IDEs -- developers, both old and new, are too lazy to learn a complex IDE to speed up their work, even though it's their main tool for making money.
replies(1): >>44609474 #
datpuz ◴[18 Jul 25 20:30 UTC] No.44609474[source]▶
I don't think efficiency of navigating your IDE is a major factor in your productivity. If you like your setup, it's probably not going to matter a whole lot. The tool you make money with is your brain.
replies(2): >>44610365 #>>44610427 #
1. deepsun ◴[18 Jul 25 22:15 UTC] No.44610365{3}[source]▶
Hard disagree.

Few points I can easily remember:

1. Navigating the code, e.g easily see all the callers, navigate up/down the call tree requires static code analysis. Super handy while reading someone's else code, which is like 90% on large projects.

2. Quick refactorings. Often times I see people discuss in lengths what would/could be instead of just go and try it out quickly, seeing all the pros and cons. Many times I proven myself wrong by trying it out and seeing pitfalls I didn't see earlier.

3. Warnings: so many real bugs could've been prevented if developers had seen (or cared about) to IDE showing a warning. Many PR review suggestions are detectable by a proper IDE without wasting reviewer's time.

4. Hotkeys (what the parent comment was talking about) -- speeds up all of that, especially refactorings, freeing dev's brain for thinking of architecture and other problems.

I can go on an on. Sometimes it feels like 50%+ of AI usage for coding is to free up fingers, not knowing that they were already mostly free by using static analysis features/hotkeys.