Engineering Kiosk

Monorepo, Polyrepo, Frontend hier, Backend dort, Mobile-App nochmal woanders. Klingt nach sauberer Trennung, führt in der Praxis aber oft zu genau dem, was wir als Entwickler:innen am wenigsten brauchen: Reibung. Abhängige Pull Requests, aufeinander wartende Releases, doppelte Tooling-Arbeit und jede Menge Koordination zwischen Teams. Die spannende Frage ist also nicht nur, ob Monorepos ein Comeback feiern, sondern ob sie heute, mit besserem Tooling und AI im Rücken, endlich ihr Versprechen einlösen. In dieser Episode sprechen wir mit Max Kless, Senior Software Engineer bei Nx, über den aktuellen Stand von Monorepos. Wir klären, was ein Monorepo eigentlich ist, warum Monorepo nicht gleich Monorepo ist und wieso ein pragmatischer, hybrider Ansatz für viele Teams sinnvoller ist als ein einziges gigantisches Repository. Außerdem schauen wir auf CI, Caching, Project Graphs, Code Ownership, Plattform-Teams und die kulturelle Seite hinter dem Thema. Denn Monorepos sind nicht nur Architektur und Tooling, sondern auch Zusammenarbeit, Standards und ein bisschen Inner Source im Alltag. Besonders spannend wird es bei AI, LLMs und Coding Agents. Wenn mehr Kontext zu besserer Unterstützung führt, werden Monorepos plötzlich wieder hochrelevant. Wir diskutieren, warum ein gemeinsamer Code-Kontext für AI-Systeme ein echter Hebel sein kann, wo die Grenzen liegen und worauf du bei einer Einführung achten solltest. Wenn du wissen willst, ob Monorepos 2026 mehr sind als alter Google-Glanz, dann bist du hier genau richtig. Bonus: Selbst Jenkins bekommt einen kleinen Ehrenmoment. Unsere aktuellen Werbepartner findest du auf https://engineeringkiosk.dev/partners Das schnelle Feedback zur Episode: 👍 (top) 👎 (geht so) Anregungen, Gedanken, Themen und Wünsche Dein Feedback zählt! Erreiche uns über einen der folgenden Kanäle … https://engineeringkiosk.dev/join-discordhttps://www.linkedin.com/company/engineering-kiosk/stehtisch@engineeringkiosk.devhttps://podcasts.social/@engkioskhttps://bsky.app/profile/engineeringkiosk.bsky.socialhttps://www.instagram.com/engineeringkiosk/ Unterstütze den Engineering Kiosk Wenn du uns etwas Gutes tun möchtest … Kaffee schmeckt uns immer https://engineeringkiosk.dev/kaffee Links https://www.linkedin.com/in/max-kless-398530216/https://monorepo.tools/https://nx.dev/https://research.google/pubs/why-google-stores-billions-of-lines-of-code-in-a-single-repository/https://turborepo.dev/https://monorepo.tools/comparehttps://bazel.build/https://www.jenkins.io/ Sprungmarken (00:00:00) Monorepos zwischen Hype, Praxis und AI-Revival (00:06:52) Was ein Monorepo wirklich ist (00:08:37) Info/Werbung (00:09:37) Was ein Monorepo wirklich ist (00:11:02) Monorepo vs. Polyrepo und sinnvolle Grenzen (00:19:07) Der pragmatische Mittelweg statt One Repo to rule them all (00:26:54) Tooling-Grundlagen für Monorepos (00:30:41) Project Graph, Caching und CI-Skalierung (00:41:28) Große Repos, Merge Queues und Git-Features (00:47:34) Monorepos als Kultur- und Organisationsfrage (00:52:32) Einführung, Buy-in und typische Anti-Patterns (00:55:09) Ownership, Plattform-Teams und laufender Aufwand (00:58:24) Warum AI und Coding Agents Monorepos pushen (01:01:55) Kontext, Ownership-Metadaten und praktische Grenzen (01:11:26) Fazit: Wann sich das Monorepo-Experiment lohnt Hosts https://gassler.devhttps://andygrunwald.com/ Community Diskutiere mit uns und vielen anderen Tech-Spezialist⋅innen in unserer Engineering Kiosk Community unter https://engineeringkiosk.dev/join-discord

Agenturen und Freelancer: Stunden tracken vs. Wert-basiert abrechnen Stunden schreiben, Tickets buchen, Angebote schätzen und am Ende trotzdem das Gefühl haben, am eigentlichen Problem vorbeizuarbeiten. Kommt dir bekannt vor? Dann ist diese Episode genau dein Ding. Denn wir gehen einer Frage nach, die viele in Agenturen, im Freelancing und in der Softwareentwicklung beschäftigt. Was passiert, wenn wir nicht mehr primär Zeit verkaufen, sondern Wert? Und warum wird genau diese Frage durch KI, Automatisierung und immer schnellere Delivery plötzlich noch viel relevanter? In dieser Episode sprechen wir mit Christoph, Geschäftsführer der E Commerce Agentur Pixolith, über Agenturgeschäft, Billable Hours, Value Based Pricing, Angebotsphasen, Vertrauen in Kundenprojekten und die Psychologie hinter Preisfindung. Wir schauen auf konkrete Beispiele aus dem E Commerce, auf B2B und B2C Shops, auf Shopware, Shopify, Updates, Migrationen und die Frage, wie sich Wert überhaupt greifbar machen lässt. Außerdem diskutieren wir, warum Scrum diese Abrechnungsfrage nicht löst, wo Goodhart's Law plötzlich sehr praktisch wird und weshalb KI nicht nur Code beschleunigt, sondern auch Beratung, Vertrieb und Delivery verändert. Wenn du verstehen willst, wie Agenturen kalkulieren, warum Stundensätze oft falsche Anreize setzen und wo Value Based Working wirklich funktioniert, bekommst du hier reichlich Stoff zum Mitdenken. Bonus mit Augenzwinkern: Selbst ein Klopapier Shop kann zum strategischen Lehrstück für Pricing, Vertrauen und Softwareprojekte werden. Unsere aktuellen Werbepartner findest du auf https://engineeringkiosk.dev/partners Das schnelle Feedback zur Episode: 👍 (top) 👎 (geht so) Anregungen, Gedanken, Themen und Wünsche Dein Feedback zählt! Erreiche uns über einen der folgenden Kanäle … https://engineeringkiosk.dev/join-discordhttps://www.linkedin.com/company/engineering-kiosk/stehtisch@engineeringkiosk.devhttps://podcasts.social/@engkioskhttps://bsky.app/profile/engineeringkiosk.bsky.socialhttps://www.instagram.com/engineeringkiosk/ Unterstütze den Engineering Kiosk Wenn du uns etwas Gutes tun möchtest … Kaffee schmeckt uns immer https://engineeringkiosk.dev/kaffee Links https://www.linkedin.com/in/christophburchartz/https://www.pixolith.de/https://salao-music.com/https://de.wikipedia.org/wiki/Goodharts_Gesetzhttps://modelthinkers.com/mental-model/goodharts-lawhttps://startupedia.net/de/was-ist/fff-friends-family-and-fools/https://www.agencyuplifted.de/buchhttps://alanweiss.com/shop/books/hardcover/value-based-fees-3rd-edition/https://the-coming-wave.com/ Sprungmarken (00:00:00) Value Based Pricing statt Billable Hours: Worum geht es? (00:05:32) Was eine Agentur eigentlich ist und warum Spezialisierung zählt (00:08:40) Info/Werbung (00:09:40) Was eine Agentur eigentlich ist und warum Spezialisierung zählt (00:14:33) Festpreis, Time and Material und Werkvertrag sauber getrennt (00:20:07) Kundenwert verstehen: Vom angefragten Shop zum eigentlichen Problem (00:23:55) Goodhart's Law: Warum Stundenabrechnung falsche Anreize setzt (00:31:54) Value quantifizieren: Beispiele, Risiken und Preislogik (00:32:37) Vertrauen statt Tickets: Wie wertschätzende Gespräche Projekte formen (00:50:47) Von Aufwand zu Angebot: Mischkalkulation, Intuition und Projektgrößen (00:57:55) Qualität, Pakete und Kundennutzen im Value Based Working (01:04:02) KI in Agenturen: Geschwindigkeit, Beratung und Maintainability (01:09:30) Updates, Migrationen und die Frage nach echtem Value (01:13:26) Der größte Fehler bei der Einführung: Warum die Flatrate scheiterte (01:15:51) Pre-Sales, Pitches und Vertrauen als Wettbewerbsfaktor (01:19:06) Fazit: Mehr Kundennutzen, mehr Verantwortung, mehr unternehmerisches Denken Hosts https://gassler.devhttps://andygrunwald.com/ Community Diskutiere mit uns und vielen anderen Tech-Spezialist⋅innen in unserer Engineering Kiosk Community unter https://engineeringkiosk.dev/join-discord

