Wie werde ich ein besserer Entwickler?

In den letzten Tag ist dieses Thema der Dauerbrenner im Netz. Überall liest man darüber, überall redet man darüber. Und seit einigen Wochen denke ich auch ständig darüber nach.<p />Wie wird man ein besserer Entwickler?<p />Als erstes fällt mir da immer ein Spruch ein: Es dauert 10 Jahre, um in irgendeinem Thema Experte zu werden. Ich halte mich zwar nur in wenigen Dingen für einen Experten, aber nach meinen Erfahrungen stimmt der Spruch 100%ig. Ich habe 10 Jahre gebraucht, bis ich ganz passable Keyboard+Klavier spielen konnte. Ich habe 10 Jahre gebraucht, bis ich gut programmieren konnte. Ich werde auch 10 Jahre brauchen, bis ich gut im Bodybuilding sein werde. Aber das sind wieder andere Themen… ;-)<p />Wie werde ich also ein besserer Entwickler?<p />Innerer Antrieb<p />Ich denke, ein guter Entwickler braucht vor allem einen inneren Antrieb. Einen Antrieb, der einen abends vom Sofa hoch und an den Rechner treibt. Der einen dazu bringt, neue Sprachen wie Groovy oder Prolog zu lernen. Der einen dazu bringt, sich mit Continuous Integration zu beschäftigen. Oder Unmengen Bücher zu lesen. Dieser Drang bringt einen auch dazu, nicht einfach nur die gestellten Aufgabe zu lösen, sondern dabei auch noch Einzelheiten um das eigenen Problem herum aufzunehmen. Das heißt, man lernt durch die Problemlösung das System selbst besser kennen.<p />Dieser innere Antrieb wird von manchen auch passion genannt, also die Hingabe an die selbst gewählte Profession. Wer keinen Spass an der Arbeit hat, ist meiner Meinung nach im falschen Beruf. Wer will schon sein Leben lang etwas tun, zu dem er gar keine Lust hat – und wer will dann auch noch Extra-Zeit aufwenden, um in diesem Bereich besser zu werden…?<p />Code lesen<p />Das bringt mich eigentlich gleich zum nächsten wichtigen Punkt, dem Lesen von Code. Nichts hilft mehr in der persönlichen Entwicklung, als den Code anderer Leute anzuschauen. Vielleicht ist das ein gutes Framework, in dem man bestimmte Patterns wiedererkennt. Oder es ist eine Anwendung, die man in einem Open Source Repository wie Sourceforge oder Github anschauen kann. Hat man das Glück und arbeitet in verschiedenen Projekten mit unterschiedlichen Leuten, sollte man auch den Code der anderen ansehen.<p />Das dient nicht nur der Weiterbildung, sondern hat auch einen ganz pragmatischen Zweck: die Anpassung des eigenen Stils an die Projektvorgabe. Man kann zwar seine eigene Handschrift in die Arbeit einbringen, aber bitte nicht beim code style oder bei der Architektur. Kreativität sollte in der Anwendung der Prozesse stattfinden, nicht in Kraut-und-Rüben-Code. ;-)<p />Andere Dinge<p />Es gibt viele andere gute Quellen und ich liste hier nur meine Top 5 auf:<p /><ul>

<li>Podcasts</li> (wie z.B. Hanselminutes, ArchitekTOUR, Herding Code)
<li>Bücher</li> (eBooks, Papier, Online)
<li>Blogs</li> (es gibt hunderte gute Blogs&uuml;ber Softwareentwicklung)
<li>Twitter</li> (viele kluge Köpfe twittern jeden Tag&uuml;ber ihre Erfahrungen und Arbeit)
<li>Konferenzen</li> (daran muss ich noch arbeiten)
</ul><p />Es gibt so viele Möglichkeiten, die man nutzen kann. Die man nutzen muss? Auf jeden Fall bieten sich unzählige Möglichkeiten, die eigene Entwicklung voranzutreiben, ohne jeden Tag ein Seminar zu buchen. Man muss nur zupacken.<p />Und auch hier gilt: Wer immer in der eigenen Komfortzone bleibt, macht auch keine Fortschritte. Wer wirklich etwas erreichen will, muss sich ständig antreiben und seinem Drang nachgeben. :-)<p />Hat jemand andere Tipps oder Erfahrungen? Gibt es Dinge, die euch geholfen haben, besser zu werden oder neue Dinge zu entdecken? Schreibt einfach einen Kommentar oder antwortet mir per Mail.

Hero Coders?

