… of a Software Developer. Neulich habe ich in meinem Artikel Was machen eigentlich IT-Influencer? erörtert, dass niemand zeigt wie so ein Arbeitsalltag als Softwareentwicklerin wirklich aussieht. Klar, das ist schon alleine wegen Verschwiegenheit und Datenschutz schwer. Dann aber dachte ich mir auch: ok, ich probiere es mal. Datenschutz und Verschwiegenheit gilt aber natürlich auch für mich.

Damit man sich die Umstände etwas besser vorstellen kann: ich bin Senior Softwareentwicklerin und Führungskraft in einem Unternehmen, das Consulting-Leistungen anbietet. Das heißt ich arbeite immer begrenzt auf eine bestimmte Zeitspanne in Projekten für Kundenunternehmen, denen ich meine Erfahrung und Fachkraft anbiete. Consulting eben. Ich programmiere also (meistens) nicht für die Firma, in der ich arbeite, sondern für Kunden, die einen Vertrag mit meiner Firma haben. Und diese Woche habe ich einen Arbeitstag von mir zusammengefasst. Willkommen bei den Devs.

7:00 Uhr „Morgenstimmung“

Guten Morgen! 😊Ich habe gefrühstückt und bin einigermaßen kameratauglich, falls wer anruft. Heute arbeite ich aus dem Home Office. Neben mir steht ein (Rest) Milchkaffee und ein Snack für Zwischendurch.

Typischerweise startet der Arbeitstag mit dem Blick in den Kalender. Außer einem großen Projekt-Blocker und einem Personalgespräch bin ich heute relativ frei. Dann starte ich alles, was ich zum Programmieren brauche – eine IDE, meine Versionsverwaltung, meine Tools zur Containerisierung. Ist alles online und geladen, kann es losgehen. Währenddessen wollen ein paar Nachrichten von gestern Abend im Chat und per Email beantwortet werden. Danach programmiere ich ca. eineinhalb Stunden. Hauptsächlich schreibe ich heute Tests. Was bedeutet das?

Wenn man (so wie ich) gerade was programmiert hat, sollte man auch die entsprechenden Tests zum Code schreiben. Damit meine ich automatisierte Tests, die auch programmiert werden müssen. Die werden dann automatisch in regelmäßigen Abständen ausgeführt und sollen sicherstellen, dass das Programm („der Code“) jederzeit ein bestimmtes Verhalten einhält. Nämlich das Verhalten, was ich zuvor neu hinzugefügt habe. Tests sollen sicherstellen, dass es „richtig funktioniert“ sozusagen. Ein (abstraktes) Beispiel wäre: wenn Nutzende Daten eingeben, die falsch sind, dann muss eine bestimmte Fehlermeldung angezeigt werden.

Kommen jetzt beispielsweise Entwickelnde nach mir und machen was am Code, sehen aber, dass dieser Test fehlschlägt, dann wissen sie: „Achso. Da gab es also mal die Anforderung, dass das so und so gemacht werden muss und danach dieses und jenes passieren muss“ und klären dann mal, warum ihre Änderungen das nun kaputt machen. Haben sie was falsch gemacht? Braucht man die Fehlermeldung nicht mehr? Wie ist denn dann das gewollte Verhalten? Das ist ein einfaches Beispiel. Und nicht das, was ich gerade abtesten muss. 😉

Meine Tests sind heute aber ähnlich einfach und die Aufgabe daher entspannt und vielleicht sogar ein bisschen langweilig gegen Ende. Ist nicht immer so. Aber ich mag diese Vormittage, in denen ich fokussiert meiner Aufgabe nachgehen kann, die Sonne scheint inzwischen ein bisschen in das Zimmer, der Kaffee ist alle und die Meetings fangen gleich an.

9:00 Uhr „Daily“

Unser Team arbeitet nach einem agilen Framework, genauer Scrum. Das sieht vor, dass man einmal am Tag zu einem solchen „Daily Meeting“ zusammenkommt, um zu berichten wie man mit den Aufgaben vorankommt. Hat irgendwer irgendwo Probleme? Gibt es Fragen von den Entwickelnden an unsere fachlichen Ansprechpartner:innen beim Kunden? Sowas halt. Weil wir ein verhältnismäßig großes Team sind, brauchen wir dafür meist tatsächlich eine halbe Stunde.

Ich berichte, dass ich die Tests schreibe und damit vermutlich heute fertig werde. Ein Kollege erwähnt, dass er in einer meiner Lieblingsservices (Service = Teil der Software) etwas fertig hat, das eine Code Review benötigt. Weil ich in den letzten Monaten vorrangig an diesem Service gearbeitet habe, höre ich da indirekt meinen Namen und weiß, dass ich mir das anschauen werde. Wenn’s klappt noch heute. Ein anderer Kollege will auch wissen, worum es da geht. Wir machen uns aus am Nachmittag gemeinsam darüber zu telefonieren.

