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.

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.

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.

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:

https://www.postgresql.org/message-id/[email protected]...

So, it depends :)

"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.

I've worked in BI (end-to-end - data modelling, reporting, ETL, etc.) for more than 10 years now across various organisations and since "data science" became all the rage, I had the pleasure to work with a few data scientists. From what I've seen so far, they are very good as statisticians (some of them university lecturers) but when it comes to building ETL pipelines, I don't think any of them could actually do it properly. Properly as in an ETL process which connects to various data sources, writes to logs, is repeatable, restartable and so on. It is not easy to get to know how to build a proper ETL process and it is not easy to learn how to "do data science" correctly as well. I see it as more productive (from my personal experience) to let the "data engineers" do the "data engineering" work - build data models, ETLs, etc. and let the "data scientists" do the "data science" work - build and fiddle with statistical models. Just like with a "full stack" developer, and the separation of work between "back end" and "front end" developers, it might be better to let each do what they do best unless you have people who can do both properly (but often it's hard to find them and they would actually be better in one area or the other). The frustration between the two camps - data "engineers" and "scientists" is usually due to mismanagement (distinct teams doing each bit separately, coordinated by one to many management layers) rather than suboptimal division and allocation of labour. Small teams of two to four people which contain the correct mix of experts would benefit from the strengths of both data professional types, and would avoid the problems around syncing the effort.

"As it stands today I’ve personally used EKS, and AWS in general a lot. I’ve used GKE a bit but only with my own personal credits doing Kubernetes The Hard Way and spinning up a very quick GKE test cluster a while ago."

"I’m being serious when I say this: if the company I’m working for decided to migrate to Azure I’d find a new job."

"It needs to be fast and bug free so that I can build cool automation on top. Working on something like Azure, especially after having worked on AWS for years, would be extremely depressing."

If the article is supposed to be an _unbiased_ comparison between cloud hosted Kubernetes providers, I'd say it's a bit of a fail. For some it would be completely different experience because they have experience with Microsoft technologies. And those people might as well quit if their company moves to AWS or a non-Azure platform.

Yeah, it's relatively dry material which is hard to grasp without the context of why we need it and how it can be applied in the real world. While the intro is good, it still has the same problem - just shows (in a good way) "some math".

He should remove the outliers and study those separately. The gini consideration goes a bit in that direction, but not far enough. Possibly even split the population in 4-5 buckets: from people under the poverty line through to the extremely rich and then compare each of those. Admittedly, this would be way harder but would paint a much better picture.