6 ms·
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.
by apohn 4y ago
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.
- valgeirg 4y agoYou are describing my positions today. FML
- PascLeRasc 4y agoThanks, it's so reassuring to hear this.
- isx726552 4y agoYeesh 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.
- spelunker 4y agoThis 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?
- apohn 4y agoQuestion: 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.
- gavinray 4y agoI have never worked at FAANG but have had coworkers + have friends that have. I'm under the impression that gRPC is popular, and in some places GraphQL.
- BerislavLopac 4y agoI prefer AAA - Amazon, Alphabet and Apple. Netflix is irrelevant, while Facebook is too evil.
- seanw444 4y agoIt'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.
- apohn 4y agoManufacturing 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.
- hermitdev 4y agoI'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).