Welchen Hut sollte ein Programmierer nicht tragen? [geschlossen]

29

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.

Schwamm
quelle
20
Eine Haube ... oh warte ..
ChaosPandion
21
Nach meiner Meinung sollte ein Programmierer keinen dieser großen mexikanischen Sombreros tragen, da die Krempe immer wieder gegen den Monitor schlägt.
Mason Wheeler
1
@Peter Turner: Der "großartigste Programmiererhut" wäre einer dieser Neuheitenjobs, der zwei Bierdosen aufnimmt. Nur kein Bier. Red Bull.
BlairHippo
4
Verdammt. So ein vielversprechender Titel ...
Niemand
4
Wenn Sie den Sombrero über dem Monitor halten, werden Reflexionen auf glänzenden Bildschirmen vermieden. Mit anderen Worten - Technik.

Antworten:

54

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.

BlairHippo
quelle
7
DIES. Nur weil ich auf Computern arbeite, kann ich die Infrastruktur nicht reparieren. Sie verschwenden nur die Zeit Ihrer Entwickler.
Jaco Pretorius
5
+1 Der Schaden, den ein Amateursysadmin anrichten kann, ist enorm.
Davidtbernal
Und wenn Sie den Sysadmin-Hut haben, bleiben Sie möglicherweise auch beim Facility-Manager-Hut, der unbedingt vermieden werden muss.
HLGEM
3
OTOH, ich arbeite in einem Unternehmen mit einer unglaublich inkompetenten und trägen IT-Abteilung. Was ich nicht geben würde, um meine eigenen Firewall-Änderungen vornehmen zu können ...
Gabe Moothart
1
Jemand wies darauf hin, dass mein Chef nicht angezogen war, sagte ihnen aber, dass er sich vom Boden schmutzig machen würde, wenn er Computer aufstellte. Sie zeigten auf mich und sagten, ich sollte es tun. Ich wäre fast über ihren Schreibtisch gesprungen und hätte sie erwürgt, aber ich nippte an meinem Kaffee und erwähnte, dass ich keine Hardware mache.
JeffO
35

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.

Chris Holmes
quelle
5
@Josh: Ich denke, das wäre eine dieser Situationen, in denen man einen neuen Job findet.
Adam Lear
21
Sei einfach vorsichtig damit. Chefs neigen dazu, diejenigen auszunutzen, die bereit sind, irgendetwas zu tun. Stellen Sie einfach sicher, dass Sie richtig entschädigt werden.
Tony
5
Ich glaube nicht, dass Chris "irgendetwas tun" sagt (nun, er ist ein bisschen am Ende; ich hole keinen Kaffee für jemanden, der mir nicht auch Getränke holt), aber ich sage: "Ich bin ein Entwickler, ich." Eine Druckerpatrone wird nicht gewechselt.
Peter Boughton
10
Ich stimme dir nicht zu. Es ist einfach zu sagen, dass ein Entwickler in der Lage sein sollte, alles zu tun, was gefragt wird, aber das bedeutet nicht, dass er es tun SOLLTE. In diesen Situationen treten einige erhebliche Interessenkonfliktprobleme auf. Ich möchte keinen Zugang zu Produktionssystemen, weil ich beschuldigt werde, wenn sie ausfallen ("na ja, XXX war letzten Monat da, also bin ich sicher, dass er etwas durcheinander gebracht hat, weil er ein Entwickler ist, kein Administrator")
MBonig
7
-1; Es gibt hier einen Kern der Wahrheit, aber es gibt einige starke Einschränkungen in dieser Denkweise. Diese Antwort reicht nicht aus, um dies anzuerkennen. Was ist, wenn das eigentliche Grundproblem darin besteht, dass Ihr Arbeitgeber das Personalmanagement für sich beansprucht? Ich sah einmal zu, wie ein Büro zusammenbrach, weil die Vorgesetzten darauf bestanden, intelligente, fähige Ingenieure in Rollen zu bringen, die sie hassten und sehr schlecht machten. Es gibt Zeiten, in denen "Nein!" ist das Beste, was Sie für sich und Ihren Arbeitgeber tun können.
BlairHippo
29

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.

Peter Turner
quelle
4
Gute engagierte Tester sind definitiv unterbewertet!
Peter Boughton
3
Hundefutter!? Ich koche nur Fünf-Sterne-Hummer! ... und deshalb brauche ich einen Tester, der mir sagt, wenn ich etwas vermasselt habe. Ich habe das Ding gemacht und weiß, wie es funktioniert. Niemand, der eine Benutzeroberfläche erstellt hat, kann diese gründlich testen, nur weil er weiß, wie sie funktioniert, und nicht, wie sie bei jemandem funktioniert, der dies nicht tut.
Morgan Herlocker
15
Es ist nichts Falsches daran, ein Tester zu sein. Es ist falsch, der einzige Tester für IHREN EIGENEN Code zu sein. Programmierer programmieren unter Berücksichtigung einer Reihe von Annahmen. Wenn der Tester identische Annahmen hat, werden sie keine unerwarteten Teile ausführen und viele Fehler übersehen.
Dbkk
5
Testen Sie Ihren eigenen Code ist definitiv ein großes Nein-Nein. Ein Programmierer kann eine Menge anderer Dinge behandeln, aber ein tatsächlicher Funktionstest (wenn Sie keinen Komponententest durchführen, sind Sie vielleicht sowieso kein Programmierer) Ihres eigenen Codes ist eine sehr schlechte Idee. Hundefutter damit ist gut, Verstand.
Glenatron
3
+1 - Programmierer denken in Bezug auf die Verwendung von Programmen deutlich anders als Nicht-Programmierer. Würden Sie jemals einen Fehler im Menüpunkt "Datei -> Speichern" entdecken?
26

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.

