Die Frage scheint mir doch etwas Allgemein zu sein, "Wie werde ich ein guter Programmierer?".
Die Antwort ist deutlich schwieriger als die Frage konkreter zu formulieren. Da ich nicht genügend über dein Vorwissen weiß, oder erraten könnte, muss ich natürlich auch auf eine sehr abstrakte Ebene zurück fallen.
So sind folgende Punkte wohl die "großen" wichtigen Punkte, bzw. gehen auf deine Post oben ein:
- Clean Code, bereits erwähnt, wird aber von 10 Personen auf 12 Arten interpretiert. Ich würde hier subjektiv vorallem auf gute Lesbarkeit und Selbsterklärung achten. Stell dir die Frage "würde ich das verstehen, wenn ich es in 1 Jahr anschauen würde"
- Kommentare sind das A und O, natürlich nicht übertreiben und einzelne Code-Zeilen beschreiben

- Die großen Pattern, wie MVC, Observer, Proxy, Composite und was es da alles so gibt, sind sehr interessant als Lernhilfe zum erkennen von abstrakten Lösungsmöglichkeiten. Nicht alles sollte streng nach deren Regeln programmiert werden, so wie sie auch erst entstanden sind, weil viele Leute die gleichen Probleme auf ähnliche Weise gelöst haben. Die wurden aber ja schon erwähnt.
- Sowohl UML als auch Klassendiagramme sind schöne Dinge, aber nur in sehr spezifischen Umgebungen. Große Gruppen (Firmen o.ä.) können so zum Beispiel für alle ersichtlich die Grundlagen und Verhaltensweise eines Programms darlegen und schaffen sich so ein gemeinsames Ziel und Funktionsumfang. Für eine einzelne Person sind solche Diagramme häufig nur unübersichtlich und insbesondere zusätzliche Arbeit mit sehr geringem zusätzlichem Nutzen (meiner Meinung nach). Aber auch für Einzelpersonen sehe ich einen Vorteil, den des gedanklichen strukturierens einer Idee, das Verständnis eines großen Ganzen. Müsste ich etwas empfehlen, würde ich diese Diagramme für den Anfang empfehlen, um sich an die Strukturierung von Programmen zu gewöhnen, aber sie so bald wie möglich wieder ablegen. (Ausgenommen sehr große Programme)
- Rekursives Programmieren ist in der Praxis meist untauglich, da z.B. die Wartbarkeit stark leidet, aber zeigt sehr schön einige Sonderheiten und Stile auf. Scheme eignet sich dafür wunderbar, um sich etwas damit vertraut zu machen.
Die Überlegungen zu einer Architektur oder auch Aufbau eines Programms sind allgemein die schwierigsten. Möglichkeiten um spezifisch diese Fähigkeit zu trainieren, würden mir nicht einfallen, abgesehen von stumpfem Habe-ein-programm-und-überlege-Stuktur-bevor-du-dir-die-Lösung-anschaust. Ich würde behaupten, dass das Beste Training in viel Programmieren besteht. Bei mir ist es so, dass sich einige Architekturen in meinem Kopf bereits gebildet haben, welche ich als Themeplate auf Problemstellungen anwenden kann, aber die haben sich auch erste daraus ergeben, dass ich auf eine ähnliche Problemstellung schonmal gestoßen bin und die auch selbst gelöst habe.
Falls das nicht hilfreich war: Das Thema ist wirklich komplex und wir haben fast zwei Uhr in der früh, ich entschuldige mich für verloren Zeit °3°