Git nutzen wir jeden Tag. Aber Hand aufs Herz: Wie viel davon verstehen wir wirklich? Hinter commit, push und pull steckt kein bisschen Magie, sondern ein erstaunlich komplexes System aus Objekten, Referenzen, Protokollen und Designentscheidungen, die bis heute die Softwareentwicklung prägen. Und genau da wird es spannend. Denn Git ist 20 Jahre alt, aber alles andere als fertig entwickelt. In dieser Episode sprechen wir mit Patrick Steinhardt, Git Maintainer, Contributor zu libgit2 und Staff Engineer im Git Team bei GitLab. Gemeinsam tauchen wir tief in die Git Internals ein und klären, warum Git sich gegen Subversion durchgesetzt hat, was ein bare Repository auf der Server-Seite eigentlich macht, wie Clone, Fetch und Push wirklich funktionieren und warum große Repositories, Millionen Referenzen, Binärdateien und Git LFS bis heute echte Herausforderungen sind. Außerdem geht es um Reftables, Partial Clones, Large Object Promises, pluggable object databases, Git History, Interactive Rebase und die Frage, was Git 3.0 mit SHA-256, besserer Usability und moderner Architektur verändern könnte. Wenn du Git bisher vor allem als Werkzeug für deinen täglichen Workflow gesehen hast, bekommst du hier einen Blick unter die Haube, der vieles neu sortiert. Vielleicht hörst du diese Folge als Developer:in mit einem leichten Ich benutze Git seit Jahren Gefühl. Vielleicht gehst du raus mit dem Gedanken: Ich kenne bisher gerade mal die Oberfläche. So oder so, diese Episode ist Pflichtprogramm für alle, die Versionskontrolle, Entwickler-Workflows, Open Source und die Zukunft von Git besser verstehen wollen. Bonus: Danach wirkt selbst git rebase plötzlich fast freundlich. Unsere aktuellen Werbepartner findest du auf https://engineeringkiosk.dev/partners Das schnelle Feedback zur Episode: 👍 (top) 👎 (geht so) Anregungen, Gedanken, Themen und Wünsche Dein Feedback zählt! Erreiche uns über einen der folgenden Kanäle … https://engineeringkiosk.dev/join-discordhttps://www.linkedin.com/company/engineering-kiosk/stehtisch@engineeringkiosk.devhttps://podcasts.social/@engkioskhttps://bsky.app/profile/engineeringkiosk.bsky.socialhttps://www.instagram.com/engineeringkiosk/ Unterstütze den Engineering Kiosk Wenn du uns etwas Gutes tun möchtest … Kaffee schmeckt uns immer https://engineeringkiosk.dev/kaffee Links https://www.linkedin.com/in/patrick-steinhardt-1b16901ba/https://gitlab.com/pks-gitlabhttps://github.com/pks-thttps://subversion.apache.org/https://fosdem.org/2026/schedule/event/HTJK33-evolving_git_for_the_next_decade/lwn.nethttps://lwn.net/Articles/1057561/https://git-scm.com/docs/git-addhttps://git-scm.com/book/en/v2/Git-Tools-Rewriting-Historyhttps://git-scm.com/docs/gitrepository-layout/2.22.0https://www.mercurial-scm.org/https://git-scm.com/docs/git-upload-packhttps://git-scm.com/docs/git-receive-packhttps://git-scm.com/docs/partial-clonehttps://git-scm.com/book/en/v2/Git-Internals-Plumbing-and-Porcelainhttps://marc-stevens.nl/research/shattered.io/https://git-scm.com/docs/reftablehttps://git-lfs.com/https://gitbutler.com/https://github.com/jj-vcs/jj Sprungmarken (00:00:00) Git, Subversion und warum verteilte Versionskontrolle gewann (00:06:12) Info/Werbung (00:07:12) Git, Subversion und warum verteilte Versionskontrolle gewann (00:11:21) Git auf der Serverseite: Bare Repositories und Protokolle (00:17:32) Große Repositories, Packfiles und Skalierung beim Git Hosting (00:20:19) Clone, Fetch und Partial Clone: Was Git wirklich überträgt (00:25:12) Dezentrales Git, zentrale Plattformen und Team-Workflows (00:34:16) Git modernisieren: C, Perl, Rust und der Weg zu Git 3 (00:42:34) Warum Hashes zentral für Git sind: SHA-1 und SHA-256 (00:47:23) Ref Tables: Neue Referenzspeicherung für große Repositories (00:54:40) Large Files, Git LFS und bessere Binary-Workflows (01:01:20) Promisor Remotes, Object Databases und neue Git-Architektur (01:09:37) Git History, Stack Branches und was als Nächstes...

