Welchen Hut sollte ein Programmierer nicht tragen? [geschlossen]

Nach meiner Erfahrung tragen Softwareentwickler häufig mehrere Hüte und üben mehrere Rollen mit unterschiedlichen Verantwortlichkeiten aus. Von der Codierung, manchmal auch dem Schreiben von SQL, dem Entwerfen der Benutzeroberfläche, dem Entwerfen der Datenbank, der Grafikmanipulation bis hin zum Testen der Qualitätssicherung.

Wenn die primäre Rolle darin besteht, Software / Code zu schreiben, welche Rollen sollte der Entwickler dann nicht übernehmen? Sind da irgendwelche?

Die Absicht dieser Frage ist nicht, dass ein Entwickler nicht in der Lage ist, eine andere Rolle zu besetzen, sondern dass die zusätzliche Rolle tatsächlich der primären Rolle entgegenwirkt oder wirklich eine dedizierte Rolle von jemandem sein sollte, der nicht primär programmiert.

Sysadmin. Die Entwicklung von Software und der Umgang mit der IT-Infrastruktur sind zwei unterschiedliche Fähigkeiten, die einem Außenstehenden ähneln. (Alles klopft nur an Computer, oder?) Für ein kleines Unternehmen wird die Versuchung sehr groß sein, The Computer Guy für alle Computer im Büro verantwortlich zu machen.

Wenn Sie die Fähigkeiten haben, beide Hüte tatsächlich zu tragen, ist das großartig. Aber es ist eines dieser Dinge, die viel länger dauern können, als die Leute glauben, und wenn Sie sich dabei selbst beibringen, ist die Wahrscheinlichkeit groß, dass Sie es nicht sehr gut machen.

Sie tragen alles, was Ihr Arbeitgeber verlangt. Das macht dich zu einem Teamplayer. Das macht Sie zu einem Problemlöser .

Die Vorstellung, ein "Entwickler", ein "Architekt" oder ein "Analytiker" zu sein, wird allzu sehr beschäftigt. Scheiß drauf. Sie sollten ein Problemlöser sein. Code ist nur ein Werkzeug in Ihrem Gürtel.

Problemlösung kommt nie aus der Mode.

Wenn mein Arbeitgeber möchte, dass ich technischen Support leiste oder Computer baue, dann sei es so. Sie denken, sie verschwenden ihr Geld, wenn sie ein Entwicklergehalt in Betracht ziehen, aber das ist ihre Sache. Ich bin hier, um Probleme zu lösen. Wie auch immer ich das tun kann, ich werde es tun. Und wenn ich das Gefühl habe, dass meine Talente nach einer gewissen Zeit verschwendet sind oder meine Arbeitszufriedenheit nicht mehr dort ist, wo ich sie haben möchte, dann habe ich nur das Recht, in einen anderen Job zu wechseln.

Aber zur Grundfrage: Es gibt keinen Hut, den Sie nicht tragen. Verdammt, wenn sie wollen, dass du Kaffee holst, tu es. Löse ihre Probleme. Sie müssen nur wissen, dass Sie das Recht haben, einen anderen Job zu finden, wenn Sie eine Änderung wünschen.

Prüfer!

Bitte schicken Sie uns die Tester bei Bedarf direkt aus der Testerschule!

Ohne Tester erwarten die Leute, dass alles auf Anhieb funktioniert, da der Programmierer der Tester ist und sie sehr schlau sind, so dass es funktionieren sollte.

Ich sage nicht, dass Hundefutter keine gute Idee ist. Ich denke nur, dass Tester jetzt, da ich Programmierer bin, sehr wichtig sind.

Sie sollten vorsichtig sein, wenn Sie bei Problemen mit der Office-Hardware an der richtigen Adresse sind . Dies kann PC-Fehlerbehebung, Serveradministration, Backups und sogar die Arbeit des Telefonsystems umfassen. Ich habe den Fehler gemacht, meine vorherigen Hardware-Erfahrungen zu erwähnen, und irgendwann standen meine Hardware- / Fehlerbehebungspflichten in einem schweren Konflikt mit meinen Programmierpflichten.

Ein Programmierer sollte nicht der einzige Tester für seinen eigenen Code sein .

Entwickler schreiben Code mit einer Reihe von Annahmen. Wenn Tester die gleichen Annahmen haben, üben sie die unerwartete Funktionalität außerhalb dieser Grenzen nicht aus, und viele Probleme bleiben unentdeckt.

