Zucker schrieb am 28. Dezember 2000 15:08:
> cgb schrieb am 28. Dezember 2000 14:22:
>
> > es macht oft Spass, ist aber auch (manchmal) sehr zermuerbend.
> Man
> > muss
> > immer am Ball mit neuen Technologien bleiben, es gibt absolut
> kein
> > Ausruhen. Jemand, der ne ruhige Kugel (mit fix geregelter
> > Arbeitszeit)
> > schieben will, sollte besser nicht diese Karriere waehlen. Ich
> > arbeite
> > auch nicht immer 50+h, aber es gibt einfach 'crunch times', wo
> man
> > einfach seine dead lines halten muss. Mit zunehmender Erfahrung
> > (seniority) kann man diese 'Ueberstunden' natuerlich in Grenzen
> > halten,
> > es ist aber nicht machbar, und schliesslich gibt es ja auch noch
> > cgb
> >
> Hallo cgb,
>
> verrate mir doch einmal bitte, wie alt Du bist ? Das was Du hier
> erzählst, machste vielleicht 10 Jahre, und dann kommt das "Burn Out
> Syndrom". Dann kannste Dich 3 Jahre beurlauben lassen, um Dich zu
> regenerieren.
> Wenn Du älter bist als angenommen, biste ein "Ausnahmeathlet" unter
> 1000.
> Nix für ungut...
Gebe normalerweise keine persoenlichen Daten heraus. Aber sei's drum,
ich bin gesunde 37 Jahre alt, und arbeite zur Zeit als Software
Architect bei einer groesseren Firma in der Naehe von Boston, MA.
Bisher habe ich von einem burn-out syndrom noch nichts verspueren
koennen. Im Gegenteil, ich bin immer noch SEHR hungrig auf neues.
Versteh' mich nicht falsch. Ich arbeite nicht staendig 70-80h. Es gibt
Zeiten, da kann man es mal lockerer angehen lassen, macht schon um
2-3pm Feierabend und geht mit den Kindern an den Strand. Ich denke
uebers vergangene Jahre gemittelt komme ich irgendwo auf 45-48h/Woche
(natuerlich 'unbezahlte' Ueberstunden). Meine letzte 'Interviewrunde'
in Deutschland hat gezeigt, dass es auch in Deutschland durchaus
ueblich ist, im Vertrag einen Passus einzubringen, dass 'evtl.
anfallende Ueberstunden durch das Grundgehalt abgegolten sind'. Der
Knackpunkt bei dieser Diskussion ist allerdings, dass Ueberstunden
oftmals vermeidbar sind, wenn
a) der individuelle Softwareentwickler sorgfaeltig plant
b) der Projektleiter Ueberstunden nicht von vornherein mit
einrechnet/erwartet (bei kleineren Firmen oder bei start-ups nicht
selten die Regel).
In den ersten Berufsjahren zahlt man oft gewissermassen Lehrgeld, weil
man eben die eigene Zeit nicht richtig einschaetzt, und
Softwareentwickler normalerweise zu optimistisch sind. Erfahrenere
Entwickler kommen in der Regel besser zurecht.
Hinzu kommt jedoch, dass man 'multi-tasking-faehig' sein muss, da man
in Regel an mehr als nur einem Projekt arbeitet. Waehrend wir die neue
Release gerade implementieren, muss ich bereits fuer die naechste
planen, und bin zudem noch evtl. an anderen Nebenprojekten beteiligt,
wie z.B. die Localization der vorhergehenden Release. Gerade bei Firmen
mit kurzem Entwicklungszyklen (im Falle meiner jetzigen Firma 6 Monate)
ist solch eine Mehrfachbelastung durchaus ueblich. Da ich fuer die
technische Planung und Ausfuehrung verantwortlich bin, muss ich
ueberall meine Haende im Spiel haben (kann natuerlich auch wenn
moeglich delegieren). Mit zunehmender Erfahrung erwarte ich diese
Faehigkeit auch von meinen Entwicklern, und das heisst nicht, dass
jeder zig Ueberstunden arbeiten muss. Sollte ein Entwickler unerwartete
Probleme erkennen, so erwarte ich einfach, dass er sie dem Team so
frueh wie moeglich anzeigt, damit man entweder gemeinsam nach einer
Loesung suchen kann oder ggf. umplant. Sehr bewaehrt hat sich in diesem
Zusammenhang der 'Extreme Programming'-Ansatz, der sich durchaus auch
mit starreren Strukturen (Entwicklungsprozessen) vertraegt.
cgb
> cgb schrieb am 28. Dezember 2000 14:22:
>
> > es macht oft Spass, ist aber auch (manchmal) sehr zermuerbend.
> Man
> > muss
> > immer am Ball mit neuen Technologien bleiben, es gibt absolut
> kein
> > Ausruhen. Jemand, der ne ruhige Kugel (mit fix geregelter
> > Arbeitszeit)
> > schieben will, sollte besser nicht diese Karriere waehlen. Ich
> > arbeite
> > auch nicht immer 50+h, aber es gibt einfach 'crunch times', wo
> man
> > einfach seine dead lines halten muss. Mit zunehmender Erfahrung
> > (seniority) kann man diese 'Ueberstunden' natuerlich in Grenzen
> > halten,
> > es ist aber nicht machbar, und schliesslich gibt es ja auch noch
> > cgb
> >
> Hallo cgb,
>
> verrate mir doch einmal bitte, wie alt Du bist ? Das was Du hier
> erzählst, machste vielleicht 10 Jahre, und dann kommt das "Burn Out
> Syndrom". Dann kannste Dich 3 Jahre beurlauben lassen, um Dich zu
> regenerieren.
> Wenn Du älter bist als angenommen, biste ein "Ausnahmeathlet" unter
> 1000.
> Nix für ungut...
Gebe normalerweise keine persoenlichen Daten heraus. Aber sei's drum,
ich bin gesunde 37 Jahre alt, und arbeite zur Zeit als Software
Architect bei einer groesseren Firma in der Naehe von Boston, MA.
Bisher habe ich von einem burn-out syndrom noch nichts verspueren
koennen. Im Gegenteil, ich bin immer noch SEHR hungrig auf neues.
Versteh' mich nicht falsch. Ich arbeite nicht staendig 70-80h. Es gibt
Zeiten, da kann man es mal lockerer angehen lassen, macht schon um
2-3pm Feierabend und geht mit den Kindern an den Strand. Ich denke
uebers vergangene Jahre gemittelt komme ich irgendwo auf 45-48h/Woche
(natuerlich 'unbezahlte' Ueberstunden). Meine letzte 'Interviewrunde'
in Deutschland hat gezeigt, dass es auch in Deutschland durchaus
ueblich ist, im Vertrag einen Passus einzubringen, dass 'evtl.
anfallende Ueberstunden durch das Grundgehalt abgegolten sind'. Der
Knackpunkt bei dieser Diskussion ist allerdings, dass Ueberstunden
oftmals vermeidbar sind, wenn
a) der individuelle Softwareentwickler sorgfaeltig plant
b) der Projektleiter Ueberstunden nicht von vornherein mit
einrechnet/erwartet (bei kleineren Firmen oder bei start-ups nicht
selten die Regel).
In den ersten Berufsjahren zahlt man oft gewissermassen Lehrgeld, weil
man eben die eigene Zeit nicht richtig einschaetzt, und
Softwareentwickler normalerweise zu optimistisch sind. Erfahrenere
Entwickler kommen in der Regel besser zurecht.
Hinzu kommt jedoch, dass man 'multi-tasking-faehig' sein muss, da man
in Regel an mehr als nur einem Projekt arbeitet. Waehrend wir die neue
Release gerade implementieren, muss ich bereits fuer die naechste
planen, und bin zudem noch evtl. an anderen Nebenprojekten beteiligt,
wie z.B. die Localization der vorhergehenden Release. Gerade bei Firmen
mit kurzem Entwicklungszyklen (im Falle meiner jetzigen Firma 6 Monate)
ist solch eine Mehrfachbelastung durchaus ueblich. Da ich fuer die
technische Planung und Ausfuehrung verantwortlich bin, muss ich
ueberall meine Haende im Spiel haben (kann natuerlich auch wenn
moeglich delegieren). Mit zunehmender Erfahrung erwarte ich diese
Faehigkeit auch von meinen Entwicklern, und das heisst nicht, dass
jeder zig Ueberstunden arbeiten muss. Sollte ein Entwickler unerwartete
Probleme erkennen, so erwarte ich einfach, dass er sie dem Team so
frueh wie moeglich anzeigt, damit man entweder gemeinsam nach einer
Loesung suchen kann oder ggf. umplant. Sehr bewaehrt hat sich in diesem
Zusammenhang der 'Extreme Programming'-Ansatz, der sich durchaus auch
mit starreren Strukturen (Entwicklungsprozessen) vertraegt.
cgb