Cant always say its hardwork... As a people observer there seems to be a lot of people coasting, or doing as little as possible, and yet get promoted, or they get into really high paying positions. This is far more common in larger corporations, where the visibility is lower.
In smaller companies the people are definitely worth their weight in gold as if they are not doing the work its very visible.
Looking at it from the perspective of StarCraft, doing a Blood Bath 1v1 against a bot its pretty straightforward. Adding another player to make it 2v1 has the potential to make it a lot easier, but there are moments where the bot could take out one of the players or at least pressure them enough to tax resources. Obviously, this all depends on the skill level of all the players/bots and their strategies.
Instead of the two players having their own base, they are running a shared base against a single bot. This makes it challenging as now the players are forced to communicate, or one can sandbag, but overall adds a bit of complexity. Though a shared base should allow one player to manage one aspect of the game while the other player manages the other aspect; such as building units and the base, while the other player navigates or harasses the bot.
It is possible to logically work together to get a better outcome, but the tools we have currently don't support that. I find this multiplayer approach intriguing as with the right formula could unlock a nice super power. As I would imagine having twice the mental bandwidth available such that more things are noticed or caught or imagined...
You just reminded me that 90s StarCraft did have a mode where 2 players would command a single “team”. Basically a single “player” with multiple cursors. It was rad! Haven’t seen the concept duplicated.
I would focus on the economy and my brother would do the military and fight the bots.
“Measurements taking of the person: foot and shoe weight, total weight including clothing, height and leg length, estimated velocity of travel at time, estimated duration of load”
I didn't but that's the case. More likely there was a limited chance to evaluate the issue and something like they had a limited time launch window, no replacement ready and it tested good. "Just put a little butter on it, it's fine".
These specialized tools are likely the cause for the increased complexity within Postgres. I would imagine that if we had more individuals focused solely on Postgres, there would be more discussions, articles, and solutions for a lot of the problems "solved" by adding more tools to the problem.
I don't understand why the answer is to always bloat the system with more specialized software and technical debt, instead of optimizing the existing system. If Postgres can truly handle all of these situations, then mastery of that one tool should be focused on.
I guess its more the rapid start-up mindset to get it up and running fast to sell the company, and leave the problem for someone else which is why a lot of our world is falling apart...
Yeah. I feel it's more of a "ticking all the boxes" situation than anything.
For example: I worked with Rails from 2009-2024 and I haven't come across a single Rails project in the wild that didn't have the queue du jour installed: sideqik+redis, delayed-job before, etc. And then since it's there, people just end up using.
As I don't want to repeat myself, with emphasis added:
> No Silver Bullet, No Free Lunch, and all that. If your problem domain really warrants something outside of relational storage, you're gonna pay that complexity cost one way or another. You can't escape it by shoehorning everything in Postgres, fantastic as a DB as it is.
So as not to bloat the system, you will end up bloating your Postgres installation instead.
Also, Unix principle/KISS: do one thing and only one thing well. Of course this comes back down to your definition of "one thing". "_Any_ Data Storage" seems to be your one thing but not for me. "Relational Data Storage" is a well-scoped one thing for me.
I'm not saying don't take advantage of the plugin system. But we must exercise good sense so as not to abuse it when we avail of its advantages. TFA's suggestion of "only after pushing Postgres to its limits, documenting why it was insufficient, and accepting the operational cost of the alternative" does not sound like good sense. It sounds like a personal and an organizational burnout waiting to happen. Wait until PG is at its limit does not sound like technical debt to you?
> If Postgres can truly handle all of these situations, then mastery of that one tool should be focused on.
Thus you have conceived the conundrum of The Database of Theseus: after how many plugins is your Postgres cluster no longer a mere Postgres cluster to the point where it is unreasonable for a seasoned/certified Postgres DBA to have a good grasp of the system in a reasonable time span?
This is almost textbook https://en.wikipedia.org/wiki/Inner-platform_effect in that this is the second paragraph of the "Examples" section. I acknowledge that Postgres' plugin system mitigates this somewhat but I just can't be convinced that all those plugins will play well with each other for all eternity and especially under stress (unless you make a PG instance for each sub-system, in which case, refer to my original comment).
For the record
- I've used PG for caching with UNLOGGED. Still had Redis for a message queue and other caching.
- I've used PostGIS because it made sense to be able to make geo query when latlon is already a (small) part of your schema.
- I've used JSONB but only because the alternative is Mongo. I still had an Elasticsearch cluster indexing all that data for search.
> When we were using Hypercard or BASIC to make dumb little programs, we weren't learning any of that stuff either, really.
> Making apps is so complicated now
Well that is not entirely true, I recall trying to learn game development. A lot of the time I spent was searching posts on web forums or asking questions in DAL/EF/Free/etc net and getting told to learn how to ask a question... not only that but I had learned it was better to write games not engines. Though I still managed to find out about GDI, which led me to DirectX, OpenGL, and then SDL. Those were scary... This is also when I learned about modding games, specifically Half-Life modding, which for some reason led me to creating bots for Counter-Strike just because I could and that is when I learned ladders are really difficult.
The load times of VC6 versus VSCode... yeah. I would bet you can load a VC6 project faster in OP's environment faster than VSCode could load the same project in a current environment.
In smaller companies the people are definitely worth their weight in gold as if they are not doing the work its very visible.
Yeah, I am jealous, but such is life...
reply