„The Social Network“ – ein Film von und für Programmierer

5 Kommentare

Gestern Abend hab ich den Film „The Social Network“ über Mark Zuckerberg den Gründer von Facebook gesehen. Meiner Meinung nach ein Must-Seen für Programmierer, denn es werden darin (unter anderem) 3 Punkte aufgezeigt, warum sein „Webprojekt“ so erfolgreich war:

1. Finde die simple Idee
Wenn man mal erfolgreiche Ideen/Produkte vergleicht, wird man feststellen, das bei den allermeisten eine simple Idee zugrunde lag, mit welcher sich das entsprechende Produkt von allen anderen abgegrenzt hat. Die Betonung liegt hierbei auf „simpel“ – einfach, unkompliziert, selbsterklärend. (=> KISS)
Bei Facebook war es die Exclusivität, die man plötzlich mit einer niedrigeren Einstiegshürde erreichen konnte und mit der „das wichtigste“ des Uni Alltags virtuell und einfach abgebildet wurde.

2. Geh in den Tunnel
Immer wieder war davon die Rede, eine Person ist gerade im Tunnel und darf deshalb nicht gestört werden. Ich behaupte mal, dass wenn man sich in seine Programmierung vertieft hat, sich also alle Sinne ohne Ablenkung um den Code drehen, ist man 3 mal so effizient, wie wenn man „aus dem Schlaf heraus“ loslegen soll.

3. Begib dich in eine kreative Umgebung
Als schon klar war, das Facebook „cool“ ist (Zitat), ziehen die Entwickler nach Kalifornien. Die erste Szene in deren Haus zeigt, wie Sie Blödsinn man machen und vom Dach des Hauses in einen Pool springen – drinnen hockt einer gerade an nem Rechner.
Wenig später (im gleichen Haus) sind zwei Mädls am Party machen: Playstation, Bong, Saufen. Dahinter hocken ne Handvoll Entwickler im Tunnel.
Ok, das mag etwas übertrieben sein und scheint schon fast sogar Punkt 2 zu widersprechen, aber Inspiration ist nun mal etwas, was nicht von alleine kommt. Kreative Umgebung sieht immer anders aus, jeder hat seine eigenen kreativen Bedürfnisse: Musik, Kunst, Natur… aber wohl eher selten grauer Büroalltag!
Was ich damit sagen will: macht aus eurem Arbeitsplatz eine Umgebung in der ihr euch wohl fühlt.

Natürlich sind das nicht alle Voraussetzungen um erfolgreich zu sein, geschweige denn guten Code zu schaffen. Aber so zumindest das Grundlegende, was man oft übersieht.
Mehr Tipps und Tricks findet ihr im CCD-Wertesystem. :)

PS: ich mag Facebook nicht. Ich glaub ich lösch mich jetzt.

Advertisements

persönliche CCD Reflektion Nr.1

Hinterlasse einen Kommentar

Ich hab schon vor einiger Zeit mir mal die CCD Armbänder bestellt und trage jetzt seit etwa 3 Wochen das rote Band an meinem Arm. Ehrlich gesagt hilft dieses Band wenig, mich während der Arbeit an die Regeln zu erinnern – eher ist es schlechter Code der mich daran erinnert. Ich find die Bänder aber ein bisschen stylisch und hab deshalb auch das schwarze Band ständig an meinem Arm. :-)

Auf jeden Fall bin ich gerade mal die Liste der Prinzipien und Praktiken für den Roten Grad durch gegangen und dabei ist mir mein fatalster Fehler aufgefallen: Ich reflektiere nicht! Das ist auch der Grund, warum ich das Prinzip Favour Composition over Inheritance (FCoI) total unter den Tisch habe fallen lassen. Kein Wunder, dass mir in meinem Posts „private Methoden vermeiden“ nicht aufgefallen ist, dass Vererbung in vielen Fällen gar nicht angebracht ist.