Jeder kennt einen dieser Hero Coder. Sie atmen Sourcecode aus, sobald sie den Mund aufmachen. Hacken, was das Zeug hält. Korrigieren Fehler in atemberaubendem Tempo. Aber braucht man sie, um Projekt erfolgreich abzuschliessen? Und tragen sie wirklich langfristig zum Erfolg bei?<p />Meine Antwort lautet: Nein.<p />Und zwar aus dem einfachen Grund, dass Software keine Ein-Mann-Show ist. Heutige Softwareprojekte sind riesengroß, kompliziert und nur von mehreren guten, eingespielten Entwicklern zu schaffen. Und Sourcecode muss gehegt und gepflegt und nicht in wilder Hackerei zusammengebaut werden. Dazu gehört eine gute Dokumentation, eine ordentliche Architektur und vor allem eingespielte Prozesse, die jeder befolgt. Das müssen keine endlosen Formularkriege sein, aber ein gewissenhaftes Vorgehen der gesamten Mannschaft.<p />Das fängt an beim Erstellen und Pflegen von groben und detaillierten Design-Dokumenten, geht&uuml;ber die Nutzung eines Bugtrackers, dem Befolgen eines coding styles bis hin zu guten commit messages. Und natürlich gehört Kommunikation dazu: Jedes Teammitglied muss wissen, wohin das Projekt geht und muss sich mit den anderen abstimmen. Damit meine ich wieder keine endlosen Meetingmarathons, sondern die Verständigung quer&uuml;ber den Schreibtisch. Fragen und Antworten, Lesen der Projektemails und Dokumentation, Querlesen von Sourcecode anderer… und genau da bleibt der hero coder auf der Strecke.<p />Wer sich zum Code schreiben immer einschliesst, keine Designs liest und&Auml;nderungen vornimmt, ohne Rücksicht auf andere, der gehört für mich nicht in die Kategorie Guter Softwareentwickler. Und seien wir ehrlich: Jeder von uns war schon einmal dieser Typ. ;-)<p />Meine Einstellung zur Softwareentwicklung tendiert in der letzten Zeit aber immer mehr zu dem Begriff software craftsmanship, d.h. Softwareentwicklung als Handwerkskunst zu sehen und alle dazugehörigen Arbeiten im Einklang mit dieser Vorgabe zu erledigen. Jeder Statiker, jeder Architekt wird mit diesem Begriff etwas anfangen können. Leider wird Softwareentwicklung immer noch als kreativer Prozess wahrgenommen, der von krawattenlosen Revoluzzern in einem kreativen Chaos betrieben wird… Aber genau wie bei Statikern oder Architekten sollte sich die Kreativität nicht im Handwerk wiederfinden, sondern in der kreativen Auslegung der bestehenden Prozesse.<p />Genau diese Sicht wird hervorragend in dem Artikel They Write The Right Stuff beschrieben, der&uuml;ber die Softwareentwicklung für das Space Shuttle erzählt.

Gutes Build Management

Heute musste ich leidvoll erfahren, dass ein gutes Build Management für alle Projekte notwendig ist und niemals vernachlässigt werden sollte.

Ich wollte ein altes Projekt in Hudson integrieren. Dabei musste ich aber feststellen, dass sich mir die Reihenfolge der Ant-Targets nicht mehr erschloss. Es gab kein Target dist, dass alle notwendigen Schritte ausführt. Das default Target war zwar abhängig von 2 anderen Targets, konnte aber den Build nicht allein erstellen. Nach ein wenig Ausprobieren und Editieren musste ich auch feststellen, dass einige Bibliotheken im Classpath fehlten. Sowohl beim Kompilieren als auch im Classpath von Ant selbst.

Und genau da liegt auch ein Vorteil von Buildsystemen: Es werden verschluderte Abhängigkeiten von Entwicklerrechnern aufgedeckt. Aus der IDE heraus (so wie das betroffene Projekt immer gebaut wurde) lief alles glatt. Jetzt – mit einem frischen Rechner und ohne die Bibliotheken in der Umgebung – schlägt der Build fehl. Wie aufwändig es jetzt wird, dieses Projekt wieder buildfähig zu machen, kann ich nur schätzen. Eventuell lag es heute abend nur an der fortgeschrittenen Zeit und an meinem daher schon etwas vernebelten Blick, vielleicht ist morgen nach 5min wieder alles gut.

Aber die Lieferfähigkeit wäre im Zweifelsfall deutlich eingeschränkt. Und da sehe ich eine große Stärke der Buildsysteme, wenn sie von Anfang an konsequent im Projekt eingesetzt werden: Der Build läuft und Fehler werden sofort entdeckt. Und sollte man nach 6, 12 oder 24 Monaten noch einmal an das Projekt heran müsste, würde man einfach das Buildsystem wieder aktivieren (vielleicht würde es nach einem neuen Commit ins Repository ja auch automatisch wieder loslegen…) und hätte eine Lieferversion erzeugt.

Und da soll die Reise hingehen. Wenn’s nach mir geht, so schnell wie möglich und mit allen Tools zur Qualitätskontrolle: Checkstyle, FindBugs, StyleCop, Unit Tests…

Algorithmen galore

Gerade habe ich bei Amazon 80€ auf den Kopp gehauen. Zwei neue Bücher sind auf dem Weg zu mir:

Das erste ist quasi ein Standardwerk für Algorithmen, das ich aber nicht kenne. Das zweite hab ich gleich dazu bestellt, weil es in Beispiele in Java enthält – wo ich mich bekanntlich am wohlsten fühle. Eine bekannte Sprache in den Beispielen zur Verfügung zu haben stelle ich mir sinnvoll vor, gerade wenn mir unbekannte Algorithmen besprochen werden. Zwei Bücher habe ich bestellt, um die Algorithmen aus beiden vergleichen zu können. Große Unterschiede im Inhalt werde ich wohl nicht vorfinden, aber ich lasse mich überraschen.

Und warum das ganze? Weil mir klar geworden ist, dass ich viel zu wenig über Algorithmen weiß. Gerade die Standards, aber auch die Theorie dahinter. Zeitverhalten, Komplexität, Aufwand und Einsatz. Das kann einfach nicht so bleiben!