Data Science Deep Dive

#75: Refactoring done right: Strategien, Risiken und Best Practice

Refactoring ist ein Begriff, der oft missverstanden wird. Er bedeutet nicht, dass etwas kaputt war, sondern dass man Code strukturell verbessert, ohne sein Verhalten zu verändern. In dieser Folge sprechen wir darüber, warum Refactoring im Alltag oft notwendig ist, wie man es erkennt und richtig angeht. Wir diskutieren, wann es sinnvoll ist, Refactoring gezielt zu planen oder spontan umzusetzen – und warum Tests dabei eine zentrale Rolle spielen. Außerdem werfen wir einen Blick auf die speziellen Herausforderungen im Data-Science-Kontext und wie man Stakeholder überzeugt. Refactoring ist kein Selbstzweck, sondern ein strategischer Hebel für bessere, wartbare Software.
 
**Zusammenfassung**
Refactoring verbessert die Code-Struktur ohne das Verhalten zu verändern für bessere Wartbarkeit und Lesbarkeit
Typische Ursachen für unübersichtlichen Code: Zeitdruck, sich ändernde Anforderungen, wenig einheitliche Standards im Team
Refactoring ist kein Zeichen für Fehler, sondern für evolutionäre Weiterentwicklung
Gelegenheits- vs. geplantes Refactoring: vom schnellen Umbau beim Feature-Entwickeln bis hin zum langfristigen Redesign
Gute Tests sind essenziell, um unbeabsichtigte Nebeneffekte zu vermeiden
Risiken: beschädigte Funktionalität, Zeitaufwand, technische Schulden bei unvollständigem Refactoring
Refactoring im Data-Science-Kontext oft besonders notwendig, da Entwicklung häufig in Skripten startet
Erfolgsfaktor: Refactoring verständlich kommunizieren als Investition in Qualität, nicht als "Schuldenbegleichung"
**Links**
[Buch] Refactoring: Improving the Design of Existing Code. M. Fowler. Addison-Wesley, Boston, MA, USA, (2019).
[Blog] Definition Of Refactoring by Martin Fowler https://martinfowler.com/bliki/DefinitionOfRefactoring.html
[Blog] Refactoring: Einführung von Antonia Runge https://www.inwt-statistics.de/blog/refactoring-einfuehrung 
[Podcast] #23: Unsexy aber wichtig: Tests und Monitoring https://www.podbean.com/ew/pb-vxp58-13f311a
📬 Fragen, Feedback oder Themenwünsche?Schreibt uns gern an: podcast@inwt-statistics.de

#74: [PAIQ1] Predictive AI Quarterly

Predictive AI Quarterly ist unser neues Format im Data Science Deep Dive. Alle 3 Monate sprechen wir über Entwicklungen im Bereich Predictive AI - kompakt, kritisch und praxisnah.Wir starten mit einem Überblick zu den aktuellen News und Trends, danach wird's hands-on: Wir berichten, was wir selbst ausprobiert haben, was gut funktioniert hat und was nicht.
 