Kann ein Popsong einen Laptop crashen? Und was passiert, wenn ein Ransomware-Angriff nicht nur Fitnessdaten lahmlegt, sondern plötzlich auch Luftfahrt-Workflows und Flight Planning betrifft? Genau mit solchen Fragen steigen wir in dieser Episode ein. Wir schauen auf zwei Security-Fälle, die auf den ersten Blick fast zu verrückt klingen, um wahr zu sein, aber genau deshalb spannend sind. Denn sie zeigen, wie unerwartet Sicherheitsprobleme entstehen und warum Zero Trust, Threat Modeling und Incident Response oft viel breiter gedacht werden müssen, als man zuerst annimmt. In dieser Episode sprechen wir über die legendäre Janet-Jackson-Sicherheitslücke, bei der Resonanz und Schallwellen bestimmte Festplatten aus dem Takt gebracht haben, bis das Betriebssystem mit Kernel Panic reagierte. Danach geht es um den Garmin-Hack von 2020, inklusive Ransomware, Phishing, Social Engineering, Lateral Movement, Backups, Offline-First-Systemen und der Frage, warum die Trennung kritischer Systeme so wichtig ist. Dabei geht es nicht nur um kuriose Storys, sondern um konkrete Learnings für Softwareentwicklung, Security Engineering und den Umgang mit Legacy-Systemen. Wenn du dich für Cybersecurity, Ransomware, Zero Trust, Backup-Strategien, Flight Planning, IoT, Legacy-Hardware und ungewöhnliche Denial-of-Service-Fälle interessierst, bekommst du hier reichlich Stoff zum Mitdenken. Oder anders gesagt: Nach dieser Episode hörst du Musik vielleicht mit etwas mehr Respekt. Vor allem in der Nähe von Spinning Disks. Unsere aktuellen Werbepartner findest du auf https://engineeringkiosk.dev/partners Das schnelle Feedback zur Episode: 👍 (top) 👎 (geht so) Anregungen, Gedanken, Themen und Wünsche Dein Feedback zählt! Erreiche uns über einen der folgenden Kanäle … EngKiosk Community: https://engineeringkiosk.dev/join-discord LinkedIn: https://www.linkedin.com/company/engineering-kiosk/Email: stehtisch@engineeringkiosk.devMastodon: https://podcasts.social/@engkioskBluesky: https://bsky.app/profile/engineeringkiosk.bsky.socialInstagram: https://www.instagram.com/engineeringkiosk/ Unterstütze den Engineering Kiosk Wenn du uns etwas Gutes tun möchtest … Kaffee schmeckt uns immer Buy us a coffee: https://engineeringkiosk.dev/kaffee Links Engineering Kiosk Episode #257 Fischbecken, Jeep, Saugroboter - 3 Hacks, 1 Lesson: Zero Trust: https://engineeringkiosk.dev/podcast/episode/257-fischbecken-jeep-saugroboter-3-hacks-1-lesson-zero-trust/CVE-2022-38392: https://nvd.nist.gov/vuln/detail/CVE-2022-38392Janet Jackson had the power to crash laptop computers: https://devblogs.microsoft.com/oldnewthing/20220816-00/?p=106994Protecting Windows users from Janet Jackson’s Rhythm Nation: https://devblogs.microsoft.com/oldnewthing/20250429-00/?p=111127Evil Corp: https://en.wikipedia.org/wiki/Dridex#Evil_CorpBig Game Hunting durch Cyberangreifer: https://www.crowdstrike.com/de-de/cybersecurity-101/ransomware/big-game-hunting/Hackers toppled Garmin networks: https://www.aopa.org/news-and-media/all-news/2020/july/27/garmin-working-to-resolve-multiday-outageflyGarmin: https://fly.garmin.com/fly-garmin/Iridium (Kommunikationssystem): https://de.wikipedia.org/wiki/Iridium_(Kommunikationssystem)Versicherung muss Garmin Ransomware-Lösegeld erstatten: https://www.inside-it.ch/versicherung-muss-garmin-ransomware-loesegeld-erstatten-20231002 Sprungmarken (00:03:37) Janet Jackson und der akustische Denial of Service (00:05:56) Info/Werbung (00:06:56) Janet Jackson und der akustische Denial of Service (00:08:14) Resonanz, Festplatten und warum Laptops abstürzten (00:14:27) Der Windows-Fix: Audiofilter statt Hardware-Redesign (00:21:14) Security Learnings aus dem Janet-Jackson-Fall (00:26:32) Garmin-Hack 2020: Ransomware mit Folgen für die Luftfahrt (00:29:30) Garmin Pilot, Flight Planning und kritische Infrastruktur (00:32:06) WastedLocker, Phishing und Lateral Movement im Netzwerk (00:37:54) Was wir aus dem Garmin-Vorfall lernen können (00:39:31) Backups,...

Fortran. Eine Sprache von 1957. Und trotzdem taucht sie im TIOBE Index plötzlich auf Platz 12 auf. Zufall, Messfehler oder ein echtes Comeback in High Performance Computing? Wenn du Fortran bisher in die Schublade Legacy und Lochkarten gesteckt hast, wird diese Episode deine Perspektive ziemlich sicher verschieben. In dieser Interviewfolge nehmen wir Fortran auseinander, aber fair. Mit dabei ist Martin Diehl, Professor an der KU Leuven, Materialwissenschaftler und Open-Source-Contributor. Wir klären, warum Fortran für wissenschaftliches Rechnen gebaut wurde, warum Performance und Memory Layout bis heute zählen und weshalb du bei NumPy und SciPy oft indirekt Fortran-Code nutzt. Dazu geht es um Modern Fortran, Rückwärtskompatibilität, Module, Typensystem, Tooling, den Fortran Package Manager FPM sowie neue Compiler wie Flang und L Fortran auf LLVM-Basis. Zum Abschluss wird es HPC konkret. OpenMP für Shared Memory, MPI für Distributed Memory und als Fortran-Spezialität Co Arrays – quasi Shared-Memory-Feelings im Cluster. Wenn du wissen willst, ob Fortran Teil des Problems oder der Lösung im Two-Language-Dilemma ist, dann hör rein. Bonus: Naming is hard, aber F minus minus war schon eine Ansage. Unsere aktuellen Werbepartner findest du auf https://engineeringkiosk.dev/partners Das schnelle Feedback zur Episode: 👍 (top) 👎 (geht so) Anregungen, Gedanken, Themen und Wünsche Dein Feedback zählt! Erreiche uns über einen der folgenden Kanäle … https://engineeringkiosk.dev/join-discordhttps://www.linkedin.com/company/engineering-kiosk/stehtisch@engineeringkiosk.devhttps://podcasts.social/@engkioskhttps://bsky.app/profile/engineeringkiosk.bsky.socialhttps://www.instagram.com/engineeringkiosk/ Unterstütze den Engineering Kiosk Wenn du uns etwas Gutes tun möchtest … Kaffee schmeckt uns immer https://engineeringkiosk.dev/kaffee Links https://martin-diehl.net/https://www.linkedin.com/in/martin-diehl/https://github.com/mardiehlhttps://scholar.google.com/citations?user=ja83swsAAAAJ&hl=dehttps://www.tiobe.com/tiobe-index/https://fortran-lang.org/https://scipy.org/https://numpy.org/https://www.netlib.org/lapack/https://www.openmp.org/https://www.mpi-forum.orghttps://de.wikipedia.org/wiki/Co-array_Fortranhttps://www.youtube.com/watch?v=RUJFd-rEa0khttps://llvm.org/https://julialang.org/https://petsc.org/https://flang.llvm.org/docs/https://fortran-lang.discourse.group/https://fpm.fortran-lang.org/https://top500.orghttps://www.modular.com/mojohttps://damask-multiphysics.orghttps://j3-fortran.orghttps://fortranwiki.orghttps://lfortran.org/ Sprungmarken (00:00:00) Fortran heute: TIOBE Index, Nostalgie und Relevanz (00:06:39) Info/Werbung (00:07:39) Fortran heute: TIOBE Index, Nostalgie und Relevanz (00:09:56) Warum Fortran entwickelt wurde und woher die Sprache kommt (00:14:24) Moderne Fortran Standards und Rückwärtskompatibilität (00:22:21) Fortran in Python: LAPACK, NumPy, SciPy und Performance (00:25:52) Typisierung, Speicherverwaltung und moderne Sprachfeatures (00:30:32) Module, Objektorientierung und Generics in Fortran (00:33:19) High Performance Computing: OpenMP, MPI und Coarrays (00:39:37) Python, Julia, C und das Two Language Dilemma (00:42:39) LLVM, Compilerentwicklung und die Zukunft von Fortran (01:00:27) Community, Package Manager und Onboarding in Fortran Hosts https://gassler.devhttps://andygrunwald.com/ Community Diskutiere mit uns und vielen anderen Tech-Spezialist⋅innen in unserer Engineering Kiosk Community unter https://engineeringkiosk.dev/join-discord