Um vorwärts zu kommen, sind Entwickler nicht hoch motiviert, Dinge zu brechen, während Tester dies tun (vielleicht auf einer unbewussten Ebene).

Dies bedeutet nicht, dass das Testen von Entwicklern nutzlos ist. Im Gegenteil - mit guten Entwicklertests können sich Tester darauf konzentrieren, tiefere Probleme zu finden. Das Testen von Entwicklern ist jedoch kein Ersatz für einen dedizierten Tester.

Zwei, die mir auf Anhieb einfallen.

1. Technischer Support. Ich bin nicht hier, um Kunden dabei zu helfen, die neue Site zu durcharbeiten oder ihnen die Verwendung von Funktionen beizubringen.
2. Es kann zwar erforderlich sein, an verschiedenen Stellen des Prozesses eine Schnittstelle zu Clients herzustellen, Sie sollten jedoch nicht direkt mit ihnen über Funktionen und Entwurfsimplementierungen kommunizieren, es sei denn, Sie sind Programmierer.

Man könnte sagen, dass die CSS / UI-Entwicklung außerhalb des Programmierbereichs liegt, aber meiner Erfahrung nach ist dies heute eine notwendige Fähigkeit. Sie können nicht einfach mit Tabellen davonkommen und sich darauf verlassen, dass jemand anderes sie korrekt implementiert. Ich mag es vielleicht nicht, Design zu implementieren oder den Code zu ändern, um mit einem neuen Design umzugehen, aber das ist Teil des Jobs.

Das Schreiben von Abfragen ist in Ordnung, Q / A-Tests sind in Ordnung (und IMO sollte die Aufgabe des Programmierers sein, eine externe Abteilung sollte es finden, aber zuerst sollten Sie es testen). Die Serveradministration ist eine Grauzone. Abhängig davon, wie groß das Projekt ist oder ob Sie einen dedizierten Serveradministrator haben, wird dieser möglicherweise nicht benötigt.

Im Allgemeinen habe ich die Erfahrung gemacht, dass die meisten Programmierer das Erscheinungsbild der Benutzeroberfläche nicht entwickeln sollten - obwohl ich mit Sicherheit in der Lage bin, eine Benutzeroberfläche zu entwickeln (und häufig eine zu erstellen, wenn ich einen Prototyp oder einen Proof of Concept erstelle) Überlassen Sie dies besser einem Menschen (der in unserer kleinen Firma ein Grafiker ist, der auch die Bildschirmlayouts erstellt und die meisten Handbücher und Broschüren erstellt).

Außerdem sollten Entwickler keine QA-Tests durchführen - das ist die Aufgabe der QA-Abteilung (das Unternehmen, bei dem ich arbeite, stellt eingebettete medizinische Geräte her, daher ist es erforderlich, dass die Tests von einer separaten Abteilung durchgeführt werden).

Andererseits sehe ich keinen Grund, warum Entwickler keine Datenbanken entwerfen und SQL schreiben können, wenn sie den Hintergrund dazu haben - das habe ich so oft getan.

Technischer Support

So viel von meinem Tag wird verschwendet, wenn ich Anrufe beim technischen Support entgegennehme ...

Einige beliebte sind:

• "Mein Konto ist gesperrt" oder "Ich habe mein Passwort vergessen"
• "Mein [Telefon | Tastatur | Maus | Computer] funktioniert nicht"
• "Mein Computer ist langsam. Können Sie nach ungewöhnlichen Ereignissen suchen?"
• "Warum passiert X, wenn ich auf diese Schaltfläche klicke? Es sollte Y sein."
• "Ich bekomme ständig diese Popups ..." oder "Ich glaube, ich habe einen Virus"
• "Diese Person ist nicht mehr hier, kannst du all ihre Sachen deaktivieren?"
• "Wir haben einen neuen Mitarbeiter. Können Sie ihn mit Login, Sicherheitskarte, Durchwahl, E-Mail usw. einrichten?"

