Frage:
Warum wird von Programmierern erwartet, dass sie lange arbeiten?
cocoa
2016-02-12 05:57:32 UTC
view on stackexchange narkive permalink

Ich bin ein Junior-Entwickler, daher habe ich nicht viel Erfahrung auf diesem Gebiet, aber ich habe zwei verschiedene Jobs und es scheint normal oder fast erwartet, dass Entwickler mehr als die typischen 40 Stunden pro Woche arbeiten. Ich verstehe, dass Menschen sehr leidenschaftlich an der Entwicklung interessiert sein können und gerne Dinge außerhalb der Arbeit tun. Ich selbst genieße, was ich tue, aber es funktioniert immer noch. Ich mag es nicht, Arbeit nach Hause zu bringen.

Da meine Mitarbeiter all diese Arbeiten außerhalb des Büros und der Arbeitszeit erledigen, fühle ich mich als schlechterer Angestellter als sie. Aber es wurde nie gesagt "Wir brauchen dich, um mehr als 40 Stunden zu arbeiten" oder was auch immer.

Ich möchte nur wissen, ob dies normal ist und ob ich mich daran gewöhnen sollte, Code außerhalb der normalen Arbeitszeit zu schreiben. Oder wenn diese Jungs einfach überdurchschnittlich gut abschneiden.

Ich stimme dafür, diese Frage als nicht thematisch zu schließen, da sie von einer fragwürdigen Prämisse ausgeht und ein Thema abdeckt, das für das Q & A-Format von StackExchange zu umfassend, subjektiv und situativ ist.
Es ist nicht zu weit gefasst - obwohl die Prämisse fraglich ist, gibt es wirklich nur ein paar Gründe für die langen Stunden: schlechte Planung und unflexibles Projektmanagement.
In einigen Kulturen / Unternehmen ist dies normal, in anderen überhaupt nicht. Wenn ich mehr als 37,5 Stunden pro Woche arbeite, muss ich dies auf meiner Arbeitszeittabelle begründen.
Sehr fragwürdige Prämisse. Es gibt so viele Rollen, die länger arbeiten, dass "mehr als die typischen 40 Stunden" tatsächlich relativ Teilzeit klingen :-) Es ist sicherlich weniger als die Hälfte der Stunden, die von Mitarbeitern an einem Ort erwartet werden, an dem ich gearbeitet habe (nichts mit Programmierung zu tun).
Was sind die konkreten Dinge, die Sie glauben lassen, dass Ihre Mitarbeiter tatsächlich mehr als 40 Stunden arbeiten (auf normaler, nachhaltiger Basis)? Wenn Sie beispielsweise jeden Tag um 8 Uhr morgens eintreffen und um 17 Uhr abreisen, können Sie dann wirklich sagen, dass Sie eine genaue Vorstellung davon haben, wie oft und wie lange Ihre Mitarbeiter "außerhalb der normalen Arbeit" bleiben?
Wir haben Zeitkarten mit winziger Präzision. Überstunden außerhalb der Gleitzeit müssen vorher genehmigt werden. Dies hängt ganz von der Unternehmenskultur und den Vorschriften ab.
@Brandin: Nicht, wenn Sie nicht eines Tages um 18 Uhr zurückkommen und überprüfen, wer noch da ist :-)
Dies kann je nach Unternehmen variieren. Jeder Entwickler in meinem Unternehmen hat 37 Stunden Zeit. Die einzige Ausnahme ist, wenn am Wochenende etwas kaputt geht und die Bereitschaftsperson arbeiten muss.
Mir wurde gesagt, dass bei allen drei Jobs, an denen ich bisher gearbeitet habe, 40-45 erwartet werden. Die implizite Erwartung ist, dass 45 die Norm ist
Sechs antworten:
#1
+10
HorusKol
2016-02-12 06:19:33 UTC
view on stackexchange narkive permalink

Ich glaube nicht, dass dies spezifisch für die Entwicklungsbranche ist, aber es kann den Anschein haben, dass es häufig vorkommt, aber nicht alle (Programmier-) Jobs sind auch so.