Du willst ein Hardware-Side-Project starten, aber schon der Gedanke an Löten, Platinen und CE-Regeln lässt dich nervös am Kaffee nippen? Willkommen im echten Leben zwischen Breadboard-Euphorie und EMV-Labor-Realität. In dieser Episode merkst du schnell, warum Hardware gleichzeitig super zugänglich und gnadenlos ehrlich ist. Und warum ein einziges Niesen ein ganzes ESP-Modul in den Feierabend schicken kann. Wir nehmen dich mit in die Maker Welt rund um ESP32, ESP8266 und ESPHome, also Open Source Firmware und YAML Konfiguration für IoT Geräte, perfekt für Home Assistant. Andrej Friesen, Smart-Hütte-Podcast-Host und Organizer eines Home-Assistant-Meetups, erzählt die komplette Story hinter PokyPow, einem kleinen Board fürs PC-Frontpanel. Damit kannst du deinen Gaming- oder Home-Server-PC über Home Assistant starten, stoppen, den Power-Button als Sensor nutzen und sogar eine Art Parental Control oder Katzenschutz aktivieren. Dazu gibt es Learnings zu Optokopplern, externer Antenne im PC-Gehäuse, Prototyping mit EasyEDA und JLCPCB sowie Outsourcing über Upwork. Und dann wird es ernst: CE-Kennzeichnung ist keine Zertifizierung, EMV-Tests können von 1700 bis 35000 Dollar kosten, Distribution ist ein eigenes Projekt und CrowdSupply kann Fulfillment, Retouren und Payment abnehmen. Wenn du Bock auf Open Source, Meetups, Tech Community und Networking hast, ist das hier deine Einladung zum Mitmachen. Am Ende bleibt nur ein Motto: "fuck around and find out." Unsere aktuellen Werbepartner findest du auf https://engineeringkiosk.dev/partners Das schnelle Feedback zur Episode: 👍 (top) 👎 (geht so) Anregungen, Gedanken, Themen und Wünsche Dein Feedback zählt! Erreiche uns über einen der folgenden Kanäle … https://engineeringkiosk.dev/join-discordhttps://www.linkedin.com/company/engineering-kiosk/stehtisch@engineeringkiosk.devhttps://podcasts.social/@engkioskhttps://bsky.app/profile/engineeringkiosk.bsky.socialhttps://www.instagram.com/engineeringkiosk/ Unterstütze den Engineering Kiosk Wenn du uns etwas Gutes tun möchtest … Kaffee schmeckt uns immer https://engineeringkiosk.dev/kaffee Links https://www.freertos.org/https://www.zephyrproject.org/https://www.ajfriesen.com/https://www.linkedin.com/in/andrej-friesen/https://github.com/ajfriesenhttps://podcast.smarthuette.de/https://de.wikipedia.org/wiki/ESP8266https://esphome.io/https://www.openhomefoundation.org/https://engineeringkiosk.dev/podcast/episode/203-die-struktur-hinter-dem-weltweit-gr%C3%B6%C3%9Ften-open-source-projekt-mit-pascal-vizeli-von-home-assistant/https://de.wikipedia.org/wiki/Steckplatinehttps://tasmota.github.io/docs/https://www.ajfriesen.com/pc-switch/https://www.youtube.com/watch?v=_qEcm43Lx3chttps://www.home-assistant.io/https://www.shelly.com/https://heinen-elektronik.de/glossar/optokoppler/https://easyeda.com/https://de.wikipedia.org/wiki/Gerber-Formathttps://aisler.net/dehttps://soldered.com/dehttps://www.upwork.com/https://www.upwork.com/https://oxide.computer/blog/building-big-systems-with-remote-hardware-teamshttps://www.youtube.com/watch?v=Pl6o_dtnEMIhttps://hackaday.com/tag/berlin/https://www.crowdsupply.com/ Sprungmarken (00:00:00) ESP Chips und ESPHome: Hardware mit YAML statt C++ (00:07:15) Info/Werbung (00:08:15) ESP Chips und ESPHome: Hardware mit YAML statt C++ (00:14:41) Breadboard, Pins, Protokolle: Schnell Sensoren bauen ohne Elektrotechnik Studium (00:21:51) ESPHome in der Praxis: OTA Flashing, Struktur, Grenzen und Tasmota Vergleich (00:28:42) pokypow erklärt: PC Front Panel Man in the Middle für Home Assistant (00:30:49) Use Cases: Wake on LAN Probleme, Parental Control und Katzen als Edge Case (00:36:42) Vom Prototyp zur PCB: Optokoppler, EasyEDA, Gerber und Bestückung (00:46:11) Der Bruchpunkt: Externe Antenne, Null Ohm Widerstand und Projekt Abbruch (00:52:28) Comeback: Nachfrage, Newsletter und warum Leute lieber kaufen als löten (00:54:08) Hardware auslagern: Requirements schreiben und Prototyping via Upwork (00:59:55)...

Du denkst, dein IoT-Kram ist harmlos: ein Thermometer, ein Staubsaugerroboter, ein bisschen Smart Home. Aber was, wenn genau diese Geräte der perfekte Tunnel aus deinem Netzwerk sind, weil sie selten sauber segmentiert werden, kaum jemand Egress Traffic prüft und Authentifizierung oft mit Autorisierung verwechselt wird? In dieser Episode nehmen wir drei Sicherheitsvorfälle auseinander und ziehen konkrete Learnings daraus: Den Aquarium-Thermometer-Case im Casino mit ungewöhnlichem Outbound Traffic, alternative Exfiltration Kanäle und die Frage, ob IoT wirklich das Einfallstor war oder eher der Exit. Ein Jeep Cherokee Hack von 2015, inklusive offenen Port 6667, DBus-Zugriff, Firmware ohne Signierung, CAN-Bus und einem Diagnosemodus, der plötzlich die Bremsen ausknipst. Ein MQTT Case rund um Staubsaugerroboter, Pub/Sub, Wildcards und fehlende ACLs, also Mandantenisolierung zum Weglaufen.Am Ende bleibt eine unbequeme, aber sehr praktische Checkliste: Segmentierung, Zero Trust, Least Privilege, Monitoring und Logging, Secure Boot und vor allem Egress Traffic als First Class Control. Und jetzt Hand aufs Herz: Was ist deine beste Ausrede, warum dein Netzwerk noch nicht segmentiert ist? Unsere aktuellen Werbepartner findest du auf https://engineeringkiosk.dev/partners Das schnelle Feedback zur Episode: 👍 (top) 👎 (geht so) Anregungen, Gedanken, Themen und Wünsche Dein Feedback zählt! Erreiche uns über einen der folgenden Kanäle … EngKiosk Community: https://engineeringkiosk.dev/join-discord LinkedIn: https://www.linkedin.com/company/engineering-kiosk/Email: stehtisch@engineeringkiosk.devMastodon: https://podcasts.social/@engkioskBluesky: https://bsky.app/profile/engineeringkiosk.bsky.socialInstagram: https://www.instagram.com/engineeringkiosk/ Unterstütze den Engineering Kiosk Wenn du uns etwas Gutes tun möchtest … Kaffee schmeckt uns immer Buy us a coffee: https://engineeringkiosk.dev/kaffee Links ACM Einteilung der Informatik: https://dl.acm.org/ccs Security Week “Hacked Smart Fish Tank Exfiltrated Data to ‘Rare External Destination’”: https://www.securityweek.com/hacked-smart-fish-tank-exfiltrated-data-rare-external-destination/Washington Post “How a fish tank helped hack a casino”: https://www.washingtonpost.com/news/innovations/wp/2017/07/21/how-a-fish-tank-helped-hack-a-casino/Casino Breach - Cyberthrowback Fish Tank Hack: https://rootcat.de/blog/fishtank_jul21/MITRE ATT&CK Database: https://attack.mitre.org/OWASP Top 10:2025: https://owasp.org/Top10/2025/Remote Exploitation of an Unaltered Passenger Vehicle (IOActive whitepaper): https://www.ioactive.com/wp-content/uploads/pdfs/IOActive_Remote_Car_Hacking.pdf Fiat Chrysler Automobiles UConnect allows a vehicle to be remotely controlled: https://www.kb.cert.org/vuls/id/819439 CVE-2015-5611: https://nvd.nist.gov/vuln/detail/CVE-2015-5611 Hackers Remotely Kill a Jeep on the Highway—With Me in It: https://www.wired.com/2015/07/hackers-remotely-kill-jeep-highway/ After Jeep Hack, Chrysler Recalls 1.4M Vehicles for Bug Fix: https://www.wired.com/2015/07/jeep-hack-chrysler-recalls-1-4m-vehicles-bug-fix/Man accidentally gains control of 7,000 robot vacuums: https://www.popsci.com/technology/robot-vacuum-army/ The DJI Romo robovac had security so poor, this man remotely accessed thousands of them: https://www.theverge.com/tech/879088/dji-romo-hack-vulnerability-remote-control-camera-access-mqtt Sprungmarken (00:00:00) Warum IT Security oft erst auffällt, wenn es knallt (00:04:44) Info/Werbung (00:05:44) Warum IT Security oft erst auffällt, wenn es knallt (00:06:14) Hack 1: Aquarium-IoT im Casino und 10 GB Datenabfluss (00:31:23) Hack 2: Jeep Cherokee, offener Port, D-Bus und CAN-Bus (00:47:18) Hack 3: DJI Staubsaugerroboter, MQTT und fehlende Autorisierung (00:52:47) Was du daraus mitnimmst: Authentifizierung, Autorisierung, Segmentierung Hosts Wolfgang Gassler (https://gassler.dev) Andy Grunwald (https://andygrunwald.com/) Community Diskutiere mit uns und...

