You won't be able to change much, in my opinion. So you have to choose whether you stay and do it their way, or go.
There's a lot to be said about your situation, but I've found that oftentimes the only way to actually figure out if a job is for you is to try it out. I have had jobs in the past which looked really good from the outside, and I even got people recommending the employer and the team, and then when I started, it became painfully obvious that the place was nowhere near as good as expected. The opposite is actually less common in my experience - if if feels wrong and if people are telling you the company is not great, it probably isn't.
There's a reason why people like working at large and reputable companies. For anyone reading your CV in the years to come, a few years spent at such a company would look impressive. You do get the benefits you mentioned, like stability and salary, so that's a net positive in your current situation. Spending a bit of time there, maybe 1-2 years would definitely not set you back too far anyway, in terms of tech, experience, etc. so it might not be as bas as you imagine it.
Then, on the opposite side, if you really hate it now, maybe you won't start liking it down the line and it could be better if you throw in the towel sooner rather than later. I've had jobs where I was unpleasantly surprised at the start, then went through periods of liking my job and then hating it and then back to liking it, etc. All in all, when I look back, I tend to remember the better things, but I can also fully remember how awful it felt at times. If the primary reason for getting into the job was that you'd work on hard problems with top talent, and there's no way to get that in the near future, then why stay there at all? The current job market would probably allow you to find something very quickly.
It's really about how you feel about the job, I think. It won't probably hurt to start looking around for better opportunities, without rushing it. It does not sound like an emergency. Plus, this way you'd give it some chance at least. It's tough to be at a job which you don't like and it's all about figuring your priorities and sticking to them.
We implemented all that manually, more or less in swift (and sqlite), then react+redux, and on the back end - postgres and python+flask. Works flawlessly so far. We do have the same setup more or less, with listeners triggering UI updates and push messages signalling the clients to fetch data from the server. Then, on the server, we have two dbs -> one where we store each update or create message, in a postgres-based queue, and another one, in a normalised format which we use for login (it's way faster than replaying all messages from the queue).
There are complexities when you move beyond one or two tables, though - like maintaining relations, ensuring things get done in the correct order, that they get merged (we merge all attributes of each item - e.g. one client can change color, and the if another changes the text content of the item these will get merged), etc.
We gave up on the websocket part and implemented basic polling, because they were not supported by App Engine at the time (things might have moved on since then, which is a couple of years ago). Yet, for a note/todo/habit tracking app, it simply doesn't need to be real-time from our experience.
Have a play at https://www.mindpad.io/app/. You can see how it works if you open up the web app in two incognito tabs, or on an iPhone and the web.
The idea behind Mura Notes is basically to have lightweight disposable notes, which you don't have to provide any personal info to use and share.
Each note has two URLs, with one allowing editing, while the other one has read-only access. If you lose the URL, you essentially lose the note.
The front end polls the API every few seconds, so if you have the same note open in a few tabs you should see it changing as the content changes.
I've been using Mura Notes for a while now and I have a pinned and bookmarked "main" note, where I have links to other notes.
I used Postgres, node.js + express, and next.js + slate.js, and everything's on GCP. Since I'm the only user so far, it takes some time to spin up the instance when I access my notes, which is a little annoying (yet, cheap).
Also, I am an iOS user, so I noticed just recently that the todo editor doesn't work ok on Android, which is a problem with slate since the examples on their site also stuff up the same way. Other than that, I think it all works reasonably well.
Some other things to note are that there's a dark mode (top right) and that if you share a read link and a few people report it as abusive, the read link will stop working. The deletion of a note results in removing its content (and there's no versioning, so it is really gone), not the actual deletion of the link. And that's about it for now.
Future (major) plans include things like one-time pad encryption, where I want to have an option to generate a random key and a text field where users can enter their own and possibly other privacy-related features. Well, I don't track usage through third-parties anyway. Nor do I have any integrations with anything external, so they are sort of private, but of course, I can see the content through the db.
Every time someone (usually someone from HR) tries to point out how great a company is because of its great perks like awesome couching sessions (not actual training), great team-building events, the best coffee machine ever, table tennis, etc. and how these somehow compensate for a subpar salary offer, I tell them: you just pay me well, give me more time off, and I'll handle all that myself.
Just to clarify.. Yes, vertipaq is the tech behind power pivot, power bi and sql server analysis services (in tabular mode) and the same column-oriented storage is also used in sql server. Excel generates queries against the data stored in a vertipaq model. You cannot write normal excel formulas on top of it and you have to use DAX (a unique to msft language, which is the replacement for MDX) instead, which is pretty much a no-go for anyone but well-trained power users.
It really depends. I've seen developers commit tiny changes all the time, which do not make sense - I wouldn't want to trace a small logic change over 10 commits. Also, sometimes you commit, then realise that there's a stupid mistake you've made and then you fix it with another commit. In those cases it does make sense to squash the commits so that you get a normal, logical, commit in the history. On the other hand, squashing perfectly legit commits together into a horrendous single commit is a pretty bad practise for obvious reasons.
Certs are maybe one of the last things my colleagues and I look for on a CV. However, in many cases, it does help a bit to have some relevant certificates listed there, especially if the candidate is applying for a junior position, or a position which does not explicitly require a tertiary degree, since it shows that they have made some effort in the right direction. Unfortunately, very often they had gone through some brain dumps and cannot demonstrate even basic subject matter knowledge in person.
Nobody is saying that it's not a good habit to form. It would be better to advise to review your column lists and remove redundant columns. Firstly because schemas change, and then because yes, you might hit an index (especially if you know it's there, as you should) and get that speed-up as well.
My issue with this advice is that it enforces the idea that "less columns in select list" = "less data accessed" _in all cases_, which as we all agree is not true. Even more so if you have a relatively well designed database, with no crazy amount of views on views (or any for that matter), UDFs, huge columns with binary data, etc, etc.
PS: "...result of UDFs - they will be getting run per value per row..." -> not always.. Inline tvfs get expanded, so you should probably be quite careful with all other user defined functions in SQL Server anyway.
I fully agree. With both comments, both yours and branko_d's.
The way I read the article, it seems to suggest that by removing rows from the select list would somehow always result in better performance. In my opinion, in the majority of cases there will be no measurable impact on performance.
In some specific cases, however, yes, it can make a big difference. In postgres it also seems like selecting all columns explicitly, but out of order can be detrimental to performance:
"Pull out the names of only the columns you need instead of using SELECT * to speed things up further."
This is not performance-related in most cases. Unless the bottleneck is in the amount of data being transferred to a client over a network connection and there is a large amount of columns, or you have an index which matches the limited column list query exactly, there would be no performance difference in SELECT * vs SELECT <column list>.
In columnar dbs it does matter because the less columns you select the less data gets accessed on disk. However, this does not hold true for row stores because data is stored in such a way that the whole row gets accessed no matter how many columns get specified in the query.
There are many other good reasons why SELECT * is acceptable only in development queries, but performance is not one of them.