You said you hate the industry, so I have to assume you want to build a business. Unfortunetely, people don't pay for programming skills. They pay for you to solve a problem or to entertain them. In essence, to get better at programming, you'll have to build products and solve the problems that come with them. Too many bugs? Learn testing. System crashes at night? Better monitoring, logging, etc. Features take too long? Better architecture. Algorithms and programming exercises are the easy part, productizing something, running something in production is the hard part. There is no book, course, or other material that can give you the understanding of what it means to build production-grade software. You can read countless stories on how you should write your code (clean code, TDD or whatever) and how you should operate your production system (DevOps, IaC, containers, and so on) but will this really apply to you? Doubtful. Start small, fix problems and fail a lot to learn what the true painpoints are and how to solve them. I met a lot of people who just tried to follow "current best practices" without any understanding as for the reason and the result almost always way a horrible moster of an architecture that fell over at the first sign of trouble.
Everyone with experience has their own style and preferences. For example, I like to write very defensive and modular code because I really hate chasing down bugs or getting up at night due to a production failure. Most people I meet don't like my code because writing code with that much test coverage and deliberate APIs takes time, so day-to-day I have to make compromises, but I will always push in that direction. Others push in other directions because of their own personal experiences. As long as there is communication, the end result is always worth it. However, if you were to follow only my advice, you'd likely become terribly locked in and think that programming is terribly boring. So don't listen to me, gather your own experiences and use learnings from other people to supplement your view of programming, but never let their view replace yours.