Hochleistungskultur in Teams zu entwickeln und wie viele Führungskräfte diese (unbewusst) sabotieren Hochleistungskultur 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/partners Das schnelle Feedback zur Episode: 👍 (top) 👎 (geht so) Anregungen, Gedanken, Themen und Wünsche Dein Feedback zählt! Erreiche uns über einen der folgenden Kanäle … https://engineeringkiosk.dev/join-discordhttps://www.linkedin.com/company/engineering-kiosk/stehtisch@engineeringkiosk.devhttps://podcasts.social/@engkioskhttps://bsky.app/profile/engineeringkiosk.bsky.socialhttps://www.instagram.com/engineeringkiosk/ Unterstütze den Engineering Kiosk Wenn du uns etwas Gutes tun möchtest … Kaffee schmeckt uns immer https://engineeringkiosk.dev/kaffee Links https://troodi.de/https://www.linkedin.com/in/philip-klasen-schwidetzki-9b38b554/https://grow.troodi.de/portal/signup?campaign=engineering-kioskhttps://engineeringkiosk.dev/podcast/episode/95-effiziente-knowledge-sharing-formate-wissen-teilen-und-begeistern/https://andygrunwald.com/blog/playing-rockpaperscissors-with-500-people/https://projekte-leicht-gemacht.de/blog/softskills/fuehrung/teams/psychologische-sicherheit/#Mit-psychologischer-Sicherheit-zu-leistungsfaehigeren-Teamshttps://de.wikipedia.org/wiki/Amy_Edmondsonhttps://www.amazon.de/Radical-Candor-Revised-Updated-Saying/dp/1529038340/ref=sr_1_2 Sprungmarken (00:00:00) Hochleistungskultur in Tech: Warum mehr Druck nicht mehr Performance ist (00:06:34) Was ist Hochleistung überhaupt und wie misst man sie sinnvoll (00:11:15) Amy Edmondson: Psychologische Sicherheit plus Accountability als Modell (00:15:18) Performance Management ohne Angst: Ziele, Fairness und der richtige Kontext (00:18:30) Angstkultur in der Praxis, Radical Candor, Caring und Daring (00:31:43) Checkfragen: So erkennst du psychologische Sicherheit im Team (00:36:04) Sabotagemuster von Führungskräften: Komfortzone, Angstzone, Micromanagement (00:41:50) Ownership im Alltag bauen: Verantwortung nicht zurücknehmen (00:53:23) Selbstausbeutung und Fürsorgepflicht: Ambition ohne Burnout (00:58:34) Mittelmanagement unter Druck: Pushback, Preisschilder und Multiloyalität (01:06:57) Tipps für Führungskräfte und Teammitglieder Hosts https://gassler.devhttps://andygrunwald.com/ Community Diskutiere mit uns und vielen anderen Tech-Spezialist⋅innen in unserer Engineering Kiosk Community unter https://engineeringkiosk.dev/join-discord

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/partners Das schnelle Feedback zur Episode: 👍 (top) 👎 (geht so) Anregungen, Gedanken, Themen und Wünsche Dein Feedback zählt! Erreiche uns über einen der folgenden Kanäle … https://engineeringkiosk.dev/join-discordhttps://www.linkedin.com/company/engineering-kiosk/stehtisch@engineeringkiosk.devhttps://podcasts.social/@engkioskhttps://bsky.app/profile/engineeringkiosk.bsky.socialhttps://www.instagram.com/engineeringkiosk/ Unterstütze den Engineering Kiosk Wenn du uns etwas Gutes tun möchtest … Kaffee schmeckt uns immer https://engineeringkiosk.dev/kaffee Links https://engineeringkiosk.dev/podcast/episode/28-o1-olog-n-on2-ist-die-komplexit%C3%A4t-von-algorithmen-im-entwickler-alltag-relevant/https://www.tinohempel.de/info/info/datenbank/normalisierung.htmhttps://engineeringkiosk.dev/podcast/episode/182-happy-birthday-sql-50-jahre-abfragesprache/https://engineeringkiosk.dev/podcast/episode/129-simplify-your-stack-files-statt-datenbanken/https://parquet.apache.org/https://research.google/pubs/dremel-interactive-analysis-of-web-scale-datasets-2/https://clickhouse.com/docs/integrations/data-formats/parquethttps://duckdb.org/https://github.com/parquet-go/parquet-gohttps://github.com/Aiven-Open/tiered-storage-for-apache-kafka/ Sprungmarken (00:00:00) Wie böse kann "das skaliert nicht" enden? (00:05:18) Normalformen, Denormalisierung und typische Skalierungsreflexe (00:06:30) Info/Werbung (00:07:30) Normalformen, Denormalisierung und typische Skalierungsreflexe (00:11:52) Row-Oriented Datastores verstehen (00:27:01) Column-Oriented Datastores: OLAP, Kompression, Spalten-Pruning und SIMD (00:36:53) Trade-offs: Warum Column-Stores nicht für jede Produktion passen (00:41:52) CSV als Dateiformat: simpel, verbreitet, aber messy (00:44:13) Apache Parquet: Columnar File Format, Row Groups und Metadaten (00:51:44) Apache Iceberg: Tabellen-Management, Snapshots und Time Travel (00:56:54) Storage vs. Compute trennen: Cloud-Kosten, Object Storage, Tiering (01:04:12) Wo es heute genutzt wird: Kafka Tiered Storage, ClickHouse, Prometheus (01:13:33) Takeaways: pragmatisch starten, DuckDB testen, Hype reflektieren Hosts https://gassler.devhttps://andygrunwald.com/ Community Diskutiere mit uns und vielen anderen Tech-Spezialist⋅innen in...

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/partners Das schnelle Feedback zur Episode: 👍 (top) 👎 (geht so) Anregungen, Gedanken, Themen und Wünsche Dein Feedback zählt! Erreiche uns über einen der folgenden Kanäle … https://engineeringkiosk.dev/join-discordhttps://www.linkedin.com/company/engineering-kiosk/stehtisch@engineeringkiosk.devhttps://podcasts.social/@engkioskhttps://bsky.app/profile/engineeringkiosk.bsky.socialhttps://www.instagram.com/engineeringkiosk/ Unterstütze den Engineering Kiosk Wenn du uns etwas Gutes tun möchtest … Kaffee schmeckt uns immer https://engineeringkiosk.dev/kaffee Links https://martinfowler.com/bliki/DomainDrivenDesign.htmlhttps://martinfowler.com/bliki/AnemicDomainModel.htmlhttps://github.com/PacktPublishing/Domain-Driven-Design-with-GoLanghttps://fabiofumarola.github.io/nosql/readingMaterial/Evans03.pdfhttps://engineeringkiosk.dev/podcast/episode/222-solid-in-go-js-co-passt-das-noch-zur-modernen-software/https://engineeringkiosk.dev/podcast/episode/222-solid-in-go-js-co-passt-das-noch-zur-modernen-software/ Sprungmarken (00:00:00) Domains kaufen vs. Domain Driven Design (00:06:01) Info/Werbung (00:07:01) Domains kaufen vs. Domain Driven Design (00:10:45) Warum überhaupt Domain Driven Design: Komplexität, Spaghetti Code und Business-IT-Graben (00:14:16) Strategisches Design: Domain verstehen und Ubiquitous Language aufbauen (00:24:33) Bounded Contexts und Context Mapping: Grenzen, Sprache, Schnittstellen (00:32:46) DDD und Teamstrukturen: Conway's Law, APIs und Verantwortlichkeiten (00:35:57) Taktisches Design: Value Objects, Entities, Aggregates, Repositories (00:43:32) Wie erkennst du DDD im Code: Kubernetes als Beispiel und Code Lesbarkeit (00:46:19) Pragmatisch starten: Glossar, Boy Scout Rule und DDD mit bestehenden Codebasen (00:52:27) Für wen lohnt sich DDD wirklich: Startup vs. Enterprise, Monolith vs. Microservices (01:00:53) Kritik und Grenzen: Over Engineering und fehlende Domain Experts (01:01:58) DDD in Plattform- und Infrastruktur-Teams: gemeinsame Sprache für Cloud Automation (01:04:09) Ressourcen, Links und Community-Feedback Hosts https://gassler.devhttps://andygrunwald.com/ Community Diskutiere mit uns und vielen anderen Tech-Spezialist⋅innen in unserer Engineering Kiosk Community unter https://engineeringkiosk.dev/join-discord

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/partners Das schnelle Feedback zur Episode: 👍 (top) 👎 (geht so) Anregungen, Gedanken, Themen und Wünsche Dein Feedback zählt! Erreiche uns über einen der folgenden Kanäle … https://engineeringkiosk.dev/join-discordhttps://www.linkedin.com/company/engineering-kiosk/stehtisch@engineeringkiosk.devhttps://podcasts.social/@engkioskhttps://bsky.app/profile/engineeringkiosk.bsky.socialhttps://www.instagram.com/engineeringkiosk/ Unterstütze den Engineering Kiosk Wenn du uns etwas Gutes tun möchtest … Kaffee schmeckt uns immer https://engineeringkiosk.dev/kaffee Links https://www.linkedin.com/in/michael-gasch/https://engineeringkiosk.dev/podcast/episode/108-agile-multi-team-projekte-die-kunst-hunderte-leute-effektiv-zu-koordinieren-mit-stephan-strack/https://aws.amazon.com/de/what-is/serverless-computing/https://docs.aws.amazon.com/step-functions/https://aws.amazon.com/de/eventbridge/https://code.berlin/de/study/bachelor/bme/product-management/https://www.iu.de/bachelor/produktmanagement/https://aws.amazon.com/de/lambda/lambda-durable-functions/https://www.aboutamazon.com/news/workplace/an-insider-look-at-amazons-culture-and-processeshttps://www.allthingsdistributed.com/2024/11/aws-lambda-turns-10-a-rare-look-at-the-doc-that-started-it.htmlhttps://engineeringkiosk.dev/podcast/episode/159-verhaltensbezogene-interview-fragen-und-star-methode/ Sprungmarken (00:00:00) Technisches Produktmanagement mit Michael Gasch (00:06:05) Info/Werbung (00:07:05) Technisches Produktmanagement mit Michael Gasch (00:16:02) Was ist Produktmanagement, was ist es nicht, und die Abgrenzung zu Projektmanagement (00:24:12) Unterschiede von Produktmanagement je nach Produkt (AWS, BMW, Booking.com) (00:29:44) Priorisierung und Kultur bei AWS: Eskalation, Disagree and Commit und Entscheidungsfindung (00:42:30) Metriken und Erfolgsmessung: GA, Adoption, Telemetrie und Feedback-Loops (00:53:43) AI und Produktmanagement: Warum Anforderungen wichtiger werden (01:02:28) Zusammenarbeit zwischen Entwickler*innen und Produktmanagement verbessern: Proaktivität, Ownership und Champions (01:06:41) Wechsel ins Produktmanagement: STAR-Methode, Mentoring und Praxisübungen (01:10:30) Unbequeme Wahrheiten: Stress, Verantwortung sowie Pricing und PnL Hosts https://gassler.devhttps://andygrunwald.com/ Community Diskutiere mit uns und vielen...

