Sure - for example we migrated all our stuff from MySQL to MariaDB.

It was completely painless, because all of the source code and many of the people who wrote that code migrated to MariaDB at the same time. They made sure the transition was effortless. We spent a months second guessing ourselves, weighing all of our options, checking and triple checking our backups, verifying everything worked smoothly afterwards… but the actual transition itself was a very short shell script that ran in a few seconds.

I will never use a proprietary database unless it’s one I wrote myself and I’d be extremely reluctant to do that. You’d need a damned good reason to convince me not to pick a good open source option.

My one exception to that rule is Backblaze B2. I do use their proprietary backup system, because it’s so cheap. But it’s only a backup and it’s not my only backup, so I could easily switch.

I’m currently mid transition from MariaDB to SQLite. That one is more complex, but not because we did anything MariaDB specific. It’s more that SQLite is so different we have a completely different database design (for one thing, we have hundreds of databases instead of just one database… some of those databases are less than 100KB - the server just reads the whole thing into RAM and slow queries on our old monolithic database are less than 1 millisecond with this new system).

never use anything vendor specific like stored procedures, vendor specific datatypes or meta queries

Yeah we don’t do anything like that. All the data in our database is in a JSON type (string, number, boolean, null) with the exception of binary data (primarily images). It doesn’t even distinguish between float/int - though our code obviously does. All of the queries we run are simple “get this row by primary key” or "find all rows matching these simple where clauses. I don’t even use joins.

Stored procedures/etc are done in the application layer. For example we don’t do an insert query anywhere. We have a “storage” object with simple read/write functions, and on top of that there’s an object for each model. That model does all kinds of things, such as writing the same data in different places (with different indexes) and catching “row not found” failures with an “ok, lets check if it’s in this other place”. That’s also the layer we do constraints which includes complex business rules, such as “even if this data is invalid — we will record it anyway, and flag it for a human to follow up on”.

In my opinion the best developers are “generalists” who know a little bit about everything. For example I have never written a single line of code in the Rust programming language… but I know at a high level all of the major pros and cons of the language. And if I ever face a problem where I need some of those pros/don’t care about the cons then I will learn Rust and start using it for the first time.

There’s not much benefit to diving deep into specialised knowledge on any particular technology because chances are you will live your entire life without ever actually needing that knowledge and if anything, it might encourage you to force a square peg into a round hole - for example “I know how to do this with X, so I’m going to use X even though Y would be a better choice”.

Wikipedia has a list of “notable” programming languages, with 49 languages just under “A” alone and I’ve personally learned and used three of the “A” languages. I dislike all three, and I seriously hope I never use any of them ever again… but at the same time they were the best choice for the task I was trying to achieve and I would still use those languages if I was faced with the same situation again.

That’s nowhere near a complete list - which would probably have a few thousand under “A” alone. I know one more “A” language which didn’t make Wikipedia’s cut.

The reality is you don’t know what technology you need to learn until you actually need it. Even if you know something that could be used to solve a problem, you should not automatically choose that path. Always consider if some other tech would be a better choice.

Since you’re just starting out, I do recommend branching outside your comfort zone and experimenting with things you’ve never done before. But don’t waste time going super deep - just cover the basics and then move on. If there’s a company you really want to work for, and they’re seeking skills you don’t have… then maybe get those skills. But it’s risky - the company might not hire you. Personally I would take a different approach, try to get a different job at the company first then after you’ve got that, start studying and ask your manager if they can help you transfer over to the job you previously weren’t qualified for, but are qualified now. In a well run company they will support you in that.

As for learning outside of your 9-5… you should spend your spare time doing whatever you want. If you really want to spend your evenings and weekends writing code then go ahead and do that… but honestly, I think it’s more healthy long term to spend that time away from a desk and away from computers. I think it would be more productive, long term, to spend that time learning how to cook awesome food or do woodworking or play social football or play music… or of course the big one, find a partner, have kids, spend as much time with them as you can. As much as I love writing code, I love my kid more. A thousand times more.

Programming is a job. It’s a fun job, but it’s still a job. Don’t let it be your entire life.

what’s wrong with just texting

If you have friends in another country, it might cost a quarter every time you send a message.

In regions of the world (e.g. Europe, and a lot of Asia) where some countries are the size of a large city (or perhaps the entire country is one city), that’s a problem. You’d be sending international texts all day every day.

I seriously doubt they removed seats because people were sitting on them.

More likely it was costing too much money.

At least in my city, some people don’t just sit on a seat (or sitable landscaping feature like a low wall). They eat on them, drink alcohol, leave behind food scraps rats eat the food, bottles get smashed, some people even go to the toilet next to the seat, etc. And yes - there are rubbish bins and toilets nearby.

Sometimes it’s worse, bloodstains, fights, etc.

The only parts of the city that have seats are cleaned three times a day and heavily policed with plain clothes officers on foot patrolling the area 24/7/365. That cost wasn’t necessary 10 years ago but it is today. We could go into why but that’s largely irrelevant.

I fundamentally disagree with the idea that these are competing strategies.

Just like walking doesn’t really compete, like at all, with flying in an aircraft, Functional and Object Oriented Programming are at their best when you use whichever approach makes sense for a given situation and in any reasonably complex software that means your code should be full of both.

OOP is really good at the high level structure of your software as well as efficiently storing data. FP is really good at business logic and algorithms.

Also, I take issue with the claim that OOP is all about “objects”. It’s also about classes. In fact I’d argue classes are more important than objects.

Supposedly if you spend about 10 minutes reading tweets, skimming through replies, etc, you’ll hit the 300 post limit and be unable to use the app until the next day. Only letting people use the site for 10 minutes is clearly bad. And most people just are not going to pay to be able to use the app.

I don’t see how this limits bots at all. You can simply spin up a hundred thousand bots and you’ll be able to crawl 30 million posts a day. At best it will slow bots down for a week while they refactor how their systems work.

This really only affects legitimate users.