It might be the case that, the "hotter" the code paths that you're writing are (the more they get executed), the more difficult it is to write that code, where

It might be the case that, the "hotter" the code paths that you're writing are (the more they get executed), the more difficult it is to write that code, where as for "colder" paths (of which there are so many more), the code isn't as difficult but there is a lot more overhead of managing complexity, business priorities, process, communication, etc. Linux kernel code is probably some of the hottest code on the planet, and the developers/community understand that contributors need to be able to do exactly what you are doing - spending months toiling over a few hundred lines, and making sure that they are as perfect as can be, because literally billions or even _trillions_ of systems will depend on that code path. It is understood that in order to get it correct, performant, and maintainable, there is no other option other than to have a skilled developer take on a very high cognitive load in order to correctly implement the task. For colder code paths, like business logic (e.g. customer registers, happens "once" per customer), that logic evolves with the team, the team evolves with the company, the company evolves with the business, the business evolves with the market, which evolves with the world. The code might be pretty simple and easy to write, but the conversations around priorities and complexity and "why are we doing this" take up the lions share of the mental effort around it. Also exhausting... TLDR it is much harder to write systems code than it is to write python code that makes a call to an API and saves a record in a database, and working on the former _perhaps_ gives you more opportunity to be shielded from typical "software engineering" toil of business communication.