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 allen anderen Bereichen, die damit in Verbindung stehen. Wir, Wolfgang Gassler und Andy Grunwald, sind beide Software Engineers und Engineering Manager, die sich bei ihrer beruflichen Laufbahn bei @trivago kennengelernt haben. Zusammen bringen sie über 30 Jahre Tech-Erfahrung an das Mikrofon und lassen dabei zwei Welten aufeinander prallen: Die Österreichische und akademische Welt von Wolfgang mit der praktischen und deutschen Ruhrpottschnauze von Andy. Ziel des Podcasts ist der Austausch zu (Senior) Engineering Themen und ggf. etwas Selbsttherapie
Wolfgang Gassler, Andy Grunwald

Hochleistungskultur in Teams zu entwickeln und wie viele Führungskräfte diese (unbewusst) sabotierenHochleistungskultur klingt nach Sport, Medaillen und noch mehr Output. In der Tech-Realität endet es aber oft in Druck, KPI-Angst und Teams, die lieber schweigen, statt Probleme offen anzusprechen. Genau dann wird es gefährlich, weil wir scheinbar Performance steigern wollen, in Wahrheit aber psychologische Sicherheit abbauen und damit die Organisation in eine Angstzone schieben.In dieser Interview-Episode holen wir uns dafür Verstärkung von Philip Klasen-Schwidetzki, Coach und Organisationsentwickler sowie Gründer von Troody. Wir nutzen das Modell von Amy Edmondson, psychologische Sicherheit plus Accountability, und übersetzen es in den Alltag von Engineering Teams, Performance Management und Leadership. Du hörst, warum mehr Messen nicht automatisch besser ist, wie du Ziele sauber rahmst, wie Caring und Daring Leadership zusammengehören und welche Sabotagemuster Führungskräfte häufig triggern, zum Beispiel Verantwortung an sich ziehen, Konflikte zu schnell entscheiden oder Teams in eine Komfortzone oder Angstzone kippen lassen.Zum Mitnehmen gibt es Kontrollfragen für ein Selbstassessment, konkrete Formulierungen für Mandate und Pushback im Middle Management, plus ein paar sehr alltagstaugliche Mikrosituationen, die über Team Performance entscheiden.Bonus: Am Ende wartet sogar ein kostenloses Lernprogramm rund um Caring und Daring, Link in den Shownotes, aber nur, wenn du bis dahin nicht schon aus der Komfortzone weggedöst bist.Unsere aktuellen Werbepartner findest du auf https://engineeringkiosk.dev/partnersDas schnelle Feedback zur Episode:

Kennst du diese Situation im Team: Jemand sagt "das skaliert nicht", und plötzlich steht der Datenbankwechsel schneller im Raum als die eigentliche Frage nach dem Warum? Genau da packen wir an. Denn in vielen Systemen entscheidet nicht das nächste hippe Tool von Hacker News, sondern etwas viel Grundsätzlicheres: Datenlayout und Zugriffsmuster.In dieser Episode gehen wir einmal tief runter in den Storage-Stack. Wir schauen uns an, warum Row-Oriented-Datastores der Standard für klassische OLTP-Workloads sind und warum "SELECT id" trotzdem oft fast genauso teuer ist wie "SELECT *". Danach drehen wir die Tabelle um 90 Grad: Column Stores für OLAP, Aggregationen über viele Zeilen, Spalten-Pruning, Kompression, SIMD und warum ClickHouse, BigQuery, Snowflake oder Redshift bei Analytics so absurd schnell werden können.Und dann wird es file-basiert: CSV bekommt sein verdientes Fett weg, Apache Parquet seinen Hype, inklusive Row Groups, Metadaten im Footer und warum das für Streaming und Object Storage so gut passt. Mit Apache Iceberg setzen wir noch eine Management-Schicht oben drauf: Snapshots, Time Travel, paralleles Schreiben und das ganze Data-Lake-Feeling. Zum Schluss landen wir da, wo es richtig weh tut, beziehungsweise richtig Geld spart: Storage und Compute trennen, Tiered Storage, Kafka Connect bis Prometheus und Observability-Kosten.Wenn du beim nächsten "das skaliert nicht" nicht direkt die Datenbank tauschen willst, sondern erst mal die richtigen Fragen stellen möchtest, ist das deine Folge.Bonus: DuckDB als kleines Taschenmesser für CSV, JSON und SQL kann dein nächstes Wochenend-Experiment werden.Unsere aktuellen Werbepartner findest du auf https://engineeringkiosk.dev/partnersDas schnelle Feedback zur Episode:

Hand aufs Herz: Wie viele Domains hast du gekauft, die heute nur noch als jährliche Renew Mail existieren? Genau mit diesem Reality Check steigen wir ein und biegen dann scharf ab: nicht Webdomains, sondern Domain Driven Design.In dieser Episode machen wir DDD greifbar, ohne dass du direkt ein 560-Seiten-Buch heiraten musst. Wir klären, welches Problem Domain Driven Design eigentlich löst, warum Teams in großen Systemen so oft in Spaghetti Code, technische Schulden und Kommunikationschaos rutschen und weshalb eine Ubiquitous Language, also eine gemeinsame, allgegenwärtige Sprache, oft der erste echte Hebel ist.Danach geht es ans strategische Design: Bounded Contexts, Context Mapping, Schnittstellen zwischen Teams und warum das verdächtig nah an Conway's Law, APIs und realen Teamstrukturen ist. Und ja, wir schauen auch auf die taktische Seite: Value Objects, Entities, Aggregates, Repositories, Domain Events, plus der Klassiker aus der Anti-Pattern-Ecke: das anämische Domänenmodell.Wir sprechen außerdem darüber, wie du pragmatisch startest, auch in bestehenden Codebasen, wer das im Team treiben kann, und warum Konsistenz im Naming gerade mit LLMs und AI Coding Tools plötzlich noch mehr zählt als früher.Wenn du wissen willst, ob DDD wirklich Enterprise Buzzword Bingo ist oder einfach der Name für verdammt gute Softwarearchitektur, dann bleib dran.Unsere aktuellen Werbepartner findest du auf https://engineeringkiosk.dev/partnersDas schnelle Feedback zur Episode:

Produktmanagement wird dauernd erwähnt, aber selten wirklich erklärt. Und genau da entsteht oft der Frust: Feature Requests prasseln rein, das Jira Backlog wächst wie Unkraut, Stakeholder eskalieren, und am Ende fragt sich jede:r im Team, wer hier eigentlich was entscheidet. Klingt bekannt? Dann ist diese Episode für dich.In dieser Episode schließen wir eine längst überfällige Lücke und steigen tief in das Thema Produktmanagement ein. Zu Gast ist Michael Gasch, Product Manager bei AWS im Serverless Umfeld. Mit ihm schauen wir uns an, was Produktmanagement wirklich ist, warum es nicht einfach Projektmanagement mit neuem Label ist und wie AWS Rollen wie PMT, SDM und TPM trennt, um Delivery, Priorisierung und Ownership sauber zu verzahnen.Wir sprechen über Working Backwards und PR/FAQ Dokumente, datengetriebene Priorisierung unter Dauerbeschuss, Paper Cuts vs. große Launches, Disagree and Commit, Bias for Action und wie Erfolg nach einem GA Launch über Metriken, Telemetrie und Kundenfeedback messbar wird. Als Praxisbeispiel nehmen wir ein echtes AWS Feature: Durable Functions in AWS Lambda, von der Idee im Kopf bis zur AWS re:Invent Bühne.Zum Schluss gibt es noch ein paar Tips:Wie kannst du proaktiver in Produktentscheidungen werden, bessere Inputs liefern und vielleicht sogar selbst Richtung Produktmanagement wechseln?Spoiler: Anforderungsanalyse, Ownership und ein bisschen STAR Methode können viel bewegen.Bonus: Wenn du dachtest, AI macht Produktmanager:innen überflüssig, warten hier ein paar ziemlich gute Gegenargumente auf dich.Unsere aktuellen Werbepartner findest du auf https://engineeringkiosk.dev/partnersDas schnelle Feedback zur Episode:

