
Sign up to save your podcasts
Or


Konsistent, Verfügbar und Ausfalltolerant: Wähle zwei - Das CAP-Theorem
Stellt euch vor, ein Handwerker könnte die Dienstleistung schnell, günstig und in hoher Qualität leisten. Wäre dies nicht ein Traum? Leider sind alle drei Eigenschaften in der Realität nicht möglich. Und genau so geht es uns mit dem CAP-Theorem in verteilten Systemen mit Datenhaltung. Speziell im aktuellen Zeitalter mit Cloud Computing, horizontaler Skalierung, weltweiter Verfügbarkeit spielt das CAP-Theorem eine essentielle Rolle.
Wie soll sich dein System verhalten, wenn die Netzwerk-Verbindung zwischen deinen Compute-Knoten ausfällt? Muss die Datenhaltung konsistent bleiben? Oder sind Inkonsistenzen für eine gewisse Zeit OK, dafür hat die Verfügbarkeit eine höhere Priorität? Um diesen Konflikt geht es in dieser Episode.
Bonus: Auf GCP kannst du deine Compute-Instanz auf maximal 12 TB SSD Disk (ohne Netzwerk-Storage) aufstocken.
Das schnelle Feedback zur Episode:
👍 (top) 👎 (geht so)
Feedback (gerne auch als Voice Message)
Gerne behandeln wir auch euer Audio Feedback in einer der nächsten Episoden, einfach Audiodatei per Email oder WhatsApp Voice Message an +49 15678 136776
(00:00:00) Intro
(00:01:16) Das CAP-Theorem
(00:03:37) Verteilte Systeme, Datenhaltung und State
(00:08:17) Was ist das CAP-Theorem?
(00:09:52) Info/Werbung
(00:11:15) Was ist das CAP-Theorem?
(00:13:10) Das C in CAP: Consistency
(00:15:12) Das A in CAP: Availability
(00:16:16) Das P in CAP: Partition Tolerance
(00:18:55) Der Problemfall in verteilten Systemen
(00:20:41) Was bedeutet es, wenn ein verteiltes System alle drei Eigenschaften erfüllen würde
(00:22:56) Wo kommt das CAP-Theorem her? Das Brewer Theorem, ACID und BASE
(00:31:50) Ausprägung CP: Consistency und Partition Tolerance
(00:33:31) Ausprägung AP: Availability und Partition Tolerance
(00:36:34) Ausprägung AC: Availability und Consistency
(00:37:16) Das CAP-Theorem im Fehlerfall: PACELC
(00:41:07) Das CAP-Theorem und die Praxis
(00:43:00) MongoDB
(00:45:13) Cassandra
(00:46:36) Kubernetes
(00:49:38) Kafka
Inner Source - Die Anwendung von Open Source Best Practices in deiner Organisation
Jede Firma und jeder Entwickler⋅in hat Berührungspunkte mit Open Source. Direkt oder indirekt durch verwendete Libraries, Server-Systeme oder Ähnliches. Wie die Open-Source-Szene funktioniert, ist auch irgendwie faszinierend. Personen, die sich nicht kennen, arbeiten weltweit und asynchron, relativ effizient zusammen und erschaffen zusammen Großes.
Inner Source hat zum Ziel, die besten Praktiken aus Open Source in einer geschlossenen Organisation zu nutzen. Doch was bedeutet dies eigentlich?
Dazu haben wir mit Sebastian Spier gesprochen. Wir steigen tiefer ein und klären, was Inner Source ist, welchen Vorteil eine Organisation bei der Anwendung von Inner Source hat, ob Inner Source ohne Open Source Erfahrung möglich ist, ob interne Firmenpolitik dadurch reduziert werden kann und welcher Support vom Leadership und vom Team eigentlich notwendig ist.
Bonus: Kneipenguide.de wurde in Perl geschrieben.
Das schnelle Feedback zur Episode:
👍 (top) 👎 (geht so)
Feedback (gerne auch als Voice Message)
Gerne behandeln wir auch euer Audio Feedback in einer der nächsten Episoden, einfach Audiodatei per Email oder WhatsApp Voice Message an +49 15678 136776
(00:00:00) Intro
(00:01:13) Open Source in Organisationen: Inner Source mit Sebastian Spier
(00:03:39) Was ist Inner Source?
(00:04:04) Info/Werbung
(00:05:23) Was ist Inner Source?
(00:08:42) Pull Requests ohne vorherige Kommunikation
(00:11:27) Was ist die Inner Source Commons Foundation?
(00:14:44) Welche Vorteile hat Inner Source?
(00:18:44) Spielt Inner Source ein Element in Interviews dar?
(00:20:30) Inner Source ohne Open Source Erfahrung
(00:23:56) Wo ist der Unterschied zu Agile und DevOps?
(00:27:59) "Meine Entwickler, meine Arbeitszeit"
(00:30:47) Kann Inner Source die interne Firmenpolitik reduzieren?
(00:33:10) Grundhaltung: Schlechter Code und Rewrite
(00:38:05) Support vom Leadership, der erste kleine Schritt und ein Langzeit-Investment
(00:48:36) Technische Foundations für Inner Source und Cross-Team-Kommunikation
(01:00:39) Forken in Inner Source: Legale Hürden
(01:03:27) Was ist die Empfehlung um mit Inner Source zu starten?
(01:07:30) Inner Source Community und Slack
Green IT und die CO2-Emissionen durch die IT, das Internet und die Software-Entwicklung
Die Klimakrise ist real. Damit wir das ganze Problem in den Griff bekommen, muss jeder mit anpacken. Doch wie viel Einfluss hat die IT mit der Hardware, dem Internet, auf der Client- und Serverseite? Darüber sprechen wir in dieser Episode. Wie lange solltest du deine Hardware nutzen? Was für eine Rolle spielen Display-Technologien wie Oled und LCD? Sind performante Websites mehr Eco-Friendly? Wie sieht es mit Cloud-Infrastruktur, Build- und CI-Pipelines aus? Wie berechnet man die CO2-Emissionen von Gigabit-Datentransfer? Welche ist die grünste Programmiersprache?
Das und noch viel mehr besprechen wir mit unserem Gast Christian "Schepp" Schaefer, der sich mit diesem Thema auseinandergesetzt hat.
Bonus: Wo die dreckigsten Industrieunternehmen Deutschlands stehen.
Das schnelle Feedback zur Episode:
👍 (top) 👎 (geht so)
Feedback (gerne auch als Voice Message)
Gerne behandeln wir auch euer Audio Feedback in einer der nächsten Episoden, einfach Audiodatei per Email oder WhatsApp Voice Message an +49 15678 136776
(00:00:00) Intro
(00:01:16) Dirty Thirty, Green IT und Vorstellung von Christian "Schepp" Schaefer
(00:06:00) Warum liegt dir das Thema Green IT und CO2-Emissionen von Websiten am Herzen?
(00:07:14) Welche Rolle spielt die IT bei den CO2-Emissionen?
(00:07:14) Info/Werbung
(00:16:06) Welche Komponenten spielen bei Green IT eine Rolle?
(00:17:58) Client-Hardware: Herstellung, Nutzungsdauer und Erneuerung
(00:22:56) Client-Hardware: Bildschirme und Display-Technologien
(00:27:15) Website-Frontend: Farbwahl, Web-Performance, Daten-Volumen und Energie-Verbrauch der Runtime
(00:33:20) Kompensation von CO2 durch Bäume
(00:35:36) Bekommt Website-Performance durch Green IT einen höheren Stellenwert?
(00:39:46) Die meist gemachten Performance-Fehler: Asset-Größe, Bildformate und Kompressionen
(00:43:40) Serverseite: Green-Hosting, Carbon Footprint auf GCP, Server erneuern, ARM Prozessoren und Workloads
(01:02:26) Build- und CI/CD Pipelines verbrauchen auch Energie
(01:03:37) CO2-Emissionen pro Einwohner in China und Deutschland
(01:05:01) Effizienz und Energieverbrauch von Programmiersprachen
(01:09:59) Was kann ich tun, um zu helfen?
Die Personalabteilung: Dein strategischer Partner auf Augenhöhe oder dein Feind und Blocker?
Für viele ist die Personalabteilung ein notwendiges Übel. Eine Abteilung, die “halt notwendig ist”. Dennoch kann die HR auch ein Team sein, welches dir eine Menge Arbeit abnimmt und neue Möglichkeiten eröffnet. In dieser Episode sprechen wir mit Patrick Kuster. Patrick hat seine ganze Karriere in verschiedenen Personalabteilungen verbracht und er gibt uns Einblicke in Recruiting-Prozesse, Job-Benefits, Arbeitszeitverkürzung, Sabbaticals, Bildungsurlaub und vieles mehr.
Bonus: Warum Mallorca als 17. deutsches Bundesland nicht von unserem Bildungsurlaub profitiert.
Das schnelle Feedback zur Episode:
👍 (top) 👎 (geht so)
Feedback (gerne auch als Voice Message)
Gerne behandeln wir auch euer Audio Feedback in einer der nächsten Episoden, einfach Audiodatei per Email oder WhatsApp Voice Message an +49 15678 136776
(00:00:00) Intro
(00:00:49) Einblick in die Personalabteilung mit Patrick Kuster
(00:06:25) Der Name "Human Resources" (HR), wenn wir doch mit Menschen arbeiten
(00:08:32) Info/Werbung
(00:10:44) Diversity in der Personalabteilung
(00:12:00) Was hat sich in den letzten 10 Jahren in der HR geändert?
(00:16:25) Hat der Fachkräftemangel den Wert und die Aufgaben der Personalabteilung verändert?
(00:17:42) Was sind die essentiellen Elemente in einem Lebenslauf (CV)?
(00:26:38) Artificial Intelligence (AI) im Recruiting Prozess
(00:29:31) Team- und Company-Fit im Recruiting
(00:34:27) Tipps für Interviews: Das Unternehmen kennen, Zeit nehmen und Fragen vorbereiten
(00:38:48) Eine außergewöhnliche Location für ein Interview
(00:39:29) Job-Benefit: Das Mysterium von unbegrenztem Urlaub
(00:44:51) Arbeitszeitverkürzung: In Teilzeit arbeiten
(00:51:48) Eine Auszeit nehmen: Sabbatical
(00:57:21) Bildungsurlaub
(01:06:26) HR als Strategischer und Sparrings-Partner um weniger zu arbeiten
(01:07:48) Was wünscht sich die HR von uns als Tech-Worker?
(01:12:01) Die Personalabteilung ist nicht euer Feind, sondern euer Ansprechpartner auf Augenhöhe
DORA Metriken: Die Performance-Messung deines Software Development Teams bzw. die Ermittlung des Reifegrades von DevOps in deiner Organisation
Softwareentwicklung ist ein kreativer Beruf. Jedes Projekt ist einzigartig und die geschriebenen Lines of Code sagen wenig über die dafür benötigte Zeit aus. Das Research-Programm DevOps Research and Assessment (DORA) versucht dennoch die Performance eines Software-Entwicklungs-Teams zu messen. Nicht via Lines of Code, sondern auf Basis von Aktivitäten, die Value liefern: Deployment Frequency, Lead Time for Changes, Mean Time to Recovery, Change Failure Rate und Reliability.
Die Metriken selbst sind weit bekannt. Wie diese Metriken beeinflusst werden können, wer eigentlich dahinter steckt, und was die Organisation eigentlich für eine Kultur vorleben muss, damit es überhaupt zu einem positiven Ergebnis kommt, wissen viele nicht. Und genau darüber sprechen wir in dieser Episode.
Bonus: AOL CDs und Metal-Musik aus Litauen
Das schnelle Feedback zur Episode:
👍 (top) 👎 (geht so)
Feedback (gerne auch als Voice Message)
Gerne behandeln wir auch euer Audio Feedback in einer der nächsten Episoden, einfach Audiodatei per Email oder WhatsApp Voice Message an +49 15678 136776
(00:00:00) Intro
(00:00:57) DORA-Metriken und die Liebe zu Daten
(00:04:02) Info/Werbung
(00:05:13) Wofür steht DORA und wer steckt dahinter?
(00:08:02) Was ist DORA und was ist das Ziel?
(00:10:47) DORA Metrik: Deployment Frequency (DF)
(00:14:44) DORA Metrik: Lead Time for Changes (LT)
(00:17:05) DORA Metrik: Mean Time to Recovery (MTTR)
(00:19:51) DORA Metrik: Change Failure Rate (CFR)
(00:20:22) DORA Metrik: Reliability
(00:22:56) High-Performing-Teams und Vergleichbarkeit
(00:27:54) DORA Capabilities und was die Metriken eigentlich beeinflußt
(00:32:09) Generative Organisationskultur nach Westrum (DevOps-Kultur)
(00:34:29) Vergleichbarkeit von Teams, Optimierung und Evaluierung der Metriken
(00:46:32) Wie kann man die DORA-Metriken erfassen?
Die Story von ownCloud und Nextcloud inkl. einer erfolgreichen Firma auf Basis von Open Source
2010 hat Frank Karlitschek die Open Source Software ownCloud als Alternative zu Dropbox gestartet. 2016 hat Frank mit dem Core-Team ownCloud verlassen und seine ursprüngliche Software sowie seine Firma geforkt. Als er diese Story 2018 auf der FOSDEM-Konferenz als Vortrag erzählte, bekam er von der Open Source Community Standing Ovations. In dieser Episode sprechen wir mit Frank über den Grundgedanken von ownCloud, was Nextcloud heute ist, GPL basierte Software im Business-Kontext, das Management eines der größten Open Source Projekte, Lobbyismus und Open Source in der Politik und vieles mehr.
Bonus: ownCloud ist als KDE Projekt gestartet.
Das schnelle Feedback zur Episode:
👍 (top) 👎 (geht so)
Feedback (gerne auch als Voice Message)
Gerne behandeln wir auch euer Audio Feedback in einer der nächsten Episoden, einfach Audiodatei per Email oder WhatsApp Voice Message an +49 15678 136776
(00:00:00) Intro
(00:01:23) OwnCloud, Nextcloud und unser Gast Frank Karlitschek
(00:04:50) Was war der Grundgedanke zur Entwicklung und Gründung von ownCloud?
(00:08:39) Was ist Nextcloud heute?
(00:10:45) Wie waren die ersten paar Wochen nach dem Fork von ownCloud zu Nextcloud?
(00:15:07) Info/Werbung
(00:16:51) Wie wichtig ist es, dass das Management eines Open Source Produktes ein Teil der Open Source Community war?
(00:17:51) Was waren die essentiellen Änderungen am Fork?
(00:22:01) Wie viele Personen arbeiten an der Codebase und Community-Management von Nextcloud?
(00:24:56) GPL-Lizenzierung und wie verdient die Firma hinter Nextcloud Geld?
(00:26:59) Wer sind die Kunden von Nextcloud?
(00:28:42) Skalierbarkeit und Infrastruktur von Großkunden und PHP-Projekten
(00:30:43) Skalierbarkeit von Services und der Firma und Recruiting im Open Source Bereich
(00:33:25) Contributor License Agreement, Intellectual Property (IP) und der Fokus aufs Contributor-Onboarding
(00:39:44) Rein und Rausspringen von Open Source Contributor
(00:42:30) Produkt-Roadmap in einem Open Source Projekt und bei (Enterprise) Kunden
(00:47:31) Nextcloud-Partner, Cloud-Anbieter, kommerzielle Lizenzen und Kunden als Contributor
(00:51:08) Gespräche auf politischer Ebene, Lobbyismus und Zertifizierungen
(00:54:40) Der Kampf gegen Microsoft und Google
(00:56:13) Wie verändert sich die Akzeptanz von GPL-basierter Software und Open Source im kommerziellen Umfeld?
(01:00:06) Wie siehst du den Trend der Open Source Szene?
Der Einstieg in die erste Lead-Position, das Engineering Management, kann beängstigend sein. Viele sagen, es ist ein Jobwechsel und keine Beförderung. Mit dem Wechsel kommen eine Vielzahl neue Aufgaben mit sich, der Arbeitsalltag ändert sich. Doch wie sieht das in der Realität aus? Wie werden diese Herausforderungen gemeistert? Darüber sprachen wir mit der Team Managerin Isabelle Glasmacher.
Wir sprechen über Hands-On Entwicklung als Manager, die Einführung von 1on1s, Feedback-Cycle als Manager vs. Entwickler, Weiterbildung und Workshops, die negativen Seiten des Manager-Daseins, lange TODO-Listen, Überstunden und Fehler, die gemacht wurden.
Bonus: Was eine DIN-Norm und Ö-Norm ist.
Das schnelle Feedback zur Episode:
👍 (top) 👎 (geht so)
Feedback (gerne auch als Voice Message)
Gerne behandeln wir auch euer Audio Feedback in einer der nächsten Episoden, einfach Audiodatei per Email oder WhatsApp Voice Message an +49 15678 136776
(00:00:00) Intro
(00:01:46) Isabelle Glasmacher zum Thema Engineering Management
(00:05:35) Kontext über die aktuelle Rolle: Team-Größe und -Konstellation
(00:08:42) Die optimale Teamgröße, Hands-On, People-Management
(00:11:11) Wie sieht ein normaler Arbeitsalltag bei dir aus?
(00:11:37) Info/Werbung
(00:13:40) 1on1: Sinnhaftigkeit, Zeit, Vorbereitung und Themengebiete
(00:22:54) Engineering Management in verschiedenen Firmen und der Spagat zwischen Team-Manager und Team-Mitglied
(00:27:22) Was man gerne wüsste, wenn man als Manager startet und Managing up
(00:39:06) Das Toolset/Werkzeugkasten eines Managers und Weiterbildung
(00:42:27) Das Hin- und Herspringen zwischen den Jobs als Manager und Software-Developer
(00:46:26) Die negativen Seiten vom Engineering Management, lange TODO-Listen und Priorisierung
(00:56:22) Feedback-Zyklen, Bewertungen und Support bei schwierigen Fällen
(00:58:49) Für wen ist die Engineering Management Rolle nichts?
(01:02:25) Was ist der größte Fehler, den du bereits im Management gemacht hast?
(01:04:21) Probiert den Job als Engineering Manager einfach aus
JavaScript: Eine multiparadigmatische Skriptsprache mit einem schwachen dynamischen Ducktyping-System.
Um die Sprache JavaScript kommt man im Web nicht mehr vorbei. Die meisten kennen sie durch Frameworks wie React, Angular, Vue.js, Next und Co. Doch wie viel weißt du über die Hintergründe und die Weiterentwicklung dieser Sprache?
In dieser Episode geht es nicht um das nächste hippe JavaScript-Framework, sondern wir sprechen mit Peter Kröner darüber, wie JavaScript erfunden wurde, was ECMAScript ist, wie TypeScript in den Mix spielt, warum die Sprache so beliebt ist, wie neue Features den Weg in die Sprache finden, was das TC39 ist, über das Monopol im Browser, verschiedene JavaScript-Engines und viel mehr.
Bonus: Wenn Hamburg im Süden liegt.
Das schnelle Feedback zur Episode:
👍 (top) 👎 (geht so)
Feedback (gerne auch als Voice Message)
Gerne behandeln wir auch euer Audio Feedback in einer der nächsten Episoden, einfach Audiodatei per Email oder WhatsApp Voice Message an +49 15678 136776
(00:00:00) Intro
(00:01:01) Unser Gast: Peter Kröner
(00:04:48) Info/Werbung
(00:06:26) Was ist JavaScript für eine Sprache und was macht sie aus?
(00:08:36) JavaScript als Verbindungs-Sprache zwischen den Welten
(00:10:28) JavaScript auf Textil-Verarbeitungsmaschinen
(00:12:42) Ein npm install nach 10 Jahren
(00:17:02) JavaScript ist Prototyp-basiert, kann aber auch OOP und Funktional
(00:21:45) Was ist der Grund für die große Beliebtheit der Sprache?
(00:23:00) Woher kommt TypeScript?
(00:28:06) Was ist ECMAScript und wie wurde JavaScript erschaffen?
(00:32:10) JavaScript-Features: Deprecation und der Prozess und Einführung von neue Features
(00:43:24) Herausforderungen bei JavaScript auf dem Client vs. auf dem Server
(00:46:00) Warum gibt es so viele Frameworks und Libraries?
(00:48:46) Das verstreute Ökosystem als Einstiegsbarriere
(00:52:01) Wird die JavaScript-Entwicklung immer komplexer?
(01:03:00) Wird die Sprache JavaScript in die richtige Richtung weiterentwickelt?
(01:06:56) Programmiersprachen kopieren Features
(01:10:34) Das Monopol im Browser und fehlende Konkurrenz
(01:16:14) JavaScript Engines
Die Fehlerkultur im Unternehmen, Transparenz in der Kommunikation und eine gewisse Distanz zum Team als Engineering Manager.
Diese Episode ist eins unserer Sommergespräche, bei dem nur eine Seite die Fragen kennt. Wolfi stellt die Fragen:
Was ist eine gesunde Fehlerkultur? Viele Unternehmen werben damit, eine gute Fehlerkultur zu haben, aus Fehlern zu lernen, Wachstumsmöglichkeiten zu bieten und Experimente zu ermöglichen. Doch ist das wirklich so? Werden Fehler transparent und weitreichend geteilt? In wirklich allen Bereichen und nicht nur im Engineering? Da trennt sich die Spreu vom Weizen.
Was darf sich ein Engineering Manager erlauben, mit dem Team zu teilen und wie viel Transparenz ist gesund? Sollte alles direkt mit dem Team geteilt werden? Oder ist eine gewisse Distanz gesund? Wie schlimm ist es, wenn mal beim Feierabendbier etwas raus rutscht? Und kann es einem Lead auch mal schlecht gehen?
All das in dieser Episode. Viel Spaß
Bonus: Wolfgangs Bio Bike und seine CO2-Emissionen
Unsere aktuellen Werbepartner findest du auf https://engineeringkiosk.dev/partners
Das schnelle Feedback zur Episode:
👍 (top) 👎 (geht so)
Feedback (gerne auch als Voice Message)
Gerne behandeln wir auch euer Audio Feedback in einer der nächsten Episoden, einfach Audiodatei per Email oder WhatsApp Voice Message an +49 15678 136776
(00:00:00) Intro
(00:01:21) Kopf frei bekommen nach langer Arbeit
(00:03:10) Fehlerkultur in Firmen und Fehler wiederholen
(00:07:36) Incident Konferenz, Geld verbrennen und die Organisation muss daraus lernen
(00:09:39) Fehlerkultur und Aufbereitung im Engineering Management beim Recruiting, bei Strategie und Priorisierung
(00:18:33) Wie stellt man eine gute Fehlerkultur innerhalb eines Teams her?
(00:20:54) Wie geht man mit seinen eigenen Fehlern im Team um?
(00:24:48) Wie viele (eigene) negative Ansichten werden mit dem Team geteilt?
(00:35:09) Entscheidungen zum positiven wenden, Emotional treiben lassen und distanzierter werden
(00:37:06) Ein Feierabend-Bier zusammen trinken
(00:41:53) Wie geht man mit schlechter Laune um? Wie viel Transparenz ist angebracht?
(00:48:53) Restrukturierungen und die Change-Kurve
(00:57:43) Wir müssen Montag mal reden
Bildung: Einblick in den Dr. Titel im Bereich Informatik.
Bildung ist wichtig. Viele Personen, die im Bereich Informatik und Software-Entwicklung unterwegs sind, haben auch studiert. Bachelor, Master, teilweise sogar einen Dr. Titel. Doch wie wichtig ist der Dr. Titel eigentlich für die Ausübung des Berufes? Brauche ich einen Dr. Titel, um eine gute Programmiererin zu werden? Was bedeutet es eigentlich, einen Dr. Titel zu erlangen? Was muss dafür getan werden? Welche Voraussetzungen muss ich erfüllen? Was kostet mich das ganze und wie finanziere ich mein Leben während dieser Zeit? Und ganz allgemein: Warum brauchen viele Doktoranden so lange?
All diese Fragen beantwortet der Podcast Co-Host Wolfgang, der selbst einen Dr. Titel der Informatik trägt.
Bonus: Die Automatisierung einer Kaffee-Strichliste als Bachelor-Arbeit.
Unsere aktuellen Werbepartner findest du auf https://engineeringkiosk.dev/partners
Das schnelle Feedback zur Episode:
👍 (top) 👎 (geht so)
Feedback (gerne auch als Voice Message)
Gerne behandeln wir auch euer Audio Feedback in einer der nächsten Episoden, einfach Audiodatei per Email oder WhatsApp Voice Message an +49 15678 136776
(00:00:00) Intro
(00:01:01) Akademische Flachwitze und der Dr. Titel in der Informatik
(00:04:05) Was wird für die Erlangung eines Dr. Titels benötigt?
(00:11:14) Grund für die Episode: Soll ich noch einen Dr. Titel dran hängen?
(00:13:10) Welche Kosten entstehen während einer Promotion?
(00:16:41) Industrie Doktoren und Grundlagen vs. Angewandte Forschung
(00:20:15) Eine Anstellung als wissenschaftlicher Mitarbeiter und Geld während des Studiums
(00:27:59) Der Dr. Titel in der Gehaltsverhandlung und Einstiegsbarrieren in die Arbeitswelt
(00:32:52) Gilt man in der Industrie mit einem Dr. Titel als überqualifiziert?
(00:34:01) Ist ein Dr. Titel hilfreich für höhere Managementpositionen?
(00:34:28) Warum dauert eine Promotion so lange und Themenfindung deiner Dissertation
(00:39:17) Pflichten während der Dr. Anstellung: Lehre und Klausuren
(00:40:59) Iterative Forschung in deiner Dissertation, etwas neues erschaffen und Publizierungen
(00:48:24) Das Thema deiner Doktorarbeit ändert sich ständig
(00:49:24) Ist ein Dr. Titel für Spezialisten oder auch für T-Shaped-Personen?
(00:51:46) Wie relevant ist der Dr.-Titel in der heutigen Zeit noch?
(00:58:59) Akademischer Spaß
(01:03:48) Wie realistisch ist ein Dr. neben dem Beruf?
(01:04:55) Würdest du den Dr. erneut anstreben?
(01:05:23) Tipps für angehende Doktoranden
From the publisher's feed
Der Engineering Kiosk ist der deutschsprachige Software-Engineering-Podcast mit Wolfgang Gassler und Andy Grunwald rund um die Themen Engineering-Kultur, Open Source, Menschen, Technologie und…