craig_asp

I know the author and I can tell you that the story is completely real.

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.

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.

All suggestions welcome, of course.

So it seems like we'll have to change what we do from writing code to reading code and fixing it..

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.

This would be great for amateur astronomers too.

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.