Ratschläge für einen schlechten Programmierer

Ratschläge für einen schlechten Programmierer

Ratschläge für einen schlechten Programmierer

Auf dieser Seite:

Statt eines Nachworts. Sehr frei nach Kurt Tucholsky.

Arbeite nie nach einem vorgegebenen Plan, einem Struktogramm, UML oder einem Pflichtenheft. Das macht einen so unsicheren Eindruck. Programmiere einfach drauflos.

Lehne es kategorisch ab, einen detaillierten Plan zu erstellen, bevor du mit der Arbeit anfängst. Schließlich bist du nicht mehr in der Ausbildung, sondern im Job, wo du für derlei Kinkerlitzchen keine Zeit mehr hast.

Erwartet dein Kunde trotzdem ein planvolles Vorgehen von dir, dann verwende den Stadtplan von Hamburg oder den Fahrplan der Bahn. Irgendeinen, egal welchen. Hauptsache, er passt nicht zum Problem.

Ein Programm, das jeder auf Anhieb versteht, ist langweilig. Mach es spannend. Sei kryptisch. Je schwieriger das Puzzle, desto ergiebiger ist der Zeitvertreib für jeden, der deinen Code nachvollziehen soll. Desto größer ist auch der Respekt, der deiner geistigen Leistung gezollt wird.

Auslagern, auslagern, auslagern. Frikassiere zusammenhängenden Code in möglichst viele Teilroutinen, und verteile diese auf möglichst viele Dateien. Maximiere die gegenseitigen Abhängigkeiten.

Erschwere die Wartbarkeit in jeder Form. Erst wenn dein Programm so kompliziert wird, dass sich niemand traut, es zu ändern, hast du gewonnen.

Entwickle deine Software weitab gängiger Programmierstandards. Erschwere Migration, wo immer es geht.

Verwende möglichst viele unterschiedliche Sprachen, bilde einen bunten Mix. Konzentriere dich auf Frameworks, die seit mindestens 15 Jahren kein Update mehr bekommen haben: Damit tust du etwas Gutes für den Denkmalschutz.

Benenne Verzeichnisse, Dateien, Namespaces, Klassen, Variablen, Parameter, Templates, Funktionen oder Subroutinen nie mit aussagekräftigen Begriffen. Verwende stattdessen "bli", "bla", "blubb", "big-heaven" oder "hugo". So was liest jeder gern. Betitele deinen Code als Best Practice.

Vermeide jede Art von Dokumentation.

Verlangt dein Kunde, dieser Laie, dennoch eine Doku, dann vermeide fachliche Bezüge zum Quelltext. Schreib irgendwas, aber nichts zum Thema.

Lösche ältere Code-Kommentare entweder ganz oder lass sie unverändert stehen (für spätere archäologische Forschung). Auf keinen Fall darfst du sie aktualisieren.

Verschwende deine Zeit nicht mit systematischem Testing. Die Vielfalt möglicher Fehler wird sowieso erst im praktischen Einsatz sichtbar. Du kannst nicht alle Fehler vorher finden, also fang erst gar nicht damit an. Das machen andere ja auch nicht.

Wenn dein Kunde trotzdem Tests sehen will, dann wähle ein Szenario (ein einziges!), das mit Sicherheit keinen Fehler verursacht, und lass es möglichst oft durchlaufen. Teste auf einem System, dessen Konfiguration keine Ähnlichkeit hat mit jener Umgebung, in der deine Software später produktiv laufen soll.

Für Softwarequalität hast du grundsätzlich keine Zeit.

Always trust, never verify. Bring der Qualität der Daten, die deine Software verarbeiten soll, grenzenloses Vertrauen entgegen. Ignoriere, nein, besser: Unterdrücke konsequent Fehlermeldungen. Die liest sowieso niemand, und überhaupt sind sie nur lästig.

Wenn du ein Problem in der Software erkennst: Halt die Klappe. Versuch nicht, es zu beheben, es lässt sich sowieso nichts dran ändern. Sprich mit niemandem darüber. Oder suchst du Ärger?

Wenn du weißt, was du tun müsstest, um den Anwender deiner Software vor Schaden zu bewahren: Mach es nur dann, wenn es dir Geld einbringt.

Solides fachliches Know-how ist überflüssig. Im weltweiten Web gibt's Snippets genug. Je weniger du verstehst, was du mit ihrer Hilfe zusammenstückelst, desto besser!

Qualität, Präzision, Zuverlässigkeit, Perfektion, Sicherheit: alles Quatsch! Trickse, mogle, schummle! Betreibe Programmier-Akrobatik! Oder du gehst unter.

Deinen Job hast du schon immer so und noch nie anders erledigt. Wieso solltest du das ändern?

Technische Neuerungen sind Teufelswerk. Bremse sie aus, indem du deine Software so kompliziert wie möglich hältst. Dann ist jeder beschäftigt, da durchzufinden, und niemand hat noch Zeit für strategische Entwicklung.

Undokumentierte Prozesse, Chaos auf den Fileservern, kryptische Dateinamen: ein Paradies! Zerstöre die Idylle nicht durch überflüssige Ordnung. Halte die Suche so aufwendig und spannend wie möglich.

Wenn du Anzeichen für einen Incident erkennst oder selbst einen verursacht hast: Verkrümel dich in die Raucherpause oder in die Fete der Nachbarabteilung. Beschwere dich dort über Langeweile im Job. Komm erst wieder, wenn der Sturm vorüber ist.

Nutze die Freiräume, die unklare und vage Formulierungen des Kunden oder deiner Chefs dir bieten. Das ist die Gelegenheit, Verwirrung zu stiften. Missbrauche sie.

Sobald du deine Dateien auf den Routineserver des Kunden gespielt hast, ist dein Job erledigt. Nach dir die Sintflut. Setze deine Erreichbarkeit auf "unbekannt verzogen".

wg / 2. April 2018



Fragen? Anmerkungen? Tipps?

Bitte nehmen Sie Kontakt zu mir auf.




C#.NET



Vielen Dank für Ihr Interesse an meiner Arbeit.


V.i.S.d.P.: Wilfried Grupe * Klus 6 * 37643 Negenborn

☎ 0151. 750 360 61 * eMail: info10@wilfried-grupe.de

www.wilfried-grupe.de/ratschlaege_schlechter_Programmierer.html