4 coole Sprachfeatures von Ada, F#, Go und PHP Kennst 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/partners Das schnelle Feedback zur Episode: 👍 (top) 👎 (geht so) Anregungen, Gedanken, Themen und Wünsche Dein Feedback zählt! Erreiche uns über einen der folgenden Kanäle … https://engineeringkiosk.dev/join-discordhttps://www.linkedin.com/company/engineering-kiosk/stehtisch@engineeringkiosk.devhttps://podcasts.social/@engkioskhttps://bsky.app/profile/engineeringkiosk.bsky.socialhttps://www.instagram.com/engineeringkiosk/ Unterstütze den Engineering Kiosk Wenn du uns etwas Gutes tun möchtest … Kaffee schmeckt uns immer https://engineeringkiosk.dev/kaffee Links https://github.com/EngineeringKiosk/cool-programming-language-featureshttps://www.php.net/manual/de/migration82.new-features.phphttps://www.php.net/manual/de/class.sensitiveparameter.phphttps://php.watch/versions/8.2/backtrace-parameter-redactionhttps://wiki.php.net/rfc/redact_parameters_in_back_traceshttps://php.watch/versions/8.0/attributeshttps://antonz.org/accepted/runtime-secret/https://github.com/golang/go/issues/21865https://go.dev/doc/go1.26https://www.heartbleed.com/https://www.heise.de/news/MongoDB-kritische-Sicherheitsluecke-in-NoSQL-Datenbank-11124891.htmlhttps://manpages.debian.org/experimental/linux-manual-4.11/memzero_explicit.9.en.htmlhttps://www.gnu.org/software/gnulib/manual/html_node/explicit_005fbzero.htmlhttps://man.freebsd.org/cgi/man.cgi?query=memset_s&sektion=3https://crates.io/crates/zeroizehttps://www.cryptologie.net/posts/zeroing-memory-compiler-optimizations-and-memset_s/https://de.wikipedia.org/wiki/Mars_Climate_Orbiterhttps://www.swr.de/swrkultur/wissen/technik-fail-einheitenfehler-laesst-mars-climate-orbiter-zerschellen-100.htmlhttps://de.wikipedia.org/wiki/F-Sharphttps://archive.fosdem.org/2022/schedule/event/ada_introduction_beginning_experienced/attachments/slides/5048/export/events/attachments/ada_introduction_beginning_experienced/slides/5048/01_ada_introduction.pdfhttps://www2.seas.gwu.edu/~mfeldman/ada-project-summary.htmlhttps://fosdem.org/https://learn.adacore.com/courses/intro-to-ada/chapters/strongly_typed_language.htmlhttps://engineeringkiosk.dev/podcast/episode/63-spa%C3%9F-mit-zahlen-under-und-overflows-r%C3%BCckw%C3%A4rtslaufende-zeit-negative-modulos-und-w%C3%A4hrungsbetr%C3%A4ge/ Sprungmarken (00:00:00) KI, Programmiersprachen und Attribute von guten...

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/partners Das schnelle Feedback zur Episode: 👍 (top) 👎 (geht so) Anregungen, Gedanken, Themen und Wünsche Dein Feedback zählt! Erreiche uns über einen der folgenden Kanäle … https://engineeringkiosk.dev/join-discordhttps://www.linkedin.com/company/engineering-kiosk/stehtisch@engineeringkiosk.devhttps://podcasts.social/@engkioskhttps://bsky.app/profile/engineeringkiosk.bsky.socialhttps://www.instagram.com/engineeringkiosk/ Unterstütze den Engineering Kiosk Wenn du uns etwas Gutes tun möchtest … Kaffee schmeckt uns immer https://engineeringkiosk.dev/kaffee Links https://engineeringkiosk.dev/podcast/episode/10-das-karriere-booster-meeting-11s/https://engineeringkiosk.dev/podcast/episode/51-was-ist-das-staff-engineer-level/https://engineeringkiosk.dev/podcast/episode/61-schwierige-1-on-1-situationen-und-l%C3%B6sungsvorschl%C3%A4ge/https://engineeringkiosk.dev/podcast/episode/75-evaluierung-deiner-job-performance-team-feedback-und-lno-framework/https://engineeringkiosk.dev/podcast/episode/110-okrs-und-beyond-agile-unternehmensf%C3%BChrung-mit-marco-alberti-von-murakamy/https://engineeringkiosk.dev/podcast/episode/113-selbstmarketing-ohne-bullshit-brag-documents/https://engineeringkiosk.dev/podcast/episode/131-equity-in-tech-startups-mehr-als-nur-gehalt-mit-philipp-pip-kl%C3%B6ckner/https://engineeringkiosk.dev/podcast/episode/205-staff-principal-wtf-karriereleitern-und-erwartungshaltungen-mit-lena-reinhard/https://www.hrworks.de/news/9-box-grid-so-beurteilen-sie-leistungen-und-potenziale-von-mitarbeitern/ Sprungmarken (00:00:00) Warum Performance Reviews oft Angst, Politik und Bias auslösen (00:05:15) Info/Werbung (00:06:15) Was ist ein Performance Review und wie läuft es in Firmen ab (00:12:02) Ziele: Feedback, Dokumentation, Fairness und Transparenz (00:18:27) Varianten aus der Praxis: Von Kaffee Gespräch bis Peer Feedback (00:23:34) Dokumentation und Systeme: Thank You, Self Assessment, Feedback per E Mail (00:27:07) 360 Grad Feedback bei Trivago: Aufwand, Nutzen und Lessons Learned (00:31:38) Feedback vs. Gehalt: Warum die Kopplung Systeme kippen lässt (00:35:54) Glockenkurve, Forced Ranking und teamübergreifende Kalibrierung (00:39:25) Glue Work sichtbar machen: Daten, Impact und Beförderungen argumentieren (00:44:34) Was du als IC tun kannst: Self Assessment, Ownership, Outcome statt Output (00:51:04) Feedback richtig nutzen: einfordern, filtern, verarbeiten (00:53:45) Prozesse bleiben imperfect, du kannst sie steuern Hosts https://gassler.devhttps://andygrunwald.com/ Community Diskutiere mit uns und vielen anderen Tech-Spezialist⋅innen in unserer Engineering Kiosk Community unter https://engineeringkiosk.dev/join-discord

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/partners Das schnelle Feedback zur Episode: 👍 (top) 👎 (geht so) Anregungen, Gedanken, Themen und Wünsche Dein Feedback zählt! Erreiche uns über einen der folgenden Kanäle … https://engineeringkiosk.dev/join-discordhttps://www.linkedin.com/company/engineering-kiosk/stehtisch@engineeringkiosk.devhttps://podcasts.social/@engkioskhttps://bsky.app/profile/engineeringkiosk.bsky.socialhttps://www.instagram.com/engineeringkiosk/ Unterstütze den Engineering Kiosk Wenn du uns etwas Gutes tun möchtest … Kaffee schmeckt uns immer https://engineeringkiosk.dev/kaffee Links https://www.linkedin.com/in/philippdeutscher/https://www.deutscherconsulting.com/https://www.deutscherconsulting.com/podcast-becoming-cto-secrets/https://www.linkedin.com/posts/philippdeutscher_der-cto-ist-das-schw%C3%A4chste-c-level-in-80-activity-7392090110470660096-WCff/https://www.linkedin.com/posts/philippdeutscher_viele-ceos-suchen-keinen-cto-sie-suchen-activity-7393902049656020992-i7Vo/https://www.linkedin.com/posts/philippdeutscher_der-beste-entwickler-ist-selten-der-beste-activity-7396076469132668929-Fr8E/https://dora.dev/https://news.microsoft.com/source/exec/kevin-scott/https://www.salesforce.com/company/parker-harris-bio/https://en.wikipedia.org/wiki/Chief_of_staff Sprungmarken (00:00:00) CTO-Rolle: Warum sie oft falsch verstanden wird (00:05:55) Was ist ein CTO und was ist er nicht? Hands-on, Bottlenecks, Skalierung (00:06:19) Info/Werbung (00:07:19) Was ist ein CTO und was ist er nicht? Hands-on, Bottlenecks, Skalierung (00:15:34) Interim vs. Fractional CTO: Mandat, Tempo, Verantwortung, Vertrauen (00:26:43) Wertbeitrag im C-Level: Brücke zwischen Business und Tech (00:43:59) CTO als Übersetzer: technische Schulden, KPIs, Incidents und Umsatz (00:46:25) Metriken in der Praxis: Velocity, DORA, Lead Time, Availability (00:54:22) CTO werden: Karrierepfade, Transformation und Growth Mindset (01:08:43) So positionierst du dich: Verantwortung ziehen, Sichtbarkeit, CTO Office Hosts https://gassler.devhttps://andygrunwald.com/ Community Diskutiere mit uns und vielen anderen Tech-Spezialist⋅innen in unserer Engineering Kiosk Community unter https://engineeringkiosk.dev/join-discord

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/partners Das schnelle Feedback zur Episode: 👍 (top) 👎 (geht so) Anregungen, Gedanken, Themen und Wünsche Dein Feedback zählt! Erreiche uns über einen der folgenden Kanäle … https://engineeringkiosk.dev/join-discordhttps://www.linkedin.com/company/engineering-kiosk/stehtisch@engineeringkiosk.devhttps://podcasts.social/@engkioskhttps://bsky.app/profile/engineeringkiosk.bsky.socialhttps://www.instagram.com/engineeringkiosk/ Unterstütze den Engineering Kiosk Wenn du uns etwas Gutes tun möchtest … Kaffee schmeckt uns immer https://engineeringkiosk.dev/kaffee Links https://engineeringkiosk.dev/podcast/episode/204-resilience-engineering-timeouts-jitter-backoff-andere-systemretter/https://engineeringkiosk.dev/podcast/episode/223-throw-redundancy-at-the-tail-request-hedging-bei-google-co/https://docs.github.com/en/rest/using-the-rest-api/rate-limits-for-the-rest-api?apiVersion=2022-11-28https://docs.github.com/en/rest/using-the-rest-api/rate-limits-for-the-rest-api?apiVersion=2022-11-28#checking-the-status-of-your-rate-limithttps://developers.cloudflare.com/fundamentals/api/reference/limits/#rate-limiting-headershttps://docs.github.com/en/graphql/overview/rate-limits-and-query-limits-for-the-graphql-apihttps://datatracker.ietf.org/doc/draft-ietf-httpapi-ratelimit-headers/https://engineeringkiosk.dev/podcast/episode/212-multi-tenant-done-right-isolationsmodelle-cell-based-architecture-shuffle-sharding-co-mit-maximilian-schellhorn/ Sprungmarken (00:00:00) Resilience Engineering: Rate Limiting (00:03:57) Failure Modes: Retry Storms, Thundering Herd, Traffic Spikes und Traffic Amplification (00:04:28) Info/Werbung (00:05:28) Failure Modes: Retry Storms, Thundering Herd, Traffic Spikes und Traffic Amplification (00:17:50) Wo platzierst du Rate Limiting: Client, Edge, API Gateway, Sidecar und Ressourcen (00:25:22) Welche Strategie passt: Bursts, Fairness und stateful vs stateless Rate Limiting (00:28:54) Algorithmen: Fixed Window, Sliding Window, Token Bucket und Leaky Bucket (00:38:36)...

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/partners Das schnelle Feedback zur Episode: 👍 (top) 👎 (geht so) Anregungen, Gedanken, Themen und Wünsche Dein Feedback zählt! Erreiche uns über einen der folgenden Kanäle … https://engineeringkiosk.dev/join-discordhttps://www.linkedin.com/company/engineering-kiosk/stehtisch@engineeringkiosk.devhttps://podcasts.social/@engkioskhttps://bsky.app/profile/engineeringkiosk.bsky.socialhttps://www.instagram.com/engineeringkiosk/ Unterstütze den Engineering Kiosk Wenn du uns etwas Gutes tun möchtest … Kaffee schmeckt uns immer https://engineeringkiosk.dev/kaffee Links https://www.linkedin.com/in/mariomueller/https://www.thesecondlineperspective.blog/https://spark.apache.org/https://aws.amazon.com/de/emr/https://iceberg.apache.org/https://parquet.apache.org/https://prestodb.io/https://delta.io/https://en.wikipedia.org/wiki/Change_data_capturehttps://clinicaltrials.gov/https://airbyte.com/https://www.selenium.dev/https://airflow.apache.org/ Sprungmarken (00:00:00) Data as a Product und Strukturierung von Daten-Teams mit Mario Müller (00:04:35) Was sind "Daten-Teams" und der Unterschied zu klassischen Analytics Teams? (00:05:54) Info/Werbung (00:06:54) Was sind "Daten-Teams" und der Unterschied zu klassischen Analytics Teams? (00:19:39) Data as a Product: Eine klassische Data-Pipeline (00:25:08) Batch- vs. Stream-Processing und Abhängigkeiten zwischen Teams (00:40:52) Sourcing von Daten (00:44:13) Data Quality Monitoring (00:48:24) Strukturierung von Daten-Teams: One-Man-Show bis 50 Personen (01:05:37) AI als neue Daten-Quelle oder Daten-Mitarbeiter (01:13:30) Tipps um Daten-Teams aufzubauen Hosts https://gassler.devhttps://andygrunwald.com/ Community Diskutiere mit uns und vielen anderen Tech-Spezialist⋅innen in unserer Engineering Kiosk Community unter https://engineeringkiosk.dev/join-discord

