somethingAlex

I’d agree, but I wonder how much faster writing a backend API in Django is compared to using node.

I’ve written a lot of python outside of the web space and a lot of JavaScript in the web space and I can’t think of a time I wish I was writing in python.

Modern JavaScript has a really expressive syntax without the runtime performance hit.

It’s a nice metaphor, but hopefully we all know what bad abstractions look like.

If you have to refer to the API documentation frequently, even for simple stuff, I don’t see how that’s adding any value.

If you have 100 lines of code but you can expose the logic in 30 lines, that’s probably worth the refactor. However, making your code 3 lines instead of 10 isn’t very important.

I feel like all of the downsides given in the quotes can be solved by making sure people get a variety of work. Define an interface and split the work into chunks. Just make sure people are being assigned to different kind of chunks should their skill allow it.

This is really just the crux of managing people and bringing out their potential. I’m not gonna split a CRUD endpoint or class between two people but I’ve also had two people write the same exact function because it was so complex.

They did this at chick-fil-a corporate as well. An extremely competent product manager described the yearly experience as “standing around not knowing what I should do and trying not to get in the way.” Those kitchens get hectic, super different than being in the office.

Like anything it's just pros and cons. Sure you save money by doing on-prem or just buying servers and colocating, but you also get all the headaches that come with that.

I used to work at one of the most popular fast food chains. I had one project that was internal to them and one that was customer facing. The internal product, a search engine for documentation ran on-prem while the e-commerce store ran on AWS. Running the former on-prem was just fine.

I'm sure glad we were on AWS for the customer-facing site, though. We'd run ads during the Macy's day parade, college national championship, etc... dear lord I could not imagine wrangling the necessary people to scale that out from an infrastructure perspective. It was very nice just doubling the number on our ASG, failing over to the secondary database, launching another DB instance with double the capacity, and repeating for the second one.

Between those popular ads and DDoS attacks I'd say AWS was a win there, but internal tools don't benefit from the cloud as much. Also not an MBA, but I feel like that's a rule a thumb you can add to the repertoire.

Honestly shocked that rust is about 4 times faster than node for the DynamoDB insert workload in the average case. I knew it'd be faster but I would have expected maybe 50% faster since most of the time is probably spent simply sending the data to dynamoDB and awaiting a response.

Also, what is up with Python being faster than Node in the beginning and then getting slower over time? The other languages (apart from graal) get faster over time. I'm referring to the average MS latency at 128MB graph at the bottom.

I think it's just the trade off between these two scenarios.

- Relatively poor amortized scale out time with good guarantees in the worst case.

- Good amortized scale out time with dropped requests / timeouts in the worst case.

With lambda, it doesn't really matter how spiky the traffic is. Users will see the cold start latency, albeit more often. With Fargate, users won't run into the cold start latencies - until they do, and the whole request may timeout waiting for that new server to spin up.

At least that seems to be the case to me. I have personally never ran a docker image in fargate, but I'd be surprised if it could spin up, initialize and serve a request in two seconds.

I think scrum and all agile frameworks are trying to solve two problems.

1) Making good software efficiently

2) How can stakeholders get a better sense of how much work a team can do per unit of time

I don't think scrum offers anything in the first department that "Hey, don't do waterfall" doesn't. I don't think this advice needs a capital "Agile" or Scrum though. It's pretty obvious nowadays.

As for the second gaol, I don't think it offers much either beyond the advice "Hey, speak up if you encounter a blocker and think it's going to take longer." Again, I don't think that deserves a capital Agile / Scrum. Has anyone actually been on a team where you nailed down your velocity and this truly helped anyone?

I think a good process is Design <-> Iterate -> Ship, have a real quick standup to identify problems early and often and then report back to stakeholders. Just pull tickets Kanban style. Have a retrospective once a month or so.

Doesn't deserve or need to be a whole religion.

But we are just talking about an x ray here. Estimating the price of a radiologist per hour is not hard.

It shouldn’t be this difficult to price x rays at a per hour or per shot basis.

Pretty much every industry has variability in their jobs. Sometimes they eat some money and sometimes they make more based on what actually happens during the job fulfillment.

No one expects (or should expect) hospitals to literally know the amount of parts and labor for every single x ray they could perform. However, like literally every other business, they should know rates and tiers such that on average they make money. Then, disclose that.

