I've worked with such niche enterprise software before. It only pigeon-holes you if you let it. One I worked with was, at the time, a VB6 based application for

I've worked with such niche enterprise software before. It only pigeon-holes you if you let it. One I worked with was, at the time, a VB6 based application for trading bank debt built on a combination of SQL Server/Access (SQL Server was the source of truth, but entire data sets would be pulled into a local Access database for reporting...). It had no integration points to speak of, not even a reliable report runner (had to run reports manually through a GUI). Over the years, they were doing a piecemeal transition to .Net, but I never saw a .Net only implementation while I worked with it (I left the company in 2012). A lot of my Python expertise on Windows comes from working with that system. I used Python because 1) I already knew it, 2) I could easily run parts on either Windows or Linux and 3) all of the internal APIs I needed access to had Python wrappers available (or I could easily write one in Boost Python at the time). I forget exactly which Python libraries I used, but there was some Win32 COM going on, some ctypes and other Python based GUI automation, as well as a lot of process management (reports tended to hang quite a bit needing killing/restarting) and ETL work. I spent roughly 7 of my 9 years at that company working in part on maintaining the integrations of that 3rd party system with our own internal systems. Yes, a significant chunk of my time at the company, but what software it was is just a footnote on my CV. Instead all of the interesting integration work I did and the efficiencies gained are elaborated upon (e.g. with 8 hours of development effort, I was able to automate away a previously 8-hour manual task that had to be done monthly).