9:30 Uhr „Was mache ich mit einer Stunde Fokuszeit?“

Das ist die Zeitspanne bis zum nächsten Meeting und ist tatsächlich nicht viel. 🤔 Lohnt es sich, sich jetzt nochmal tief in den Code zu begeben? Ich muss allerdings eh erstmal Stretching machen. Ich mache ca. 10 Minuten Dehnungen auf der Sportmatte, die hier rumliegt und entkrampfe Nacken und Rücken. Lasse ich das ein paar Tage weg, bekomme ich das zu spüren. Außerdem gehe ich fix mein Obst schnippeln. Die Zeit hänge ich hinten ran.

1h fokussiert arbeiten … klingt nicht viel!? Ja so fragmentarisch sind meine Tage und die meiner Kollegen und Kolleginnen üblicherweise schon. Die produktivste Zeit ist tatsächlich für mich fast jeden Tag vor um 9 und ggf. nochmal nachmittags, wenn es dort zusammenhängend ein paar Stunden meetingfrei gibt. Damit will ich nicht sagen, dass die Meetings sinnfrei sind – die haben natürlich alle eine Bewandnis. Ich schreibe jetzt weiter meine Tests. Heute kann ich euch nichts spannenderes berichten. Aber ich dürfte aus Gründen des Datenschutzes, der IT-Security und der Verschwiegenheit eh nicht, also … 😉

Hin und wieder poppt für mich ein Reminder meines Mail- und Kalenderprogramms auf, dass mich informiert, dass in 15 Minuten bzw. „jetzt“ ein Meeting startet. Das nehme ich meist als Anlass, um meine Sitzposition zu verändern. Im Home Office habe ich eine Drei-Positionen-Lösung: sitzen, stehen oder „Mittelding“ mit Hocker/Stehstütze. Ich brauche das … .

10:30 Uhr „Refinement“

Im Refinement refinen (=verfeinern) wir Storys (=Aufgaben). Das heißt wir lesen die aufmerksam durch, stellen Fragen dazu und ergänzen alles, was in der Aufgabenbeschreibung fehlt oder unkonkret ist. Idealerweise verfeinert man so lange bis alle ein Verständnis von den Storys haben und diese bearbeiten könnten. Das geht manchmal super fix und manchmal (so wie heute) brütet man schon mal etwas länger daran. Man schreibt auch eine Schätzung der Komplexität an die Story, damit man später mal weiß wie aufwendig die Umsetzung wird.

Heute ist vieles aus dem Service dran, an dem ich derzeit am meisten arbeite, weswegen es besonders spannend für mich ist. Aber mitdenken lohnt sich natürlich bei allen Aufgaben. Selbst wenn man annimmt, dass die bei jemandem anderen landen werden. 😅 Da wir ehrlich sind … jede:r hat eine/n Lieblingsservice/-aufgabe.

12:00 Uhr „Mahlzeit“

Meine Mittagspause ist eher kurz, wenn ich im Home Office bin. Ich schnappe in der Küche mein Essen, wärme das in der Mikrowelle auf oder auch nicht. Wenn ich im Home Office bin, fehlt etwas das Schnacken mit den Kolleg:innen. Das kompensiere ich mit 20-30 min Fernsehen. Genau das mache ich jetzt. Es läuft eine halbe Folge von Evil Staffel 4. Dazu gibt es jetzt mein Mittagessen. Heute auf der Speisekarte: ein großer Teller griechischer Salat. 🥗

12:30 Uhr „Fokuszeit“

Nun mache ich weiter rum an meinen Unit- und Integrationstests. 👩‍💻 Ich werde endlich fertig und kann einen Pull Request stellen. Was heißt das? Der Code, den man fabriziert hat, wird erstmal zum Mergen (=Einfügen) in den schon bestehenden Codestand angeboten und braucht eine Code Review. Einfach so Mergen gibt es bei uns nicht. Es muss mindestens eine Person angucken und genehmigen. Das ist einfach die Coder-Form der Peer Review. Darüber informiere ich die Kollegen in unserem Chat und das war’s. Ich kann online sehen, ob mein Code formal „ok“ ist, weil wir CI/CD machen. Build-Pipelines mit allerlei nützlichen Checks laufen über meinen Code und auch die Tests und alles sieht gut aus. Bin gespannt, ob die Kollegen was finden. Pipeline sagt Code ist ok. ✔

