Da ich mich momentan verstärkt wieder im PHP-Umfeld rumtreibe, bin ich über diese Auflistung von Tipps/Regeln für Programmierer gestolpert, die viele Probleme sehr genau erkennt. Aber meiner Erfahrung nach wird oft genau entgegen gesetzt dazu gehandelt und diese Lösungen den regelkonformen auch oft vorgezogen.

Zu 1. Technologie ist nur das Tool, aber nicht die fertige Lösung
Oft wird am Anfang eines Projektes eine Technologie gewählt und es wird Erfahrungen damit gesammelt. Bei den nächsten Projekten wird diese Erfahrung höher eingestuft, als die Erleichertungen, die andere Technologien bieten würde. Grundsätzlich kann immer mit jeder Technologie fast alles lösen, aber jede Technologie wurde mit einem bestimmten Augenmerkt entwickelt. JavaFX ist z.B. toll um vorhandene
Desktop-Anwendungen zu erweitern oder zu er setzen. Beim Versuch eine komplexere Webanwendung durch eine JavaFX-Anwendung zu erstzen wird man eher scheitern, weil die Konzepte einfach zu weit auseinander sind.

Zu 2. „Geschickt“ ist der Feind von „eindeutig“
Es gilt irgendwie die Annahme, dass es eine einfache Lösung schnell überlegt ist und wenn man länger nachdenkt eine komplexe Lösung dabei raus kommt. Ich würde behaupten, dass es genau anders herum ist. Erst wenn man alles ausreichend durch schaut hat und verschiedene Lösungswege durch gegangen ist, kann man etwas auf das Elementare herunter brechen. Nach 2h nachdenken wird die Lösung einfacher und klarer als, als wenn ich das erste nehme was mir nach 2min in den Kopf kam.

Zu 3. Nur dann Code schreiben, wenn es wirklich nötig ist
Hier würde ich nicht nur unnötigen Code und unbenutzte Funktionen aufführen sondern auch Templates, wenn es um die Darstellung geht. Es ist schlecht und bringt mehr mögliche Fehlerquellen mit, wenn ich Dinge die ich mit einem Template erledigen könnte im Code formulieren müsste. HTML-Tables + CSS in Kombination mit z.B. AngularJS ist sehr viel Übersichtlicher und da durch weniger fehleranfällig als z.B. ein TableView in JavaFX wo ich für jede Zeile und Spalte einen eigenen Renderer schreiben muss, wenn es über die einfache Darstellung eines String hinaus geht. Jeder Renderer implementiert ein bestimmtes Interface oder leitet einen schon vorhandenen Renderer ab, der wiederrum Code enthält den man nicht kennt und der aber in Wechselwirkung mit dem eigenen Code auch mal lustige Seiteneffekte haben kann. Eine Hintergrundfarbe zusetzen mit einer Angabe im style des TD oder dafür einen Renderer schreiben macht nicht nur zeitlich einen Unterschied sondern sorgt auch für viel mehr Code und weniger Übersicht.

Zu 4. Kommentare sind meist „böse“
Kommentare sind nicht verkehrt, aber meistens nutzlos und machen alles Unübersichtlich. Oft hört man "man braucht mindestens einen Kommentar der beschreibt wozu die Methode da ist. Weil wenn du nach einem halben Jahr dir deinen Code wieder ansiehst weißt du dass oft nicht mehr." FALSCH! Wer Methoden schreibt, die er nach 6 Monaten nicht mehr zuordnen kann, macht grundsätzlich etwas falsch. Zu glaube man würde vergessen was loadArticleById($id) macht, ist genau so weltfremd. Wenn man Methoden und Klassen richtig und beschreibend benennt, wird jeder der den Namen liest auch verstehen, was da passiert ohne die Implementierung betrachten zu müssen. Also keine Abkürzungen verwenden und lieber längere Namen verwenden. Wenn man das macht wird man auch loadArticleByCategoryIdAndMaxPrice($catId,$maxPrice) verstehen. Die ganz extremen wollen auch Kommentare an jedem Getter und Setter sehen, aber da wird nicht erklärt was das zu setzende fachlich bedeutet sondern nur das dort was gesetzt wird.
Also zu glauben das unnütze Kommentare besser sind als gar keine Kommentare ist meiner Meinung nach falsch.

Zu 5. Vor dem Code-Schreiben wissen, was der Code bewirken soll
Am Ende muss man die Anforderung verstanden haben. Da muss richtig Kommuniziert werden. Aber selbst wenn man es falsch versteht... niemand wird anfangen eine Methode zu schreiben, ohne zu wissen was am Ende dabei raus kommen soll. Allein wenn man sich den Methodennamen überlegt, wird man diesen Schritt ja schon erfüllen.