The type of consultancies and firms which actually pay out profit based on equity are usually LLP's / partnerships (part of the reason why "Partner" is a title in finance, law, etc.

Tech companies are usually corporations (often C corps in the startup world.) What equity gets you in the two scenarios is completely different.

I wasn't talking about people needing to work more than 40 hours. I agree, exceeding that shouldn't become normal.

I'm talking about the people who have to take care of their kid, so they can't work the usual 9 to 5. They got 28 hours from target, but they do need some more money, so they do UberEats at night.

I'm talking about the student who really can't work in the day because they have to study and attend classes. Hell, sometimes they can't even work at night due to their group project and their team members slacking off. Well, now they can just Uber when they have time instead of committing to a schedule at the local Subway.

I fail to see how this new "servant economy" isn't an improvement on the unskilled labor sector.

It's never been easier for someone who needs to work two jobs... to work two jobs; one with weekly hours and another you can do whenever is convenient. It has never been easier for a student to make some cash when it's convenient for them and with no weekly obligation.

These are improvements on jobs that already existed and new jobs altogether.

We should probably be focusing on how to provide more upward mobility and access to education instead of demonizing improvements to an economic sector which will always exist.

Those 1, 2, 3... buttons on the front are presets they already configured. It's triggering their "standing up preset" button once every 45 - 60 mins and then they press the "sitting preset" whenever they want.

There's no neural network you could train using supervised learning to solve sorting in the general case.

To train a neural network, the training set and test set need to come from a common probability distribution but the inputs of sorting algorithms can be random. There's no relation between what you could possibly train your network on and what you'd ask it to do.

Put another way - the input and output of your model would have zero correlation. There's nothing to train the model to pick up on.

Interesting related work: Graves[0] trained a "neural Turing machine" to encode instructions for a basic sorting algorithm.

[0] https://arxiv.org/abs/1410.5401

Personally, I have a tendency to lump them together because they always seem to be propagated by people with certain characteristics.

- They think "questioning everything" makes them smart even though many questions are answered to a point where being contrarian is irrational.

- They're generally just anti-intellectual. They enjoy talking about stuff without introducing any rigor.

- Probably the most interesting to me; they tend to have rather isolated jobs. I suppose they haven't been exposed to incompetence at scale.

You're right, it's not correct to just lump everything into one bucket. But when they seem to be pushed by a different incarnation of the same person every time, I get desensitized. Especially because, when I do bite and ask some follow up questions, I never seem to get any answers.

I see a very common arch of "I want to achieve" -> "Okay, life is about more than that, I'm going to practice balance" in these comments. I have also gone through it.

Around 19-24 years old I was working like a dog and making some great career progress. That helped me today, like you said, but I'm now the happiest I've ever been by enjoying this fine summer and working when I feel like working.

I look back on those years and truly wish I saw the other things life has to offer at the time.

I think there was a disconnect. In the context of my reply I was assuming that your opinion is what society generally holds true. I, too, believe this. It's talked about in books like the Growth Mindset and that book resonates with me a lot.

I was merely trying to say that these two ideas (1) you don't have to be genetically gifted to achieve greatness and (2) some people are just genetically gifted and they may very well reach ideas that most others won't - even in solitude - are not incongruent ideas.

The vast majority of people are not given great genetic aptitudes for things so reminding society that normal people can come together and create wonderful things is truly helpful. However, we should also recognize that some people, like von Neumann, Gauss, Newton, etc, are just on another level - and we as a society should also foster the potential of these people.

