ksclk

If true, this would be observed at least partially in software engineers as well, since what we deal with is kind of made up as well, but I don't see it.

What is the difference between first principles and higher order thinking?

Could you please explain what the difference is between first principles and higher order thinking?

Based on the moon example, it seems you define it as a set of principles you can base your decisions on? E.g. to get somewhere, you must minimize your distance. What makes something a first principle?

I'm asking because my understanding is that "reasoning from first principles" is just taking a step back, asking yourself what's really the goal and reasoning backwards. But it seems like you've got two different concepts (first principles and higher order thinking), which makes me think you've got it figured out more than I do.

> Property is and always has been a zero-sum game that soaks up capital but doesn't return anything.

Why?

Say someone wanted to transition from coding to engineering. What path would you have them take? What should they learn?

Does cron work (wake up the vm) there?

I assume it's cheaper to own the whole vertical slice at this scale, so you can control everything. Given that there's the financial incentive to do it, how would you prevent companies from growing vertically? If you declared a legal limit, how would you prevent a single entity from forming a chain of companies, effectively producing one huge vertical company as well?

Thanks a ton! While I don't have the experience to understand all of it, I appreciate your writing, like the sibling poster (and that you didn't delete your comment)!

It reminds me of huge enterprise-y tools, which in the long run often are more trouble than they're worth (and reimplementing just the subset you need perhaps would be better), and (the way you speak about OOP) bloated "enterprise" codebases with huge classes and tons of patterns, where I agree making things leaner and less generic would do a lot of good.

At first however I thought that you're against the idea of managing complexity by hierarchically splitting things into components (i.e. basically encapsulation), which is why I asked for clarification, because this idea seems fundamental to me, and seeing that someone is against it got me interested. I think now though that you're not against this idea, and you're against having overly generic abstractions (components? I'm not sure if I'm using the word "abstractions" correctly here) in your stack, because they're harder to understand, which I understand. I assume this is what blackbox means here.

Does it sound correct?

> the idea of creating black boxes that you can't misuse

Could you please expand upon your idea, particularly the idea that creating (from what I understood) a hierarchical structure of "blackboxes" (abstractions) is bad, and perhaps provide some examples? As far as I understand, the idea that you compose lower level bricks (e.g. classes or functions that encapsulate some lower level logic and data, whether it's technical details or business stuff) into higher level bricks, was what I was taught to be a fundamental idea in software development that helps manage complexity.

> structure things as a loosely coupled set of smaller components

Mind elaborating upon this as well, pretty please?

Hi! Could you please tell me what use cases would nginx be better for, outside of serving static files?

Moreover, having worked with Django a bit (I certainly don't have as much experience as you do), it seems to me that anything that benefits from asynchrony and is trivial in Node is indeed a pain in Django. Good observability is much harder to achieve (tools generally support Node and its asynchrony out of the box, async python not so much), Celery is decent for long running, background, or fire and forget tasks, but e.g. using it to do some quick parallel work, that'd be a simple Promise.all() is much less performant (serialize your args, put it in redis, wait for a worker to pick it up, etc), doing anything that blocks a thread for a little bit, whether in Django or Celery,is a problem, because you've got a very finite amount of threads (unless you use gevent, which patches stdlib, which is a huge smell in itself), and it's easy to run out of them... Sure, you can work around anything, but with Node you don't have to think about any of this, it just works.

When you're still small, isn't taking a week to move to Node a better choice than first evaluating a solution to each problem, implementing solutions, each of which can be more or less smelly (which is something each of your engs will have to learn and maintain... We use celery for this, nginx for that, also gevent here because yada yada, etc etc), which in total might take more days and put a much bigger strain on you in the long term? Whereas with Node, you spend a week, and it all just works in a standard way that everyone understands. It seems to me that exploring other options first would indeed be a better choice, but for a bigger project, not when the rewrite is that small.

Thank you for your answers!

> you can already use a SAT solver

Could you elaborate please? How would you approach this problem, using a SAT solver? All I know is that a SAT solver tells you whether a certain formula of ANDs and ORs is true. I don't know how it could be useful in this case.