Adventskalender: Making of/Behind the scenes und Community Rückblick 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/partners Das schnelle Feedback zur Episode: 👍 (top) 👎 (geht so) Anregungen, Gedanken, Themen und Wünsche Dein Feedback zählt! Erreiche uns über einen der folgenden Kanäle … https://engineeringkiosk.dev/join-discordhttps://www.linkedin.com/company/engineering-kiosk/stehtisch@engineeringkiosk.devhttps://podcasts.social/@engkioskhttps://bsky.app/profile/engineeringkiosk.bsky.socialhttps://www.instagram.com/engineeringkiosk/ Unterstütze den Engineering Kiosk Wenn du uns etwas Gutes tun möchtest … Kaffee schmeckt uns immer https://engineeringkiosk.dev/kaffee Links https://engineeringkiosk.dev/deutsche-tech-podcasts/https://podcast.smarthuette.de/https://0x0d.de/https://digitaleanomalien.de/https://focusondevops.podigee.io/https://python-podcast.de/show/https://tilpod.net/https://it-berufe-podcast.de/https://happy-bootstrapping.podigee.io/https://user.space/show/urlaub-im-userspace/ Sprungmarken (00:00:00) Adventskalender: Making of/Behind the scenes und Community Rückblick Hosts https://gassler.devhttps://andygrunwald.com/ Community Diskutiere mit uns und vielen anderen Tech-Spezialist⋅innen in unserer Engineering Kiosk Community unter https://engineeringkiosk.dev/join-discord

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/partners Das schnelle Feedback zur Episode: 👍 (top) 👎 (geht so)  Anregungen, Gedanken, Themen und Wünsche Dein Feedback zählt! Erreiche uns über einen der folgenden Kanäle … EngKiosk Community: https://engineeringkiosk.dev/join-discord LinkedIn: https://www.linkedin.com/company/engineering-kiosk/Email: stehtisch@engineeringkiosk.devMastodon: https://podcasts.social/@engkioskBluesky: https://bsky.app/profile/engineeringkiosk.bsky.socialInstagram: https://www.instagram.com/engineeringkiosk/ Unterstütze den Engineering Kiosk Wenn du uns etwas Gutes tun möchtest … Kaffee schmeckt uns immer Buy us a coffee: https://engineeringkiosk.dev/kaffee Links Philipp Krenn auf LinkedIn: https://www.linkedin.com/in/philippkrenn/Google Summer of Code: https://summerofcode.withgoogle.com/Elastic: https://www.elastic.co/Developer relations auf Wikipedia: https://en.wikipedia.org/wiki/Developer_relationsFOSDEM: https://fosdem.org/2026/ Sprungmarken (00:00:00) Developer Relations mit Philipp Krenn (00:05:22) Was ist Developer Relations? Wo ist der Unterschied zum Marketing? (00:07:58) Info/Werbung (00:08:58) Was ist Developer Relations? Wo ist der Unterschied zum Marketing? (00:17:10) Technik vs. Developer Relations und der Alltag (00:22:23) Personenkult (00:28:22) Das eigene Produkt und das Ökosystem (00:34:31) Priorisierung von Developer Relations Aktivitäten und KPIs (00:43:02) DevRel im Markt: Hype Zyklen, Budget, AI Boom und Jobnachfrage (00:52:38) Welche Skills benötige ich als Developer Advocate? (00:58:44) Reisetätigkeit: Konferenzzirkus vor Corona und heutige Realität (01:02:45) Was müssen Unternehmen für Developer Relations verstehen? Hosts Wolfgang Gassler (https://gassler.dev) Andy Grunwald (https://andygrunwald.com/) Community Diskutiere mit uns und vielen anderen Tech-Spezialist⋅innen in unserer Engineering Kiosk Community unter https://engineeringkiosk.dev/join-discord