**Zusammenfassung**
TabPFN ist ein Foundation-Modell speziell für tabulare Daten, das Prognose- und Klassifikationsaufgaben ohne Finetuning lösen kann
Finetuning-Optionen: Neben dem kostenpflichtigen Angebot von PriorLabs existiert ein Open-Source-Repo zum Finetuning von TabPFN, das aktiv weiterentwickelt wird
mit TabICL gibt es ein weiteres Foundation-Modell für tabulare Daten, das synthetisch trainiert ist, sich auf Klassifikation konzentriert und auch bei großen Datensätzen (bis 500k Zeilen) schnelle Inferenz verspricht
Foundation-Modelle für Zeitreihen: Unternehmen wie IBM, Google und Salesforce entwickeln eigene Foundation-Modelle für Time-Series Forecasting (z. B. TTMs, TimesFM, Moirai), diese werden bislang auf echten Zeitreihen trainiert
der GIFT-Benchmark dient als Standard zum Vergleich von Zeitreihenmodellen – hier zeigt sich, dass ein angepasstes TabPFN auch für Zeitreihen überraschend leistungsfähig ist
Hands On:
TabPFN lässt sich analog zu scikit-learn einsetzen und ist besonders dann praktisch, wenn eine GPU vorhanden ist, die Einstiegshürde ist sehr niedrig
in Zukunft wird mit multimodalen Erweiterungen (z. B. Bilder), quantisierten Varianten und weiteren Alternativen zu TabPFN gerechnet, der Bereich Foundation Models für strukturierte Daten entwickelt sich rasant
**Links**
Podcastfolge #72: TabPFN: Die KI-Revolution für tabulare Daten mit Noah Hollmann
TabPFN:
Finetuning Angebot von Prior Labs
GitHub-Repo: Finetune TabPFN v2
GitHub-Repo: Zero-Shot Time Series Forecasting mit TabPFNv2
TabICL:
GitHub-Repo: TabICL – Tabular In-Context Learning
Workshop @ ICML 2025: Foundation Models for Structured Data (18. Juli 2025 in Vancouver)
Blogartikel & Studien:
Tiny Time Mixers (TTMs) von IBM Research
Moirai:  A Time Series Foundation Model by Salesforce
Blogartikel von inwt: "TabPFN: Die KI-Revolution für tabulare Daten"
Huggingface Spaces & Modelle:
TimesFM Foundation Model für Zeitreihen von Google Research
GIFT-Eval Forecasting Leaderboard
📬 Fragen, Feedback oder Themenwünsche?Schreibt uns gern an: podcast@inwt-statistics.de

#73: Korrelation vs. Kausalität: Was braucht es für fundierte Entscheidungen?

Korrelation ist nicht gleich Kausalität, und wer fundierte Entscheidungen treffen will, braucht mehr als gute Vorhersagen. In dieser Folge geht es um Confounder, Spurious Correlations und die Frage, wann Machine Learning kausale Einsichten liefern kann. Mit dabei: DoubleML als Brücke zwischen klassischer Statistik und Machine Learning.
 
**Zusammenfassung**
Unterscheidung zwischen Vorhersage und Intervention: Nur Kausalität beantwortet die "Was-wäre-wenn?"-Frage
Praxisbeispiele: Bugs & Discounts, Eiskonsum & Kriminalität, Salzgehalt & Flussmenge
Wichtig: Confounder identifizieren und herausrechnen, z. B. durch Zeitreihenzerlegung
Einführung in Double ML: ML-Modelle für Response und Treatment, Effektschätzung über Residuen
Herausforderungen: Overfitting-Bias, Regularisierung, verzerrte Effekte bei hoher Komplexität
Alternativen & Ergänzungen: A/B-Tests, strukturelle Gleichungsmodelle, Kausaldiagramme
Fazit: Vorsicht bei Spurious Correlations, Ceteris-paribus-Fallen und Feature-Interpretation - Kausalität braucht Kontext und Methode
**Links**
Blogartikel von Scott Lundberg:Be Careful When Interpreting Predictive Models in Search of Causal Insightshttps://medium.com/data-science/be-careful-when-interpreting-predictive-models-in-search-of-causal-insights-e68626e664b6
ICECREAM-Datensatz (verfügbar über das tsapp R-Paket):https://search.r-project.org/CRAN/refmans/tsapp/html/ICECREAM.html
Victor Chernozhukov et al. (2018):Double/debiased machine learning for treatment and structural parameters, The Econometrics Journal, Volume 21, Issue 1https://doi.org/10.1111/ectj.12097
Matheus Facure Alves (2022):Causal Inference for The Brave and True (kostenfreies Online-Buch)https://matheusfacure.github.io/python-causality-handbook/landing-page.html
DoubleML (Python & R):https://docs.doubleml.org/stable/index.html
EconML (Microsoft Research):https://econml.azurewebsites.net/index.html
Causal ML (Uber Engineering):https://causalml.readthedocs.io/en/latest/
Vortragsfolien von Prof. Dr. Steffen Wagner:"Navigating the Ocean of Correlations to the Islands of Causality – Time Series Analyses at its Best", gehalten bei der Machine Learning Week München 2024https://de.slideshare.net/secret/aArFURFQSBxrzB
 
📬 Fragen, Feedback oder Themenwünsche?Schreibt uns gern an: podcast@inwt-statistics.de

#72: TabPFN: Die KI-Revolution für tabulare Daten mit Noah Hollmann

