I think MongoDB gets an unfair shake when it comes their updated license terms. They tried to be good OSS participants while still trying to run a business. They put it out there under a permissive license but tried to make some money of it (which is a tough already). And then they got popular and AWS basically just resold their tech because of the license. They had to change their terms and regular users freaked out. If you don't resell Mongo "as-a-service" you're fine. A lot of developers didn't see it that way and it hurt them.
Snaps and the continuous issues with them was the main reason for me to leave. I'm very happy with Linux Mint now. I'll use Ubuntu on the server but never again on the desktop. I get what Snap was trying to accomplish, but it failed miserably IMHO.
I'm probably a bit late on this, but none of these points touched on a software engineer building a complex architecture for no reason. I have seen this so many, many times. Yes, they can handle point #1. They take all the tickets associated with it and solve them quickly because they built it and know all the connections. The implementation makes no attempt (or claim) at scalability so that's a moot point. For point #3, interestingly enough these are never about optimization of anything, but about abstraction over abstraction over abstraction. As for the graph DBs, those aren't allowed anyway by the company they work for (thank goodness) or they would find some way to incorporate them.
Yes, I'm being a bit glib, but over-engineering does not always mean there's some good intentions in there. It can just be really bad.
You are on the right path! Most new devs don't even comment at all (and plenty of senior devs). As for variables names, I wouldn't fret about that. Yes, 'foo' isn't a good var name but the exact name doesn't matter as much as one would think.
I can't even imagine wanting to handle managing accounts and credentials for that many users at an enterprise! At that point SSO integration is well worth the money. How did you handle removing access when a user was no longer employed at the company?
There is a lot of talk of feature flags but that only works when you can realistically delay your feature 2 weeks so that the 'special' set of clients can see it early. What we've seen that has worked is essentially demoing the feature in staging/test to stakeholders at the major/demanding client. They are happy that they aren't taken by surprise and then we provide training materials for major feature/UI changes to their users. Never have had an issue, client is happy and essentially zero technical involvement.
Wow, that's great to hear the taxi company stepped up, but I'm completely shocked by it! In the decade of taxi experiences prior to Uber/Lyft/ridesharing almost every taxi experience was absolutely awful. Driving erratically, on the phone, can't (or won't) take cards, won't take the route I said, literally kicking me and my spouse out of the cab and yelling at us for saying they needed to make a left turn instead of right (we lived in the area and knew where we were going). I'm convinced that a taxi driver has to literally kill someone before any action will be taken against them. I've found that Uber/Lyft usually tends to side with the rider but, like you shared, that's not always the case. The mutual rating system is a net plus IMO. Every cab company is different I guess, but I will never set foot in a cab again out of principle.
^^ Listen to this! As a manager and developer as well, I 100% agree. If you are a great worker and your manager isn't incompetent, they will fight for you up the chain. But don't approach it abrasively at first. That just sets the wrong tone for everyone.
On the other hand, if a good manager doesn't care if you quit, it also says a lot. There are developers I was so relieved just quit. It wasn't worth it keeping them.
As much as I want to disagree you have to do somewhat of a coding interview in today's environment. I'm not talking about anything super difficult. Just connecting a database query you've had to write (previous step) to front end code. Having something that simple be take home is asking applicants to put somewhere and pay for someone to do it. Nothing hacker-rank level and you'd be surprised at the number of people that fail. We're not even touching fizz-buzz complexity. Sorry, but you will have to to be able to write a very very basic non-google-facebook level of code in our interview.
Interestingly enough, in my entire career so far, for things that weren't cached that should have been or were already cached and working, the one invalidation point was the save page of the entity. Sometimes it's not that hard for vast majority of cases.
I love good write-ups like this! Although I would have liked a bit more detail.
UX at scale is really difficult sometimes and there are constant trade-offs and limitations to deal with. Everyone expects perfectly smooth performance with data available at an instant and it's easy to be the other side and judge than to have to actually work through the complications of solving it.
Sorry, just seeing this now. In my scenario, it's number of vesseils available for charters. So you pay so much for first vessels and some more for additional vessels. Companies with more vessels have more revenue so they can pay more.
Head count makes sense in some spaces/products. I shouldn't have been so definitive. However, the units of measure used should always be something the target enterprise understands. For example, the company I work for in healthcare prices contracts by number of beds, which is a number ever hospital understands. Im so glad I don't have to tell someone that they can't be added to use the product cause their seats are maxed out.
A lot of this is obvious now but not as much 8-10 years ago. Don't price your SaaS per seat, ever. It will be abused. My tiny, niche SaaS uses X 'resources' configured in the product. If you have X resources configured for your business it means you're big enough to pay more.
I graduated college shortly before you started and the landscape wasn't all that different when I graduated than when you started. Yes, a good part of any job is just data/crud plumbing but there are interesting and challenging problems to solve even if you're not at a FAANG. Sometimes you got to find and fix them yourself. The one thing that I love now that I'd didn't have early in my career is the tooling! Just having the right programming and debug options is huge and I feel like I was in the Dark Ages in the early to mid aughts compared to now. As for the cubicle/office change, that might be moot now with move to WFH.
Oh, would love to have been a fly on that wall. I wonder what they did for 'reporting'. mongo/document dbs are great for niche uses. I don't disagree on that. But for an overall store I don't see it.
I believe all employees should be paid a decent wage and it's clear Blizzard is severely underpaying a good part of their workforce. But it's unfair to say that all employees at one level should get the same salary. We try hard to make sure good employees get raises, cause we want to keep them! If someone shared a document around with salaries and someone came to us demanding why they were paid less we'd either have to come back with, ok this is awkward but you're just not as good/productive/etc of an employee. Or you just didn't negotiate enough when hiring.
In my experience, many of the best CS students from foreign countries go to U.S. universities anyways (usually in the upper tier programs). So wouldn't that mean other countries are already at a disadvantage?
Totally agree about trying to get a better deal if you're going to stay. I would be pissed if I found out the other engineer had more equity than me and I was basically doing all the work. If you get more equity, then you can feel you're getting fairly compensated for your part in building the startup and who care what the other engineer does or what happens.
Seconded on Vue. If you haven't used a frontend JS framework in a while, Vue will still be easy to pick up and learn. I love it. As for backend, Django, Rails, even .net core will do. Whatever you're most comfortable with.
I work in the tech healthcare industry. I wonder why they only went with (or focused on?) ML/NLP text analysis to analyze data. There is a wealth of discrete data available in EMRs (pharmacy, lab, eMAR, etc.). Yes, there is plenty of diagnosis text but that is almost always associated with ICD10 codes. The only area where I believe text analysis would be useful is documentation and microbiology data, and in many cases micro is discrete as well.