Just fair warning: you seem to be under the assumption that “boring” means “straightforward and just makes sense.” It does not. If you’re looking for that… good luck! Update if you find somewhere and I’ll join you.
Many use a lot of proprietary software, which can be a type of hell nobody understands till you end up as an expert in a niche area and spend your day dealing with vendors and tech support to fix anything. After 5 years you are an expert on "EnterpriseSoftwareCorpA On-Prem Elastic Scaling Stack and Integration to EnterpriseSoftwareCorpB On-Prem Data Stack" which nobody really sees as valuable, so you are now trapped in your career.
I know a bunch of people who wisely let go of 10+ years of their experience in some aging software so they could start again as an AWS solution architect. I'm sure it's was brutal doing that in their 40s/50s, with family, etc. It was tough, but 2 years later they are in a far better career position than those who are still praying for something to happen with those Enterprise stacks.
A lot of the hell that is enterprise software is how systems talk to each other. I'll give an example. Project is started to bring data from Vendor A Product into Product from Vendor B. Vendor A claims system is "open" but there is no documentation outside of some cryptic .NET examples. Even when a successful connection is made, the data and data model makes no sense and nearly impossible to map to what users see in UI.
Vendor A gets a call. Vendor A repeats "open" and brings an "SME" to explain data model. SME is really a Sales Engineer who concludes Vendor A has another product that will expose the data in usable way. Start evaluating this product, and it turns there is a lot overlap between features in Vendor A new product and Vendor B's product. Plus, you still need to use .NET and a proprietary connection to get data from A -> B. Plus,Vendor A's new product does data transformations in a black box..nobody knows what exactly.
Vendor A and B are pointing fingers and each trying to make a case for why their product needs to do X features. Nobody understands this .NET library, so a consulting company is used to build data pipeline from Vendor A -> B.
Granted, a lot of the above wouldn't be acceptable today and a lot of these types of systems are going away and being replaced by ones that are actually designed to be interoperable with other systems. This type of story is hopefully going away sooner than later.
I use a lot of proprietary systems in my current job at extra-big company, but at least they use stuff like SQL, RESTful APIs, etc. I can understand our Data and how it maps. Those are transferable skills.
I can only hope that FAANG isn't building systems where everything is proprietary and make no sense to anybody outside of the Eng team that built them.
I'm under the impression that gRPC is popular, and in some places GraphQL.
That being said, companies like GE, Siemens, and PTC are trying desperately to capture that space as well with their Saas/PaaS.. I won't say they are crap, but it's just more lock-in under the guide of "open." One of them has already gone the way of Watson.
YMML will vary in manufacturing. If you can jump to one of these companies that is on their journey from legacy systems to more open ones, you can definitely land in a good spot. Just ask the right questions when you interview there.
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).
And more of “places running near archaic .NET/JVM versions that somehow manage to combine bureaucracy with lack of organization”.
Majority of the services were older .NET framework projects with some other stuff scattered around. They had a sizable mainframe team, but we’re trying to migrate away from that platform.
I have a friend who works for a major low-code software company. They're doing quite well financially because of all the excitement around low-code. The product is good if you stay within the boundaries of what it can do. Some managers people think they can replace their enterprise Tableau/Spotfire/PowerBI license with low-code and they get bitten very badly.
Finding engineers for a low-code environment is a challenge. You need to understand software development well enough that you can build something because loops, conditional statements, all of those concepts are there. You also need to find somebody who is willing to possibly lock their career into a single tool and forgo the benefits of knowing a general purpose language like C#, Python, etc.
Some companies have success with finding technically minded business people or IT folks who don't enjoy coding and training them. They can thrive and build some nice apps. Lots of folks can't make the leap and fail. Software Engineers are probably the worst bunch to try an convince because the opportunity cost is too high.
Business / money making / crucial systems? No. Some random HR survey application? Maybe. Sadly Microsoft seems to have convinced a number of folks in our organization that this tool set is appropriate for all our development.
I would recommend anybody this approach.
Rule of thumb for Germans, if they write a fax phone number on the imprint or the website looks 90s style... don't waste your time, skip them.
I went to visit out there and kinda dig the area.
I suspect that there's a fair amount of overlap—not total, but quite a bit—between companies that were doing old stuff The Right Way, with lots of well-considered automation and high-quality backups and well-documented, repeatable, largely scripted configuration, and companies that are on some of the "sexy" tech now. So it might be even harder than it used to be to find a company doing things the "boring" way but who don't have a horrible, barely-functioning mess on their hands.
I'd think some of the nerdier, niche tech places probably run things OK and not super new-school. Something like Rsync.net, maybe. Possibly places that like BSD in general will tend not to be on the new hotness. Difficulty: those sorts of places tend to have pretty low head counts so it may be hard to land a job at one (go figure, much of the tried and true stuff Just Works and doesn't require a ton of babysitting if you halfway know what you're doing)
Are there any examples of this? I’m coming up on 20 years into my career and i’ve genuinely never seen a large company that had their IT function ticking over sweetly. Every single one had aspirations and had some things nailed to a greater or lesser extent but none were “done”.
If anything, things are a LOT better today. The old mis-configured MS Exhange host hanging off the office DSL line is gone these days. The MD / CEO’s password is unlikely to be Password1 nowadays.
Well, yeah. It’s been 10 years, and we need to change the password every 3 months, also, you told me not to use ‘Password’, so the password is now ‘CompanyName40’
If you happen to be looking for a DevOps or SRE role, check a large banks job boards, you'll be surprised how many open roles are available.
The point is - it's difficult to make generalizations about orgs that big.
If only it were so... A lot of teams in these companies are heavily into fad-chasing, so your random internal web app that has 1 user per hour will be deployed in fully-scalable manner on the company's k8s cluster (which is shit, because company didn't put nearly enough people into keeping it running).
I'll second this. Strongly.
It is not so much boring as more of an amalgam of scar tissue and duct tape that accumulates over time and is a maintenance nightmare. You might run into the rare place that does things "right" with old technology but those are rare.
I do think some new things are "crazy" but I'll take "crazy new" before "crazy old" most days of the week.
but of course it also depends on how clever the people beforehand have been, is it stuff tied to impossible knots that cross over 5 parallel dimensions, where nobody knows what it does or how it's doing it, just that "it somehow works, so we don't touch it, that guy was a wizard", or is it just layers of faith held together with duct tape and rope, where people tried to fix stuff over years, throwing in patches that "probably should help, I think, maybe", which could be condensed into less than a third of the size, when rewritten...
I've seen a lot of modern tech from other large companies too (banks, retailers etc.) - the culture and pace of development might be different but their tech stacks are very up to date. Even if some of those companies have an old mainframe still running somewhere, they have tonnes of other software too, most of it much more up to date.
And I think companies 500-1000 of the Fortune 1000 would be even more interesting to work for.