Wir sprechen mit Noah Hollman von Prior Labs, einem der Schöpfer von TabPFN (Tabular Prior Fitted Network), über dieses bahnbrechende Foundation-Modell für tabulare Daten. In der Diskussion geht es um die Funktionsweise von TabPFN, die Rolle von In-Context Learning, die Herausforderungen bei der Anwendung der Transformer-Architektur auf tabulare Daten sowie die Generierung synthetischer Daten mit strukturellen kausalen Modellen (SCMs). Darüber hinaus beleuchten wir die beeindruckenden Benchmarking-Ergebnisse und zusätzliche Features des Modells. Zum Ende hin sprechen wir über die offenen Herausforderungen von Prior Labs und welche "Moonshots" sie für die Zukunft planen.
 
**Zusammenfassung:**
TabPFN ist ein Modell für Vorhersagen auf tabellarischen Daten, entwickelt von Prior Labs
Es nutzt In-Context Learning, um Aufgaben durch Sequenzen von Daten zu lernen, und wurde speziell für die Transformer-Architektur angepasst
TabPFN wurde mit 100 Millionen synthetischen Datensätzen, die durch strukturelle kausale Modelle (SCMs) generiert wurden, trainiert
Es stellt einen neuen Benchmark dar und liefert starke Leistungen über verschiedene Domänen hinweg
Das Modell kann Unsicherheiten quantifizieren, mit fehlenden Werten umgehen und Outlier erkennen
TabPFN ist auf Consumer-Hardware trainierbar, was die Entwicklung auch auf kleinen GPUs ermöglicht
Zukünftige Entwicklungen fokussieren sich auf Zeitreihen, Kausalität und multimodale Modelle
 
**Links:**
Blog: TabPFN: Die KI-Revolution für tabulare Daten https://www.inwt-statistics.de/blog/tabpfn-die-ki-revolution-fuer-tabulare-daten
Nature Publikation zu tabPFN aus 2025: https://www.nature.com/articles/s41586-024-08328-6
Artikel über tabPFN  in Fortune: https://fortune.com/2025/02/05/prior-labs-9-million-euro-preseed-funding-tabular-data-ai/
Nature News & views von Duncan C. McElfresh: https://www.nature.com/articles/d41586-024-03852-x
Zeit für Unternehmer: https://www.zeit.de/zeit-fuer-unternehmer/2025/01/kuenstliche-intelligenz-tabpfn-tabellen-daten?freebie=a67d9166
Publikation zu tabICL: https://arxiv.org/abs/2502.05564
früher Hintergrund-Artikel zur Transformers Architektur für Bayesianische Inferenz : https://arxiv.org/abs/2112.10510
früheres Working Paper zu tabPFN: https://arxiv.org/abs/2207.01848
GitHub Repo zu tabPFN: https://github.com/PriorLabs/TabPFN
Homepage Prior Labs: https://priorlabs.ai/
#71: Predictive LLMs: Skalierung, Reproduzierbarkeit & DeepSeek https://www.podbean.com/ew/pb-p2wjd-1897b7e
Feedback, Fragen oder Themenwünsche gern an podcast@inwt-statistics.de

#71: Predictive LLMs: Skalierung, Reproduzierbarkeit & DeepSeek

In dieser Folge geht's um die Frage: Macht Größe von Large Language Models (LLMs) bei Predictive Analytics wirklich einen Unterschied? Wir vergleichen Open-Source-Modelle mit bis zu 70 Milliarden Parametern – und siehe da, das 8B-Modell schlägt das große Schwergewicht. Außerdem berichten wir vom Finetuning auf einer AWS-Maschine mit 8 A100-GPUs und den Herausforderungen in Bezug auf die Reproduzierbarkeit. Auch das viel diskutierte DeepSeek-Modell haben wir im Autopreis-Benchmark antreten lassen. Und wie immer fragen wir uns: Was ist praktisch und was ist overkill?
 
