#39 Gemischte Tüte: Software Engineer, Github, OpenSource, Git und HomeOffice

Ein neues Format: Die gemischte Tüte mit Software Engineers, Git, GitHub, Open Source und Home-Office-Equipment

Eine Episode mit vier verschiedenen Themen, die uns als User-Fragen zugespielt wurden. Es geht um den Unterschied von einem Software Developer und Software Engineer, ob wirklich alles was wir auf GitHub finden als "Open Source" bezeichnet werden kann und benutzt werden darf, ob Git wirklich dezentral ist und wie wir das ganze eigentlich benutzen und wie die Home-Offices von Wolfgang und Andy eigentlich aussehen.

Bonus: Ob Lakritz was in einer gemischten Tüte zu suchen hat.

Sprungmarken

(00:00:00) Intro

(00:00:35) Das Format "die gemischte Tüte"

(00:02:42) Was ist der Unterschied von einem Software Developer und Software Engineer?

(00:08:04) Ist eigentlich alles, was auf Github ist, Open Source und darf ich dies einfach so verwenden?

(00:18:47) Ist Git wirklich dezentral und wir können weiterarbeiten, auch wenn GitHub down ist?

(00:31:14) Wie sieht unser Home-Office Setup aus?

(00:45:39) Outro

Hosts