4 coole Sprachfeatures von Ada, F#, Go und PHPKennst du noch die Zeit, in der du Syntax, Standard Libraries und Edge Cases mühsam zusammengoogelt hast, statt einfach die KI zu fragen? Und wenn die KI heute sowieso Code schreibt, ist es dann überhaupt noch wichtig, mehrere Programmiersprachen zu kennen?Genau da steigen wir ein. Nicht als Sprachkrieg, sondern als Nerd-Tour durch vier Sprachfeatures, die dir Bugs, Security Incidents und Einheitenchaos ersparen können. Wir starten mit Ada und Type Ranges, also Typen mit eingebauten Wertebereichen, inklusive eines Crashes der Ariane-5-Rakete, eines Integer-Overflow und Compile-Time-Checks. Danach geht es zu F und Units of Measure, wo Meter, Sekunden oder sogar Geldbeträge Teil des Typensystems werden und der Compiler dich vor dem Mars Climate Orbiter Moment bewahrt. Dann schauen wir auf PHP und SensitiveParameters, damit Secrets nicht mehr fröhlich in Stack Traces und Logs auftauchen. Und zum Schluss landen wir bei Go: Secret Mode als Security Feature für Forward Secrecy, damit Schlüssel nach dem Handshake wirklich aus dem Speicher verschwinden. Außerdem gibt es ein GitHub-Repo mit Demos in Docker-Containern, damit du die Features in wenigen Minuten selbst anfassen kannst.Wenn du auf Open Source, Tech Community-Austausch und praktisches Knowledge Sharing stehst, wirst du hier Spaß haben. Und wenn du nach der Episode denkst, du hast noch ein besseres Sprachfeature, dann schick es rüber; wir sammeln das.Bonus: Wir schaffen es, von Raketencrash bis hin zu Secret Leaks zu kommen, ohne JavaScript als Gewinner zu küren. Knapp jedenfalls.Unsere aktuellen Werbepartner findest du auf https://engineeringkiosk.dev/partnersDas schnelle Feedback zur Episode:

Performance Reviews. Schon beim Wort ziehen sich bei vielen die Schultern hoch: zu viel Bürokratie, zu wenig Fairness, zu viel Politik und am Ende bleibt das Gefühl, dass eine Note mehr über das System sagt als über deine Arbeit.In dieser Episode drehen wir das einmal um. Wir schauen uns an, wie Performance Reviews wirklich funktionieren, warum sie in der Tech-Welt so oft anecken und wie du sie als Engineering Manager, aber auch als Individual Contributor aktiv für dich nutzen kannst.Wir sprechen über Ziele wie Feedback, Wachstum und Dokumentation, über Subjektivität, Bias und die Frage, warum "wer schreibt, der bleibt" im Alltag leider erschreckend oft stimmt. Dazu nehmen wir konkrete Modelle auseinander: Peer-Feedback, 360-Grad-Feedback, Self-Assessments, Kalibrierungsrunden und die heikle Kopplung von Gehalt und Beförderungen. Plus: Wie du Glue Work sichtbar machst und warum Outcome fast immer mehr zählt als Output.Wenn du dieses Jahr nicht im Review überrascht werden willst, ist das hier dein Setup. Und ja, du kannst mehr beeinflussen, als du denkst.Bonus: Wenn du nach der Folge anfängst, Impact zu tracken, hat dein Future-Ich beim nächsten Review deutlich weniger Stress.Unsere aktuellen Werbepartner findest du auf https://engineeringkiosk.dev/partnersDas schnelle Feedback zur Episode:

CTO, der oder die da oben, macht bestimmt nur PowerPoint, oder? Oder ist die Rolle am Ende das schwierigste C-Level, weil du gleichzeitig Tech, Business, Menschen und Politik zusammenhalten musst, ohne zum Bottleneck zu werden?In dieser Episode nehmen wir die CTO-Rolle auseinander, inklusive typischer Missverständnisse. Wir klären, warum ein CTO nicht zwingend der beste Engineer im Raum sein sollte, wie du vermeidest, dass Entscheidungen nur durch ein Schlüsselloch betrachtet werden, und warum gute CTOs vor allem eines tun: zwischen Business und Tech übersetzen, Prioritäten verhandeln und bewusst mit technischen Schulden umgehen.Zu Gast ist Philipp Deutscher, CTO Coach sowie Fractional und Interim CTO, also CTO as a Service. Er bringt Erfahrung aus IT Operations, DevOps und Platform Engineering mit und teilt konkrete Einblicke aus der Praxis: von CTO-Archetypen wie Founding CTO, Scale-up CTO, Corporate CTO und Field CTO bis hin zu den Unterschieden zwischen Interim- und Fractional-CTO. Außerdem sprechen wir über Tech Leadership, Stakeholder Alignment, KPI-Denken (Velocity, DORA Metrics, Availability) und darüber, warum Monitoring oft erst startet, wenn es schon brennt.Wenn du dich fragst, ob CTO ein Karriereziel für dich ist, bekommst du dazu auch eine klare Roadmap: Verantwortung übernehmen, sichtbar werden, die Perspektive wechseln. Und ja, Nine to Five reicht dafür selten.Neugierig, welcher CTO-Typ du wärst und wie du dich darauf vorbereitest? Dann rein in die Episode.Bonus: CTO-Titel sind günstig. Die Konsequenzen manchmal nicht.Unsere aktuellen Werbepartner findest du auf https://engineeringkiosk.dev/partnersDas schnelle Feedback zur Episode:

Rate Limiting klingt erstmal wie ein nerviges Nein. In Wahrheit ist es oft der Unterschied zwischen stabiler Plattform und dem Klassiker: kurz ein bisschen Traffic, und plötzlich ist alles down. Denn Systeme scheitern selten an einem Request, sondern fast immer an zu vielen: Retry Storms nach einem Funkloch, Thundering Herd nach einem Cache-Expire, Traffic Amplification in Microservices oder einfach ein Tenant, der als Noisy Neighbor das ganze Haus wachklingelt.In dieser Episode gehen wir gemeinsam tief ins Reliability- und Resilience-Engineering und bauen Rate Limiting von Grund auf. Wir klären, wozu Rate Limiting wirklich da ist, wie es sich von Back Pressure, Graceful Degradation, Fault Isolation und Load Shedding abgrenzt und wo du es in deiner Architektur verankerst: Client, Edge, API Gateway, Sidecar Proxy wie Envoy oder direkt an Ressourcen wie Datenbanken und Queues.Dann wird es konkret: Wir vergleichen die gängigen Strategien und Algorithmen, Fixed Window, Sliding Window, Token Bucket und Leaky Bucket, inklusive Bursts, Fairness und der Frage stateful vs. stateless. Dazu kommt die Realität: Was machst du, wenn der Rate Limiter selbst ausfällt – Fail Open vs. Fail Closed –, und warum das nicht nur Technik ist, sondern auch Produktmanagement, Monetarisierung und Kundenerlebnis.Als Bonus schauen wir auf Best Practices aus der Praxis: wie GitHub und Cloudflare Rate Limits via HTTP-Header kommunizieren, warum standardisierte Header gerade wieder Fahrt aufnehmen und wieso Rate Limiting bei GraphQL-APIs so schnell zur Kostenberechnung im Query-AST wird.Wenn du danach dein System nicht nur schneller, sondern auch stressresistenter machen willst, bist du hier richtig. Und ja, ein resilientes System darf auch mal Nein sagen, damit es morgen wieder Ja sagen kann.Bonus: Manchmal ist der beste Load Test ein einzelner Curl-Befehl zur falschen Zeit.Unsere aktuellen Werbepartner findest du auf https://engineeringkiosk.dev/partnersDas schnelle Feedback zur Episode:

Data as a Product: Was steckt dahinter?Warum ist AI überall, aber der Weg von der Datenbank zu "Wow, das Modell kann das" wirkt oft wie ein schwarzes Loch? Du loggst brav Events, die Daten landen in irgendwelchen Silos, und trotzdem bleibt die entscheidende Frage offen: Wer sorgt eigentlich dafür, dass aus Rohdaten ein zuverlässiges, verkaufbares Datenprodukt wird.In dieser Episode machen wir genau dort das Licht an. Gemeinsam mit Mario Müller, Director of Data Engineering bei Veeva Systems, schauen wir uns an, was Datenteams wirklich sind, wie "Data as a Product" in der Praxis funktioniert und warum Data Engineering mehr ist als nur ein paar CSVs über FTP zu schubsen. Wir sprechen über Teamstrukturen von der One-Man-Show bis zur cross-functional Squad, über Ownership auf den Daten, Data Governance und darüber, wie du Datenqualität wirklich misst, inklusive Monitoring, Alerts, SQL-Regeln und menschlicher Quality Control.Dazu gibt es eine ordentliche Portion Tech: Spark, AWS S3 als primärer Speicher, Delta Lake, Athena, Glue, Airflow, Push-Pull statt Event-Overkill und die Entscheidung für Batch Processing, obwohl alle Welt nach Streaming ruft.Und natürlich klären wir auch, was passiert, wenn KI an den Daten rumfummelt: Wo AI beim Bootstrapping hilft, warum Production und Scale tricky werden und wieso Verantwortlichkeit beim Commit nicht von einem LLM übernommen wird.Wenn du Datenteams aufbauen willst, Data Products liefern musst oder einfach verstehen willst, wie aus Daten verlässlicher Business-Impact wird, bist du hier genau richtig.Bonus: Batchjobs bekommen heute mal ein kleines Comeback.Unsere aktuellen Werbepartner findest du auf https://engineeringkiosk.dev/partnersDas schnelle Feedback zur Episode:

Adventskalender: Making of/Behind the scenes und Community RückblickIm Engineering-Kiosk-Adventskalender 2025 sprechen befreundete Podcaster⋅innen und wir selbst, Andy und Wolfi, jeden Tag kurz & knackig innerhalb weniger Minuten über ein interessantes Tech-Thema.Unsere aktuellen Werbepartner findest du auf https://engineeringkiosk.dev/partnersDas schnelle Feedback zur Episode:

Developer Relations wirkt von außen oft wie eine Bühne, ein Reisekoffer und ein paar Sticker am Messestand. Aber was, wenn genau diese Rolle der stärkste Hebel ist, um dein Produkt besser zu machen, deine Tech-Community ernsthaft aufzubauen und Entwickler:innen wirklich erfolgreich zu machen?In dieser Episode nehmen wir Developer Relations auseinander, ganz ohne Marketing-Buzzword-Bingo. Zu Gast ist Philipp Krenn, Head of Developer Relations bei Elastic. Philipp bringt nicht nur jahrelange DevRel-Praxis mit, sondern auch Community-DNA, von Viennadb-Meetups bis Papers We Love, plus Open-Source-Erfahrung rund um Google Summer of Code und das Elastic-Ökosystem.Wir klären, was DevRel eigentlich ist, wo die Grenze zu Developer Marketing verläuft und warum der wichtigste Unterschied oft die Zwei-Wege-Kommunikation ist: raus in die Community und zurück ins Produktteam. Wir sprechen über den Alltag von Developer Advocates, Konferenzen, Content, Community Support auf Discourse, Reddit, Stack Overflow und Slack und wie man Feedback so sammelt, dass es in Roadmaps landet. Dazu kommt die große Frage: Influencer oder nicht? Und warum der Personenkult für Firmen gefährlich werden kann.Außerdem geht es um Open Source, Meetups, Tech Community, Networking, KPIs ohne falsche Anreize, den DevRel-Hype-Zyklus rund um AI und welche Skills du brauchst, wenn du selbst in Developer Relations einsteigen willst.Am Ende weißt du nicht nur, ob DevRel zu dir passt, sondern auch, wie du als Entwickler:in DevRel wirklich nutzen kannst, ohne nur Socken mitzunehmen.Bonus: Wenn jemand mit Laptop und kaputter Query kommt, ist das für Philipp kein Problem, sondern der Wunschzustand.Unsere aktuellen Werbepartner findest du auf https://engineeringkiosk.dev/partnersDas schnelle Feedback zur Episode:

Selbstmanagement: Weniger To-do-Listen-Stress, mehr ProduktivitätIm Engineering-Kiosk-Adventskalender 2025 sprechen befreundete Podcaster⋅innen und wir selbst, Andy und Wolfi, jeden Tag kurz & knackig innerhalb weniger Minuten über ein interessantes Tech-Thema.Unsere aktuellen Werbepartner findest du auf https://engineeringkiosk.dev/partnersDas schnelle Feedback zur Episode:

Spiele für Softwareentwickler:innen.Im Engineering-Kiosk-Adventskalender 2025 sprechen befreundete Podcaster⋅innen und wir selbst, Andy und Wolfi, jeden Tag kurz & knackig innerhalb weniger Minuten über ein interessantes Tech-Thema.Unsere aktuellen Werbepartner findest du auf https://engineeringkiosk.dev/partnersDas schnelle Feedback zur Episode:

E-Mails wirken simpel – sind aber technisch ein ziemliches Minenfeld. In dieser Adventkalender-Folge tauchen wir in die Welt von SPF, DKIM, DMARC, SRS und ARC ein.Im Engineering-Kiosk-Adventskalender 2025 sprechen befreundete Podcaster⋅innen und wir selbst, Andy und Wolfi, jeden Tag kurz & knackig innerhalb weniger Minuten über ein interessantes Tech-Thema.Unsere aktuellen Werbepartner findest du auf https://engineeringkiosk.dev/partnersDas schnelle Feedback zur Episode:

3 forks und wo sie heute stehen mit Christian Stankowic, Jan Walther & Enrico Bartz aus dem Urlaub im Userspace PodcastIm Engineering-Kiosk-Adventskalender 2025 sprechen befreundete Podcaster⋅innen und wir selbst, Andy und Wolfi, jeden Tag kurz & knackig innerhalb weniger Minuten über ein interessantes Tech-Thema.Unsere aktuellen Werbepartner findest du auf https://engineeringkiosk.dev/partnersDas schnelle Feedback zur Episode:

Tooltips (Tüddelkrams) für Container, Kubernetes und Lets Encrypt/ACME mit Felix, Moritz und Volkmar vom FOCUS ON: DevOps Podcast.Im Engineering-Kiosk-Adventskalender 2025 sprechen befreundete Podcaster⋅innen und wir selbst, Andy und Wolfi, jeden Tag kurz & knackig innerhalb weniger Minuten über ein interessantes Tech-Thema.Unsere aktuellen Werbepartner findest du auf https://engineeringkiosk.dev/partnersDas schnelle Feedback zur Episode:

Wer überwacht eigentlich dein Monitoring System? – Dead Man's Switch für dein Alerting.Im Engineering-Kiosk-Adventskalender 2025 sprechen befreundete Podcaster⋅innen und wir selbst, Andy und Wolfi, jeden Tag kurz & knackig innerhalb weniger Minuten über ein interessantes Tech-Thema.Unsere aktuellen Werbepartner findest du auf https://engineeringkiosk.dev/partnersDas schnelle Feedback zur Episode:

Die Balance zwischen Familie, Konzernjob und Side Project.Side Project, Vollzeitjob und dann auch noch Kinder. Klingt nach einer dieser Ideen, die man sonntags feiert und montags bereut. Aber was, wenn genau darin die Energie steckt, die dir im Konzernalltag fehlt? Und was, wenn die größte Challenge gar nicht Zeit ist, sondern Erwartungen, Selbstzweifel und der Druck, immer liefern zu müssen?In dieser Episode sprechen wir mit Stephan, iOS-Software-Engineer bei der Techniker Krankenkasse, Quereinsteiger mit McKinsey-Background, Vater von zwei Kindern und Indie-Developer der Haushaltsbuch-App Monee. Stephan nimmt uns mit in seine Hypercare-Phase als Elternteil, erklärt sein Setup mit Vier-Tage-Woche, Kinderbetreuung und klaren Absprachen und zeigt, wie er ein Side Project so baut, dass es nicht die Familie frisst.Wir gehen tief in Energiemanagement, Autonomie als Motivator, Support-Triage, den Umgang mit Crashs und negativen Reviews sowie in die Realität von Build-in-Public, inklusive Survivorship Bias. Dazu gibt es ehrliche Einblicke darin, wie man als Entwickler:in trotz wenig Zeit dranbleibt, ohne sich selbst zu zerlegen.Wenn du dich fragst, wie du Weiterbildung, Open Source oder ein eigenes Produkt neben Familie und Job realistisch unterkommst, ist das deine Episode.Bonus: Elternlogik des Tages. Ein Kind ist kein Kind. Du bist noch in der Überzahl.Unsere aktuellen Werbepartner findest du auf https://engineeringkiosk.dev/partnersDas schnelle Feedback zur Episode:

Der Ursprung von Foo und Bar mit Wolfgang Schoch von Digitale AnomalienIm Engineering-Kiosk-Adventskalender 2025 sprechen befreundete Podcaster⋅innen und wir selbst, Andy und Wolfi, jeden Tag kurz & knackig innerhalb weniger Minuten über ein interessantes Tech-Thema.Unsere aktuellen Werbepartner findest du auf https://engineeringkiosk.dev/partnersDas schnelle Feedback zur Episode:

Petition: Anerkennung von Open-Source-Arbeit als Ehrenamt in Deutschland mit Boris HinzerIm Engineering-Kiosk-Adventskalender 2025 sprechen befreundete Podcaster⋅innen und wir selbst, Andy und Wolfi, jeden Tag kurz & knackig innerhalb weniger Minuten über ein interessantes Tech-Thema.Unsere aktuellen Werbepartner findest du auf https://engineeringkiosk.dev/partnersDas schnelle Feedback zur Episode:

Offizielle Weiterbildungen in der IT mit Stefan Macke vom IT-Berufe-PodcastIm Engineering-Kiosk-Adventskalender 2025 sprechen befreundete Podcaster⋅innen und wir selbst, Andy und Wolfi, jeden Tag kurz & knackig innerhalb weniger Minuten über ein interessantes Tech-Thema.Unsere aktuellen Werbepartner findest du auf https://engineeringkiosk.dev/partnersDas schnelle Feedback zur Episode:

Heute geht's um zwei Pizzen, ein Team – und warum dein Kopf manchmal wie ein überladener Geschirrspüler klingt. Du erfährst, warum Amazons berühmte Two-Pizza-Rule mehr ist als ein Meme und wie Teamgröße, Kommunikation und Tools deinen Cognitive Load heimlich in die Höhe treiben.Im Engineering-Kiosk-Adventskalender 2025 sprechen befreundete Podcaster⋅innen und wir selbst, Andy und Wolfi, jeden Tag kurz & knackig innerhalb weniger Minuten über ein interessantes Tech-Thema.Unsere aktuellen Werbepartner findest du auf https://engineeringkiosk.dev/partnersDas schnelle Feedback zur Episode:

Electron-Apps mit Python mit Dominik Geldmacher und Jochen Wersdörfer vom Python-Podcast.Im Engineering-Kiosk-Adventskalender 2025 sprechen befreundete Podcaster⋅innen und wir selbst, Andy und Wolfi, jeden Tag kurz & knackig innerhalb weniger Minuten über ein interessantes Tech-Thema.Unsere aktuellen Werbepartner findest du auf https://engineeringkiosk.dev/partnersDas schnelle Feedback zur Episode:

Trust Battery mit Andreas Lehr vom Happy Bootstrapping PodcastIm Engineering-Kiosk-Adventskalender 2025 sprechen befreundete Podcaster⋅innen und wir selbst, Andy und Wolfi, jeden Tag kurz & knackig innerhalb weniger Minuten über ein interessantes Tech-Thema.Unsere aktuellen Werbepartner findest du auf https://engineeringkiosk.dev/partnersDas schnelle Feedback zur Episode:

Public Money, Public Code: Wenn es sich um öffentliche Gelder handelt, sollte es auch öffentlicher Code sein.Warum zahlen wir eigentlich doppelt? Wir finanzieren Software mit Steuergeld, aber der Code verschwindet hinter verschlossenen Türen. In dieser Episode sprechen wir über Public Money Public Code: Wenn öffentliche Gelder in Software fließen, sollte der Code als Open Source verfügbar sein. Nicht nur fair für die Allgemeinheit, sondern auch strategisch klug für digitale Souveränität und gegen Vendor Lock-in.Gemeinsam mit unserem Gast Johannes Näder, Senior Project Manager Policy bei der Free Software Foundation Europe, tauchen wir in die Praxis ein. Johannes koordiniert die Initiative Public Money Public Code, berät Verwaltung und Politik und hält Vorträge zu nachhaltiger Beschaffung, Openwashing und digitaler Souveränität. Wir klären die Grundlagen freier Software, warum die vier Freiheiten zählen und wieso die Lizenzfrage nicht optional ist. Danach wird es konkret: Wie öffentliche Vergabeverfahren heute funktionieren, was sich mit der EU-Vergabereform ändern könnte, und wie Behörden statt Lizenzpaketen künftig Entwicklung, Maintenance und Support von Open Source einkaufen können.Wir schauen auf Erfolge und Best Practices: Schleswig-Holstein migriert massenhaft auf LibreOffice, das österreichische Bundesheer ist umgestiegen, München investiert wieder in freie Software. Wir sprechen über ZenDiS, den souveränen Arbeitsplatz OpenDesk und die Code-Plattform OpenCode.Bonus: Wer hätte gedacht, dass das österreichische Bundesheer zum (LibreOffice) Vorreiter wird?Unsere aktuellen Werbepartner findest du auf https://engineeringkiosk.dev/partnersDas schnelle Feedback zur Episode:

Heute geht's um eine dieser unscheinbaren Technologien, die du wahrscheinlich täglich nutzt: UUIDs! Ob in deiner Datenbank, im Betriebssystem oder in verteilten Systemen. Wie und warum funktionieren UUIDs, welche Versionen gibt es und warum ist nicht jede UUID gleich gut für deine Datenbank.. Außerdem: Alternativen wie Snowflake, ULID oder NanoID..Im Engineering-Kiosk-Adventskalender 2025 sprechen befreundete Podcaster⋅innen und wir selbst, Andy und Wolfi, jeden Tag kurz & knackig innerhalb weniger Minuten über ein interessantes Tech-Thema.Unsere aktuellen Werbepartner findest du auf https://engineeringkiosk.dev/partnersDas schnelle Feedback zur Episode:

Warum zum Teufel interessiert man sich für so ein trockenes Thema wie InfoSec? mit Stefan Ebeling und Sven Hauptmann vom Zeroday Podcast.Im Engineering-Kiosk-Adventskalender 2025 sprechen befreundete Podcaster⋅innen und wir selbst, Andy und Wolfi, jeden Tag kurz & knackig innerhalb weniger Minuten über ein interessantes Tech-Thema.Unsere aktuellen Werbepartner findest du auf https://engineeringkiosk.dev/partnersDas schnelle Feedback zur Episode:

XY-Problem: Frag nicht nach deiner Lösung, sondern erklär das Problem.Im Engineering-Kiosk-Adventskalender 2025 sprechen befreundete Podcaster⋅innen und wir selbst, Andy und Wolfi, jeden Tag kurz & knackig innerhalb weniger Minuten über ein interessantes Tech-Thema.Unsere aktuellen Werbepartner findest du auf https://engineeringkiosk.dev/partnersDas schnelle Feedback zur Episode:

Wie man mit Smart Home (Home Assistant) anfängt mit Andrej Friesen und Thomas Wiebe von SmartHütte.Im Engineering-Kiosk-Adventskalender 2025 sprechen befreundete Podcaster⋅innen und wir selbst, Andy und Wolfi, jeden Tag kurz & knackig innerhalb weniger Minuten über ein interessantes Tech-Thema.Unsere aktuellen Werbepartner findest du auf https://engineeringkiosk.dev/partnersDas schnelle Feedback zur Episode:

Was macht eine richtig gute Tech-Kultur aus? Ein Tech-Radar hilft zumindest dabei bzw. ist ein guter Indikator dafür. . Du erfährst, wie moderne Tech-Organisationen technologische Entscheidungen strukturieren, dokumentieren und strategisch einsetzen. Warum ein Tech Radar mehr ist als nur ein Katalog, wie du damit Innovation steuerst und was das Ganze mit Autonomie und Standards zu tun hat – genau das erfährst du hier. Schnapp dir einen Kaffee und tauch ein in eine Folge, die technologische Klarheit schafft und Lust auf mehr macht!Im Engineering-Kiosk-Adventskalender 2025 sprechen befreundete Podcaster⋅innen und wir selbst, Andy und Wolfi, jeden Tag kurz & knackig innerhalb weniger Minuten über ein interessantes Tech-Thema.Unsere aktuellen Werbepartner findest du auf https://engineeringkiosk.dev/partnersDas schnelle Feedback zur Episode:

Open-Source-Contributions jenseits von Code mit Sujeevan Vijayakumaran und Dirk Deimeke vom TILpod.Im Engineering-Kiosk-Adventskalender 2025 sprechen befreundete Podcaster⋅innen und wir selbst, Andy und Wolfi, jeden Tag kurz & knackig innerhalb weniger Minuten über ein interessantes Tech-Thema.Unsere aktuellen Werbepartner findest du auf https://engineeringkiosk.dev/partnersDas schnelle Feedback zur Episode:

Wenn die Digitalisierung fehlschlägt: The London Ambulance System DisasterWas passiert, wenn Politik alles automatisieren will, ein starres Pflichtenheft ohne Tests verabschiedet und eine kleine Agentur in Rekordzeit ein hochkritisches System auf Visual Basic liefern soll? 1992 ging das Notrufsystem des London Ambulance Service mit einem Big Bang Rollout live. Ohne vollwertige Schulung, ohne belastbare Lasttests und ohne echten Backup-Plan. Das Ergebnis: Fehldispatches, endlose Wartezeiten, Ausnahmezustand in der Leitstelle und ein technischer Kollaps durch ein simples Memory Leak.In dieser Episode sprechen wir über den gesamten Projektverlauf vom London Ambulance System Disaster: Von der Zettelwirtschaft mit Förderband über ein überambitioniertes Automatisierungsvorhaben, NIH-Syndrom in der Ausschreibung, unrealistische Deadlines und Budgets, fehlendes Projektmanagement sowie Quality Assurance. Wir beleuchten die Live-Inbetriebnahme im Oktober 1992, GPS- und Statusprobleme in den Ambulanzen, die Exception-Flut auf den Monitoren, das ungetestete Failover und die Folgen für Personal, Vertrauen und Öffentlichkeit.Wir ordnen das Desaster für die Tech Community ein und ziehen Parallelen zu heute: AI- und Cloud-Rollouts ohne Fallback, Fix-forward statt Rollback, End-to-End- und Lasttests mit realistischen Szenarien, SRE-Praktiken, soziotechnische Systeme, UX in kritischen Workflows und die ethische Verantwortung von Entwicklerinnen. Außerdem: moderne Beispiele wie die Boeing 737 Max und Pandemie-Apps, die zeigen, wie zeitlos diese Learnings sind.Bonus: Das Kernsystem lief auf Visual Basic unter Windows 3. Klingt retro, war aber alles andere als ein Retro-Game.Unsere aktuellen Werbepartner findest du auf https://engineeringkiosk.dev/partnersDas schnelle Feedback zur Episode:

Yak Shaving: Warum du dich auf das richtige Problem konzentrieren solltest.Im Engineering-Kiosk-Adventskalender 2025 sprechen befreundete Podcaster⋅innen und wir selbst, Andy und Wolfi, jeden Tag kurz & knackig innerhalb weniger Minuten über ein interessantes Tech-Thema.Unsere aktuellen Werbepartner findest du auf https://engineeringkiosk.dev/partnersDas schnelle Feedback zur Episode:

Kennst du das? Neun Klicks sind blitzschnell, der zehnte hängt gefühlt ewig. Genau da frisst die Tail Latency deine User Experience und der Durchschnittswert hilft dir kein bisschen. In dieser Episode tauchen wir in Request Hedging ein, also das bewusste Duplizieren von Requests, um P99 zu drücken und Ausreißer zu entschärfen.Wir starten mit einem kurzen Recap zu Resilience Engineering: Timeouts, Retries, Exponential Backoff, Jitter, Circuit Breaker. Danach gehen wir tief rein ins Hedging: Was ist der Hedge Threshold, warum optimieren wir auf Tail statt Head Latency und wie Perzentile wie P50, P95 und P99 die Sicht auf Performance verändern. Wir zeigen, wie du Hedging sicher umsetzt, ohne dein Backend zu überlasten, wo Idempotenz Pflicht ist und warum Schreibzugriffe besonders heikel sind.In der Praxis klären wir, wie du Requests sauber cancelst: HTTP 1.1 via FIN und Reset, HTTP 2 mit RESET_STREAM, gRPC Support und wie Go mit Context Cancellation nativ hilft. Zum Tooling gibt es echte Beispiele: Envoy als Cloud-native Proxy mit Hedging, gRPC, Open Source Erfahrungen. In der Datenbankwelt sprechen wir über Read Hedging, Quorum Reads und Write-Constraints bei Cassandra und Kafka, über Vitess im MySQL-Universum und Grenzen von PG Bouncer. Auch Caches wie Redis und Memcached sowie DNS Patterns wie Happy Eyeballs sind am Start. Historisch ordnen wir das Ganze mit The Tail at Scale von Jeff Dean ein und schauen, wie Google, Netflix, Uber, LinkedIn oder Cloudflare Hedging verwenden.Am Ende nimmst du klare Best Practices mit: Hedging gezielt auf Tail Latency einsetzen, Requests wirklich canceln, Idempotenz sicherstellen, dynamische Thresholds mit Observability füttern und deine Guardrails definieren.Neugierig, ob Hedging dein P99 rettet, ohne dich selbst zu ddosen? Genau darum geht es.Bonus: Hedgehog hat damit nichts zu tun, auch wenn der Name dazu verführt.Keywords: Resilience Engineering, Request Hedging, Tail Latency, P99, Perzentile, Microservices, HTTP 2, gRPC, Go Context, Observability, Monitoring, Prometheus, Grafana, Envoy, Open Source, Cassandra, Kafka, Vitess, Redis, Memcached, Quorum Reads, Tech Community, Networking.Unsere aktuellen Werbepartner findest du auf https://engineeringkiosk.dev/partnersDas schnelle Feedback zur Episode:

SOLID: Single-Responsibility, Open-Closed, Liskovsche Substitution, Interface-Segregation und Dependency-InversionSOLID klingt nach Fels in der Brandung, fühlt sich in der Praxis aber oft nach Abstraktionspyramide an. Brauchen wir die fünf Prinzipien heute noch oder bremsen sie uns beim Time-to-Market aus? In dieser Episode gehen wir genau dieser Frage nach und nehmen dich mit von der nicht ganz offiziellen SOLID-Entstehungsgeschichte über die wichtigsten Prinzipien bis hin zur ehrlichen Einordnung zwischen Clean Code, Teamrealität und AI-Overengineering.Wir starten mit dem S wie Single Responsibility und zerlegen den klassischen UserService: Was gehört rein, was raus, warum Utils-„Mülleimer“ gefährlich sind und wieso Komposition in der Praxis oft die bessere Wahl ist. Danach das O wie Open-Closed mit zwei greifbaren Beispielen: Rabattlogik ohne if-Hölle und Zahlungsanbieter-Design zwischen Switch Case und Strategie. Beim L wie Liskov Substitution wird es historisch und konkret: Barbara Liskov, Turing Award, Rechteck–Quadrat und die Frage, warum protected so oft Kapselung sprengt. Beim I wie Interface Segregation feiern wir kleine, fokussierte Interfaces, Duck Typing und die Go-Philosophie. Und beim D wie Dependency Inversion klären wir den Unterschied zu Dependency Injection, zeigen Injection-Varianten und warum Tests dadurch so viel leichter werden.Wir ordnen ein, wo SOLID glänzt und wo es Grenzen hat: Overengineering durch zu viele Klassen, DI-Container-Magic, ORMs, Microservices als Fehlinterpretation von SRP sowie der gesunde Trade-off zwischen sauberen Contracts und schneller Lieferung. Dazu Teamkultur statt Dogmatismus, Clean Code ohne Religion und die Erkenntnis, dass gute Architektur vor allem durch Datenflüsse, Domain-Zuschnitte und klare Systemgrenzen entsteht.Am Ende bleibt ein pragmatisches Playbook: Komposition über Vererbung, kleine Interfaces, klare Contracts, Injection wo es hilft und bewusstes Brechen von Regeln, wenn der Kontext es fordert.Bonus: Side Project-Idee aus der Community-Ecke. Baue einen Fax-zu-Discord-Bot. Wir integrieren ihn. Versprochen.Unsere aktuellen Werbepartner findest du auf https://engineeringkiosk.dev/partnersDas schnelle Feedback zur Episode:

Wie baust du Mobile Games, die nicht nur Spaß machen, sondern auch auf jeder Plattform funktionieren und sich selbst tragen? In dieser Episode sprechen wir über Mobile Gaming: von der Idee über den Game Loop bis zur Monetarisierung. Mit dabei ist Fabi Fink, Game Lead bei Lotum. Lotum steht für Social Casual und Puzzle Hits wie Quiz Planet und Word Blitz, hat die Marke von 1 Milliarde Installationen geknackt und spielt technisch die gesamte Klaviatur von Web bis Native.Wir klären, warum Mobile inzwischen rund die Hälfte des Gaming-Umsatzes ausmacht und ordnen Hypercasual, Casual, Midcore und Hardcore mit vielen Beispielen ein. Wir zeigen, was Mobile heute bedeutet: Native Apps in App Store und Play Store, aber auch Games als Facebook Instant Games sowie Integrationen für Reddit, Discord, TikTok und Netflix. Du erfährst, wie Social Loops auf Plattformen funktionieren, warum asynchrones Multiplayer ein Growth-Hebel ist und was Viralität gegenüber klassischer User Acquisition auszeichnet.Technisch gehen wir tief rein: Warum Lotum für viele Titel auf Vue.js setzt und Game-UX wie eine hochinteraktive Web-App denkt. Wir sprechen über Performance-Details, GPU-freundliche Animationen und warum beim WordBlitz-Core Plain JavaScript die Nase vorn hat. Im Backend wird es handfest mit WebSockets, Redis-Clustern und Realtime-Events in der Google Cloud. Dazu kommen Tools und Plattformen wie Nakama (Open Source Backend for Games) und SpacetimeDB, plus eine ehrliche Kostenstory rund um Firebase.Natürlich geht es auch ums Geld: Ads vs. In-App Purchases, Hybrid-Modelle, ROAS über 180 Tage und was erfolgreiche Titel wirklich auszeichnet. Wir teilen KPI-Realität, A/B-Testing-Erkenntnisse, warum kleine UX-Texte große Effekte haben können und welche Schwelle ein Spiel bei Lotum erreichen sollte, um weiterverfolgt zu werden.Wenn du wissen willst, wie moderne Mobile Games entstehen – technologisch, produktseitig und monetär – schnapp dir diese Episode.Unsere aktuellen Werbepartner findest du auf https://engineeringkiosk.dev/partnersDas schnelle Feedback zur Episode:

