Kategorien
Entwickler 2.0
Heute möchte ich mal eine Lanze brechen für all die, die Spaß daran haben sich weiter zu entwickeln. Ich muss vorne weg sagen, das meine Kollegen, mit denen ich jetzt zusammen arbeiten darf, dazu gehören. Trotzdem gibt es immer wieder PHP Entwickler, bei denen so etwas nicht auf der Tagesordnung steht. Ich nenne die zwei Typen mal Entwickler 1.0 und Entwickler 2.0.
Der 1.0 Typ ruht sich auf dem aus, was er kann. Er macht alles, wie er es immer schon gemacht hat, denn hier kennt er jeden „Handgriff“ in- und auswendig. Im Legacy Code ist er zuhause und weiß genau, in welcher Datei in welcher Zeile er was verändern muss, um Dinge anzupassen. Außer ihm weiß das leider kaum jemand, denn man braucht Jahre, um den unstrukturierten PHP4 (?) Code so gut zu überblicken wie der Kollege 1.0. Was würde also ein 2.0er machen? Sich den Code schnappen und ihn so umbauen, dass dorthin kommt, wo man in auch erwartet (das kann peut-a-peut passieren). Das bedeutet natürlich man muss mit alten Ritualen brechen und neue lernen. Ganz üble Sache. Mit dem „das haben wir schon immer so gemacht“ ist es dann nun mal Schluss. Eigentlich eine sehr sehr angenehme Sache, wenn man es Projekt zusammen umbaut, so das es wieder passt. Falls man alleine diesen Wunsch hegt, dann kann man in Probleme geraten.
So passierte es einem gewissen Nils L. als er in Karlsruhe gegen Windmühlen kämpfte. Der Kampf war zum Glück nicht so lange, denn irgendwann klappte alles ganz gut im Team. Dennoch gab es einen Kollegen, der an alte Rituale festhielt. Das Problem war dabei nicht, dass er nicht mitmachen wollte, sondern dass alles was im Zuge dieses Umbaus für ihn nicht mehr so flüssig ging, gegen mich persönlich und meine Ideen gerichtet wurde. Tja dumm gelaufen. Zumindest habe ich in den Wochen sehr viel gelernt im Umgang mit Kollegen, danke schon mal dafür.
Kann man aus der ganzen Geschichte was lernen? Bestimmt. Ich habe auf jeden Fall gelernt, dass man solche strukturellen Änderungen nur im Team durchsetzen kann, denn wenn man versucht das alleine durchzudrücken, wird man den Umbau immer an den Hacken haben und für alles verantwortlich sein. Das war auf jeden Fall ein Fehler von mir. Im Endeffekt hat zwar alles geklappt, aber ich hatte einen „Feind“ mehr in meinen Leben. Was die anderen gelernt haben, kann ich nur raten. Ich denke mal, dass vielleicht ein Blick auf neue bzw. moderne Technologien und Architekturen nicht mehr so beängstigend sind wie früher. Vielleicht konnte ich ihnen auch mitgeben, dass man Refaktoring auch stückweise betreiben kann, ohne das ganze Projekt neu aufzusetzen. Keine Ahnung. Nächste Woche bin ich in meiner alten Heimat und da werde ich einfach mal rumfragen.Vielleicht versuche ich auch mal den Entwickler 1.5 zu definieren, der eine perfekte Mischform aus den zwei Typen ist und somit jedes Problem meistern kann.
Kennt ihr auch solche Situation? Oder seht ihr euch vielleicht in einem der beiden Typen wieder? Die Kommentarfunktion schreit gerade zu nach eurem Feedback.
Wie aus der Seele gesprochen. Ich habe hier von Entwickler 0.5 bis 2.0 alles sitzen und muss zum einen von allen den Quellcode überprüfen können und zum anderen für jeden die passenden Aufgaben finden. Nicht einfach, sag ich dir 🙂
Hachja.. manchmal vermisse ich diese Streitereien zwischen euch beiden 😀
Ich hab als neutraler Beobachter aber auf jeden Fall auch einiges daraus lernen können und ab und zu spielt sich es auch heute noch ähnlich ab, aber ich könnte Ihn nicht mehr als Entwickler1.0 aber auch nicht als Entwickler 2.0 kategorisieren. Der perfekte Hybride als Entwickler 1.5 (wenn das wirklich die perfekte Form wäre, warum nicht 3.0 ? Lernt aus „Fehlern“ von beiden Vorgängern 😀 ) ist er aber glaube ich auch nicht 😉
@Sebastian: Ich hab doch gar keine Namen gesagt 🙂
Äh ja klar.. ich bezog mich mit „euch“ natürlich auf den Nils L. aus deiner Geschichte und einen anderen Kollegen aus einer Geschichte, die ich auch gerne erzähle. Insofern betrachte mein „Sebastian“ beim Namen eher als ein „Sebastian B.“, denn dieser Post meint ja auch nur rein fiktive Personen aus einer Geschichte 😉
Hallo. Ich möchte zu diesem Thema auch mal meinen Beitrag beisteuern, denn ich finde, auf einen Menschen in meiner Firma trifft er ganz genau zu.
Ich schreibe hier zwar öfter Artikel, verändere aber jedoch meinen Namen und entferne die URL, man weiß ja nie, wer hier noch so rumlungert!
Also: ich mache seit 2008 eine Ausbildung zum Fachinformatiker für Anwendungsentwicklung und arbeite bei einer Agentur, die sich speziell auf das Umsetzen von Internetlösungen spezialisiert hat.
Soweit, sogut, bevor ich dort war, hatte ich noch ein Bewerbungsgespräch, dass wirkte aber auch alles sehr gut und ich konnte noch nicht erahnen, was mich dort erwarten wird.
Ich beschäftige mich seit ca. 8 Jahren mit den Thema PHP und Webentwicklung und bin auch immer sehr erpicht darauf, neue Technologien etc. zu lernen, was auch ganz gut klappt… derzeit lese ich beispielsweise deinen Buchtipp von der Startseite bzgl. der Designpatterns… ich kannte DP zwar schon vorher, aber was dort für interessante Neuerungen drin sind: einfach genial!
Jedoch zurück zum Thema: mein lieber so geschimpfter Ausbilder (dem ich meilenweit voraus bin, sorry Chef) meint immer noch, PHP Versionen weit entfernt von der 5er zu verwenden. Um genauer zu sein ist es die schöne Schnapszahl 4.4.4. Somit sind alle Projekte (und das sind vieeele) auch auf dieser Basis umgesetzt. Umswitchen auf PHP5 gibt es auch nicht, da ja dann vielleicht die anderen Projekte nicht mehr laufen – was auch sein koennte, denn so murksig wie die programmiert sind – KEIN WUNDER.
Der Code ist durchweg prozedural umgesetzt – wen wunderts. Der Clou an der ganzen Sache: der Code beinhaltet sogut wie KEINE Arrays? Warum werden sich wohl einige fragen? Richtig! (Zitat Ausbilder) „Nee so Arrays sind nicht so mein Fall, ich hab die mal verwendet, da ging das nicht so gut und seitdem mag ich die nicht mehr“… Alles klar, somit gibt es Konfigurationsvariablen auch nur mit in folgenden Stil (auch sehr fein übrigens): $configkdkanneditieren = 1; oder $configkdadminbereichokay = 1;
Zum Thema Objektorientierung: (Zitat Ausbilder) „Naja, das ist ja fast das gleiche wie Arrays, ich habe mal gelesen, dass man so MySQL Werte aus der Datenbank holen kann…“ – Gemeint hat er mysql_fetch_assoc und mysql_fetch_object z.B.
Achja, man darf übrigens auch nicht bei verschiedenen Projekten irgendwelche Dateistrukturen ändern: da heißen die Configs immer gleich, der Aufbau bleibt gleich, der Inhalt meist auch (dann findet man in einem CMS Konfigurationen aus einer Webshop) und so weiter: Begründung diesmal: „Ja dann brauch ich da nur die Zugangsdaten mit Copy & Paste reinkopieren, das geht ganz schnell und viel easier!“.
Ich habe das mal gemacht, also die Struktur geändert: da durfte ich mir eine halbe Stunde lang was anhören vonwegen: „Jaaa, miimimi, das geht so nicht, ich muss das auch verstehen.“ (Dazu muss man sagen: ich habe ein Array für die Configs gemacht, also $CONFIG[„Key“] = „Wert“;)
Das sind nur einige der Schoten, die ich hier berichten kann, da gibt es noch unzählige mehr.
Nun verrate mir doch bitte mal einer, wie ich diese Art des Entwicklers nennen kann? Entwickler 0.0.0.0.1 ALPHA?
Oh man, und sowas nennt sich Ausbild(er/ung)!
Grüße und viel Spaß beim Lesen!
Ach ja, wie die Faust aufs Auge…
Ich habe mich selbst vom 1.0er zum 2.0er entwickelt, bei anderen hat diese Entwicklung leider nicht stattgefunden. Inzwischen versuche ich durch intensive Überzeugungsarbeit meine Kollegen zum 2.0-Typen zu wandeln, allerdings in ganz kleinen Schritten… also eher 1.1, 1.2,… 🙂
Mir würde es teils schon reichen, wenn Schlechtes nicht noch schlechter gemacht würde. Ich gebe die Hoffnung nicht auf.
Adrenalin-Junkies und Formular-Zombies Kap 69. Letzter und vorletzter Satz.
Es kann nicht immer des beste Weg sein, aber manchmal der schlicht bessere.
Ich bin selber einer der Entwickler, die versuchen auf dem Höhe der Technik zu bleiben und sich stetig fortzuentwickeln. Jedoch stoße ich natürlich auch auf Kollegen, die schon etwas länger diese Tätigkeiten ausführen und diese gerne wie bisher ausführen möchten. Was mir dabei auffällt ist, dass diese auch oft Fehler in neuen Vorgehensweisen aufzeigen, die mir vielleicht entgangen wären und die sich tatsächlich nicht perfekt migrieren lassen. Insofern sind das für mich die 1.5er Leute, da sie den Blick für das moderne haben, jedoch sich die Vorteile aus dem „vergangenen“ rauspicken.
Ich kann dem unbekannten Nils L. insgesamt zustimmen. Ich selber arbeite oft in größeren Teams an Projekten, wo sich immer wieder solche Strukturen zeigen. Innerhalb dieser Teams ist auch das Einkommensgefälle enorm, und entlang dieser Linie kommen oft auch starke konzeptionelle „Meinungsverschiedenheiten“ an die Oberfläche.
Da gibt’s im Bereich der Portalentwicklung technische Consultants, die kosten am Tag das, was der fest angestellte Programmierer monatlich kriegt. „Recht“ hat in diesen Projekten fast immer der teurere, der hat wiederum oft jahrelange Erfahrung und macht gewisse Dinge eben schon immer so. (Aber ich will nicht ungerecht sein, es gibt viele innovative, geradezu geniale teure Consultants, vor denen: Hut ab!)
Gut finde ich, dass diese Projekte irgendwann vorbei sind, neue anfangen, und ich für meinen Teil nicht fest sitze und einen auf „nett“ machen muss, weil ich in den Strukturen viele weitere Jahre überleben muss.
Die ganz schlimmen Fälle tragen bei mir intern übrigens das Kürzel WOB – „World Of Bullshit“ 🙂
Oh ja .. kennt wohl jeder von uns. Den Lacher hatte ich Letztens als es um ein Portal der größeren Art ging (Anbindung an mehrere externe Datenbanken/Services usw), und der liebe Kollege schlägt vor, das Ganze auf Contenido bzw. PostNuke umzusetzen .. „weil es da ja schon eine Userverwaltung gibt“.
Naja gut … kann man machen .. 🙂
Ich persönlich bin wohl der Entwickler 1.6.7.9… Entwickel sehr gerne in OOP etc. Aber gerade was TDD und Co angeht, das vergesse ich denn mal ganz gerne und kleinere Geschichten, da würde ich nie auch nur eine einzige Klasse bauen, weil overheaded… wenn das Projekt denn mal aus welchen Gründen auch immer größer wird, tja denn werd ich wohl zum Refactoring Monster… 😀
(Offtopic) A propos Karlsruhe: es wurde zwar schon einmal geklärt wer „von uns“ auf der PHP Conference in KA sein wird, aber noch nicht, ob das Interesse besteht, dass man sich mal vor Ort trifft. Was meint ihr?
Ich kenne natürlich auch solche Konstellationen und ich kenne sie sowohl aus der 1.0 als auch 2.0 Perspektive. Ich will damit sagen es geht in solchen Fortschritt-Diskussionen in Teams nicht nur um Technik sondern um die Verschiebung von Einfluss und „Macht“. Ein Technologie- oder Paradigmen-Wechsel macht den mühsam erworbenen Senior-Entwickler-Titel wieder zum Junior. Gegen diese Degradierung wehren sich manche alte Hasen. Diese Verlustängste aufzufangen und einen konstruktiven Ausweg zu finden ist Führungsaufgabe (die leider zu oft liegen bleibt).
@13 Naja aber manchmal muss man auch mal den Entwickler – Entwickler sein lassen – ich kenne „Debatten“ (ähnlich wie im Bundestag), wo tagelang über irgendwelche (OOP-)Patterns diskutiert wurde. Das Ende vom Lied war oder ist oft, dass der Kunde sich einfach für jemanden entscheidet, der schneller und effizienter zu sichtbaren Resultaten kommt. Dem Kunden ist es nämlich meist scheißegal, wie das Teil gebaut wurde, die hauptsache es wird in geplanten Zeitraum gebaut. Und da sich in vielen Firmen einfach bestimmte Dinge eingebürgert haben, werden oft auch „neue“ Sache einfach nicht berücksichtigt… Das hat denn weniger was mit Macht zu tun, als mit Zeitdruck, bei vielen Projekten…
@14: Aus der Seele gesprochen. Die oberste Prämisse sollte lauten Wartbarkeit und Lesbarkeit für Dritte. Beides MUSS im Team abgestimmt sein. Da ist es egal ob OOP oder Prozedural programmiert wird. der Einsatz der Technik muss zielgerichtet gewählt werden können, was die meisten Entwickler über Erfahrung lernen müssen. Kein Kunde akzeptiert horrende Angebote für eine Erweiterung oder ewig dauernde Bug Fixes nur weil der Code unwartbar ist. Wer aus der Reihe tanzt fliegt (bei uns), aus Kostengründen. Ein weiterer Typ Entwickler fehlt hier noch. Da gibt es so Neunmalkluge mit 0 Erfahrung in Enterprise Projekten oder Team Entwicklungen, die meinen sie würden für die komplexeste Lösung gelobt, permanent mit Kanonen auf Spatzen schiessen aber keinen blassen Schimmer von dem haben, was sinnvoll, angemessen und teamkompatibel ist.
Ihr vergesst die Entwickler, deren Chef ihnen keine andere Möglichkeit lässt, sich weiterzubilden, neu zu strukturieren und veraltete Arbeitsabläufe zu entsorgen.
Wenn man täglich nichts anderes tut und zu nix anderem kommt, als das übliche Einerlei an Support, Codefixes und kleinen Erweiterungen am alten Code, ist es oft nicht so einfach, sich weiter zu entwickeln.
Naja, anzumerken ist dass ein 2.0er in der Lage ist neue Technologien kritisch zu bewerten und nicht einfach jede Technologie mitmacht. Ich frage mich zur Zeit warum es in PHP möglich ist anonyme Funktionen (Lambda-Funktionen) zu erzeugen. Einzige Sinnvolle Verwendung, meiner Meinung nach, ist wenn der Code-Bock NICHT wiederverwendet werden soll. Die einzige Situation die mir dazu einfällt ist, wenn ich eine Callback-Funktion z.B. bei den Sortier-Funktionen von PHP direkt in dem Aufruf der Sortier-Funktion definiere. Aber dafür dieses Feature „Lambda-Funktionen“ in PHP einführen? M.E. eher nicht. Und wenn ich etwas wiederverwenden möchte habe ich doch genügend Möglichkeiten: prozedual in Funktionen oder OO in Klassen (z.B. auch statisch). Folgenden Code würde ich in jedem Coding Standard als „no-go“ definieren: „$lamdaFunction($param1, $param2)“ – dieser Zwitter aus Variable und Funktion ließt sich einfach schlecht. Das bringt doch keinen Mehrwert. Und schreibfaule Code-Golfer sollten nicht der Grund für die Einführung von anonymen Funktionen sein. Über weitere Meinungen würde ich mich freuen. Vielleicht kann mich ja jemand „erleuchten“.
Ich wollte den Kommentar von Balu vom 13.11.2009 (11:37) aufgreifen, da ich solchen Zuständen bereits zum Opfer gefallen bin.
Im Team hatten wir damals beschlossen ein großes Projekt in sehr kurzem Zeitraum zu realisieren. Jeder kennt diese Situation: mind. 30 Klassen sind zu schreiben und Schnittstellen, wie schlimmer nicht geht :). Also gibt es zwei Monate lang keinen frühen Feierabend ohne Überstunden… und an eine ausführliche Planung ist momentan überhaupt nicht zu denken ;]]]
Im Team: drei 1.0 und drei 2.0 Entwickler. Schon beim ersten Meeting wurden Barrieren geschaffen, welche leider noch zum Ende des Projektes existierten. Naja… im Projekt selbst wurden einige Sachen vereinbart, welche beide Seiten zufrieden stellen sollten. Quasi ein paar Guidelines of Coding, sowie bestimmte Grenzen und sonstige Absprachen vorab, um gemeinsam in eine Richtung zu schwimmen :))) … eigentlich ein guter Weg.
Mein Fazit: das Verständnis, die Selbstverständlichkeit und Interpretation von Dokumentationen zwischen 1.0 und 2.0 Entwicklern gehen soweit auseinander, dass zum Ende d.h. beim Zusammensetzen verschiedener Meilensteine … theoretisch eigentlich zwei unterschiedliche Architekturen entstanden sind. Auf der einen Seite die neusten Features / Konzepte und auf der anderen Seite ganz einfaches, aber dennoch gutes Coding.
Mir persönlich ist aufgefallen, dass viele Entwickler inzwischen.. wie soll man es sagen.. eine Art „Angstgefühl“ vor einem unglaublich schnell wachsendem Pool an Softskills entwickelt haben. Man könnte es auch als ängstliche Herangehensweise an neueste Features beschreiben, denn wie soll man mit wenig Zeit da noch einsteigen können?!
Ein Angestellter mit Kindern und einem fest ausgebuchtem Abendprogramm kann leider nicht z.B. 2 Stunden am Tag an einem lokalen Client neuste Erfahrungen und Standards von SOA oder einem/r Model Driven Development / Architecture testen.
Ich gehörte eher zum 2.0 Entwickler… da ich neue Informationen und Softskills am liebsten direkt als CD in mein Hirn legen würde 😉 Aber die andere Seite darf nicht übersehen werden, da man am Ende feiert man als Team den Erfolg!!!
Unsere Lösung: am Freitag nur 4 Stunden arbeiten… und 4 Stunden testen / entwickeln wir eigene private Applikationen im Team. Dies geht natürlich nur mit einem entsprechendem Arbeitgeber und 1.0 Entwicklern die man zumindest etwas motivieren kann.
Gruß,
Luke