Jede Rolle, die ihn dazu bringt, sich selbst zu verwalten. In kleinen Teams besteht häufig die Tendenz, einen der leitenden Entwickler zum Projektmanager zu machen, ihn aber auch als Programmierer im Team zu halten. Dies führt zu allen möglichen Problemen, da dieser Typ als Programmierer im Grunde nicht verwaltet wird. Anstatt alle Aufgaben an die anderen Teammitglieder zu delegieren, wird er häufig versucht sein, viele von ihnen sich selbst zuzuweisen, insbesondere die schwierigsten Aufgaben. Die schwierigsten Aufgaben, diejenigen, die am wahrscheinlichsten Probleme verursachen, werden einer Person zugewiesen, die nur zu 50% als Programmierer verfügbar ist und als solche niemandem Bericht erstattet. Wenn andere Teammitglieder nicht in der Lage sind zu liefern, anstatt ihnen in den Arsch zu treten, wird er versuchen, ihre Aufgaben zu erledigen, denn als Projektmanager ist er für den Erfolg verantwortlich und der sicherste Weg, dies zu erreichen, besteht darin, es selbst zu tun nicht wahr

Technischer Support für Dinge, die Sie nicht selbst entwickelt, bereitgestellt oder gewartet haben, für die Sie keine Schulung erhalten haben und die nicht über wichtige Änderungen auf dem Laufenden gehalten werden. Ein Teil meiner Arbeit besteht darin, Kunden anzurufen, die wissen, warum ihr Internet nicht funktioniert. Ich kümmere mich nicht um diese Hälfte des Geschäfts, also kann ich ihnen nichts von Nutzen erzählen.

Es muss kein technischer Support geleistet werden, mit dem es kein Problem gibt. Es ist ein Sekretär / Techniker, der versucht, Dinge zu entwickeln.

Es wird ziemlich anstrengend, wenn man den ganzen Tag auf Leute hört, die sich beschweren und ihnen nichts sagen können. Ich würde raten, dies um jeden Preis zu vermeiden.

Vertrieb .

Einige arme Kerle müssen es tun, aber es sollten sicher nicht die Entwickler sein.

Als ich älter geworden bin, habe ich festgestellt, dass dies am besten ist, wenn Entwickler ihre eigenen Bereitstellungen nicht durchführen (ich habe gegen diesen einen Zahn und Nagel gekämpft). Sie sollten keine Rechte an der Produktionsdatenbank haben, außer ausgewählten Rechten. Unser Code wurde viel weniger fehlerbehaftet (und das gleiche Problem trat nicht mehrmals auf, da die Änderung nur in prod vorgenommen wurde und eine spätere Entwicklung es erneut überschrieb und dann nur in Eile auf prod reparierte, spülte und wiederholte), als wir Ich musste damit beginnen, es anderen Leuten zur Bereitstellung zu geben und durfte keine schnellen Produktionsänderungen vornehmen, da die Bereitstellung nicht ganz richtig war. Außerdem haben wir diese versehentlichen "Aktualisierungen ohne die hervorgehobene where-Klausel, die jeden Datensatz in der Tabelle veränderten", eingestellt.

Künstler und User Interface Designer .

Die meisten Programmierer sind in Bezug auf Kunstwerke sehr arm, aber Unternehmen müssen nicht dafür bezahlen, dass ein Künstler Bilder und Symbole für ihre Produkte malt, sondern verwenden einfach "Programmierkunst" - mit abscheulichen Ergebnissen. (Bis Windows Vista war dies der augenscheinlichste Unterscheidungsfaktor zwischen Macs und PCs. Macs sahen wunderschön und freundlich aus, PCs waren ein Dorn im Auge.)

In ähnlicher Weise sind viele Programmierer nicht sehr an der Benutzeroberfläche interessiert - sie kümmern sich hauptsächlich um ihren Code. Sie legen einfach den Inhalt ihrer Mitgliedsvariablen direkt in einigen bearbeitbaren Feldern offen. Dabei spielt es oft keine Rolle, wo sie Schaltflächen und Felder auf ihren Formularen platzieren, und gehen davon aus, dass dies ausreicht, was zu unbrauchbarer Software führt. (Die gesamte Handybranche war daran schuld, bis das iPhone eintraf, um ihnen zu zeigen, dass man tatsächlich eine benutzerfreundliche Handy-Benutzeroberfläche erstellen konnte.)

Lotus Notes ist ein hervorragendes Beispiel dafür, wie schlecht diese beiden Dinge sein können, wenn Sie keinen professionellen Designer beauftragen, den Programmierern zu helfen.

Schreiben von Gesamttests und Testplänen. Im Ernst, Leute, ich kann meine eigenen Testpläne schreiben, aber das bedeutet, dass ich alle Missverständnisse, falschen Annahmen und kognitiven Fehler, die ich beim Schreiben des Stoffes gemacht habe, in das Produkt einbringe. Es war das Einzige, was ich an einer Firma hasste, bei der ich arbeitete. Wo ich jetzt bin, haben wir zumindest Code-Reviews, die dieses Zeug wahrscheinlich auffangen werden.

Tragen Sie niemals mehr "Hüte", als Sie vernünftigerweise handhaben können und mit denen Sie sich gut auskennen, und versuchen Sie, Entwickler von Postfächern zu überzeugen, indem Sie sagen, dass sie weder A noch B tun sollten bedeutet dies, dass ein großartiger UI-Designer möglicherweise unbemerkt bleibt, weil jemand der Meinung ist, dass Programmierer sich davon fernhalten sollten die Benutzeroberfläche.

Am Ende des Tages wird jeder unterschiedliche Stärken und Schwächen haben, und ein guter Manager / Vorgesetzter / Teamleiter sollte wissen, wie er die für ihn arbeitenden Personen am besten anleiten kann, um sicherzustellen, dass die Talente angemessen eingesetzt werden. Wenn Sie mit dem Entwerfen von Benutzeroberflächen oder dem Umgang mit Endbenutzern nicht vertraut sind, teilen Sie dies Ihrem Team mit, damit Sie Ihre Rolle in diesem Bereich minimieren können. Sie sollten jedoch bereit sein, zusätzliche Arbeiten in einem anderen Bereich aufzunehmen.

Wenn Sie zu viele Hüte tragen (z. B. Programmierer, UI-Designer, Tester, Business-Analyst usw.), werden Sie bei einigen von ihnen entweder schlecht abschneiden oder sich selbst verbrennen. Stellen Sie sicher, dass Sie wissen, mit wie vielen Hüten Sie umgehen können, und versuchen Sie, die Arbeitsbelastung auf diesem Niveau zu halten.

Darüber hinaus gibt es wirklich keine "Hüte", die ein Entwickler nicht tragen sollte, wenn er die Fähigkeiten besitzt, sich in dieser Rolle zu übertreffen.

Ich neige dazu, jeden Job anzunehmen, der auf mich geworfen wird, wenn und nur wenn:

• Ich warne im Voraus über mein Können und mögliche Auswirkungen und mein Chef entscheidet, dass es akzeptabel ist
• Es gibt eine Person auf Guru-Ebene, die mir helfen kann (und wird), mit etwas Unerwartetem umzugehen
• Lesen Sie einige Dokumentationen durch, stellen Sie Fragen online usw.

Auf diese Weise bin ich größtenteils gegen meinen Chef versichert und wenn jemand einen Fehler macht, ist dies zumindest reparabel.

Entwickler sind Stakeholder in der Situation (wie Kunden, Eigentümer usw.), sodass sie das Recht haben, einen sinnvollen Job zu erwarten. Das bedeutet meiner Meinung nach die Möglichkeit, mit Ihren Stärken zu arbeiten .

Ein Entwickler sollte also keinen Hut tragen, der keine Energie liefert, zum persönlichen Wachstum beiträgt und zu Höchstleistungen führt - und "Hüten", die diese Dinge für sie erledigen, Zeit stehlen.

Abgesehen davon, dass sie nicht die Einzigen sind, die ihren eigenen Code testen, denke ich, dass jeder "Hut" in Ordnung ist, wenn es für den Entwickler, der den Hut trägt, eine sinnvolle Arbeit ist.

Der "Designer" oder der "Kreative". Sie werden von der unschuldigen Erstellung eines Modells der Benutzeroberfläche einer Anwendung über die Erstellung von Marketingtexten für die nächste Online-Werbekampagne bis hin zu endlosen Diskussionen über den "richtigen" Blauton gehen, bevor Sie ihn kennen x_x.

dieser Hut mit den Bierdosen auf der Seite mit einem Strohhalm. schlechte Idee, wenn Sie erwischt werden.

bearbeiten:

Hier ist der Hut, den ich hasse, aber der hat eine große Belohnung - es ist ein großes Zeichen für mich, dass wenn dieses Ding kaputt geht, alles deine Schuld ist ... ah, aber wenn es gut ist, dann bist du mein Sohn der gute Junge, den wir alle kennen sind - jetzt geh zurück in den Keller ... braver Junge ... das war's.

Der Schuld Hut.