Ansonsten kann ich im Nachhinein sagen, dass ich die anderen Regeln gut einhalten konnte:

  • DRY: Ich liebe dieses Prinzip und es ist mir ins Blut übergegangen. Da muss ich eher aufpassen, dass ich es nicht übertreibe! ;)
  • KISS: Das mach ich meiner Meinung nach sowieso, da ich nicht so der akademische Typ bin und ich zufrieden bin, wenn der Code funktioniert und gut aussieht. Obwohl ich mir vielleicht manchmal mehr Gedanken über eine Lösung machen sollte, anstatt einfach alles auszuprogrammieren. Dies endet nämlich oft in verschachtelten Schleifen die nur noch anhand Ihrer Kommentare zu entziffern sind.
  • Vorsicht vor Optimierung: Davon lass ich generell die Hände weg. Die Gründe sind ähnlich wie im vorherigen Punkt. Die einzige gern gesehene Optimierung ist bei mir Refaktorisierung!
  • Favour Composition over Inheritance (FCoI): Wie schon im einleitenden Text erwähnt, hatte ich diesen Punkt total übersehen. Aber ich denke, dass genau hier zu oft strukturelle Fehler entstehen. Zumindest konnte ich das so bei mir feststellen.
  • Pfadfinderregel beachten: Meiner Meinung nach die beste Regel um alle Praktiken und Prinzipen zu üben: Dreckigen Code aufräumen. Damit gewöhnt man sich schnell ab, selber ekligen Code zu schreiben. Zumindest tut es ganz arg im Hirn weh, wenn man man doch schnell mal etwas hinhackt! ;)
  • Root cause analysis: Das ist eine Sache, an der ich noch einiges arbeiten muss. Denn schneller ist ein Workaround gebaut, als der eigentliche Bug entfernt. Liegt aber auch daran, dass ich in der Dienstleistung und nicht in der Entwicklung arbeite. Da hab ich einfach kein Zeit mit meinem lahmen Rechner die Dependency Projekte zu debuggen, den Fehler zu beheben und dann alles noch hoch zu laden. Wenn es auch noch ganz schlecht läuft, bin ich dann für die Folgefehler verantwortlich und es geht noch mehr Zeit drauf! Meine Alternative: Workaround bauen und den Bug ins Tracking System eintragen.
  • Ein Versionskontrollsystem einsetzen: SVN ist cool! Mehr hab ich nicht zu sagen. Zum Glück darf ich es einfach nur verwenden. (Danke Edu)
  • Erste Refaktorisierungsmuster anwenden: Im roten Grad bedeutet das nur Methoden extrahieren (=> DRY) und Umbenennen. Beides habe ich sehr oft gemacht in letzter Zeit und bin daher ziemlich zufrieden mit mir.
  • Täglich reflektieren: Hatte ich bisher leider vergessen. Vor allem, wenn ich kurz vor Feierabend noch schnell was machen muss und dann einfach keine Lust mehr hab länger zu bleiben. Aber ich denke, dass ich es damit nachgeholt hab. Mal sehen, ob ich es zukünftig besser umsetzen kann.

Mein Fazit: Diese Woche noch roter Grad – nächste Woche widme ich mich dann dem orangenen zu.

Clean Code Developer

1 Kommentar

Ich möchte hier kurz ein sehr interessantes Projekt, Aktion oder vielleicht eher eine „Programmierer Religion“ vorstellen: Die Clean Code Developer.

Es handelt sich hierbei um ein Team, welches ein Wertesystem mit verschiedenen Regeln, Prinzipien und Praktiken definiert hat, deren Einhaltung dazu dienen soll, generell besseren Code zu hinterlassen.

Eigentlich sind dies zum größten Teil Regeln, die den meisten Entwicklern mehr oder weniger bewusst/bekannt sind. Doch mit dem CCD Werte System wurde nun ein Standard definiert, an dem man sich immer wieder messen und mit der Hilfe dessen man immer mehr zum Programmierer mit der weißen Weste wird ;).

Ich persönlich finde diese „Aktion“ super und werde mir demnächst auch mal die coolen Armbänder bestellen ;) und das Wertesystem zu Herzen nehmen.