Code Kata

vom 18. July 2008

Auf codinghorror.com habe ich neulich einen interessanten Artikel gelesen, der sich mit der generellen Frage beschäftigt, ab wann man ein Experte ist, ab wann man dazulernt und warum Praxiserfahrung wichtig ist.

[...]Contrary to what you might believe, merely doing your job every day doesn't qualify as real practice. Going to meetings isn't practicing your people skills, and replying to mail isn't practicing your typing. You have to set aside some time once in a while and do focused practice in order to get better at something. I know a lot of great engineers -- that's one of the best perks of working at Amazon -- and if you watch them closely, you'll see that they practice constantly. As good as they are, they still practice. They have all sorts of ways of doing it, and this essay will cover a few of them.[...]

Von täglicher Routine wird man nicht besser. Erst wenn man sich Zeit für neues nimmt, an seine Grenzen stößt und genau dort weitermacht wo man scheitert, wird man besser. Jeff Atwood hat eine interessante Liste mit Tipps zusammengetragen, von denen ich ein paar für sehr wichtig halte und deshalb - zusammen mit einigen Tipps von mir - hier noch einmal aufführe.

Such dir einen Helden

Schau dir auf Wikipedia die Pioniere der Informatik an und such dir einen davon raus. Folge allen Links und lese über ihn. Finde heraus, mit was sich dein Held beschäftigt (hat) und versuche seine Lösungswege zu verstehen.

Lese fremden Code

Lies täglich 20 Minuten lang Code von anderen Programmierern. Wenn du keinen Code von Arbeitskollegen oder Freunden bekommen kannst, such dir ein Open-Source-Projekt das dir gefällt und arbeite dich in den Code ein. (Beispielsweise Firefox, RubyOnRails, Django, Subversion, o.ä.) Anfangs scheint es so, als wäre der Code in einem Leben nicht zu überschauen, doch mit der Zeit findet man Muster, versteht die Zusammenhänge, erkennt wie Probleme gelöst wurden und lernt Techniken und Architekturen kennen. Auch erkennt man auf diese Weise, was guten Programmcode ausmacht.

Lasse andere deinen Code lesen

Such dir eine Person, die deinen Code lesen will und lasse diese deinen Code bewerten. Gute- sowie schlechte Programmteile müssen hervorgehoben werden, nur so lernt man dazu. Ein "Ja, ist ganz nett" bringt niemanden weiter.

Nutze deine Programme besser

Mach eine Liste mit deinen 10 meistgenutzten Tools und lese für eine Stunde das Hanbruch/Dokumentaton/ManPage eines zufällig ausgewählten Programms. Versuche in dieser Stunde neues über dieses Programm herauszufinden und Arbeitsabläufe zu beschleunigen. Beispielsweise Shortcuts, Features von denen du noch nichts gehört hast oder Konfigurationseinstellungen, die die Bedienung einfacher machen.

Programmiere!

Theorie schön und gut, aber ohne richtige Programmiererfahung wird man nicht weit kommen. Der Beste Weg dafür ist es einfach zu tun. Probiere neue Technologien aus, schaue dir unterschiedliche Frameworks an und hacke was das zeug hält!

Wer ist der Beste?

Suche und arbeite zusammen im Team an Projekten. Finde heraus, was es bedeutet, der beste und der schlechteste Programmierer zu sein. So kannst du herausfinden, wie du besser werden kannst.

Code-Pflege

Lerne fremden Programmcode, den du nicht geschrieben hast zu warten. Am Besten funktioniert das, in dem man ein verwaistes Projekt wieder auferstehen lässt (fork) oder Fehler behebt (bug-fixing). So lernt man, was es ausmacht, wartbaren Code zu schreiben.

Lerne verschiedene Programmiersprachen

Such dir eine Programmiersprache heraus, die komplett andere Konzepte und Strategien verfolgt, welche du bis jetzt noch nie genutzt hast oder welche dir bis jetzt noch nie bewusst waren.

Für weitere Tipps und Kritik steht die Kommentarfunktion und die Anmerkungen am Linken Rand bereit :)

delicious bookmark del.icio.us, Auf codinghorror.com habe ich neulich einen [interessanten Artikel][0] gelesen, der sich mit der generellen Frage beschäftigt, ab wann man ein Experte ist, ab wann man dazulernt und warum Praxiserfahrung wichtig ist. *[...]Contrary to what you might b


Kommentare


kb am 18. July 2008
Ach maaaan - jetzt hatt ich so n langen Text und dann hab ich auf den Pioneerlink geklickt..

Was ich sagen wollte: Einige Punkte sind beim täglichen arbeiten durchaus gegeben:
Code-Pflege von anderen
Code von anderen lesen
Seinen Code lesen lassen (na gut, so ein richtiges Feedback gibts nicht)
Arbeiten in Teams..

Nachdem ich nur mehr oder weniger motiviert war in den letzten, kurzen, Semesterferien Ruby on Rails zu lernen habe ich jetzt einen neuanlauf gewagt (und das sogar schon vorgestern, ganz aus eigeninitiative!) und jetzt liegt hier erst mal 1 Buch über Ruby und 3 über Rails. Das möchte ich neben meiner Arbeit in den Sommerferien noch lernen. Ich vertrete da nämlich genau die gleiche Ansicht wie du!

Das mit den Tools hört sich auch gut an .. schieb ich aber auf :D
Bis ich meine endgültige Arbeitsumgebung gefunden habe..

jthoenes am 18. July 2008
Also,

ich finde es schade, dass du nicht zwischen deinen Atwoods Tipps trennst. Wäre im Sinne der Nachvollziehbarkeit notwendig.

Und zum letzten Punkt. Ich schlage an dieser Stelle Scala vor ;-) Wenn du mein Blog liesst, werden in den nächsten paar Monate einige Beispiele von mir dort auftauchen ...

Gruß
Johannes

Aaron am 31. July 2008
Ich habe sie deshalb nicht getrennt, da ich im Prinzip nur die Ideen übernommen habe. Hätte ich die Tipps frei übersetzt oder 1:1 übernommen, hätte ich natürlich eine klare Trennung von meinen und denen von Atwoods gemacht. Zudem sind die Tipps ja ursprüunglich von Peter Norvig und Steve Yegge.

Felix am 2. August 2008
Der Beitrag gefällt mir.
Ich bin gerade bei meiner DiplArbeit und in diesem Rahmen entwickel ich Software mit einem andernen noch zusammen. Das Programm ist soweit fertig und hat ca. 35000 Zeilen Code in 127 Klassen.
An so einem großen Projekt habe ich bis jetzt noch nie mitgearbeitet.
Nach meiner Ansicht habe ich gerade durch das Ausarbeiten von Routinen im Rahmen dieses Projektes viel gelernt. Es war also meine "tägliche Routine", die mir neues gezeigt hat.
Was ich sagen will: Tägliche Routine zu haben ist kein Nachteil für die eigene Weiterentwicklung, wenn man seine "Routinen" flexibel hält. Ja ich weiß, Routine und Flexibiltät widerspricht sich...doch so ist es ja meistens im Leben und das funktioniert auch ganz gut :-)

Claudio am 14. September 2010
Die Idee des Idols - "Such dir einen Helden" - aufzugreifen, find ich super! :-)

In agiler SW-Entwicklung (Scrum, XP) werden die anderen Ideen auch idealerweise praktiziert: mittels Retrospektive, Code Review, Collective Ownership und Pair Programming.