I would assume one major thing here is that many orgs only need a small subset of functionality from what most products provide. Many times, that small subset of functionality is only "good enough" in and of itself, but the org is paying the premium for the entire suite of whatever it is. This makes realizing that an LLM can get them to MVP and beyond much easier.
Charging hundreds of thousands if not millions per year for very basic functionality is what is "killing" b2b SaaS.
There is also the benefit of being able to use a single database (and hence schema) across multiple "apps". In many cases the complexity arises from the fact that all these apps have their own databases.
I'm not sure if this is the right place to ask, but does anyone else still work in an environment where they have to do synchronous version control? It's a nightmare and I have yet to find a decent solution.
To give an idea, this is a proprietary system that is extendable via scripts, but all of the artifacts are exported via XML files where script source is escaped into one XML tag within the metadata. Same with presentation layers, the actual view XML is escaped into one line within one attribute of the metadata file. The "view" xml may be thousands of lines but it is escaped into a single like of the export file so any change at all just shows that line as being changed in a diff. Attempts at extracting that data and unescaping it even seem to present problems because when the XML is exported often times the attributes within the schema are exported in a different order, etc.
I recently took a job maintaining and extending the functionality of an enterprise Enterprise Asset Management product through its own scripting and xml-soup ecosystem. Since it is such a closed system with a much smaller dataset of documentation and examples, it has been great at using what it does know to help me navigate and understand the product as a whole, and how to think of things in regard to how this product works behind the scenes in the code I cannot see.
It doesn't write the code for me, but I talk to it like it is a personal technical consultant on this product and it has been very helpful.
I don't doubt that is certainly a motivator, but I also don't disagree that a formal study on the effects of flooding corn fields en-masse is in order.
If I put corn in a pond to hunt waterfowl, I go to jail.
If I put pond in the corn, I can charge $10k+/yr to hunt my personal duck park.
My son loves trains. There are a couple of state parks near me that have tracks running through them and I once tried to find something like this / flight tracker for trains and learned their security / obfuscation around that seems to be on the same level of submarines? Why?
The British rail system releases as open data(JSON over AMQP) all train movements down to indidvidual signal blocks
You can view some of the the live maps here: https://www.opentraintimes.com/maps, but this is unique as far as I know.
I don't think it's really down to super-tight security as such, rather that there's no reason to release the data publically.
Ships and airplanes broadcast data because it's useful for collision avoidance and tracking. The international maritime and aerospace system is far too complicated and large that you could ever build a private network of every ship or plane operator sharing encrypted data, or that one company could set up receivers for the tracking data worldwide. A closed system wouldn't work.
Rail is both physically and legally a finite closed space. The network operator knows definitively where every train in their network is because they have sensors in the tracks. The network is responsible for preventing collisions, not the individual trains. They have contracts with every company which operates on their tracks and if these need their internal data they can get it. So there's simply no good reason why trains should be publically broadcasting their information, or why network operators would want to expose all their internal data.
And against the no positives there are negative sides - apart from a couple of famous cases I've not heard of it in Europe, but stealing from cargo trains seems to be big business in the US: https://www.latimes.com/california/story/2022-11-17/los-ange...
In the UK the open tracking data also brought complaints from freight companies who feared competitors would use it to analyse their movements, figure out which traffic flows were the most profitable and use it for commercial advantage.
Also, if you're a plane or a boat it's really important everyone knows where you are for general safety / rescue reasons. On a (consolidated and decently organised) railroad the railway operators can take care of all of that.
There are a lot of factors that go into achieving success in the workplace. There are usually competing ideas of what success is to you, versus what it is to the one rating you or paying you. You have to, at some level, appear to be good at something they think is good to have around. Sometimes that aligns with what you think is good, sometimes it doesn’t.
Of course the advice in OP is going to be relative, but it’s not a bad rule of thumb to have a good sense of what your immediate does, how they think, what metrics they value, etc. If not for your own advancement- keeping immediate leadership off tilt can greatly increase QOL, or vice-versa. I personally would love to have leadership above me that I think "damn, I'd like to be a little more like that guy" but in almost 20 years of being in the workforce, including military and the likes, that kind of leadership has been hard to come by.
Paper Credentials: I'm going to stack on a masters degree and some more certs. As a kid I was into development and anything tech, but for some reason resisted formal education or even working in the field. I spent my summers and school breaks working different construction trades as my entire family was spread out amongst the trades. After the military I did an entrepreneurial stint, then I took the comfortable, "guaranteed" route, in regard to career- wherever I could land in the US Fed. Govt, where I did about 12 years in 5 or so different positions... I was raised to, and had always worked hard - but I never really had much risk in regard to losing my job until recently.
Preceding wall of text to explain how hard the realization hit, for practically the first time in my life, when stuff started going crazy in the feds: "damn... I really could be ~6mo away from losing it all." As many of you know, the market was and is ridiculous. Thankfully a few years back, even when I "knew" I didn't need it, I finished my BS:CS before my GI Bill dried up. And then as another challenge took the Security+ exam before I started applying for a job in the private sector. A lot of people in this industry like to say none of that matters-- which might certainly be true, but I can say without a doubt that those pieces of paper are the main reason I was about to get out of the hole I was in. I'd rather not be in that position ever again, but I'd like to be well prepared "on paper" if I am.
There are entire niches of us that make a living (not at IBM) making certain IBM products actually do what they're supposed to. From my vantage point I see essentially zero maintenance going on with their products. I sincerely don't understand the market (why do people keep paying hundreds of thousands to millions of dollars for non-existent support?) - but whatever.
Charging hundreds of thousands if not millions per year for very basic functionality is what is "killing" b2b SaaS.
reply