
Sign up to save your podcasts
Or


Wenn du glaubst, dass du YAML kennst …
„YAML Ain’t Markup Language“ (ursprünglich „Yet Another Markup Language“) kennen viele nur als Sprache für Konfigurationsdateien. Laut dem Gründer von YAML ist das Format aber nicht dafür gedacht. Und überhaupt nutzen sehr viele Tools nur einen Bruchteil der Fähigkeiten von YAML. Welche das sind, hat uns Tina Müller erklärt. Tina ist u.a. Contributorin zur YAML Spezifikation und gibt uns mal einen Einblick in das Serialisierungs-Format.
Wir sprechen über darüber, welches Problem YAML lösen wollte, wie es in der Realität genutzt wird, wie YAML selbst sowie die YAML-Parser in verschiedenen Sprachen weiterentwickelt werden, über die Flaws von YAML, wie zB. das Norway Problem oder die Billion Laughs Attacke und schauen mal welche Features nicht so bekannt sind, wie YAML tags, aliases oder YAMLScript.
Das schnelle Feedback zur Episode:
👍 (top) 👎 (geht so)
Feedback
Gerne behandeln wir auch euer Audio Feedback in einer der nächsten Episoden, einfach die Audiodatei per Email an [email protected].
(00:00:00) YAML mit Tina Müller
(00:06:27) Was ist YAML und wie zeichnet sich YAML aus?
(00:09:19) YAML, JSON und die Abgrenzung zu anderen Formaten
(00:11:00) Info/Werbung
(00:12:37) YAML, JSON und die Abgrenzung zu anderen Formaten
(00:28:56) YAML-Spezifikation
(00:33:22) YAML-Testsuite
(00:39:24) Das Norway-Problem
(00:44:39) YAML-Features: Aliases, Anchors und YAMLScript
No-Code-Tools sind technische Schulden!
Wenn es zu dem Thema No-Code kommt, gibt es oft zwei Lager: Die einen lieben es. Die anderen sagen “Das ist doch gar kein richtiges Programmieren”. Dennoch gibt es Firmen, die No-Code-Plattformen im großen Stil einsetzen. Und immer wenn damit “mal was richtiges” gebaut wird, stellen sich dieselben Fragen wie bei richtiger Software-Entwicklung: Wie sieht es mit der Security / Maintainability / Skalierung und Co aus? Und wenn wir sowas auf den Tisch bringen, dann ist das Thema Refactoring und technische Schulden nicht mehr weit.
Und genau darum geht es in dieser Episode. Wolfgang ist fest überzeugt von “No-Code-Tools sind technische Schulden!”. Und Andy lässt sich das ganze mal erklären, um zu verstehen, was er eigentlich damit meint. Wir sprechen darüber, was No-Code und Low-Code eigentlich ist, was technische Schulden sind und warum dies ggf. nicht subjektiv zu sehen ist, welche Probleme sich bei großer No-Code-Nutzung auftun und ob klassische Probleme (aber auch Lösungen) der Software-Entwicklung sich auf die No-Code-Entwicklung übertragen lassen.
Bonus: Streit auf LinkedIn ist wohl nicht gern gesehen.
Das schnelle Feedback zur Episode:
👍 (top) 👎 (geht so)
Feedback
Gerne behandeln wir auch euer Audio Feedback in einer der nächsten Episoden, einfach die Audiodatei per Email an [email protected].
(00:00:00) No-Code sind technische Schulden
(00:03:13) Info/Werbung
(00:04:18) Was ist No-Code und Low-Code?
(00:23:03) Was ist Technical Debt?
(00:32:08) Technische Schulden bei keinem Code - Wie geht das?
(00:38:07) Gelöste Probleme im High-Code-Umfeld sind neue Probleme im No-Code-Umfeld
(00:47:35) Security im No-Code-Umfeld
(00:52:38) Steht No-Code im Konflikt zu moderner Software-Entwicklung?
(00:59:17) No-Code richtig eingesetzt ist dein Beschleuniger
Wie gehen andere bei ihrer Jobsuche vor? Ein Erfahrungsaustausch
Irgendwann kommt der Zeitpunkt, da denken viele von uns “Soll ich mir mal was Neues suchen? Ein Tapetenwechsel im Job könnte mir ggf. gut tun.” oder “Ich will endlich mal was anderes sehen” oder “Das könnte mein nächster Schritt in meiner Karriere sein”. Aber: Die Jobsuche kann anstrengend sein. Im Internet liest man viele Do’s und Dont’s. Verwirrung kommt schnell auf, was nun der richtige Weg ist. Deswegen sind Erfahrungen von anderen so wichtig. Und genau darum geht es in dieser Podcast-Episode.
Zu Gast sind Doreen und Ellen vom UNMUTE IT Podcast. Beide haben vor kurzer Zeit ihren Arbeitgeber gewechselt und erzählen von ihrer Herangehensweise und Erfahrungen bei der Job-Suche. Wir sprechen über Job-Hopping und wann es Zeit ist, sich einen neuen Job zu suchen, wie und wo man nach neuen Arbeitsmöglichkeiten sucht, wie wichtig das eigene Netzwerk und Vitamin-B ist, worauf es bei der richtige Firma ankommt, was Red-Flags und Warnsignale ist sind, über den Interviewprozess, wie viel Glück involviert ist und wie man mit Misserfolgen umgeht.
Viel Spaß bei diesem Podcast-Crossover.
Das schnelle Feedback zur Episode:
👍 (top) 👎 (geht so)
Feedback
Gerne behandeln wir auch euer Audio Feedback in einer der nächsten Episoden, einfach die Audiodatei per Email an [email protected].
(00:00:00) Podcast-Crossover mit UNMUTE IT
(00:06:02) Info/Werbung
(00:07:20) Podcast-Crossover mit UNMUTE IT
(00:07:21) Wann fängt es an, darüber nachzudenken, sich einen neuen Job suchen?
(00:14:40) Job-Hopping und ab wann ist es zu lang bei einer Firma?
(00:22:07) Der erste Schritt bei der (strukturierten) Job-Suche
(00:29:40) Das eigene Netzwerk bei der Job-Suche
(00:41:59) Hire for attitude, not for skill und Interviews
(00:58:00) Die richtige Firma finden
(01:13:36) Warnsignale und Red-Flags
(01:32:08) Interview-Prozess und Take Home Challenges
(01:43:49) Verhandlungen und Gehalt
(01:54:18) Abschluss
Explain my like i am five: Die Grundlagen moderner Suchen
Wir, als User, erwarten heutzutage ziemlich viel von einer Suchmaschine. Es soll “magisch” verstehen, was wir eigentlich finden möchten. Egal ob wir das richtige Wort dafür nutzen (aka Synonym-Suche) oder ob der Begriff einen Tippfehler hat (aka “Meinten Sie …?”).
Oft werden Tools wie Elastic- oder OpenSearch, Solr, Algolia und Co. für sowas eingesetzt, denn eine einfache Volltext-Suche mittels eines Wildcard-SQL-SELECT Statement reicht dafür nicht mehr aus. Doch was steckt eigentlich dahinter? Wie funktionieren all diese modernen Suchen eigentlich im Inneren? In dieser Episode geht es um die Grundlagen moderner Suchmaschinen. Wir schmeißen mit Begriffen wie Stemming, Homonyme, BERT, Stopwords, Inverted Index, Suffixbäume, N-Grams, Term Frequency-Inverse Document Frequency, Vector Space Model und Co um uns und erklären das ganze im “Explain me Like I am five”-Stil.
Bonus: Wie Konzepte des Information Retrieval mit Bälle-Bädern erklärt werden.
Das schnelle Feedback zur Episode:
👍 (top) 👎 (geht so)
Feedback
Gerne behandeln wir auch euer Audio Feedback in einer der nächsten Episoden, einfach die Audiodatei per Email an [email protected].
(00:00:00) Buzzword-Bingo bei modernen Suchen
(00:04:40) Die Komplexität moderner Such-Systeme
(00:05:55) Info/Werbung
(00:07:00) Die Komplexität moderner Such-Systeme
(00:09:58) Wie funktioniert High-Level eine Suchmaschine?
(00:11:04) Verarbeitung der Such-Daten durch Tokens: Sprache, Stop-Words, Lemmatisierung, Stemming
(00:20:53) Zahlen als Such-Wörter, Embeddings und Bidirektionale Encoder-Repräsentationen von Transformers (BERT)
(00:29:34) Speichern der Daten mit einem Index: Invertierter Index und Suffixbäume
(00:43:07) Daten wirklich finden durchs Ranking: N-Grams, TF/IDFrequency und Vector Space Model
(00:59:54) Wie wählt man ein gutes Such-System aus?
(01:04:20) Wie beeinflusst Generative AI die aktuellen Suchsysteme und Sucht-Grundlagen?
Ein Leitspruch für die Frontend-Welt: Make simple things simple and complex things possible
Die Frontend-Entwicklung hat in den letzten Jahren einen ziemlich großen Wandel erlebt. Es fing alles ganz simpel an: CSS und JavaScript wurden einfach via script-tag inkludiert. Danach kamen Performance-Optimierung durch Minification, mehr JavaScript- und CSS Features (zB Browser-APIs) wurden in die Browser implementiert und die Standards kamen nicht hinterher, doch wir Entwickler*innen wollten wir diese schon in Produktion nutzen (aka Polyfills und Transpilieren). Und auch die Web-Apps wurden immer mehr “Desktop-Like”, was einen Effekt auf die Frontends von heute hat, zB. React, Vue und Co. Und wo sind wir heute? Frameworks wie HTMX, die mit Einfachheit werben, erleben einen neuen Hype.
Doch ist das alles neu oder nur “alter Wein in neuen Schläuchen”? Erkaufen wir uns durch diesen großen Tooling-Stack wirklich Einfachheit oder schließen wir uns durch die Komplexität doch nicht in eine "proprietäre API” ein, die es sehr schwer macht, das Framework zu wechseln? Und zu guter letzt: Ist die Komplexität gerechtfertigt?
Zu diesem Thema sprechen wir mit Golo Roden. Golo ist Frontend-Experte und spezialisiert auf native Webtechnologien. Mit ihm behandeln wir Themen wie die Probleme von aktuellen UI-Frameworks und woher diese Probleme eigentlich kommen, wie er zu einfacheren Konzepten wie HTMX steht, über mögliche Lösungsansätze für die Probleme, Standards wie Web Components und welche Rolle TypeScript in dem ganzen Mix einnimmt.
Bonus: Warum Monkey Island das richtige Spiel für dich und deine Kinder ist.
Das schnelle Feedback zur Episode:
👍 (top) 👎 (geht so)
Feedback (gerne auch als Voice Message)
Gerne behandeln wir auch euer Audio Feedback in einer der nächsten Episoden, einfach Audiodatei per Email oder WhatsApp Voice Message an +49 15678 136776
(00:00:00) Unser Gast Golo Roden
(00:06:28) Info/Werbung
(00:07:32) Monkey Island für Kinder
(00:11:53) Der aktuelle Tech-Stack in einem Web-Projekt
(00:15:04) Innovation in der Frontend-Welt oder alter Wein in neuen Schläuchen?
(00:26:10) Was ist HTMX und welches Problem soll es lösen?
(00:33:11) Kritikpunkte an HTMX
(00:42:50) Innovation fördert auch die Standardisierung im Web
(00:47:29) Bloated JavaScript und User Experience im Web
(00:55:51) Hohe Kohäsion, niedrige Kopplung
(01:02:00) Web Components und Standardisierung
(01:09:04) Welche Rolle spielt TypeScript in diesem Mix?
AI in der Software-Delivery: Unsere größte Möglichkeit oder purer Hype? - Ein Realitätscheck
Generative AI ist in der Software-Entwicklung allgegenwärtig. Mit Co-Pilot stellt GitHub den Platzhirsch im Bereich Codegenerierung und bewirbt es mit einer 55% Produktivitätssteigerung. Bei solchen Effekten dreht jedes C-Level-Management am Rad. Doch was ist dran am Hype? Sollten wir wirklich alle so aufgeregt sein?
Zu dieser Frage bzw. zu einem Realitätscheck sprechen wir mit Birgitta Böckeler, Global Lead for AI-assisted Software Delivery bei Thoughtworks. Sie beschäftigt sich u.a. damit, wozu Generative AI in der Softwareentwicklung genutzt werden kann, welche Einsatzbereiche neben der Codegenerierung existieren, für welche Bereiche Coding Assistenten gut und für welche nicht so gut sind funktionieren aber auch welchen Effekt die ganze AI-Bewegung auf den ganzen Softwareentwicklungsprozess hat.
Bonus: Ein Kampf zwischen AI-Fans und Skeptiker
Das schnelle Feedback zur Episode:
👍 (top) 👎 (geht so)
Feedback (gerne auch als Voice Message)
Gerne behandeln wir auch euer Audio Feedback in einer der nächsten Episoden, einfach Audiodatei per Email oder WhatsApp Voice Message an +49 15678 136776
(00:00:00) Software Delivery und AI mit Birgitta Böckeler
(00:03:09) Info/Werbung
(00:04:15) Birgitta Böckeler - Global Lead for AI-assisted Software Delivery
(00:07:17) Was ist Generative AI im Umfeld der Software-Entwicklung?
(00:13:33) Wie viel Erfahrung ist für den sinnvollen Einsatz von Generative AI notwendig?
(00:22:36) Intellectual Property (IP) bei Coding LLMs
(00:27:09) Retrieval Augmented Generation, Halluzinationen und Kontext für das LLM
(00:41:58) Erhöhte Produktivität durch Coding Co-Piloten
(00:55:40) In welchen Bereichen der Software-Entwicklung kann AI uns noch helfen?
(01:02:44) Wie verändert sich die professionelle Softwareentwicklung durch AI?
Den Softwareentwicklungs-Prozess beschleunigen, indem mehr Arbeit auf die Entwickler abgewälzt wird?
2024 ist das Jahr der Effizienz. Überall wird nachgesehen, was noch schneller und besser laufen kann. So auch bei der Softwareentwicklung. Denn dort ist allzeit bekannt: Umso später ein Fehler aufgedeckt wird, desto teurer ist seine Behebung. Deswegen wurde früh damit angefangen, nicht nach der Softwareentwicklung das Programm zu testen, sondern schon während der Entwicklung die Tests zu schreiben. Der Test-Prozess wurde in der Zeitleiste nach Links geschoben. In der Industrie nennt man diesen Vorgang “Shift Left”.
Doch bei Tests ist es nicht geblieben. DevOps verlagert die Operations nach Links. Cloud die Definition von Infrastruktur als Code (und somit in die Softwareentwicklung). Security nimmt ebenfalls einen wichtigen Standpunkt in der modernen Welt ein. Metriken, strukturierte Logs und weitere Signale für Observability sind ein fester Bestandteil der Softwareentwicklung. Doch wie viel Prozesse sollen (und können) dennoch nach Links verschoben werden? Wie viele Aufgaben soll eine einzige Entwicklerin erledigen? Ist nicht einfach mal gut?
Bonus: Alles mit Ops - DevOps / MLOps / CloudOps / AIOps / DataOps / SecOps / DevSecOps / HROps LegalOps BizOps LLMOps ChatOps NoOps
Das schnelle Feedback zur Episode:
👍 (top) 👎 (geht so)
Feedback (gerne auch als Voice Message)
Gerne behandeln wir auch euer Audio Feedback in einer der nächsten Episoden, einfach Audiodatei per Email oder WhatsApp Voice Message an +49 15678 136776
(00:00:00) Der Software-Engineer-Job wird bedroht
(00:03:11) Info/Werbung
(00:05:08) Was ist Shift Left?
(00:10:37) Welches Problem soll Shift Left lösen?
(00:14:21) Warum ist Shift Left gerade jetzt aktuell?
(00:16:56) Der Unterschied von Shift Left in einem Startup und in einem Konzern
(00:24:37) Aktivitäten, die nach Links geshifted werden
(00:33:13) ShiftLeft mit Infrastruktur und Plattformen
(00:38:00) Nachteile von Shift Left
(00:44:09) Konfliktpotenzial bei der Einführung von Shift Left
(00:52:05) Shift Left ist nichts neues
Sales Engineering: Die Karriere “on top” auf deiner eigentlichen Karriere
Im Software Engineering gibt es viele Vorurteile gegen die Sales-Funktion. Doch wenn wir mal ehrlich zu uns sind: Die Sales-Abteilung bringt die Kunden, die wiederum das Geld in die Firma bringen. Kurz um: Durch die Sales-Arbeit haben wir alle einen Job. Und wenn wir dies mal weiterdenken: Was wäre, wenn du mit deinem Engineering Know How an diesem Hebel etwas bewirken könntest?
Genau darum geht es in der Funktion des Sales Engineerings. In dieser Episode sprechen wir mit Patrick Pissang, dem Social Sales Engineer, und bringen etwas Licht ins Dunkle: Was ist Sales Engineering? Sind dies zwei Jobs in einer Person? Wie technisch muss ein Sales Engineer sein und wie sieht eigentlich ein solcher Sales Prozess aus? Welche Firmen können von dieser Rolle denn wirklich Gebrauch machen? Welche Skills sind gefragt und wie kann man mehr über diese Rolle erfahren?
All das in dieser Episode.
Bonus: Was Herr der Ringe und Sales Engineering gemeinsam haben.
Das schnelle Feedback zur Episode:
👍 (top) 👎 (geht so)
Feedback (gerne auch als Voice Message)
Gerne behandeln wir auch euer Audio Feedback in einer der nächsten Episoden, einfach Audiodatei per Email oder WhatsApp Voice Message an +49 15678 136776
(00:00:00) Sales Engineering mit Patrick Pissang, dem Social Sales Engineer
(00:04:03) Die Sales-Engineering-Map im Herr der Ringe Style
(00:07:34) Info/Werbung
(00:08:42) Vorurteile von Sales
(00:12:51) Was ist Sales Engineering?
(00:21:26) Die verschiedenen Rollen in einem Sales Prozess
(00:24:32) Sales Engineering vs. Solution Architect, Developer Advocate und Co
(00:28:33) Pre- und Post-Sales
(00:32:35) Karriere-Weiterentwicklung durch Sales-Engineering
(00:56:01) Schnupper-Kurs im Sales
Kommunikation und Marketing über die eigene Arbeit: Ein Muss oder Wichtigtuerei?
Jeder Angestellte ist für eine gewisse Aufgabe angestellt. Doch während der täglichen Arbeit kommt eine ganze Menge weitere Aufgaben dazu, die für viele Manager und andere Teams “unsichtbar” sind: Dem Kollegen bei seiner Entwicklungsumgebung helfen, den roten Test-Build fixen, dem Junior-Engineer eine Frage beantworten, eine Präsentation für das Meeting morgen vorbereiten, und so weiter.
Dennoch ist diese unsichtbare Arbeit wichtig. Oft wird diese auch als Glue-Work, also Klebstoff, der das ganze Konstrukt zusammenhält, beschrieben. Und über ein ganzes Jahr macht man davon nicht wenig. Doch damit diese Arbeit gesehen wird und auch eine entsprechende Wertschätzung bekommt, müssen andere davon erfahren. Und da kommt Kommunikation und Selbstmarketing ins Spiel.
In dieser Episode sprechen wir darüber, wie viel Selbstmarketing OK ist, ob es einen Unterschied zwischen leisen und lauten Personen gibt, wie Activity Logs oder Brag Documents dir selbst helfen können, die entsprechende Glue-Work zu deiner Vorgesetzt zu kommunizieren, und geben Tipps wie das ganze in die wöchentliche Arbeitsroutine eingebettet werden kann.
Bonus: Ist Zuckerfrei wirklich ohne Zucker und Alkoholfrei wirklich ohne Alkohol?
Das schnelle Feedback zur Episode:
👍 (top) 👎 (geht so)
Feedback (gerne auch als Voice Message)
Gerne behandeln wir auch euer Audio Feedback in einer der nächsten Episoden, einfach Audiodatei per Email oder WhatsApp Voice Message an +49 15678 136776
(00:00:00) Intro und das Brag Document
(00:01:44) Laut oder leise?
(00:07:49) An was haben wir vor 3 Monaten gearbeitet?
(00:10:20) Info/Werbung
(00:11:18) Protokollier deine Arbeit und Gluework
(00:24:49) Brag Document: Für dich und deine Vorgesetzte
(00:26:35) Das richtige Level an Kommunikation für die entsprechende Anerkennung
(00:39:54) Brag-Documents im Freelancing und die AI
(00:45:29) Ein einfacher Dokument reicht völlig aus
(00:48:08) Brag-Documents für die Beförderung und der eigene Impact
Feedback (gerne auch als Voice Message)Wenn der Wechsel vom Software Engineer zur Managerin eine Beförderung ist, ist dann der Wechsel vom Manager-Dasein zurück zum Software Engineer eine Degradierung?
Genau mit dieser Frage beschäftigen wir uns in dieser Episode. Umgangssprachlich nennt man den Wechsel hin und her, von Software Engineer zum Management und zurück, das Engineering Manager Pendulum.
Wir haben mit Tom Bartel gesprochen, der diesen Wechsel schon zweimal vollzogen hat. Mit Ihm sprechen wir darüber, wie der Gedanke zum Pendeln entstanden ist, wie sein Umfeld und das eigene Unternehmen darauf reagiert hat, wie schwierig es ist sich an andere Perspektiven und Flughöhen in der täglichen Arbeit anzupassen, wie das Gehirn sich auf die unterschiedlichen Tagesabläufe verändert, und was er Leuten raten würde, die ebenfalls darüber nachdenken, in das Engineering Manager Pendulum einzusteigen.
Bonus: Wie ein neuer Grill eine Verpackungswut auslösen kann.
Das schnelle Feedback zur Episode:
👍 (top) 👎 (geht so)
Feedback (gerne auch als Voice Message)
Gerne behandeln wir auch euer Audio Feedback in einer der nächsten Episoden, einfach Audiodatei per Email oder WhatsApp Voice Message an +49 15678 136776
Links(00:00:00) Intro
(00:04:00) Info/Werbung
(00:05:00) Engineering Management Pendulum und unser Gast Tom Bartel
(00:08:39) Was ist das Engineering Management Pendulum
(00:20:14) Möchtest du wieder Individual Contributor werden?
(00:27:21) Pendulum und die Firmenkultur
(00:31:34) Wie sich nach einem Pendel deine Arbeit verändert
(00:44:28) Leute im Team, die selbst gependelt sind
(00:51:57) Andere Flughöhen vs. Hands-On
(01:12:54) Tips zum pendeln, wenn du drüber nachdenkst
From the publisher's feed
Der Engineering Kiosk ist der deutschsprachige Software-Engineering-Podcast mit Wolfgang Gassler und Andy Grunwald rund um die Themen Engineering-Kultur, Open Source, Menschen, Technologie und…