We can have both, we need both (since most people aren't like those three names above), and there's no reason we shouldn't try to embrace both ideas.

EDIT: the last sentence refers to the context of authorization systems. Not completely in general.

One point I haven't seen covered is complexity.

Carta seems to have an extremely complex authorization scheme but I wouldn't say that's the common case. Many organizations can get by using simple role + account based permissions.

If you are a member of this account then you have access to the resources this account owns minus anything you can't access because you don't have role X or Y. Oftentimes the account based permissions boil down to where clauses in SQL statements. The role based permissions can be mapped to scopes in a JWT or similar.

Anything beyond that can be done with if statements in your "parse user input" function or simply caught later on resulting in a 4XX error.

I know at my particular organization, even when we have cross-account sharing, it's heuristic based. It's simple enough to just apply it in the application code. Stuff like "did this user's organization receive this shipment?"

I feel like you have to be either a very large organization trying to make sure people do things consistently or have a very, very granular permissions model to even embark on making the decision of "build a whole authorization product in house or outsource it?"

I suppose comments like this are what got the author to write the blog post.

Genetics also matter and we as a society should make sure we foster the potential of people like the 10X scientist. I have a great memory - my brother however, has an encyclopedic memory. He doesn't forget things that he reads. I will never be like, regardless of my environment.

But most people aren't in the 99th percentile of genetics so emphasizing the fact that most innovations do come from collaboration is helpful for society. However, we should still emphasis that there truly are some "rockstars" out there and make sure their environment matches up to their genetics.

I just don't think browsers are in a good position to implement advanced features like this, though. They are too general of a tool to be opinionated and if you aren't going to be opinionated I don't see how javascript isn't the answer.

What kind of autocomplete do you want? Which algorithm? What's the threshold if you're using some kind of "string distance" metric? What do you want to do style wise when you match portions of strings? What optimizations should be made for your specific case?

I don't see how a web browser is in a better position to make these types of features compared to a javascript library / web assembly.

In the new technology sector this is certainly true. Find your product-market fit and then optimize when you become mature and scale up.

But aren't we talking about extremely mature kernel code here? My impression is that all kernel distros in high use are optimized but they are general use software. The degree to which you may optimize software is constrained but the diversity of use cases you must support.

Does anyone know to what extent Apple differentiates between in-app purchases and subscriptions? I've heard Netflix and Spotify do not give Apple 30% because, well, that'd be kind of ridiculous for these companies to give 30% of their revenue to Apple.

But what about mid-sized companies? I pay a yearly subscription fee to Headspace. If Apple is actually taking 30% of their revenue because people access it via an iPhone? That... just doesn't seem sustainable.

Could you explain what you mean by inequality eats at society at all levels?

Obviously if inequality gets to a certain point, where you don't have a solid middle class anymore - that's problematic. I'm just curious about your stance because I too feel like Jeff being rich doesn't really make my life any worse.

What are consumers intuitively expecting compliance with this law to look like?

Data from one service may be in an entirely different schema than the service you want to import it too - let alone format. Service A may summarize your data and throw away the granular stuff, but service B runs on the granular data.

Are consumers going to implement ETL pipelines to achieve portability? Are they expecting to hook up streaming mechanisms for enormous swathes of data?

Just as an example, if I wanted to get a list of every song I liked on Spotify and import it into Apple Music, how would that even work? The songId of Spotify is undoubtedly different than the one Apple uses. Are Apple and Spotify supposed to agree on a common file format?

I agree with the intent of the law but I'm not surprised most services do not offer an automated way to take out data. It's a rare case, often a heavy workload, and there's really no way to guarantee the data you receive is actually portable.

None. It's not meant to be an investment, it just happens to be used like one currently.

It's ironic, the same thing that makes these coins valuable to people (volatility, and mostly in the upwards direction) is a major reason why they are hard to use for mass transactions.

However, there is some good here. People are getting familiar with crypto by participating in this investment strategy. A relatively stable coin capable of high transaction throughput and low fees - one that can actually be used as a currency instead of an investment - will benefit from this in the future.

What do you mean by "cheat" in the workforce?

Under 100GB; I'm sure vanilla Postgres would suit our needs too. However, adding TimescaleDB on top was not much of an investment and in exchange we got an interface for operations we do often, effortless continuous aggregation, near-constant time appends, and a native way to leave data mutable for a period of time before marking it immutable and compressing it.

The performance is a great feature but its also just an intuitive, familiar (pretty much just SQL) tool that makes life easier.

Very happy with our choice to use TimescaleDB. The idea to simply make it a Postgres extension was brilliant. The compression release was one of the cooler features I've seen in recent times. Row database for recent transactional data, columnar compressed database for historical OLAP workloads - pretty much automagically.

The consistency level seems to be Causal Consistency, which does include read-your-writes. S3 doesn't provide ACID transactions, so stricter consistency models aren't really needed.

From what I've read, if a network issue occurs which would impair consistency, S3 sacrifices availability. The write would just fail.

But this isn't your 5-node distributed system. Like they mention in the article, the witness system can remove and add nodes very quickly and it's highly redundant. A network issue that would actually cause split-brain or make it difficult to reach consensus would be few and far between.