Wolfgang Gassler (https://twitter.com/schafele)
Andy Grunwald (https://twitter.com/andygrunwald)

Feedback (gerne auch als Voice Message)

Email: stehtisch@engineeringkiosk.dev
Twitter: https://twitter.com/EngKiosk
WhatsApp +49 15678 136776

Transkript

Das Transkript wurde automatisiert per Speech-to-Text erstellt und kann daher Fehler enthalten.

Andy Grunwald (00:00:04 - 00:00:40)

Willkommen zur Episode 39 vom Engineering Kiosk. Normalerweise haben wir ein Thema, was die Episode bestimmt. In dieser Episode spielen wir etwas mit dem Format und beschäftigen uns mit vier Themen, die uns als Userfragen zugespielt wurden. Es geht dabei um den Unterschied von Software Developer und Software Engineer, ob alles, was auf GitHub gehostet ist, automatisch Open Source ist, ob wir Git wirklich so dezentral nutzen, wie es gedacht ist und wie unser Home Office so aussieht. Viel Spaß dabei! Alle guten Dinge sind zwei, oder? Und deswegen versuchen wir... Moment, bei euch.

Wolfi Gassler (00:00:40 - 00:00:43)

In Duisburg sind alle guten Dinge zwei?

Andy Grunwald (00:00:43 - 00:00:47)

Bei uns in Duisburg sind wir froh, wenn wir überhaupt was geschafft kriegen, siehe den Duisburger Hauptbahnhof.

Wolfi Gassler (00:00:48 - 00:00:51)

Also alle guten Dinge sind eins bei euch.

Andy Grunwald (00:00:51 - 00:01:05)

Alle guten Dinge sind, wenn wir mal anfangen. Aber heute machen wir mal alle guten Dinge sind zwei. Denn heute versuchen wir das Format der gemischten Tüte endlich mal einzuführen. Wir haben die ganze Sache erfolglos in Episode 36 versucht.

Wolfi Gassler (00:01:07 - 00:01:22)

Ja, weil du so viel redest und nicht mehr aufhörst zu reden, wenn man dir eine Frage stellt. Ich hab sogar am Ende von der Episode dich wieder rausschneiden müssen, weil du bei einer ganz kurzen Frage, die man mit einem Satz beantworten sollte, wieder irgendwie vier Minuten oder so geantwortet hast.

Andy Grunwald (00:01:23 - 00:01:25)

Sprach er und redete mir rein.

Wolfi Gassler (00:01:26 - 00:01:28)

Du warst bei der gemischten Tüte.

Andy Grunwald (00:01:28 - 00:01:47)

Gemischte Tüte. Was ist eine gemischte Tüte? Früher bin ich immer zum Kiosk gegangen, hab eine D-Mark oder zwei D-Mark auf den Tresen gelegt und konnte mir dann von den Süßigkeiten eine gemischte Tüte aussuchen. Ich hätte gern zwei Cola-Kacher, drei saure Zungen und so weiter. Zwei weiße Mäuse, die waren immer klasse. Aber Lakritz war nie dabei.

Wolfi Gassler (00:01:47 - 00:01:52)

Das ist gut, wer will sowas?

Andy Grunwald (00:01:52 - 00:01:58)

Ich weiß auch nicht, ich mag auch keinen Lakritz, aber es gibt auch Leute, die mögen Kaiserschmarrn mit Rosinen.

Wolfi Gassler (00:01:58 - 00:02:00)

Das ist einzig wahre.

Andy Grunwald (00:02:01 - 00:02:05)

Deswegen versuchen wir heute erneut das Format der gemischten Tüte zu etablieren.

Wolfi Gassler (00:02:05 - 00:02:13)

Und statt den weißen Mäusen haben wir intelligente Fragen von unserer Hörerschaft, die wir versuchen zu beantworten.

Andy Grunwald (00:02:13 - 00:02:30)

Diese Fragen haben wir über Zeit gesammelt. Wir haben diese Fragen auf verschiedene Arten und Weisen bekommen, via E-Mail, via Twitter, manchmal auf Meetups oder Ähnliches. Und wir maintainen eine lange Liste von diesen Arten von Fragen, wo wir uns dann immer ein Thema rauspicken, über das wir hier im Podcast sprechen.

Wolfi Gassler (00:02:30 - 00:02:35)

Also, falls ihr eine Frage habt, bitte nur her damit, wir beantworten sie dann irgendwann mal.

Andy Grunwald (00:02:35 - 00:02:53)

Wir versuchen diese Fragen zu timeboxen, irgendwas so zwischen 10 und 15 Minuten und dann springen wir zum nächsten. Ich würde sagen, springen wir mal direkt rein. Die erste Frage, die wir bekommen haben, ist Wolfgang, was ist der Unterschied von einem Software-Developer, Developerin und einem Software-Engineer, einer Software-Ingenieurin?

Wolfi Gassler (00:02:54 - 00:03:36)

Heißt es eigentlich Developer oder Developper? Das frage ich mich die ganze Zeit. Das sagen mittlerweile so viele Leute Developer, dass ich schon glaube, es ist richtig, aber ich kann mir das eigentlich nicht vorstellen. Aber das ist ein anderes Thema, du brauchst es jetzt gar nicht beantworten. Die Frage kam von von Nils und wir hatten die schon versucht in einem Satz zu beantworten, also ich habe sie in einem Satz beantwortet in Folge 36, du in vier Minuten, die ich dann rausgeschnitten habe, also lass ich dir mal den Vortritt, du kannst jetzt deine vier Minuten, ich könnte einfach die vier Minuten reinschneiden jetzt vom letzten Mal, das wäre ja noch einfacher, aber ich lass dir mal den Vortritt. Vielleicht noch mal zur Erinnerung, meine Einsatzantwort war, es gibt keinen Unterschied zwischen Software-Developer und Software-Engineer.

Andy Grunwald (00:03:36 - 00:04:57)

Das challenge ich ein bisschen, denn es gibt keine industrieweite Definition von Software-Developer und Software-Engineer und auch in Job-Descriptions wird der Begriff austauschbar behandelt. Ich denke, mehr und mehr Job-Descriptions gehen von Software-Developer zu Software-Engineer mit der These, dass sich das sehr wahrscheinlich professioneller anhört. Persönlich denke ich, der Unterschied ist, dass ein Software-Ingenieur wirklich, ich nenne es mal, Ingenieurshaft an die Arbeit rangeht und das Handwerk mit einer professionelleren Brille betrachtet. Was meine ich damit? Ich meine damit, ein Design-Dokument schreibt, also man bekommt eine Anforderung und dann denkt man wirklich mal einen Tag, zwei oder länger darüber nach, wie baue ich das dann am besten. man schreibt die Anforderungen mal auf, man dokumentiert sie, man schreibt ein Design-Dokument, man geht verschiedene Arten, verschiedene Lösungsarten durch, man schreibt Pro und Con auf für welche Lösungsart, man hat dann wirklich, ich nenne es mal auch einen Decision-Log, also einen Entscheidungs-Log, warum man welche Lösung denn auch wirklich verworfen hat. Damit man nämlich später sagen kann, in zwei Jahren, ja das ist ja alles scheiße, warum haben wir es damals nicht so gemacht, dann kann man diese Vorarbeit, die ein Software-Engineer macht, dann wieder raus von sagen okay die rahmenbedingungen damals waren ganz anders und hier ist die grundlage weswegen wir uns für die aktuelle lösung.

Wolfi Gassler (00:04:57 - 00:05:43)

Entschieden haben aber ist das nicht ist das nicht eher ein senior engineer also wo würdest du jetzt wenn du eine job anzeige siehst software developer würdest du jetzt sagen die leute die sich dort bewerben haben alle diese fähigkeiten nicht oder wo ist der unterschied zwischen einem senior software developer und senior software engineer siehst du dann irgendwo einen unterschied Also mir kommt ja fast vor, das ist diese krankhafte, okay krankhafte lasse ich weg, wenn ich das mit Deutschland verbinde, also diese Hochhebung des Begriffes Ingenieur, Ingenieur in Deutschland, die ihr so gerne betreibt und das Ingenieurswesen so wichtig sei und dass ihr in Deutschland so die großen Ingenieure seid. Bei uns ist das fast ein Schimpfwort in Deutschland, wenn man Titel Ingenieur hat, so ein billiger Titel, den man relativ billig bekommt.

Andy Grunwald (00:05:43 - 00:05:53)

Man sagt ja auch German Engineering. haben senior software developer diese fähigkeiten nicht natürlich haben sie diese fähigkeiten und ich sage ja auch dass der begriff austauschbar.

Wolfi Gassler (00:05:53 - 00:06:16)

Verwendet wird aber warum willst du dann dann überhaupt einen unterschied rein reklamieren wenn sie sowieso austauschbar sind und so verwendet werden und niemand dann großen unterschied sieht außer dass es cooler klingt das ist nämlich auch meine Meinung dass es glaube ich nur cooler klingt mittlerweile zumindest im deutschsprachigen raum im englischsprachigen raum bin ich mir gar nicht sicher und darum wird es einfach mehr verwendet.

Andy Grunwald (00:06:16 - 00:06:21)

Ja gut aber alter weine neuen schläuchen auszuschenken hat machen wir jeden tag in der it also von daher.

Wolfi Gassler (00:06:21 - 00:06:22)

Das muss man nicht noch unterstützen.

Andy Grunwald (00:06:23 - 00:07:00)

Also jeder, der sagt irgendwie Microservices ist super was Neues. Nee, ist nicht was Neues. Wir haben halt nur neuere Tools mit Sidecar Patterns und Service Meshes und blablabla drumherum. Und deswegen, warum sollen wir da bei Titeln aufhören? Ich stimme dir zu, dass der Unterschied wirklich schwammig ist, ja? Und sollte man einen Job ablehnen, weil man dann Software Developer heißt? Nein, sollte man nicht. Denn ich denke, es kommt ganz auf die Philosophie und auf den Qualitätsanspruch des Arbeitgebers an, aber auch den Qualitätsanspruch, den man selbst an den Tag legt. Natürlich gibt es auch 10, 20, 30 oder mehr Prozent an Software-Developer, die auch Design-Dokumente schreiben.

Wolfi Gassler (00:07:01 - 00:07:09)

Wenn du jetzt einen Job ausschreiben würdest, was würdest du verwenden? Welchen Begriff für einfach einen Entwickler oder Entwicklerin, die du suchst?

Andy Grunwald (00:07:10 - 00:07:42)

Software-Engineer. Ich denke halt, dass der Wandel des Begriffes von Software-Developer nach Software-Engineer sich gegebenenfalls auch ein bisschen an dem Wandel der Welt drumherum orientiert. Wo früher immer IT eine Kostenstelle war, ist das heute der Innovationstreiber in der Firma. Und wo früher man gesagt hat, okay, da Software-Developer, das sind nur die Nerds im Keller, und die kann es ja keinem Kunden zeigen, hat sich das ja jetzt auch gewandelt. Und ich denke halt, dass Software-Engineer, der Begriff des Software-Engineers das auch ein bisschen unterschreibt.

Wolfi Gassler (00:07:42 - 00:07:48)

Okay, ich bin auf jeden Fall gespannt, was unsere Community so auf Twitter dazu zu sagen hat.

Andy Grunwald (00:07:48 - 00:07:55)

Und das zieht sich natürlich auch in Backend-Developer, Backend-Engineer, Frontend-Developer, Frontend-Engineer. Ja, also ich meine, die machen die gleiche Arbeit, so ist das nicht.

Wolfi Gassler (00:07:56 - 00:08:01)

Ich sag nur deutsche Ingenieurskunst. Aber gehen wir mal zum nächsten Punkt, zur nächsten Frage.

Andy Grunwald (00:08:01 - 00:08:18)

Okay, ich glaub, das ist ein Streitthema, da kommen wir nie bei, ne? Naja, ist ja auch okay. Okay, die nächste Frage, die uns erreicht hat, war folgendes. Ist eigentlich alles, was auf GitHub ist, open source und darf ich das einfach so verwenden? Also im Videostream grübelt der Wolfgang gerade.

Wolfi Gassler (00:08:19 - 00:08:56)

Ich erinnere mich jetzt gerade, dass einer unserer Hörer, der Simon, mir mal geschrieben hat, dass wir in einer Folge so ungenau über Open-Source-Lizenzen gesprochen haben und dass das eigentlich viel komplexer sei. Jetzt bin ich fast zu ängstlich, diese Frage zu beantworten, weil ich wieder die Open-Source-Lizenzen durcheinander bringen könnte oder zu ungenau definieren könnte. Meine schnelle Antwort wäre, es ist alles zugänglich, das heißt es ist vielleicht open, aber nicht im Sinne von Open Source und Open Source Lizenzen, weil im Endeffekt muss man immer genau prüfen, was für eine Lizenz dahintersteckt, wäre meine Antwort in einem Satz. Also es ist ein privates Repository, aber dann habe ich sowieso keinen Zugriff.

Andy Grunwald (00:08:56 - 00:08:58)

Wir reden jetzt hier nur von Public Repositories.

Wolfi Gassler (00:08:59 - 00:09:01)

Was ist deine Meinung?

Andy Grunwald (00:09:01 - 00:10:01)

Nein, es ist nicht alles Open Source und es darf auch nicht alles verwendet werden. Nur weil der Quellcode öffentlich zugänglich ist und lesbar, heißt das nicht, dass du den Quellcode nehmen kannst und in deinem privaten oder kommerziellen Projekt nutzen kannst. Wenn keine Lizenz angegeben ist, dann unterliegt das immer noch dem klassischen Problem des Intellectual Properties. Und eine Lizenz muss nicht unbedingt immer nur durch ein dediziertes License-File angelegt sein. Das kann einfach auch so sein, dass in den Quellcodedateien im Header eine Lizenz drin steht oder irgendwo anders in dem Repository. Aber auch wenn der Quellcode bei einem GitHub-Repository Open Source ist, also der Source Code ist offen, heißt das nicht, dass der Code Open Source ist und mit dem zweiten Open Source meine ich unter einer Open Source Lizenz steht. Und auch wenn er eine Lizenz hat, heißt das nicht, dass diese Lizenz wirklich eine Open Source Lizenz ist.

Wolfi Gassler (00:10:02 - 00:10:14)

Und dann gibt's ja noch den Unterschied zwischen Free und Open Source und nur Open Source und Libre und die ganzen Geschichten. Also es gibt ja nicht mal die Open-Source-Lizenzen.

Andy Grunwald (00:10:14 - 00:11:16)

Das ist richtig. Ich sag mal so, dass die gängigen Lizenzen im Open-Source-Bereich, eine MIT, eine BSD, eine GPL, eine Apache 2, das sind halt schon Lizenzen, die offiziell von den großen Organisationen als Open-Source-Lizenzen deklariert sind. Wenn es natürlich jetzt in diese Free Software und Libre Ecke geht, dann ist das alles natürlich nochmal ein bisschen spezieller aufgezogen und da geht es natürlich dann auch sehr speziell in diese GPL Ecke. Das bedeutet zum Beispiel, wenn ich eine GPL lizenzierte Software nutze und in meine Software mit einbaue, und die auch modifiziere, dann muss das Resultat ebenfalls unter GPL neu lizenziert werden. Dann kann ich die nicht einfach unter Apache 2 lizenzieren. Was es dann wiederum automatisch opensource macht, das ist bei der MIT-Lizenz zum Beispiel jetzt nicht der Fall. Die MIT-Lizenz oder Software, die unter MIT lizenziert ist, kann ich in meine Software einbauen, modifizieren und dann auch verkaufen.

Wolfi Gassler (00:11:17 - 00:11:42)

Und da hat eben der Simon, einer unserer Hörer, damals bei Folge 4 auch kritisiert, dass wir gesagt haben, dass GPL dann nicht so gern von Firmen verwendet werden, weil man da eben dann daraus auch wieder Open Source immer generieren muss. Und da hat er eben auch zu Recht gesagt, es stimmt nicht, dass Firmen da automatisch die Hände davon lassen. Und das beste Beispiel ist ja auch der Linux-Körner selber, der GPL ist und dementsprechend durchaus von Firmen verwendet wird.

Andy Grunwald (00:11:43 - 00:12:13)

Das ist korrekt, aber da kommt es ja ganz drauf an, wie GPL-lizenziertes Software verwendet wird. Wenn ich das Endprodukt, nämlich den Linux-Kernel, einfach so nutze, dann kann ich den ja auch in mein kommerzielles Projekt mit einbauen. Wenn ich aber jetzt den Wolfgang-Kernel mache, und nutze den Source-Code vom Linux-Kernel und modifiziere den weiter und verkaufe den Wolfgang-Kernel danach. Das geht nicht, weil mein Wolfgang-Kernel muss ich dann unter GPL-Lizenz stellen.

Wolfi Gassler (00:12:14 - 00:12:59)

Und was ja heutzutage auch viel gemacht wird, und das haben wir ja gerade kürzlich besprochen mit Elasticsearch zum Beispiel, dass immer mehr diese Lizenzen kommen, die sagen, du darfst es zwar verwenden, außer wenn du ein Produkt damit baust und es als Service wieder anbietest. Es gibt ja auch zum Beispiel diese Kafka-Alternative Red Banda, sind ein Drop-In-Replacement und sind, glaube ich, in C geschrieben, wenn mich nicht alles täuscht. Auf jeden Fall nicht in Java. Und behaupten auch, sie sind schneller und die haben genauso die gleiche Lizenz. Darfst du natürlich anwenden, aber du darfst kein Service anbieten in der Cloud, weil das wollen sie für sich natürlich behalten, um irgendwie Geld zu machen mit der Software. Das ist ja mittlerweile ein ziemlich klassisches Pattern und auch verständliches, weil du halt damit noch irgendwo einen Revenue Stream hast von deiner Open Source Software.

Andy Grunwald (00:12:59 - 00:13:16)

Nehmen wir doch mal das Beispiel von Elasticsearch. Elasticsearch hat einen Lizenzwechsel gemacht. Das bedeutet aber, dass alle vorherigen Versionen, die bereits released wurden, noch unter der alten Lizenz stehen. Das bedeutet, du könntest jetzt als Cloud-Provider die älteren Versionen von Elasticsearch immer noch betreiben als Cloud-Offering.

Wolfi Gassler (00:13:17 - 00:13:23)

Ja, was einmal unter einer Lizenz draußen war, kannst du natürlich nicht mehr zurückziehen und verhindern.

Andy Grunwald (00:13:23 - 00:14:14)

Ganz genau. Aber kommen wir nochmal zur Frage, ist denn alles, nur weil das auf GitHub jetzt öffentlich einsehbar ist, kann ich das denn nutzen? Die Antwort ist einfach nein. Und die Realität sieht da ein bisschen anders aus, weil die Leute nutzen einfach die Software und kaum, also die meisten kleineren Firmen werden jetzt keine Lizenzchecks haben über alle Dependencies. Wir hatten da auch schon mal in einer Episode drüber gesprochen, wie kompliziert es eigentlich ist, alle Dependencies von deiner Software herauszufinden. Da geht's dann natürlich unter anderem in das Thema Bill of Materials, sogenanntes BOM, was all dieses Inventar natürlich kategorisiert und was es dann durch Super macht. Aber es ist generell ein sehr schwieriges Thema zu wissen, welche Lizenzen eigentlich in deiner Applikation so alles verwendet werden. Sind diese Lizenzen überhaupt untereinander kompatibel? Ist das eigentlich überhaupt legal, was ich mache?

Wolfi Gassler (00:14:16 - 00:14:49)

Was auch ganz oft passiert ist, dass es gar keine Lizenz gibt, keine definierte Lizenz und damit ist es auf keinen Fall Open Source, nur weil der Source Code verfügbar ist. Damit ist es eigentlich automatisch proprietär und du darfst den Source Code nicht verwenden. GitHub hat da ja ein bisschen gegengesteuert, dass du automatisch jetzt angeboten bekommst, eine Lizenz zu kreieren, wenn du ein Repository erstellst. Aber es kann natürlich immer noch ein Repository irgendwo herumschwirren, das ganz praktisch ist, aber keine spezifische Lizenz definiert hat. Und das macht dann natürlich auch ein Problem im Zweifelsfall.

Andy Grunwald (00:14:49 - 00:15:14)

Wenn man natürlich rechtlich auf der sicheren Seite sein möchte, ist das natürlich auch ein Problem, wenn ich ein Repository habe, wo keine Lizenz definiert ist. Dann kommt der Wolfgang, macht einen Pull-Request, somit haben wir beide Intellectual Properties dieser Software und danach setze ich einfach eine Lizenz drauf und stelle Wolfgangs Code, den er in die Software überführt hat, unter eine Open-Source-Lizenz.

Wolfi Gassler (00:15:15 - 00:15:18)

Was du eigentlich nicht mal darfst, weil es ja urheberrechtlich bei mir liegt.

Andy Grunwald (00:15:19 - 00:16:09)

Ganz genau. Das bedeutet, wenn ich einen Lizenzwechsel habe oder eine Lizenz einführe, muss ich eigentlich die Erlaubnis von allen vorherigen Contributoren haben. Deswegen gibt es natürlich auch diese CLAs, ein Contributor License Agreement, was man bei sehr großen Projekten oft unterschreiben muss, bevor man einen Pull Request machen kann. Und die Details unterscheiden sich natürlich von CLA zu CLA, aber summa summarum steht da eigentlich drunter, okay, ich trete meine eigentlichen Intellectual Property-Rechte an dieses Projekt. Und an dieses Projekt ist entweder eine Association, eine Organisation oder, ja, eine Firma oder ähnliches ab, damit diese nämlich einen solchen Move später machen können. Und deswegen war ja unter anderem für größere Projekte wie Elastic es möglich, Lizenzen zu ändern, ohne das Agreement von den vorherigen Contributors einzukriegen.

Wolfi Gassler (00:16:10 - 00:16:35)

Ganz oft ist es ja auch, dass Projekte Dual Licensing fahren. Das heißt, sie haben einerseits eine Open Source License und dann aber auch eine proprietäre Lizenz, so wie MySQL. Und wenn du dann natürlich Contributions bekommst, dann wirst du die ja auch im Zweifelsfall für deinen proprietären Zweig mit einbinden, wenn das was Sinnvolles ist für dich. Und dadurch musst du natürlich auch so Agreements dementsprechend. Bei MySQL meines Wissens gibt es das auch abnicken.

Andy Grunwald (00:16:36 - 00:17:59)

Es gibt auch recht viele Projekte, die sagen, du bist Privatanwender oder du machst mit der Anwendung meiner Software kein Geld, dann kannst du die nutzen. Wenn du diese kommerziellen nutzen möchtest, bitte frag bei mir an, dann gebe ich dir eine Erlaubnis oder schicke dir eine Lizenzkostenrechnung. Sowas gibt es auch, was natürlich dann im Endeffekt für die Frage bedeutet, ist eigentlich alles, was auf GitHub ist, Open Source und darf ich das verwenden? Die Antwort ist nein. Es muss eine Lizenz in dem Projekt definiert sein. Dann kommt es darauf an, was für eine Lizenz und wie sieht die aus? Es gibt offizielle Listen, die sagen, das ist eine offiziell anerkannte Open Source Lizenz. Jede Lizenz bringt Rechte und Pflichten mit, wie zum Beispiel Alles, was unter Apache 2 lizenziert ist, ist recht safe, weil man in der Apache 2 Lizenz sogar das Recht hat, die unterliegenden Patente mitzunutzen, falls diese Software irgendwelchen Patenten unterliegt. Somit passt ein bisschen auf, was ihr da nutzt. In der Realität kennen sich aber sehr, sehr wenige Anwälte damit aus, weil das ein sehr komplexes Thema ist, besonders wenn wir das ganze Thema weltweit spannen. Intellectual property ist in vielen Ländern einfach anders gehandhabt. In Amerika wird es anders gehandhabt als in Deutschland. Das soll jetzt hier keine Rechtsberatung sein, aber als Pragmatiker ist es auch oft so, wo kein Kläger, da kein Richter.

Wolfi Gassler (00:17:59 - 00:18:01)

Oh, die österreichische Herangehensweise.

Andy Grunwald (00:18:01 - 00:18:08)

Ich würde halt sagen, passt ein bisschen auf, besonders wenn ihr größer werdet. Kommen wir zur Frage 3.

Wolfi Gassler (00:18:08 - 00:18:43)

Und wer sich da näher informieren will, Wikipedia ist da natürlich ein guter Start, aber die Liste ist ewig lang von Licenses. Es gibt auch so Online-Projekte, die da ein bisschen helfen, so wie chooselicense.com oder unter opensource.org findet man auch einige Informationen zu den ganzen licenses. Creative Commons haben wir auch noch gar nicht erwähnt, aber auch die haben auf der Webseite so einen kleinen Wizard, wo man dann einstellen kann, was will ich eigentlich erreichen mit der License und am Ende wird die richtige License ausgegeben. Also da gibt es einige Hilfe im Internet, wo man ganz gut eigentlich damit starten kann.

Andy Grunwald (00:18:44 - 00:19:05)

Wir verlinken euch die entsprechenden Links in den Shownotes. Springen wir direkt weiter. Bleiben wir beim Thema Git. Wolfgang, die Frage 3 handelt um das Versionskontrollsystem Git selbst. Ist Git wirklich dezentral? Weil irgendwie arbeiten wir doch immer nur mit GitHub und wenn es down ist, gehen wir eh einen Kaffee trinken.

Wolfi Gassler (00:19:05 - 00:19:07)

Ich verwende sowieso nur CFS.

Andy Grunwald (00:19:07 - 00:19:27)

Du bist auch keine 20 mehr, ne? Aber die Frage hat einen wahren Kern, wenn Github wirklich down ist, wenn wir mal wieder das Github Unicorn kriegen, dann ist auf Twitter die Hölle los, Hacker News hat wieder einen Top Beitrag, Github ist wieder down und in letzter Zeit war das ja nicht wirklich selten, dass Github mal einen Hickup hatte.

Wolfi Gassler (00:19:27 - 00:19:33)

Wobei meistens die Suche eigentlich, die hat bei mir immer ein Problem. Verwenden sicher Elasticsearch im Hintergrund.

Andy Grunwald (00:19:33 - 00:20:04)

Weiß ich nicht. Aber warum ist das so? Warum gehen wir immer Kaffee trinken, wenn GitHub direkt down ist? Weil im Endeffekt ist die Frage schon valider. Nutzen wir Git als dezentrales Versionskontrollsystem? zentral und nutzen wir dann eigentlich nur das Feature from Branchen und Mergen, was den Vorteil von Git gegenüber Subversion hat, weil irgendwie habe ich schon ein bisschen das Gefühl, dass sehr sehr viele Leute Git ähnlich wie Subversion nutzen und ohne zentralen Server, man kann schon arbeiten, aber man limitiert sich halt selbst.

Wolfi Gassler (00:20:05 - 00:20:53)

Ich glaube halt, dass GitHub ja auch viel mehr ist als Git. Git ist schon dezentral und du kannst es auch dezentral nutzen. Du kannst halt keine sinnvollen Pull-Requests in der Web-Oberfläche zum Beispiel machen. Das ist aber kein Git-Feature. Das ist halt alles, was GitHub rundherum gebaut hat. Eine coole Suche in dem Source-Code, die extrem schnell ist. Pull-Requests, Issues. Also alle Features rundherum und ich glaube, das macht eigentlich GitHub aus und darum ist es halt mittlerweile ein sehr zentrales System, das man auch nutzt und als zentrales System nutzt und das geht halt weit über das eigentliche Git hinaus. Der Sourcecode, nur weil du den Sourcecode lokal hast, hilft dir das halt nur geringfügig weiter, wenn du den richtigen Branch noch nicht ausgecheckt hast oder die ganzen Kommentare nicht dazu hast zum Pull-Request.

Andy Grunwald (00:20:53 - 00:21:13)

Ja, das ist korrekt, aber ich meine, natürlich können wir, wenn wir Git haben, wir können, auch wenn GitHub down ist, können wir lokal commiten, wir können lokal branchen, wir können lokal mergen. Und ja, im Vergleich zu Subversion konnten wir das nicht, denn jede Operation, so gut wie jede Operation hatte einen Kontakt zum zentralen Server.

Wolfi Gassler (00:21:13 - 00:21:18)

Kannst du vielleicht für unsere junge Hörerschaft noch ganz kurz erklären, was SVN ist?

Andy Grunwald (00:21:18 - 00:21:39)

SVN ist ein zentrales Versionskontrollsystem, was, ich würde schon fast sagen, in der Softwareindustrie als Vorgänger von Git gesehen wurde. Ich meine, es gibt natürlich neben Git auch noch Mercurial und Perforce und andere Versionskontrollsysteme, aber ... CVS? CVS war ja noch vor Subversion.

Wolfi Gassler (00:21:39 - 00:21:48)

Ich habe gerade nachgeschaut, die aktuelle CVS-Version ist von 2008, aber ich kenne zumindest noch mindestens eine Organisation, die CVS verwendet.

Andy Grunwald (00:21:49 - 00:22:43)

Also Subversion haben wir, ich sage mal, vor Git verwendet und mit wir meine ich eigentlich die Industrie. Git gab es natürlich schon sehr, sehr lange, aber zu Room ist Git erst zu einem späteren Zeitpunkt gekommen. Subversion hatte die Eigenheit, dass jede Operation auch ein SVN-Log, was dann eigentlich ein Git-Log ist, also gib mir mal die letzten Comments, eine Kommunikation zum Server brauchte. Und als Git kam, Git hatte die Features von Branching und Merging als sogenannten First Class Citizen, also das war das Kernfeature eigentlich von Git. Man konnte branchen in Subversion, man konnte mergen in Subversion. Doch das war alles immer ein bisschen komplizierter und bei weitem nicht so einfach, weil diese Features im Nachhinein erst zu Subversion kamen. Und Git hat den ganzen Spieß ein bisschen umgedreht, besonders wenn es um Teamarbeit geht und Co.

Wolfi Gassler (00:22:44 - 00:22:47)

Weißt du, wann Git entwickelt wurde? Rat mal.

Andy Grunwald (00:22:47 - 00:22:50)

Git wurde schon sehr, sehr früh entwickelt. Keine Ahnung.

Wolfi Gassler (00:22:51 - 00:22:52)

Ja, wirf mal eine Zahl raus.

Andy Grunwald (00:22:52 - 00:22:54)

1998.

Wolfi Gassler (00:22:54 - 00:23:05)

Gar nicht so weit daneben, aber es war erst 2005, die erste Release. Ich hatte auch immer gedacht, das ist eigentlich älter, aber Linus ist da sehr spät damit um die Ecke gekommen.

Andy Grunwald (00:23:06 - 00:24:31)

So und das Riesenproblem war jetzt natürlich bei Subversion, wenn der zentrale Subversion-Server down war, konntest du wirklich gar nichts machen, du konntest noch niemals mehr committen. Und dann hat natürlich, dann kam Git und hier sagt, hey cool, wir sind ja jetzt dezentral und allem drum und dran, wir können ja jetzt ein Git-Log machen auf deiner lokalen Festplatte und man kann ja Committen und Branchen und Mergen und was weiß der Geier nicht. Und dann kam natürlich dieses Konzept von sogenannten Remotes. Das bedeutet, weil jeder ja eine komplette Kopie des Git-Repositorys hat, auf seiner lokalen Feststätte, müssen wir uns irgendwie organisatorisch drauf einigen, wo ist denn jetzt die richtige Git-Realität? Also, wo ist denn jetzt das, die Kopie des Git-Repositorys, welches wir als Team sagen, okay, das ist die Source of Truth, das ist unsere Software, diese Software liefern wir jetzt aus. Und dazu haben wir irgendwie GitHub wiedergemacht. Das bedeutet, wenn du mal ein bisschen weit rausgehst, kann man jetzt theoretisch die Behauptung aufstellen, GitHub ist unser zentraler Subversion-Server. Weil dort die verschiedenen Changes an den verschiedenen lokalen Kopien wieder zusammenfließen und womit wir kommunizieren. Obwohl wir natürlich GitHub gar nicht bräuchten. Das bedeutet, ich könnte mir jetzt einfach sagen, hey, öffne mal bitte Git-Port bei dir, Wolfgang, dann gib mir mal kurz deine Git-Remote-URL oder welche IP-Adresse ich dich bekomme oder unter gasla.dev und dann push ich dir meinen Branch rüber, genauso wie GitHub.

Wolfi Gassler (00:24:33 - 00:25:18)

Ja und so ist es ja ursprünglich gemacht worden. Also es gibt ja nicht wirklich einen SVN-Port oder so, aber einfach klassisch SSH. Und das war genau die Idee früher. Du hattest einen Server und dort hast du mit SSH einfach deine Änderungen abgelegt und gepusht. Also alles das, was heutzutage über GitHub funktioniert, hat man früher einfach bei SSH gemacht oder machen vielleicht einige immer noch. Und darum läuft es ja im Hintergrund auch über SSH ab. Und darum verwendest du auch SSH-Keys, wenn du mit GitHub arbeitest, weil im Hintergrund ist einfach bei SSH abgelegt wird. Und so war auch die ursprüngliche Zusammenarbeit zwischen den Entwicklern, die dann Git verwendet haben. Und da hat es halt einen oder mehrere zentrale Server gegeben, genau. Und das gibt halt jetzt eine coole Web-Oberfläche oben drüber. Das ist eigentlich, was GitHub ausmacht.

Andy Grunwald (00:25:18 - 00:25:33)

Das ist korrekt, aber hast du das Gefühl, dass das Feature von Git Remote oder von Remotes selbst von sehr vielen Entwicklern verstanden ist oder denken die, der Name Origin oder Upstream sind fixe Begriffe?

Wolfi Gassler (00:25:33 - 00:25:42)

Ja, ich frage mich immer, wie relevant das ist. Muss ich verstehen, wie mein Elektromotor von meinem Tesla funktioniert, nur weil ich einen Tesla fahre. Ich fahre übrigens keinen Tesla, aber...

Andy Grunwald (00:25:42 - 00:26:00)

Das ist ein valider Punkt, aber kommen wir auf die Frage zurück. Ist Git wirklich dezentral, beziehungsweise nutzen wir die dezentralen Features von Git, oder ist es einfach nur valide, dass wir alle aufhören zu arbeiten, wenn Git up-down ist? Weil wir sagen, wir können nicht arbeiten, obwohl wir arbeiten könnten.

Wolfi Gassler (00:26:01 - 00:27:02)

Ja, ich glaube schon, dass man die dezentralen Features auch nutzt, weil jeder, der mal SVN verwendet hat, weiß, dass das schon anders abläuft und mit den sauberen Branches und dass man da wirklich lokal auf der KUBI arbeitet und mehrere Branches hat und da auch wechseln kann. Und alle diese Dinge, die ja sehr stark sind bei Git, ist jetzt die Frage, ob das ein dezentrales Feature ist an sich. Aber diese Features werden schon stark genutzt. Also ich würde schon sagen, grundsätzlich Vermute ich zumindest, dass den meisten Entwicklerinnen schon klar ist, dass das dezentral ist und die auch in gewisser Weise das so nutzen. Aber wie gesagt, es ist halt viel mehr, was GitHub ausmacht und anbietet. Und ich glaube, das ist der große Unterschied, weil wenn deine Idee nicht funktioniert, kannst du auch nicht programmieren, obwohl der Source-Code vielleicht da ist. Also du brauchst halt gewisse Tools und GitHub ist halt mittlerweile auch ein Tool geworden, vor allem wenn es darum geht, zusammenzuarbeiten. Und da brauchst du halt die Kommentare, weil wie willst du deinen Pull-Request verbessern, wenn die Kommentare fehlen von deinem Review, von deinem Code-Review?

Andy Grunwald (00:27:02 - 00:27:28)

Code-Reviews werden gemacht von Leuten, die nicht an sich glauben. Wir machen Main-Based Development, Master-Based Development. Achtung, wer den Begriff Trunk-Based Development schon mal gehört hat, dieser kommt aus dem Bereich Subversion, weil in Subversion war eigentlich das ungeschriebene Gesetz, dass der Master-Branch beziehungsweise der Main-Branch Trunk hieß. Nur mal so als kleine Story aus dem Krieg.

Wolfi Gassler (00:27:28 - 00:28:03)

Und weil wir gerade Code Reviews erwähnt haben, wir haben da eine eigene Episode dazu gemacht, Episode 16 zu Code Reviews, da gehen wir natürlich auch auf ein paar Dinge in dem Bereich ein. Was ich übrigens kürzlich gerade erfragt habe oder gehört habe, dass in der Gamebranche SVN noch sehr stark ist, dass die eine Kombination aus SVN und Git teilweise verwenden, weil Git so Probleme macht mit großen Dateien und die haben ja sehr große Dateien und Assets und die teilweise so eine Kombination fahren aus SVN und Git, um mit ihren extrem großen Repositories und großen Dateien irgendwie zurecht zu kommen.

Andy Grunwald (00:28:05 - 00:28:14)

Ja, das stimmt, Subversion war deutlich besser in der Handhabung von großen Dateien, von Binaries und Co. Natürlich gibt's das auch alles in Git, mit Git LFS und allem drum und dran.

Wolfi Gassler (00:28:14 - 00:28:31)

Das funktioniert aber in der Gamebranche scheinbar nicht. Das reicht nicht aus für deren Use Case. Kann ich jetzt leider nicht genau sagen, warum, aber das funktioniert nicht so gut. Darum haben die teilweise Eigenentwicklungen, die dann eben so hybrid auf Git für den Source Code und für die ganzen Assets und so weiter auf SVN basiert.

Andy Grunwald (00:28:35 - 00:30:27)

Falls ihr in der Gamebranche unterwegs seid, lasst uns doch mal wissen, wie ihr da mit großen Binaries umgeht. Wer auf jeden Fall ein bisschen mehr über dieses dezentrale Feature von Git, sogenannten Git-Remotes, lernen möchte, der kann sich ganz einfach mal ein bisschen damit beschäftigen, wie zum Beispiel Forking auf GitHub funktioniert, weil das ist eigentlich nichts anderes. Ihr forkt ein populäres Open-Source-Projekt, ihr forkt das in euren GitHub-Repository. Was ihr dann eigentlich macht ist, ihr müsst nicht euer geforktes Repository in einen anderen Ordner klonen. Ihr könnt auch einfach euer geforktes Repository als zweiten Remote lokal anlegen und dann den Remote pullen. Somit habt ihr eigentlich zwei Repositories, zwei verschiedene Realitäten in einem lokalen Clone, in einem lokalen Checkout. Und da merkt man relativ schnell, dass Begriffe re-upstream und origin eigentlich nur irgendwelche Wörter sind, weil man kann seinen lokalen Fork auch Hans-Peter oder Wanne-Eickel nennen. Das ist kein Problem, das obliegt euch. Forkt einfach mal ein Repository. und macht doch mal ein bisschen Gedanken über Git-Remotes, dann kommt ihr relativ schnell drauf, dass hey, Git ist ja doch dezentraler als ich dachte und wir brauchen GitHub nicht. Natürlich, wenn man GitHub jetzt als Issue-Tracker, Milestone-Tracker, Project-Tracker und ähnliches nutzt, dann ist es natürlich eine andere Geschichte, aber das ist ja dann wieder fern von Git. Ich hatte auf jeden Fall ein bisschen Spaß, über diese Frage nachzudenken, und ich denke, wir können uns alle ein bisschen an die Nase fassen und Git dezentraler nutzen. Ist natürlich auch ein bisschen mehr Aufwand, wenn ich die ganze Zeit quer übers Internet zu dir lokal auf die Festplatte pushe und co. Eigentlich ist ein Git ja so schon das größte Napster der Welt, ne? Weil eigentlich kann man ja dadurch auch einen guten File-Transfer machen, oder?

Wolfi Gassler (00:30:27 - 00:30:31)

Aber mit einer zentralen Stelle, also Peer-to-Peer ist es noch nicht ...

Andy Grunwald (00:30:31 - 00:30:38)

Aber wenn ich möchte, dann pushe ich was zu dir rüber. Dann pushe ich dir ein Branch rüber in deine Git-Kopie, oder? Das wäre doch möglich.

Wolfi Gassler (00:30:38 - 00:30:43)

Wenn man das Ganze sehr breit sieht, ja, dann kann man da natürlich Parallelen ziehen, das stimmt.

Andy Grunwald (00:30:43 - 00:30:45)

Lassen wir die kriminellen Gedanken.

Wolfi Gassler (00:30:45 - 00:31:45)

Und wer sonst noch mehr zu Git wissen will, die Git-Dokumentation selbst ist eigentlich sehr gut und hat sehr gute Beispiele. Und was ich auch immer ganz nett finde, ist die Webseite learngitbranching.js.org, wo man ein bisschen spielerisch durch die ganze Branching-Geschichte durchgehen kann und Commands ausprobieren kann und das auch besser verstehen kann. Also wer da mal in die Tiefe gehen will, auch mit so, wie die ganzen Bäume erzeugt werden und wann man jetzt wirklich einen neuen Branch, einen neuen Ast aufmacht und wann nicht, da kann man eigentlich ganz gut sich mal durchspielen. Aber kommen wir mal zur nächsten Frage. Und zwar die Frage kommt von unter anderem von Mario, die haben wir aber schon mehrfach gestellt bekommen, wahrscheinlich Corona bedingt vor allem. Die Frage war nämlich, wie sieht euer Büro, Homeoffice Setup, mobile Setup, wie auch immer aus? Und nachdem jetzt keiner mehr im Homeoffice arbeitet, beantworten wir die Frage. Jetzt nachdem Corona vorbei ist oder so ähnlich, zumindest hoffentlich.

Andy Grunwald (00:31:46 - 00:31:59)

Wir hatten ja schon drüber gesprochen also deutschland hält noch an dieser korona warnen fest und ich habe jetzt vor kurzem auch gelesen da wurde wieder mehr geld reingeschossen und österreich und die niederlande haben die schon abgeschaltet richtig.

Wolfi Gassler (00:31:59 - 00:32:01)

Ja wir haben korona sowieso abgeschrieben.

Andy Grunwald (00:32:01 - 00:32:06)

Ich meine die deutschen minister reden schon da irgendwie drüber winterwelle und blabliblub.

Wolfi Gassler (00:32:06 - 00:32:20)

Ja, also ich glaube auch, dass da sicher noch einiges kommt im Winter, da werden wir noch Spaß haben. Aber aktuell, glaube ich, gibt es keinen besonderen Druck mehr, dass man da im Homeoffice arbeitet, auf jeden Fall. Darum besprechen wir die Frage jetzt, wo sie nicht mehr so wichtig ist.

Andy Grunwald (00:32:20 - 00:32:28)

Aber Homeoffice wird ja nicht verschwinden. Deswegen, wie sieht euer Büro-, Mobile- und Homeoffice-Setup aus? Was ist euch besonders wichtig und wo drückt der Schuh?

Wolfi Gassler (00:32:29 - 00:32:33)

Also erzähl mal, wie sieht dein Homeoffice-Setup aus?

Andy Grunwald (00:32:33 - 00:32:46)

Ich habe meinen eigenen Raum dafür, wo mein Schreibtisch drinsteht mit Aktenordnern, blabliblub. Das ist mir sehr wichtig, dass ich einfach die Tür schließen kann. Ich habe einen höhenverstellbaren Schreibtisch von fully.com.

Wolfi Gassler (00:32:46 - 00:32:48)

Ich klicke, als wäre es irgendwie ein Rad, so Mountainbike.

Andy Grunwald (00:32:49 - 00:33:40)

Nee, das ist ein Online-Shop, der Büromaterialien verkauft. Höhenverstellbaren Schreibtisch find ich schon sehr, sehr wichtig, weil ich mich auch öfters einfach hinstellen möchte. Ich hab einen ordentlichen Schreibtischstuhl. Ich hab jetzt keinen ... Ich hab mit einem Ikea-Stuhl angefangen, aber da hab ich gemerkt, ich sitze krummer denn je. Deswegen hab ich mir einen ordentlichen ergonomischen Schreibtischstuhl gekauft. Einen Moment, guck grad, wie der heißt. Mein höhenverstellbarer Schreibtisch ist der Jarvis von Fully.com und ich habe den Haag Capisco ergonomischen Bürostuhl. Nicht ganz günstig beides, beides so circa um die 800 bis 1000 Euro. Meines Erachtens nach ist das aber sehr, sehr gut investiertes Geld, weil ich das jeden Tag mindestens acht Stunden nutze und das Geld für auch deine Gesundheit, glaube ich, ganz gut investiert ist.

Wolfi Gassler (00:33:41 - 00:33:44)

Und was hast du Computerbildschirm technisch?

Andy Grunwald (00:33:44 - 00:33:54)

Computertechnisch bin ich auf einem MacBook Pro M1 unterwegs. Bildschirm ist ein riesen Bildschirm. Ich weiß gerade gar nicht wie viel Zoll. Auf jeden Fall sehr groß.

Wolfi Gassler (00:33:54 - 00:34:06)

Ist ja super. Andi schaut gerade, kommt mir vor in alle Richtungen in dem Videocall. Der muss riesig sein. Es hat so ausgeschaut, als hätte er gerade links und rechts in die Ecken von seinem Raum irgendwie geschaut.

Andy Grunwald (00:34:06 - 00:35:23)

Nein, mein Laptop ist links neben meinem großen Bildschirm auf einem Laptop-Stand. Ich habe eine externe Webcam von Logitech 1080p. Ich nutze nicht die Build-In-Kamera von Macbook. Ich arbeite mit der kabellosen Tastatur und dem Trackpad von Apple. Ich bin also ein Apple-Jünger, tut mir leid, aber ich habe mich mal sechs Monate auf einem Thinkpad mit Fedora versucht, da bin ich irgendwie nicht mit warm geworden. Podcast-technisch habe ich einen NT-USB von Rode mit zugehörigen Mikrofon-Arm. Und meine Kopfhörer, da laufe ich entweder auf Apple EarPods oder auf dem Bose QC35 mit Bluetooth. Das ist so mein Setup. Im Büro selbst habe ich noch ein Blackboard, was eigentlich, naja, ein Whiteboard in schwarz ist, mit so Art von Kreidelstiften. Was mir aber enorm wichtig ist, dass man sich auch mehr und mehr bewegt. Das bedeutet, ich bin noch am überlegen, ob ich mir noch irgendwie ein kleines Sportgerät kaufe, so ein kleines Laufband für unter den Schreibtisch oder ähnliches, damit man ein bisschen mehr Bewegung hat, weil da drückt nämlich dann auch der Schuh. Man muss sich halt wirklich zwingen aufzustehen, sich zu bewegen, weil sonst sitzt man hier acht Stunden.

Wolfi Gassler (00:35:24 - 00:35:46)

Jetzt wohnst du eh schon in der Pampa, hast die Natur vor der Tür. Warum gehst du denn nicht raus? Du hast ja ein Handy. Mittlerweile ist es zwar schwierig, immer noch in Deutschland eine sinnvolle Verbindung am Handy zu bekommen oder überhaupt eine Verbindung, wenn man außerhalb von den Großstädten ist. Aber mittlerweile ist es ja so weit, dass du einfach ein Meeting auch draußen machen kannst. Geh doch da zu deinem Fluss. Wie heißt dieser große Fluss?

Andy Grunwald (00:35:46 - 00:35:48)

Geh doch da zu deinem Fluss. Der Fluss heißt Rhein, ja?

Wolfi Gassler (00:35:48 - 00:35:49)

Ja, ja, genau.

Andy Grunwald (00:35:49 - 00:35:52)

Es ist, glaube ich, die meistbefahrenste Wasserstraße in Deutschland.

Wolfi Gassler (00:35:53 - 00:36:09)

Da sieht man wieder dieses Blitzen in Andis Augen, wenn es um den Rhein geht. Ja eben, spazier doch am Rhein und mach da ein Meeting. So wie wir das früher auch bei Trivago gemacht haben, gemeinsam am Rhein spazieren gehen und mal das, was wir jetzt bei Podcast machen, einfach mal am Rhein machen.

Andy Grunwald (00:36:09 - 00:37:31)

Ja, da bin ich ehrlich, das muss ich einfach mehr machen. Ich muss die Flexibilität vom Homeoffice einfach mehr nutzen. Ich muss einfach mit meinem Handy einfach mal mehr rausgehen. Ab und zu mache ich das aus dem Garten heraus, weil ich auch im Garten WLAN habe. Das ist natürlich ganz gut, wenn man halt einen fähigen Laptop hat mit einer großen und langen Akkulaufzeit, weil auch so ein Google Chrome zieht halt in der Videokonferenz schon ein bisschen was an der Batterie. Aber das ist einfach, wo man sich ein bisschen zwingen muss, mehr die Flexibilität wirklich zu nutzen. Mobiltechnisch, ich mache immer einen Hotspot auf, auf meinem Handy, falls ich irgendwo bin und tazza darüber. Und da bin ich dann wirklich ganz normal mit meinem MacBook M1 unterwegs. Würde ich fast sagen, relativ Standard Setup, großer Bildschirm, nichts Spezielles. Ich finde wirklich einen guten ergonomischen Bürostuhl ungemein wichtig, weil das geht direkt auf euren Rücken. Wenn ihr euch wirklich einen kaufen möchtet, schaut mal in irgendwelchen Läden bei euch in der Gegend und Testet den wirklich, weil nicht einfach im Internet irgendwas bestellen. Die Stühle von Ikea sind auch gut, doch wenn ihr wirklich da mal ein bisschen in Ergonomie einsteigt, dann werdet ihr schon merken, dass ein unglaublich guter Stuhl viel wert ist. Und ja, bekommen wir sehr wahrscheinlich auch kostet. Die sind dann nicht günstig. Ich habe gefühlt überall wo Gesundheit draufsteht ist halt alles enorm teuer.

Wolfi Gassler (00:37:31 - 00:37:54)

Und die sind auch gar nicht unbedingt immer die besten. Also da scheiden sich schon auch die Geister. Darum finde ich auch mal draufsetzen einfach und das ausprobieren und einen der gut ist. Aber es muss nicht immer weit über 500 Euro sein nur damit es irgendwie sinnvoll ist. Also es gibt auch kostengünstigere Stühle auch gebrauchte teilweise sehr gute. Aber am Ende muss einfach der Stuhl passen meiner Meinung nach.

Andy Grunwald (00:37:54 - 00:38:03)

Also ich hab jetzt kein Audio Mixgerät oder ähnliches. Super viele Leute haben das ja. Ich hab auch keine Spiegelreflexkamera als externe Webcam.

Wolfi Gassler (00:38:03 - 00:38:05)

So was gibt's.

Andy Grunwald (00:38:05 - 00:38:19)

Super viele Leute, die sich damit mit der Optimierung eines Videos und Audios beschäftigen, machen so was. Ich hab kein Ringlicht hinterm Bildschirm für Beleuchtung. Ich hab hier keine Philips Huey-Lampen für tolles Ambiente. Wie sieht dein Setup aus?

Wolfi Gassler (00:38:21 - 00:41:35)

Ich bin ja ein großer Fan von kostengünstiger Hardware, die aber qualitativ gut ist. Und ich bin auch ein großer Fan, die Sachen sehr lange zu verwenden, solange sie gut funktionieren. Darum verwende ich zum Beispiel auch ein ThinkPad Notebook, was jetzt acht Jahre alt ist. Ist jetzt wirklich langsam in den Jahren gekommen, aber funktioniert immer noch sehr gut. Und ich habe ganz früher eigentlich auch immer mir meine Arbeitsplätze wesentlich besser eingerichtet. Und dann ist irgendwann Trivago gekommen und da habe ich auch noch einen Arbeitsplatz gehabt und irgendwann waren dann meine Teams so groß, dass die über mehrere Stockwerke verteilt waren und die hatte dann diese Philosophie, dass sie einfach gerne auch mit den Teams arbeiten möchte oder bei denen hin und wieder sitzen möchte oder mit den Leuten. Und irgendwann habe ich dann gemerkt, eigentlich dieser Schreibtisch, den ich dort habe, den verwende ich gar nie mehr, weil ich immer irgendwo unterwegs bin oder irgendwo in einem Team sitze. Und am Ende hatte ich eigentlich nur mehr meinen Laptop, den ich immer mit hatte. Ich hatte nicht mal das Netzteil mit und habe mich einfach an irgendeinen Platz gesetzt, wo ein freies Netzteil war und habe dann von dort ausgearbeitet oder habe mir irgendwo eines ausgeliehen. Und das habe ich dann irgendwie weitergelebt. Und wie ich dann auf Reisen war, mehrere Monate lang, habe ich mich eigentlich auch daran gewöhnt, einfach auf einem 14-Zoll-Notebook zu arbeiten. Und das habe ich mir irgendwie beibehalten. Also ich brauche eigentlich wesentlich seltener als externe Displays, weil ich einfach auf den kleinen Displays auch sehr gut arbeiten kann und mir das zurechtgelegt habe. Und das unterstützt mich natürlich bei einem mobileren Lebensstil, wo ich auch aus dem Zug oder so arbeite, wenn ich unterwegs bin. Und das Größte, was ich eigentlich mittlerweile so immer mit mir mitschleppe neben dem Notebook, ist eigentlich dieses Mikrofon. Dieses Podcast-Mikrofon, damit wir ja immer unsere Episoden aufnehmen können. Aber auch das ist eigentlich ein sehr kostengünstiges Samsung-Mikrofon. Kein Kondensator-Mikrofon, sondern ein dynamisches Mikrofon, weil das für das Podcasten meiner Meinung nach besser ist. Aber da muss ich auch sagen, das ist das, was jetzt bei Remote Work für mich am wichtigsten ist, einfach einen guten Ton zu haben und ein sinnvolles Mikro. Weil das stört mich am meisten in so Meetings, wenn du einfach eine schlechte Audioqualität hast. Und das geht einfach extrem auf den Kopf und man bekommt Kopfweh. Und wenn man in langen Meetings ist und 100.000 Geräusche hat und Rückkopplungen. Meiner Meinung nach macht es sehr viel aus, wenn es dann um die Qualität von dem Meeting geht. Und das ist mir eigentlich wichtig, einen guten Ton zu haben. Die Kamera ist viel weniger wichtig, meiner Meinung nach. Und ob das jetzt gut beleuchtet ist, sinnvoll, einigermaßen sinnvoll beleuchtet werden natürlich schon gut. Aber der Ton ist das Wichtigste. Und sonst bin ich da eigentlich sehr mobil unterwegs mit meinem Notebook. Und da habe ich mir das eben zurechtgelegt, dass ich dort auch schnell arbeiten kann, arbeite sehr viel mit so Desktops, die ich wechseln kann, also so virtuellen Desktops, damit ich hin und her springen kann, viel mit Shortcuts. Und da kann ich dann eben auch mobil im Zug zum Beispiel super arbeiten und super produktiv arbeiten. oder aus einem Café oder an den verschiedenen Schreibtischen, auch wenn ich natürlich jetzt irgendeinen Standing-Desk oder so gerne verwende mal, aber ich probiere schon, möglichst mobil zu bleiben. Und ehrlich gesagt, ich sehe jetzt wenig Unterschied in meiner Code-Qualität, die am Ende rauspurzelt, ob ich jetzt einen großen Bildschirm oder einen kleinen Bildschirm habe.

Andy Grunwald (00:41:35 - 00:42:06)

Ja gut, bei der Screen-Größe, ich glaube, da kommt es wirklich ganz darauf an, wie du arbeitest. Du sagtest gerade, du hast sehr viele virtuelle Desktops, wenn du da deinen Workflow angepasst hast, alles super. mehrere Fenster aufzuhaben auf dem großen Screen, speziell auch in der Videokonferenz, wenn du dein Screen shares oder ein paar Codefenster auf hast, mal gegebenenfalls zwei, drei mit einem Terminal etc. Das ist schon hilfreich. Ich kenne auch Leute, die stellen ihren Bildschirm senkrecht, damit die mehr Code auf einem Bildschirm kriegen. Sowas habe ich jetzt auch nicht.

Wolfi Gassler (00:42:06 - 00:42:42)

Also wenn ich vielleicht jetzt wirklich 100% meiner Zeit coden würde, was ja immer weniger wird bei mir, dann würde ich vielleicht auch wieder den größeren Bildschirm auch bevorzugen, weil es schon praktisch ist, aber ich habe ehrlich gesagt gelernt damit auszukommen und wie gesagt, Coding ist bei mir jetzt nicht der Hauptbestandteil meiner Arbeit, würde ich mal sagen und dementsprechend komme ich auf einem kleinen Notebook eigentlich ganz gut aus. Da ist mir eigentlich wichtiger, dass ich einfach mobil bin und jederzeit schnell arbeiten kann. egal wo ich bin, ob ich jetzt im Zug bin, auf irgendeinem Schreibtisch sitze, in einem Café arbeite, bei einem Kunden bin, dass ich da einfach möglichst schnell bin.

Andy Grunwald (00:42:42 - 00:42:52)

Was mir recht wichtig ist, sind so Sachen, die eigentlich gar nicht mit dem Homeoffice beziehungsweise mit einem Computersetup zu tun haben, zum Beispiel Mein Rudergerät finde ich enorm wichtig für mich, dass ich einfach mal.

Wolfi Gassler (00:42:52 - 00:42:58)

Jetzt hast du den Rhein vor der Tür und du brauchst ein Rudergerät wieder daheim, kannst du dich nicht in so ein Boot setzen und dort rudern?

Andy Grunwald (00:42:58 - 00:43:27)

Ich hab hier keinen Steg direkt vor der Tür, das ist das Problem. Und Intervalltraining in einem Rudergerät, in einem Ruderboot auf dem Rhein ist auch ein bisschen schwierig. Nee, aber das ist halt so relativ wichtig für mich, wo man einfach mal 10, 20 Minuten drauf springen kann. Einfach mal ein bisschen was anderes machen kann, aber das zählt jetzt eher nicht zum Equipment. Sucht euch auf jeden Fall irgendwas, damit ihr mal weg vom Screen kommt. Also ein eigener Raum ist unglaublich wichtig, Schreibtisch, Stehschreibtisch, ich benutze ihn jeden Tag.

Wolfi Gassler (00:43:27 - 00:43:45)

Das muss man sich aber natürlich erstmal leisten können, einen eigenen Raum, muss man auch dazu sagen. Weil die wenigsten Leute haben natürlich einen eigenen Office-Raum mit eingeplant, die in einer Wohnung leben oder sich eine Wohnung zugelegt haben. Vor allem, wenn man natürlich irgendwo in der Großstadt lebt, hat man ja selten mit einem Büro geplant, vor Corona zumindest.

Andy Grunwald (00:43:46 - 00:43:55)

Das ist korrekt. Und ich hatte auch sehr viele Kollegen, die haben ihren Bildschirm dann auf dem Küchentisch aufgebaut. Bin mir halt nicht sicher, ob man da konstant wirklich von zu Hause arbeiten kann.

Wolfi Gassler (00:43:55 - 00:44:27)

Kommt wahrscheinlich auf die Umgebung drauf an natürlich. Aber ich glaube, möglich ist alles. Und wie gesagt, ich habe das eigentlich mir so zurechtgelegt, dass ich von überall recht schnell arbeiten kann. Und dadurch bin ich auch nicht verwöhnt, sage ich mal, mit irgendeinem großen Bildschirm, weil sonst hat man eben dieses Problem, ah, mir fehlt Der große Bildschirm-Arme fehlt dieses Gimmick, diese Tools. Und wenn man gar nie auf diesen Zug aufspringt so stark, dann ist man auch weniger anspruchsvoll und kann dann eben auch schnell losstarten. Eine externe Maus ist mir zum Beispiel noch auch wichtig, weil ich bin kein Touchpad-Freund.

Andy Grunwald (00:44:27 - 00:44:47)

Ich habe dieses Apple Trackpad extern und somit bin ich auch eins zu eins im Flow mit dem Trackpad von Apple selbst auf dem MacBook. Es gibt immer wieder Stimmen, die sagen, okay, das ist nicht ergonomisch und so weiter. Ja, das kann vielleicht sein, aber ich habe jetzt noch nie Probleme gehabt und ich mache das schon seit Jahren mit meinem Handgelenk oder ähnliches.

Wolfi Gassler (00:44:47 - 00:45:20)

Also ich glaube auch, dass man da einiges machen kann ergonomisch, aber ich bin da auch der Meinung, lieber eine Stunde weniger arbeiten und dann eine Stunde irgendwo an die frische Luft rausgehen. Im Idealfall hat man einen Berg vor der Tür oder so, wie wenn man in Österreich wohnt, dann kann man das natürlich nutzen, aber man kann auch ihn rein nutzen. Ich bin ja auch immer an den Rhein gegangen, wie ich in Düsseldorf gewohnt habe, ist ja auch okay. Aber ich glaube, das bringt viel mehr, da eine Stunde rauszugehen, anstatt sich irgendwie eine fancy ergonomische Maus zu kaufen im Endeffekt, und dafür aber diese Stunde eben zu arbeiten, anstatt an die frische Luft zu gehen.

Andy Grunwald (00:45:20 - 00:45:24)

Die ganze Hardware, die wir gerade genannt haben, die Wolfgang hat, die ich habe.

Wolfi Gassler (00:45:24 - 00:45:26)

Die Berge meinst du?

Andy Grunwald (00:45:26 - 00:45:48)

Die Berge. Listen wir natürlich in den Show Notes auf. Wir packen auch ein Foto dazu, wie denn unser Schreibtisch so aussieht. Gegebenenfalls müsste man dann aufräumen. Aber vielleicht machen wir auch einfach jetzt gleich einfach mal ein Foto und dann könnt ihr das alles nachlesen. Vier Fragen, einigermaßen gut getimboxt. Das war unsere gemischte Tüte. Wolfgang, wie fandest du das Format als erstes?

Wolfi Gassler (00:45:49 - 00:45:49)

Anders.

Andy Grunwald (00:45:49 - 00:45:54)

Ist das jetzt so, wie ich habe gekocht und du sagst, es schmeckt interessant, oder?

Wolfi Gassler (00:45:54 - 00:46:24)

Ja, das muss ich mir noch überlegen. Aber es ist schon sehr positiv, dass wir es geschafft haben, in der Zeit durch die vier Fragen durchzukommen. Lasst uns auch mal wissen, was ihr so denkt über dieses Format. Schickt uns auf jeden Fall Fragen. Wir sind immer glücklich über die Fragen und werden die auch beantworten im Rahmen von langen Folgen, kurzen Folgen, irgendwo am Rande, wie sich das auch immer ausgeht. Sorry, ausgeht ist schon wieder so ein österreichischer Ausdruck. Versteht wieder niemand. Also wie sich es zeitlich so machen lässt.

Andy Grunwald (00:46:24 - 00:46:28)

Das war es von uns in der heutigen Episode. Wir wünschen euch einen schönen Tag.

Wolfi Gassler (00:46:28 - 00:46:34)

Bis bald. Andi, du kannst doch nicht diese Episode jetzt beenden, ohne unsere ganzen tollen Feedback-Kanäle zu erwähnen.

Andy Grunwald (00:46:34 - 00:46:36)

Lass es einfach weg. Da droppen die Leute eh raus.

Wolfi Gassler (00:46:36 - 00:46:39)

Dir ist jetzt klar, dass ihr das auf keinen Fall rausschneiden würdet.

Andy Grunwald (00:46:39 - 00:46:40)

Das ist mir egal.

Wolfi Gassler (00:46:40 - 00:47:28)

Aber wir könnten ja nochmal wieder erwähnen, dass man uns liken kann. Kann man uns liken? Ja, Sterne vergeben. Aber noch wichtiger wäre eigentlich, anderen Leuten einfach Bescheid zu sagen. wie cool denn der Engineering Kiosk ist. Und wer es weniger cool findet, der kann ja auch noch auf unsere Webseite gehen, engineeringkiosk.dev, da findet man ja eine lange Liste von anderen coolen Podcasts, die man sich dann anhören kann. Also auch diese Liste kann man gerne teilen mit anderen Leuten und die darauf aufmerksam machen, weil am Ende geht es darum, irgendwo Knowledge zu sharen und zu verbreiten. Und ob das jetzt wir sind oder andere Podcasterinnen, ist eigentlich ja wirklich egal. Und damit auch von meiner Seite, ich werde jetzt höchstwahrscheinlich auf den Berg gehen. Zumindest wenn der Nebel sich langsam verzogen hat. Und dann mal dort meine Ergonomie abholen.

Andy Grunwald (00:47:28 - 00:47:35)

Viel Spaß dabei Wolfgang. Ich werde heute auch noch an den Rhein gehen, weil mein Hund mich in diese Richtung zerren wird.

Wolfi Gassler (00:47:35 - 00:47:37)

Dann grüß mir den Rhein doch schön.

Andy Grunwald (00:47:37 - 00:47:40)

Ich bestell schöne Grüße. Tschüss, bis bald. Tschau.