So, Zeit für eine neue Aufgabe. Ich gucke also bevor ich was Neues anfange, ob es was von den Kollegen zu reviewen gibt. Gibt es wie ich aus dem Daily weiß. Ich gucke das an und erinnere mich, dass wir ja telefonieren wollten, was wir dann auch ad hoc tun. Ein bisschen was habe ich doch anzumerken und der Kollege schaut sich das nochmal an.

Von dieser Fokuszeit hier zwacke ich aber auch eine halbe Stunde für Führungskräfte-Kram ab. ⏲ Ich leite ein kleines Team und habe gleich ein Mitarbeitergespräch. Daher schaue ich nochmal meine Notizen durch, was es zuletzt so für Themen bei meinem Teammitglied gab. Außerdem gehe ich demnächst in den Urlaub und wollte meiner Vertretung noch eine Email mit allen wichtigen Daten schicken. Ich bereite das schon mal vor.

Natürlich sind das „Interna“. Ich stelle diese Zeit selbstverständlich nicht dem Kunden in Rechnung. Daher muss ich selber meine Zeit sehr genau tracken. ☝ Ich mache das u.a. durch eine einfache Excel-Tabelle. Früher habe ich auch eine App für Zeittracking benutzt. Die war mir aber zu unflexibel und ich bin zurück zur Excel-Tabelle. Außerdem markiere ich meine unterschiedlichen Aufgabengebiete im Kalender mit jeweils anderen Farben. Es gibt gute Wochen und dann gibt es „andere“ Wochen… . Und ja, jeder gefärbte Block steht für ein Meeting oder einen Blocker, indem ich was spezifisches zu einer bestimmten Zeit machen muss.

14:30 Uhr „Mitarbeitergespräch“

Ein Mitarbeitergespräch eben. Wir tauschen aus, was es Neues gibt, wie es im Projekt läuft und klären ein paar Themen, die neulich aufschlugen. Hat mein Mitarbeiter Fragen oder spezifische Themen mitgebracht? Ja, ein paar. Wir besprechen das und gehen dann die Jahresziele durch. 😊

15:30 Uhr „Kaffeerunde“

Weil unser Team verteilt arbeitet und es gut für die Stimmung ist, erlaubt man uns vier Mal die Woche ein halbstündiges Coffee Break Meeting zu machen. Wir sitzen halt wild verteilt in Deutschland und kommen eher selten alle zusammen. Für die Stimmung und das Miteinander tut es aber viel, wenn man diese typischen Kaffeeküchengespräche hat („Wie gehts? Was macht das Leben? Wie war dein Wochenende?“) Wenn man verteilt arbeitet, gibt es keinen klassischen Zeitpunkt dafür, während sich das im Büro automatisch ergibt. Wir haben uns den Zeitpunkt geschaffen und es ist zwangsläufig auch ein Online-Meeting. Wer keine Zeit hat, wählt sich meist eh nicht ein. Meist sind wir stabile 3-5 Personen von eigentlich knapp über 10 Menschen.

Ich finde das echt cool vom Projekt – es ist für uns Projektzeit. Manchmal besprechen wir tatsächlich nur welche Serien wir gerade schauen oder wie unser Tag bis jetzt war. Aber es geht eigentlich auch immer irgendwie um unsere Aufgaben. Ob ein Umsystem down war, gerade was nicht geht, welche Probleme wir hatten. Also lohnt es halt auch (aus Projektsicht, nicht nur menschlich). Für unsere Stimmung tut das auf jeden Fall viel.

16:15 Uhr „Feierabend“

Nach der Kaffeerunde beantworte ich noch ein paar Chatnachrichten. Tja, und dann schließe ich alle meine Programme. Riskiere nochmal kurz einen Blick, ob morgen was besonders ansteht. Ich beschließe, dass ich morgen ins Büro fahre. Jetzt erstmal offline gehen, alles zuklappen und nochmal Dehnen gehen. Das war’s: a day in the life … .

Tatsächlich war das heute für mich ein „ruhiger“ Tag, weil ich so wenige Meetings hatte. Überrascht? Ansonsten habe ich durchschnittlich mehr. Dabei dachten früher immer alle Softwareentwickler:in sein wäre ein unsozialer Beruf. 😉 Wie sieht ein Tag in eurem Arbeitsleben aus? Hat euch irgendwas an meinem überrascht oder hättet ihr euch das genau so vorgestellt?

Netzgeflüster ist eine Kategorie meines Blogs in der ich mich immer zwischen dem 10. und 15. eines jedes Monats Themen aus IT, Forschung, Netzwelt und Internet widme genauso wie Spaß rund um die Arbeit mit Bits und Bytes. 🙂