Zu 6. Code testen, bevor man ihn an das Qualitätsmanagement weitergibt
Entwickeln und Testen kann man nicht trennen. Wer Entwickelt muss, dass es auch testen. Alles andere würde auch unnötig Zeit kosten. Einen abschliessenden Test sollte dann jemand anderes machen. Aber die grundlegenden Tests kann man nicht auslagern.

Zu 7. Jeden Tag etwas neues lernen
Jeder kennt einen oder mehrere, der oder die mal vor Jahren etwas gelernt haben und seit dem alles immer damit lösen. Leute die immer Desktop-Anwendungen gebaut haben und Server irgendwie noch akzeptieren aber Webanwendungen für totalen Unsinn halten.
Das ist immer kein Problem, solange diese Personen nicht große Entscheidungen für ein Projekt zu treffen haben. Dann wird schnell ein Web-Client abgelehnt, weil JavaScript dynamische Typsierung nutzt. Allgemeine Tendenzen bei Entwicklungen sowie so komplett ignoriert und als Unsinn bezeichnet, wenn jemand mal was in die Richtung vorschlägt. Es wäre alles Unsicher, man hätte keine Erfahrungen, es müsste sich erst einmal zeigen ob es sich durchsetzen wird (das habe ich erst vor kurzen zum Thema Multithreading gehört), usw. Sich was neues mal wenigstens anzusehen, wird als Zeitverschwendung gesehen und mit den alten Sachen, die man schon immer nutzt, würde da ja auch irgendwie gehen. Auch wenn man die alte Technologie nutzen kann, die neuen
Konzepte bringen trotzdem oft etwas, und wenn es nur eine neue Sichtweise ist, warum etwas weiterhin so mach wie bisher.

Zu 8. Nicht vergessen: Code schreiben macht Spaß
Hier merkt man eindeutig, dass der Original-Text nicht aus Deutschland stammt. Programmieren ist eine erste Sache! Wer bei der Arbeit Spaß hat, der erledigt seinen Job ja offensichtlich nicht richtig.
Wenn man einfach und schnell zum Ziel kommt, macht es Spaß und die Qualität von Dingen die mit Spaß an der Sache gemacht werden ist meistens sehr hoch. Aber bei allen was auch so intern an Frameworks oder Libs entwickelt wird, ist leicht und schnell nie ein Argument warum etwas benutzen sollte. Leicht zu verstehen muss nichts sein, man könne ja die rudimentär vorhandene Anleitung lesen.
Anleitungen lesen ist genau so Spannen wie Kontoauszüge lesen.. was aber in Deutschland wohl immer noch als super lustige Freizeitbeschäftigung gilt. Ich habe genug interne Frameworks und Libs erlebt die einfach schrecklich zu benutzen waren. Sie machten was sie sollten, aber die Zeit um die benutzbar zu machen, galt gleich wieder als sinnlose Zeitverschwendung.
Man muss den Spaß am Programmieren sich bewahren und wenn das am Ende mit privaten Projekten umgesetzt wird.

Zu 9. Man kann nicht alles wissen
Das kann man nicht. Man muss nur wissen wo man suchen oder wen man fragen muss. Es gibt nur ganz wenige, die meinen, dass das was sie nicht wissen, damit auch gleichzeitig unbedeutend wird. Einen guten Programmierer macht nicht aus alle Klassen-Referenzen und Protokoll-Spezifikationen auswendig zu kennen. Aber wenn man etwas nicht weiß, kann es lernen und das ist leider auch immer Arbeit.

Zu 10. Best Practices hängen vom Kontext ab
Web-Anwendugnen brauchen andere Best Practices als Desktop-Anwendungen. Java ist anders als PHP. Es gibt immer viele Überschneidungen aber am Ende machen es auch gerade die kleinen Unterschiede aus. In Java sollte man den Application-Scope verwenden und nicht die Session, wenn man für die gesamte Anwendungen einmal etwas laden/parsen muss. In PHP sollte man die Session verwenden, weil es nichts auf Applikationsebene gibt.
Wenn jemand Best Practices erstellt und meint es wäre jetzt die Lösung für alles, kann man davon ausgehen, dass es mit etwas Glück für einen Fall passt oder eher für gar keinen.

Zu 11. Immer nach Vereinfachung streben
Wie schon weiter oben beschrieben wird leider oft einfach mit schnell verwechselt. Um eine einfache und gute Lösung zu finden braucht man Zeit und die sollte man sich nehmen dürfen. Die Zeit wird man am Ende wieder einsparen, weil der Code dadurch viel einfacher zu pflegen und zu erweitern ist.