Warum passiert es?

Die häufigste Ursache dafür ist Personalmangel oder schlechte Planung. Es gibt so ziemlich drei Faktoren in der Entwicklung - Funktionen, Qualität, Zeit. Wenn Sie Zeit und Qualität festlegen, beschränken Sie automatisch die Funktionen, die Sie bereitstellen können. Einige Orte möchten alle drei Funktionen von guter Qualität innerhalb einer bestimmten Frist. Sie möchten jedoch nicht mehr Mitarbeiter einstellen (hauptsächlich aus Geldgründen, aber manchmal kann ein neuer Entwickler ein Projekt verlangsamen), sodass das aktuelle Team mehr Stunden pro Person hat.

Eingebunden Dies ist eine Erwartung, dass ein Entwickler 7,5 Stunden am Tag codiert, wenn er für 7,5 Stunden einen Vertrag abschließt. Das passiert nicht. Entwickler brauchen Pausen für Kaffee und Toilette, sie checken E-Mails und nehmen an Meetings teil. Um die erwarteten 7,5 Stunden Aufgaben zu erledigen, benötigen sie 10 Stunden.

Das Management muss die Nebenkosten berücksichtigen und nur einen Teil dieser 7,5 Stunden für Entwicklungsaufgaben einplanen ( Meine persönliche Präferenz ist es, jeden Tag etwa 5 bis 6 Stunden "on task" zu planen.

Ein weiterer Grund - und ich habe gesehen, dass dies mehr in der Spielebranche als anderswo der Fall ist, aber es gilt in Auch im Allgemeinen - Entwickler holen zu Beginn des Projekts (oder sogar am Tag) auf, nachzulassen. Okay - nicht ganz nachlassend ... Aber viele Projektpläne des Managements lassen sich nicht leicht für Forschung und Entdeckung erklären. Ich habe Geschichten von Spieleentwicklungsstudios gehört, in denen sie alle möglichen seltsamen und verrückten Ideen und Programme als Recherche für die ersten ein oder zwei Jahre in einem Zwei- / Dreijahresplan ausprobiert haben ... Dann würden sie erkennen, dass sie ein Produkt liefern müssen und dann ein Jahr damit verbringen, all die Arbeiten zu erledigen, die sie im Vorjahr nicht erledigt haben. Dies kann an dem Tag geschehen, an dem sie am Morgen die unproduktive Entwicklung nachholen.

Ist es üblich?

Wie gesagt, diese Praxis ist nicht universell. Wir haben eine Mindestarbeitswoche von 37,5 Stunden, und fast jeder verbringt in den meisten Wochen weniger als 40 Stunden bei der Arbeit. Nach einigen Änderungen in der Projektplanung gab es nur zwei separate vierzehn Tage, in denen in fast drei Jahren Überstunden angefordert wurden. Wir haben auch keine Frist verpasst.

Es gibt viele andere Orte, an denen wir arbeiten können, und jeder hat eine andere Kultur. Wenn Sie keine übermäßigen Arbeitszeiten mögen, sollten Sie in der Lage sein, einen Arbeitsplatz zu finden, der stabilere Arbeitszeiten bietet.

Richtig, ich kenne viele Entwickler, die oft nachholen, weil sie nicht die ganze Zeit wirklich gearbeitet haben
Es ist jedoch keine schlechte Sache. Die meisten von ihnen programmieren - nur nicht im Einsatz ...
Ja, es ist mir egal, solange die geleisteten Arbeiten und Fristen eingehalten werden
Wenn Sie Änderungen im Schätzprozess vornehmen möchten, kann es hilfreich sein, bestimmte Daten zu erfassen, die die "On Task" -Zeit anzeigen. Ich habe einige Tage lang wichtige Aktionen in Schritten von nicht weniger als 15 Minuten pro Tag aufgezeichnet und konnte dann feststellen, dass ich (Beispiel) durchschnittlich 1,25 Stunden pro Tag mit E-Mail- und Verwaltungsarbeiten verbracht habe und 0,75 Codeüberprüfungen durchgeführt habe , 2.25 anderen helfen oder Mentoring, .5 in Besprechungen, so dass ich mit 3.25 tatsächlich bei der Arbeit bin. Ich mache das immer noch, um meine eigenen Arbeitsgewohnheiten zu verbessern.
Die 5-6 Stunden "on task" scheinen eine geniale Idee zu sein. Wir haben 9-Stunden-Tage in Indien und erledigen eine 8-Stunden-Aufgabe oder zwei 4-Stunden-Aufgaben an einem Tag. Unterbrechungen werden in diesen Stunden berücksichtigt. Wurden die beiden Systeme verglichen? Ich denke, Gruppenzwang lässt die Leute berichten, dass sie 8 Stunden anstatt 6 Stunden am Tag "gearbeitet" haben.
Der Mitarbeiter muss noch 7,5 Stunden arbeiten - die 6 Stunden dienen Planungszwecken
"Funktionen, Qualität, Zeit ... Einige Orte möchten alle drei ..." Siehe https://en.wikipedia.org/wiki/Project_management_triangle
#2
+4
keshlam
2016-02-12 08:35:32 UTC
view on stackexchange narkive permalink

Die geleisteten Arbeitsstunden sind für Ihren Arbeitgeber irrelevant. Was zählt, ist die Produktivität. Diese Leute arbeiten möglicherweise zu spät, um mehr zu erledigen, oder zu spät, um genug zu erledigen.

Alle anderen sind gleich, wenn sie mehr erreichen, sind sie bessere Mitarbeiter, z jetzt ... vorausgesetzt, sie können dieses Tempo halten, ohne auszubrennen. Intelligenter arbeiten ist besser als härter arbeiten, aber wenn Sie genügend Zeit haben, können Sie einen Nagel mit einem Schraubenzieher einschlagen. Natürlich wird der Schraubenzieher dabei ziemlich verprügelt; Möglicherweise möchten Sie diesen Ansatz nicht wählen.

Wenn sie länger arbeiten und nicht qualitativ hochwertigere Ergebnisse liefern, ist dies ein Punkt für Sie. Sie haben mehr Reservekapazität.

Die Tatsache, dass jemand anderes produktiver ist, sollte Sie an sich nicht erschrecken. Es wird immer Leute geben, die Ringe um dich herum codieren können, und Leute, die Schwierigkeiten haben, mit dir Schritt zu halten. Konzentrieren Sie sich darauf, Ihre eigenen Fähigkeiten auszubauen, um der beste Mitarbeiter zu sein, den Sie sein können. Dazu gehört auch, anderen zum Erfolg zu verhelfen. Das sind keine Konkurrenten, sondern Ressourcen, die Ihnen helfen können, Ihre Arbeit besser zu machen ... und möglicherweise Menschen, die einige Dinge von Ihnen lernen könnten, was auch für Ihren Wert als Mitarbeiter von Bedeutung ist.

As Wir haben in anderen Antworten gesagt, dass dies ein Spiel mit positiver Summe ist. Wenn Sie mit Menschen arbeiten, kommen Sie schneller und weiter als gegen sie.

Fazit: Sie werden für eine bestimmte Anzahl von Stunden bezahlt. Sie müssen diese Stunden arbeiten. Ob Sie dem Unternehmen zusätzliche Zeit spenden, liegt bei Ihnen. Sie müssen nicht der Typ sein, der mit seiner Tastatur verheiratet ist, um ein wertvolles Mitglied der Community zu sein, aber wenn Sie diesen Weg gehen möchten und wirklich das höhere Tempo halten können, das eine Möglichkeit ist, zu schlagen "übertrifft die Erwartungen bei weitem". Dies ist weder der einzige noch der beste Weg für die meisten Menschen, und ein einfaches "Überschreiten" kann völlig ausreichend sein, wenn Sie nicht das Herz haben, bis zum 30. Lebensjahr VP zu werden.

+1 Der Fragesteller ist sich nicht sicher, ob die zusätzlichen Stunden auf schlechtes Projektmanagement oder leidenschaftliche Mitarbeiter zurückzuführen sind
#3
+3
CKM
2016-02-12 06:07:47 UTC
view on stackexchange narkive permalink

Sie haben eine festgelegte Menge an Arbeit, die innerhalb einer bestimmten Frist erledigt werden muss, und eine festgelegte Menge an Mitarbeitern, die die Arbeit erledigen. Sie können es für eine beliebige Anzahl von Projekten so betrachten. Nehmen Sie also die Menge an Arbeit und teilen Sie sie durch die Anzahl der Personen, die die Arbeit erledigen: Kann dies getan werden, wenn alle eine gerade 40-Stunden-Woche arbeiten? Wie Menschen mit ihrer Zeit umgehen, hängt weitgehend von einer Reihe von Faktoren ab, aber Arbeit: Personal vs. Frist ist ein Grundprinzip.

Zum Beispiel: Bei einigen Jobs ist es nicht netto, während derselben Schicht härter zu arbeiten Sie haben den gleichen Effekt wie längere Arbeitszeiten, und für andere ist es wünschenswert, Ihre Arbeit mit nach Hause zu nehmen, anstatt sich während einer langen Schicht schrecklich auszubrennen.

Und deshalb wurde der agile Prozess populär und erfolgreich. Anstatt an der Frist zu arbeiten, passen Sie die Frist an Ihre Kapazität an. Abhängig davon, wie Sie Ihren Prozess einrichten, überprüfen Sie alle ein oder zwei Wochen Ihr Feature-Backlog, priorisieren es, bewerten den Aufwand (in willkürlichen Punkten) und die Arbeit an dem, was Sie "historisch" abgeschlossen haben. Wir legen auch Wert darauf, keine Heldentaten zu ziehen, um einen Sprint zu beenden, da dies die Zahlen verzerrt. Wir schnallen uns an und arbeiten extra, wenn die Dinge im Großen und Ganzen nicht so laufen, wie wir es möchten. Aber es ist eine Teamentscheidung.
#4
+1
paparazzo
2016-02-12 08:44:25 UTC
view on stackexchange narkive permalink

Ich denke, ein Großteil davon hängt mit den frühen Tagen sinnloser Stunden der Zuweisung von Speicher, langen Builds und mehrdeutigen Fehlermeldungen zusammen. Und auch Pushs einer Versionsversion.

Mit besseren Tools von heute sind Programmierer viel effizienter und haben weniger Totzeiten. Die Norm scheint sich zu einer normaleren Arbeitswoche zu bewegen.

In so etwas wie Spielen ist die Norm 60+ und wird wahrscheinlich fortgesetzt.

#5
+1
NotVonKaiser
2016-02-12 22:26:50 UTC
view on stackexchange narkive permalink

Meine Erfahrung mit der Softwareentwicklung zeigt, dass es sich um eine Kombination von Dingen handelt:

Nicht genügend Ressourcen für einen Job zugewiesen, kombiniert mit schlechter Planung.

Es gibt diesen Witz, dass Entwickler immer 50% zu der Zeit hinzufügen, in der sie tatsächlich etwas in einem Zitat tun werden, und dann fügen ihre PMs weitere 50% hinzu. Das ist nicht ganz falsch und auch nicht immer eine schlechte Idee. Ein Job, von dem Sie glauben, dass er 4 Stunden dauert, kann tatsächlich ein paar Tage dauern, bis Sie ihn behoben haben, sobald Sie unvorhergesehene Fehler behoben haben und sich mit Komplikationen befasst haben, die neue Anforderungen mit sich bringen (und ich liebe Agile, aber das ist eine Sache, die damit passiert). Unit-Tests, QS-Tests, Codeüberprüfung usw.

Die einzige Möglichkeit, dies zu beheben, besteht darin, im Voraus zu planen, und niemand möchte wie der langsame Entwickler in der Gruppe aussehen.

Sich auf einen Misserfolg einstellen

Als Auftragnehmer mag ich es, neue Jobs zu wechseln, und oft ist es das große, klaffende Probleme, die ich beheben musste. Es ist ganz natürlich, extra zu arbeiten, um diese krassen Probleme zu beheben, und außerdem muss ich sagen, dass es zunächst viel Spaß macht, sich mit völlig neuen Problemen zu befassen. Ich denke, das führt dazu, dass viele Leute zu Beginn eines Auftritts viel OT arbeiten, bezahlt oder auf andere Weise.

Wo diese Idee zusammenbricht, ist das manchmal, besonders wenn Sie es nicht sind Sehr klar darüber, dass Sie zusätzliche Zeit arbeiten, um Termine usw. einzuhalten, bekommen die Nicht-Programmierer in Ihrem Team - insbesondere BAs und Stakeholder - eine falsche Vorstellung davon, wie viel Sie in einer Woche produzieren können. Das macht es besonders schwierig, 3 Monate später zu reduzieren, da Sie dann diskutieren müssen, warum Ihre Produktivität gesunken ist.

Der ständige Todesmarsch

Eine Sache, von der ich auch ziemlich viel gesehen habe, ist, dass sich ein Team in einem ständigen Krisenmodus befindet. Es ist in Ordnung, ein paar 50- oder 60-Stunden-Wochen zu arbeiten, um eine bestimmte Frist einzuhalten, oder wenn es einen großen Fehler gibt, den Sie jetzt beseitigen müssen, aber ich war an Orten, an denen das Management die Dinge so zu arrangieren scheint, dass es immer eine gibt drohende Krise gleich um die Ecke aus ... Gründen. Einige Leute denken, dass dies die Produktivität der Menschen erhöht (ich bin anderer Meinung, aber das ist sowieso der Gedanke). Manchmal kommt man mit einem Minus ins Spiel, weil das vorherige Team ein Jahr damit verbracht hat, etwas zu tun, das sie sechs Monate hätte brauchen sollen, und so weiter

Es ist schwierig, eine gute Lösung für dieses Problem zu finden, da es nicht von Entwicklern, sondern vom Management stammt. Alles, was ich dazu sagen kann, ist, sicherzustellen, dass Sie in ständiger Kommunikation mit dem Management bleiben, damit diese zumindest verstehen, wie viel Stress sie auf Sie und Ihr Team ausüben.

Scope Creep

Wie bereits erwähnt, gefällt mir Agile sehr gut, und eines der Dinge, die mir am besten gefallen, ist die ständige wöchentliche oder zweiwöchentliche Kommunikation mit Menschen, die Ihre verwenden werden Produkt. Sie zeigen, was Sie hinzugefügt haben, sie sprechen mit Ihnen darüber, wie es sich von dem unterscheidet, was sie wollten, Sie nehmen diese Änderungen vor und zeigen sie beim nächsten Sprint usw. Ich denke, es vermeidet ordentlich das wirklich große Problem des Wasserfalls, das ist, dass Sie Monate damit verbringen können, an etwas zu arbeiten, nur um ein Endprodukt zu erhalten, das völlig falsch ist.

Abgesehen davon eignet sich Agile sehr gut für Leute, die bei dieser Planung / Demonstration neue Ideen einbringen Treffen, und es ist wieder einmal schwer, dieser Typ zu sein, der sagt "das steht nicht in der Dokumentation. Wir können es hinzufügen, aber es wird X Wochen zum Projekt hinzufügen". Aber jemand muss dieser Typ sein, wenn Sie vermeiden möchten, dass das Zielfernrohr möglicherweise zum Marsch des ständigen Todes führt.

So arbeiten wir einfach

Ich denke, dies ist wirklich das am wenigsten wichtige Problem, aber wenn ich ein Problem habe, werde ich mich oft hinsetzen und daran arbeiten, bis es gelöst ist. Wenn dies einige 14-Stunden-Tage erfordert, sind einige 14-Stunden-Tage erforderlich. Und wenn ich den Rest der Woche nicht früh abheben kann, habe ich vielleicht mehr als 50 Stunden Zeit.

Dies ist kein normaler Bürojob, bei dem Sie um 9 Uhr morgens einchecken Ich habe festgestellt, dass Nicht-Programmierer dies etwas weniger bemerken, wenn sie einen Entwickler an einem Mittwoch um 2 Uhr nachmittags abheben sehen (sie sehen nicht, Natürlich, dass Sie an diesem Morgen um 5 Uhr da waren, weil es ein Problem gab, das Sie einfach nicht ins Bett bringen konnten, bis Sie es gelöst haben), aber der allgemeine Punkt bleibt: Dies ist ein Job, bei dem Sie am Ende des Tages nicht sind Gemessen an den Stunden, die Sie arbeiten, aber an den Dingen, die Sie liefern.

Start-ups

Sie müssen nicht immer 70 Stunden arbeiten Woche bei einem Start-up, aber denken Sie daran, dass Sie für ein kleines Unternehmen, das gerade erst anfängt, nicht nur für einen Gehaltsscheck arbeiten, sondern auch daran, Ihr Unternehmen im Geschäft zu halten. Entschuldigung, aber manchmal kann man das einfach nicht vermeiden. Wenn Sie sich um die 40-Stunden-Marke halten möchten, suchen Sie sich ein Fortune 500-Unternehmen, für das Sie arbeiten können.

#6
-2
blankip
2016-02-12 13:46:44 UTC
view on stackexchange narkive permalink

Programmierer sind Autoren.

Wenn ein Autor ein Buch schreiben würde, wäre es wirklich seltsam, wenn jemand anderes den mittleren Absatz übernimmt und an einen anderen Autor weitergibt.

Es gibt einige Läden, in denen die Programmierer das ganze Buch schreiben, und andere, in denen sie sich um ihre eigenen Kapitel kümmern.

Wenn Sie jedoch gut sind, möchte jemand lieber 15 Stunden gut schreiben als 8 Stunden gut schreiben und 7 Stunden Kauderwelsch.

Wenn Sie weniger Stunden als Programmierer arbeiten möchten Gehen Sie in einen agilen Shop, gehen Sie zu einem Unternehmen mit einer Menge Programmierer (besser als Sie), gehen Sie zu einem Unternehmen mit einer ausgereiften Produktlinie oder werden Sie viel schneller.

Ich bin nicht davon überzeugt, dass der gute Programmierer immer noch Qualität liefert, wenn er sich der 15-Stunden-Marke nähert. Die Prämisse dieser Unternehmen ist also imo fehlerhaft.
@PaulHiemstra - Falsch. Ein guter Autor wird immer noch mehr über die Geschichte wissen als derjenige, der für einen so guten Autor übernehmen würde. Jetzt könnte der Autor aufhören, bevor das Buch vorbei ist, aber sie sind immer noch die besten, um die Geschichte zu schreiben, verdammt noch mal.
Wenn der Autor weiterhin 15 Stunden am Tag arbeitet, brennt er aus und das Buch wird nicht fertig. Wenn Sie den Autor eine normale Zeit pro Tag an dem Buch arbeiten lassen, erhalten Sie bessere Ergebnisse. Ich stimme Ihnen zu, dass ein guter Autor immer besser ist, nur nicht, dass eine gute Arbeitszeit von 15 Stunden eine gute Rendite für die investierte Zeit bringt.
@PaulHiemstra - gehe zum Writer-Stack. Sehen Sie, wie viele Stunden Autoren im letzten Monat vor Ablauf einer Frist investiert haben. 15 Stunden scheinen Urlaub zu sein.


Diese Fragen und Antworten wurden automatisch aus der englischen Sprache übersetzt.Der ursprüngliche Inhalt ist auf stackexchange verfügbar. Wir danken ihm für die cc by-sa 3.0-Lizenz, unter der er vertrieben wird.
Loading...