Halbwertszeit von Wissen

Ein spannender Aspekt an der Software-Entwicklung ist die ungeheure Vielfalt an Konzepten, Technologien und Frameworks. Interessierte Software-Entwickler sind ständig dabei, Dinge neuzulernen, vorhandenes Wissen skeptisch zu validieren, und veraltetes Wissen (oder Ansichten) explizit “zu vergessen”.

IT-Wissen hat unterschiedliche Halbwertszeiten. Nehmen wir als Beispiel die Beherrschung der BlackBerry-API: Diese API ist an ein Produkt gebunden. Wenn das Produkt komplett auf eine neue Basis umgestellt wird oder gar stirbt, ist das vorhandene Wissen bzw. die Erfahrung mit der API auf einmal wertlos. Das gleiche gilt beispielsweise auch für Browser-“Optimierungen” (a.k.a Hacks) im Frontendbereich. Frontend-Entwickler, die sich bestens mit IE6 oder IE7-Hacks auskannten, können diese Informationen getrost vergessen, da das Produkt (der Internet Explorer 6,7) einfach nicht mehr relevant ist.

Das Einzige, was vom “Produkt”-Wissen bleibt, sind Konzepte, Strukturen und Ideen, die sich auf andere Gebiete übertragen lassen und die Fähigkeit, Probleme zu analysieren und schnell Lösungen zu finden.

Abseits von der Produktwelt ist das Wissen beständiger. Nehmen wir die HTTP-Spezifikation: HTTP 1.1 gibt es schon seit 1997, und wird wohl noch eine Weile bestehen (Auch wenn Google mit SPDY die Vorlage zu HTTP 2.0 geliefert hat). Von daher lohnt es, die Spezifikation wirklich komplett durchzuarbeiten, sofern man irgendwas mit Internet zu tun hat.

Andere Klassiker sind z.B. die 1989 veröffentliche Bash-Shell oder der wohl ewig nutzbare Vim-Editor. Wer sich da wirklich einarbeitet, kann Jahre davon profitieren.

Die Halbwertszeit von Wissen ist eine wichtige Variable bei der Zusammenstellung des eigenen “Knowledge-Portfolios“. Fundiertes Produkt-Wissen ist natürlich für die tägliche Arbeit unerlässlich, es darf aber nicht das Einzige sein, was man in das Portfolio übernimmt. Sehr wichtig ist es, Wissen mit langer Halbwertszeit zu identifizieren und so das eigene Portfolio langfristiger zu gestalten.