Kategorien
Der gute PHP-Entwickler
Ab und zu bekomme ich „Leserbriefe“ oder werde von Lesern irgendwas gefragt. Wenn ich es nicht vergesse oder zu sehr im Stress bin, antworte ich sogar drauf. Nein im Ernst, vielen Dank für eure Mails, ich freue mich jedes Mal. Manchmal kommen aber auch E-Mail, die ich nicht einfach so still und leise untergehen lassen will. So kam zum Beispiel letzte Woche von Alexander eine Anfrage. Er wollte wissen, was einen guten PHP-Entwickler ausmacht. Finde ich eine relativ schwere Frage, aber ich wollte das hier im großen Diskutieren, weil ich glaube dass da wirklich Gesprächsstoff existiert. Dieser Artikel ist also eigentlich für Alex, aber ihr dürft trotzdem mitreden.
Ich versuche mich jetzt einfach mal mit einer Auszählung mit wichtigen Eigenschaften, dabei zähle ich Punkte auf, auf die ich Wert legen würde, wenn sich bei uns im Team jemand vorstellen würde:
- PHP-Kenntnisse: Ok, das ist einfach. PHP sollte er beherrschen. Ist aber wirklich nur einer von vielen Punkten, den ich gar nicht unbedingt als wichtigsten erachten würde. Ok für einen guten PHP-Entwickler schon, aber ein guter Softwareentwickler wäre mir genau so lieb.
- OOP-Verständnis: Die Konzepte der objektorientierten Programmierung sollten klar sein. Das bedeutet aber auch, dass man sich andere Programmiersprache wie Java oder C# mal angesehen hat und weiß, wie man dort Probleme löst. Das bringt mich auch gleich zum nächsten Punkt:
- (Web-)Technologien: Jedes Jahr gibt es ganz klare Hypes, von denen man zumindest gehört haben und grob verstehen sollte, was eigentlich dahinter steckt. Zur Zeit sind dies Sachen wie node.js, NoSQL, MemCache bzw. redis, Message Queues, Gateway Cache um nur ein paar zu nennen. Lest also Blogs und Zeitschriften.
- Angrenzende Technologien: Es gibt Dinge die einfach zusammengehören. Das sind zum einen Bud Spencer und Terence Hill, aber auch PHP und JavaScript, SQL, HTML und CSS. Bei mir ist es so, dass ich in all diesen Dingen nicht der beste bin, aber ich immer alles hinbekomme und ich auch weiß, wen ich bei was zu fragen habe.
Das waren so die Hard-Skill, die mir wichtig sind. Aber eigentlich sind mir die Softskills wichtiger.
- Offenheit: Versteift euch nicht auf PHP, da draußen gibt es so viele andere tollen Sprachen und Systeme von denen wir alle lernen können. Und bitte keine Angst haben Dinge wie ant oder maven mal zu testen, nur weil sie eigentlich aus einer anderen Welt kommen. In unserem Team ist es zum Beispiel so, dass man einmal am Tag eine Mail von einem Kollegen bekommt mit einem Blog-Post oder ähnlichem, den man sich doch mal durchlesen soll, weil’s interessant ist.
- Gelassenheit: Ich liebe es mit Personen zu arbeiten, die kompetent sind und sich nicht aus der Ruhe bringen lassen. Ich habe früher mal mit so jemanden zusammengearbeitet und schwärme heute immer noch davon. In hitzigen Diskussionen sachlich bleiben und nicht in Stress geraten ist für mich ein wunderbarer Soft-Skill. Da muss ich aber auch noch dran arbeiten.
- Gut-Genug-Erkenner: Keine Ahnung wie man das in einen Begriff fassen kann, es ist aber für einen guten Entwickler wichtig zu wissen, wann ein Produkt oder eine Klasse gut genug ist. Eigentlich bringt die Erfahrung das mit sich, ich kenne aber noch genügend Leute, die sich auch nach 10 Jahren Webentwicklung noch jedes mal scheuen etwas zu finalisieren, weil ja noch Feature A oder B fehlen könnten. Schließt Dinge ab! Dies gilt auch im besonderen für Performance-Liebhaber, aber da haben wir ja im letzten Artikel schon drüber geredet.
- Motivation: Pädagogisch wahrscheinlich ein Reinfall, aber als letztes der mir am wichtigste Punkte. Motivation. Ihr habt von all dem, was ich vorher aufgezählt habe keine Ahnung, liebt aber das Internet und die Webentwicklung? Ich würde euch einstellen, denn wenn man das liebt was man macht, wird man irgendwann zum guten Entwickler. Wichtig dabei ist aber, dass ich euch jemanden sucht, von dem ihr lernen könnt. Mr. Miyagi und Daniel Son wären hier vielleicht ein Beispiel. Ja ich weiß, ich bin alt.
So das waren jetzt erst mal die Punkte, die mir so spontan eingefallen sind. Ich hoffe Alexander (und die 2000 anderen Leser) sind glücklich und schreiben in den Kommentaren, was sie noch für wichtig erachten.
Danke für die Zusammenfassung. Was mir noch fehlt ist so etwas wie Zumutbarkeit. Denn nicht jeden (noch so genialen) Programmierer kann man zu einem Kunden mitnehmen. 🙂
@Michael: Ich finde Entwickler haben beim Kunden relativ wenig verloren, außer der Kunde ist groß genug, dass er sich mit der IT-Abteilung des Kunden besprechen soll.
Ich muss Michael da eigentlich zustimmen. Zumutbarkeit. Es geht ja nicht nur um externe Kunden. So kann gerade bei einem Portal auch das Portal-Management als „Kunde“ gesehen werden. Gerade Skills, die dann in Richtung der Kundenkommunikation gehen muss man dann besitzen. Dazu gehört nicht nur Zumutbarkeit, sondern auch, dass man sich einfach ausdrücken kann, das man überzeugen kann. Selbstbewusst muss man sein und hinter dem stehen was man da erzählt. Man kann eigentlich sehen worauf das hinaus läuft. Nicht nur gegegnüber einem „Kunden“ braucht man solche Eigenschaften, sondern auch gegenüber der Kollegen. Wer will denn mit jemandem arbeiten, der etwas vorbringt und dann sofort einknickt und einem zustimmt, wenn man anfängt Kritik zu üben?
Man kann es also so zusammenfassen: Zumutbarkeit, Selbstbewusstsein, Eloquent
Schöne Beschreibung. Ein Skill fehlt mir noch auf der Liste, der meines Erachtens sehr wichtig ist: Teamfähigkeit Die Zusammenarbeit mit anderen Entwicklern aber auch mit fachfremden Kollegen, etwa Screendesignern, ist wichtig.
@Manuel Grundner: Je nach Größe des Unternehmens, ist der Entwickler auch Projektleiter und damit Ansprechpartner für den Kunden.
@Oliver: Da hast du vollkommen recht, nur wenn man einen Entwickler zum Kunden „mitnehmen“ will, hat man vermutlich schon eine Größe erreicht wo das eher nicht mehr der Fall ist. Entwickler „vergeuden“ die meiste Zeit bei solchen Besprechungen (in denen sie schon wieder sehr viel guten Code schreiben könnten).
@Manuel: Da sagt aber Scrum und Extreme Programming was anderes, da arbeitet man direkt mit dem Kunden aka Product Owner zusammen. Ich finde es auch sehr wichtig, dass ein Entwickler „kundenkompatibel“ ist.
@Manuel: ich finde gerade das man als Entwickler direkten Kundenkontakt haben sollte, um den Kunden ansatzweise zu verstehen und die eigene Software nicht völlig blind an den Bedürfnissen des Kunden vorbei zu entwickeln.
Und um dem Kunden zu vermitteln was die Software leistet und wie dies geschieht.
Das bringt mich dann auch zu einer, meiner Meinung nach, sehr wichtigen Fähigkeit.
Wissensvermittlung: Ein Entwickler muss in meinen Augen fähig sein komplexe Sachverhalte im Gespräch verständlich zu machen.
Was bringt mir ein Entwickler im Team der erstklassigen Code produziert, die besten Designkonzepte entwickelt, aber im Endeffekt alles alleine macht weil er seine Ideen dem restlichen Team nicht verständlich machen kann?
Üben kann man das sehr gut beim Kunden vor Ort.
Ich finde es auch gut, wenn man sich mal mit Frameworks, Bibliotheken und vielleicht ein paar Open Source Projekten der Sprache beschäftigt hat -> Man lernt spannende Konzepte und ist tiefer in der Sache drin.
Was ich in diesem Zusammenhang immer interessant finde – wie ist denn die allgemeine Meinung wann man PHP „beherrscht“? Wenn man die PHP-Funktionen aus dem FF kennt und ggf. mal noch die Parameterreihenfolge nachschlagen muss (bzw. die IDE das machen lässt), oder wenn man (ungefähr) weiß was es gibt und dann im entsprechenden Teil der Funktionsreferenz nachschlägt?
Ich finde auch das der Entwickler zum Kunden sollte, weil der Programmierer muss das Produkt des Kunden verstehen und für der Umsetzung des Produktes in die Computerwelt muss man manchmal fragen stellen auf die der Contacter nie kommen würde.
@Alberto & @Thorsten
Leider sind die agilen Ansätze der Softwareentwicklung noch nicht bei allen Kunden angekommen. Prinzipiell ist es das Wichtigste, dass der Entwickler den Kunden und seine Geschäftsprozesse versteht. Aber Entwickler müssen nicht immer Productowner oder Productmanager sein.
Konkrete Anforderungen sind wichtigste für den Entwickler, so Gott will kommen die auch gerne direkt vom Kunden.
Ich kenne leider auch solche Besprechungen wo der Kunde noch nicht mal weiß was er will, oder wie sein Prozess auszusehen hat. Bei solchen Besprechungen sollte der Entwickler lieber zuhause bleiben.
Teamfähigkeit hängt insgesammt nicht vom Kunden ab, sondern vom Entwickler und dem Team ansich. Ist meineserachtens neben Motivation und Purpose die wichtigste aller Eigenschaften.
Ps.: Manchmal spiele ich gerne advocatus diaboli 🙂
Ich finde das grade in Agenturen Entwickler unbedingt mit sollten zum Endkunden, sonst kommt der Vertriebler wieder mit hanebüchenden Ideen, die er dem Kunden zugesagt hat (ohne das Budget zu erhöhen), ohne zu überlegen das dieses Feature eventuell einen Faktor X an Mehrarbeit bedeutet und das damit die Deathline nicht mehr zu halten ist.
@Martin: Da gebe ich dir absolut recht. Ich arbeite in einer Werbeagentur und mein Kollege und ich schlagen doch teilweise die Hände über dem Kopf zusammen, was da dem Kunden versprochen wird. Meistens sind die Ideen dann auch irgendwie umzusetzen, aber frag nicht wie. 😉
@Nils
Danke, dass du dir die Zeit genommen hast, diesen Artikel zu verfassen und auf diesem Weg noch mehr Meinungen zum Thema einfließen lassen.
Die hier aufgezählten Skills sind informativ, was mir aber noch fehlt, ist die Richtung von @chp.
Sachen wie Test-Driven-Development oder SCMs, mich interessiert auch mehr Praxisbezug. Für viele sind bestimmte Dinge schon offensichtlich und werden evtl. gar nicht erwähnt, deswegen würde es mich sehr interessieren wie so der Alltag eines Entwicklers aussieht.
Welches wissen setzt Ihr täglich ein, z. B. ihr seid froh das ihr Ahnung von SCMs habt oder von Design-Patterns. Natürlich wäre es cool zu hören Sachen wie, ich bin froh, dass ich studiert habe, dadurch kann ich dies oder das.
Ich hoffe man kann verstehen, was mich interessiert 🙂
Also ich finde es wichtig, dass die Person in das Team passt. Gerade in kleineren Teams ist es extrem von Vorteil, wenn sich das Team untereinander versteht, da so die Kommunikation innerhalb des Teamworks meines Erachtens besser ist.
Klar ist auch, dass die Person diverse HardSkills hat:
– Grundsätzliches Verständnis der Sprache / Paradigmen
– Erfahrung mit Versionierung
– Security Issues
– Performance im Auge haben
– Lust auf neues -> persönliche Weiterentwicklung und Lust auf neue Tools und Technologien
Bezüglich Kundenkontakt:
Wenn man nur im Büro sitzt und nach einem Plan enwickelt, den ein anderer macht (Stichwort Scrum-Master), braucht man nicht wirklich zum Kunden.
Wenn man aber den Kundenkreis anders definiert und Feature-Wünsche aus dem Unternehmen kommen, sollte man den BWLer verstehen und der BWLer sollte den Entwickler verstehen.
@manuel
entwickler die nicht kundenkompatibel sind haben schon im letzten jahrtausend ihre daseinsberechtigung verloren.
ich glaube bei uns im keller sitzt noch so einer rum und arbeitet jetzt mit der schaufel und kohlen an der heizanlage.
Vorzeigbarkeit? Ich bitte Euch, das ist doch oberflächlich! Es gibt genug Schlipsträger da draußen und Fachleute werden für Ihren Sachverstand bezahlt, nicht für Ihre Modelqualitäten oder dafür, dass ihnen der Anzug so gut passt und sie so eloquente Redner sind!
„Entwickler mit zum Kunden“ erscheint mir außer für Einzelkämpfer oder Klein(st)agenturen der komplett falsche Ansatz. Vielmehr muss der Vertriebler/„Unterhändler“ genug Sachverstand und Erfahrung haben, um Themen einschätzen zu können, im Idealfall vielleicht Projektleiter oder ehemaliger Programmierer sein UND Entscheidungsbefugnisse besitzen.
Dass sich ein Entwickler mit dem Anwender auseinandersetzt ist ein schöner Traum, aber letztlich
– Hat er ohnehin keine Entscheidungsbefugnis, genauso wenig wie die Anwender in der beauftragenden Firma – das entläuft die Verantwortungshierarchien
– Hat er keinen Überblick über Kosten und Kalkulation – Featureversprechen sind hier genauso gefährlich
– Hat er evtl. keinen Überblick über das gesamte Projekt
– Unterlaufen „private“ Absprachen auf Anforderungsebene das gesamte Projektmanagement – Zeit-, Ressourcenplanung, Zeitpuffer
– Ist das Lastenheft Aufgabe des Auftraggebers
Was der Vertriebler alles verspricht, ist ein Thema für die Diskussion „was ist ein guter Vertriebler“ 😉
@nikosch
wie oft erleben wir das „Vertriebler“ dem Kunden das blauen vom Himmel versprechen, und wer darf es ausbaden? Richtig der Entwickler, ich für
meinen Teil hab schon vor langer Zeit festgestellt das es besser ist die Herren und Damen nicht zu lange alleine zu lassen. Da gehen die Pferde mit denen durch. Sachverstand ist bei denen meistens Mangelware.
Aber was macht den guten Entwickler aus?
ganz einfach, Freude am knobeln 😉
@Martin: „Freunde am knobeln“ – WORD! 🙂
A propos letzter Artikel – hab ich da was falsches geschrieben, dass er nicht freigeschaltet wurde?
Das Wichtigste fehlt mir auch noch, woran auch die meisten scheitern. Das sog. „McGyver Gen“. Mit einfachen Mitteln komplexe Probleme lösen, Konzepte kombinieren können und wissen, wie man neue Informationen findet, wenn man etwas nicht weiß … oder halt „Freude am Knobeln“. 🙂
@Oliver: Nein lösche keine Kommentare. Aber vielleicht ist er in den Spamfilter geraten, das passiert leider immer mal wieder. Bist du so nett und schreibst ihn noch mal?
Ist auch egal, aber gespeichert war er auf jeden Fall, weil noch mal absenden ging nicht.
@nikosch
Ich gebe dir in allen Punkten vollkommen recht. Manchmal ist eine Entscheidung des Vertrieblers/Chef’s auch mit Kompromissen oder Zukunftsaussichten (verlust) verbunden. Dafür kriegt man wenigstens eine Fuß in die Tür.
Das dass für die Entwickler natürlich oft in einer Timing-technischen Katastrophe endet finde ich in Ordnung, dafür pfuscht er mir nicht in meine Architektur.
Für Weise Entwickler gehört der Vertrieb genauso zum Team, und weiß lange genug vorher wie weit die Grenzen des Kunden sind. Bauchgefühl und Fachwissen sollte der Programmierer schon haben.
In der Webentwicklung ist das ganze etwas schwieriger, weil man sehr viele Kunden bedient. Ich entwickle Backoffice-Software für 2 große Kunden die sehr ähnliche Anforderungen haben. Bei uns hat sich ein Mittelsmann sehr gut bewährt, und der Entwickler (also ich) telefoniert und sieht den Kunden nur in Ausnahmesituationen.
@miasin
Das kommt drauf an wie der Kunde seine Software entwickelt haben will. Wie ich oben bereits gesagt habe akzeptieren nicht alle Kunden (oder sehr viele) einen Scrum oder XP Ansatz. Dann muss man halt nach einer Art Wasserfall-modell entwickeln, weil man Pflichtenhefte nahezu stupide durchackert. Entwickler beim Kunden sind da meist fehl am Platz. Die wollen Ihr Produkt genau wie es im Pflichtenheft steht, und nicht anders.
btw. Wir entwickeln „auch“ Software für Behörden. Vielleicht wird mein Standpunkt dann klarer.
@nikosch
Den Vertriebler den du beschreibst gibt es nicht. Wenn es ein guter (Ex-)Techie ist, dann entfernt er sich in den Jahren immer weiter davon, weil sich ja auch die Technik weiterentwickelt. Es gibt keine Generalisten sondern nur noch Spezialisten.
Klaren Kommunikation sowohl nach innen (technisch eindeutig, keine Begriffe vermischen) als nach außen (Kunde, PM, PO bzw. SM also die Technik beschreiben so dass man sie versteht) erachte ich als sehr wichtig. „Vorzeigbarkeit“ gehört auch dazu, denn ich möchte eben nicht immer zwingend den Mittelsmann haben wollen, weil ich den Techie nicht auf Externe loslassen kann.
@Alex: Ich mache noch einen Artikel mit meinem „Werkzeugkasten“ und vielleicht noch einen mit Entwicklungsmethoden, die man sich anschauen sollte. Ich hoffe, dass ich dann das Thema abgeschlossen hab 😉
Dann mal Butter bei die Fische: Wo find ich so jemanden und bekommen im Rabatt bei größeren Abnahmemengen? 😀
@Stephan: Wenn du jemanden suchst, der den ganzen Tag gute Ideen hat und forscht und du ihm einen Sack voll Geld geben willst, dann meld‘ dich 😉
@Nils: Ich würde mich nur freuen über weitere Artikel zu diesem Thema 😉
@oftopic
Auf der letzten PHPUNCONFERCE in Hamburg gab es auch einen Speak zum Thema
„Verstehe deinen Projektmanager“ 😉
http://wiki.php-unconference.de/index.php/PhpUnconf2010SaturdaySessionA2
Manuel Grundner hat es eigentlich am besten formuliert. Bei kleinen Klitschen mag es Sinn machen den einen Entwickler mit zum Kunden zu nehmen, … sprich, man kann das nicht pauschalisieren.
Bei Firma A macht es Sinn; bei Firma B nicht.
Aber back2topic:
„Zur Zeit sind dies Sachen wie node.js, NoSQL, MemCache bzw. redis, Message Queues, Gateway Cache um nur ein paar zu nennen.“
Damit kann man dich beeindrucken? 🙂 „node.js“ ist natuerlich „neu“ und auch „gehyped“, aber ein guter Programmierer kann auch ohne „node.js“ gut sein. Wenn man es faktisch betrachtet verpasst er ohne node.js so gut wie nichts, da node.js tatsaechlich nur ein Hype ist und es seit Jahren Loesungen fuer ein Problem gibt, was fuer die meisten keins ist.
Und wieso stellst du memcached in Relation zu redis? Redis ist einfach nur ein schneller keyvalue Store und memcached was ganz anderes und memcached ist auch alles, nur nicht neu und auch kein Hype. Memcached ist etablierte Software.
Aber gut…wenn ein guter PHP Programmierer in der Lage sein muss irgendwelche zufaelligen Buzzwords rauszublubbern, dann hat man es ja leicht. Buzzword Bingo macht ja bekanntlich auch Spass :D.
Ne, mal im Ernst: wenn jemand redis nicht kennt, dann ist das ueberhaupt kein Problem; wichtiger ist es doch, wie schnell sich jemand in ein neues Thema einarbeiten kann. Wenn ich jemandem sage, dass er Daten mit redis speichern soll, dann erwarte ich, dass er die Software innerhalb von Minuten versteht und basierend darauf schnell ein Konzept erstellt, was Sinn macht. Das gleiche trifft eigentlich auch auf memcached und allen anderen Technologien zu.
Also eigentlich ist diese Liste viel zu allgemein, denn diese paar Punkte beschreiben doch hunterttausende von Menschen, die gerade PHP gelernt haben und die sind dann doch alles, nur nicht gut :).
Naja, mir ja egal :).