jrott

That’s a really good counter argument.

Most people don’t want to run there own infrastructure. Also many newsletters are written by people that aren’t technical so self hosting is for a really limited audience.

Most companies do have pathologically bad interview practices. The usual thing it to cargo cult off of other companies interview practices or be based off of some idea that has been seen before.

Even if you want to make it complex it's if it is core to your business and provides competitive advantage build otherwise buy.

I thought Zoom had moved to Oracle cloud.

Snowflake is pretty nice compared to redshift. Though I really wish there copying data out of s3 worked better then it does.

Python has a bunch of magic but it's mostly helpful for beginners it’s only when you start to do anything beyond simple scripts that it gets in the way.

Yup and clustering effects are still real. Eventually we'll come out of the pandemic and companies will want to be near there biggest customers.

I guess overall there is a fine equilibrium to find between having a totally uniform stack used by everyone, and having each team using drastically different tools. ESBs can make you fall into an extreme without realising it, because at first, it may look like a grandiose unification plan.

This totally nails it on the head. The problem with Entreprise service buses is the same problems that every major unification plan runs into. It usually executives looking for one ring to rule them all. This misses all the complexity that is going on in the business and deprives the teams that are actually solving those problems the independence to solve them the best way.

Yeah I feel like these articles always end up coming up with apple pie positions. Like talking to customers more is good advice probably but it’s also the most common most stated advice for early startups.

yeah this one makes no sense at all. Enterprise sales and massive legal departments to appeal to the kids.

The learning curve on J feels like a wall everytime I try and use it I end up bouncing off pretty quickly because it's so dense.

I get that feeling however I know for fargate there are some vertical scaling limitations that don't exist with kubernetes.

Also at this point there is a ton of stuff out there that assumes you are deploying to kubernetes and makes that the path of least resistance.

I like this a ton. It's much nicer to use then Gliffy or Lucidchart. It does need more options though Boxes and more choices of arrows especially.

I really want to like google cloud. Every time I use it things seem better set up than in AWS. I feel like I can't even bring it up at work though because of the issues with deprecation.

I actually think that being able to learn an expiring things deeply enough that you start to see the permeant skills underneath is really important.

Being able to look at something and quickly separate the core important concepts that are being used from the syntax and implementation details seems super important for long term success in a field.

this looks cool but what is the list of connectors that it currently has.

Yeah this absolutely makes a huge difference. The upgrade cycle for laptops and desktops has gotten long. When things have been slow for me at least it almost always memory bound and not cpu bound at this point as well.

Well they think that at least

absolutely manual tagging stuff is a plague. In large enterprises I've seen manual tagging efforts that result in massive amounts of gaps and confusion about who owns what and whatever else is being done with tags.

That is good news. Do any of the other companies have people working on MDN?

Spark has worked decently for me if you need to be cloud agnostic.

Currently I’m in AWS land and Athena has been mostly working for what I need but I haven’t really pushed it that hard yet.

Yeah this lines up pretty well with my experience. Usually when I see someone endlessly refactoring something it's because they have an idea they're really into.

You end up with everything having dependency injection or one service that has been churned on 15 times. I haven't seen it yet where it's general plumbing fixes.

LEGO bricks basically. They kinda click together in my mind with a sorta super structure of IAM and VPCs

It is, but so is the problem space, as evidenced by AWS's own clusterfuck of services.

It kinda comes with the problem space they're trying to solve: how do you efficiently run a bunch of services on a bunch of computers? Virtualization solves one problem but you still have networking and service discovery to sort out.

Oh it absolutely is complicated. The way amazon does it seems to click better with my mental model for how all of this is supposed to work though. I'm really not sure if it's right or wrong or it just depends on how you model these problems.

I loved this. Every time I try to work with Googles opensourced stuff it always feels so complicated to me.

Wiki rot is a real thing. The problem I've got with this suggestion is that it doesn't handle the case of pages that are useful but don't need to updated frequently.

The bigger issue that I see is that keeping internal documents in a good state is hard and it's no ones responsibility usually. I've been on teams where the internal documentation is great but it's always been because one person has put a ton of time into maintaining it.

In many senses it's a good thing. The major fear is usually getting fired for it. However if you are in a position where that's not true or you can recover from it easily you should absolutely push back against that sort of nonsense.

It's partially discipline but culture plays a role as well. If everyone at your company is sending slack messages at 7 and you aren't it becomes easy to be branded not a team player.

The biggest thing for me is to gently check if I’m drifting in a conversation and to make sure that I’m actually listening to what the other person is saying.