Selbstmanagement: Weniger To-do-Listen-Stress, mehr Produktivität 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/partners Das schnelle Feedback zur Episode: 👍 (top) 👎 (geht so) Anregungen, Gedanken, Themen und Wünsche Dein Feedback zählt! Erreiche uns über einen der folgenden Kanäle … https://engineeringkiosk.dev/join-discordhttps://www.linkedin.com/company/engineering-kiosk/stehtisch@engineeringkiosk.devhttps://podcasts.social/@engkioskhttps://bsky.app/profile/engineeringkiosk.bsky.socialhttps://www.instagram.com/engineeringkiosk/ Unterstütze den Engineering Kiosk Wenn du uns etwas Gutes tun möchtest … Kaffee schmeckt uns immer https://engineeringkiosk.dev/kaffee Links https://engineeringkiosk.dev/ep156https://engineeringkiosk.dev/ep66https://engineeringkiosk.dev/ep235 Sprungmarken (00:00:00) Selbstmanagement: Weniger To-do-Listen-Stress, mehr Produktivität Hosts https://gassler.devhttps://andygrunwald.com/ Community Diskutiere mit uns und vielen anderen Tech-Spezialist⋅innen in unserer Engineering Kiosk Community unter https://engineeringkiosk.dev/join-discord

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/partners Das schnelle Feedback zur Episode: 👍 (top) 👎 (geht so) Anregungen, Gedanken, Themen und Wünsche Dein Feedback zählt! Erreiche uns über einen der folgenden Kanäle … https://engineeringkiosk.dev/join-discordhttps://www.linkedin.com/company/engineering-kiosk/stehtisch@engineeringkiosk.devhttps://podcasts.social/@engkioskhttps://bsky.app/profile/engineeringkiosk.bsky.socialhttps://www.instagram.com/engineeringkiosk/ Unterstütze den Engineering Kiosk Wenn du uns etwas Gutes tun möchtest … Kaffee schmeckt uns immer https://engineeringkiosk.dev/kaffee Links https://engineeringkiosk.dev/spiele-fuer-softwareentwickler/https://www.factorio.com/https://store.steampowered.com/app/427520/Factorio/https://www.metaroot.ch/press-kit/the-farmer-was-replacedhttps://store.steampowered.com/app/2060160/The_Farmer_Was_Replaced/https://www.artifactsmmo.com/https://screeps.com/https://store.steampowered.com/app/1137320/Screeps_Arena/https://github.com/EngineeringKiosk/awesome-software-engineering-gameshttps://adventofcode.com/ Sprungmarken (00:00:00) Spiele für Softwareentwickler:innen Hosts https://gassler.devhttps://andygrunwald.com/ Community Diskutiere mit uns und vielen anderen Tech-Spezialist⋅innen in unserer Engineering Kiosk Community unter https://engineeringkiosk.dev/join-discord