Warum wird von Programmierern erwartet, dass sie lange arbeiten? [abgeschlossen]

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

Da meine Kollegen all diese Arbeit außerhalb der Büro- und Arbeitszeiten erledigen, fühle ich mich, als wäre ich ein 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 das normal ist und ob ich mich daran gewöhnen sollte, Code außerhalb der normalen Arbeitszeiten zu schreiben. Oder ob diese Jungs nur über Leistungsträger sind.

Ich stimme dafür, diese Frage als nicht zum Thema gehörend 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 breit, subjektiv und situativ ist.
Es ist nicht zu weit gefasst - obwohl die Prämisse fragwürdig ist, gibt es wirklich nur ein paar Gründe für die langen Arbeitszeiten: schlechte Planung und unflexibles Projektmanagement.
In manchen Kulturen/Unternehmen ist das normal, in anderen überhaupt nicht – wenn ich mehr als 37,5 Stunden pro Woche arbeite, muss ich das auf meinem Stundenzettel rechtfertigen.
Sehr fragwürdige Prämisse. Es gibt so viele Rollen, die länger arbeiten, dass "mehr als die typischen 40 Stunden" zu arbeiten tatsächlich relativ Teilzeit klingt :-) 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 Kollegen tatsächlich mehr als 40 Stunden (auf einer normalen, dauerhaften Basis) arbeiten? Wenn Sie zum Beispiel jeden Tag um 8:00 Uhr kommen und um 17:00 Uhr gehen, können Sie wirklich sagen, dass Sie eine genaue Vorstellung davon haben, wie oft und wie lange Ihre Kollegen bleiben, um „außerhalb der normalen Arbeit“ zu arbeiten?
Wir haben minutengenaue Stempelkarten. Über die Gleitzeit hinausgehende Überstunden müssen vorher genehmigt werden. Dies hängt ganz von der Unternehmenskultur und den Vorschriften ab.
@Brandin: Es sei denn, du kommst eines Tages um 18 Uhr zurück und schaust nach, wer noch da ist :-)
Dies kann je nach Unternehmen variieren. Jeder Entwickler in meinem Unternehmen hat 37 Stunden eingeplant. Einzige Ausnahme ist, wenn am Wochenende etwas kaputt geht und der Bereitschaftsdienst arbeiten muss.
Mir wurde gesagt, dass bei allen drei Jobs, in denen ich bisher gearbeitet habe, 40-45 erwartet werden. Die implizite Erwartung ist, dass 45 die Norm ist

Antworten (6)

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

Warum passiert das?

Die häufigste Ursache dafür ist Personalmangel oder schlechte Planung. Es gibt so ziemlich drei Faktoren bei der Entwicklung – Features, Qualität, Zeit. Wenn Sie Zeit und Qualität festlegen, schränken Sie automatisch die Funktionen ein, die Sie liefern können. Einige Orte wollen alle drei - gute Qualitätsmerkmale innerhalb einer bestimmten Frist. Aber sie wollen nicht mehr Personal einstellen (hauptsächlich aus Geldgründen, aber manchmal kann ein neuer Entwickler ein Projekt verlangsamen), sodass das aktuelle Team am Ende mehr Stunden pro Person hat.

Damit verbunden ist die Erwartung, dass ein Entwickler 7,5 Stunden am Tag programmieren wird, wenn er für 7,5 Stunden unter Vertrag genommen wird. Dies geschieht nicht. Entwickler brauchen Pausen für Kaffee und Toilette, sie checken E-Mails, nehmen an Meetings teil. Um also die erwarteten 7,5 Stunden an Aufgaben zu erledigen, benötigen sie dafür 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, jeden Tag etwa 5-6 Stunden „on task“ einzuplanen).

Ein weiterer Grund – und ich habe gesehen, dass dies mehr in der Gaming-Branche als anderswo der Fall ist, aber es gilt auch im Allgemeinen – Entwickler holen auf, wenn sie früh im Projekt (oder sogar am Tag) nachlassen. Okay - nicht ganz nachlassen ... Aber viele Projektpläne des Managements berücksichtigen Forschung und Entdeckung nicht ohne Weiteres. Ich habe Geschichten von Spieleentwicklungsstudios gehört, in denen sie alle möglichen seltsamen und verrückten Ideen und Programme als Forschung für die ersten ein oder zwei Jahre in einem Zwei- oder Dreijahresplan ausprobiert haben ... Dann würden sie feststellen, dass sie ein Produkt liefern müssen , und verbringen dann ein Jahr damit, all die Arbeit zu erledigen, die sie im Vorjahr nicht erledigt haben. Dies kann tagsüber passieren, wo sie am Morgen für die nicht produktive Entwicklung nachgeholt werden.

Ist es üblich?

Wie gesagt, diese Praxis ist nicht universell. Wir haben eine wöchentliche Mindestarbeitszeit 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 in fast drei Jahren nur zwei Wochen, in denen Überstunden angefordert wurden. Wir haben auch keine Deadline verpasst.

Es gibt viele andere Orte, an denen man arbeiten kann, 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 sich oft beeilen, aufzuholen, weil sie nicht wirklich die ganze Zeit gearbeitet haben
Es ist aber nicht wirklich schlimm. Die meisten von ihnen programmieren - nur nicht bei der Arbeit ...
Ja, das ist mir egal, solange die Arbeiten erledigt und Fristen eingehalten werden
Wenn Sie Änderungen im Schätzprozess vornehmen möchten, kann es hilfreich sein, einige spezifische Daten zu erfassen, die die „Auf-Task-Zeit“ zeigen. Ich habe einige Tage lang signifikante Aktionen in nicht weniger als 15-Minuten-Schritten für einen Tag aufgezeichnet und konnte dann feststellen, dass ich (Beispiel) durchschnittlich 1,25 Stunden pro Tag mit E-Mail- und Verwaltungsarbeiten verbrachte, 0,75 mit Codeüberprüfungen , 2,25 anderen helfen oder betreuen, 0,5 in Meetings, sodass ich mit 3,25 tatsächlich bei der Aufgabe 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 schätze, der Gruppenzwang lässt die Leute berichten, dass sie 8 Stunden statt 6 Stunden am Tag „gearbeitet“ haben.
Der Mitarbeiter muss noch 7,5 Stunden Arbeit verbuchen – die 6 Stunden dienen der Planung
"Features, Qualität, Zeit ... Manche Orte wollen alle drei ..." Siehe en.wikipedia.org/wiki/Project_management_triangle

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

Unter sonst gleichen Bedingungen sind sie vorerst bessere Mitarbeiter, wenn sie mehr erreichen … vorausgesetzt, sie können dieses Tempo aufrechterhalten, ohne auszubrennen. Intelligenter zu arbeiten ist besser als härter zu arbeiten, aber mit genügend Zeit können Sie einen Nagel mit einem Schraubendreher eintreiben. Natürlich wird der Schraubenzieher dabei ziemlich verprügelt; Sie möchten diesen Ansatz möglicherweise nicht verfolgen.

Wenn sie länger arbeiten und keine qualitativ hochwertigeren Ergebnisse liefern, ist das ein Vorteil für Sie; Sie haben mehr Reservekapazität.

Die Tatsache, dass jemand anderes produktiver sein könnte, sollte Sie an sich nicht erschrecken. Es wird immer Leute geben, die Ringe um Sie herum codieren können, und Leute, die Schwierigkeiten haben, mit Ihnen Schritt zu halten. Konzentrieren Sie sich darauf, Ihre eigenen Fähigkeiten aufzubauen, um der beste Mitarbeiter zu sein, der Sie sein können, und 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 zu Ihrem Wert als Mitarbeiter zählt.

Wie wir in anderen Antworten gesagt haben, ist dies ein Positivsummenspiel. Mit Menschen zu arbeiten bringt dich schneller weiter, als gegen sie zu arbeiten.

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, bleibt Ihnen überlassen. Sie müssen nicht der Typ sein, der mit seinem Keyboard verheiratet ist, um ein wertvolles Mitglied der Community zu sein, aber wenn Sie diesen Weg gehen wollen und das höhere Tempo wirklich aufrechterhalten können, ist dies eine Möglichkeit, „die Erwartungen bei weitem zu übertreffen“. Es ist weder der einzige noch der beste Weg für die meisten Menschen, und ein einfaches „Übertreffen“ kann völlig ausreichend sein, wenn Sie nicht fest entschlossen sind, mit 30 Jahren ein VP zu sein.