**Zusammenfassung**
Modellgröße ≠ bessere Prognosen: Das Llama-3.1-8B übertraf das größere 70B-Modell bei der Fahrzeugpreisprognose
DeepSeek im Benchmark: Das chinesische Modell zeigt bei größeren Trainingsmengen eine ähnlich gute Performance wie das Llama-3.1-8B, ist bei kleinen Datensätzen aber schwächer
Finetuning mit Multi-GPU auf AWS: Für das 70B-Modell war ein Setup mit 8 A100-GPUs nötig
Reproduzierbarkeit bleibt schwierig: Trotz Seed erzeugen wiederholte Finetuning-Runs unterschiedliche Ergebnisse
Modellselektion empfohlen: Um zuverlässige Prognosen zu erhalten, sollte aus mehreren Finetuning-Durchläufen das beste Modell ausgewählt werden
CPU-Inferenz möglich, aber langsam: Im Vergleich zur GPU war die Vorhersage auf der CPU ca. 30-mal langsamer, Quantisierung könnte künftig Abhilfe schaffen
Ausblick auf TabPFN & Quantisierung: Kommende Beiträge widmen sich Erfahrungen mit TabPFN und der praktischen Umsetzung von quantisierten LLMs auf kleineren Maschinen
**Links**
[Begleitender Blogartikel] Predictive LLMs: Skalierung, Reproduzierbarkeit & DeepSeek https://www.inwt-statistics.de/blog/predictive-llms-skalierung-reproduzierbarkeit-und-deepseek
#50: Predictive Analytics mit LLMs: ist GPT3.5 besser als XGBoost? https://inwt.podbean.com/e/50-predictive-analytics-mit-llms-ist-gpt35-besser-als-xgboost/
#64: Predictive LLMs: Übertreffen Open-Source-Modelle jetzt OpenAI und XGBoost bei Preisprognosen https://inwt.podbean.com/e/64-predictive-llms-ubertreffen-open-source-modelle-jetzt-openai-und-xgboost-bei-preisprognosen/
vLLM Framework für schnelle Inferenz: https://github.com/vllm-project/vllm?tab=readme-ov-file
torchtune Finetuning-Framework von PyTorch: https://github.com/pytorch/torchtune
PyTorch Reproducibility: https://pytorch.org/docs/stable/notes/randomness.html
Paper zur Reproduzierbarkeit von QLoRA-Finetuning: S. S. Alahmari, L. O. Hall, P. R. Mouton and D. B. Goldgof, "Repeatability of Fine-Tuning Large Language Models Illustrated Using QLoRA," in IEEE Access, vol. 12, pp. 153221-153231, 2024, doi: 10.1109/ACCESS.2024.3470850 https://ieeexplore.ieee.org/document/10700744
heise online: Komprimierte KI: Wie Quantisierung große Sprachmodelle verkleinert von René Peinl https://www.heise.de/hintergrund/Komprimierte-KI-Wie-Quantisierung-grosse-Sprachmodelle-verkleinert-10206033.html
deepseek-ai/DeepSeek-R1-Distill-Llama-8B auf Huggingface https://huggingface.co/deepseek-ai/DeepSeek-R1-Distill-Llama-8B#6-how-to-run-locally
TabPFN: Hollmann, N., Müller, S., Purucker, L. et al. Accurate predictions on small data with a tabular foundation model. Nature 637, 319–326 (2025). https://doi.org/10.1038/s41586-024-08328-6 
Feedback, Fragen oder Themenwünsche gern an podcast@inwt-statistics.de

#70: Der Aufstieg zur Datenreife – Stufe für Stufe zur Data Maturity

Wie datenreif ist dein Unternehmen eigentlich? Wir sprechen über die fünf Stufen der Data Maturity – von manueller Datensammlung bis zur KI als Teil der Unternehmenskultur. Dabei geht es auch um die Rolle der Organisation, warum viele beim „Death by Dashboards“ hängenbleiben und wie man echte Fortschritte macht. Und wir diskutieren, welche Abkürzungen auf diesem Weg funktionieren – und welche eher nach hinten losgehen.
 