Blockiert dein Code Review gerade mal wieder den Release oder ist es der unsichtbare Klebstoff, der Wissen im Team verteilt? In dieser Episode gehen wir der Frage auf den Grund, warum Reviews weit mehr sind als ein einfaches “looks good to me” und was sie mit sozialer Interaktion, Teamdynamik und Wissensverteilung zu tun haben. Wir sprechen mit Prof. Michael Dorner, Professor für Software Engineering an der TH Nürnberg, der seit Jahren zur Rolle von Code Reviews in der Softwareentwicklung forscht: mit Code Review Daten von Microsoft, Spotify oder trivago. Überall zeigt sich: Pull Requests sind mehr als technische Checks, sie sind Kommunikationsnetzwerke. Gemeinsam beleuchten wir, warum Tooling oft zweitrangig ist, wie sich Review-Praktiken historisch entwickelt haben und was das alles mit Ownership, Architektur und sogar Steuern zu tun hat. Ein Blick auf Code Reviews, der dir definitiv eine neue Perspektive eröffnet.Bonus: Wir erklären, warum alle Informatiker Doktoren auch Philosophen sind ;)Unsere aktuellen Werbepartner findest du auf https://engineeringkiosk.dev/partnersDas schnelle Feedback zur Episode:

Technische Schulden: Code veröffentlichen und weiterziehen oder doch erst aufräumen?Technische Schulden fühlen sich oft nach Ballast an, können aber dein stärkster Hebel für Speed sein. Der Knackpunkt ist, sie bewusst und sichtbar einzugehen und konsequent wieder abzubauen. In dieser Episode sprechen wir darüber, wie wir technische Schulden strategisch nutzen, ohne uns langfristig festzufahren.Ward Cunningham sagt: Technische Schulden sind nicht automatisch schlechter Code. Wir ordnen ein, was wirklich als “Debt” zählt und warum Provisorien oft länger leben als geplant. Dann erweitern wir die Perspektive von der Code‑ und Architektur‑Ebene auf People und Prozesse: Knowledge Silos, fehlendes Code Review und organisatorische Entscheidungen können genauso Schulden sein wie ein any in TypeScript. Wir diskutieren sinnvolle Indikatoren wie DORA Metriken, zyklomatische Komplexität und den CRAP Index, aber auch ihre Grenzen. Warum Trends über Releases hilfreicher sind als Einzelwerte oder wie Teamskalierung die Kennzahlen beeinflusst. Dazu die Business Seite: reale Kosten, Produktivitätsverluste, Frust im Team und Fluktuation. Als Anschauung dient der Sonos App Rewrite als teures Lehrstück für akkumulierte Schulden.Wenn du wissen willst, wie du in deinem Team Technical Debt als Werkzeug nutzt, Metriken und Kultur klug kombinierst und den Business Impact sauber argumentierst, dann ist diese Episode für dich.Bonus: Wir verraten, warum Legacy allein keine Schuld ist und wie Open Source, Plattformteams und Standardisierung dir echte Zinsen sparen können.Unsere aktuellen Werbepartner findest du auf https://engineeringkiosk.dev/partnersDas schnelle Feedback zur Episode:

Bug-Management muss man wollen … und können – Teil #2Du kennst das Gefühl: Die Bug-Liste wird immer länger, die Zeit aber immer knapper – und plötzlich stehen Feature-Wünsche und Qualitätsansprüche Kopf an Kopf im Sprint. Willkommen im ganz normalen Entwickler:innen-Wahnsinn!In dieser Episode tauchen wir tief ein in die zweite Runde unseres Bugmanagement-Doppelpacks: Wir klären, wie du mit alternden Bugs umgehst, warum manchmal ein kompletter Bug-Löschantrag oder gar eine „Buginsolvenz“ sinnvoll ist, wie du Frust auf Kundenseite vermeidest und was Priorisierung in der Praxis bedeutet. Wir diskutieren Zero-Bug-Policies, Team-Taktiken fürs gemeinsame Backlog-Aufräumen, Root-Cause-Analysen und Deadlines, die aus harmlosen Fehlerchen plötzlich Release-Blocker machen können. Dabei streifen wir Themen wie Maintenance-Kultur, Feature-vs.-Bugfix-Balance (KTLO vs. Verbesserung), Testing-Strategien von Unit bis Canary Deployment, den Sinn (und Unsinn) von Bugsmash-Days und welche Metriken wirklich zeigen, ob sich der gesamte Aufwand am Ende lohnt.Außerdem nehmen wir die menschliche Seite unter die Lupe: Welche Rollen und Verantwortlichkeiten braucht's eigentlich für ein wirksames Bugmanagement? Wann wird ein Bug zu einem Incident? Und wie schaffst du es, Bugfixing auf Leadership-Ebene gebührend anzuerkennen, statt nur im Schatten der Feature-Entwicklung zu dümpeln?Fun Fact: Je länger ein Bug lebt, desto schwerer wird's mit dem Fix – oder er verschwindet ganz von allein (aka Buginsolvenz).Unsere aktuellen Werbepartner findest du auf https://engineeringkiosk.dev/partnersDas schnelle Feedback zur Episode:

Bug-Management muss man wollen … und können.Jede:r von uns kennt sie: Bugs in der Software. Sie verstecken sich nicht nur in tiefen Architekturentscheidungen oder Skurrilitäten des Nutzerverhaltens. Sie sind Alltag, egal wie viel Testautomatisierung, KI-Unterstützung oder Code-Reviews wir in unseren Prozessen haben. Doch wie gehst du damit um, wenn die Bugliste immer länger wird, dein Team über Jira-Tickets stöhnt und die Frage im Raum steht: Lohnt es sich überhaupt, Bugs systematisch zu managen?In dieser Episode nehmen wir dich mit durch alle Facetten des modernen Bug-Managements. Wir diskutieren, wie Bugs überhaupt entstehen, warum 'Zero Bug'-Versprechen ein Mythos sind und welche Strategien es gibt, Fehler möglichst früh zu finden. Ob durch Beta-Channels, Dogfooding im eigenen Unternehmen oder kreatives Recruiting. Wir tauchen ein in die Welt der Bug Reports: Wie sieht ein richtig guter aus? Welche Infos braucht das Engineering und wie senkst du die Hürden, damit dein Team (und auch die Community) wirklich meldet? Klartext gibt's auch zur Priorisierung: Wie klassifizierst du Bugs nach User-Impact, Komplexität und Business-Wert, anstatt an zu vielen bunten Jira-Feldern zu verzweifeln?Neugierig? Dann bleib dran.Bonus: Unerwartete Funfact-Challenge → Ist schlechte UX ein Bug oder ein Feature?Unsere aktuellen Werbepartner findest du auf https://engineeringkiosk.dev/partnersDas schnelle Feedback zur Episode:

Datenbanken sind das Rückgrat vieler Anwendungen, aber wie konsistent sind deine Daten eigentlich? Egal ob Banküberweisung, Sneaker-Kauf im Online-Shop oder das neueste Side-Project: Oft verbergen sich hinter der vermeintlich „sicheren“ Datenhaltung komplexe Stolperfallen. Wie funktionieren Transaktionen wirklich? Und warum kann ausgerechnet ein falsch gewähltes Isolationslevel zu Dirty Reads, non-repeatable Reads oder sogar zu Write Skew führen?Wir nehmen dich in dieser Episode mit auf eine Reise in die Tiefen der Konsistenzmodelle. Wolfi ist ehemaliger Forscher für Datenbanksysteme an der Uni Innsbruck. Mit ihm steigen wir ein in die Praxis und Theorie; Von Foreign Keys und Check Constraints bis hin zur Multi-Version Concurrency Control (MVCC). Du erfährst, was sich hinter Serializable, Repeatable Read, Read Committed und Read Uncommitted verbirgt und weshalb Tools wie Jepsen immer neue Fehler in selbst „sicheren“ Systemen aufdecken.Am Ende weißt du, warum dich auch als Entwickler:in das Thema Konsistenz, Isolationslevel und Transaktionsmanagement beschäftigen solltest.Bonus: Dirty Reads sind wie Gerüchte: Man hört sie, bevor sie wahr sind… aber was, wenn sie nie stimmen?Unsere aktuellen Werbepartner findest du auf https://engineeringkiosk.dev/partnersDas schnelle Feedback zur Episode:

Client SDKs: Die schöneren APIs?APIs sind das Rückgrat moderner Softwareentwicklung, doch wer kennt nicht das Dilemma? Die API ändert sich, Fehlermeldungen stapeln sich im Postfach, und plötzlich hängt dein Workflow am seidenen HTTP-Thread. Genau dort kommen Client SDKs ins Spiel. Sie machen aus kryptischen API-Endpunkten handliche, sprachnahe Werkzeuge, die dir nicht nur Nerven, sondern auch Zeit sparen.In dieser Episode schauen wir hinter die Kulissen der SDK-Entwicklung. Wir sprechen aus Maintainer-Perspektive über Supportdruck, Burnout und die (oft unterschätzte) Verantwortung in Open Source. Gleichzeitig tauchen wir tief in die Praxis ein: Was ist ein Client SDK genau? Wann lohnt sich Handarbeit, wann die Code-Generation? Warum ist idiomatisches SDK-Design mehr als nur Style – und weshalb boosten einige SDKs wie das von Stripe oder AWS sogar den wirtschaftlichen Erfolg ganzer Unternehmen?Gemeinsam werfen wir einen Blick auf Architektur, Best Practices, Edge Cases, Testing, Dokumentation und Wartung. Und natürlich diskutieren wir, wann ein SDK wirklich sinnvoll ist – und in welchen Fällen du lieber einen simplen HTTP-Aufruf selbst schreibst.Bonus: Wieso Atlassian Merch statt Sponsoring schickt.Unsere aktuellen Werbepartner findest du auf https://engineeringkiosk.dev/partnersDas schnelle Feedback zur Episode:

Wie würdest du ... Open Podcasts … bauen? Architektur- und Design-Diskussion, die zweite.Monolith oder Microservices? Python oder Go? Wer träumt nachts eigentlich vom perfekten ETL-Stack? Als Softwareentwickler:in kennst du das: Daten aus zig Quellen, kapriziöse APIs, Security-Bedenken und der Wunsch nach einem skalierbaren, sauberen Architekturkonzept. Fragen über Fragen und etliche mögliche Wege. Welcher ist “der Richtige”?Genau dieses Szenario nehmen wir uns zur Brust: Wolfi hat mit „Open Podcast“ ein reales Projekt gebaut, das Analytics-Daten aus Plattformen wie Spotify, Apple & Co. zusammenführt. Du willst wissen, wie du verteilte APIs knackst, Daten harmonisierst, Backups sicherst und deine Credentials nicht als Excel-Sheet auf den Desktop legst? Komm mit auf unseren Architektur-Deepdive! Andy wird Schritt für Schritt interviewt und challenged, wie er als Engineer, von API-Strategie über Message Queues bis Security und Skalierung, dieses Problem kreativ lösen würde. Nebenbei erfährst du alles Wichtige über Open-Source-Vorteile, Datenbanken (PostgreSQL, Clickhouse), Backups, Monitoring und DevOps. Das Ganze immer garniert mit Learnings aus der echten Praxis.Unsere aktuellen Werbepartner findest du auf https://engineeringkiosk.dev/partnersDas schnelle Feedback zur Episode:

“Die Remote-Arbeitsweise ist die bessere Office-Arbeitsweise”Remote? Homeoffice? Büro? Die Pandemie hat unsere Art zu arbeiten nachhaltig verändert. Doch wie fühlt sich 100% remote heute wirklich an? In dieser Episode tauchen wir tief ein: Was bedeutet es, wenn das Office keinen festen Platz mehr hat und der Arbeitsweg aus wenigen Schritten zwischen Bett und Schreibtisch besteht? Andy teilt seine Erfahrungen aus mehr als drei Jahren im komplett remote geführten Arbeitsumfeld – mit Teams verteilt über Deutschland, Europa und Asien.Wir sprechen offen darüber, worauf es im Remote Setup im Tech-Bereich wirklich ankommt: Wie unterscheiden sich Remote, Homeoffice, Telearbeit und mobiles Arbeiten juristisch und praktisch? Wie wandelst du Isolation in produktive Freiheit um und wo liegen die Stolpersteine bei sozialer Interaktion, Sichtbarkeit, Networking und Karriere? Was tun gegen das berüchtigte "Out of Sight, Out of Mind" und wie helfen Eigeninitiative, asynchrone Kommunikation und eine Portion Mut zu neuen Routinen? Außerdem geht's um globales Arbeiten über Zeitzonen, Selbstmanagement und die Frage: Ist Remote wirklich für alle die beste Lösung oder doch nur ein spannender Ausflug? Als Bonus gibt es Insights zu Unternehmens-Meetups, virtuelles Teambuilding und Networking-Tricks, die auch introvertierte Entwickler:innen glücklich machen können.Funfact: Wer im Homeoffice keinen Nachbarn zum Quatschen hat, kann auf Meetups setzen – aber Achtung, nach einem Abend Community-Action ist die Batterie schneller leer, als du "Zoom" sagen kannst!Unsere aktuellen Werbepartner findest du auf https://engineeringkiosk.dev/partnersDas schnelle Feedback zur Episode:

Multi-Tenant-Systeme sind besser Single-Tenant-SystemeMultitenant Architekturen sind oft eine unterschätzte Herausforderung in der Softwareentwicklung. Stell dir vor, du betreibst eine Plattform, die tausende Kunden gleichzeitig sauber, performant und sicher bedienen soll – und ein einziger Fehler könnte im schlimmsten Fall alle Daten gleichzeitig gefährden. Klingt nach einem echten Albtraum? Ist es auch! Und genau deshalb tauchen wir in dieser Episode tief in die Welt von Multitenant-Systemen ein.Mit dabei ist Max Schellhorn, AWS Solutions Architect und Experte für SaaS, Cloud und serverless Architekturen. Gemeinsam diskutieren wir, warum Multitenant-Systeme mehr sind als nur ein WHERE-Klausel im SQ-StatementL, wie du echte Daten- und Sicherheitsisolation erreichst, welche Cloud-nativen Mechanismen relevant sind und wie cell-basierte Architekturen im Praxiseinsatz funktionieren.Wir klären was ein klassisches Single-Tenant-Setup ist wann moderne Cell- und Shuffle-Sharding-Konzepte zum Einsatz kommen sollten, räumen mit Mythen auf und liefern handfeste Tipps, wie du als Developer, Cloud Engineer oder CTO dein System flexibel, resilient und kostenoptimiert skalierst – ohne dabei den Fokus auf Security, Margen und Ops zu verlieren. Am Ende weißt du, wie sich Multitenancy modelliert, was wirklich zählt und warum „Multitenant ist das bessere Single Tenant“ mehr als ein Tech-Buzzword ist.Bonus: Im Outro gibt's den vermutlich schlechtesten Gemini-Witz zu Multitenancy.Unsere aktuellen Werbepartner findest du auf https://engineeringkiosk.dev/partnersDas schnelle Feedback zur Episode:

Distributed Denial of Service-Angriffe: Was tun, wenn die Bits zur Waffe werden?Kennst du das Gefühl, wenn deine Seite plötzlich nicht mehr lädt – und du schwörst, irgendwer dreht gerade absichtlich am Rad? Immer schneller, immer größere Bandbreiten, immer mehr Geräte online – verteilte Angriffe sind zum traurigen Alltag geworden. Doch was steckt wirklich hinter dem Buzzword „DDoS“?Wir nehmen dich in dieser Engineering-Kiosk-Episode mit in die Welt der Distributed Denial-of-Service-Attacken – praxisnah, technisch und ohne Panikmache. Als Gast begrüßen wir Stefan Behte. Er ist Vice President Platform & Application sowie Informationssicherheitsbeauftragter bei Babiel, kennt die Absicherung prominenter Webseiten wie die des Deutschen Bundestags aus erster Hand, engagiert sich beim Chaos Computer Club und hat das Buch „Distributed Denial of Service: Angriffe erkennen & abwehren“ geschrieben.Gemeinsam tauchen wir tief ein: Wer sind eigentlich die Täter ― vom Script Kiddie mit Booter-Service bis zur staatlich orchestrierten Cyber-Kampagne? Wie funktionieren Angriffe auf Layer 3/4 bis zur cleveren Business-Logik-Manipulation im Online-Shop? Wie bauen Angreifer Botnetze auf und wie erkennt und mitigiert man den Traffic-Wahnsinn? Wir sprechen über Infrastruktur-Design, sinnvolle DDoS-Protection in Cloud und On-Premise, finanzielle Fallen und smarte Defense-Strategien.Mit dabei: Jede Menge Security-Funfacts (Stichwort: Quakenet! Slowloris im Anzug!), praxisnahe Tools zum Selbertesten und eine Diskussion über KI-Trends und die Zukunft des digitalen Wettrüstens.Bonus: Im Podcast wird live die Engineering-Kiosk-Webseite auf DDoS-Resilienz geprüft – hast du schon getestet, wie robust dein Projekt ist?Unsere aktuellen Werbepartner findest du auf https://engineeringkiosk.dev/partnersDas schnelle Feedback zur Episode:

