They’re outside of the “tech” industry. Look at companies 200-300 on the Fortune 500; their IT group uses boring tech.
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.
I used to work in a Customer facing role at a Enterprise Software Company that sold up and down the Fortune 500. I got to see a lot of different tech stacks.
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.
Yeesh I feel that way working at a FAANG (or MAGMA or whatever it’s called this week). I’m an expert at our internal systems and platforms, but that’s not a skill that’s transferable anywhere else.
This was probably the most surprising thing about working at a FAANG company (although in hindsight it shouldn't have been). What, you all don't use Jenkins, JIRA, Spring, insert-OSS-or-other-well-known-tool-here and instead have all this crazy internal stuff I've never heard of?
Question: Are the system you using open standards (e.g. RESTful APIs)? Do they have Data Models that follow some sort of sensible standard that allow for interop with other systems via sensible mechanism systems?
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.
It's kind of funny: I dealt with more garbage proprietary stuff (NetSuite for example) at my previous job at a tech company, but use almost all open-source stuff at my current job at a manufacturing company.
Manufacturing is in an interesting space right now. There's a lot of hype around Industrial IoT (IIoT) and IoT 4.0. A lot of companies are using that hype to ask for budget to migrate their systems to open source and systems which are more open.
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.
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).
Fair warning, many non-tech F500 may be less of “places running their setup out of a rack in a rando datacenter grandfathered into an affordable Edgecast plan running a LAMP stack on Debian using borg for backups?”
And more of “places running near archaic .NET/JVM versions that somehow manage to combine bureaucracy with lack of organization”.
Mind you, it can get even more archaic than .NET/JVM ("hey, never change a running system, plus, even if we wanted, we wouldn't have the money to pay for it")
A friend runs a small consulting business and he recently took on a customer running NetWare and a bunch of server side software. I'd take .NET/JVM over that.
The non-tech F500 I worked at several years ago is doing everything they can to abandon .NET/Java in favor of low-code tools. Their engineers are jumping ship and they're having a hard time finding replacements.
>in favor of low-code tools. Their engineers are jumping ship and they're having a hard time finding replacements.
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.
My nonprofit works with a very talented Microsoft consultancy to help our transition from on-prem servers to Microsoft 365 cloud. My main contact there (Director of Biz Operations) says they have transitioned most of their custom development from .NET to Power Apps/Power Automate. It's not the only toolset they use, but he says it's the right tool for many small-medium biz CRUD needs.
This is the direction my current employer is headed. I was sent on a week long course to evaluate the viability of PowerApps. While there is certainly some cool stuff in there, it just doesn't feel like we should be moving all our development there wholesale. There is certainly a time and place, or at least that is how it seems to me.
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.
Interesting, there was some low code at the last F500 I worked with, but mostly for very small tolls not requiring much of any business logic.
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.
Small-scale manufacturing is another good spot. I spent some years doing consulting work with a steel processing company. "Boring" tech, but interesting problems to be solved.
This is it. Currently at a local manufacturing company, and their in-house software runs mostly open-source stuff. No major proprietary headache to deal with, it's not a tech company so I'm not dealing with the obnoxious meetings and calls; and since the software I maintain is internal, I don't have to deal with angry customers. Coworkers let me know if something needs to be better, and I make it so. Simple.
For that you need a small/medium business where the owners realize that IT is fundamental to their business even if it does not appear to be so... and the amount of people open-minded enough to admit that is not exactly large.
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.
Thanks for the advice. I had an internship at medium-sized manufacturer in California, above SF a bit. Was really cool to be next to a bunch of CNC machines while writing some code. I think I’ll try to find that vibe again sometime.
> 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.
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)
>> 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
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.
> 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’
Not only risk aversion - they were really early in digitizing their baseline services, so many of them have quite old mainframes by now. It's difficult, expensive, and, as you said, risky, to change old code that the whole organization is operating against.
+1 to this. I've worked in tech but never enjoyed the "upgrade the system every 2 years approach." Banks and financial services are now regulated to be slow, methodical, and dependable post 2008. I found a manager I respect in a group that does work I'm curious about (options/futures) so it's a good fit.
Well, I work in finance and we do a lot of upgrades. We rarely touch the old COBOL systems. But we rewrite plenty of JSF and even AngularJS front ends. In fact, I created a system about 2 years ago that is currently being rewritten by a different team. So it does still change. I have never worked at a true tech company so I'm just assuming the change is slower.
The scope of IT at a JMPC or a BAML is massive, and has grown both through acquisition and organically over decades. Virtually any technology you can think of is most likely being used or (at least being supported) by some unit at the bank. In a recent year JPMC's IT spend was $12 billion. In my personal experience (at JPMC) I knew groups who were using Clojure and Scala (while my manager assured me such technology was not authorized at the bank.) I knew of groups on AWS, on e on Azure and some using an internal Cloud Foundry implementation. (My group was running bond monte carlo's in an abortion of an IBM compute grid system straight out of 1992.) I personally knew of Mongo, Cassandra, Oracle, Sybase, SQL Server and KDB installations. Kapital - possibly the most famous commercial use of Smalltalk originated at JPM.
The point is - it's difficult to make generalizations about orgs that big.
My (rather out-of-date) experience with banks is that they have no problem adopting new tech but they don't retire the old tech. Add in a bunch of mergers and you get an unholy mess.
I work in finance. My point was basically that the industry is usually slower to adopt the new stuff. Of course they will adopt cloud, but are the the first ones or are they 5 years behind the leaders. It seems they also tend to not change COBOL code often and are just adding new stuff in the new tech. So change still happens, but the scope and rate may be different than other industries.
> They’re outside of the “tech” industry. Look at companies 200-300 on the Fortune 500; their IT group uses boring tech.
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).
Often these are the types of companies that let numerous consulting companies run roughshod over their organization. You end up with a dozen different proprietary systems created by a dozen different consultants/contractors implementing the latest fad.
> under the assumption that “boring” means “straightforward and just makes sense.” It does not
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.
"crazy old" likely has years and years of people documenting all the workarounds and hacks that need to be done to achieve X
while "crazy new" might not have that much cruft, but you'll be stuck trying to figure it out by pretty much alone
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...
This might just be stereotype. As a single data point, I work at a large boring non-tech company - my team's ML runs on Kubernetes just like the cool kids do it.
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.
I'd think it probably just splits to two groups: 1) IT is critical, therefore we'll use modern tech that makes it more reliable or better, VS 2) Meh, It Works™, so why change it? We've got better things to do than figure out the latest pointless tech...(especially the case at smaller places, where there's less budget for the invisible backend machinery)
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.