Produktiver Mentor und Systemautomatisierer

Jonathan: Hallo zusammen und willkommen zum Exercism Community Podcast. Ich habe das Privileg, mit Isaac zu sprechen. Er ist einer unserer Maintainer und Contributors und hat in letzter Zeit sehr vielen Lernenden in unseren GoHorts, unseren Lern-Kohorten, einiges an Mentoring gegeben. Die haben wir 30 Tage lang laufen lassen, inzwischen glaube ich zweimal, vor allem zu Go und Elixir. Und Isaac hat beim Go-Track mitgeholfen, was großartig war. Isaac, ein herzliches Willkommen. Erzählst du mir ein bisschen, wo du zu Hause bist, woher du kommst und wie du zur Technik gekommen bist? Isaac: Ja, ich lebe in Kalifornien. Ich wohne in San Jose, Kalifornien. Die ehrliche Wahrheit ist: Ich bin zur Technik gekommen, weil mein älterer Bruder in der Technik war, und ich habe alles gemacht, was er gemacht hat. Ich hatte eine ganze Menge Geschwister. Wir sind gern miteinander abgehangen, oder manche von uns hingen lieber mit den einen zusammen als mit den anderen. Ich hatte einen älteren Bruder, mit dem ich sehr gern abhing. Er fand es nicht unbedingt genauso toll, mit mir abzuhängen, aber ich bin ihm die ganze Zeit hinterhergelaufen und wollte tun, was auch immer er tat. Er hat sich mit etwa 15 ein „C for Dummies“-Buch geschnappt, das im Haus herumlag, und ich war damals, wenn ich mich richtig erinnere, 9. Er hat also C geschrieben, und ich so: Wenn er das macht, dann mache ich das auch. Meine Programme waren in dem Alter ziemlich einfach und basic. Es war eher so: Wie heißt du, hallo Bob, solche Übungen. Sie waren nicht übermäßig komplex. Irgendwo muss man ja anfangen. Also fing ich da an. Ich dachte: Oh, man kann dieses Steuerzeichen ausgeben, und es macht ein Geräusch. Das ist so cool. Ich habe ein Programm geschrieben, das buchstäblich nur ein \a ausgibt. Aber ich habe mit 9 angefangen. Ich habe C-Programme geschrieben. Wir hatten eine alte Windows-3.1-Maschine, die in DOS bootete, und mein Bruder hatte ein Batch-Skript eingerichtet, das beim Start des Computers ein Menü anzeigte, in dem man auswählen konnte: Windows starten, Spiele starten, es gab so ein Spielmenü. Man konnte 5 tippen für Warcraft oder was auch immer. Also schrieb ich Batch-Skripte, als wir andere Spiele installiert hatten und so weiter. Von da an ging es nur noch bergab. Mein Bruder ging für Computer Engineering an die Uni, und wieder dachte ich: Wenn er das macht, mache ich das auch. Ich habe also mit 9 angefangen, C zu schreiben. Ich habe in der Highschool Visual Basic 6 geschrieben. Ich hatte einen Palm Pilot, auf dem ich in der Highschool verschiedene Programme geschrieben habe. Mein Mathelehrer war richtig cool. Ich war an einer von diesen alten Schulen... Jonathan: War das so eine Art, erinnerst du dich, sie haben versucht, so etwas wie das Ding vor dem iPad rauszubringen, und so ein paar Leute haben es bekommen, und es hatte dieses kleine Stift-Gekritzel. Und alle fanden es supercool, weil es rauskam und dann zisch, und dann konnte man drauf rumtippen. Es war so, es hat nicht... Ich erinnere mich immer daran, weil dann das iPad rauskam und alle so dachten: Ah, ein bisschen zu früh. Der Pilot war einfach dieses bisschen, ein bisschen seiner Zeit voraus, weißt du, was ich meine? Isaac: Es war ungefähr ein Jahrzehnt lang großartig, aber ja, es gab dieses Palm Graffiti, mit dem man eingegeben hat. Es gab ein kleines Eingabefeld, und man musste Zeichen schreiben, die aber so ein bisschen auf dem Alphabet basierten. Das A war einfach ein Dreieck und das F so ein rechter Winkel. Ja, mein Highschool-Mathelehrer meinte: Hey, wenn du das Programm schreibst, ist es cool, wenn du es im Test benutzt. Ich habe also in der Highschool Palm-Pilot-Programme geschrieben, was wirklich cool war. Ich ging für Computer Engineering an die Uni. Da redeten Leute von Skriptsprachen. Ich wusste nicht so richtig, was das war, also habe ich mir zufällig Perl geschnappt. Und dann bin ich nach dem Aufbaustudium zu Google gekommen. 2013 haben sie mich von der Ostküste nach Kalifornien geholt. Und da habe ich vor etwa einem Jahrzehnt Python gelernt. Und Python ist seit zehn Jahren meine Hauptsprache. Ich war bei Google, also ist mein Stil stark vom Google-Stil geprägt. Deshalb schreibe ich hauptsächlich so. Und dann, vor etwa vier Jahren, ich glaube 2018, hat Google intern angefangen, die Sprache Go zu pushen, und da habe ich Go gelernt. Jonathan: Cool. Und Isaac, wenn du von Google-Stil sprichst, gab es da so ein festes Gefühl von „So ist es richtig“? Oder ist das eher... Wie war das, erzähl mal ein bisschen mehr, weil das ist interessant. Isaac: Codestil ist nicht unbedingt die richtige Art, es zu machen, sondern eher eine einheitliche Art, die alle machen sollen. Man sagt, ein guter Kompromiss oder ein gutes Geschäft ist eines, bei dem niemand glücklich ist. Niemand ist so richtig zufrieden mit dem Styleguide, aber solange alle ihn befolgen, sieht der Code einheitlich aus. Das heißt, jeder kann sich irgendein Stück Code aus der Google-Codebasis schnappen und Änderungen vornehmen, und solange alle dieselben Style-Richtlinien befolgen, ist der Code überall einheitlich. Du musst nicht denken: Oh, diese Codebasis nutzt Vier-Leerzeichen-Einrückung und diese hier zwei, oder hier gilt diese Namenskonvention und da jene. Alles in der gesamten Codebasis wird gleich gemacht. Niemand ist mit irgendwas davon glücklich. Jeder hat seine Bereiche, in denen er es gern anders hätte, aber da es einen dokumentierten Styleguide gibt, der öffentlich zugänglich ist, kannst du einfach nach dem Google Python Style Guide googeln, und da steht drin, wie wir bei Google Code schreiben. Solange alle sich an diesen Guide halten, sieht der Code sehr einheitlich aus. Das ist wirklich schön: Du kannst jede Codebasis öffnen, und es gibt keine Überraschungen, kein „Oh, das würden sie anders schreiben“. Jonathan: Ist das vielleicht der Grund, warum Go so gut in diesen Kontext passt? Weil es formatiert ist und wirklich so: So ist es. Man sieht definitiv den Google-Einfluss. Isaac: Ja, ich weiß nicht, wie stark Rob Pike vom Google-Ansatz beeinflusst war oder wie stark er den Google-Ansatz beeinflusst hat. Ich bin nicht sicher, was zu was geführt hat, aber Go treibt das definitiv auf eine andere Ebene, wo... Es gibt sogar noch mehr, also bei Python gibt es verschiedene Stile und Leute passen ihre Linter an, um verschiedene Dinge zu akzeptieren. Google zum Beispiel nutzt intern in Python Zwei-Leerzeichen-Einrückungen, weil viel Code tief verschachtelt ist und sie keine riesige Wand aus Leerzeichen wollen. Extern nutzen die meisten vier Leerzeichen, und das steht so in der Python-Dokumentation. Aber bei Go haben sie das einfach auf eine andere Ebene gebracht und gesagt: Die Sprache selbst hat nur eine Formatierung. Es gibt nur einen Weg zu formatieren. Es gibt keine Online-Debatten darüber, was der richtige Weg ist. Es gibt nur einen. Jonathan: Das spart eine verdammte Menge Hin und Her. Sagen wir es einfach so. Ja, das ist gut. Isaac: Ja. Jonathan: Okay. Also, als du bei Google angefangen hast, hattest du da nie Python gemacht oder hattest du schon ein bisschen reingeschnuppert, oder war das ein leichter Sprung? Wie... weil du es so klingen lassen hast, als hättest du den Job bei Google bekommen und dann hieß es: Okay, cool, lern Python, los geht's. Isaac: Das stimmt. Ich glaube, bevor ich zu Google kam, habe ich nie Python geschrieben. Ich habe ein oder zwei Jahre Perl geschrieben. Ich schätze, zu dem Zeitpunkt waren es ein paar Jahre, in denen ich Perl schrieb. Mein erster Sommerjob. Das ist eine ganz andere Geschichte. Ich habe sechs Jahre vor meinem Wechsel zu Google angefangen, Perl zu schreiben, also habe ich damals schon einiges an Perl geschrieben. Ich habe ein bisschen Bash geschrieben, war also mit Skriptsprachen vertraut. Aber Python hatte ich noch nie geschrieben. Aber wenn man sich mit genug Sprachen beschäftigt hat... Die Lernkurve ist etwas flacher, wenn man eine weitere Sprache lernt, weil man die meisten Konstrukte schon gesehen hat und es nur eine etwas andere Syntax ist, ein etwas anderer Werkzeugkasten. Aber es ist viel vom alten Zeug, nur leicht anders, anders geschrieben. Die Konstrukte sind meist ziemlich ähnlich. Wenn man also vier Sprachen gelernt hat, ist die fünfte so: Oh, das ist nur etwas anders geschrieben. Jonathan: Ja, ja. Das ist interessant. Jetzt hast du vorhin ein bisschen gekichert über deinen ersten Job, so aus der Highschool raus. Also, war es bei dir immer so: Ich werde im Engineering-Bereich sein, ich werde das mit den Computern machen? War das immer ein bewusster Gedanke, oder war es immer so: Das ist einfach der Ort, an den ich natürlich passe, und es macht mir Spaß, und das war's? Wie war das so... Isaac: Ich schätze... Ich habe sehr versucht, in die Fußstapfen meines Bruders zu treten. Er ging in Computer Engineering. Er hat angefangen zu programmieren, als ich ein Kind war. Ich bin mitgelaufen. Ich habe programmiert, seit ich klein war. Er ging in Computer Engineering, und da war es dann so: Ich wollte dasselbe machen wie er, und außerdem hatte ich richtig viel Spaß am Programmieren und so. Also wusste ich, seit ich auf die Highschool kam, als mein Bruder schon an der Uni war, dass ich dort landen wollte. Jonathan: Er ist ein paar Jahre älter als du, es klingt also, als hätte er dich als Person massiv beeinflusst. Wie viele andere Geschwister hast du noch? Oder war er in deinen Augen das Nonplusultra? Isaac: Ich habe acht Geschwister, aber er war definitiv derjenige, mit dem ich mich richtig gut verstanden habe. Er ist einer von... ich schätze, mit manchen verstehe ich mich besser als mit anderen. Wenn man acht hat, gibt es immer eine Bandbreite. Mit ihm habe ich mich ziemlich gut verstanden. Wir denken oft sehr ähnlich. Wir haben oft ähnliche Interessen. Wir haben ständig über Computer gefachsimpelt. Tun wir immer noch. Seine Frau mag es nicht, wenn das die Tischkonversation beim Abendessen wird. Sie so: Keine Arbeit am Esstisch. Wir fachsimpeln einfach die ganze Zeit über Programmieren und reden ständig darüber. Es ist wirklich schwer zu sagen, wie viel davon einfach ich war, der ihn nachahmen wollte, und wie viel einfach ähnliche Interessen. Wir haben heute definitiv ähnliche Interessen. Ich weiß nicht, wie viel davon Veranlagung und wie viel Erziehung ist. Ich kann nicht wirklich sagen, wie viel davon ich ihn nachahme und wie viel einfach ähnliche Interessen sind. Aber da ich von früh an in seine Fußstapfen getreten bin, bin ich ihm gefolgt, und er hat gewissermaßen den Weg vorgegeben, und ich bin ihm gefolgt. Jonathan: Ja, das ist richtig cool. Und wo ist er jetzt? Nur aus Interesse, ist er an der Ostküste? Isaac: Er ist immer noch an der Ostküste, er arbeitet in der Tech-Branche. Wir haben kurz bei derselben Firma gearbeitet. Jonathan: Ja, okay, cool. Das gibt es also. Cool. Ich wollte nur mal fragen. Jetzt eine der Sachen... Du warst also richtig involviert in der Kohorte, die wir gerade hatten. Also in der neuesten Lern-Kohorte, besonders mit Go, wir haben 30 Tage lang was mit Go gemacht. Wie... und dein Engagement bei Exercism war vorher eher speziell im Maintainen, aber auch ziemlich viel im Mentoring, soweit ich verstehe. Wie hast du diese Aufteilung erlebt? Also, wie bist du überhaupt auf Exercism gestoßen, und welche verschiedenen Aspekte macht es dir Spaß, dazu beizutragen? Isaac: Ich bin ursprünglich auf Exercism gestoßen, weil ich versucht habe, Haskell wieder zu lernen. Ich habe bei Google einen Haskell-101-Kurs gemacht, der ziemlich Spaß gemacht hat. Und dann dachte ich: Oh, ich sollte mehr Zeit damit verbringen. Und dann ist es eingeschlafen. Und dann habe ich versucht, wieder einzusteigen. Jonathan: und wir sehen uns beim nächsten Mal. Isaac: Bei jeder Sprache finde ich, dass der einfachste Weg, sie zu lernen, ist, sie tatsächlich zu schreiben. Der einfachste Weg, sie zu schreiben, ist, einen Zweck dafür zu haben. Ich habe keinen großartigen Zweck gefunden, Haskell zu schreiben, was es sehr schwer gemacht hat, wieder reinzukommen. Aber ich habe Exercism entdeckt und dachte: Oh, das könnte mir helfen, mehr Haskell zu schreiben. So bin ich ursprünglich auf Exercism gestoßen. Einmal dort, dachte ich: Oh, es gibt einen Python-Track und einen Haskell-Track und ein paar Übungen hier drin. Und dann ging es in den Kaninchenbau. Jonathan: Und schon ging es in den Kaninchenbau. Isaac: Ja. Ich habe angefangen, Übungen in Python zu lösen. Ich habe angefangen, Übungen in Bash zu lösen. Ich habe ein paar der Go-Übungen gemacht. Als der Go Hort aufkam und ich mir einige meiner früheren Lösungen ansah, sah ich, dass viele davon drei Jahre zuvor eingereicht worden waren. Ich habe mich also 2019 zum ersten Mal für den Go-Track angemeldet und damals einen Teil dieser Übungen gelöst. Und ich mache inzwischen seit einem Jahrzehnt Python. Ich fühlte mich also relativ wohl dabei, als Python-Mentor einzusteigen, und damit verbringe ich heutzutage die meiste Zeit bei den Übungen. Und dann habe ich angefangen, PRs, Pull Requests, an den Python-Track zu schicken, weil es Dinge gab, die nicht passten. Und dann habe ich mich im Bash-Track engagiert. Ich bin nicht ganz sicher, wie das passiert ist, aber aus dem Einreichen von Korrekturen am Bash-Track wurde, dass ich Bash-Maintainer bin. Jonathan: Einfach so. Ich meine, es ist genau so: Pass auf, worauf du dich einlässt, oder? Isaac: Ja, und dann hat Glenn den Ock-Track aufgebaut, und ich dachte: Oh, ich kenne Ock, ich mag Ock, lass mich auf den Zug aufspringen. Ich habe also mitgeholfen, die Übungen im Ock-Track aufzubauen. Ich bin nicht ganz sicher, aber ich glaube, als ich vor drei Jahren die Go-Übungen gesehen habe, habe ich den ganzen Track abgeschlossen, und dann meinte einer der Mentoren: Oh, du hast alle Übungen geschafft, vielleicht solltest du Mentor werden. Ich bin nicht gut genug, ich schreibe Go nicht oft genug und regelmäßig genug, um mich beim Mentoring wohlzufühlen. Ich war also nicht wirklich Go-Mentor. Aber als ich dann zum Go Hort kam und es eine Menge Leute gab, die Mentoring wollten, dachte ich: Oh, ich könnte mich ja für einen Monat als Mentor anmelden und mithelfen. Aber tatsächlich bin ich vor Kurzem selbst als Lernender in den Go Hort eingestiegen. Und dann bin ich sozusagen aus dem Lernenden-Bereich rübergewechselt, schätze ich. Jonathan: Und dann bin ich sozusagen aus dem Lernenden-Bereich rübergewechselt, schätze ich. Pass auf, worauf du dich einlässt. Ich sag's dir, da scheint sich ein Muster abzuzeichnen: Du meldest dich für eine Sache an und landest am Ende als etwas anderes, aber das ist wirklich cool. Okay, also: Was die Zeit angeht, in der du Lernende im Go-Track betreut hast, was sind da so die häufigsten Dinge, die du siehst? Ich meine, im Go-Track sind wahrscheinlich ziemlich viele erfahrene Entwickler, würde ich sagen, Leute, die schon eine gewisse Erfolgsbilanz in der Entwicklung hatten. Aber was waren so die Dinge, bei denen du dachtest: Okay, das sind die typischen Sachen, an denen die Leute hängen bleiben? Gab es Muster oder Dinge, bei denen du fandest: Okay, das ist häufig, das taucht ziemlich konstant auf, möglicherweise? Isaac: Ich weiß nicht. Das meiste Mentoring, das ich gesehen habe, betraf Leute mit abgeschlossenen Lösungen. Die Leute haben die Übung meistens schon gelöst, bevor sie zum Mentoring kommen. Die Leute stecken also bei den meisten Interaktionen, die ich habe, nicht fest. Es ist also meistens so: Sie haben eine Übung erfolgreich abgeschlossen, und dann ist viel des Inputs: Gibt es einen effizienteren Weg, das zu machen? Gibt es einen besseren Algorithmus? Eine der häufigen Sachen, die viel zu oft auftaucht, ist der Aufbau von Strings in Sprachen wie Go und Python, wo Strings unveränderlich sind. Da ist es nicht sehr effizient, viele Strings aneinanderzuhängen. Also heißt es oft: Hey, du könntest das mit einem Array aufbauen und die Strings dann zusammenfügen, oder du kannst in Go einen String Builder verwenden. Es geht also viel darum, sie in Richtung besserer Muster, Best Practices und Patterns zu schubsen. Danke fürs Zuschauen. Jonathan: Okay, cool. Das ist faszinierend. Jetzt, aktuell: Wie sieht dein Alltag bei der Arbeit aus, was die Frage angeht, wo die Entwicklung reinpasst? Du bist ja schon eine Weile in der Tech-Branche, wie sieht der Tag aus? Was sind die Herausforderungen? Was sind die Teile, die dir an deiner Arbeit gerade Spaß machen? Isaac: Ich bin in der Rolle Site Reliability Engineering, was grob ähnlich zu DevOps ist. Da steckt auch ein bisschen Sysadmin-Zeug drin. Ich trage seit etwa einem Jahrzehnt in einer Bereitschaftsrotation einen Pager. Mein Alltag hängt also stark davon ab, ob ich gerade Bereitschaftswoche habe oder nicht. Wenn ich Bereitschaft habe, geht es viel darum, den Pager im Auge zu behalten, es gibt eine Ticket-Queue, eine Support-Queue, und darum, sicherzustellen, dass fehlschlagende Prozesse oder Probleme diagnostiziert und behoben werden. Das ist ungefähr eine Woche von sechs, oder je nachdem, wie groß das Team gerade ist. Und die restliche Zeit bin ich in Bereitschaft. Jonathan: Mm-hmm. Isaac: Ich verbringe viel Zeit damit, mit Automatisierung herumzuspielen. Es geht also viel darum, Prozesse zu identifizieren, die umständlich sind, und sie weniger umständlich zu machen. Es kann sein, dass... Es mag einen Grund geben, dass es passiert, aber generell finde ich: Wenn dieses Problem auftritt, müssen wir, sagen wir, manuell reparieren, indem wir diese Befehle und jene Befehle ausführen, und dann denke ich: Warum führen wir diese Befehle von Hand aus? Können wir ein Python-Skript schreiben, das das alles für dich macht? Oder können wir die Tools verbessern, damit sie nicht fehlschlagen und das Problem selbst abfangen? Und viel davon ist einfach der Versuch, den Alltag des Systembetriebs so zu verbessern, dass Menschen weniger involviert sind oder nicht mehr so tief involviert sein müssen, damit alles reibungslos läuft. Jonathan: Macht dir dein Tag Spaß, also das Suchen nach diesen kleinen Bereichen, wo man optimieren kann? Wie viel deines Jobs ist Reagieren auf Dinge, und wie viel davon ist, aus der Reaktion heraus zu denken: Oh cool, das ist eine Gelegenheit, und dann proaktiv nach diesen kleinen Bereichen zu suchen? Wie ist die Balance normalerweise? Isaac: Ich mag Automatisierung, das ist wahrscheinlich das, was mir an meinem Job am meisten Spaß macht: Dinge automatisieren zu können. Es ist nicht immer reaktiv. Ich meine, reaktiv kann heißen, dass etwas kaputtgeht, es kann aber auch heißen: Oh, Leute führen diesen Befehl aus, und ich habe festgestellt, dass wir diesen Befehl ständig kopieren und einfügen, kann ich das verbessern? Oder ich sehe, dass jemand irgendwo ein Runbook ändert oder irgendwo einen Befehl verbessert, und dann denke ich: Oh, der Befehl ist ziemlich unordentlich, kann ich den einfach von Grund auf neu schreiben? Und natürlich ist Aufmerksamkeit zu viel, sie muss mit Anreiz ausbalanciert werden, es muss weniger große Worte sein, eine bessere Sprache, all das Zeug. Da muss man drüber wegkommen, indem man es einfach versucht. Ehrlich gesagt, alles in meinem Job passt eigentlich, wenn ich so darüber nachdenke. Ich bin ein sehr motivierter Mensch, also nein, mein Job ist, glaube ich, überall dabei, aber in jedem Job, den ich liebe, schlage ich für mich Zeit tot, er ist nur da, um zu versuchen... Jonathan: Fabrikarbeit, könnte man sagen. Isaac: Refactoring, zu bemerken, dass es Tools gibt, die umständlich zu benutzen sind, und zu beschließen, sie neu zu schreiben oder Wrapper darum zu bauen. Ich sehe zum Beispiel Änderungen an einem großen, komplizierten Programm und denke: Oh, das Programm ist ein Durcheinander. Kann ich reingehen und das neu schreiben oder refactoren? Oder ich baue neue... Ich meine, es ist nicht immer Refactoring, es ist manchmal auch einfach, neue Tools zu bauen. Es ist wie: Oh, wir haben einen Prozess mit 20 Schritten, packen wir das alles in ein Programm. Vieles davon läuft darauf hinaus, dass ich diese Dinge irgendwie entdecken muss. Manchmal entdecke ich sie, weil mir eine Reihe von Aufgaben zugewiesen wird, und dann denke ich: Ich will die nicht von Hand ausführen. Manchmal entdecke ich sie, indem ich es einfach bemerke: Ich schaue irgendwo etwas Code nach und denke: Oh, dieser andere Code da drüben, den ein anderes Team pflegt, macht Dinge schlecht, lass mich das refactoren oder moderne Bibliotheken benutzen oder so. Jonathan: Also viel... einfach sehen können. Wie viel freie Hand hast du? Hast du ziemlich viel freie Hand, umso herumzugehen und hier und da reinzuschweben und zu ändern? Das muss ziemlich Spaß machen, ziemlich schön sein. Isaac: Mein Manager lässt mir sehr freie Hand, was wirklich schön ist. Ich weiß nicht, wie viel davon daher kommt, ich bin gerade nicht bei Google, aber ich weiß nicht, wie viel davon aus meinem Google-Hintergrund kommt. Bei Google waren die Leute sehr offen dafür, reinzuschweben und zu sagen: Oh, ich habe bemerkt, ich benutze zufällig diese Bibliothek und sie könnte so und so verbessert werden. Lass mich das mal fixen. Ich habe sehr, sehr kurz bei einem Startup gearbeitet, wo die Kultur ganz anders war, viel weniger offen. Und beim Startup waren die Leute sehr beschützend gegenüber ihrer Codebasis, und es wurde nicht gern gesehen, wenn andere ihren Code änderten. Da dachte ich: Oh, mit dieser Codebasis gibt es ein Problem. Wirklich, ändere es mal für... diese Codebasis. Jonathan: Ja, zurückbleiben. Aber das ist interessant, weil... man würde annehmen, dass ein Startup viel eher so ist: Na ja, Hauptsache, der Job wird erledigt, und zwar so billig wie möglich, weißt du. Aber vielleicht konnte Google das als Konzept viel besser handhaben. Und das ist... sorry, ich habe gerade das Licht angemacht, weil wir, gerade kein Licht für alle, die zuhören, in Kapstadt fällt ab und zu der Strom aus. Gerade eben blende ich mich selbst, aber egal. Aber das ist interessant, zurück zu dem Punkt mit der Startup-Kultur und wie Leute ironischerweise viel mehr damit befasst sind, Eigentum an Dingen zu haben, und dadurch vielleicht alles etwas lahmlegen, weißt du? Isaac: Ja, ich weiß nicht, ob ein Startup zu sein unbedingt gut mit einer offenen... es war wie eine spielerische Arbeitskultur. Bei Google war vieles von dem, was Leute taten, Spiel, in dem Sinne, dass ihnen Spaß machte, was sie taten. Sie machen es, weil es ihnen Spaß macht. Sie waren sehr freundlich dabei oder sehr offen. Manche andere Arbeitskulturen sind weniger darauf ausgerichtet, Dinge zu tun, weil sie einem Spaß machen, und mehr darauf: Es ist ein Job, oder das ist mein Code und ich weiß, wie das funktioniert. Ich will nicht, dass andere Leute daran rumfummeln. Ich bin nicht ganz sicher, was dazu gehört, solche Arbeitskulturveränderungen herbeizuführen. Aber Google hat sehr stark das Gefühl gefördert, dass alle Zugang zu all dem Code haben. Ihr seid alle befugt, Änderungen daran vorzunehmen. Macht einfach, was ihr für richtig haltet. Und dann in meinem aktuellen Job gibt mir mein aktueller Manager auch viel freie Hand. Er sagt: Klar, du hast was zum Fixen gefunden, dann fix es. Du hast einen Bereich gefunden, der verbessert werden kann, ich stelle mich dir nicht in den Weg. Sag mir, wie ich helfen kann. Ich kann also vieles von dem, was ich tue, selbst steuern, und wenn ich einen Bereich finde, wo ich denke: Oh, das könnte ich besser machen, dann sagt er: Ja, cool, mach. Jonathan: Okay, schön. Und du, die Firma ist an der Ostküste, habe ich recht? Du arbeitest also tatsächlich remote? Ich glaube, ich erinnere mich, dass du gesagt hast, du wolltest rüberziehen, und dann kam COVID, und das Ganze war irgendwie vorbei. Wie empfindest du das Remote, die Distanz, die Zeitverschiebung, all das? Beeinflusst dich das, oder...? Isaac: Ich vermisse es definitiv, in einem Büro zu sein und mit Leuten persönlich zu interagieren. Das gibt es also. Die Zeitverschiebung, mein Team war sehr entgegenkommend mit dem Zeitunterschied. Ich bin drei Stunden hinter dem Rest meines Teams. Es gibt ein kurzes Daily-Standup, das ich verpasse. Wir haben zwei tägliche Setups für zwei verschiedene Produkte. Das erste verpasse ich, und mein Team war sehr gut darin, mir da entgegenzukommen, und wir nutzen intern viel Slack. Sie sind sehr gut darin, einen täglichen Slack-Thread mit aufgetretenen Problemen zu haben, damit ich auf dem Stand bin. Und wenn sie etwas brauchen, pingen sie mich an. Ich versuche mein Bestes, responsiv zu sein, und erledige das Zeug morgens so schnell ich kann. Es ist also ein bisschen so: Die Zeitverschiebung ist nicht toll, aber es ist auch nicht schlimm, wir haben es ganz gut hingekriegt. Und umgekehrt gibt es die andere Seite: Sie wissen, dass sie jemanden im Team haben, der etwas später wach ist. Ich hatte Kollegen, da war es 18 Uhr an der Ostküste und sie meinten: Oh, das ist kaputt. Hey, Isaac ist an der Westküste, Isaac könnte mir damit helfen, weil es dort erst 15 Uhr ist. Es funktioniert also in beide Richtungen. Ja, und... Jonathan: Ja. Isaac: Ich war... ja, ich habe Google 2019 verlassen, sorry, 2020. Ich habe 2019 interviewt. Ich sollte 2020 im Mai anfangen. Ich hatte geplant, im August umzuziehen, April 2020, aber COVID begann und all das, das Büro wurde geschlossen, und es war viel so: Oh, das Büro ist noch nicht offen, er zieht um, sobald es öffnet. Und dann, zwei Jahre in der Pandemie, fingen sie an, das Büro wieder zu öffnen. Und ich dachte: Weißt du, ich bin mir nicht mehr sicher, ob ich überhaupt umziehen will. New York klang echt aufregend, aber da waren all diese offenen Läden und Veranstaltungsorte und so. Aber jetzt, wo es eine Pandemie gibt, klingt vieles davon nicht mehr ganz so aufregend. Ich bin also nach zwei Jahren Remote-Arbeit auf eine Remote-Stelle umgestiegen. Jonathan: Und bist du so ein Stadtmensch oder Land oder irgendwas dazwischen? Was... denn New York ist Stadt. Das ist zu 100 % Stadt. Ich meine, da gibt es kein Vertun. Weißt du, was ich meine? Das wäre also ein ziemlicher Wechsel gewesen, schätze ich. Ja. Trotzdem aufregend. Isaac: Ich bin in einer großen Metropolregion aufgewachsen, das Stadtleben ist mir also nicht fremd. Aktuell wohne ich im Vorort. Ich mag Wandern und Radfahren und bin so oft wie möglich draußen. Ich wohne also gern im Vorort, in der Nähe von großartigen Wander- und Radwegen und so. Nach New York zu ziehen wäre eine ziemliche Veränderung. Aber ich denke, ab und zu alles auf den Kopf zu stellen, ist nicht schlecht. Und wenn ich mein Leben in New York hasse, ziehe ich einfach wieder weg. Jonathan: So schwer ist das ja nicht. Aber das ist cool. Jetzt verbringst du wahrscheinlich, korrigier mich, wenn ich falsch liege, viel Zeit vor dem Bildschirm, in einem Büro, Homeoffice oder was auch immer. Kommst du jeden Tag raus, so... Wie balancierst du die ganze Bildschirmwelt gegen... hast du so deine tägliche Zeit, wo du sagst: Ich muss raus und einfach nach draußen und was anderes machen? Isaac: Ich wünschte, ich hätte sie. An manchen Tagen, Monaten oder Jahren bin ich besser darin als in anderen. 2020 war ich ziemlich gut darin, fast jeden Tag Rad zu fahren. Die meisten Wochenenden komme ich raus. Ich versuche, einmal pro Woche zu wandern. Ich war nicht großartig darin, aber ich gehe wandern. Es hängt von der Jahreszeit ab. Ich bin in Kalifornien. Manche Wochen sind extrem heiß. Wir hatten gerade eine Hitzewelle mit über 40 Grad Celsius, etwa eine Woche lang. Das macht es schwierig, rauszukommen. Wir sind in Kalifornien, wo es Brände gibt, also gibt es manchmal ein oder zwei Wochen, in denen die Luftqualität draußen nicht ganz sicher zum Atmen ist. Das macht es in Kalifornien manchen Wochen schwierig, draußen zu sein. Und in einer Pandemie drinnen zu sein, ist auch schwierig. Es gibt also definitiv Wochen, in denen ich viel mehr drinnen bin als in anderen. Aber ich mag es, rauszukommen. Ich hatte Phasen von sechs Monaten, in denen ich mindestens jede zweite Woche gewandert bin. Jonathan: und dann. Isaac: Ich hatte Phasen, in denen ich etwa einmal im Monat campen war, sechs Monate am Stück. Es gibt also Phasen, in denen bin ich besser, und dann gibt es Phasen, in denen bin ich einfach zwei Wochen am Stück im Haus. Jonathan: Ja, das ist cool. Und Isaac, was ist der nächste... Vielleicht, ich weiß nicht, vielleicht hast du so weit noch nicht gedacht, aber wie sehen die nächsten fünf Jahre für dich aus? Hast du eine Idee, oder bist du eher so: Ich will mein eigenes Unternehmen gründen oder ich will das machen? Oder bist du einfach so: Ach, ich genieße das Leben und genieße, wo ich bin. Isaac: Bevor ich an die Westküste gezogen bin, dachte ich, ich hätte ein besseres Gefühl dafür, wie meine Zukunft aussehen wird. Aber das alles auf den Kopf gestellt zu bekommen, hat mir gelehrt, dass es wirklich schwer ist, vorherzusagen, was im nächsten Jahr passiert, geschweige denn in fünf. Ich bin recht glücklich. Ich habe vor Kurzem die Stelle gewechselt. Vor etwa zwei, zweieinhalb Jahren. Mein aktueller Job gefällt mir recht gut, ich sehe also nicht, dass sich das bald ändert. Ich wäre gern die nächsten zwei, drei Jahre im selben Job, fünf Jahre weiter. Ich liebe es, in Kalifornien zu leben. Ich liebe es, wandern, radfahren und campen zu können und so. Ich sehe mich also nicht so schnell aus Kalifornien wegziehen. Und ich sehe mich auch nicht so bald aus diesem Job weggehen, weil mir die Arbeit dort ziemlich viel Spaß macht. Ich bin also ziemlich zufrieden und habe keine großen... ich habe keine großen Veränderungen geplant, aber es ist wirklich schwer zu sagen. Jonathan: Das ist cool. Okay, ich habe noch ein paar Fragen, zu denen ich gern deine Perspektive hätte. Die erste ist wahrscheinlich nicht die, auf die ich dich vorbereitet habe, aber die... Wenn du... Wenn zehn Leute jetzt in dein Büro kämen, zehn völlig Fremde, und du wüsstest nichts übers Programmieren, und du hättest so eine Harfenistin und einen Gärtner und was auch immer, was wären die drei wichtigsten Tipps, die du ihnen geben würdest, um mit dem Programmieren anzufangen? Wenn du es darauf runterbrechen könntest: Mach das um jeden Preis, was wären einige dieser Tipps? Isaac: Die wichtigste Empfehlung wäre, ein Problem zu finden, das du mit Programmieren lösen könntest. Du hast also ein konkretes Projekt, das Motivation liefert, ohne ein bestimmtes Ziel vor Augen, das dich vorantreibt. Es ist extrem schwierig, Programmieren zu lernen, ohne... wie bei jeder anderen Fähigkeit braucht das Programmierenlernen ein gutes Maß an Hartnäckigkeit oder Durchhaltevermögen. Man muss einfach dranbleiben. Am Anfang kann es sehr herausfordernd sein. Es kann sehr frustrierend sein. Ohne etwas, das dich vorantreibt, gibt man leicht auf. Wenn es irgendwie möglich ist, hilft es sehr, etwas zu haben, das man damit wirklich machen will. Das gehört alles zum selben Rat. Man muss einfach dranbleiben. Es hilft sehr, geduldig mit sich selbst zu sein und anzuerkennen, dass man eine neue Fähigkeit lernt und oft scheitern wird. Ich habe Leute erlebt, die Programmieren lernen wollten und frustriert waren. Sie meinten: Oh, ich bin normalerweise gut in Dingen, und es klappt nicht auf Anhieb. Und ich sage: Ja, Scheitern gehört zum Lernprozess. Und wenn es dir unangenehm ist, bei etwas zu scheitern, kann es dir sehr schwerfallen, neue Fähigkeiten zu erlernen. Man muss geduldig mit sich selbst und mit dem Prozess sein und einfach viel dranbleiben. Jonathan: Das ist hilfreich. Ich würde sagen, das ist ungefähr so... Ich habe gerade erst gemerkt, wie Methoden funktionieren. Und das kam einfach durchs Durchgehen, weil viel von dem Wissen, wenn Leute über Sachen reden, steckt so viel vorausgesetztes Wissen drin, besonders beim Unterrichten. Plötzlich schmeißen alle mit dem Wort Methoden um sich. Ich so: Was zum Teufel ist eine Methode? Was geht hier vor? Und erst durch die Kohorte mit Go habe ich angefangen zu verstehen: Oh, Methoden funktionieren so. Aber es war fast wie der Groschen, der fiel, und ich musste mich so lange in diese Umgebung und diese Terminologie eintauchen, dass es langsam einsickert. Ich würde sagen, das war eines der größten Dinge für mich: nicht zu versuchen, alles auf einmal zu lernen, sondern ein einfaches Konzept nach dem anderen anzugehen. Weil alles so stark zusammenhängt, dass man irgendwann anfängt, das Denkmodell zusammenzusetzen, was wirklich wichtig ist. Das ist also ein tolles kleines Werkzeug. Ich sage den Leuten davon, dass Isaac empfiehlt: Sei geduldig und freundlich zu dir selbst und geh eins nach dem anderen an. Das ist richtig cool. Okay. Dann die letzte Frage, und bevor ich dich den Rest deines Tages weitermachen lasse: Wir haben im Team über dieses Konzept gesprochen, den Hügel, auf dem man sterben würde, in der Tech-Welt. Das klingt ziemlich melodramatisch und nach viel Drama. Und die Idee ist im Kern: Was ist die eine Sache, von der du glaubst, dass sie absolut entscheidend ist, eine unverrückbare Denkweise oder Perspektive, die man in der Tech-Welt haben sollte? Ein gutes Beispiel wäre, ich weiß nicht, auf ganz trivialer Ebene: Ich setze immer erst meine Funktionen und dann schreibe ich mein CSS, wenn ich Frontend mache. Also Funktionalität, dann Logik, dann was auch immer. Es könnte sein, wir hatten eine, Rebecca, die den Unison-Track leitet. Sie meinte, statt ein Genie zu haben, das meinungsstark und schwierig im Umgang ist, hätte sie lieber 50 Leute, die wirklich gern im Team arbeiten und gemeinsam Probleme lösen. Das war eine ihrer... und ich habe es nett formuliert. Aber was wäre dein Hügel, auf dem du in der Tech-Welt sterben würdest, dein Non-Negotiable? Isaac: Das ist wahrscheinlich stark davon geprägt, wie Google Dinge macht. Bei Google gibt es dieses Konzept der Readability, bei dem Code leicht lesbar sein soll. Und viel von dem, was ich beim Schreiben von Code tue: Ich will, dass mein Code einfach zu lesen und zu verstehen ist. Und ich habe viel Code gesehen, besonders in... es gibt einen großen Fokus auf Effizienz und Benchmarking und das Beschleunigen von Code. Oft räume ich ein, dass die Art, wie ich es mache, nicht unbedingt die effizienteste ist, aber wenn ich finde, dass der Code leichter zu lesen ist, dann bevorzuge ich ineffizienten, leicht lesbaren Code gegenüber supereffizientem Code. Es gibt dieses bekannte Zitat, ich bin nicht sicher, wem es genau zugeschrieben wird, dass vorzeitige Optimierung die Wurzel allen Übels ist. Und wenn Leute fragen: Oh, wie kann das effizienter sein? Dann sage ich: Muss es denn effizienter sein? Bist du auf... läuft es in Produktion und du stößt auf Effizienzprobleme? Ist es zu langsam, um in Produktion genutzt zu werden? Wenn du mit dem Code in Produktion noch kein Problem erlebt hast, bei dem er effizienter sein muss, warum würdest du ihn dann effizienter machen? So wie er ist, ist er leichter zu lesen. Er ist leichter zu warten. Andere Leute können verstehen, was vor sich geht. Warum würdest du gut geschriebenen Code aufgeben, der leicht zu benutzen und leicht zu warten ist, um ein paar CPU-Zyklen zu sparen? Ist Strom billig genug und sind CPUs billig genug, dass wir Code nicht optimieren müssen? Nur um ihn zu optimieren. Jonathan: Ja, es ist immer lustig, weil es eines dieser Dinge ist, wo ich denke... unser Programm kompilierte und lief in 30 Millisekunden. Und sie so: Oh, aber wir haben es auf 20 Millisekunden runtergebracht. Ich so: Ich könnte dir nicht sagen... Ich könnte dir nicht sagen, welches schneller, welches langsamer war. Das klingt schnell. Ich denke, das ist ein guter Punkt. Ich bin sicher, ich würde deinen Code gern lesen, aber das ist großartig. Isaac, vielen Dank für deine Zeit, dafür, dass du früh aufgestanden bist und das Load Shedding auf der Südhalbkugel ausgehalten hast. Und dafür, dass ich hier in völliger Dunkelheit sitze, was für dich sicher ziemlich komisch ist. Aber vielen Dank für deine Zeit. Und ich freue mich darauf, dich bei künftigen Lern-Kohorten und in den Mentoring-Streams und all dem zu sehen. Und danke für all deinen Beitrag zu Exercism und überall. Ich weiß das sehr zu schätzen. Und ja, nochmals vielen Dank. Und ich sehe dich gleich. Nein, gern geschehen. Pass auf dich auf, Isaac. Tschüss. Isaac: Vielen Dank noch einmal. Gern geschehen. Pass auf dich auf, Isaac.