Ask Me Anything, die Zweite!Eure Fragen, unsere Antworten. Hast du dich schon mal gefragt, wie Entwickler:innen eigentlich ihren riesigen To-Do-Berg organisieren, wie viel Kaffee wirklich durch ihre Venen fließt oder wie man als Papa von drei Kids noch Engagement für Open Source oder Side Projects übrig hat?Was tun wir gegen Overcommitment und Stress? Wie priorisieren wir, damit private Themen, Side Projects & Karriere am Ende halbwegs im Einklang bleiben?Dies sind nur einige Fragen, die wir bekommen haben. Du erfährst u.a.Ob Koffeinkonsum ein Running Gag in der IT ist.Welche Produktivitäts-Tools, Workflows & persönlichen Rituale sind bei uns im Einsatz (Spoiler: Getting Things Done & Remember The Milk sind nicht tot).Warum Sport beim Stressmanagement hilft.Wie Side Projects manchmal sogar zu echten Exits führen, inklusive der Frage aller Fragen: Wie viel ist ein Dev-Projekt wirklich wert?On top reden wir über Podcast-Equipments (Spoiler: Gutes Mikro ab 50€ genügt!), Automatisierung, Videospiele für Entwickler:innen und wozu ein Podcast wirklich Aufwand bedeutet.PS: Podcast hören macht dich zwar nicht produktiver – aber definitiv entspannter.Unsere aktuellen Werbepartner findest du auf https://engineeringkiosk.dev/partnersDas schnelle Feedback zur Episode:

Datacenter oder Besenkammer? Die IT im deutschen MittelstandViele Entwickler:innen und Techies leben in der Cloud-Native-Bubble – doch sieht die Realität des deutschen Mittelstands wirklich so modern aus? Die Antwort: eher selten. In dieser Episode sprechen wir mit Patrick Terlisten, Technik-Geschäftsführer eines klassischen IT-Systemhauses aus Köln. Es geht direkt in die Besenkammer des Mittelstands – dorthin, wo das Rechenzentrum oftmals noch ein Abstellraum und Cloud nur ein Modewort ist.Gemeinsam mit Patrick werfen wir einen ehrlichen Blick auf IT-Infrastruktur abseits von Start-ups: Wie sieht der Alltag zwischen Virtualisierung, Lizenzmodellen und Patchmanagement aus? Welche Rolle spielen „Shadow IT" und Software, für die es längst kein Dev-Team mehr gibt? Und wie kommt der Mittelstand, vom Sozialträger bis zum Maschinenbauer, eigentlich mit Themen wie Cloud, Open Source oder Security klar?Wir diskutieren, warum die Realität oft ganz anders ist als das Hochglanz-Image auf Tech-Konferenzen: Von Kabelsalat über Lizenzen im Abo-Wahnsinn bis hin zu der Frage, wie viel Handwerk tatsächlich noch in IT steckt – und warum klassische Systemhäuser heute genauso mit Entwickler:innen & DevOps zu tun bekommen wie die hippe Startup-Welt. Patrick gibt dabei nicht nur Einblicke in seinen Systemhaus-Alltag, sondern erzählt auch wie sich das IT-Handwerk in Zeiten von Cloud und Hyperscalern verändert.Bonus: IT-Handwerk ist Kabelziehen und Zunft – und Cable Porn bleibt eine Kunst für sich.Unsere aktuellen Werbepartner findest du auf https://engineeringkiosk.dev/partnersDas schnelle Feedback zur Episode:

Personal Security 101: Die Security-Basics für Entwickler*innenDenkst du, Passwortmanager sind in 2025 längst Standard? Dann kennst du vermutlich noch nicht die Realität von vielen Devs. Selbst bei den Profis landen SSH-Schlüssel, API-Keys oder Secrets oft unverschlüsselt auf der Festplatte.In dieser Episode gehen wir zurück zu den Security-Basics. Wir sprechen offen darüber, was wirklich Best Practice ist und was in der Praxis (und bei uns privat) anklang findet. Warum sind Passwortmanager ein echtes Must-have? Wann reicht TOTP – und wann brauchst du Hardware-Tokens wie den Yubikey? Welche Kompromisse gehst du zwischen UX, Sicherheit und „Faulheit“ ein? Außerdem diskutieren wir, wie du SSH-Keys richtig schützt und wie du sensible Umgebungsvariablen verwaltest. Weiterhin klären wir, was Phishing, Typosquatting und homographische Angriffe sind.Engagiere dich in unserer Community, teile deine Security-Stories und verrate uns deine Lieblings-Tools – oder die Hacks, auf die du heute lieber nicht mehr stolz bist. Vielleicht schaffen wir es gemeinsam, Security 2025 ein Stück besser zu machen.Unsere aktuellen Werbepartner findest du auf https://engineeringkiosk.dev/partnersDas schnelle Feedback zur Episode:

Ask Me Anything, die Erste!Du willst wissen, warum JavaScript bei uns manchmal für Bauchschmerzen sorgt? Oder wie wir bei dem rasenden Hype rund um KI & LLMs überhaupt noch den Überblick behalten? Vielleicht brennt dir auch die Frage unter den Nägeln, was wirklich wichtiger ist: Produkt, Gehalt oder Technologie bei deinem neuen Job – und würdest du für den „Purpose“ wirklich auf Geld oder deine Lieblings-Technologie verzichten?In dieser AMA-Episode stellen wir uns euren Fragen. Von Linter-Diskussionen, der Hassliebe zu JavaScript und Typescript, über Jobhopping und geplatzte Side-ProjectsDie Fragen kommen aus unserer Community, die Antworten von uns.Reinhören, mitdenken, Feedback dalassen – und vielleicht kommt eure Frage in der nächsten Runde gleich dran!Bonus: Wie viele Side-Projects passen eigentlich zwischen Hundespaziergang, Open Source und Podcast-Aufnahme?Unsere aktuellen Werbepartner findest du auf https://engineeringkiosk.dev/partnersDas schnelle Feedback zur Episode:

Entscheidungen: Das Metronom unseres (Arbeits-)Alltags und oft eine echte Challenge.Schnell kommt im Team das Gefühl auf: "Nicht schon wieder endlose Diskussionen!" Oder: "Warum dauert das immer ewig?". In dieser Episode nähern wir uns der Entscheidungsfindung von allen Seiten – mit Anekdoten aus unserem Berufsleben, strukturierten Frameworks und konkreten Alltagstipps, die dich und dein Team weiterbringen.Du erfährst: Was unterscheidet eine Typ-1-Entscheidung von einer Typ-2-Entscheidung und warum hilft dieses Framework, endlich etwas auf die Straße zu bringen? Wir sprechen über Jeff Bezos, die RACI-Matrix, Runbooks und Standard Operating Procedures aus dem Operations-Bereich und Feuerwehr-Einsätzen und warum schnelle, aber gut dokumentierte Beschlüsse im Engineering Gold wert sind.Natürlich diskutieren wir auch Dinge wie: Sind synchrone Meetings wirklich der Heilige Gral oder kann Remote-Arbeit sogar für bessere, inklusivere Entscheidungen sorgen? Wie sollten Entscheidungen dokumentiert werden? Warum verlaufen Entscheidungsprozesse oft zäh, selbst wenn es "nur" um das Mittagsessen geht?Bonus: Ob 100% Zustimmung bei Entscheidungen überhaupt realistisch oder bloß ein Meeting-Mythos ist.Unsere aktuellen Werbepartner findest du auf https://engineeringkiosk.dev/partnersDas schnelle Feedback zur Episode: