I am a pilot, and am going for my instrument rating. Learning to fly well take a lot of time. It's also very rewarding. I write a lot of code. I write books. I write articles, I write scripts for videos. I act in those videos. I review those videos. I'm pretty busy most of the time. When I have a free moment, I read, or play Minecraft. I like watching Youtube videos about flying, or about science. I like PBS SpaceTime, and Veritasium, and Smarter Every Day. I also like conservative political podcasts. I keep pretty busy. And if there's nothing else left, I read science fiction.

They make me laugh. It's an old problem. It's been tried many times. It never works quite the way people think it will. In the end, there will always be lots and lots of code. Take great care that whatever platform you use allows you to write tests. One of the biggest failings of platforms like that is that they don't allow you to test what you write.

Coding ability is nowhere near enough. Programers need to be good communicators. They need to be articulate, creative, caring, problem solvers. They need to be able to focus deep and long. They also need to be able to talk to business analysts, customers, and managers. They need to be able to see deep details, and also get the big picture. It's a tough mix of attributes to find.

I don't know anything about Django. I advise against marrying frameworks though. Try to get the milk without buying the cow.

"Class Categories" was Booch's original term for "Component". It was an play on Bertrand Russell's solution to the problem of.... Nevermind. The reason that I use the metrics at the level of a component is that the metrics are statistical. They tend to be accurate if the sample size is high enough. At the level of a class, the mathematics is subject to a lot of "error". I think DI frameworks are fine; but vastly overused. My advice is to use them to inject a relatively small number of Factories and Strategies; and to do that injection into Main. What I don't want to see is @autowired scattered everywhere through the code -- and especially not in the business objects.

I don't know what /r/programmers is. I am aware that there are folks who don't like my message for one reason or another. That's fine. I believe in the marketplace of ideas. If their ideas are better, their ideas will win. Some folks don't like the fact that I am a conservative, and a republican. Some folks don't like the fact that I voted for Donald Trump. That's fine. I believe in the marketplace of ideas. If my politics is wrong, then it will lose. Meanwhile, I've been a programmer for 48 years. That's something of a rarity. Very few people alive have been coding for 48 years straight. That sheer level of experience puts me in a position of some authority. I'm also a tolerably good writer, and that helps. Anyway, there's room for all of us here.

The best practice is to use the smallest interface that provides the methods that your callers need to call.

No, though some other folks have.

Every programmer should know many language. Dave Thomas and Andy Hunt once said (in "The Pragmatic Programmer): Learn a new language every year. This is good advice. Every programmer should know a C based language like C, Go, Java, C# or C++. Every programmer should know a functional language like Clojure, or F#. Every programmer should know a stack based language like Forth. Every programmer should know a logic language like prolog. Every programmer should know LISP. And that's just for starters.

I was never invited to be on the C++ standards committee. Had I been invited, I would have declined. I hate bureaucracies. I don't want to haggle over little tiny language features. I want to code. I know absolutely nothing about Rust. I may look into it one day; but there are so many other things to look into. Decisions, decisions.