Very good indeed! He put in words my thoughts.

One piece of advice that doesn't seem to be mentioned is to work on building your intuition of fundamental CS limitations. As an analogy, the conservation of energy is a very useful physics principle because it's widely applicable, easy to apply, and helpful for estimation. Computer science also has many similar principles that are widely applicable, easy to apply, and helpful for estimation. You can use these general principles to help evaluate new technologies as well as jump straight to the heart of what trade-offs must be involved in a particular piece of tech. You can also learn to quickly spot when new technologies claim to have built a perpetual motion machine (eg. a technology that claims to ignore fundamental CS limitations). Further, these principles can guide you even when jumping into new environments, platforms, languages, ecosystems, etc. Some examples: The CAP theorem A really common trope is for a new technology to claim to solve all your distributed application problems. Knowing the CAP theorem can help you either get to the actual tradeoffs or ignore the snake oil pitch. ACID ACID is nice a way to set baseline expectations for databases. If someone is trying to sell you a "database" or state management solution that doesn't offer ACID, then they better have a good reason for compromising. It's common and useful to have a database that drops the (D)urability requirement, but I've seen far too many state management solutions that don't offer ACI and don't have a good reason. POSIX Especially on linux, almost every application is built on the same fundamental operating system primitives. Even for non-posix systems, understanding posix gives you an intuition for what fundamental limitations are imposed by the operating system. As an example, for whatever reason, every programming language builds their own high level API for working with files and network I/O and they often screw it up by providing a high level API that compromises on efficiency or capability. If you're already familiar with the fundamental operations, you can selectively choose to ignore the high level API when necessary (👀 ruby, nodejs). Understanding the building blocks of operating system APIs also gives you several tools for fundamental tradeoffs with threads, processes, I/O, networking, RAM, synchronization primitives, etc. It also helps you understand why web applications are generally much worse than native applications. It's because the web APIs (websockets, webassembly, LocalStorage, WebWorkers) are just janky versions of the underlying OS APIs (sockets, assembly, file system, threads/processes). Others I think there are also plenty of lists that can help build intuition for fundamental limitations that can help you focus on what tradeoffs are necessary for a piece of tech. • Various lists under "numbers every programmer should know". • Falsehoods programmers believe about X, https://github.com/kdeldycke/awesome-falsehood • fault tolerant systems, http://erlang.org/download/armstrong_thesis_2003.pdf • The halting problem • Algorithms • Distributed state and consistency https://aphyr.com/tags/jepsen • https://en.wikipedia.org/wiki/Two_Generals%27_Problem

I remember seeing a new technology recently which seems to fall for every https://en.wikipedia.org/wiki/Fallacies_of_distributed_computing