+1 Der Fragesteller ist sehr unklar, ob die zusätzlichen Stunden auf schlechtes Projektmanagement oder leidenschaftliche Mitarbeiter zurückzuführen sind

Sie haben eine festgelegte Menge an Arbeit, die bis zu einer Frist erledigt werden muss, und eine festgelegte Anzahl von Mitarbeitern, die die Arbeit erledigen. Sie können es für beliebig viele Projekte so betrachten. Nehmen Sie also die Menge an Arbeit und teilen Sie sie durch die Anzahl der Personen, die die Arbeit erledigen: Kann es erledigt werden, wenn alle eine gleichmäßige 40-Stunden-Woche arbeiten? Wie Menschen mit ihrer Zeit umgehen, hängt weitgehend von einer Reihe von Faktoren ab, aber Arbeit: Personal vs. Deadline ist ein grundlegendes Prinzip.

Zum Beispiel: Bei einigen Jobs bringt härteres Arbeiten während derselben Schicht nicht den gleichen Effekt wie längeres Arbeiten, und bei anderen ist es wünschenswert, die Arbeit mit nach Hause zu nehmen, anstatt sich während einer langen Schicht schrecklich zu verbrennen.

Und deshalb wurde der agile Prozess populär und erfolgreich. Anstatt bis zum Abgabetermin zu arbeiten, passen Sie den Abgabetermin an Ihre Kapazität an. Alle ein bis zwei Wochen, je nachdem, wie Sie Ihren Prozess einrichten, sehen Sie sich Ihr Feature-Backlog an, priorisieren es, bewerten, wie viel Aufwand damit verbunden ist (in willkürlichen Punkten) und die Arbeit an dem, was Sie „historisch“ fertigstellen konnten. Wir legen auch Wert darauf, keine Heldentaten zu ziehen, um einen Sprint zu absolvieren, da dies die Zahlen verzerrt. Wir schnallen uns aber an und arbeiten extra, wenn es im Großen und Ganzen nicht so läuft, wie wir es uns wünschen. Aber es ist eine Teamentscheidung.

Ich denke, vieles davon ist auf die frühen Tage der gedankenlosen Stunden der Speicherzuweisung, langer Builds und mehrdeutiger Fehlermeldungen zurückzuführen. Und auch Pushs einer Versionsfreigabe.

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

In so etwas wie Gaming ist die Norm 60+ und wird wahrscheinlich so bleiben.

Meine Erfahrung mit Softwareentwicklung ist, dass es eine Kombination von Dingen ist:

Einem Auftrag nicht genügend Ressourcen zugewiesen, kombiniert mit schlechter Planung.

Es gibt diesen Witz, der herumgeht, dass Entwickler immer 50 % zu der Zeit hinzufügen, die sie tatsächlich für etwas in einem Angebot benötigen, und dann fügen ihre PMs weitere 50 % hinzu. Das ist nicht ganz falsch und es ist 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 unvorhergesehene Fehler behoben haben, sich mit Komplikationen befassen, die neue Anforderungen mit sich bringen (und ich liebe Agile, aber das ist eine Sache, die damit passiert). Unit-Tests, QA-Tests, Code-Review und so weiter.

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

Bereiten Sie sich auf das Scheitern vor

Als Auftragnehmer mag ich an neuen Jobs unter anderem die Abwechslung und oft die riesigen, klaffenden Probleme, die zu lösen ich hereingeholt wurde. Es ist ganz natürlich, dass man extra an diesen eklatanten Problemen arbeitet, und obendrein muss ich sagen, dass es am Anfang viel Spaß macht, sich mit ganz neuen Problemen zu beschäftigen. Ich denke, das führt dazu, dass viele Leute zu Beginn eines Gigs viel OT arbeiten, bezahlt oder anderweitig.

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

Der ständige Todesmarsch