Jon Onstott
quelle
Teilen Sie den Tätern mit, dass sie die Erlaubnis Ihres Chefs benötigen, und registrieren Sie alle dafür verwendeten Zeiten.
@Thor Die Richtung, um an Hardware-Sachen zu arbeiten - kam von meinem Chef. Es war hilfreich für das Büro, aber ich konnte meine Karriere nicht so sehr auf das Programmieren konzentrieren, wie ich es mir zu diesem Zeitpunkt gewünscht hätte.
Jon Onstott
@ Jon, wenn der Chef sagt, dass Sie es tun müssen, dann müssen Sie es tun. Sie können dann mit ihm besprechen, ob dies zufriedenstellend ist oder nicht, und wenn Sie keine Einigung erzielen können, ist es Zeit zu gehen.
+1 Mir ist dasselbe passiert. Sie möchten, dass ich nicht nur Code schreibe, sondern mich auch mit Netzwerkproblemen sowie mit browbeating-Anbietern befasse, was zu viel Stress geführt hat.
Rich
16

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.

dbkk
quelle
10

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.

Josh K
quelle
7
In Bezug auf Punkt 2 gibt es mindestens ein Unternehmen, dessen Grundprinzip darin besteht, dass die Person, die den Code schreibt, direkt mit dem Kunden spricht: Disintermediation hat ihre Vorteile.
Frank Shearar
10

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.

Tcrosley
quelle
2
+1 Einverstanden, dass QA-Tests durch die Entwickler, die es geschrieben haben, den Zweck zunichte machen.
Spong
2
@JoshK Einige QA-Tests können von den Entwicklern durchgeführt werden, die wichtigsten QA-Tests sollten jedoch von anderen durchgeführt werden. Wenn Sie Ihre eigene App testen, die Sie geschrieben haben, können Sie potenzielle Probleme unbewusst umgehen. Der Punkt ist, Probleme zu entdecken, die die Entwickler nicht finden können, quasi wie frische Augen.
Spong
2
@JoshK @ChaosPandion Einverstanden, einige vorherige Tests durch Entwickler sollten durchgeführt werden - aber es sollte nicht vertrauenswürdig sein. Daher sollten QS-Tests von denen getrennt werden, die sie nicht entwickelt haben.
Spong
5
-1: Ich bin nicht einverstanden, dass Programmierer die GUI nicht entwerfen sollten. Ich habe 8 Jahre in einer kleinen Firma gearbeitet und die gesamte Benutzeroberfläche entworfen. Ich habe mich immer an die hervorragenden Designrichtlinien von Microsoft gehalten und ein paar HMI-Designbücher gelesen. Wir haben nur Grafiken an externe Illustratoren ausgelagert.
Wizard79
3
Eine Sache, die mich hier stört, ist die Folgerung, dass ein Grafiker für das Entwerfen von Benutzeroberflächen besser geeignet ist als ein Programmierer. Es mag sein, dass Ihr Grafiker sehr gut im Entwerfen von Schnittstellen ist, aber im Allgemeinen kann es zu einer verwirrenden, unbrauchbaren, hübschen Schnittstelle ausarten, im Gegensatz zu der verwirrenden, kaum benutzbaren, hässlichen Schnittstelle, die Sie vom stereotypen Programmierer erhalten würden.
David Thornley
8

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?"
Rachel
quelle
6

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

user281377
quelle
5

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.

Tarka
quelle
Ja, es ist anstrengend, mehrmals am Tag die Persönlichkeit wechseln zu müssen. Es ist schwierig, an Aufgaben zu arbeiten, die Konzentration erfordern, wenn Sie ständig unterbrochen werden.
Rich
5

Vertrieb .

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

Dan Ray
quelle
4

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.

HLGEM
quelle
Ja ja und ja Geben Sie den Entwicklern niemals Zugang zur Produktion und nur sehr eingeschränkt (und am besten gar nicht) zur Inszenierung. Nicht zuletzt verringert es den Stress, dem sie ausgesetzt sind.
ElGringoGrande
1
Ja! Ich bin ein Entwickler und möchte nicht auf all diese Produktionsmaterialien zugreifen können . Und mit anderen Personen, die die Bereitstellung der Software durchführen, ist dies ein weiterer Test des Bereitstellungsprozesses. (Und vielleicht verbessert sich auch die Wiederherstellung nach einem Desaster.)
Erschrecken Sie
3

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.

Jason Williams
quelle
2
"Die meisten Programmierer sind im Artwook sehr arm" und "Viele Programmierer sind nicht sehr interessiert" sind nicht dasselbe wie "kein Programmierer interessiert" und "alle Programmierer sind schlecht". Ich habe tatsächlich ein Paar gekannt, das ziemlich gut darin ist.
MIA
1
@ Jim Leonardo: In der Tat. Deshalb habe ich "am meisten" und "viel" und nicht "alles" gesagt. :-)
Jason Williams
3

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.

David Thornley
quelle
Ja, die meisten Tests sollten neben den Spezifikationen geschrieben werden, bevor Code erstellt wird. Obwohl es keine schlechte Sache ist, wenn ein Entwickler zusätzliche Tests hinzufügt, die auf dem Wissen darüber basieren, was er berührt hat.
Peter Boughton
3

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.

rjzii
quelle
1

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.

Audrius
quelle
1

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.

Ingvald
quelle
1

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.

Wildpeaks
quelle
0

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.

Johnny
quelle