Kategorien
Du bist nicht der beste Softwareentwickler
Ich habe vor „kurzem“ mal einen Bericht gelesen von einem Softwareentwickler, der die wichtigsten Erfahrungen aus 20 Jahre Programmierung zusammengeschrieben hat. Ein Satz ist bei mir irgendwie hängen geblieben und da ich ihn gut fand, möchte ich heute auch mal kurz darüber schreiben (wenn jemand von euch übrigens einen Link auf den 20 Jahre Artikel hat, dann her damit, ich habe ihn leider verloren).
„Du bist nicht der beste Softwareentwickler.“
Na klar ist das so, werdet ihr denken. Es gibt viele Entwickler, der besser sind als ich. Joel Spolsky z.B. vielleicht auch Kent Beck und die anderen großen Software-Gurus. Ich würde mir nie anmaßen, mich mit diesen Größen messen zu können. Aber so einfach will ich’s natürlich nicht machen. Den Satz meine ich ein wenig anders. Auch bei mir im Team gibt es Leute, die mehr auf dem Kasten haben. Zumindest in einigen Gebieten. Früher, das war noch bei Nero, da war ich manchmal so von mit überzeugt, dass ich mir gar nicht mehr unbedingt die Meinungen der anderen angehört habe. Meine war eh „richtiger“. Ich übertreibe jetzt natürlich ein wenig, aber so ähnlich habe ich mich manchmal gefühlt.
Das Problem an dieser Einstellung ist, dass man in so einer Situation gar nichts mehr dazu lernen kann. Auch wenn die anderen gute Ideen haben, überhört man die meistens, verzichtet sogar auf Diskussionen. Wie soll so ein Teamgefühl aufkommen? Wahrscheinlich gar nicht. Man sollte sich also immer vor Augen halten, dass man nicht der beste Softwareentwickler ist und immer dazulernen kann. Auch von Leuten, die man gerne unterschätzt. Mittlerweile habe ich es glaube ich geschafft Meinungen von anderen einzuholen, auch wenn ich der Meinung bin schon nahe an der perfekten Lösung dran zu sein. In den meisten Fällen wird die Lösung besser dadurch.
Da stimme ich dir absolut zu.
Ich merke das jeweils, wenn ich Code Reviews mit den Lehrlingen mache. Obwohl ich ziemlich sicher den grösseren Rucksack als sie habe, gibt es immer wieder interessante und clevere Sequenzen zu entdecken.
Es ist wohl auch ein gutes Gefühl, wenn sie mir erklären können, warum sie dies so gelöst haben 🙂
Meinst Du diesen Artikel?
Tja, als Teamleiter ist es wichtig die Stärken und Schwächen der anderen zu kennen. Man muss nicht alles können, aber man muss wissen, wen man fragen oder notfalls anrufen kann, falls ein bestimmtes Problem auftritt.
Gleiches Problem wenn das Management glaubt sie wären allwissend. Dann wird externe Expertise nicht eingeholt, sich an externen Treffen der Entwicklercommunity nicht beteiligt und Schulungen nicht zugelassen – denn man ist ja sowieso viel klüger als der Rest.
Wenn jemand merkt, dass er/sie etwas nicht weiß, gibt es zwei Arten von Menschen: die einen versuchen es sich anzueignen. Die anderen entscheiden: das brauche ich nicht zu wissen, denn es ist a) schlecht b) blöd c) nur was für niedere Mitarbeiter.
Aus diesem Grund bin ich auch strikt gegen fachfremde Geschäftsführer von technischen Unternehmen.
Meine Erfahrung ist, dass fachfremde Leitungspersonen im Management – insbesondere (aber nicht nur) Frauen – die Ansicht entwickeln, sie bräuchten von der Technik dahinter keine Ahnung haben (schließlich ist das nicht ihr Gebiet und nicht ihre Aufgabe). Was vergessen wird: auf der Leitungsebene muss man in der Lage sein eine Produktvision zu vermitteln. Wie soll man der Truppe voranreiten, wenn man verkehrt herum auf dem Gaul sitzt?
Als Folge werden Aufträge an Land gezogen für Produkte, die man gar nicht hat, zu absurden Preisen, die man gar nicht leisten kann.
Hallo Nils,
leider gibt es genug Leute, die in ihrem Elfenbeinturm sitzen, und der Meinung sind, sie sind schlichtweg Programmierer von Gottes Gnaden. Ich habe einige kennen gelernt. Code anderer Leute wird gnadenlos verrissen und schlecht gemacht, nur der eigene Maßstab zählt. Bei Einem gipfelte es dann darin, das er zutiefst in seinem Ego verletzt war, als ihn jemand auf seine if-Konstrukte ansprach. Nur die eigenen Coding-Standards sind richtig, ansonsten kann man mit anderen nicht zusammen arbeiten. Sind natürlich extreme Beispiele, aber es zeigt deutlich, was dabei heraus kommt, wenn man sich nie und nimmer, auch nur ein bisschen in Frage stellt, oder auch nur einen gut gemeinten Rat annimmt, anstatt sich beleidigt oder angegriffen zu fühlen.
Gut passt dazu auch ein Zitat von Philip Rosenthal (Unternehmer, 1916):
„Wer aufhört, besser zu werden, hat aufgehört, gut zu sein.“
In dem Satz steckt irgendwie alles drin und trifft den Nagel in vielen Bereichen auf den Kopf.
Da kann ich mich nur anschließen.
Auch wenn man natürlich oft mehr Erfahrung und Wissen als die Frischlinge hat, so kommen gerade von denen oftmals in Diskussionen die interessantesten neuen Ansätze. Eben auch weil sie noch nicht in festgefahrenen Bahnen denken und auch unkonventionellen Lösungen gegenüber offen sind.
Und gerade diese anderen Denkansätze lassen die eigene Lösung auf einmal in einem anderen Licht erscheinen und man erkennt, dass diese Lösung auch noch optimiert werden kann.
Auch wenn coden schon etwas mit Architektur und Best-Practises zu tun hat, trotzdem steckt auch ein gewisser kreativer Prozess mit drin. Und mehrere Leute sind eben noch immer kreativer als Einer alleine.
Ja aber ich bin doch aber der beste Softwareentwickler 😉 *späßle*
Ich lerne täglich dazu, so auch wie es das Zitat von DSB aussagt.
Es ist köstlich mit Erfahrungen herum zu prahlen, noch schöner allerdings ist es innovative Ideen von seinen Azubies zu hören 🙂
Als Web/Anwendungsentwickler sage ich immer:
„Man schwimmt nicht mit dem Strom sondern gegen den Strom“.
Wer aufhört zu lernen entfernt sich immer weiter vom Ziel…
Top ist es, wenn ein Team aus unterschiedlichen Altersgruppen, Berufserfahrung und Fachbereichen besteht.
(Best Practice, Ergeiz und Unterschiedliche Denkansätze an einem Tisch)…
Als Einzelperson ist es immer schwer sich selbst einzuschätzen (kein Vergleich vorhanden), keine anderen Gedanken, Lösungen und Ideen…
@Florian: Ja genau den, vielen Dank.
@Christian dem würde ich wiedersprechen, vergleich gibt es immer mit anderen, und sei es nur durch das Weiterbilden. Klar die Selbstreflexion wird dadurch schwierigern, denn wer stehlt seine eigenen Lösungen gerne in Frage um besser zu werden.
> …denn wer stehlt seine eigenen Lösungen gerne in Frage um besser zu werden.
Öhm, jeder der besser werden will?
Bei Scrum gibt es ja auch die Retrospektive. Dies kann man im kleinen auch auf sich selbst anwenden und dann kann man auch besser werden. Kritische Betrachtung der eigenen Arbeit ist mE sehr wichtig, es darf aber auch nicht ins Gegenteil umschlagen, sodass man die eigene Lösung grundsätzlich als schlecht betrachtet.
Man muss eben den Mittelweg finden.
Meinst du mit „vor Kurzem“ eigentlich den 16. Januar 2010? Zu jenem Zeitpunkt wurde der Artikel nämlich im Lesestoff verlinkt. 🙂 An solche Artikel sollte man irgendwie regelmäßiger erinnert werden.