Durch meine Suche nach Adroid-HowTows und mehr Input über dieses Thema bin ich auf den youtube-Channel GoogleDevelopers gestoßen. Die Präsentationen sind meistens richtig gut und von Leuten, die es wissen müssen.
Gerade lief bei mir "The Myth of the Genius Programmer". Dieser Vortrag geht darauf ein, daß die Geschichte ("the ultimate geek fantasy") vom genialen Programmier, welcher sich ein paar Jahre in ein stilles Kämmerlein einschließt und dann mit einem brillianten, perfekten Produkt die Welt erobert und dann für alle Zeiten berühmt ist ein einziger Mythos ist.
Die Vortragenden eröffnen die bittere Wahrheit:
Softwareentwicklung ist ein hochgradig sozialer Prozess, der verschiedensten psychologischen Effekten unterliegt. Unter anderem:
- Programmier wollen ihre Fehler oft verstecken und niemand gibt gerne zu, daß er einen Fehler gemacht hat.
- Allein im Keller zu sitzen und proggen ist toll, aber die richtig guten, großen Projekte werden von vielen Personen geschrieben, die miteinander interagieren müssen.
Also geben sie viele Tipps, wie man besser in kollaborativen Umgebungen arbeiten und Produktiv sein kann, unter anderem:
- Drop the ego: Man sollte sich als Teil eines Teams sehen
- Kritik ist nicht böse: Wie gibt man gutes Feedback? Wie bekommt man ein dickes Fell?
- Embrace Failure: Versagen an sich ist nicht schlimm, konstant am selben Problem zu scheitern schon. Solange man scheitert lernt man. Man sollte Dokumentieren: Was ist passiert? Warum? Was habe ich dabei gelernt? Hier spielt auch viel Versagensangst mit.
- Iterate Quickly: "Don't just fail, fail quickly and try something different as fast as you can." Je schneller man Versagt, desto schneller lernt man auch.
- Being a small fish: Man sollte sich einen Mentor suchen. Wenn man selbst in der Hierachie weiter unten steht, lernt man schneller.
Sie gehen auch auf die Softwareseite ein und reden über Tools:
"The world is full of jerks, but the internet makes it seem that they all live next door to you".
Technologien wie Patchrechte in Versionskontrollsystemen sollten nicht dazu benutzt werden um Probleme mit schwierigen Personen zu lösen. Dann folgen noch Schilderungen von Erfahrungen die sie mit Open Source Projekten gemacht haben und wann der beste Zeitpunkt ist damit zu beginnen kollaborativ zu arbeiten.
Besonders gefallen hat mir die Stelle, an welcher vom "Bus-Factor" die Rede ist. Ich zitiere einfach mal:
"The bus factor is the number of people on your software project that have to get hit by a bus that are gonna leave you in a world of hell. So, if there's only one person that knows that really obscure file system code and they get hit by a bus, whether that bus comes in the form of an actual bus, or they get married, or they have a kid, or they change jobs, or they move away or they get bored..."
Nicht nur, daß der der Grad des Schadens von Personalausfall duch Verkehrsunfälle mit dem von Kinderkriegen oder Heiraten gleichgesetzt wird (die Kollegen sind mir jetzt schon SEHR sympathisch), gibt es dafür auch noch Tipps. Der "Bus-Faktor" sollte klein gehalten werden indem so viele Leute wie möglich über so viele Teile des Codes wie möglich bescheid wissen sollten.
Das geballte IT-Wissen ist nur so über mich hereingebrochen und ich würde mir am liebsten alle Talks nacheinander reinziehen...