Ein Tag als Softwareentwickler

Der Beruf des Softwareentwicklers. Er beginnt irgendwann zu unchristlichen Zeiten und endet auch zu solchen. Dabei macht man nichts anderes, als den ganzen Tag vor einem Bildschirm zu sitzen und auf eine Tastatur einzuhacken. 120 Anschläge die Sekunde – acht Stunden am Tag durchweg, sodass sich der schwarze Bildschirm mit immer mehr weißen Zeichen füllt. Am Ende drückt man dann einmal auf die ENTER-Taste und zack – wir sind drin, im System der NSA. Zumindest, wenn es nach vielen Filmen geht.

Doch wie läuft so ein Tag im Leben eines Softwareentwicklers wirklich ab? Ein Tag im Leben eines Softwareentwicklers könnte wie folgt ablaufen:

Das Entwicklerleben …

… beginnt in den meisten Fällen zunächst einmal mit dem erscheinen auf Arbeit. Sachen abgelegt, schon einmal den PC einschalten und danach ab in die Küche – erstmal einen Kaffee ziehen und eine Flasche Wasser greifen. Zurück mit der Ausrüstung am Arbeitsplatz am PC einloggen und – genau, ihr wusstet es – eMail-Client öffnen. Emails lesen. Die Hände über dem Kopf zusammenschlagen. Emails beantworten. Noch schnell ein kurzer Blick über das Ticketsystem werfen – gibt es zu meinen Zwischenständen von gestern etwas neues? Sind die fertig bearbeiteten Tickets abgenommen, oder muss ich nachbessern und Bugs fixen? Nun, ist auch egal – es ist schon wieder 09:30 und damit Zeit für unser daily Stand-Up. Beeilung, der SCRUM-Master steht schon in der Tür.

Das Daily StandUp

Das Daily- oder auch Standup-Meeting ist ein 10-15 minütiges Meeting. Dabei bildet die Entwicklerschaft einen Halbkreis – mit der offenen Seite zum Backlog, welches entweder in analoger Form auf einer Tafel oder in digitaler Form mit dem Beamer an die Wand projeziert wird. Es dient dem kurzen Austausch über den aktuellen Entwicklungsstand innerhalb des Teams. Ziel ist es, den Tag zu planen: welche Themen will ich heute angehen? Bei welchen brauche ich noch Zuarbeit? Was bekomme ich noch fertig heute, bei welchen Tickets brauche ich länger? Gibt es irgendetwas wichtiges, auf das ich meine Teammitglieder hinweisen möchte?

Nachdem wir diese ganzen Diskussionen hinter uns gebracht haben, geht es wieder zurück an den Arbeitsplatz.

Zurück am Platz – endlich programmieren!

Endlich zurück am Platz, blinkert schon wie wild der Jabber-Client. Och Mensch, da braucht wieder jemand aus dem anderen Bereich Zuarbeit. Nun gut – nach fünf maligem fragen aufgrund von schwammiger Erklärun und mehrmaliger spontaner Abwesenheit des gegenüber nehme ich eben kurz den Telefonhörer in die Hand. Rufe ihn an. Die Sache ist in zwei Minuten geklärt. Endlich. Programmieren!

Also die IDE geöffnet, nochmal kurz mittels eines git pull die Arbeitskopie aktualisiert. Browser geöffnet, Refresh gedrückt. BAM. Error 500. Wer war’s? Natürlich keiner. Spitze. Also nun push-History nachschauen und einzeln prüfen, woher der Fehler kommt? Oder lieber gleich fixen? Ich entscheide mich für zweiteres. 20 Minuten später ist das Problem gelöst. Der Quellcode eingecheckt, alle anderen können wieder arbeiten. Es ist Mittagspause.

Zurück am Platz – endlich programmieren!

Nun beginnt der eigentlich spannende Teil des Tages: jetzt habe ich eine funktionierende Arbeitsumgebung. Alle Mails sind abgefrühstückt. Gegessen habe ich. Los geht’s!

Nach ungefähr 45 Minuten werde ich unterbrochen. Eine Projektmanagerin steht neben mir. Sie will den Stand des Features wissen. Ich sage ihr, dass ich heute wohl das gröbste schaffe und wenn nichts dazwischen kommt, werde ich das Feature morgen finalisieren und es an die Testabteilung geben. Das stellt sie soweit zufrieden. Sie verlässt das Büro. 10 Minuten später steht mein Scrum-Master neben mir und fragt nach, seit wann ich solche kurzfristigen Termine herausgebe. Verwirrt frage ich ihn, was er meint – die Projektmanagerin stand bei ihm am Tisch und wollte ein Release für morgen haben. Sie meinte, das Feature sei morgen fertig hätte ich gesagt. Nachdem ich ihm die Situation erklärt habe, wird er nun der Projektmanagerin den Wind aus den Segeln nehmen müssen. Ich programmiere weiter.

Mittlerweile bin ich tatsächlich zwei Stunden ungestört gewesen, als sich ein weiterer Kollege meldet. Er benötigt Hilfe. Wir setzen uns zusammen an seinen Platz und tauschen Wissen aus, begeben uns auf Fehlersuche. Die Zeit vergeht – wir finden den Fehler und können ihn eliminieren. Wir schreiben ein weiterführendes Ticket – unsere Hack-artige Lösung muss dringend durch etwas Hand- und Fußfestes ersetzt werden. Das Ticket wird wohl (so wie die 25 anderen der letzten 14 Tage) im Nirvana verschwinden.

Als ich wieder an meinem Arbeitsplatz sitze, pingt mich ein Kollege an – er macht für heute Feierabend, hat aber noch ein Ticket fertiggestellt. Ich solle mir seinen Quellcode anschauen und ein Code-Review anfertigen, damit die Tester morgen direkt mit den manuellen Tests starten können. Da das Code-Review Teil meiner Arbeit ist, verspreche ich ihm das Ganze heute noch durchzuziehen – er bedankt sich, wünscht einen schönen Feierabend. Ich wünsche das gleiche, beginne direkt mit dem Code-Review. Meine zwei kleinen Anmerkungen passe ich direkt selbst an, schiebe das Ticket auf coding finished und gebe es an die Testabteilung weiter. Per eMail benachrichtige ich meinen Kollegen noch darüber, dass ich zwei kleine Anpassungen durchgeführt habe – das Review sonst aber gut aussah. Aus der Bahn sendet er mir eine Antwort-eMail und bedankt sich.

Mittlerweile ist es Abend. Nach drei Stunden Programmierung und der sonstigen „Daily Routine“ verlasse ich das Büro. Geschafft habe ich wie immer gefühlt nichts, was in meiner Ticketliste stand. Zu tun hatte ich dennoch ordentlich. Morgen werde ich mir direkt meine großen Kopfhörer aufsetzen. Vielleicht bin ich dann ungestört und kann das Feature fertigstellen …