Eine Sache, die ich auch ziemlich oft gesehen habe, ist ein Team, das sich im 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 größeren Fehler gibt, den Sie sofort beheben müssen, aber ich war an Orten, an denen das Management die Dinge so zu arrangieren scheint, dass es immer einen gibt drohende Krise gleich um die Ecke aus... Gründen. Einige Leute denken, dass dies die Produktivität erhöht (da bin ich 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, wofür es sechs Monate hätte brauchen sollen, und so weiter .

Es ist schwierig, eine gute Lösung für dieses Problem zu finden, da es in der Regel nicht von den Entwicklern, sondern vom Management kommt. Alles, was ich dazu sagen kann, ist, stellen Sie sicher, dass Sie in ständiger Kommunikation mit dem Management bleiben, damit es zumindest versteht, wie viel Stress es Ihnen und Ihrem Team bereitet.

Umfang kriechen

Wie bereits erwähnt, genieße ich Agilität, und eines der Dinge, die mir am meisten Spaß machen, ist die ständige wöchentliche oder zweiwöchentliche Kommunikation, die Sie mit Menschen haben, die Ihr Produkt verwenden werden. 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 das wirklich große Problem von Waterfall, das ist, dass man monatelang an etwas arbeiten kann, nur um mit einem Endprodukt zu enden, das völlig falsch ist.

Abgesehen davon eignet sich Agile sehr gut für Leute, die in diesen Planungs-/Demonstrationsmeetings neue Ideen entwickeln, und es ist wieder einmal schwer, der Typ zu sein, der sagt: „Das steht nicht in der Dokumentation. Wir können es hinzufügen, aber es wird X hinzufügen Wochen zum Projekt". Aber jemand muss dieser Typ sein, wenn Sie verhindern wollen, dass der Umfang kriecht und möglicherweise zum ständigen Todesmarsch führt.

So arbeiten wir einfach

Ich denke, das ist wirklich das unwichtigste von allen, aber wenn ich vor ein Problem gestellt werde, setze ich mich oft einfach hin und arbeite daran, bis es gelöst ist. Wenn das ein paar 14-Stunden-Tage erfordert, dann erfordert es ein paar 14-Stunden-Tage. Und wenn ich den Rest der Woche nicht irgendwann früher abheben kann, lande ich vielleicht bei 50 Stunden plus.

Dies ist kein normaler Bürojob, bei dem Sie um 9 Uhr einchecken, eine Stunde Mittag essen und um 6 ausstempeln. Mir ist aufgefallen, dass Nicht-Programmierer sich dessen etwas weniger bewusst sind, wenn sie sehen, dass ein Entwickler etwas nimmt an einem Mittwoch um 2 Uhr nachmittags frei (sie sehen natürlich nicht, 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), sondern der allgemeine Punkt bleibt: Das ist ein Job, bei dem man am Ende des Tages nicht nach der geleisteten Arbeitszeit, sondern nach der erbrachten Leistung beurteilt wird.

Start-ups

Sie müssen nicht immer 70 Stunden pro Woche in einem Start-up arbeiten, aber denken Sie daran, dass Sie für ein kleines Unternehmen, das gerade erst anfängt, nicht nur für einen Gehaltsscheck arbeiten, Sie arbeiten, um zu bleiben Ihr Unternehmen im Geschäft. Sorry, aber manchmal lässt es sich einfach nicht vermeiden. Wenn Sie sich um die 40-Stunden-Marke halten möchten, finden Sie ein Fortune-500-Unternehmen, für das Sie arbeiten können.

Programmierer sind Autoren.

Wenn ein Autor ein Buch schreiben würde, wäre es wirklich seltsam, wenn jemand anderes die Mitte des Absatzes übernehmen und an einen anderen Autor weitergeben würde.

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

Wenn Sie jedoch gut sind, würden sie lieber jemanden 15 Stunden lang gut schreiben lassen, als 8 Stunden gutes Schreiben und 7 Stunden Kauderwelsch zu haben.

Wenn Sie weniger Stunden als Programmierer arbeiten möchten, gehen Sie zu einem agilen Geschäft, gehen Sie zu einem Unternehmen mit einer Menge Programmierern (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 noch Qualität liefern wird, 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 hört der Autor vielleicht auf, bevor das Buch zu Ende ist, aber sie sind immer noch die besten, um die Geschichte zu schreiben, Stunden, die verdammt sind.
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, erzielen Sie bessere Ergebnisse. Ich stimme Ihnen zu, dass ein guter Autor immer besser ist, nur nicht, dass es sich auszahlt, wenn man ihn 15 Stunden arbeiten lässt.
@PaulHiemstra - gehen Sie zum Autorenstapel. Sehen Sie, wie viele Stunden Autoren im letzten Monat vor einer Frist investiert haben. 15 Stunden werden wie Urlaub erscheinen.