Die Vorlesungen von VB* waren so mit die genialsten, die ich im Studium hatte. Einer seiner Hinweise war es, beim Einstellen** von Programmieren explizit nicht auf die sozialen Umgangsformen oder Konstrukte wie „Teamfähigkeit“ und „Angepassheit“ zu achten. Seine (durchaus richtige) Argumentation geht in die Richtung, dass bei einem Entwickler ausschließlich die Codequalität wichtig ist, das menschliche Miteinander geht dagegen unter – und ist häufig nicht wichtig, im Zweifelsfall wird der Kundenkontakt unterbunden und wenn es externen Kontakt gibt, wird darauf geachtet, dass das Gegenüber auch ITler ist.
Zusammenfassend nannte er diese Art von Programmierern Diven, die es zu hegen, pflegen, verwöhnen und schützen gilt.
Einen riesigen Schwachpunkt hat der Ansatz aber: Wenn nun ein Coder eingekauft wird, der im Umgang eine Diva ist, aber nicht die überragende Qualität liefert, die dieser Personalansatz verlangt? Ein umgänglicher durchschnittlicher Entwickler ist einbindbar in Arbeitsabläufe, um einen nicht umgänglichen überdurchschnittlichen Entwickler werden die Prozesse herum gebaut.
Und ein durchschnittlicher nicht umgänglicher Coder? Dann knirrscht es an allen Ecken und Enden, man muss um ihn herumplanen und seine sozialen Eigenheiten verbunden mit normaler Buganzahl sorgen für Stress und Mehraufwand in jedem einzelnen Projekt- oder Prozessschritt.
*) VB nicht wie Visual Basic, auf diese Vorwürfe reagierte er mit FdiK
**) der Studiengang ist darauf ausgelegt, dass am Ende Personalverwantwortung im Lebensplan da ist. ich nutzte den Wirtschaftsanteil ausschließlich dafür, den Feind kennen zu lernen…