**Zusammenfassung**
Data Maturity Skala: Fünf Stufen von manueller Datennutzung bis zu datengetriebener Kultur mit AI/ML – viele Unternehmen stecken noch in den unteren Bereichen fest
Organisationskultur als Schlüssel: Kultur bestimmt maßgeblich, wie datenreif ein Unternehmen wird – HiPPO-Denke (Highest Paid Person's Opinion), Risikoaversion und fehlende Offenheit sind häufige Bremsklötze
Typische Hürden: Datensilos, fehlendes Qualitätsbewusstsein, "Death by Dashboards" und Projekte ohne echten Erkenntnisgewinn
Aufbau von Datenreife: Kombination aus Top-Down-Initiativen und Bottom-up-Leuchtturmprojekten, ergänzt durch agile Vorgehensweise
PoC → MVP → Produkt: Datenprojekte sollten in kurzen, klar umrissenen Phasen geplant und bei fehlendem Nutzen auch konsequent gestoppt werden
Abkürzungen und Workarounds: Externe Daten, simulierte Daten oder cloudbasierte Infrastruktur können helfen – bergen aber auch Risiken für Aussagekraft und Akzeptanz
Data Mesh & Self-Service BI: Nur sinnvoll bei entsprechender Datenkultur – sonst droht mehr Chaos als Erkenntnisgewinn
 
**Links**
Maturity Model mit 5 Stufen von Gartner: Gartner Survey Shows Organizations Are Slow to Advance in Data and Analytics https://www.gartner.com/en/newsroom/press-releases/2018-02-05-gartner-survey-shows-organizations-are-slow-to-advance-in-data-and-analytics
#61: Technologische Must-Haves: Unser Survival-Guide für Data-Science-Projekte https://www.podbean.com/ew/pb-k6fx5-175ea51
#36: Der Data Mesh Hype und was davon bleibt https://www.podbean.com/ew/pb-7er7v-15080c1
Feedback, Fragen oder Themenwünsche gern an podcast@inwt-statistics.de

#69: AI Agents verstehen und evaluieren mit Matthäus Deutsch

AI Agents sind mehr als nur Chatbots – aber wie bewertet man sie richtig? Wir sprechen über die Herausforderungen beim Testen von AI im Kundenservice, warum falsche API-Parameter ins Chaos führen und wieso "mysteriöser Fleischeintopf" ein PR-Desaster wurde. Matthäus Deutsch von Parloa berichtet, wie flexible Plattformintegrationen und evaluative Ansätze (z.B. assertion-based Testing und Simulationen) den Einsatz von AI Agents vorantreiben. Außerdem: welche Metriken wirklich zählen, was Multi-Agent-Setups leisten und warum der Preisverfall bei Open-Source-Modellen das Game verändert. 
 
Zusammenfassung
AI Agents erweitern klassische Chatbots im Kundenservice, insbesondere im Telefonbereich, durch GenAI-basierte, dynamische Lösungen
Parloa demonstriert flexible Plattformintegrationen und den Einsatz von Evaluationsmethoden wie assertion-based Testing und Simulationen
Die Evaluation von AI Agents erfordert spezielles Benchmarking auf Plattform- und individueller Ebene
Typische Herausforderungen sind Integrationsprobleme, fehlerhafte API-Calls und unzureichendes Instruction Following
Tests erfolgen sowohl auf Konversationsebene als auch durch deterministische Ansätze und LLMs als Judge
Es müssen komplexe Metriken und Trade-offs beachtet werden, wobei häufig binäre Testansätze aggregiert werden
Schnelle Updates auf neue Modellversionen sind möglich, allerdings steigen langfristig die Kosten durch umfangreiche Testzyklen
Innovationen wie optimierte Speech-to-Speech-Technologien und Open-Source-Lösungen (z. B. DeepSeek) bieten Potenzial zur Kostenreduktion
Der Einsatz von Operatoren-Modellen und Tool-Integrationen ermöglicht auch die Anbindung an Legacy-Systeme, z.B. SAP
Ziel ist es, den Automatisierungsanteil im Kundenservice zu erhöhen und eine Balance zwischen bewährter Qualität und neuen Features zu finden
Links
Matthäus Deutsch auf LinkedIn: https://www.linkedin.com/in/matth%C3%A4us-d-928864ab/
Parloa Contact-Center-AI-Plattform https://www.parloa.com/de/
Stellenangebote bei Parloa https://www.parloa.com/company/careers/#jobs
#55: Alle machen XGBoost, aber was macht eigentlich XGBoost? Mit Matthäus Deutsch https://www.podbean.com/ew/pb-6gvc6-16d5018
#64: Predictive LLMs: Übertreffen Open-Source-Modelle jetzt OpenAI und XGBoost bei Preisprognosen? https://www.podbean.com/ew/pb-m5qr2-17c425d
heise online: "Aromatisches" Chloramingas, Eintopf aus Menschenfleisch: KI-Rezepte irritieren https://www.heise.de/news/Aromatisches-Chlorgas-Eintopf-aus-Menschenfleisch-KI-irritiert-mit-Rezepten-9242991.html
Feedback, Fragen oder Themenwünsche gern an podcast@inwt-statistics.de

#68: CI/CD für Daten: Datenversionierung für stabile & nachvollziehbare Systeme

Daten(banken) versionieren – klingt maximal unsexy, spart aber Stress im Deployment. Warum ohne Schema-Versionierung selbst kleine Änderungen große Probleme verursachen und was ORMs, Flyway oder Liquibase damit zu tun haben, erfahrt ihr hier. Daten historisieren ist ein Must-have für Compliance, Reproduzierbarkeit und Modellierung. Aber Achtung: Nicht jede Lösung passt für jede Datenbank und den Live-Betrieb. Wir geben Tipps, wie ihr eure Datenprodukte systematisch und effizient im Griff behaltet.
**Zusammenfassung**
Schema-Versionierung ist essenziell, um Änderungen an Datenbanken nachvollziehbar und reibungslos ins Deployment einzubinden
Fehlende Versionierung kann zu kaputten Prozessen führen, wenn Schema-Änderungen nicht dokumentiert und automatisiert umgesetzt werden
Werkzeuge wie ORMs, Flyway oder Liquibase helfen dabei, Änderungen an Datenbankschemata strukturiert zu verwalten
Historisierung von Daten ist für Compliance, Reproduzierbarkeit und Modellierung entscheidend  
Ansätze zur Datenhistorisierung: Append-only-Strategien vs. System-Versionierung
Herausforderungen: Performance-Engpässe, hohe Pflegekosten und Kompatibilitätsprobleme je nach Datenbank und Migrationstool  
Best Practices: Versionierung systematisch einführen, Automatisierung priorisieren und sicherstellen, dass Downgrades funktionieren.  
**Links**
#58: Arm, aber sexy: Data Warehousing at Scale ohne Budget https://www.podbean.com/ew/pb-gywt4-1719aef
#52: In-process Datenbanken und das Ende von Big Data https://www.podbean.com/ew/pb-tekgi-16896e4
#36: Der Data Mesh Hype und was davon bleibt https://www.podbean.com/ew/pb-7er7v-15080c1
Flyway: https://www.red-gate.com/products/flyway/
Liquibase: https://www.liquibase.com/
Alembic (für SQLAlchemy): https://alembic.sqlalchemy.org/en/latest/
MariaDB: https://mariadb.org/
ClickHouse: https://clickhouse.com/
Fragen, Feedback und Themenwünsche gern an podcast@inwt-statistics.de

#67: "It works on my machine" war gestern – Docker Best Practices für Data Science

Dieser Satz "it works on my machine" hat IT-Teams und Data Scientists lange Nerven gekostet. Früher war Deployment ein mühsames Zusammenspiel aus Setup-Anleitungen, inkompatiblen Umgebungen und endlosen Rückfragen. Docker bringt endlich Ordnung ins Chaos: Anwendungen laufen isoliert, reproduzierbar und unabhängig vom Host-System. Warum Containerisierung für Data Science ein echter Gamechanger ist und welche Best Practices du kennen solltest, erfährst du in dieser Folge!
 
Zusammenfassung 
Früher war Deployment umständlich: lange Setup-Anleitungen, inkompatible Umgebungen, viele Rückfragen 
Virtuelle Maschinen haben das Problem teilweise gelöst, sind aber ressourcenintensiv und unflexibel
Data Scientists arbeiten oft mit R/Python, was IT-Abteilungen vor Herausforderungen stellt
Fehlende Reproduzierbarkeit führt zu Stress, Verzögerungen und hohem Kommunikationsaufwand
Docker schafft eine standardisierte, isolierte und reproduzierbare Umgebung für Anwendungen
Container laufen direkt auf dem Host-OS, sind schlanker als VMs und starten schneller
Mit Dockerfiles lassen sich Umgebungen als Code definieren und automatisch deployen
Best Practices: schlanke Base-Images, .dockerignore, nur benötigte Abhängigkeiten installieren
Automatisierung mit CI/CD-Pipelines beschleunigt den Entwicklungs- und Deploy-Prozess
Containerisierung ist für moderne Data-Science-Workflows unverzichtbar und spart IT sowie Data Science viel Zeit
Links
Offizielle Docker Dokumentation https://docs.docker.com/
Docker Hub https://hub.docker.com/
[Blog] Die Welt der Container: Einführung in Docker https://www.inwt-statistics.de/blog/die-welt-der-container-einfuehrung-in-docker
[Podcast] #14: Kubernetes https://www.podbean.com/ew/pb-m5ggz-13454c7
[Podcast] #59: Besser mit Helm: komplexe Deployments einfach(er) umsetzen https://www.podbean.com/ew/pb-txhnf-17314de
[Video] Solomon Hykes stellt Docker vor (2013) "The future of Linux Containers" https://www.youtube.com/watch?v=wW9CAH9nSLs&t=158s
Fragen, Feedback und Themenwünsche gern an podcast@inwt-statistics.de

#66: Developer vs. Data Scientist mit Andy Grunwald und Wolfgang Gassler

Warum knirscht es immer wieder zwischen Data Scientists und Developern? In dieser Episode holen wir uns Verstärkung von Andy und Wolfi vom Engineering Kiosk Podcast um dieser Frage auf den Grund zu gehen. Wir reden über typische Klischees und warum diese zu Konflikten führen. Gemeinsam sprechen wir darüber, welche Skills helfen, damit beide Spezies am Ende harmonisch zusammenarbeiten können – statt sich gegenseitig auszubremsen.
Zusammenfassung
Klischees und Konflikte: Stereotype über Data Scientists (Jupyter-Fans, Doktortitel) und Developer (Perfektionismus, Black-Box-Furcht)
Teamorganisation: Cross-funktionale Teams vs. getrennte Abteilungen (Vor- und Nachteile, Agenturmodell)
Typische Herausforderungen: Übergabe von Prototypen an die Entwicklung, Verständnis von SLAs/Responsezeiten, Datenbankauswahl
Skill-Set und Zusammenarbeit: Generalistisches Grundwissen in DevOps und Softwarearchitektur, offenes Mindset
Links
Engineering Kiosk Podcast: https://engineeringkiosk.dev/
Andy Grunwald auf LinkedIn: https://www.linkedin.com/in/andy-grunwald-09aa265a/
Wolfgang Gassler auf LinkedIn: https://www.linkedin.com/in/wolfganggassler/
[Engineering Kiosk] #179 MLOps: Machine Learning in die Produktion bringen mit Michelle Golchert und Sebastian Warnholz https://engineeringkiosk.dev/podcast/episode/179-mlops-machine-learning-in-die-produktion-bringen-mit-michelle-golchert-und-sebastian-warnholz/
[Engineering Kiosk] #178 Code der bewegt: Infotainmentsysteme auf Kreuzfahrtschiffen mit Sebastian Hammerl https://engineeringkiosk.dev/podcast/episode/178-code-der-bewegt-infotainmentsysteme-auf-kreuzfahrtschiffen-mit-sebastian-hammerl/
[Engineering Kiosk] #177 Stream Processing & Kafka: Die Basis moderner Datenpipelines mit Stefan Sprenger https://engineeringkiosk.dev/podcast/episode/177-stream-processing-kafka-die-basis-moderner-datenpipelines-mit-stefan-sprenger/
[Data Science Deep Dive] #30: Agile Softwareentwicklung im Data-Science-Kontext https://www.podbean.com/ew/pb-mvspn-1482ea4
[Data Science Deep Dive] #23: Unsexy aber wichtig: Tests und Monitoring https://www.podbean.com/ew/pb-vxp58-13f311a
[Data Science Deep Dive] #20: Ist Continuous Integration (CI) ein Muss für Data Scientists? https://www.podbean.com/ew/pb-4mkqh-13bb3b3
Fragen, Feedback und Themenwünsche gern an podcast@inwt-statistics.de