Engineering Kiosk (Wolfgang Gassler, Andy Grunwald)
Explore every episode of Engineering Kiosk
| Pub. Date | Title | Duration | |
|---|---|---|---|
| 12 Nov 2024 | #149 Recommender Systems: Funktionsweise und Forschungstrends mit Eva Zangerle | 01:11:03 | |
Recommender Systems: Was steckt hinter modernen Empfehlungsalgorithmen? Moderne Empfehlungsalgorithmen begegnen uns im Alltag überall: Die nächste Serie bei Netflix, die “für dich zusammengestellte Playlist” bei Spotify oder “Kunden, die diesen Artikel gekauft haben, kauften auch” bei Amazon. In Zeiten von AI könnten wir meinen, dass dies alles schwarze Magie ist. Doch i.d.R. folgen die Empfehlungen gewissen Logiken. All das ganze wird im Research Bereich “Recommender Systems” genannt. Dies ist auch das Thema dieser Episode. Prof. Dr. Eva Zangerle, eine Expertin im Bereich Recommender System erklärt uns, was Recommender Systems eigentlich sind, welche Grundlegenden Ansätze für Empfehlungsalgorithmen existieren, wie viele Daten benötigt werden um sinnvolle Ergebnisse zu erzielen, was das Cold-Start Problem ist, wie Forscher evaluieren können, ob es gute oder schlechte Empfehlungen sind, was die Begriffe Recall und Precision eigentlich bedeuten, ob Empfehlungsalgorithmen auch einen gewissen Bias entwickeln können sowie welche Trends auf dem Forschungsgebiet zur Zeit aktuell sind. Unsere aktuellen Werbepartner findest du auf https://engineeringkiosk.dev/partners
Das schnelle Feedback zur Episode: Feedback
Gerne behandeln wir auch euer Audio Feedback in einer der nächsten Episoden, einfach die Audiodatei per Email an stehtisch@engineeringkiosk.dev. Links
Sprungmarken(00:00:00) Recommender Systems mit Eva Zangerle (00:06:07) RecSys - Die ACM Recommender Systems Conference (00:06:31) Info/Werbung (00:07:31) RecSys - Die ACM Recommender Systems Conference (00:17:58) User Profile und Kontexte in Recommender Systems (00:25:38) Wie baut man ein Recommender Systems auf? (00:36:02) Das Cold-Start Problem, balancierte Algorithmen und das Habsburger-Problem (00:42:37) Evaluierung von Recommender Systems: Precision und Recall (00:51:55) AI und LLMs als Empfehlungs-Assistent (00:55:51) Spezielle Datenbank-Systeme, Sequential Recommendation und Audio Recommendations (01:01:22) Key Trends in der Recommender Systems und Information Retrieval Szene (01:09:09) Empfehlung für den Einstieg in Recommender Systems Hosts
Feedback
| |||
| 14 Mar 2023 | #62 Technologien konsolidieren, oder wie Startups sammeln? | 01:08:20 | |
Was ist der richtige Ansatz? Ein Stack für die ganze Firma oder jedes Team darf die Technologie wählen, wie es möchte? Die Wahl der richtigen Programmiersprache, der richtigen Datenbank, der richtigen Cloud-Umgebung. Gibt es etwas, worüber sich Software-Engineers mehr streiten können? Doch genau diese Fragen stehen i.d.R. beim Start eines Projektes an. Zumindest, wenn das Team die freie Wahl hat. Dies ist das eine Extrem. Im anderen Extrem wird die Sprache und der Stack von der Firma vorgegeben und im Rahmen wird auch operiert. Was ist nun besser? Was sind die Vorteile von "Alles ist möglich"-Ansatz? Und warum sollte man diese nicht wählen? Und welche Gründe gibt es für den "Ein-Stack"-Ansatz? Und was passiert, wenn die Firma von einem Extrem ins andere wechseln möchte? Wie geht man bei einer möglichen Technologie-Konsolidierung vor? Was passiert mit der Innovationsfreudigkeit? Welchen Effekt hat dies auf die Mitarbeiterinnen? All das und noch viel mehr gibt es in dieser Episode. Bonus: Wird in Innsbruch alles immer neu entwickelt und ob das Spagetti Eis nur in NRW bekannt ist. Unsere aktuellen Werbepartner findest du auf https://engineeringkiosk.dev/partners
Das schnelle Feedback zur Episode: 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
Sprungmarken(00:00:00) Intro (00:01:03) Lieblingsprogrammiersprache und die Migration auf JavaScript (00:03:22) Zwei Extreme: Einheitlicher Stack oder Jeder darf wählen was man möchte (00:06:18) Vorteile vom "Alles ist möglich"-Ansatz (00:12:46) Nachteile vom "Alles ist möglich"-Ansatz (00:24:39) Vorteile vom einheitlichen Stack-Ansatz (00:29:58) Nachteile vom einheitlichen Stack-Ansatz und wird die Innovationsfreudigkeit geblockt und Legacy-Apps fördert? (00:34:58) Konflikte und Emotionen bei Konsolidierungen (00:40:07) Wie kann eine Konsolidierung durchgeführt werden? (00:55:42) Effekt auf die Mitarbeiter bei einer Konsolidierung (01:00:04) Wie ist der Stand bei euch in der Firma? Steht eine Konsolidierung bevor? (01:01:30) Welcher Ansatz ist denn nun der beste? (01:07:07) Zusammenfassung Hosts
Feedback (gerne auch als Voice Message)
| |||
| 04 Oct 2022 | #39 Gemischte Tüte: Software Engineer, Github, OpenSource, Git und HomeOffice | 00:47:46 | |
Ein neues Format: Die gemischte Tüte mit Software Engineers, Git, GitHub, Open Source und Home-Office-Equipment Eine Episode mit vier verschiedenen Themen, die uns als User-Fragen zugespielt wurden. Es geht um den Unterschied von einem Software Developer und Software Engineer, ob wirklich alles was wir auf GitHub finden als "Open Source" bezeichnet werden kann und benutzt werden darf, ob Git wirklich dezentral ist und wie wir das ganze eigentlich benutzen und wie die Home-Offices von Wolfgang und Andy eigentlich aussehen. Bonus: Ob Lakritz was in einer gemischten Tüte zu suchen hat. 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 Unsere aktuellen Werbepartner findest du auf https://engineeringkiosk.dev/partners
Links
Sprungmarken(00:00:00) Intro (00:00:35) Das Format "die gemischte Tüte" (00:02:42) Was ist der Unterschied von einem Software Developer und Software Engineer? (00:08:04) Ist eigentlich alles, was auf Github ist, Open Source und darf ich dies einfach so verwenden? (00:18:47) Ist Git wirklich dezentral und wir können weiterarbeiten, auch wenn GitHub down ist? (00:31:14) Wie sieht unser Home-Office Setup aus? (00:45:39) Outro Hosts
Feedback (gerne auch als Voice Message)
| |||
| 21 Feb 2023 | #59 Kann man mit Open Source Geld verdienen? | 00:54:11 | |
Finanzierung von Open-Source-Projekten ist essentiell - Doch welche Möglichkeiten gibt es? Open-Source-Projekte sind wichtiger denn je, in unserer aktuellen Gesellschaft. Projekte wie cURL, OpenSSL, sqlite und Co. werden oft von wenigen Leuten maintained, doch Millionen Menschen nutzen diese jeden Tag, auch oft ohne es zu wissen. Die meisten Open-Source-Projekte werden in der Freizeit maintained. Doch wie passt das zusammen, besonders wenn die Miete gezahlt werden muss und auch Essen auf dem Tisch sein soll? Da kommt das (nicht ganz so einfache) Thema der Finanzierung von Open Source Projekten auf. In dieser Episode gehen wir genau darauf ein und stellen euch ein paar Möglichkeiten vor, wie du Geld mit bzw. für dein Open-Source-Projekt bekommen kannst. Dabei geht es nicht nur um den Platzhirsch GitHub Sponsors, sondern auch um professionelles Sponsoring von Firmen, dem Early-Access-Modell, staatliche Förderungen und so langweilige Themen wie Steuern. Bonus: Was Rundfunkgeräte mit Batterien mit Open-Source zu tun haben und ob Geld wirklich motivierend ist. Unsere aktuellen Werbepartner findest du auf https://engineeringkiosk.dev/partners
Das schnelle Feedback zur Episode: 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
Sprungmarken(00:00:00) Intro (00:01:03) FOSDEM Konferenz, Community-Treffen und teures Bier (00:04:57) Geld und Open Source: Finanzierung von und Geld verdienen mit Open-Source Projekten (00:07:43) Open-Source Sponsoring von Firmen (für große und kleine Firmen) (00:14:03) Gerechte Verteilung von Geld innerhalb eines Open Source Projektes (00:21:20) Geld empfangen und Nutzen durch Fiscal Hosts (00:23:47) Early-Access-Modell: Früher Zugang zu neuen Features in Open Source Projekten (00:28:24) Das Open-Source Projekt als Produkt sehen (00:30:57) Open-Source-Arbeit als normaler Vollzeit-Arbeitnehmer (00:35:03) Aus dem Open-Source Projekt ein Business machen (Open-Core) (00:41:44) (Staatliche) Förderung und Stipendien zur Finanzierung von Open-Source Projekten (00:46:40) Versteuerung von Open-Source-Sponsoring (00:50:37) Ist es unmoralisch, mit Open-Source Geld zu verdienen? (00:51:49) Buy me a beer und Flachwitze Hosts
Feedback (gerne auch als Voice Message)
| |||
| 21 Nov 2023 | #98 Der Hype um Rust mit Matthias Endler | 01:13:45 | |
Rust: Die System-Programmiersprache der nächsten 40 Jahre? Die Programmiersprache Rust erlebt aktuell einen Hype, wie kaum eine andere Programmiersprache bisher. Sehr viele Leute nennen Rust als die nächste Programmiersprache, die sie gerne lernen wollen. Projekte auf Github prahlen damit, dass diese mit Rust geschrieben wurden. Und jede zweite Case-Study einer großen Tech-Firma hat etwas mit Rust zu tun. Doch warum wird die Sprache so gehyped? Ist es nur Marketing oder steckt wirklich der Knaller der nächsten 40 Jahre dahinter? Und ist wirklich alles Gold was glänzt? Irgendwo muss es doch auch ein paar Pitfalls und Shortcomings geben. In dieser Episode sprechen wir mit Matthias Endler. Matthias ist seit Anfang an bei Rust dabei. Dabei geht es um: Welches Problem Rust löst, einen Deep Dive in die Konzepte, wie sich die Lernkurve von Rust verhält, aber auch die Rückwärtskompatibilität gewährleistet wird und noch vieles vieles mehr. Bonus: Ob Franken oder Oberpfalz. Bayern bleibt Bayern. Das schnelle Feedback zur Episode: 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
Sprungmarken(00:00:00) Intro (00:00:55) Unser Gast Matthias Endler (00:06:30) Was ist Rust? (00:08:42) Info/Werbung (00:09:44) Was ist Rust? (00:10:46) Der Rust-Compiler und Rust im Einsatz bei Mozilla (00:17:59) Einsatzgebiete für Rust und die Performance (00:22:07) Die Lernkurve von Rust, Ownership und Borrowing (00:32:18) Globale Variablen in Rust und der Entwickler-Workflow mit dem Rust-Compiler (00:43:39) Rückwärts-Kompatibilität in Rust (00:53:36) Der Hype um Rust und das gute Image (00:57:43) Pitfalls und Shortcomings von Rust (01:01:48) Rust Compile-Zeiten und Multi-Paradigmen-Sprache (01:10:01) Ressourcen zum lernen von Rust (01:12:57) Outtakes Hosts
Feedback (gerne auch als Voice Message)
| |||
| 08 Nov 2022 | #44 Der Weg zum hochperformanten Team | 00:56:20 | |
Psychologie, Team-Dynamiken und hochperformante Teams: Zufällige Stichwörter oder relevante Themen? Eine Gruppe von Menschen soll zusammen und miteinander arbeiten. Am besten noch hochperformant, mit einem grandiosen Outcome und das ganze innerhalb einer Woche nach Gründung des Teams. So oder so ähnlich stellen sich viele Leute Team-Dynamiken vor. Dass dies alles nicht ganz so einfach ist, weiß jeder, der schon mal ein neues Team geformt bzw. übernommen hat. Das 5 Phasenmodell für die Teamentwicklung von Bruce Tuckman, ein US-amerikanischer Psychologe, kann dir eine gewisse Hilfestellung liefern. Forming, Norming, Storming, Performing und Mourning/Adjourning: Was zeichnet die einzelnen Phasen aus? Welches Verhalten kann beobachtet werden? Welche Fragen und Bedürfnisse entstehen bei den Teammitgliedern? Welcher Leadership-Style wird benötigt bzw. ist angebracht? Über dieses Thema sprechen wir in dieser Episode. Viel Spaß. Bonus: Was Puppenspieler mit Leadership zu tun haben, warum Kaiserschmarrn immer noch ein Thema ist und wieso das Currywurst-Museum + Bud Spencer-Museum eine Rolle spielt. 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 Unsere aktuellen Werbepartner findest du auf https://engineeringkiosk.dev/partners
Links
Sprungmarken(00:00:00) Intro (00:01:07) Sarg aus Pilzen und das Bestattungsmuseum (00:04:02) Wenn ein Mitglied das Team verlässt, hast du ein neues Team (00:05:10) Dynamiken in einem Team: "Wie läuft es bei dir?"-Floskel (00:08:09) Die 5 Phasen bei der Entwicklung eines Team (00:10:54) Woher kommt das Modell der 5 Phasen bei der Entwicklung eines Team und welche Phasen gibt es? (00:14:28) Phase 1: Forming - Die Einstiegs- und Findungsphase (der erste Kontakt) (00:19:11) Phase 2: Storming - Die Auseinandersetzungs- und Streitphase (der Konflikt) (00:26:54) Phase 3: Norming - Die Regelungs- und Übereinkommensphase (der Vertrag) (00:32:58) Phase 4: Performing - Die Arbeits- und Leistungsphase (die Kooperation) (00:43:56) Phase 5: Mourning/Adjourning - Die Auflösungsphase (00:47:02) Muss jedes Team alle Phasen durchlaufen? (00:50:43) Wie verhalten sich die Phasen und die Team-Dynamik in einem Remote-Setup? (00:53:59) Leadership-Workshops und Erfahrung durch Praxis (00:55:20) Outro und Feedback Hosts
Feedback (gerne auch als Voice Message)
| |||
| 23 Apr 2024 | #120 No-Code ist technische Schuld! | 01:07:56 | |
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: Feedback
Gerne behandeln wir auch euer Audio Feedback in einer der nächsten Episoden, einfach die Audiodatei per Email an stehtisch@engineeringkiosk.dev. Links
Sprungmarken(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 Hosts
Feedback
| |||
| 05 Dec 2024 | #156 Inbox Zero: der Pro-Tipp für deine Produktivität | 00:10:57 | |
Inbox Zero: Die E-Mail-Flut und das eigene Postfach endlich unter Kontrolle. Im Engineering Kiosk Adventskalender 2024 sprechen befreundete Podcaster⋅innen und wir selbst, Andy und Wolfi, jeden Tag kurz & knackig innerhalb von wenigen Minuten über ein interessantes Tech-Thema. Unsere aktuellen Werbepartner findest du auf https://engineeringkiosk.dev/partners Das schnelle Feedback zur Episode: Links
Sprungmarken(00:00:00) Inbox Zero Hosts
Feedback
| |||
| 07 Jun 2022 | #22 NoSQL: ACID, BASE, Ende einer Ära Teil 2 | 01:00:36 | |
Neben relationalen Datenbanken gibt es noch eine ganz andere Welt: NoSQL. Doch wofür steht eigentlich NoSQL? Kein SQL? Not Only SQL? Was ist eigentlich die Geschichte hinter dem Hype? Warum wurde diese Art von Datenbanken erfunden? Wofür sind diese gut? Folgen NoSQL Datenbank auch dem ACID-Concept? Was ist Eventual Consistency? Und was sind Neo4J, M3, Cassandra, und Memcached für Datenbanken? Eine Episode voller Buzzwords … Hoffen wir auf ein Bingo. Bonus: Warum Wolfgang keinen Manta fährt und ob Andy bald mit einem Ferrari zum einkaufen fährt. Feedback an stehtisch@engineeringkiosk.dev oder via Twitter an https://twitter.com/EngKiosk Unsere aktuellen Werbepartner findest du auf https://engineeringkiosk.dev/partners
Links
Sprungmarken(00:00:00) Intro (00:00:53) Wolfgangs Auto, Entlastungspaket in Deutschland (00:03:23) Heutiges Thema: NoSQL Datenbanken und CO2-Einsparung durch Datenbank-Optimierungen (00:07:20) Was ist anders zur Episode 19 (Datenbanken) und ist NoSQL überhaupt noch ein Thema? (00:08:39) Was verstehen wir unter dem Begriff NoSQL und woher kommt es eigentlich? (00:15:58) Tip: Für Side Projects besser vertikal anstatt horizontal skalieren (00:16:50) NoSQL: Speziellere Lösungen mit Fokus auf Einfachheit und Benutzerfreundlichkeit (00:18:38) Braucht man heute noch Datenbank-Administratoren (DBA)? (00:21:13) Der Job des klassischen System-Administrator ist weiterhin relevant (00:23:15) Gibt es wirklich keine Datenbank-Schemas in der NoSQL-Welt? (00:27:23) Schema-Lose Möglichkeit in relationalen Datenbanken und Arbeit in die Datenbank oder Software auslagern (00:30:53) NoSQL hat die ACID-Properties aufgeweicht und warum ACID nachteilig für die Skalierung ist (00:33:28) Das NoSQL BASE Akronym (00:36:15) Der Client muss die Datenbank ordentlich nuzten um ACID-Garantien zu bekommen (00:41:35) Was bedeutet eigentlich NoSQL? Kein SQL? Not Only SQL? (00:43:38) Haupt-Speicher Datenbanken und was SAP damit zu tun hat (00:48:02) Was ist Neo4J für eine Datenbank und welcher Use-Case kann damit abgedeckt werden? (00:50:49) Was ist M3 für eine Datenbank und welcher Use-Case kann damit abgedeckt werden? (00:53:06) Was ist Cassandra für eine Datenbank und welcher Use-Case kann damit abgedeckt werden? (00:54:20) Was ist Memcached für eine Datenbank und welcher Use-Case kann damit abgedeckt werden? (00:58:44) Outro Hosts
Engineering Kiosk Podcast: Anfragen an stehtisch@engineeringkiosk.dev oder via Twitter an https://twitter.com/EngKiosk | |||
| 23 May 2023 | #72 Meetings: Jeder hat sie, keiner will sie | 01:04:26 | |
Meetings: Ein essentieller Teil unseres Arbeitsalltages und doch wird nur gemeckert? Meetings sind ein Teil unserer Arbeitskultur, um die keiner herumkommt. Doch irgendwie meckert jeder darüber. "Dieses Meeting hätte auch eine E-Mail sein können", "Ich habe zu viele Meetings und komme nicht zum Arbeiten", "Das Meeting war nicht interessant oder relevant für mich". Das Faszinierende daran: Jeder kennt die Grundregeln, um ein Meeting effizient zu gestalten: Eine Agenda, ein klares Ziel, nur die relevanten Leute einladen, Meeting Notes, etc. Doch scheint es unmöglich, gute bzw. gut geführte und relevante Meetings im Arbeitsalltag zu etablieren? Wir sprechen über Meetings absagen, in Meetings wirklich präsent zu sein, "No-Tech-Meetings", die "Law of two feet", wieviel Probleme eigentlich durch Meetings an der Kaffeemaschine entstehen und warum es auf die Disziplin jedes einzelnen bei Meetings ankommt. Bonus: Hund im Büro und die Abkürzung von "Team" - Toll ein anderer Machts 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 Unsere aktuellen Werbepartner findest du auf https://engineeringkiosk.dev/partners
Links
Sprungmarken(00:00:00) Intro (00:01:14) Engineering Kiosk Community (00:06:14) Warum das Thema Meetings allgegenwärtig ist (00:07:32) Was ist das große Problem mit Meetings und warum ist es ein Hassthema? (00:09:40) Haben wir durch Remote-Arbeit weniger Meetings als im Büro? (00:13:48) Was ist ein wertvolles Meeting? (00:17:30) Meetings absagen, Meeting-freie Tage und Kontext-Switche (00:21:28) In Meetings präsent sein und den Personen vertrauen (00:29:33) Feedback nach Meetings geben, mit getroffenen Entscheidungen leben und Law of two feet (00:38:29) No-Tech-Meetings und was am Laptop machen (00:42:23) Gute Meetings sind hart und hängt nicht nur vom Meeting-Organisator ab (00:45:50) Zu viele Meetings, Alignment in und durch Meetings und Stand Ups (00:57:31) Hybrides Setup: Nur Meetings, wenn wir im Büro sind? Hosts
Feedback (gerne auch als Voice Message)
| |||
| 11 Oct 2022 | #40 Wie wird man und Frau zum Senior Dev? | 00:49:43 | |
Was ist eigentlich ein Senior Engineer und wie werde ich zu einem? In der Tech-Industrie werden Titel wie Junior-, Senior-, Staff- und Co genutzt, um Levels und Erfahrung auszudrücken. Doch was ist eigentlich ein Senior-Engineer? Was unterscheidet ein Senior von einem Junior? Wie kann sowas in der Praxis aussehen? Ist Zeit ein wirklicher Faktor für eine Beförderung (10 Jahre Berufserfahrung oder 10x 1 Jahr Berufserfahrung)? Ist "Senior" zu sein ein "Einmal-Aufwand" oder ist kontinuierliche Energie gefordert? In dieser Episode beschreiben Andy und Wolfgang einige Attribute, die den Unterschied eines Juniors und Seniors darstellen und beschreiben, wie man den Weg zum Senior einschlagen kann. Bonus: Warum ein Meterstab auch Zollstock genannt wird und warum Wolfgang ein T als hart bezeichnet. 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 Unsere aktuellen Werbepartner findest du auf https://engineeringkiosk.dev/partners
Links
Sprungmarken(00:00:00) Intro (00:00:58) Berufserfahrung, Breites vs. tiefes Wissen und Karriere (00:06:23) Wie wichtig ist Karriere und Titel? (00:08:03) Umgang mit Positions-Titeln in Firmen (00:09:28) Heutiges Thema: Wie kann ich ein Senior Engineer werden? (00:13:02) Erste Schritte zum Senior: Übernahme von kleinen Projekten - Die Arbeit pro-aktiv vorantreiben (00:18:18) Impact: Was wird im Produkt wirklich gebraucht? (00:19:34) Technische Skills: Entwicklung von Code und Testing (00:22:34) Technische Skills: Debugging (00:24:43) Technische Skills: Monitoring, Alerting und Skalierung (00:26:13) Technische Skills: Security (00:28:48) Kommunikations Skills: Feedback, positiv gestimmt, Mentoring und Knowledge Sharing (00:35:15) Senior Engineer zu sein ist nicht einfach (00:35:47) Technologie vs. Business-Verständnis: Wann ist eine Lösung gut genug? (00:39:38) In die Senior-Rolle reinwachsen: Erfahrung und Zeit (00:42:54) Unterschiedliches Verständnis von der Senior-Rolle (00:45:07) Der eine Tipp auf dem Weg zum Senior Engineer (00:47:32) Inflationäre Nutzung des Begriffs "Senior" (00:48:37) Outro Hosts
Feedback (gerne auch als Voice Message)
| |||
| 15 Oct 2024 | #145 Große Open Source Projekte managen: 20 Jahre im TYPO3 Projekt mit Benni Mack | 01:10:55 | |
Ist “Open Source” eigentlich der Quellcode? Oder geht es primär um Menschen und der Code ist nur das Ergebnis? Die Open Source Bewegung ist aus der Softwareentwicklung nicht mehr wegzudenken. Ein Teil davon zu sein fühlt sich gut an. Wir geben etwas zurück. Einige von uns träumen auch davon, dass das eigene Open Source Projekt mal so richtig groß wird. Doch wie verändert sich eigentlich die Art und Weise, wie wir ein Open Source Projekt managen, wenn dies eine große Nutzerbasis, viele Contributoren und noch mehr Reichweite bekommt? Steht dann noch das eigentliche Ergebnis, der Quellcode, im Vordergrund? Oder spielen Themen wie Community Management, der Einfluss auf Menschen, Finanzierung oder Governance-Strukturen eine größere Rolle? In dieser Episode sprechen wir mit Benni Mack. Benni ist Project Lead bei TYPO3, einem Open Source Content Management System. Er gibt uns Einblicke, welche Aktivitäten eigentlich notwendig sind um ein solch großes Open Source Projekt am leben und laufen zu halten, welchen Einfluss es auf Menschen haben kann, wie junge contributoren motiviert werden können, welche Governance und Finanzierungsstrukturen existieren und wir sprechen über die negativen Seiten und Herausforderungen bei großen Open Source Projekten. Bonus: Was Snowboard fahren und Surfen mit Softwareentwicklung zu tun hat. Unsere Partner aus der Werbung: https://engineeringkiosk.dev/partners
Das schnelle Feedback zur Episode: Feedback
Gerne behandeln wir auch euer Audio Feedback in einer der nächsten Episoden, einfach die Audiodatei per Email an stehtisch@engineeringkiosk.dev. Links
Sprungmarken(00:00:00) Management von großen Open Source Projekten mit Benni Mack (00:04:36) Werbung/Info (00:05:36) Was ist TYPO3 und was zeichnet es aus? (00:09:55) Welche Relevanz hat Content Management eigentlich noch? (00:12:15) Governance-Modell und Team-Strukturen beim Open Source Projekt TYPO3? (00:21:52) Roadmaps, Visionen und Features bei großen Open Source Projekten (00:38:06) Motivation von neuen Contributoren und Open Source Stars (00:45:55) Community-Aufbau bei großen Open Source Projekten (00:49:28) Agenturen und Open Source Sponsoring (00:57:03) Gerrit und GitHub als Source Code Management Plattform (01:04:41) Ablehnung von Patches (01:08:14) Contributions zu anderen Open Source Systemen Hosts
Feedback
| |||
| 18 Jun 2024 | #128 Devs müssen wissenschaftliche Papers lesen!? | 01:01:02 | |
Wie werden eigentlich wissenschaftliche Paper richtig gelesen? Du besuchst HackerNews und es trendet ein Artikel über einen neuen Algorithmus, der 100 mal besser ist als ein anderer. 1500 Kommentare hat der Post bereits. Für dich ist eins klar: Das MUSST du lesen. Du klickst drauf und erkennst “Uh … es ist ein wissenschaftliches Paper”. Du fragst dich: Quälst du dich da nun durch? Oder suchst du lieber auf YouTube nach einer Zusammenfassung? So gehts wahrscheinlich vielen Nicht-Akademikern - Denn, diese Dokumente können langweilig und trocken sein, voll von irgendwelchen Formeln, die sowieso nur 3% der Menschheit verstehen. Doch was ist, wenn man wissenschaftliche Paper nicht von vorne bis hinten liest, wie normale Bücher? Wie liest man diese Dokumente richtig, dass man nicht konstant weg pennt? Darum gehts in dieser Episode - Wolfgang erklärt die Tricks und Kniffe, wie man das meiste in kurzer Zeit aus den neusten wissenschaftlichen Erkenntnissen rausholt. Bonus: Bit-Shifting ist immer noch ein Hass-Thema. Das schnelle Feedback zur Episode: Feedback
Gerne behandeln wir auch euer Audio Feedback in einer der nächsten Episoden, einfach die Audiodatei per Email an stehtisch@engineeringkiosk.dev. Links
Sprungmarken(00:00:00) Wissenschaftliche Paper richtig lesen (00:03:31) Wissenschaftliche vs. Industrielle Paper (00:08:56) Info/Werbung (00:09:42) Wissenschaftliche vs. Industrielle Paper (00:19:04) Vorgehensweise beim lesen (00:37:54) Forschungsergebnisse reproduzierbar gestalten (00:39:33) Wie finde ich das richtige Paper? (00:50:40) Papers we love und Paper zusammenfassen Hosts
Feedback
| |||
| 25 Jan 2022 | #04 Lohnt der Einstieg in Open Source? | 00:50:44 | |
Für Andy ist Open Source und die Open Source Community ist bereits ein langer und essentieller Begleiter. In dieser Episode interviewed Wolfgang Andy genau zu dieseme Thema: Wie war sein Einsteig? Wieso es wichtig ist, sich Zeit zu nehmen um ein Bug-Ticket zu schreiben und was Snowboarden mit Open Source zu tun hat. Bonus: Wie man Andy dazu bringt, nackig durch die Wohnung zu flitzen. Unsere aktuellen Werbepartner findest du auf https://engineeringkiosk.dev/partners
Feedback an stehtisch@engineeringkiosk.dev oder via Twitter an https://twitter.com/EngKiosk Andy (https://twitter.com/andygrunwald) und Wolfgang (https://twitter.com/schafele) sprechen im Detail über: Sprungmarken(2:04) Wann hast du mit Open Source begonnen und warum? (03:27) Wie würdest du denn Open Source definieren? (05:08) Warum bist du in der Open Source Szene geblieben? (06:45) Hattest du mal schlechte Erlebnisse bei oder mit Open Source? als Maintainer? (07:33) ... und als Contributor? (08:15) Welche Tips kannst du Contributoren geben, um die Erfolgschancen für Pull Requests zu erhöhen? (10:04) Hast du Best Practices aus Maintainer-Seite, wie man mit Contributoren umgeht? (12:12) Wie geht man mit eigenen Open Source Projekten um, die man selbst nicht mehr nutzt? (15:31) Wie gehst du mit Feature Requests um? (17:56) Hat dir bereits jemand ein Feature gesponsored? (19:14) Open Source wird als Free work verstanden (20:45) Tipps für einen Feature Request bei einem Projekt (21:49) Kommunikation ist sehr wichtig (22:36) Wie siehst du den Stellenwert von Open Source im professionellem Umfeld? (24:35) Open Source als Mittel fürs Recruiting (25:40) Wie kann sich eine kleine Firma im Open Source Bereich engagieren? (28:09) Was hälst du von dem Open Source First Konzept? (29:29) Was ist Inner Source? (30:40) Passwörter und Secrets im Code (32:12) Möglichkeiten um ein Repository zu Open Sourcen (32:38) Negative Punkte für den Einsatz von Open Source (36:55) Welche Open Source Lizenz würdest du empfehlen, wenn jemand mit einem neuen Projekt starten möchte? (39:29) Projekte auf GitHub ohne Lizenz (40:35) Beer- und Pizza-Lizenz (41:02) Kleine Sponsoring-Beiträge und Danke-Nachrichten können viel bewirken (45:13) Andy flitzt nackig durch die Wohnung (48:15) Was deine Open Source Contribution mit deinem professionellen Werdegang zu tun hat Erwähnte Artikel
Erwähnte Personen
Erwähnte Projekte
Erwähnte Events
Erwähnte Lizenzen
Hosts
Engineering Kiosk Podcast Anfragen an stehtisch@engineeringkiosk.dev | |||
| 21 Mar 2023 | #63 Spaß mit Zahlen: Under- und Overflows, Rückwärtslaufende Zeit, Negative Modulos und Währungsbeträge | 01:01:07 | |
Herausforderungen mit Zahlen in der Programmierung: Hidden bugs, Effekte auf die Realität und der richtige Umgang. Der korrekte Umgang mit Zahlen in der Softwareentwicklung ist so wichtig wie die Reifen bei einem Auto, um es zu fahren. Obwohl viele Entwickler sagen, Mathematik ist ein täglicher Bestandteil des Tages, so kommt man um die Verarbeitung von Zahlen nicht drum herum. Doch wie schon früher in der Schule, kann der Umgang mit Zahlen sehr Herausfordernd sein. In dieser Episode sprechen wir über klassische Fehler, die beim Umgang mit Zahlen in Software gemacht werden, über skurriles Verhalten von Programmiersprachen aber auch über die Effekte dessen auf die reale Welt. Es geht um Datentypen in Programmiersprachen und deren Wertebereiche, Probleme mit großen Zahlen und JSON, Währungsumrechnung und die korrekte Speicherung, Integer-Under- und Overflow, negative Modulo-Berechnungen, rückwärtslaufende Uhrzeiten und wie verschiedene Programmiersprachen sich bei der selben Berechnung anders verhalten. Bonus: Ob Wolfgang Graf Zahl von der Sesamstraße kennt und warum JavaScript nicht gut in dieser Episode davonkommt. Unsere aktuellen Werbepartner findest du auf https://engineeringkiosk.dev/partners
Das schnelle Feedback zur Episode: 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
Sprungmarken(00:00:00) Intro (00:01:03) Wie viel hat Informatik und Mathematik mit Softwareentwicklung zu tun und Bitoperationen (00:06:24) Das heutige Thema: Probleme mit Zahlen (integer, float, double, decimals) (00:08:09) Implizite Typ-Konvertierung bei Skriptsprachen und verschiedene Basen von Zahlen (00:10:37) Division in MySQL mit Konvertierung nach JSON wird zum string (00:12:39) Einstieg in Datentypen: int, int32, int64, signed, unsigned, Wertebereiche, Go und JavaScript (00:20:58) Problem mit großen Zahlen: Twitter Tweet IDs, JavaScript BigInt und JSON (00:26:51) Probleme mit Währungen: Rundungsfehler und die korrekte Speicherung (00:35:31) Probleme mit Wertebereichen: Under- und Overflows, Signed und Unsigned Datentypen (00:40:43) Under- und Overflow in der Realität: Das Jahr 2038 und 2036 Problem (00:44:43) Probleme mit Zeit: Rückwärts Laufende Uhren, Leap-Seconds und Monotonic-Clock (00:52:46) Probleme mit Modulo: Negative Zahlen führen zu verschiedenen Ergebnissen (00:58:42) Weitere Probleme mit Zahlen: Portabilität, Zahlen-Basen, UUID und Bit-Operationen Hosts
Feedback (gerne auch als Voice Message)
| |||
| 04 Mar 2025 | #185 Der Mainframe ist tot, lang lebe der Mainframe! Von COBOL bis JavaScript am Mainframe mit Tobias Leicher von IBM | 01:23:52 | |
Der Mainframe ist tot, lang lebe der Mainframe! “Nobody ever got fired for buying IBM”. So oder so ähnlich hieß bzw. heißt ein Sprichwort in unserer IT-Industrie. Und wenn man sowas hört, hat man oft eins im Sinn: Mainframes. Die dicken Kisten, die in jeder Bank und in jeder Versicherung stehen. Das Ganze sagt sich so schnell. Doch wissen wir wirklich, wovon wir da eigentlich sprechen? In dieser Episode klären wir was eigentlich ein Mainframe ist, was diesen so besonders macht, wie groß und teuer eine solche Maschine ist, was eine z-Architektur ist, ob Mainframes für Greenfield-Projekte genutzt werden, welche Betriebssysteme darauf laufen können, ob wir bei der Software-Entwicklung an COBOL gebunden sind oder ob Go, JavaScript, Rust und Co auch auf einem Mainframe laufen können und inwieweit wir moderne Praktiken wie GitOps, Continuous Delivery, Pre-Production-Testing und Co anwenden können. Am Ende stellen wir uns die Frage, ob der Mainframe im Zeitalter von Cloud, Kubernetes, Commodity Hardware und verteilte Systeme noch eine Rolle spielt, wie wir als Software-Entwickler mal mit der z-Architektur und dem Mainframe spielen können und was für Herausforderungen die Firmen, die heutzutage noch einen Mainframe und alten Quellcode betreiben, so haben. Bonus: Heißt es Der, die oder das Mainframe? Unsere aktuellen Werbepartner findest du auf https://engineeringkiosk.dev/partners Das schnelle Feedback zur Episode: Feedback
Links
Sprungmarken(00:00:00) Mainframes mit Tobias Leicher (00:06:37) Info/Werbung (00:07:37) Der, die oder das Mainframe? (00:13:45) Was ist ein Mainframe? Hardware, Größe, Preis und Features (00:24:47) Transaktionale Workloads und Mainframe Nutzer (00:31:09) zOS und Linux auf dem Mainframe und Sprach-Runtimes (00:42:24) Legacy-Software in Cobol, PL/1 und Java (00:53:07) Pre-Production-Testing, Virtualisierung und verteilte Systeme (00:59:56) K8s, CNCF, GitOps, DevOps und Deployments (01:05:42) Die Zukunft von Mainframes und Doom (01:21:21) Mit dem Mainframe(rn) in Berührung kommen Hosts
Feedback
| |||
| 09 Jan 2024 | #105 Cloud-Ausfallsicherheit: Die Realität von Regionen und Availability Zones | 01:07:17 | |
Cloud Regions und Availability Zones: The good, the bad, the ugly Das Cloud Marketing verspricht viel - unter anderem Hochverfügbarkeit und Resilienz. Primär wird das durch die gleichzeitige Nutzung mehrerer Availability Zones und Regions ermöglicht. Doch ist wirklich alles Gold was glänzt? In dieser Episode schauen wir mal etwas tiefer rein. Wie sind Regions und AZs eigentlich bei den Cloud Providern definiert? Sind alle Regionen gleich oder gibt es gewisse Eigenheiten? Hat jede Region mehrere Availability Zones? Was bedeutet es eigentlich, wenn man eine App in mehreren Availability Zones betreiben möchte? Oder sogar in mehreren Regions? Und wie häufig gibt es eigentlich AZ und Region-Ausfälle? In dieser Episode bringen wir etwas Licht ins Dunkel. Bonus: Deprimierender Regen und die Cloud haben viel gemeinsam Das schnelle Feedback zur Episode: 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
Sprungmarken(00:00:00) Intro (00:04:52) Was sind Regionen (Regions) und Availability Zones (AZs)? (00:08:47) Info/Werbung (00:09:56) Was sind Regionen (Regions) und Availability Zones (AZs)? (00:20:15) Eigenheiten bei Regionen (Local Zones, Wavelength Zones und “Fault Domains”) (00:34:58) Cloud Provider mit Regions, die nur eine AZ haben (00:38:02) Was bedeutet es eigentlich, etwas “Multi AZ” zu betreiben? (00:45:41) Was bedeutet es eigentlich, etwas “Multi Region” zu betreiben? (00:51:14) Wie oft kommen Availability Zone- und Regional Outages vor? Hosts
Feedback (gerne auch als Voice Message)
| |||
| 28 May 2024 | #125 Die Kunst der technischen Dokumentation mit Jana Aydinbas | 01:02:43 | |
Dokumentation: Jeder braucht sie, keiner will sie schreiben Vielen Software-Entwickler⋅innen ist eins nicht bewusst: Technisches Schreiben ist eine Profession. Ein eigener Beruf. Denn es ist eine Kunst, Dokumentation so zu schreiben, dass sie auch gelesen und genutzt wird. Die Kunst, komplexe technische Informationen schnell zugänglich zu machen. Doch wie macht man das denn nun genau? Darüber sprechen wir mit Jana Aydinbas. Jana ist von Beruf Technical Writerin. Wir klären die Unterschiede zwischen Technical Writing und normalem schreiben, geben Einblick in das Berufsfeld, widerlegen klassische Mythen die Software-Entwickler⋅innen gegenüber dem Schreiben von Dokumentation haben, und lassen uns erklären, was eigentlich eine gute und professionelle Dokumentation ausmacht und wie man selbst den eigenen Doku-Skill verbessern kann. Bonus: Jira Tickets lesen ist gleichzusetzen mit investigativem Journalismus Unsere aktuellen Werbepartner findest du auf https://engineeringkiosk.dev/partners
Das schnelle Feedback zur Episode: Feedback
Gerne behandeln wir auch euer Audio Feedback in einer der nächsten Episoden, einfach die Audiodatei per Email an stehtisch@engineeringkiosk.dev. Links
Sprungmarken(00:00:00) Technical Writing mit Jana (00:04:26) Dokumentation schreiben, aber Hauptberuflich: Warum? (00:05:51) Technical Writing, normalem Schreiben und Redakteure und (00:09:17) Jira-Research und Dokumentation im Software Development Lifecycle (00:14:21) In eigener Sache (00:15:16) Jira-Research und Dokumentation im Software Development Lifecycle (00:20:35) Was macht eine Dokumentation zu einer guten Dokumentation? (Regeln, Zielgruppe, Terminologie) (00:27:02) Übersetzungen, Code, Screenshots in Dokumentationen und AI (00:35:23) Dokumentations-Mythen: Out of Date, niemand liest Dokumentation, Dokumentation schreiben ist nicht attraktiv, Code ist die Dokumentation (00:44:16) Dokumentation für Hardware (00:47:31) Dokumentation im Open Source Bereich (00:50:54) Read the docs und Write the docs (00:53:37) Dokumentations-Best-Practices zum selber anwenden Hosts
Feedback
| |||
| 07 Nov 2023 | #96 Selbstgemacht vs. Fertigprodukt: Ein Blick auf das Not-Invented-Here-Phänomen | 01:09:23 | |
Nur unsere eigene Lösung ist die beste: Das "Not invented here" Syndrome (NIH) Ihr kennt das bestimmt: Es gibt eine neue Herausforderung zu lösen. Das Team steigt sofort in die Planung ein, um die Anforderungen in Source-Code zu kippen. Ihr sitzt da und fragt euch: Das kann doch nicht sein, dass wir die einzigen sind, die dieses Problem haben. Da muss es doch schon was fertiges geben.”. Doch das Team wettert dagegen: “Unser Problem ist sehr speziell. Wir bezweifeln stark, dass es da etwas gibt, was unseren Anforderungen standhält. So oder so ähnlich spielt es sich jede Woche in etlichen Teams ab. Es wird die eigene Arbeit über externe Lösungen gestellt. Die Nachteile werden oft später sichtbar. Über dieses Thema sprechen wir in dieser Episode. Nicht nur, was die Gründe dafür sind, sondern auch, wie man dem etwas entgegensetzen kann. Bonus: Warum keiner vor dem "Not invented here" Syndrome geschützt ist - Wolfgang und sein Meetup-System. Unsere aktuellen Werbepartner findest du auf https://engineeringkiosk.dev/partners
Das schnelle Feedback zur Episode: 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
Sprungmarken(00:00:00) Intro (00:00:53) Das "Not invented here" Syndrom (NIH) und Open Source (00:09:31) Grund: Ich kann das besser (00:15:33) Grund: Fertige Lösungen sind zu komplex (00:26:13) Grund: Fertige Lösungen sind zu unflexible weil ein einzigartiges Problem haben (00:40:38) Grund: Fertige Lösungen sind zu teuer (00:48:44) Negative Effekte des "Not invented here" Syndroms (NIH) (00:55:10) Positiven Effekte des "Not invented here" Syndroms (NIH) (01:01:50) Wie kann man tun, um das "Not invented here" Syndrom (NIH) zu verhindern? Hosts
Feedback (gerne auch als Voice Message)
| |||
| 20 Jun 2023 | #76 Mit Open Source 100.000$ verdienen, Sponsorware und Plattform-Risiken bei GitHub mit Martin Donath | 01:18:14 | |
Kann man von einem Open-Source-Projekt seinen Lebensunterhalt verdienen? Martin Donath ist einer der wenigen Menschen im deutschsprachigen Raum, der über 100.000 USD mit Open Source Sponsorengeldern verdient. Mit seinem Projekt Material for MkDocs hat er das Sponsorware-Model erfolgreich implementiert und dies somit zu seinem Vollzeitjob gemacht. In dieser Episode stellt sich Martin unseren Fragen und wir sprechen über Open Source und wann die Maintenance eines Projektes wirkliche Arbeit wird, was Sponsorware ist, über den Churn von Sponsoren, Pricing-Strategien, Release-Zyklen, den Umgang mit internen Prozessen in Unternehmen, Platform-Risiken bei GitHub Sponsors und viele weitere Themen, die Open Source alles andere als eine schöne Grüne Wiese erscheinen lassen. Bonus: Was Material for MkDocs mit Stripe gemeinsam hat. Unsere aktuellen Werbepartner findest du auf https://engineeringkiosk.dev/partners
Das schnelle Feedback zur Episode: 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
Sprungmarken(00:00:00) Intro (00:01:16) Das Problem der Finanzierung von Open Source mit Martin Donath (00:02:36) Vorstellung Martin Donath und 100.000 USD mit Open Source verdienen (00:05:42) Das Projekt Material for MkDocs: Documentation that simply works (00:08:22) Die ursprüngliche Motivation ein neues Theme zu erstellen (00:12:07) Ab wann ist das Open Source-Projekt richtige Arbeit geworden? (00:14:58) Wie hast du die Motivation über die Zeit hochgehalten? (00:17:13) Wie war der Schritt zur Monetarisierung des Themes? (00:20:09) Wie funktioniert Sponsorware (00:22:33) Sponsoren-Churn (00:23:48) Entwicklung der Features, Release-Strategie und Kunden-Feedback (00:32:36) Konkurrenz-Produkte und Zielgruppen (00:34:07) Informationen über die GitHub Sponsoren, Kontakt und Paypal (00:36:02) Was ist GitHub Sponsors und Source Code Leaks (00:38:35) Pricing-Strategien, Unternehmen und Self-Service bei GitHub Sponsors (00:48:38) Sponsorbot, Software as a Service und Platform-Risiko (01:01:16) Warum hat GitHub Paypal abgeschaltet und Enterprise-Ausrichtung von GitHub (01:08:24) GitHub Sponsor-Geld als Gehalt, Steuern und Total Compensation (01:11:37) Sponsern von anderen Projekten und Contributor-Fund (01:13:16) Tips zur Anwendung von Sponsorware Hosts
Feedback (gerne auch als Voice Message)
| |||
| 02 May 2023 | #69 MySQL vs. MariaDB | 01:10:59 | |
Wie viel MySQL Drop In-Replacement steckt wirklich in MariaDB? MariaDB, ein Fork der populären Datenbank MySQL. Angetreten, um ein Drop-In-Replacement und eine direkte Alternative zu MySQL darzustellen. Doch wie viel ist da dran? Ist MariaDB MySQL kompatibel? Wo liegen die Gemeinsamkeiten und Unterschiede? Was war eigentlich der Grund für den Fork? In welchen Bereichen entwickeln sich beide Datenbanken vollkommen anders? Und was hat sich im Bereich der Storage-Engines alles so getan? In dieser Episode bringen wir etwas Licht in den direkten Vergleich zwischen MySQL und MariaDB. Bonus: Was ein Weber-Grill mit MySQL und MariaDB zu tun hat. Unsere aktuellen Werbepartner findest du auf https://engineeringkiosk.dev/partners
Das schnelle Feedback zur Episode: 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
Sprungmarken(00:00:00) Intro (00:00:58) Wetter, Zecken in der Software-Engineering und die MySQL OpenSource Community (00:06:11) Was ist InnoDB und das MySQL Changelog (00:08:37) MySQL vs. MariaDB - Ein Drop-In-Replacement? (00:10:43) Was ist eigentlich MySQL und was ist MariaDB? (00:14:15) Wo kommt MySQL und MariaDB eigentlich her? (00:22:26) MariaDB ist kein volles Drop-In-Replacement für MySQL (00:25:51) Der SQL Standard bei MySQL und MariaDB (00:29:47) Storage Engines und Object-Storage (00:39:09) Replikation zwischen MySQL und MariaDB und Traffic auf andere Datenbanken spiegeln (00:45:52) Ist MariaDB performanter als MySQL? (00:48:32) Aussprache von MySQL (00:50:37) Einfachheit und Konfigurationsmöglichkeit (00:52:44) Die Liste von Inkompatibilitäten wird länger und Traffic spiegeln (00:57:20) Version Scheme von MySQL und MariaDB (00:58:41) Welchen Grund gibt es für MySQL bei einem neuen Projekt? (01:03:42) Mögliche MariaDB Lizenz-Änderung und UUID-Datentyp (01:04:54) Feature-Support von Vitess (01:10:03) Logo von MariaDB Hosts
Feedback (gerne auch als Voice Message)
| |||
| 18 Mar 2025 | #187 Meeresschutz mit Code – Sea Shepherds Tech-Einsatz mit Florian Stadler | 01:07:30 | |
Code mit Impact und Meeresschutz digital: Der Einsatz von Software bei Sea Shepherd Deutschland In dieser Episode tauchen wir in die Welt des Meeresschutzes ein. Florian Stadler, seit 15 Jahren aktiv und Kampagnenleiter bei Sea Shepherd Deutschland, gibt uns Einblicke, wie Software beim Meeresschutz angewandt wird, um verlorene Fischernetze (sogenannte Geisternetze) aufzuspüren und zu bergen. Wir sprechen darüber, wie mithilfe Sonar-Scans und manueller Interpretation und (teils öffentlicher) Datenbanken der Meeresboden in der Ostsee systematisch untersucht wird, um illegale Fangmethoden und Umweltschäden aufzudecken. Dabei beleuchten wir auch Herausforderungen wie Schiffs-Ortungen, Bereiche von Cyber Security, wie z. B. AIS-Spoofing, den Datenaustausch mit anderen Organisationen, Infrastruktur auf einem Schiff von Sea Shepherd, wie Software-Entwickler*innen beim Meeresschutz helfen können und den oft überraschenden Einsatz von pragmatischen Lösungen wie händisch gepflegte Excel-Listen, selbst erstellten Google Maps-Layern oder Bildmaterial von öffentlich zugänglichen Webcams. Die Grenzen zwischen Hightech und altbewährter Technik mit pragmatischen Ansätzen verschwimmen hier ganz wunderbar. Bonus: Excel vs. Hightech – Wie kann man mit simplen Tools und digitaler Navigation ganze Meeresgebiete effizient kartieren? Unsere aktuellen Werbepartner findest du auf https://engineeringkiosk.dev/partners Das schnelle Feedback zur Episode: Feedback
Links
Sprungmarken(00:00:00) Intro (00:01:28) Meeresschutz bei Sea Shepherd Deutschland mit Florian Stadler (00:05:50) Der letzte Einsatz (00:06:29) Info/Werbung (00:07:29) Der letzte Einsatz (00:11:45) Die Ostsee als Einsatzgebiet (00:13:47) IT und Software beim Support von Einsätzen und das Schiff Triton (00:16:30) Geisternetze, Sonar-Scans, Datenbanken und Excel-Listen (00:27:34) Kartographierung der Ostsee (00:36:20) Austausch der Daten mit anderen Organisationen (00:37:56) Open Source Intelligence, Vessel-Tracking und Spoofing (00:53:21) Wie Software und Software-Entwickler*innen helfen können (01:02:50) Schiffs-Infrastruktur und Antennen Hosts
Feedback
| |||
| 28 Jan 2025 | #180 Skalierung, aber zu welchem Preis? (Papers We Love) | 00:58:55 | |
Skalierung und verteilte Berechnungen: Sind mehr CPUs wirklich immer schneller? Stell dir vor, du bist Softwareentwickler*in und jeder spricht von Skalierung und verteilten Systemen. Doch wie effizient sind diese eigentlich wirklich? Heißt mehr Rechenpower gleich schnellere Ergebnisse? In dieser Episode werfen wir einen Blick auf ein wissenschaftliches Paper, das behauptet, die wahre Leistung von verteilten Systemen kritisch zu hinterfragen. Wir diskutieren, ab wann es sich lohnt, mehr Ressourcen einzusetzen, und was es mit der mysteriösen Metrik COST (ausgesprochen Configuration that Outperforms a Single Thread) auf sich hat. Hör rein, wenn du wissen willst, ob Single-Threaded Algorithmen in vielen Fällen die bessere Wahl sind. Bonus: Ggf. machen nicht alle Wissenschaftler so wissenschaftliche Arbeit. Unsere aktuellen Werbepartner findest du auf https://engineeringkiosk.dev/partners Das schnelle Feedback zur Episode: Feedback
Links
Sprungmarken(00:00:00) Papers We Love: Scalability! But at what COST? (00:03:11) Was bedeutet Skalierung? (00:05:32) Info/Werbung (00:06:32) Was bedeutet Skalierung? (00:16:20) PageRank- und Label Propagation-Algorithmus (00:24:10) Optimierung der Daten und verwendeten Algorithmen für spezifische Probleme (00:29:17) COST: Configuration that Outperforms a Single Threat (00:31:58) Learnings aus dem Paper (00:37:50) Wissenschaftlicher Anspruch und Einschätzung des Papers (00:52:34) Was können wir für die Praxis aus dem Paper lernen? Hosts
Feedback
| |||
| 29 Mar 2022 | #12 Make oder Buy | 00:59:43 | |
Make oder Buy: Alles einkaufen oder doch lieber selber machen? Eine Frage die jeder von uns kennt: Sind meine Anforderungen so speziell, dass es kein Produkt auf dem Markt gibt, die diese abdeckt? Kann ich das nicht ggf. sogar besser, wenn ich das selbst mache? In dieser Episode versuchen wir das Thema mal etwas zu durchleuchten: Wann sollte man Services einkaufen? Wann doch lieber selbst umsetzen? Wie geht man mit interner Politik und Gegenwehr um? Was kostet das Selbermachen eigentlich und was bedeuten Begriffe wie Total Cost of Ownership, Opportunitätskosten und Shadow-IT eigentlich? Ist Open Source ein Zwischenweg und wie sieht die ganze Security-Mäßig aus? Bonus: Ob wir ein Karrierepodcast sind, was man in 1. Semester BWL lernt, welche Sicherheitsanforderungen eine Webagentur aus Wanne-Eickel hat und warum Wolfgang Google mehr vertraut als sich selber. Feedback an stehtisch@engineeringkiosk.dev oder via Twitter an https://twitter.com/EngKiosk Unsere aktuellen Werbepartner findest du auf https://engineeringkiosk.dev/partners
Links
Sprungmarken(00:00) Intro (01:33) Sollen wir die Software für unser A/B-Testing kaufen oder selber bauen? (05:23) Reisekosten-Abrechnungen: Wie kann es gehen? (06:53) Make or buy (08:27) Wolfgangs Stand bei Make or buy im privaten Leben (14:45) Wolfgangs Entscheidungskriterien für make or buy (15:42) Was ist die eigene Zeit wirklich Wert? (17:57) Klassische Beispiele für den “make or buy”-Fall in Firmen (23:42) Was kostet ein Software-Engineer, etwas selbst zu machen (Total Cost of Ownership) (28:55) Abgrenzung von make or buy (30:14) Opportunitätskosten: Produktivität und User Experience (33:40) Welche Bereiche gibt es, wo es Sinn macht, die Produkte nicht einzukaufen? (37:07) Risiken beim Einkaufen von Produkten: Shadow-IT und Workflows (41:16) Gegenwehr, fadenscheinige Gründe und interne Politik bei make or buy (48:02) Sicherheitsbedenken bei der Benutzung von externen Services (50:48) Eigene Erfahrung: Mehr make oder mehr buy? (56:07) Wann sollte man Software kaufen? (56:39) Wann sollte man die Software selbst bauen? (57:44) Outro Hosts
Engineering Kiosk Podcast: Anfragen an stehtisch@engineeringkiosk.dev oder via Twitter an https://twitter.com/EngKiosk | |||
| 12 Apr 2022 | #14 async und await: asynchrones Arbeiten im Alltag | 00:56:29 | |
Remote-Work, asynchrone und parallele Arbeit und die eigene Work-Life-Balance. Durch Corona haben wir alle einen Geschmack von der Remote-Arbeit und Home Office bekommen. Einige hassen es, andere lieben es und haben sogar dem Büro für immer den Rücken gekehrt. Aber worauf kommt es denn wirklich an? Wolfgang und Andy gehen dieser Frage mal auf den Grund: async und await, Event-Loop, Fokus-Zeiten, Eule und Lerche als Menschentypen, Vertrauen im Team, messbare Ergebnisse, Pro-Aktivität und Schreib-Skills. Was das alles miteinander zu tun hat, hört ihr in dieser Episode. Bonus: Warum man in Amsterdam anders meditiert als anderswo, wieso Andys Liebe zu Redis einen Knick bekommen hat und ob Wolfgang wirklich Holländer ist. Feedback an stehtisch@engineeringkiosk.dev oder via Twitter an https://twitter.com/EngKiosk Unsere aktuellen Werbepartner findest du auf https://engineeringkiosk.dev/partners
Links
Sprungmarken(00:00) Intro und Rückmeldung zur Episode #13 über Produktivität (01:22) Async + Asynchronität (async, await, event loop) (02:00) Vorteil von asynchroner Verarbeitung (04:13) Asynchronität vs. Parallelisierung (07:08) NodeJS, Callback-Hölle und async/await in Ruby (08:27) Warum verwenden wir nicht die asynchrone Herangehensweise um unsere eigene Zeit besser auszunutzen? - Asynchrones Arbeiten (11:23) Asynchrones Arbeiten, Schlafrhythmus (Eule vs. Lerche) und lange Fokus-Zeiten (14:48) Was verstehen wir unser asynchroner Arbeit? (18:34) Wie kommt man denn zu dem asynchronen Arbeiten (zB als kleine Firma)? (Vertrauen, Pro-Aktivität, Über-Kommunikation) (21:29) … was noch? (Kollaboratives Tooling, Energie für Vorschläge und Objektivität, Diagramme, Transparenz) (29:12) Die Funktion und Wahrnehmung von Slack in der asynchronen Arbeitswelt (34:05) Die Schriftform als Skill und warum dies trainiert werden sollte (35:22) Anwendungen von deinen Schreib-Skills im Ticket-System (38:50) Technical Writing, Dokumentation und Meeting Protokolle (39:26) Design Dokumente als Basis für die asynchrone Arbeit (53:32) Tiefere Gedanken während des schreibens (54:05) Wrap Up zum Thema asynchrones Arbeiten und Outro Hosts
Engineering Kiosk Podcast: Anfragen an stehtisch@engineeringkiosk.dev oder via Twitter an https://twitter.com/EngKiosk | |||
| 07 May 2024 | #122 Ich hasse Re-Orgs | 01:07:15 | |
Die Umstrukturierung der Firma: Hart für alle oder eine neue Chance? Firmen, ihre Produkte aber auch ihr Umfeld ändern sich ständig. Um wettbewerbsfähig zu bleiben, um weiter Profit zu erwirtschaften, müssen Unternehmen sich (intern) ändern. “Wer nicht mit der Zeit geht, geht mit der Zeit”. Interne Umstrukturierungen sind somit ein notwendiges Übel bei jeder Firma von einer gewissen Größe. Sie kommt, auch wenn man es nicht will, und ist notwendig, um die Organisation in die Richtung zu bewegen, damit die Unternehmensziele erreicht werden. Umstrukturierungen, sogenannte Reorgs, sind oft negativ behaftet. Doch warum ist das so? Darum geht es in diesem Podcast. Wir klären, was Reorgs eigentlich sind, wozu und mit welchem Zweck diese durchgeführt werden, wie eine Reorg oft bei den Individual Contributern gesehen wird, wie es zu einer Reorg kommt und wie diese durchgeführt wird, aber auch wie du selbst das Beste daraus machen kannst. Bonus: Warum Consultants im Haus nie was Gutes sind. *** Diese Episode wird gesponsert von ... Dir: https://engineeringkiosk.dev/kaffee *** Unsere aktuellen Werbepartner findest du auf https://engineeringkiosk.dev/partners
Das schnelle Feedback zur Episode: Feedback
Gerne behandeln wir auch euer Audio Feedback in einer der nächsten Episoden, einfach die Audiodatei per Email an stehtisch@engineeringkiosk.dev. Links
Sprungmarken(00:00:00) Unternehmens- und Teamumstrukturierungen (Reorgs) (00:03:49) Credibility: Warum sprechen wir über Reorgs? (00:05:57) Was ist denn eine Re-Org? (00:08:18) Buy us a coffee (00:09:40) Was ist denn eine Re-Org? (00:20:31) Produkte werden bei einer Re-Org beendet (00:27:48) Die Flughöhe vom Management und Detail-Probleme bei der Re-Org (00:30:25) Wie startet man eine Re-Org? (00:39:15) Team-Strukturen abseits von Spotify bei einer Re-Org (00:43:50) Ausführung und Kommunikation einer Re-Org (00:54:12) Es steckt viel Arbeit hinter einer Re-Org Hosts
Feedback
| |||
| 16 Aug 2022 | #32 Die richtigen Leute anstellen: Die Recruiting Pipeline | 01:04:28 | |
Recruiting: Einer der wichtigsten Aufgaben einer Firma - Doch worauf kommt es an? Leute kommen. Leute gehen. Fluktuation bzw. ein Jobwechsel ist ganz normal in der heutigen Zeit. Kaum jemand bleibt "bis zur Rente". Doch worauf kommt es an, wenn man neues Personal für sein Team / Firma sucht? Wie viel Zeit soll man als Hiring Manager investieren? Wo findet man gute Leute? Welche Fragen sind die richtigen? Wie geht man damit um, wenn man sich nicht 100%ig sicher ist? Und wie trifft man die finale Entscheidung? All das und noch viel mehr behandeln wir in dieser Episode. Bonus: Warum Wolfgang eine Aufmerksamkeitsspanne wie ein Welpe hat, was Aufzüge mit Recruiting zu tun haben und ob Wanne-Eickel wirklich existiert. 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 Unsere aktuellen Werbepartner findest du auf https://engineeringkiosk.dev/partners
Links
Sprungmarken(00:00:00) Intro (00:00:36) Perlenhochzeit beim Engineering Kiosk und das stoppen von Projekten (00:02:30) German Tech Podcasts (00:04:40) Das heutige Thema: Recruiting aus der Sicht des Arbeitgebers (00:06:35) Warum ist das Thema relevant? und was Recruiting mit Kultur zu tun hat (00:11:25) Sollte man "Leute einstellen" delegieren? (00:15:20) Wie viel Zeit sollte ein Hiring Manager ins Recruiting investieren? (00:18:05) Wie findet man die richtigen Leute? Wie wichtig sind persönliche Empfehlungen? (00:21:55) Die Entscheidung, ob du eine Person einstellst: False-Negatives vs. False-Positives (00:26:45) Der Recruiting-Prozess: Wen suche ich eigentlich? (00:29:15) Der Recruiting-Prozess: Was sind die richtigen Fragen, die ich stellen kann? (Strukturierte Interviews und Freestyle) (00:43:30) Der Bias über die Historie und vergangene Stationen von Kandidat-innen (00:50:15) Der Recruiting-Prozess: Die finale Entscheidung treffen (00:57:10) Die aktuelle Lage am Jobmarkt, die Kosten von Recruiting und Demotage (01:03:00) Outro Hosts
Feedback (gerne auch als Voice Message)
| |||
| 19 Dec 2024 | #170 - 404 Not Found! | 00:11:36 | |
Der Status Code “404”: Was ist das, wofür steht es und woher kommt es? Im Engineering Kiosk Adventskalender 2024 sprechen befreundete Podcaster⋅innen und wir selbst, Andy und Wolfi, jeden Tag kurz & knackig innerhalb von wenigen Minuten über ein interessantes Tech-Thema. Unsere aktuellen Werbepartner findest du auf https://engineeringkiosk.dev/partners Das schnelle Feedback zur Episode: Links
Sprungmarken(00:00:00) Der Status Code “404” Hosts
Feedback
| |||
| 05 Sep 2023 | #87 Die DORA-Metriken: Ist Software-Entwicklungs-Performance messbar? | 00:54:42 | |
DORA Metriken: Die Performance-Messung deines Software Development Teams bzw. die Ermittlung des Reifegrades von DevOps in deiner Organisation Softwareentwicklung ist ein kreativer Beruf. Jedes Projekt ist einzigartig und die geschriebenen Lines of Code sagen wenig über die dafür benötigte Zeit aus. Das Research-Programm DevOps Research and Assessment (DORA) versucht dennoch die Performance eines Software-Entwicklungs-Teams zu messen. Nicht via Lines of Code, sondern auf Basis von Aktivitäten, die Value liefern: Deployment Frequency, Lead Time for Changes, Mean Time to Recovery, Change Failure Rate und Reliability. Die Metriken selbst sind weit bekannt. Wie diese Metriken beeinflusst werden können, wer eigentlich dahinter steckt, und was die Organisation eigentlich für eine Kultur vorleben muss, damit es überhaupt zu einem positiven Ergebnis kommt, wissen viele nicht. Und genau darüber sprechen wir in dieser Episode. Bonus: AOL CDs und Metal-Musik aus Litauen Das schnelle Feedback zur Episode: 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
Sprungmarken(00:00:00) Intro (00:00:57) DORA-Metriken und die Liebe zu Daten (00:04:02) Info/Werbung (00:05:13) Wofür steht DORA und wer steckt dahinter? (00:08:02) Was ist DORA und was ist das Ziel? (00:10:47) DORA Metrik: Deployment Frequency (DF) (00:14:44) DORA Metrik: Lead Time for Changes (LT) (00:17:05) DORA Metrik: Mean Time to Recovery (MTTR) (00:19:51) DORA Metrik: Change Failure Rate (CFR) (00:20:22) DORA Metrik: Reliability (00:22:56) High-Performing-Teams und Vergleichbarkeit (00:27:54) DORA Capabilities und was die Metriken eigentlich beeinflußt (00:32:09) Generative Organisationskultur nach Westrum (DevOps-Kultur) (00:34:29) Vergleichbarkeit von Teams, Optimierung und Evaluierung der Metriken (00:46:32) Wie kann man die DORA-Metriken erfassen? Hosts
Feedback (gerne auch als Voice Message)
| |||
| 28 Nov 2023 | #99 Modernes SQL ist mehr als SELECT * FROM - mit Markus Winand | 01:19:49 | |
SQL is Dead, Long Live SQL! Fast jede Applikation hat irgendeine Form von persistenter Datenhaltung. Oft in Form einer Datenbank. Der Platzhirsch bei Datenbanken sind Systeme, die sich mit der Structured Query Language (kurz SQL) abfragen lassen. MySQL, PostgreSQL, Oracle, MSSQL Server, sqlite, Google BigQuery und so weiter. Die coolen Kids haben vielleicht irgendeine Form von NoSQL-Datenbank im Einsatz. Aber auch da kommt man nicht um SQL herum. Für die meisten Entwickler*innen ist SQL ein alter Hut. SELECT * FROM Tabelle WHERE foo = bar GROUP BY id. Das haben wohl die meisten gelernt und damit kommt man schon sehr weit. Doch war es das mit den Möglichkeiten von SQL? Klare Antwort: Nein. Die Sprache wird weiterentwickelt, bekommt moderne Features und hat weitaus mehr zu bieten als manch einer denkt. Und darüber sprechen wir in dieser Episode mit dem SQL-Experten Markus Winand. Wir sprechen über Modernes SQL, die verschiedenen SQL Standards, ORMs und die Trennung von “Daten-Logik” und “Application-Logik” sowie über eine “Can I Use”-Platform für SQL Features. Bonus: Warum die Übernahme von MySQL durch Oracle das Beste war, was MySQL passieren konnte. Unsere aktuellen Werbepartner findest du auf https://engineeringkiosk.dev/partners
Das schnelle Feedback zur Episode: 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
Sprungmarken(00:00:00) Intro (00:01:26) Unser Gast Markus Winand (00:07:04) Was ist SQL? (00:15:17) Wie beliebt ist SQL? (SQL is dead. Long Live SQL?) (00:17:09) Wie entsteht der SQL Standard und wer steckt dahinter? (00:19:57) Wird SQL zur eierlegenden Wollmilchsau? (00:21:45) Eine Tour durch die SQL Standards (00:40:33) Was ist modernes SQL? (00:46:22) Vendor-Lock-In bei SQL-Datenbanken und die Lehre von modernem SQL (00:52:04) Applikationslogik in der Datenbank, AI und Vektor-Datenbanken und ORMs (01:10:24) Coole SQL Feature, welche unterrepräsentiert sind: FILTER und Row Pattern Matching (01:15:06) Wo geht der SQL Trend hin? (01:17:26) Abschlusswort von Markus Winand Hosts
Feedback (gerne auch als Voice Message)
| |||
| 09 May 2023 | #70 Alan Turing: Der Vater der heutigen Informatik (Turing-Complete, Turing-Test, Halting-Problem, Turing-Maschine, Captcha) | 00:56:59 | |
Wenn man sich eigentlich mal fragt, auf wen die ganze heutige Entwicklung in der Informatik zurückführt, taucht immer wieder ein Name auf: Alan Turing. Sei es der Turing-Award (der Nobelpreis der Informatik), die Turing-Maschine oder der Turing-Test. Doch wer ist bzw. war Alan Turing eigentlich? Warum wurde nach ihm ein Award benannt? Was ist die Turing-Maschine und wofür ist sie gut? Was bedeutet es, wenn etwas Turing-Complete ist und wieso ist das Bestehen des Turing-Tests eigentlich so schwer? In dieser Episode machen wir mal einen kleinen (historischen) Ausflug in einen Teil der theoretischen Informatik und schmeißen mit Begriffen wie dem Hilbert Kalkül, das Halting-Problem, dem Lambda Kalkül und Co um uns. Bonus: Was die Band Abba mit Turing zu tun hat und warum Turing Serverless erfunden hat. Unsere aktuellen Werbepartner findest du auf https://engineeringkiosk.dev/partners
Das schnelle Feedback zur Episode: 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
Sprungmarken(00:00:00) Intro (00:00:53) Ist printf oder CSS Turing-Complete? (00:04:40) Alan Turing und der Turing-Award und der Gruppenzwanz (00:06:55) Was ist der Turing Award? (00:11:33) Wer ist Alan Turing? (00:14:12) Was ist die Turing-Maschine und was bedeutet Turing-Complete? (00:30:45) Das Halting-Problem (00:35:27) Was ist der Turing-Test? Wer hat diesen bestanden? Und die Geschichte von CAPTCHA (00:50:39) Welche Relevanz hat der Turing Test zur heutigen Zeit? Hosts
Feedback (gerne auch als Voice Message)
| |||
| 22 Feb 2022 | #07 Die Freelance Freiheit | 01:04:01 | |
Sein eigener Chef zu sein, sich die Projekte aussuchen können und sich die Zeit frei selbst einzuteilen. Obendrein noch einen Haufen Geld verdienen. Das ist die Vorstellung von vielen ITlern zur Selbstständigkeit. Doch wie sieht die Realität aus? Was sind die negativen Aspekte? Und wie viel Geld kommt wirklich unterm Strich bei rum? In dieser Episode teilt Wolfgang seine langjährige Freelance-Erfahrung: Welche Arten von Freelancing gibt es, wie er die Probleme beim Schätzen des zeitlichen Aufwandes umgeht, warum rostende Software ein Problem ist und zu schlecht gelaunten Kunden führt, ob es sich lohnt seine Finger zu versicherung und was goldene Handschellen mit all dem zu tun haben. Bonus: Wie Wolfgang einen Kunden beim Krafttraining im Fitnessstudio akquiriert hat, ohne selbst Gewichte zu stemmen. Feedback an stehtisch@engineeringkiosk.dev oder via Twitter an https://twitter.com/EngKiosk Unsere aktuellen Werbepartner findest du auf https://engineeringkiosk.dev/partners
Links
Anderes
Sprungmarken(00:00:00) Intro (00:00:45) Bier holen (00:01:43) Wolfgangs erstes Freelancing-Projekt (00:02:54) Weibliche Software-Engineering Freelancer (00:03:45) Wie Wolfgang zum Freelancing gekommen ist (00:05:17) Verschiedene Arten vom Freelancing (00:08:19) Freelancing als Lösung für Remote Work (00:10:16) Scheinselbstständigkeit (00:11:13) Entwicklung der Freelancing-Arbeit anhand deiner Erfahrung (00:14:14) Software Maintenance bei Freelancing-Projekten (00:17:40) Was sind die positiven Aspekte des Freelancings? (00:27:28) Was sind die negativen Seiten vom Freelancen? (00:28:25) Kundenakquise (00:29:44) Preisfindung (00:37:00) Wie geht man die Selbstständigkeit an? Wie setze ich es in der Praxis um? (00:40:42) Steuerberater (00:46:09) Welche Kosten kommen noch auf einen zu? (00:48:21) Haftung und was eine GmbH für dich tun kann (00:50:11) Geschäftskonten (00:51:18) Der Start ist schwer und Weiterempfehlungen (00:54:29) Fragen, um herauszufinden, ob die Selbstständigkeit etwas für mich ist (00:59:56) Neben der Festanstellung starten (01:02:12) Outro Hosts
Engineering Kiosk Podcast: Anfragen an stehtisch@engineeringkiosk.dev oder via Twitter an https://twitter.com/EngKiosk | |||
| 13 Dec 2022 | #49 Die Zukunft: Software Repository Mining | 00:54:55 | |
Die Analyse von Metadaten aus dem Software-Entwicklungsprozess: Yey or Ney? Die wenigsten kennen den Begriff des Software Repository Minings, doch die meisten benutzen Features, die darauf zurückzuführen sind. Zum Beispiel der automatische Vorschlag von den richtigen Pull Request Reviewern. Es geht darum, auf Basis der Daten aus dem Softwareentwicklungsprozess neue Erkenntnisse zu gewinnen, um diesen einfacher und produktiver zu gestalten. In dieser Episode klären wir, woher die Daten kommen, wie man an diese gelangt, welche Anwendungsfälle es gibt, was die Herausforderungen dabei sind und wie ihr damit starten könnt. Bonus: Ob Andy bereits 50 Jahre alt ist und warum gute Architektur auch als Selbstschutz dient. 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 Unsere aktuellen Werbepartner findest du auf https://engineeringkiosk.dev/partners
Links
Sprungmarken(00:00:00) Intro (00:00:48) Das heutige Thema: Software Repository Mining (00:02:15) Warum kann Andy was zum Thema Software Repository Mining sagen? (00:04:03) Worum geht es beim Software Repository Mining? (00:05:48) Wie kommt man an die Daten der Software Repositories? Data- und Web-Mining (00:07:29) Klassische Anwendungsfälle von Software Repository Mining: Software Metriken, Velocity (Scrum) und womit wurde die Website gebaut? (00:13:07) Anwendungsfall: Analyse von Commits (00:15:12) Wer schaut sich solche Metriken? Wer kümmert sich um das Software Repository Mining? (00:17:40) Anwendungsfall: Analyse von Kopplungen von einzelnen Dateien (00:19:08) Ab wann macht Software Repository Mining Sinn? Wie schwierig ist es, sowas einzuführen? (00:22:35) Anwendungsfall: Der geeignete Code-Reviewer (00:23:36) Research: Nachvollziehbarkeit und Qualität von Source-Code (00:27:06) Anwendungsfall: Automatische Versioning auf Basis von Semantic Versioning (00:32:13) Anwendungsfall: Hot Topic Analyse (00:33:24) Anwendungsfall: Kontextbasierte Informationen in der IDE (00:37:27) Anwendungsfall: Review-Cycles im Pull Request als Datenpunkt fürs Mentoring und Coaching (00:39:28) Ranglisten und Gamification aus Basis von Code Contributions (00:41:14) Herausforderungen von Software Repository Mining: Unsaubere Daten, Data Storage, Cross-Linking und die Interpretation von Ergebnissen (00:48:21) Wie startet man am besten mit Software Repository Mining? (00:50:20) Andys Bachelor-Arbeit als Podcast (00:51:18) Warum ist Software Repository Mining ein Nischen-Thema? (00:54:00) Outro: FOSDEM Konferenz Hosts
Feedback (gerne auch als Voice Message)
| |||
| 06 Jun 2023 | #74 REST: Das oft falsch verstandene Architektur-Paradigma | 01:02:55 | |
Das REST-API Architektur-Paradigma: Oft verwendet und oft nicht komplett umgesetzt. REST-APIs sind überall im Internet. Jede statische Webseite ist sogar REST-Konform. Doch die meisten REST-Implementationen sind gar nicht vollständig, bzw. nur halbherzig umgesetzt. Die ursprüngliche Idee von REST hatte viel mehr im Gepäck. In dieser Episode gehen wir das Thema der REST-API an. Was ist REST? Wo ist der Unterschied zu Restful? Warum wird dieses Architektur-Paradigma oft falsch verstanden? Worum geht es bei den 6 Prinzipien (Client-Server-Architektur-Modell, (HTTP)-Caching, Mehrschichtige Systeme, Zustandslosigkeit, Einheitliche Schnittstelle und Code on Demand) eigentlich? Wie versioniert man eine API? Und welche Nachteile hat REST? All das und noch viel mehr in dieser Episode. Bonus: Was Napster, eDonkey und Korn mit Brause mit REST APIs zu tun haben. Unsere aktuellen Werbepartner findest du auf https://engineeringkiosk.dev/partners
Das schnelle Feedback zur Episode: 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
Sprungmarken(00:00:00) Intro (00:01:16) REST-APIs, das oft falsch verstandene Architektur-Paradigma (00:05:05) Was ist REST? (00:12:13) Wann wurde REST erfunden? (00:14:14) Die 6 Prinzipien von REST (00:15:04) Client-Server-Architektur-Modell, (HTTP)-Caching, Mehrschichtige Systeme, Zustandslosigkeit (00:19:15) Einheitliche Schnittstelle: Adressierbarkeit der Ressource (00:23:42) Einheitliche Schnittstelle: HTTP Methoden (00:31:02) Einheitliche Schnittstelle: Hypermedia as the Engine of Application State (HATEOAS) (00:37:38) API Maturity Model (00:42:19) Code on Demand (00:46:41) API-Versionierung + Warning HTTP Header (00:55:36) Nachteile von REST-APIs: Mehrfache Requests und kompletter Payload (00:59:06) Rundumschlag zum Thema REST Hosts
Feedback (gerne auch als Voice Message)
| |||
| 12 Sep 2023 | #88 Die Personalabteilung: Freund oder Feind? mit Patrick Kuster | 01:16:40 | |
Die Personalabteilung: Dein strategischer Partner auf Augenhöhe oder dein Feind und Blocker? Für viele ist die Personalabteilung ein notwendiges Übel. Eine Abteilung, die “halt notwendig ist”. Dennoch kann die HR auch ein Team sein, welches dir eine Menge Arbeit abnimmt und neue Möglichkeiten eröffnet. In dieser Episode sprechen wir mit Patrick Kuster. Patrick hat seine ganze Karriere in verschiedenen Personalabteilungen verbracht und er gibt uns Einblicke in Recruiting-Prozesse, Job-Benefits, Arbeitszeitverkürzung, Sabbaticals, Bildungsurlaub und vieles mehr. Bonus: Warum Mallorca als 17. deutsches Bundesland nicht von unserem Bildungsurlaub profitiert. Das schnelle Feedback zur Episode: 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
Sprungmarken(00:00:00) Intro (00:00:49) Einblick in die Personalabteilung mit Patrick Kuster (00:06:25) Der Name "Human Resources" (HR), wenn wir doch mit Menschen arbeiten (00:08:32) Info/Werbung (00:10:44) Diversity in der Personalabteilung (00:12:00) Was hat sich in den letzten 10 Jahren in der HR geändert? (00:16:25) Hat der Fachkräftemangel den Wert und die Aufgaben der Personalabteilung verändert? (00:17:42) Was sind die essentiellen Elemente in einem Lebenslauf (CV)? (00:26:38) Artificial Intelligence (AI) im Recruiting Prozess (00:29:31) Team- und Company-Fit im Recruiting (00:34:27) Tipps für Interviews: Das Unternehmen kennen, Zeit nehmen und Fragen vorbereiten (00:38:48) Eine außergewöhnliche Location für ein Interview (00:39:29) Job-Benefit: Das Mysterium von unbegrenztem Urlaub (00:44:51) Arbeitszeitverkürzung: In Teilzeit arbeiten (00:51:48) Eine Auszeit nehmen: Sabbatical (00:57:21) Bildungsurlaub (01:06:26) HR als Strategischer und Sparrings-Partner um weniger zu arbeiten (01:07:48) Was wünscht sich die HR von uns als Tech-Worker? (01:12:01) Die Personalabteilung ist nicht euer Feind, sondern euer Ansprechpartner auf Augenhöhe Hosts
Feedback (gerne auch als Voice Message)
| |||
| 16 Dec 2024 | #167 Tabs vs. Spaces mit dem Index out of bounds Podcast | 00:10:19 | |
Tabs vs. Spaces mit dem Index out of bounds Podcast. Im Engineering Kiosk Adventskalender 2024 sprechen befreundete Podcaster⋅innen und wir selbst, Andy und Wolfi, jeden Tag kurz & knackig innerhalb von wenigen Minuten über ein interessantes Tech-Thema. Unsere aktuellen Werbepartner findest du auf https://engineeringkiosk.dev/partners Das schnelle Feedback zur Episode: Links
Sprungmarken(00:00:00) Tabs vs. Spaces Hosts
Feedback
| |||
| 24 Sep 2024 | #142 Ist Return to Office die Zukunft? Was die Wissenschaft sagt - mit Jean-Victor Alipour vom IFO | 01:16:37 | |
Home Office vs. Return to Office: Der Machtkampf der Arbeitsweisen. Home Office, Telearbeit, mobiles Arbeiten, Full Remote oder ab und zu auch Sofa-Zentrale, Küchen-Kontrollzentrum oder Pyjama-Büro. Obwohl diese Begriffe rechtlich und steuerlich teils eine andere Bedeutung haben, ist das Ergebnis das gleiche: Arbeiten von Zuhause bzw. nicht aus dem Büro deines Unternehmens. Zur Corona Pandemie sind wir alle, freiwillig oder gezwungen, in den Genuss des Home Offices bekommen. Einige Unternehmen haben das Home Office als festen Bestandteil beibehalten. Andere haben Regeln für ein Hybrid-Modell eingeführt und wiederum andere springen auf den 5 Tage Return to Office Zug auf. Das Thema ist hoch subjektiv, denn jeder hat eine Meinung, welches Arbeitsmodell das beste ist. Doch wie sehen denn eigentlich die Zahlen und Fakten zu diesem Thema aus? Jean-Victor Alipour, Dr. im Bereich Volkswirtschaft, hat mit den Forschungen zu diesem Thema bereits vor der Corona Pandemie begonnen. Mit ihm klären wir, wie das Ansehen von Home Office vor der Pandemie war, welche Verbreitung Home Office und Hybrides Arbeiten heute hat, Inwieweit die Produktivität steigt bzw. sinkt, ob es eine Return To Office-Bewegung gibt und ob bzw. wie sich die städtischen Ballungsgebiete im Hinblick auf Remote work ändern. Unsere aktuellen Werbepartner findest du auf https://engineeringkiosk.dev/partners
Das schnelle Feedback zur Episode: Feedback
Gerne behandeln wir auch euer Audio Feedback in einer der nächsten Episoden, einfach die Audiodatei per Email an stehtisch@engineeringkiosk.dev. Links
Sprungmarken(00:00:00) Home Office und Return to Office mit Dr. Jean-Victor Alipour (00:04:04) Werbung/Info (00:05:04) Home Office und Return to Office mit Dr. Jean-Victor Alipour (00:15:41) Was ist eigentlich mit Home Office gemeint? (00:19:38) Attraktivität und Vorurteile von Home Office vor Corona (00:28:59) Längeres Arbeiten gleich höhere Produktivität im Home Office? (00:41:33) Fully Remote vs. Hybrid-Arbeit (00:51:29) Was sind gute und schlechte Home Office Konzepte? (00:59:41) Gibt es einen Return to Office-Trend? Hosts
Feedback
| |||
| 14 Apr 2025 | #191 Graphdatenbanken: von GraphRAG bis Cypher mit Michael Hunger von Neo4j | 01:12:16 | |
Von Kanten und Knoten: Ein Einstieg in Graph-Datenbanken Welche Relationen die einzelnen Datensätze in deiner Datenbank haben, kann eine Rolle bei der Entscheidung spielen, welche Art von Datenbank du am besten einsetzen solltest. Wenn du unabhängige Datensätze hast, die keine Relation zueinander haben oder häufige One to Many-Relationen, sind relationale Datenbanken gut geeignet. Wenn du jedoch sehr viele Many to Many Relationen hast, spielt eine Datenbank-Art ihre Vorteile aus: Graph Datenbanken. Ein gutes Beispiel sind wohl soziale Netzwerke wie LinkedIn oder Facebook, wo Events, Personen, Firmen und Posts mit Kommentaren eine durchgehende Beziehung zueinander haben. Auch bekannt als Social Graph. Natürlich kann dies auch alles in einer relationalen Datenbank gespeichert werden, aber Fragen wie “Gib mir bitte alle Personen, über die ich im 3. Grad verbunden bin, die aus Deutschland kommen und bei Aldi gearbeitet haben” sind schwer zu beantworten. Für Graph-Datenbanken jedoch ein Klacks. Grund genug, diesem Thema eine Bühne zu geben. Darum geht es in dieser Episode. In dem Interview mit dem Experten Michael Hunger klären wir, was eine Graph-Datenbank ist, welche Anwendungsfälle sich dadurch besser abbilden lassen, als z. B. in relationalen Datenbanken, was der Ursprung von Graph Datenbanken ist, was der Unterschied eines Property-Graph-Model und dem Triple-Store-Model ist, wie man mithilfe von Sprachen wie Cypher, SPARQL und Datalog, Daten aus einem Graph extrahiert, für welche Use Cases dies ggf. nicht die richtige Datenstruktur ist und geben einen Einblick in die Themen Knowledge Graphen, LLMs und GraphRAG. Bonus: Was der Film Matrix mit Graph-Datenbanken zu tun hat. Unsere aktuellen Werbepartner findest du auf https://engineeringkiosk.dev/partners Das schnelle Feedback zur Episode: Anregungen, Gedanken, Themen und WünscheDein Feedback zählt! Erreiche uns über einen der folgenden Kanäle …
Unterstütze den Engineering KioskWenn du uns etwas Gutes tun möchtest … Kaffee schmeckt uns immer
Links
Sprungmarken(00:00:00) Graph Datenbanken mit Michael Hunger (00:05:17) Info/Werbung (00:06:17) Graph Datenbanken mit Michael Hunger (00:16:12) Warum Java für eine Datenbank? (00:20:51) Was sind klassische Anwendungsfälle von Graph Datenbanken? (00:24:13) Vokabeln im Bereich Graph Datenbanken (00:27:27) Graphen in relationalen Datenbanken (00:31:11) Cypher als Abfragesprache für Graph Datenbanken (00:42:20) SPARQL und Datalog als Abfragesprachen für Graph Datenbanken (00:52:38) Index-Strukturen bei Graph Datenbanken (00:55:08) Wofür sind Graph Datenbanken nicht geeignet? (01:00:14) LLMs, Knowledge Graphen und GraphRAG (01:07:32) Mein Einstieg in die Welt der Graph Datenbanken Hosts
CommunityDiskutiere mit uns und vielen anderen Tech-Spezialist⋅innen in unserer Engineering Kiosk Community unter https://engineeringkiosk.dev/join-discord | |||
| 22 Mar 2022 | #11 Die Suche nach dem IT Traumjob | 00:58:51 | |
Den richtigen Arbeitgeber und die richtige Firma finden: Eine Mammut-Aufgabe. In dieser Episode sprechen Wolfgang und Andy ein wenig darüber wie man neue, potentielle, Arbeitgeber findet, welche Fragen man sich selbst stellen kann um herauszufinden, was einem wichtig ist, geben Tipps um mit Recruitern zusammen zu arbeiten, Fragen uns ob ein hohes Gehalt wirklich alles ist, ob Startups, ScaleUps oder Konzerne besser sind und warum Agrar-Tech und Mähdrescher der heiße Scheiß sind. Als Start in dieses Thema gibt es ein Re-Cap von einer User-Umfrage auf Reddit zum Thema 1on1s und die Beantwortung der Frage, wie man gutes (People) Leadership in neuen Firmen erkennt. Bonus: Was Andys Kegeltour mit seiner Jobsuche zu tun hat und was ein Mottek ist. Feedback an stehtisch@engineeringkiosk.dev oder via Twitter an https://twitter.com/EngKiosk Unsere aktuellen Werbepartner findest du auf https://engineeringkiosk.dev/partners
Links
Sprungmarken(00:00) Intro (01:02) Reddit-Umfrage zum Thema 1 on 1 / Episode 10 (03:02) "Man braucht keine 1 on 1s, wir können immer drüber sprechen" (08:58) Wie wichtig sind 1 on 1s für dich bei deinem neuen Arbeitgeber? (12:16) Wie findest du heraus, ob der Lead Erfahrung hat? (15:05) Ist ein 1on1 ein Weiterentwicklungs-Benefit einer Firma oder Standard, den man annehmen sollte? (16:49) Welche Weiterentwicklungsmöglichkeiten sind wichtig für die Wahl einer neuen Firma? Was ist einfach zu etablieren? (18:41) Wie findet man eine neue Firma, bei der man sich bewerben könnte? (21:39) Interviews sind auch glückssache (24:13) Den Interviewprozess nutzen um zu erfahren, wie andere die Probleme lösen (25:50) Firmen finden durch Liebe zum Produkt (31:56) Firmen finden ohne Liebe zum Produkt (37:12) Ist ein Startup etwas für mich? (39:30) Sucht nicht selbst, sondern lasst euch finden (zB über LinkedIn) (41:25) Tipps um mit Recruitern zu arbeiten (45:22) Macht euch Gedanken, was Ihr vom neuen Arbeitgeber erwartet (47:51) Gehalt, Geld und wie viel wollt und braucht Ihr? (51:19) Andys Haupt-Kriterien für eine neue Firma (53:50) Wie viele Interviews waren notwendig, um die richtige Firma zu finden? (55:40) Interviews und Coding Challenges als Side Projetc (56:12) Outro Hosts
Engineering Kiosk Podcast: Anfragen an stehtisch@engineeringkiosk.dev oder via Twitter an https://twitter.com/EngKiosk | |||
| 26 Jul 2022 | #29 Die andere Seite: Meetups & Konferenzen organisieren | 01:08:48 | |
Meetups und Konferenzen: Ein wichtiger Bestandteil der Tech-Community und als Plattform für den Wissenstransfer. Jeder kennt Meetups und Konferenzen. Firmen sponsern Meetups und geben Mitarbeitern sogenannte Konferenz-Budgets. Doch wie sieht es hinter den Kulissen aus? Was bedeutet es ein Meetup zu organisieren? Welche Herausforderungen und Chancen bietet es? Wie viel Zeitaufwand benötigt es, ein Meetup auf die Beine zu stellen? Und ist es das gleiche wie die Organisation einer Konferenz? In dieser Episode wird Andy, als Organisator des Web Engineering Meetups Düsseldorf und der localhost-Konferenz, genau zu diesem Thema interviewed. Bonus: Was die Zeitschrift Computer Bild und Fortuna Düsseldorf mit Meetups zu tun haben. 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 Unsere aktuellen Werbepartner findest du auf https://engineeringkiosk.dev/partners
Links
Sprungmarken(00:00:00) Intro (00:00:36) Sommerpausen, Ferien und Release-Cycle (00:03:06) Empfehlungs-Algorithmen von Podcast-Plattformen (00:04:38) Der nachteil der Sommerzeit? Keine Meetups und Konferenzen (00:05:17) Wie groß ist das Web Engineering Meetup Düsseldorf und wie lange habt Ihr Pause gemacht? (00:06:16) Das heutige Thema: Die Organisation von Meetups und Konferenzen (00:07:06) Wann hat Andy mit Usergroups und Meetups gestartet? (00:09:51) Wie viele Leute kommen denn ca. zu den Treffen? (00:11:44) Wie schwierig ist es ein Meetup zum laufen zu bekommen? (00:13:28) Das Thema der No-Show-Rate bei Meetups (00:14:32) Was war der Planungsaufwand für die ersten Events? (00:16:02) Wie hast du die ersten Speaker gefunden? (00:18:28) Was ist es für ein monatlicher Zeitaufwand für die Meetup-Organisation? (00:20:01) Wie wird man das Firmenbranding von einem Meetup los? (00:26:53) Was hat sich bei den Firmen in Bezug auf Meetups in den letzten 10 Jahren geändert? (00:30:23) Welche Tipps haben wir für die Firmen, die sich bei Meetups präsentieren? (00:33:24) Recruitern auf Meetups und Regeln / Code of Conduct (00:35:56) Monetarisierung von Meetups und Motivation von Organisatoren (00:39:34) Der nächste Schritt: Eine eigene Konferenz (00:42:27) Wo ist der organisatorische Unterschied zwischen einem Meetup und einer Konferenz? (00:49:00) Neue Meetups: Lieber Online? Lieber Offline? Lieber Hybrid? (00:51:25) Online Meetups bieten einen größeren Zugang, deswegen mehr Konkurrenz? (00:54:37) Was würdest du als Start-Tip neuen Organisatoren zur Gründung mitgeben? (01:03:15) Online oder Offline-Meetups und eure Initiative (01:05:42) Die Checkliste zur Organisation eines Meetups (01:08:04) Outro Hosts
Feedback (gerne auch als Voice Message)
| |||
| 20 Aug 2024 | #137 Die Schaltsekunde und ihre IT-Folgen: Ein Sekundenbruchteil mit Impact | 00:52:42 | |
Eine (Schalt)-Sekunde kann für ganz schön viele Probleme sorgen Alle 4 Jahre haben wir ein Schaltjahr, ein zusätzlicher Tag wird eingefügt. Was aber vielen nicht bekannt ist: Immer mal wieder gibt es auch eine Schaltsekunde. Auf einmal hat der Tag nicht 86.400 Sekunden sondern 86.401 Sekunden. Und eine solch zusätzliche Sekunde kann, zumindest bei IT-Systemen, für eine ganze Menge Probleme sorgen. Und auch eine ganze Podcast-Episode füllen. Wir sprechen über die Schaltsekunde und warum diese seit 1970 nur 27 mal eingefügt wurde. Wir thematisieren die Probleme die eine zusätzliche Sekunde erzeugt, Welche Lösungsmöglichkeiten es gibt, diese Probleme vorzubeugen, zB wie Windows damit umgeht, wann man eine monotonic Clock verwenden sollte, oder Warum Google und Amazon einzelne Sekunden in ihrem Zeit-Server verlangsamen und somit die Schaltsekunde “schmieren”. Und wir sprechen über die Zukunft der Schaltsekunde, also ob wir diese noch brauchen oder nicht. Es dreht sich also alles um Zeit bzw. um eine Sekunde. Bonus: Du hast nur 27 Versuche, den Bug zu finden Das schnelle Feedback zur Episode: Feedback
Gerne behandeln wir auch euer Audio Feedback in einer der nächsten Episoden, einfach die Audiodatei per Email an stehtisch@engineeringkiosk.dev. Links
Sprungmarken(00:00:00) Intro (00:01:16) Was ist eine Schaltsekunde und wieso hat ein Tag 86400 Sekunden? (00:03:54) Info/Werbung (00:05:55) Was ist eine Schaltsekunde und wieso hat ein Tag 86400 Sekunden? (00:18:29) Welchen Einfluss hat eine zusätzliche Sekunde auf die IT? (00:30:44) Probleme in der klassischen Software-Entwicklung (00:33:26) Lösungen: Reboot, ignorieren und Smear-Second (00:44:05) Die Zukunft der Schaltsekunde Hosts
Feedback
| |||
| 05 Apr 2022 | #13 Produktivität | 00:58:49 | |
Zeit- und Produktivitätsmanagement: Buzzword-Bingo oder bringt das wirklich was? So blöd wie das Thema auch klingen mag, es hat Vorteile. Nicht nur im beruflichen Umfeld, sondern auch im privaten. Wolfgang und Andy sprechen über Ihre Art und Weise, Aufgaben zu organisieren, welche Methoden Sie verwenden, welche was bringen und welche Blödsinn sind, wo die Probleme liegen, ob man Talent dafür bracht, wie man sich selbst mit spannenden Aufgaben austricksen kann und wie man damit seinen Vorgesetzten Erziehen kann. Bonus: Warum Wolfgang endlich seine Zahnbürste wechselt, was Volkswagen mit Getting Things Done zu tun hat und wieso Andy ab und zu knatsch mit seiner Frau hat. Feedback an stehtisch@engineeringkiosk.dev oder via Twitter an https://twitter.com/EngKiosk Unsere aktuellen Werbepartner findest du auf https://engineeringkiosk.dev/partners
Links
Bücher
Sprungmarken(00:00) Warum Zeit- und Produktivitätsmanagement relevant ist (04:44) Zeit-Management als Thema in 1on1s (06:08) Getting Things Done (GTD) von David Allen (12:31) Kritik zu Getting Things Done (GTD) (17:02) Muss man jede Regel von Gettings Things Done (GTD) befolgen um es erfolgreich einzusetzen? (18:38) Nutzung von Getting Things Done (GTD) im privaten und im beruflichen (21:03) Erinnerungen als Engineering Manager um soziale Kontakte zu pflegen (23:03) Wie man seine Ehefrau mit Getting Things Done auf die Palme bringen kann (25:00) Inbox Zero (30:35) Kalender (35:24) Eisenhower-Matrix (38:46) Herausforderung: Aufgaben aktiv nicht zu tun (42:21) Sich selbst mit spannenden Tasks selbst austricksen aka "Shape and Sell" (45:21) Das schwierige, mit einer neuen Methode zu starten (47:33) Welche Tools gibt es? Oder ist Stift und Zettel das Mittel der Wahl? (52:59) Inspiration durch Blog-Artikel und Bücher (55:37) Outro Hosts
Engineering Kiosk Podcast: Anfragen an stehtisch@engineeringkiosk.dev oder via Twitter an https://twitter.com/EngKiosk | |||
| 11 Jul 2023 | #79 Font-Engineering und Schriftarten fürs Programmieren mit Philipp Acsany | 01:09:55 | |
Font Engineering und die Welt der Programmier-Schriftarten. Wie wichtig ist die Wahl der Schriftart für die Programmierung? Welche Möglichkeiten und Vorteile bietet die richtige Schriftart in deinem Editor? Macht es Sinn für verschiedene Programmiersprachen andere Schriftarten zu wählen? Worauf kommt es eigentlich an, wenn wir uns über Schriftarten für die Programmierung unterhalten? Wie entstehen eigentlich Schriftarten, was ist Font-Engineering und was bedeuten die Begriffe Ligaturen, Hinting und Kerning? Über all diese Fragen sprechen wir mit dem Wahl-Berliner Philipp Acsany. Als Font-Engineer und Python Programmierer hat er an vielen Schriftarten von großen Firmen mitgearbeitet. In dieser Episode gibt er uns einen Einblick in die Welt der Schriftarten mit einem speziellen Fokus auf das Programmieren. Bonus: Warum es völlig OK ist, in Comic Sans zu programmieren. Unsere aktuellen Werbepartner findest du auf https://engineeringkiosk.dev/partners
Das schnelle Feedback zur Episode: 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
Sprungmarken(00:00:00) Intro (00:01:12) Font Engineering mit Philipp Acsany (00:06:47) Warum kann man eine Podcast-Episode über Schriftarten und Font Engineering machen? (00:08:20) Was bedeutet monospace vs. proportionale Schriftarten? (00:10:21) Welchen Hintergrund hat es, warum spezifische Schriftarten für gewisse Anlässe (Bücher vs. Screen-Display, Einladungen, ...) genutzt werden? (00:14:21) Warum sind Schriftarten fürs Programmieren oft monospace? (00:15:18) Gibt es Schriftarten für das Programmieren, die proportional und nicht monospace sind? (00:17:24) Moderne Entwicklungen bei Schriften: Ligaturen (00:26:23) Hinting und die Relevanz von Dateiformaten bei Schriftarten (00:33:11) Schriftdesign vs. Font-Engineering (00:34:14) Ist es möglich, von Schrift-Design und Font-Engineering zu leben? (00:36:37) Character Sets: Unterstützung von speziellen Zeichen von einer Schriftart (00:42:43) Sicherheits-Attack-Vektor durch spezielle Buchstaben und der .zip Top-Level-Domain (00:44:11) Schriftarten und Deutsche Industrie-Normen (DIN) (00:48:49) Macht es Sinn für verschiedene Programmiersprachen verschiedene Schriftarten zu verwenden? (00:52:26) Programming-Fonts unter Open Source Lizenz (00:53:48) JetBrains Mono, Schriftgröße und -Farbe (00:57:02) Schrift-Familien, die Berechnung von fehlenden Schriften und Betriebssysteme (01:01:09) Tipps zur Auswahl deiner Editor-Schriftart (01:05:29) Der Einstieg in das Font-Engineering (01:07:24) Welche Programmier-Font nutzt Philipp Acsany? Hosts
Feedback (gerne auch als Voice Message)
| |||
| 14 May 2024 | #123 The Bread Code: vom Entwickler zum Brot-Influencer mit Hendrik Kleinwächter | 01:05:40 | |
Brot backen und Software-Engineering: Wie passt das zusammen? Das Brot ist den Deutschen heilig. Manche bezeichnen Deutschland als die Brotnation. Der 21. April ist sogar der Tag des Deutschen Brotes. Was es nicht alles gibt. Das klingt alles kompliziert, aber die Grundzutaten sind recht simpel: Mehl, Wasser, Salz und ein wenig Zeit. Vielleicht ist das auch der Grund, warum es so viele Leute zuhause ausprobieren und ihr eigenes Brot backen wollen. Und es kommt mir so vor, als sind es überproportionale Leute aus dem Softwarebereich. Einer, der “das Brot backen demokratisieren” möchte, ist Hendrik Kleinwächter. Als gelernter Software Engineer overengineered er das ganze etwas und macht es dadurch für uns alle zugänglicher. Mit Brotbackrezepten war er lange auf der HackerNews Startseite, mittels A/B-Tests versucht er die beste Back-Methode zu finden: Einkorn- oder Emmer Vollkornmehl? Geölte Laibform oder Laibform mit Pergamentpapier? Sauerteig-Gärung mittels Fruchtfliegen? Er visualisiert den Backprozess mit Flowcharts und hat ein Buch über Sauerteigbrot geschrieben und es unter einer Open Source Lizenz auf GitHub zur Verfügung gestellt. Das ist so skurril, wie es klingt. Und dazu haben wir Fragen. Es geht ums Brot backen mit einem Software-Engineering Mindset. Bonus: Neu im Angebot, die Finkenwerder Scholle Unsere aktuellen Werbepartner findest du auf https://engineeringkiosk.dev/partners
Das schnelle Feedback zur Episode: Feedback
Gerne behandeln wir auch euer Audio Feedback in einer der nächsten Episoden, einfach die Audiodatei per Email an stehtisch@engineeringkiosk.dev. Links
Sprungmarken(00:00:00) Brot Backen mit Hendrik Kleinwächter (00:06:35) Mit Brot backen auf HackerNews und GitHub (00:09:24) Was ist am modernen Brot backen kaputt? (00:14:18) Mit Hilfe von YouTube das Brot backen demokratisieren (00:16:34) The Bread Code: Brot backen und Software Engineering (00:23:10) A-B-Testing beim Brot backen (00:32:54) Popularität von Brot backen auf YouTube (00:37:34) Open Source Buch zum Brot backen: Flow-Charts und UML-Diagramme (00:51:46) Troubleshooting-Guide beim Brot backen (01:00:37) Das minimalste Setup um ein Brot zu backen Hosts
Feedback
| |||
| 10 Oct 2023 | #92 Technologie trifft Deutsche Ausbildungskultur: Die moderne IT-Berufsausbildung mit Stefan Macke | 01:19:07 | |
Wie ist der Stand bei der klassischen Berufsausbildung in der Informatik und in der Softwareentwicklung? Deutschland ist bekannt für die hohe Qualität bei der Berufsausbildung. Auch im Bereich der Informatik kann man sich ausbilden lassen. Dabei sprechen wir vom Fachinformatiker (Anwendungsentwicklung, Systemintegration, Digitale Vernetzung oder Daten- und Prozessanalyse), vom IT-Systemelektroniker, von der Kauffrau für Digitalisierung-Management oder IT-Systemmanagement. Doch wie ist der Stand in der Berufsausbildung? Wie läuft das ganze ab? Wie offen und modern sind die Ausbildungsinhalte? Was müssen Unternehmen tun, um ausbilden zu können? Wie sehen die Statistiken von Ausbildungsstellen vs. wirklichen Azubis aus? Benötigen wir in 2023 überhaupt noch die klassische Ausbildung, wo wir uns mit YouTube und Coding-Bootcamps alles viel schneller beibringen können? Über all das und noch viel mehr sprechen wir mit unserem Gast Stefan Macke, der als Experte auf diesem Gebiet auch einen eigenen Podcast zu diesem Thema hat, den IT-Berufe-Podcast. Bonus: Hintergründe zu Natural, der 4GL Programmiersprache Das schnelle Feedback zur Episode: 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
Sprungmarken(00:00:00) Intro (00:01:19) Berufsausbildung in der Informatik mit Stefan (00:03:18) Programmierung mit Java und Natural und auf Mainframes (00:03:35) Info/Werbung (00:04:51) Programmierung mit Java und Natural und auf Mainframes (00:06:30) Einführung in die deutsche Berufsausbildung / Duale Ausbildung (00:10:46) Welche IT-Berufe gibt es, in denen eine Ausbildung möglich ist? (00:13:30) Verschiedene Berufe, die gleichen Inhalte und Verkürzung der Ausbildung (00:17:08) Aktuelle Statistiken zur Verteilung der verschiedenen Berufe (00:19:22) Faire Verteilung von offener Software? Oder ist alles proprietär und "Windows"-Spezifisch? (00:21:48) Wie modern sind aktuelle Berufsschulen? (00:23:41) Sind die Inhalte der Ausbildung deutschlandweit einheitlich? (00:25:48) Spagat zwischen den Programmiersprachen bei der Ausbildung (00:27:54) Aufteilung des Alters bei Azubis (00:29:18) Entsprechen die Inhalte der Ausbildung dem schnell entwickelndem Internet-Standard? (00:33:39) Werden die Berufe deutschlandweit definiert und die Anerkennung von Abschlüssen (00:36:53) Die Suche nach Azubis (u.a. mit alten Programmiersprachen) (00:39:43) Welche Anforderung muss eine Organisation erfüllen, um ausbilden zu können? (00:43:04) Wie groß ist das Problem, dass Azubis die Firma wechseln? (00:45:50) Benötigen wir mehr Ausbildungsbetriebe oder mehr Azubis? (00:46:14) Welche Rolle spielt das Unternehmen am Erfolg der Ausbildung? (00:51:49) Rückläufige Statistiken bei den Ausbildungen und Bildung aus dem Internet (00:56:00) Sollten Unternehmen mehr Azubis vs. Akademiker suchen? (00:59:25) Wozu brauche ich noch eine Berufsausbildung in 2023? (01:01:28) Welche Kritik gibt es an der Fachinformatiker-Ausbildung? (01:03:36) Was würdest du an der Berufsausbildung ändern? (01:08:19) Siegel für qualitativ hochwertige Ausbildungsbetriebe (01:10:53) Die Berufsausbildung basiert auf dem Ehrenamt (01:13:58) Tipps für Azubis oder Leute die eine Ausbildung machen möchten Hosts
Feedback (gerne auch als Voice Message)
| |||
| 01 Aug 2023 | #82 Hinter den Kulissen: Die Informatik-Doktorarbeit und ist der Dr. Titel in der heutigen IT-Welt noch relevant? | 01:09:49 | |
Bildung: Einblick in den Dr. Titel im Bereich Informatik. Bildung ist wichtig. Viele Personen, die im Bereich Informatik und Software-Entwicklung unterwegs sind, haben auch studiert. Bachelor, Master, teilweise sogar einen Dr. Titel. Doch wie wichtig ist der Dr. Titel eigentlich für die Ausübung des Berufes? Brauche ich einen Dr. Titel, um eine gute Programmiererin zu werden? Was bedeutet es eigentlich, einen Dr. Titel zu erlangen? Was muss dafür getan werden? Welche Voraussetzungen muss ich erfüllen? Was kostet mich das ganze und wie finanziere ich mein Leben während dieser Zeit? Und ganz allgemein: Warum brauchen viele Doktoranden so lange? All diese Fragen beantwortet der Podcast Co-Host Wolfgang, der selbst einen Dr. Titel der Informatik trägt. Bonus: Die Automatisierung einer Kaffee-Strichliste als Bachelor-Arbeit. Unsere aktuellen Werbepartner findest du auf https://engineeringkiosk.dev/partners
Das schnelle Feedback zur Episode: 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
Sprungmarken(00:00:00) Intro (00:01:01) Akademische Flachwitze und der Dr. Titel in der Informatik (00:04:05) Was wird für die Erlangung eines Dr. Titels benötigt? (00:11:14) Grund für die Episode: Soll ich noch einen Dr. Titel dran hängen? (00:13:10) Welche Kosten entstehen während einer Promotion? (00:16:41) Industrie Doktoren und Grundlagen vs. Angewandte Forschung (00:20:15) Eine Anstellung als wissenschaftlicher Mitarbeiter und Geld während des Studiums (00:27:59) Der Dr. Titel in der Gehaltsverhandlung und Einstiegsbarrieren in die Arbeitswelt (00:32:52) Gilt man in der Industrie mit einem Dr. Titel als überqualifiziert? (00:34:01) Ist ein Dr. Titel hilfreich für höhere Managementpositionen? (00:34:28) Warum dauert eine Promotion so lange und Themenfindung deiner Dissertation (00:39:17) Pflichten während der Dr. Anstellung: Lehre und Klausuren (00:40:59) Iterative Forschung in deiner Dissertation, etwas neues erschaffen und Publizierungen (00:48:24) Das Thema deiner Doktorarbeit ändert sich ständig (00:49:24) Ist ein Dr. Titel für Spezialisten oder auch für T-Shaped-Personen? (00:51:46) Wie relevant ist der Dr.-Titel in der heutigen Zeit noch? (00:58:59) Akademischer Spaß (01:03:48) Wie realistisch ist ein Dr. neben dem Beruf? (01:04:55) Würdest du den Dr. erneut anstreben? (01:05:23) Tipps für angehende Doktoranden Hosts
Feedback (gerne auch als Voice Message)
| |||
| 23 Dec 2024 | #174 Frontend-Engineering Metriken im Team einführen mit dem Working Draft Podcast | 00:06:12 | |
Frontend-Engineering Metriken im Team einführen mit dem Working Draft Podcast. Im Engineering Kiosk Adventskalender 2024 sprechen befreundete Podcaster⋅innen und wir selbst, Andy und Wolfi, jeden Tag kurz & knackig innerhalb von wenigen Minuten über ein interessantes Tech-Thema. Unsere aktuellen Werbepartner findest du auf https://engineeringkiosk.dev/partners Das schnelle Feedback zur Episode: Links
Sprungmarken(00:00:00) Frontend-Engineering Metriken im Team einführen Hosts
Feedback
| |||
| 04 Jun 2024 | #126 Killing the Mutant: Teststrategien mit Sebastian Bergmann | 01:19:39 | |
Testing ist nicht gleich Testing - Ein Deep Dive mit Sebastian Bergmann Viele Software-Entwickler⋅innen kennen Unit-Tests. Einige schreiben Unit Tests bei der Entwicklung. Wenige machen wirklich Test-Driven-Development. Doch beim Unit-Testing fängt das ganze Thema Testing doch erst an. Wie sieht es denn mit Static Testing, Non-Functional-Testing, White-Box-Testing, End-to-End-Testing, Dynamic Testing oder Integration Testing aus? Und hast du schon mal von Mutanten Testing gehört? Ganz schön viele Buzzwords. Und dabei haben wir noch gar nicht die Fragen beantwortet, was eigentlich gute Tests sind, wie viele Tests genug Tests sind, wie AI uns helfen kann bessere Tests zu schreiben oder ob Testing eigentlich moderner Kram ist oder schon seit Anbeginn des Programmier Zeitalters eine Rolle gespielt hat. In dieser Episode gibt es einen Rundumschlag zum Thema Testing mit Sebastian Bergmann. Bonus: Die Amiga-Szene lebt. Unsere aktuellen Werbepartner findest du auf https://engineeringkiosk.dev/partners
Das schnelle Feedback zur Episode: Feedback
Gerne behandeln wir auch euer Audio Feedback in einer der nächsten Episoden, einfach die Audiodatei per Email an stehtisch@engineeringkiosk.dev. Links
Sprungmarken(00:00:00) Testing mit Sebastian Bergmann, PHP und MySQL auf dem Amiga (00:10:11) 25 Jahre an einem Projekt und haben wir Testing verlernt? (00:10:20) Danke an alle Supporter! (00:11:16) Haben wir Testing verlernt? (00:23:04) Functional Testing vs. Non Functional Testing (00:24:48) Black Box vs. Whitebox-Testing (00:26:56) Integrations-Testing und End to End-Testing (00:32:47) Ist Automated Testing der Industrie-Standard? (00:38:01) Warum werden keine Tests geschrieben? (00:46:28) Metriken um einen Test zu bewerten (00:54:24) Mutanten-Testing / Mutation testing (00:59:30) AI im Bereich Testing (01:07:50) Ist Test Driven Development noch relevant? (01:09:27) Welche Testabdeckung sollte ich anstreben? (01:16:10) Fangt mit testen an Hosts
Feedback
| |||
| 17 Oct 2023 | #93 Barbara Liskov - Das L in SOLID (Liskovsches Substitutionsprinzip & Abstraktion) | 00:52:41 | |
Liskov Substitution Principle: Das L in SOLID von Barbara Liskov Heutzutage wird die Informatik und Softwareentwicklung leider primär von Männern dominiert. Doch schaut man ein paar Jahrzehnte zurück, haben viele Frauen maßgeblich die heutige Software-Entwicklung geprägt. Eine Frau war Barbara Liskov. Liskov? Das kennt man doch irgendwoher? Genau. Sie ist unter anderem die Namensgeberin für das L in den SOLID-Prinzipien (die ersten 5 Prinzipien des objektorientierten Designs). Als zweite Frau überhaupt hat Barbara Liskov 2008 den berühmten Turing Award erhalten. In dieser Episode besprechen wir ihr Lebenswerk. Bonus: Barbara Liskov war an den Sprachkonstrukten Exceptions, yield, multiple assignments und multiple returns beteiligt. Das schnelle Feedback zur Episode:
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
Sprungmarken(00:00:00) Intro (00:01:13) SOLID-Prinzipien und die Anwendung in der Praxis (00:03:02) Info/Werbung (00:04:05) SOLID-Prinzipien und die Anwendung in der Praxis (00:07:07) Frauen in der Informatik und Turing Award-Gewinnerin "Barbara Liskov" (00:11:20) Erfindung von Grundlagen der Software-Entwicklung und GOTO Statements (00:14:10) GOTO Statements considered harmful (00:18:14) Venus Betriebssystem (00:19:20) Forschung zu den heutigen Grundlagen der Software-Entwicklung (00:21:49) Global variable considered harmful (00:23:18) Abstraktion, Spezifikationen und die Programmiersprache Clu (00:31:53) Das L in SOLID: Liskov Substitution Principle (LSP) (00:44:23) The Power of Abstraction Hosts
Feedback (gerne auch als Voice Message)
| |||
| 14 Feb 2023 | #58 Software-Updates, alte Software, Long Term Support und End of Life-Dates | 00:56:39 | |
Alte Software akzeptieren oder lieber jedem Update hinterherjagen? Podcast als Video: https://youtu.be/94RZcJefzR8 Das ist die Balance, die jeder finden muss. Wann update ich Software? Wie lange kann ich alte Software betreiben? Ab wann ist alte Software ein wirkliches Risiko? Sollte ich bei jeder neuen Major-Version direkt updaten? Bringt es überhaupt etwas, eine alte Software auf etwas Neues zu migrieren, ohne neue Funktionalität zu bekommen? Welche Risiken verbergen sich hinter den Updates? Ist der klassische Spruch "Never touch a running system" noch aktuell oder sogar ein Fehler? All das und weitere Themenbereiche wie Long-Term-Support, End of Life-Dates, die Software-Metrik Dependency Drift, Dependabot und rostende Software besprechen wir in dieser Episode. Bonus: Warum früher alles besser war, sogar die Zukunft und warum Legacy immer das Geld verdient. Unsere aktuellen Werbepartner findest du auf https://engineeringkiosk.dev/partners
Das schnelle Feedback zur Episode: Das tiefere 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
Sprungmarken(00:00:00) Intro (00:01:26) Video-Podcast (00:02:02) Alte Technologien (16-Bit Applikationen, PHP und JQuery und JavaScript-Abhängigkeiten) und Version Pinning (00:07:37) Was oder Wer ist dependabot? (00:09:00) Ist Subversion alte Software? Und was bringt es nach git umzusteigen? (00:12:49) Migrationen ohne neue Funktionalität und Software an die sich niemand ran traut (00:16:16) Wann weiß ich, wann ich die Software updaten sollte? End of Life-Dates (00:21:30) Software rostet: Updates für Blackbox-artige Software und nächtliche CI runs sind (00:27:08) Sollten Support / End of life dates auch an Kunden kommuniziert werden? (00:29:04) Long Term Support (LTS) / Extended Long Term Support (ELTS) (00:35:38) Dependency- und Version-Drift oder Software-Aging (00:38:02) Arten und Zeit-Intervalle von Software-Auslieferung (00:40:53) Wie lang fasst man ein System nicht mehr an und das Jahr 2038 mit den Unix-Timestamps (00:47:04) sqlite bietet Support bis zum Jahr 2050 (00:53:26) Zusammenfassung, Schrödingers Backup und Feedback Hosts
Feedback (gerne auch als Voice Message)
| |||
| 19 Apr 2022 | #15 Source Code Kommentare, Git Commits Messages, Merge Commits und Branch-Visualisierungs-Kunst | 01:05:04 | |
Kommentare im Quellcode und Git Commit Messages - Liest die überhaupt wer? Ein Streit, der so alt ist wie die Software Entwicklung selbst: Code ist Selbsterklärend und braucht keine Kommentare. Oder doch? Und die Git Historie ist auch eigentlich sinnlos. Warum sollte da jemand zurück gehen und sich die Commit Messages durchlesen? Diese Fragen und Themen wie Semantic Versioning, Idiomatische Programmier-Patterns, Merge Commits, Story-Tellung und was Fynn Kliemanns Kunst mit der Git Branch-Visualisierung zu tun hat, klären Wolfgang und Andy in dieser Episode vom Engineering Kiosk. Bonus: Warum Andy einen neuen Podcast-Partner sucht und Wolfgang lieber seinen Code angreift, anstatt Ihn zu entwickeln. Feedback an stehtisch@engineeringkiosk.dev oder via Twitter an https://twitter.com/EngKiosk Unsere aktuellen Werbepartner findest du auf https://engineeringkiosk.dev/partners
Links
Sprungmarken(00:00:00) Intro (00:01:21) Home Office: Job und Privat stark trennen? (00:02:31) Warum macht man Sport und wie steht Wolfgang zur bayerischen Ess- und Feierkultur (00:03:43) Karriere oder Software-Engineering Podcast und Hardcore-Tech-Thema (00:04:38) Wie viel Kommentare hat die letzte Datei, die du in der IDE offen hattest? (00:01:16) Wie stehst du allgemein zu Kommentaren? (00:01:05) Was sind sinnvolle Kommentare und ist Code wirklich selbsterklärend? (00:13:55) Komplexen code refactoren oder lieber gut kommentieren? (00:17:40) Kommentare für kopierten Stack Overflow Code (00:19:48) Kommentare für die Business-Domäne (00:20:11) Algorithmen und Variablen mit einem Buchstaben (00:21:46) Können gute Variablen und Funktionsnamen Kommentare ersetzen? (00:23:43) Wird der Code fürs Lesen oder Schreiben optimiert? (00:25:43) Bit-Shifting versteht doch keiner (00:28:29) Wie komplex eigentlich die Bash-Programmierung sein (00:33:11) TODO-Kommentare im Code oder lieber ein Ticket? (00:36:56) Story-Telling im Code und Entwickler-Humor (00:40:02) Kommentare in Deutsch oder Englisch und Domänen-Vokabular (00:42:34) Wie sollten Git Commit Messages aussehen? Und warum Git Commit Messages E-Mail sein können (00:45:39) Isolierte Git Commits für bessere Git Commit Messages (00:46:44) Merge Commits (00:49:59) Strukturierte Git Commit Messages und Nutzung von Prefixes wie bugfix und feature in Git Commit Messages (00:52:13) Was ist Semantic Versioning (SemVer)? (00:56:38) Der Linux Kernel als Vorbild für gute Commit Messages (00:57:55) Wolfgangs Meinung zu Merge-Commits (00:59:38) Branch-Visualisierung in Git (01:01:30) Outro Hosts
Engineering Kiosk Podcast: Anfragen an stehtisch@engineeringkiosk.dev oder via Twitter an https://twitter.com/EngKiosk | |||
| 02 Aug 2022 | #30 Ist ein Informatikstudium sinnvoll? Welche Ausbildung für Devs? | 01:05:36 | |
Wie wichtig ist die Universität und ein Studium für den heutigen Beruf als Software Entwickler⋅in? Diese bzw. ähnliche Fragen haben wir von unseren Hörer⋅innen zugesendet bekommen: Welche Unterschiede gibt es in den Ausbildungen? Wie relevant ist eine schulische oder berufliche Ausbildung? Sollte man ein Bachelor, Masterstudium machen? Und würden wir den Weg zum Dr. Titel empfehlen? Haben Akademiker nur Vorteile? Oder auch Nachteile bei der Jobsuche und beim Job selbst? Und wie kann man als Nicht-Studierte oder Quereinsteiger in der IT-Industrie Fuß fassen? All das und noch viel mehr in der Episode. Bonus: Was akademischer Spaß, Beleidigungen und Serdar Somuncu mit der ganzen Thematik zu tun haben. 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 Unsere aktuellen Werbepartner findest du auf https://engineeringkiosk.dev/partners
Links
Sprungmarken(00:00:00) Intro (00:00:50) Hat die akademische Laufbahn, Wolfgang zu einem besseren Software-Entwickler gemacht? (00:04:53) Unterschied zwischen der schulischen und beruflichen Ausbildung? (00:12:06) Haben Leute von spezifischen Universitäten / Schulen mehr drauf als andere? (00:14:10) Das heutige Thema: Wie wichtig ist die Uni / akademische Ausbildung für den Job in der IT? (00:15:11) Andys Erfahrung auf der privaten Hochschule (00:19:14) Abschlüsse von privaten Hochschulen und wie diese in der Industrie angesehen werden können (00:20:52) Können akademische Abschlüsse auch hinderlich sein? (00:24:24) Over-Engineering, unschöner Quellcode und wissenschaftliches Arbeiten von Leuten mit Dr. Titel - Erfahrungen von der Universität (00:30:27) Unterschiede in der Arbeit und Guidance vom Manager (00:31:45) Gibt es Unterschiede in der Entwicklung/Einstellung von Leuten im Beruf mit oder ohne akademische Ausbildung? (00:36:01) Sind alle Personen anpassungsfähig an eine bestimmte Arbeitsweise? (00:40:13) Kann "akademisch" ein Schimpfwort sein? (00:43:58) Wissbegierig, Neugierig, Resistenz und Motivation sind viel wichtiger (00:48:30) Ist ein Studium empfehlenswert für einen Job in der IT? Und bringt mich das bei der Jobsuche weiter? (00:55:17) Ist ein fehlendes Studium ein möglicher Karriere-Blocker? (00:58:30) Sollten Quereinsteiger bei einer kleineren Firma starten? (01:00:17) Wie sollten Schüler vorgehen? Ein Studium oder direkter Berufseinstieg? (01:03:15) Würdest du Leuten mit Studium einen den Weg zum Doktor empfehlen? (01:04:34) Outro Hosts
Feedback (gerne auch als Voice Message)
WhatsApp +49 15678 136776 | |||
| 14 Jan 2025 | #178 Code der bewegt: Infotainmentsysteme auf Kreuzfahrtschiffen mit Sebastian Hammerl | 01:08:44 | |
Softwareentwicklung in der Praxis: Infotainment-Systeme für Kreuzfahrtschiffe. Jede Industrie und Domäne hat ihre Eigenheiten und Herausforderungen. Dies überträgt sich auch auf die Software, die für die entsprechenden Anwendungsfälle geschrieben wird. Oft fragen wir uns “Wie ist es eigentlich, Software für Brauereien, Waschmaschinen oder Mähdrescher zu schreiben?”. In dieser Episode beantworten wir diese Frage für das Thema Kreuzfahrtschiffe - Also die richtig dicken Pötte. Welche Software wird auf einem Kreuzfahrtschiff benötigt? Auf welcher Hardware läuft diese und wo steht die Hardware überhaupt - In der Cloud oder ist das ein schwimmendes Datacenter? Wie sieht es mit der Internet-Connectivity und dem Debugging aus, wenn man auf den Weltmeeren unterwegs ist? Welche Probleme muss die Software lösen, wenn Ländergrenzen übertreten werden in Bezug auf Zeitzonen, Datenschutz und Accessibility? Unser Gast Sebastian Hammerl steht uns Rede und Antwort. Bonus: Speedboot fahren mit Systemadministratoren - Warum nicht? Unsere aktuellen Werbepartner findest du auf https://engineeringkiosk.dev/partners Das schnelle Feedback zur Episode: Feedback
Links
Sprungmarken(00:00:00) Intro (00:01:09) Softwareentwicklung auf und für Kreuzfahrtschiffe mit Sebastian Hammerl (00:07:08) Software auf einem Schiff installieren, wenn es im Trockendock ist (00:07:49) Info/Werbung (00:08:49) Software auf einem Schiff installieren, wenn es im Trockendock ist (00:27:51) Software die sich bewegt: Zeitzonen (00:36:39) Internationale Gegebenheiten: Datenschutz (00:39:41) Bug-Handling und Deployments (00:46:07) Schwimmendes Datacenter: Redundanz und Notfälle (00:53:16) Tech-Stack auf einem Schiff (00:55:40) Als IT-Admin auf dem Schiff arbeiten (01:01:16) Empfehlung für alle, die sich das Thema näher ansehen wollen Hosts
Feedback
| |||
| 30 Apr 2024 | #121 YAML: Mehr als Konfiguration! Aliases, Tags und YAMLScript mit Tina Müller | 01:07:19 | |
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: Feedback
Gerne behandeln wir auch euer Audio Feedback in einer der nächsten Episoden, einfach die Audiodatei per Email an stehtisch@engineeringkiosk.dev. Links
Sprungmarken(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 Hosts
Feedback
| |||
| 04 Jul 2023 | #78 Microservice & Monolith: Was die Industrie in den letzten 9 Jahren gelernt hat | 01:01:25 | |
Monolithen und Microservices: Ein Evergreen der Software-Industrie. Mitte der 2010er Jahre bekam das Thema der Microservices Popularität. Doch was haben wir nach ca. 9 Jahren darüber gelernt? Sind Microservices immer noch der heilige Gral oder war es eine tolle Reise und alle pendeln zurück zu Monolithen? Viele Firmen haben positive und negative Erfahrungen und Learnings mit Microservices gemacht. Doch war es für alle der richtige Schritt? Nutzen die meisten Firmen die wahren Vorteile von Microservices wirklich aus? Und welches Problem löst der Microservice-Trend eigentlich? Ein technisches oder organisatorisches Problem? Welche Probleme gibt es in der Welt um Microservices, besonders in großen, schnell wachsenden Organisationen? Was sind typische Gründe warum Microservices scheitern? Und waren Cloud Native, Container-Scheduler wie Kubernetes und Co einfach nur weiteres Öl, was ins Microservice Feuer gekippt wurde? In dieser Episode schauen wir uns an, was die Industrie denn so in den letzten 9 Jahren über den ganzen Microservice-Hype gelernt hat. Bonus: Warum es weiterhin ein Religionsthema bleibt und es keine Gewinner geben wird. Unsere aktuellen Werbepartner findest du auf https://engineeringkiosk.dev/partners
Das schnelle Feedback zur Episode: 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
Sprungmarken(00:00:00) Intro (00:01:25) Warum Microservices und Monolithen ein Motivationsloch auslösen (00:03:14) Wann kam das Thema "Microservices vs. Monolithen" eigentlich auf? (00:06:07) Geht es wieder zurück zu Monolithen? (00:09:15) Welches Problem sollte Microservices eigentlich lösen? (00:17:13) Was ist ein Monolith, Micro- und Nano-Service? (00:22:49) Löst die Microservice vs. Monolith-Frage ein technisches oder organisatorisches Problem? (00:24:38) Ist der Erfolg von Kubernetes und Container scheduling direkt mit dem Hype um Microservices zu verbinden? (00:28:42) Sind Microservices denn immer einzelne Systeme? (00:31:41) Guidelines für Microservices: Independent Systems Architecture, Reliability Manifesto und Best Practices (00:42:02) Gute Architekturen um Teams skalierbar zu gestalten und Microservices im Frontend (00:45:11) Warum Microservices scheitern (00:47:25) Gemeinsame Datenmodelle und Deployment Monolithen (00:51:55) Code-Ownership bei Firmen-Umstrukturierungen und Gesetz von Conway (00:56:14) Beide Modelle sind gleich schlecht (00:59:51) Feedback zum Motivationsloch Hosts
Feedback (gerne auch als Voice Message)
| |||
| 19 Mar 2024 | #115 Die Shift Left Philosophie: Mehr Verantwortung für Devs | 00:54:59 | |
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: 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
Sprungmarken(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 Hosts
Feedback (gerne auch als Voice Message)
| |||
| 12 Jul 2022 | #27 Sicherheit in der Dependency Hölle | 00:56:18 | |
Was haben die JavaScript Pakete left-pad, color, faker und cross-env gemeinsam? Alle waren in npm Package Sicherheits-Incidents involviert. Wenn man sich die Anzahl von Javascript Abhängigkeiten bei Mittelgroßen Projekten ansieht, ist eine dreistellige Anzahl an JavaScript Paketen nicht unüblich. Das liegt primär an der überschaubaren Größe der Pakete und somit der Funktionalität. Alles nur, um Pakete verwaltbarer zu halten. Doch dieser Umstand macht das JavaScript-Ecosystem so attraktiv für Angreifer oder kann zu extremen Seiteneffekten führen. In dieser Episode sprechen wir drei npm Package Incidents durch, was es damit aufsich hatte, welche Attack-Möglichkeiten es noch gibt und wie man sich als Software Entwickler dagegen schützen kann. Bonus: Was Bademeister, Blubberwasser und eine ASCII-Repräsentation von Uncle Sam und der amerikanischen Flagge mit JavaScript zu tun haben. Feedback an stehtisch@engineeringkiosk.dev oder via Twitter an https://twitter.com/EngKiosk Unsere aktuellen Werbepartner findest du auf https://engineeringkiosk.dev/partners
Links
Weitere nicht behandelte Incidents
Sprungmarken(00:00:00) Intro (00:00:35) Intro: 10.000 Downloads und Die Bademeister (00:01:42) Wie viele Firmen setzen (bewusst) Open Source ein? (00:04:09) Wie viele Firmen unterstützen Open Source finanziell? (00:06:22) Open Source Funding via Media Tech Lab (00:08:11) Das Management von Software-Dependencies anhand des JavaScript-Ecosystems via npm (00:08:59) Warum JavaScript als Beispiel genutzt wird und die Theorie warum JavaScript Pakete so klein sind und viele Abhängigkeiten haben (00:15:06) npm Package Incident: Das Paket "left-pad" wurde aus der npm Registry entfernt (unpublished) (00:23:06) npm Package Incident: Die Pakete "color" und "faker" geben Textmüll auf der Konsole aus (00:27:29) npm Package Incident: Das Paket "cross-env" und der typosquatting-Angriff mit "crossenv" (00:33:01) Weitere Angriffs-Vektoren in Bezug auf Software Dependencies: Böswilliger Maintainer, Schadcode in Sub-Dependency, Account-Übernahme und die falsche Package Registry (00:40:23) Ein Lösungsweg: npm package scopes (00:42:02) Weitere Lösungswege: Schadcode und frühere Fraud-Detection auf Plattform-Seite, die Überwachung von direkten Dependencies und Version-Pinning (00:47:40) Dependabot: Versionen von Dependencies automatisch updaten und auf neue Dependencies achten (00:53:44) Der gesunde Streit: Zanken und Bierchen (00:54:17) Outro Hosts
Engineering Kiosk Podcast: Anfragen an stehtisch@engineeringkiosk.dev oder via Twitter an https://twitter.com/EngKiosk | |||
| 27 Sep 2022 | #38 Monitoring, Metriken, Tracing, Alerting, Observability | 00:55:50 | |
Wie würde heutzutage ein moderner Logging, Metriken, Monitoring, Alerting und Tracing-Stack aussehen? Im Infrastruktur-Bereich gibt es zu jedem Bereich etliche Tools. Cloud-Native ist das Buzzword der Stunde. In dieser Episode erzählt Andy, wie er einen modernen Stack für ein Side-Projekt für die Bereiche Logging, Metriken, Monitoring, Alerting und Tracing aufsetzen würde. Unter anderem geht es dabei um Fragen wie: Was sollte man eigentlich alles loggen? Wie kann man von einem Alert angerufen werden? Wie visualisiert man Daten in schönen Graphen? Brauchen wir Tracing? Und was ist Observability? Bonus: Engineering Porn und Buzzword-Bingo. 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 Unsere aktuellen Werbepartner findest du auf https://engineeringkiosk.dev/partners
Links
Sprungmarken(00:00:00) Intro (00:00:50) Wolfgangs MySQL-Buch (00:02:11) Heutiges Thema: Wie würde Andy die Themen Monitoring, Alerting, Metriken und Logging bei einem Side Projekt angehen? (00:04:49) Warum brauchst du Logging, Monitoring, Metriken und Tracing? (00:07:29) Logging von Exceptions, Warnings und anderen Fehler, Logging und der ELK-Stack (00:16:06) Was sollte man eigentlich alles loggen? (00:19:22) Log-Rotation und Log-Retention auf Object-Storage (00:27:30) Metriken mit Prometheus (00:31:46) Visualisierung von Metriken mit Grafana (00:34:25) Intelligente Alerting Systeme und die richtigen Schwellenwerte finden (00:38:47) Alerts senden und anrufen lassen (00:43:22) Tracing: Was ist das und brauchen wir das? (00:48:49) Was ist Observability? (00:51:42) Iterativer Aufbau seiner Plattform und Alternativen (00:54:49) Keine bezahlte Werbung (00:55:14) Outro und Feedback Hosts
Feedback (gerne auch als Voice Message)
| |||
| 14 Nov 2023 | #97 Metriken, Hypothesen und Fehler: A/B-Testing in der Praxis mit Philipp Monreal | 01:08:46 | |
Kontinuierliches Lernen mit Hilfe von Experimenten und A/B-Testing In vielen Diskussion geht es darum, welche Lösung die bessere ist und einen größeren Impact hat. Viele Entscheidungen werden aus dem Bauch heraus getroffen, obwohl gesagt wird, dass wir datengetrieben arbeiten. Doch Daten und Ergebnisse sind oft nicht vorhanden. Experimente mit A/B-Tests sind für solche Situationen das Mittel der Wahl. Hypothese aufstellen. Experiment umsetzen und durchführen. Ergebnis evaluieren. Und das ganze wiederholen. Klingt einfach.Experimentelles Mindset: Check. Doch wie macht man sowas denn im Detail? Auf welche und wie viele Metriken schaut man während eines Experiments? Wie lange darf es dauern? Kann ich das ganze auch mit wenig Kunden und Traffic umsetzen? Was sind die typischen Fehler beim A/B-Testing? Was ist ein p-Wert, eine statistische Signifikanz, eine Power-Analyse, ein A/A-Test, der Priming-Effekt? Das und noch viel mehr in dieser Episode mit unserem Gast Dr. Philipp Monreal. Bonus: Ob A/B-Testing mit Podcast-Episoden-Titeln für normale Podcast-Hosts möglich ist. Unsere aktuellen Werbepartner findest du auf https://engineeringkiosk.dev/partners
Das schnelle Feedback zur Episode: 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
Sprungmarken(00:00:00) Intro (00:01:01) Unser Gast: Philipp Monreal (00:03:06) Experimenten in der Softwareentwicklung und das experimentelle Mindset (00:07:46) Hypothesengetriebene Entwickeln und die Implementierung einer Lernkultur (00:14:29) Metriken für Experimente und die Verteilung von Test- und Kontrollgruppen (00:26:45) Statistisches Rauschen, der p-Wert, die Nullhypothese und statistische Signifikanz (00:35:30) "Extraordinary claims, require extraordinary evidence" und "Any figure that looks interesting or different is usually wrong" (00:41:49) Günstiges Testen im Tech-Bereich (00:45:31) Mehrere Tests gleichzeitig durchführen (00:49:57) Storytelling als Ergebnis-Präsentation und Kontrolle der Daten (00:58:00) Vorbereitung und Nachbereitung von Experimenten (01:01:44) Lernen als wichtiger Faktor in der Organisation Vermeidung von "Hippos" (01:06:31) Podcast-Titel-Tests mit A/B-Testing Hosts
Feedback (gerne auch als Voice Message)
| |||
| 11 Jun 2024 | #127 Imposter-Syndrom & Peter-Prinzip mit Dr. Fanny Jimenez | 01:01:41 | |
Phänomene aus dem beruflichen Leben und die persönliche Wahrnehmung der eigenen Fähigkeiten und Leistungen Jeder kennt diese Situation: Man muss etwas präsentieren und fragt sich “Wenn die merken, dass ich eigentlich gar keine Ahnung von diesem Thema habe …” oder dass man sich den eigenen Erfolg, die eigene Leistung einfach nicht eingestehen möchte. Das Ganze nennt man Imposter-Syndrom oder auch Hochstapler-Syndrom genannt. Und es ist ganz normal. Das Gegenteil davon ist der sogenannte Dunning-Kruger-Effekt. Wenn einzelne Personen ihr Können überschätzen, obwohl sie sich dafür nicht qualifiziert oder das nötige Wissen haben. Und das dritte Phänomen aus dem beruflichen Leben ist das Peter-Prinzip. Dies besagt, dass Menschen bis zu ihrer Unfähigkeit befördert werden. Kommt dir alles irgendwie bekannt vor? Vielleicht sogar aus deinem Beruf? Uns auf jeden Fall. Deswegen wollten wir mehr über diese Themen wissen und sprechen mit der promovierten Psychologin Fanny Jimenez darüber. Fanny bringt Licht ins dunkle, erklärt uns, was die einzelnen Phänomene wirklich bedeuten, welchen Einfluss diese auf unsere Persönlichkeit haben, aber auch, ob diese normal sind, wie wir diesen vorbeugen können und vieles mehr. Bonus: Bin ich eigentlich noch normal, wenn … Unsere aktuellen Werbepartner findest du auf https://engineeringkiosk.dev/partners
Das schnelle Feedback zur Episode: Feedback
Gerne behandeln wir auch euer Audio Feedback in einer der nächsten Episoden, einfach die Audiodatei per Email an stehtisch@engineeringkiosk.dev. Links
Sprungmarken(00:00:00) Psychologie mit Fanny Jimenez (00:05:28) Das Imposter-Syndrom (00:10:09) Die eigene Komfortzone, Stereotypen und das Selbstwertgefühl (00:16:30) Werbung in eigener Sache (00:17:46) Dauerhaftes lernen, Personen enablen und Angststörungen (00:27:18) Perfektionismus, die Relation zum Imposter-Syndrom und Leidensdruck (00:33:05) 360° Feedback (00:35:34) Ist das Imposter-Syndrom normal? (00:36:51) Der Dunning-Kruger-Effekt (00:42:26) Die positiven Seiten des Imposter-Syndrom (00:43:32) Das Peter-Prinzip (00:56:20) Wie erkenne ich, ob "der Peter bin"? (00:57:48) Wann ist man selbst zufrieden? Social Media als Vergleichsmaschine (01:00:11) Schlusswort von Fanny Jimenez Hosts
Feedback
| |||
| 08 Dec 2024 | #159 Verhaltensbezogene Interview-Fragen und STAR-Methode | 00:08:48 | |
Verhaltensbezogene Interview-Fragen und STAR-Methode. Im Engineering Kiosk Adventskalender 2024 sprechen befreundete Podcaster⋅innen und wir selbst, Andy und Wolfi, jeden Tag kurz & knackig innerhalb von wenigen Minuten über ein interessantes Tech-Thema. Unsere aktuellen Werbepartner findest du auf https://engineeringkiosk.dev/partners Das schnelle Feedback zur Episode: Links
Sprungmarken(00:00:00) Verhaltensbezogene Interview-Fragen und STAR-Methode Hosts
Feedback
| |||
| 14 Jun 2022 | #23 Schaltest du noch oder automatisiert du schon: Home Automation | 01:03:32 | |
Machst du noch selbst das Licht an oder automatisiert du schon? Internet of Things (IoT) ist in aller Munde. Jedes Device trackt irgendwas mit. Doch was kann man damit machen? Home Automation ist das richtige Stichwort. Und dafür braucht man kein eigenes Haus oder ein abgeschlossenes Studium. In dieser Episode geben Andy und Wolfgang einen praktischen Einblick und wie man am einfachsten selbst loslegen kann. Weiterhin versuchen wir euch mit unseren Learnings vor schlimmerem zu bewahren. Viel Spaß beim automatisieren. Bonus: Warum der Grundriss von Andys Wohnung nun in China ist und warum bald alle Hörer∙innen nackig durch ihre Wohnung rennen. Feedback an stehtisch@engineeringkiosk.dev oder via Twitter an https://twitter.com/EngKiosk Unsere aktuellen Werbepartner findest du auf https://engineeringkiosk.dev/partners
Links
Sprungmarken(00:00:00) Intro (00:01:49) Home Automation - Warum ist das Thema überhaupt relevant? (00:04:22) Was ist unsere Einstiegsdroge als Intro ins Thema Home Automation? Spoiler: Vernetzte Rauchmelder (00:07:06) Internet of Things (IoT) ist überall (00:07:49) Was wir in dieser Home Automation Folge behandeln und was nicht (00:11:08) Wie startet man mit Heimautomatisierung "the lean way"? (00:16:22) Was ist Home Assistant? (00:19:37) Wie sieht Wolfgangs Home Automation Setup aus? (mit einem Einstieg zu Zigbee und Zigbee Mesh) (00:22:20) Wie sieht Andys Home Automation Setup aus? (00:24:58) Was ist MQTT? (00:28:07) Protokolle im Home Automation Umfeld: Zigbee, Homematic, Z-Wave, Thread (00:37:09) Herausforderungen bei der Home Automation: Anzahl der Protokolle im System (00:43:22) Herausforderungen bei der Home Automation: (Manuelle) Nutzung trotz Ausfall (nach Neustart oder Stromausfall) (00:47:30) Herausforderungen bei der Home Automation: Box of Shame - Zu viele Komponenten, die noch verbaut werden müssen (00:48:33) Herausforderungen bei der Home Automation: Ist das ganze ohne Internet / Cloud lauffähig? (00:50:48) Herausforderungen bei der Home Automation: Monitoring von Batteriekomponenten (00:53:31) Welche Automations haben wir implementiert? (01:01:27) Zuviele Home Automation Systeme und Komponente (01:02:00) Outro Hosts
Engineering Kiosk Podcast: Anfragen an stehtisch@engineeringkiosk.dev oder via Twitter an https://twitter.com/EngKiosk | |||
| 31 Dec 2024 | #176 Der Engineering Kiosk wird 3 Jahre alt! | 01:05:51 | |
3 Jahre Engineering Kiosk: Geburtstagsepiode und Jahresrückblick auf 2024 Der Engineering Kiosk Podcast wird stolze 3 Jahre alt. Ein Grund zu feiern. Zeitgleich geht das Jahr 2024 zu Ende. Eine Möglichkeit auf einen Rückblick, wie sich das Engineering Kiosk Projekt entwickelt. Wir sprechen über Episoden, die etws bei unseren Hörer*innen und bei uns selbst bewegt haben. Wir teilen ein paar Statistiken über den Podcast sowie unseren persönlichen Highlights, Lowlights und Neutralights. Weiterhin geben wir einen Einblick wie wir unsere Interviewgäste auswählen und wir auf gekaufte Interviews und Tech Employer Branding Agenturen reagieren. Am Ende lösen wir auch noch unsere Tech Predictions für das Jahr 2024 auf und entscheiden somit, wer das bessere Orakel ist. Bonus: Auch Podcast-Hosts streiten sich manchmal wie ein altes Ehepaar und ein paar Outtakes gibts auch. Unsere aktuellen Werbepartner findest du auf https://engineeringkiosk.dev/partners Das schnelle Feedback zur Episode: Feedback
Links
Sprungmarken(00:00:00) Happy Birthday Engineering Kiosk (00:03:35) Info/Werbung (00:04:35) Happy Birthday Engineering Kiosk (00:25:51) Statistiken zum Podcast (00:33:32) Unsere Highlights (00:39:17) Unsere Lowlights (00:41:04) Unsere Neutralights (00:43:00) Interviews, wie wir Gäste auswählen und gekaufte Episoden (00:50:34) Tech Predictions aus 2024 / Episode 100 (01:02:45) Ausblick auf 2025 Hosts
Feedback
| |||
| 25 Feb 2025 | #184 GPU Programmierung - von CUDA bis OpenMP mit Peter Thoman | 01:10:21 | |
GPU-Programmierung: Andere Chips und eine andere Art zu programmieren In der heutigen Zeit dreht sich fast alles in der IT um AI. Und damit auch oft um den sich positiv entwickelnden Aktienkurs von Nvidia. Warum Nvidia? Als Hersteller von Grafikkarten bzw. Grafikchips (kurz GPUs) profitieren sie deutlich von den hohen Nachfragen nach dieser Art von Chips. Das Ganze hat die Frage aufgeworfen: Inwieweit ist die Programmierung auf bzw. für eine GPU anders als bei einer klassischen CPU? In dieser Episode behandeln wir dieses Thema: Paralleles Programmieren auf der GPU. Wir bröseln das Buzzword-Bingo auf und schauen uns an, was der Unterschied zu verteiltem vs. parallelem Rechnen ist, was HPC und CUDA eigentlich ist, ob bzw. wie man auf Grafikkarten ohne Frameworks programmieren kann, welche algorithmischen Use Cases neben AI und Transformer-Modelle existieren, wie man einen Algorithmus für die GPU programmiert und was man alles vermeiden sollte, sprechen über Speicherzugriffsmuster und warum Matrizen-Multiplikationen so gut auf GPUs funktionieren aber auch was Performance-Portabilität bedeutet und ob es Probleme mit der Heterogenität von Grafikkarten und Chips gibt. Und das alles mit Dr. Prof. Peter Thoman. Bonus: Wie besucht man möglichst effizient alle Städte in Deutschland? Das Problem des Handlungsreisenden. Unsere aktuellen Werbepartner findest du auf https://engineeringkiosk.dev/partners Das schnelle Feedback zur Episode: Feedback
Links
Sprungmarken(00:00:00) Intro (00:01:28) Paralleles Programmieren auf der GPU mit Peter Thoman (00:07:26) Was ist was? Verteiltes vs. paralleles Rechnen, HPC, CUDA und mehr (00:08:34) Info/Werbung (00:09:34) Was ist was? Verteiltes vs. paralleles Rechnen, HPC, CUDA und mehr (00:22:34) Wie hat die Berechnung auf der GPU begonnen? (00:33:23) Use-Cases für die GPU (00:45:58) Matrizenmultiplikation und Neuronale Netze auf der GPU (00:55:11) Heterogenität der Grafikkarten und Chips (01:00:10) Dein Einstieg in die GPU-Programmierung Hosts
Feedback
| |||
| 20 Sep 2022 | #37 Mit IT-Büchern Geld verdienen? Wer liest überhaupt noch Bücher? | 01:00:21 | |
Lohnt es sich ein IT-Fachbuch zu schreiben? Es gibt zu jeder Software und zu jedem IT-Thema mindestens ein Buch. Doch wie ist es eigentlich, ein solches Buch zu schreiben? Was macht ein Verlag und braucht man diesen in der heutigen Zeit eigentlich noch? Wird man dadurch reich oder bleibt es Hungerlohn? Was für ein Tech-Stack steckt hinter einem Buch? Und wie würde man eigentlich starten? All das klären wir in dieser Episode mit Wolfgang, der ein Buch über MySQL im Rheinwerk-Verlag (Galileo Press) publiziert hat. Bonus: Warum Wolfgang eher ein Fan vom Reden ist und warum er wirklich so lange für seinen Dr. Titel benötigt hat. 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 Unsere aktuellen Werbepartner findest du auf https://engineeringkiosk.dev/partners
Links
Sprungmarken(00:00:00) Intro (00:00:40) Schreib-Skills (00:02:42) Thema: Das schreiben von IT Fachbüchern - MySQL, das umfassende Handbuch (00:03:39) Wie gut kennst du dich im Bereich MySQL aus? (00:05:19) Überblick über Wolfgangs MySQL Buch (00:09:34) Wie lange habt ihr benötigt, das Buch zu schreiben? (00:11:24) Welcher Tech-Stack wurde genutzt, um das Buch zu schreiben? (00:13:43) Welche Aufgaben hat der Verlag übernommen? (00:18:54) Wie hast du die Verbindung zum Verlag aufgebaut? (00:21:17) Was verdient man mit einem IT Fachbuch? (00:28:21) Warum hast du ein Buch geschrieben? Was bringt es ein Buch zu schreiben? (00:30:27) Was hat sich durch das Buch bei dir professionell ergeben? (00:32:22) Wieso habt ihr das Schreiben einer neuen Edition abgelehnt? (00:33:56) Imposter-Syndrom: Wie viel weißt du über das MySQL Datenbank-Thema, nach deiner Recherche? (00:35:52) Wie viele Amazon-Reviews hast du gekauft? (00:38:39) Liest du IT-Fachbücher? (00:43:24) Würdest du nochmal ein Buch schreiben? (00:46:32) Würdest du Leuten empfehlen, ein Buch zu schreiben? (00:51:00) Was würdest du Leuten empfehlen, die ein Buch schreiben möchten? (00:53:25) Würdest du nochmal ein Buch über eine Software/Software-Version schreiben? (00:55:50) Hattest du schon Berührungen zu einem Ghostwriter? (00:58:46) Lohnt sich das Mittel- und Langfristig ein Buch zu schreiben? (01:01:22) Selbst-Publishing und Print on Demand (01:03:56) Audio-Rants, Reddit und Outro Hosts
Feedback (gerne auch als Voice Message)
| |||
| 21 May 2024 | #124 Technische Glaubwürdigkeit bewahren: Müssen Leads den Code kennen? | 00:49:51 | |
Hands-On als Engineering Manager: Yay or Nei? Leute, die einmal das Handwerk des Software-Engineerings professionell ausgeübt haben und dann ins Management wechseln, haben oft den Drang, ihr Hardskills nicht zu verlieren. Doch durch den neuen Job sind die Prioritäten nun andere: People Leadership, das Team effizient halten, Strategie und Roadmaps entwickeln. Wo bleibt denn da noch die Zeit am Code mitzuarbeiten? Wir stellen uns die Frage: Warum ist das so? Muss das sein, dass Manager weiterhin technisch sind? Und wenn ja, welche Gefahren birgt das? Aber auch: Wie können wir es möglich machen, obwohl unser Kalender sagt, dass die Woche mit Meetings bereits belegt ist? Darum geht es in dieser Episode. Viel Spaß! Bonus: Auch Manager laufen auf Kaffee. Unsere aktuellen Werbepartner findest du auf https://engineeringkiosk.dev/partners
Das schnelle Feedback zur Episode: Feedback
Gerne behandeln wir auch euer Audio Feedback in einer der nächsten Episoden, einfach die Audiodatei per Email an stehtisch@engineeringkiosk.dev. Links
Sprungmarken(00:00:00) Die Anforderung, dass Engineering Manager Hands On sind (00:06:54) Muss ein Engineering Manager technisch sein? (00:10:09) Verschiedene Firmen definieren die Rolle einer Managerin unterschiedlich (00:12:48) Risiken, wenn die Engineering Manager zu technisch sind (00:14:08) Möglichkeit technisch zu bleiben: Pair-Programming und Code Reviews (00:18:25) Möglichkeit technisch zu bleiben: Dokumentation schreiben und Architektur Entscheidungen (00:22:38) Möglichkeit technisch zu bleiben: Rubber Duck Development, On-Call und Coden (00:32:01) Lernen außerhalb der Arbeitsumgebung: Hackernews, Konferenzen, Meetups und Code Katas (00:43:48) Engineering Management ist ein anderer Job als Software Entwicklung Hosts
Feedback
| |||
| 18 Apr 2023 | #67 Die Netz-Entlastung des Internets: Content Delivery Networks (CDNs) | 01:06:42 | |
Content Delivery Networks (CDNs): Die Netz-Entlastung des Internets Jeder nutzt sie, bewusst oder unbewusst: Content Delivery Networks. Sie sind aus dem Internet nicht mehr wegzudenken. Angetreten, um einzelne Server/Websites vor Überlastungen zu schützen, bilden diese nun das Backbone von schnellen Ladezeiten für Websites, Video-Streaming und Co. Doch was genau ist eigentlich ein CDN? Was sind Vor- und Nachteile? Welche Arten von CDNs gibt es? Hat der Begriff "Edge" aus dem Cloud-Bereich auch was damit zu tun? Und überhaupt: Sollte ich mit meiner App ein CDN verwenden, wie würde ich meine App migrieren und ist dies überhaupt konform mit den aktuellen Datenschutz-Regelungen? Dies und noch viel mehr in dieser Episode. Bonus: Was Geldautomaten und Holland-Räder mit Content Delivery Networks zu tun hat. Unsere aktuellen Werbepartner findest du auf https://engineeringkiosk.dev/partners
Das schnelle Feedback zur Episode: 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
Sprungmarken(00:00:00) Intro (00:00:58) Das heutige Thema: Content Delivery Networks (CDNs) (00:03:30) CDNs, Google Fonts, GDPR und die Abmahnung (00:07:54) Was sind Content Delivery Networks (CDNs)? (00:12:47) Warum wurden Content Delivery Networks erfunden? (00:15:23) CDN ist inzwischen ein Oberbegriff für viele Services (00:16:25) JavaScript Caching durch CDNs: Früher und heute (00:19:10) Vor- und Nachteile: Performance, Abhängigkeiten und Multi-CDN (00:22:04) Vor- und Nachteile: Kosten (00:27:47) Vor- und Nachteile: Sub-Domains und parallel Requests (00:30:18) Vor- und Nachteile: Sicherheit-Mechanismen, Traffic-Analysen und Komplexität (00:33:51) CDN-Topologien: Verstreute und Konsolidierte CDNs (00:36:04) Point of Presence (POP), Edge-Locations und -Computing (00:50:25) CDN-Arten (Pull und Push) und Dateien löschen (00:54:30) Solltest du CDNs eigentlich verwenden? (00:57:02) CDNs in Legacy-Software implementieren (00:59:05) DSGVO und CDNs: Ein Konflikt? (01:02:59) CDNs für kleine oder große Dateien? (01:04:43) Feedback, Community und Empfehlungen Hosts
Feedback (gerne auch als Voice Message)
| |||
| 03 Jan 2022 | #01 Side Projects - Fluch oder Segen für die Karriere? | 00:46:22 | |
Zwei Engineering Manager über Side Projects: Wie diese den Recruiting Prozess beeinflussen, welche Learnings aus einem Projekt generiert werden, was die freiwillige Feuerwehr mit Site Reliability Engineering zu tun hat, welche negativen Seiten Side Projects haben können, ob ein Hund auch ein eigenes Side Project ist und warum man nicht seinen eigenen Mailserver betreiben sollte. Bonus: Der Unterschied zwischen Schnacken und Schnackseln Unsere aktuellen Werbepartner findest du auf https://engineeringkiosk.dev/partners
Feedback an stehtisch@engineeringkiosk.dev oder via Twitter an https://twitter.com/EngKiosk Andy (https://twitter.com/andygrunwald) und Wolfgang (https://twitter.com/schafele) sprechen im Detail über: Sprungmarken(00:26) Warum "Engineering Kiosk"? Woher kommt der Name? (01:52) Einstieg ins Thema "Side Projects" (02:00) Side Projects im Recruiting Prozess und Lebenslauf (03:45) Muss das Side Project etwas mit dem Job zu tun haben? (05:40) Alleine oder im Team? (08:10) Was bringt dir die Information "Side Project" für das Interview selbst? (11:25) Hire for Skill or for attitude (12:43) Kann ein Side Project auch etwas negatives bedeuten (als Hiring Manager)? (14:55) Wolfgang erzählt aus dem Krieg: Sein Mail-Server Side-Project (18:31) Psychologischer Druck bei Side Projects (19:23) Learnings aus Side Projects (23:44) Rollen-, Zeit- und Energiemanagement: Side-Projects mit Familie/in der Freizeit (31:53) Side Projects als Ausgleich (34:10) Learnings aus dem Side Project im Job als Engineering Manager (36:27) Lohnen sich Side Projects für die Job-Suche? (40:02) Wie Ihr eure Side Projects nutzen könnt um das Interview zu eurem Vorteil zu drehen (42:45) Brauchen wir POP3 noch? (43:34) Top Tip: Startet ein Side Project und setzt euch die richtigen Erwartungen (44:39) Sind Arbeitgeber glücklich über Side Projects von MitarbeiterInnen? Erwähnte Personen
Hosts
Engineering Kiosk Podcast Anfragen an stehtisch@engineeringkiosk.dev | |||
| 14 Dec 2024 | #165 Pessimistisches und Optimistisches Sperren in Datenbanken: Eine Geschichte | 00:06:10 | |
Pessimistisches und Optimistisches Sperren in Datenbanken. Im Engineering Kiosk Adventskalender 2024 sprechen befreundete Podcaster⋅innen und wir selbst, Andy und Wolfi, jeden Tag kurz & knackig innerhalb von wenigen Minuten über ein interessantes Tech-Thema. Unsere aktuellen Werbepartner findest du auf https://engineeringkiosk.dev/partners Das schnelle Feedback zur Episode: Links
Sprungmarken(00:00:00) Pessimistisches und Optimistisches Sperren in Datenbanken Hosts
Feedback
| |||
| 25 Oct 2022 | #42 Lexer, Parser und Open Source in Counterstrike | 00:53:38 | |
Was haben Lexer, Parser und Counter-Strike gemeinsam? Richtig! Eine schöne Open Source Story. Computerspiele sind für viele Software-Entwicklerinnen und -Entwickler der Einstieg. Andere wiederum steigen über den klassischen Bildungsweg eines Informatik-Studiums in die Softwareentwicklung ein. Dabei wird oft viel Theorie wie Lexer, Parser und Compilerbau durchgenommen. Doch was haben Computerspiele mit Lexer und Parser gemeinsam? Andy erzählt eine Story, wie er vor Jahren sich mit Lexer und Parser anhand einer Counter-Strike-Konfigurationsdatei vertraut gemacht hat. Eigentlich nur, um eine datengetriebene Spielanalyse zu betreiben. Raus kam ein Lexer und Parser für das Valve Data Format (VDF). Eine Geschichte voller Over-Engineering, Open Source, Spaß und einem Job-Angebot. Bonus: Wie Wolfgang nur ans cheaten denkt, was autoexec mit Maustreibern zu tun hat und was Landmaschinen auf YouTube mit Rabbitholes zu tun haben. 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 Unsere aktuellen Werbepartner findest du auf https://engineeringkiosk.dev/partners
Links
Sprungmarken(00:00:00) Intro (00:00:42) Wolfgang und Computer-Spielen, LAN-Parties, 10 Mbit-Netzwerke und End-Terminator (00:08:57) Der Hintergrund: Wie Andy zu Counter Strike kam und was das mit programmieren zu tun hat (00:14:25) Counter Strike Game State Integration: Webhooks vom Spiel (00:19:52) Valve Data Format (VDF), die Source Game Engine (00:21:29) Daten-getriebene Spiel-Strategien und ein automatischer Installer für eine Webhook-Adresse (00:25:28) Ein Lexer und Parser für das Valve Data Format (VDF) (00:30:03) Was ist ein Lexer? Was ist ein Token? (00:35:14) Was ist ein Parser? (00:39:18) War es notwendig, einen Lexer und Parser zu schreiben? Und die Testphase des Installers (00:41:47) Wird die Lexer- und Parser Library von jemandem verwendet? Und ein Job-Angebot (00:46:31) Anwendungsfälle: Spiele-Analysen, Zimmerlicht auf Basis der Bombe ändern, Streaming-Overlays (00:49:43) Eine schöne Open Source Story (00:51:46) Outro Hosts
Feedback (gerne auch als Voice Message)
| |||
| 27 Aug 2024 | #138 Gemeinsam stark: Jobsharing und Tandems in der modernen Arbeitswelt mit Anna Drüing-Schlüter | 01:11:06 | |
Alternatives Arbeitsmodell: Job-Sharing mit Tandem Die Welt wird immer komplexer. In diesem Kontext ist die Digitalisierung nicht immer förderlich. Die erhöhte Komplexität der Umgebung hat auch einen Effekt auf den eigenen Job und auf Leads und andere Führungskräfte. Firmen stehen immer wieder vor der Herausforderung, die richtige Person für eine Stelle zu finden. Doch was wäre denn, wenn wir nicht eine Person für eine Stelle, sondern gleich zwei neue Mitarbeiter für eine offene Stelle suchen würden? Bestimmt springen dir gerade ganz viele (negative) Gedanken durch den Kopf und du fragst dich “Hä? Wat?”. Doch simplifiziert fasst dies das alternative Arbeitsmodell des Job-Tandems zusammen. Und genau darum geht es in dieser Episode. Wir sprechen mit Anna Drüing-Schlüter von der Firma Twise, die uns Einblick in diese Art von doppelter Führung gibt. Bonus: Alles muss man vielleicht doch nicht allein machen. Das schnelle Feedback zur Episode: Feedback
Gerne behandeln wir auch euer Audio Feedback in einer der nächsten Episoden, einfach die Audiodatei per Email an stehtisch@engineeringkiosk.dev. Links
Sprungmarken(00:00:00) Intro (00:01:16) Job-Tandem mit Anna Drüing-Schlüter (00:05:09) In Bezug auf Flexibilität und Karriere: Was hat sich in den letzten Jahren im Arbeitsmarkt geändert? (00:06:07) Info/Werbung (00:07:35) In Bezug auf Flexibilität und Karriere: Was hat sich in den letzten Jahren im Arbeitsmarkt geändert? (00:26:19) Entscheidungsfindung im Tandem (00:33:58) Wie offen sind Firmen für dein Tandem-Modell? (00:40:48) Doppelte Kosten im Job-Sharing? (00:49:33) Verantwortlichkeiten im Tandem (00:54:21) Erfahrung bei der Arbeit im Tandem (01:00:25) Kommunikation nach Außen (01:06:57) Wie starte ich mit dem Job-Sharing-Modell? Hosts
Feedback
| |||
| 24 May 2022 | #20 Off-Boarding und On-Boarding: Wie verlasse ich eine Firma richtig? | 01:13:22 | |
Firmenwechsel. Kündigung ist raus. Wie gehts weiter? Offboarding und Onboarding sind i.d.R. zwei Themen die sehr stark unterschätzt werden. Wie sieht man als Mitarbeiter zu, dass bei einem Firmenwechsel keine verbrannte Erde hinterlassen wird? Wie übergibt man alles ordentlich? Warum ist das überhaupt wichtig? Und was ist ein Exit-Gespräch? Und wenn das alles durch ist: Wie startet man bei der neuen Firma ordentlich? Worauf sollte man achten? Und wie kann Onboarding aussehen? Dies und nich viel mehr. Bonus: Was Peter Thiel mit Kleber zu tun hat, was Krokodile mit Prüfungsergebnissen zu tun hat und was ein Weckmann mit dem Podcast zu tun hat. Feedback an stehtisch@engineeringkiosk.dev oder via Twitter an https://twitter.com/EngKiosk Unsere aktuellen Werbepartner findest du auf https://engineeringkiosk.dev/partners
Links
Sprungmarken(00:00:00) Intro (00:01:52) Landtagswahl in NRW und das Feedback bei der Briefwahl (00:07:42) Themen-Intro: Offboarding und Onboarding (00:08:42) Wie kommen wir auf das Thema Offboarding und Onboarding (00:10:09) Warum ist das Thema Offboarding und Onboarding relevant ist (00:12:02) Wie lang sollte man bei einer Firma bleiben? (00:16:02) Muss man sich jede 2 bis 4 Jahre neu erfinden? (00:19:43) Die Definition von Arbeit: Geld gegen Zeit und Fähigkeit und Loyalität zu Firmen (00:21:12) Die Goldenen Handschellen durch Equity, Stocks und Firmen-Anteile (00:22:49) Warum ist der Offboarding-Prozess eigentlich wichtig? (00:23:43) Der Offboarding-Prozess aus der Sicht der Firma: Feedback, Exit-Chat, eigenes Netzwerk (00:32:30) Der Offboarding-Prozess aus Sicht eines Mitarbeiter: Verbrannte Erde, Kaffee trinken, Prozesse die failen (00:48:00) Die Zeit zwischen Offboarding und der neuen Firma: Urlaub (00:50:51) Onboarding in einer neuen Folge: Intro Chats, Dokumentation, Checklisten, Diagramme und dumme Fragen (01:11:20) Outro Hosts
Engineering Kiosk Podcast: Anfragen an stehtisch@engineeringkiosk.dev oder via Twitter an https://twitter.com/EngKiosk | |||
| 01 Nov 2022 | #43 Cloud vs. On-Premise: Die Entscheidungshilfe | 01:11:04 | |
Wann ist die Cloud das richtige für dich und deine Applikation? Oder doch lieber alles selbst hosten? Die Cloud wird oft als "die Lösung" für all deine Probleme beschrieben. Sie ist günstig, man benötigt weniger Personen für den operativen Betrieb, alle Services sind gemanagt und serverless und alle anderen Probleme hat man sowieso nur On-Premise. Sind damit On-Premise Datacenter und Selfhosting ausgestorben und sollten gemieden werden? Oder gibt es sogar Szenarien, wo On-Premise sogar große Vorteile hat? In dieser Episode geht es um diese Frage: Wann ist die Cloud und wann On-Premise / die eigenen Server für dich die bessere Wahl? Wir diskutieren über diese Frage anhand eines Blogposts über eine Migration aus der Cloud von 37Signal's Produkt "Hey.com". Bonus: Was der Produktlebenszyklus vom VW Golf mit der Cloud zu tun hat und warum ein Raid 1 kein Backup ist. 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 Unsere aktuellen Werbepartner findest du auf https://engineeringkiosk.dev/partners
Links
Sprungmarken(00:00:00) Intro (00:00:54) Return to Monkey Island für Linux (00:02:59) Der letzte Service, der von Google wieder eingestellt wurde: Google Stadia (Cloud Gaming) (00:04:08) Das heutige Thema: Migration aus der Cloud hin zu On-Premise (00:06:20) Warum 37Signal sich mit ihrem Service HEY aus der Cloud zurück zieht (00:13:13) Warum ist eine Migration aus der Cloud ein Thema für den Podcast und die Ansichten von Basecamp/37Signals (00:17:06) Was ist eigentlich die Cloud bzw. was heißt "die Cloud"? Und wo ist die Abgrenzung zu "Cloud Native"? (00:26:19) Verlernen wir, wie Server geracked und Datacenter betrieben werden, wenn wir immer nur die Cloud nutzen? (00:31:44) Was kostet die Cloud vs. On-Premise und wann rentiert sich welches Modell? Total Costs of Ownership, Hardware und die Größe des Operations-Team (00:51:01) War die Migration von On-Premise in die Cloud bei trivago eine gute und sinnvolle Entscheidung? (00:58:00) In welchem Setup würden wir die Cloud und wann On-Premise wählen? (01:06:59) Angst um den eigenen Job bei einer Cloud-Migration (01:09:33) Zusammenfassung und Outro Hosts
Feedback (gerne auch als Voice Message)
| |||
| 15 Dec 2024 | #166 Das Fediverse mit Christian Stankowic vom Focus on Linux Podcast | 00:11:07 | |
Was ist das Fediverse? mit Christian Stankowic vom Focus on Linux Podcast. Im Engineering Kiosk Adventskalender 2024 sprechen befreundete Podcaster⋅innen und wir selbst, Andy und Wolfi, jeden Tag kurz & knackig innerhalb von wenigen Minuten über ein interessantes Tech-Thema. Unsere aktuellen Werbepartner findest du auf https://engineeringkiosk.dev/partners Das schnelle Feedback zur Episode: Links
Sprungmarken(00:00:00) Was ist das Fediverse? Hosts
Feedback
| |||
| 10 Jan 2022 | #02 Technologienzoo Side Projects | 00:44:50 | |
Wolfgang und Andy erzählen ein wenig was über ihre eigenen Side Projects sourcectl (https://gettoknow.sourcectl.dev/), F-Online (https://www.f-online.at/) und the athlete (https://theathlete.app/). Wir machen eine Rundfahrt durch den verwendeten Technologienzoo, diskutieren ob man Monitoring in Side Projects benötigt, wann es Over-Engineering und wann gerechtfertigt ist, ob der heutige Einsatz von Zend Framework 1 schon als kriminell gewertet werden kann und hören Wolfgang zu, wie er DevOps Anfängerfehler begeht indem ihm die Festplatte voll logs läuft. Bonus: Wie Wolfgang den ultimativen Reichtum mit seinem eigenen CMS zur dotcom Blase verpasst hat Unsere aktuellen Werbepartner findest du auf https://engineeringkiosk.dev/partners
Feedback an stehtisch@engineeringkiosk.dev oder via Twitter an https://twitter.com/EngKiosk Andy (https://twitter.com/andygrunwald) und Wolfgang (https://twitter.com/schafele) sprechen im Detail über: Sprungmarken(00:00) Intro (02:03) Vorstellung von Andy und Wolfgang (02:18) Vorstellung Andy Grunwald (02:36) Vorstellung Wolfgang Gassler (03:11) Side Project "inspect": Automatische Generierung einer RabbitMQ Architektur (04:23) Was ist RabbitMQ? (05:33) Side Project "sourcectl": Metrik Platform für Inner Source und Open Sorurce Projekte (06:32) sourcectl: Warum nutzt du RabbitMQ und keine Datenbank für das Message Queuing? (07:48) sourcectl: Monitoring (08:55) sourcectl: Verarbeitung von Messages (09:50) sourcectl: Infrastruktur- und Application-Setup (12:01) Was zur Hölle ist ein OMR (vs. ein ORM)? (12:53) Was ist Traefik: The Cloud Native Application Proxy? (17:45) Traefik Pro und Overengineering: Loadbalancing über mehrere Server und verteilte SSL Zertifikate (20:00) Side Project "F-Online": Für den Führerschein in Österreich lernen (21:34) F-Online: Hosting und Monitoring (25:27) Tipps um Kosten bei Google Cloud unter Kontrolle zu halten (26:01) F-Online: Infrastruktur- und Application-Setup (26:42) Wolfgangs Leiche im Keller: Zend Framework 1 auf (teils) aktueller PHP Version (29:00) F-Online: JavaScript Architektur (31:29) F-Online: APIs (32:40) F-Online: Datenbank (34:39) F-Online: Wie es aussehen würde, wenn es nochmal neu gebaut werden würde (37:22) Engineers over-engineeren von Haus aus (37:40) Side Project "the athlete" (39:02) Ziele, Motivation und die (eigenen) Erwartungen an Side Projects (40:28) Wolfgang erzählt vom Krieg: Sein eigenes Content Management System (42:37) Outro Erwähnte Side Projects
Erwähnte Technologien
Anderes
Erwähnte Personen
Hosts
Engineering Kiosk Podcast Anfragen an stehtisch@engineeringkiosk.dev | |||
| 09 Dec 2024 | #160 Grace Hopper mit UNMUTE IT | 00:11:27 | |
Grace Hopper mit dem UNMUTE IT Podcast. Im Engineering Kiosk Adventskalender 2024 sprechen befreundete Podcaster⋅innen und wir selbst, Andy und Wolfi, jeden Tag kurz & knackig innerhalb von wenigen Minuten über ein interessantes Tech-Thema. Unsere aktuellen Werbepartner findest du auf https://engineeringkiosk.dev/partners Das schnelle Feedback zur Episode: Links
Sprungmarken(00:00:00) Grace Hopper Hosts
Feedback
| |||
| 12 Dec 2024 | #163 Benevolent Dictator for Life (BDFL) | 00:13:18 | |
Benevolent Dictator for Life (BDFL): Was ist das? Wer ist das? Ist dies was gutes? Im Engineering Kiosk Adventskalender 2024 sprechen befreundete Podcaster⋅innen und wir selbst, Andy und Wolfi, jeden Tag kurz & knackig innerhalb von wenigen Minuten über ein interessantes Tech-Thema. Unsere aktuellen Werbepartner findest du auf https://engineeringkiosk.dev/partners Das schnelle Feedback zur Episode: Links
Sprungmarken(00:00:00) Benevolent Dictator for Life (BDFL) Hosts
Feedback
| |||
| 04 Feb 2025 | #181 Von Code zu Value: Wie Entwickler·innen Business-Mehrwert schaffen | 01:09:11 | |
Zu verstehen, wie eine Firma Geld verdient, ist Voraussetzung um Mehrwert zu schaffen Die wenigsten von uns arbeiten für Luft und Liebe. Mieten müssen gezahlt werden und Essen müssen wir auch alle. Deswegen gehen viele von uns in einem klassischen Angestelltenverhältnis arbeiten. In einem Angestelltenverhältnis gehören auch Gehaltserhöhungen und ab und zu auch mal eine Beförderung dazu. Einige Gehälter werden automatisch angepasst, wie z.B. bei einer Tariferhöhung. Andere müssen dafür ihren Wert, den sie zur Firma beitragen, erhöhen. Und um dies zu erreichen, sollte man wissen, wie die eigene Firma eigentlich Geld verdient und welche Herausforderungen das Business-Modell hat. Denn dies ist nicht immer auf den ersten Blick zu erkennen. In dieser Episode schauen wir uns mal drei Business-Modelle an, erklären, worauf diese basieren, welche Herausforderungen diese mit sich bringen, ob diese sich heutzutage noch lohnen und welchen Zwiespalt diese oft bei der Produktentwicklung erzeugen. Wir sprechen darüber, wie viel du den Arbeitgeber eigentlich kostet, wie viel Werbung heutzutage noch Wert ist, Warum sogenannte A-Kunden zwar viel Geld einbringen können, aber ein großes Risiko für eine Firma sind, warum das passive Einkommen bei deinem eigenen Software as a Service Produkt ein Irrglaube ist und wie du das neue Wissen über Business-Modelle für dich nutzen kannst, um deinen eigenen Wert zu erhöhen. Bonus: Wenn man mehr Geld möchte, muss man mehr Geld einbringen. Unsere aktuellen Werbepartner findest du auf https://engineeringkiosk.dev/partners Das schnelle Feedback zur Episode: Feedback
Links
Sprungmarken(00:00:00) Intro (00:01:24) Warum es wichtig ist, das Business-Modell zu verstehen (00:07:19) Info/Werbung (00:08:19) Cost per Click / Cost per Sale / Affiliate (00:20:11) Werbefinanzierte Services (00:38:49) Abo-Modelle oder X as a Service (00:56:20) Weitere Business-Modelle (00:59:02) Wie hilft mir, als Entwickler*in, dieses neue Wissen? Hosts
Feedback
| |||
| 08 Apr 2025 | #190 Mehr Meetings, mehr Macht? Der Weg zur Tech-Führungskraft | 01:26:53 | |
Wie kommt man eigentlich zu einer Führungsposition? Wie werde ich Engineering Manager? Diese Frage hat uns aus unserer Community erreicht. Ein Grund genug, sich diesem Thema in einer Episode zu widmen. Diesmal aber in einer leicht anderen Form. Die Frage stammt von Jan, einem Full-Stack Software-Engineer, der in Zukunft ins Engineering Management wechseln möchte. Mit ihm haben wir ein Vor-Interview geführt und ihn mit Fragen gelöchert. Wir gehen darauf ein, was wir eigentlich unter einer Führungskraft verstehen, welche Motivationen existieren um ins Engineering Management wechseln zu wollen, ob es dabei automatisch immer mehr Geld gibt, welche Herausforderungen beim Wechsel vom Engineer ins Management entstehen, wo der wechsel leichter ist, im eigenen Unternehmen oder durch einen Firmenwechsel, wie man sich einen klassischen Arbeitsalltag als Manager vorstellt und was man bereits heute tun kann, um für eine solche Position infrage zu kommen. Bonus: Ein Podcast wird zum Radio. Unsere aktuellen Werbepartner findest du auf https://engineeringkiosk.dev/partners Das schnelle Feedback zur Episode: Anregungen, Gedanken, Themen und WünscheDein Feedback zählt! Erreiche uns über einen der folgenden Kanäle …
Unterstütze den Engineering KioskWenn du uns etwas Gutes tun möchtest … Kaffee schmeckt uns immer
Links
Sprungmarken(00:00:00) Intro (00:01:08) Wie werde ich Engineering Manager*in? (00:03:33) Kontext, Erfahrung und Umgebung von Jan Semrau (00:07:06) Info/Werbung (00:08:06) Kontext, Erfahrung und Umgebung von Jan Semrau (00:19:21) Welches Level einer Führungskraft darf es denn sein? (00:26:48) Was ist deine Motivation? Warum möchtest du Führungskraft werden? (00:40:21) Ist es ein klassischer Karriereschritt, in eine Führungsrolle zu wechseln? (00:50:45) Was wurde bereits getan, um die Position eines Engineering Managers zu bekommen? (00:53:26) Ist es leichter, eine solche Stelle im eigenen Unternehmen oder bei einem Arbeitgeberwechsel zu bekommen? (01:04:35) Die Vorstellung eines klassischen Arbeitsalltags als Führungskraft (01:11:48) Was sind deine größten Herausforderungen beim Wechsel in eine Führungsrolle? Hosts
CommunityDiskutiere mit uns und vielen anderen Tech-Spezialist⋅innen in unserer Engineering Kiosk Community unter https://engineeringkiosk.dev/join-discord | |||
| 20 Dec 2024 | #171 Vergiss deine Maus mit Philipp Hoeler-Lutz von Click! Clack! Hack! | 00:05:36 | |
Warum du keine Maus mehr brauchst (und du deiner Tastatur mehr zutrauen solltest) mit Philipp Hoeler-Lutz von Click! Clack! Hack! Podcast. Im Engineering Kiosk Adventskalender 2024 sprechen befreundete Podcaster⋅innen und wir selbst, Andy und Wolfi, jeden Tag kurz & knackig innerhalb von wenigen Minuten über ein interessantes Tech-Thema. Unsere aktuellen Werbepartner findest du auf https://engineeringkiosk.dev/partners Das schnelle Feedback zur Episode: Links
Sprungmarken(00:00:00) Warum du keine Maus mehr brauchst Hosts
Feedback
| |||
| 01 Feb 2022 | #05 Team Lead - der einzige Ausweg | 00:40:12 | |
Engineering Manager oder Team-Lead: Eine Position die sehr motivierend, aber auch abschreckend wirken kann. Was erwartet einen? Was ist die Aufgabe einer Engineering Managerin? Wie verändert sich der Arbeitsalltag? Ist die Stelle überhaupt etwas für mich? Und was passiert, wenn ich doch lieber Software Entwickeln möchte? Gibt es einen alternativen Karrierepfad? All das und noch über viel mehr Erfahrungen sprechen Andy und Wolfgang in Episode 05 vom Engineering Kiosk. Bonus: Warum Andy Muskelkater im Arsch hat Unsere aktuellen Werbepartner findest du auf https://engineeringkiosk.dev/partners
Feedback an stehtisch@engineeringkiosk.dev oder via Twitter an https://twitter.com/EngKiosk Erwähnte Artikel
Bücher über das Engineering Management
Sprungmarken(00:55) Hörer Feedback (01:43) Wann bist du das erste mal in eine Teamlead-Stelle gerutscht? (03:15) Kann man bereits Aufgaben eines Teamleads übernehmen, ohne ein Teamlead zu sein? (04:18) Wie viel Zeit hast du mit Hands-On und wie viel mit People Management verbracht? (04:52) Wie lang warst du Individual Contributor bevor du Teamleiter wurdest? (05:42) Was hat sich am meisten an deinem Arbeitsalltag geändert? (09:22) Was ist ein 1 on 1 Meeting und warum ist dies sinnvoll? (13:27) Was ist eine gute Teamgröße für den Start als Engineering Manager? (14:50) Woher wusstest du, was du als neuer Engineering Manager machen musst? (20:51) Empfehlungen um die Entscheidung "Möchte ich den Job einer Engineering Managerin machen?" treffen zu können (24:25) Feedback-Loop eines Software Engineers und eines Engineering Managers (25:50) Was solltest du nicht wollen, wenn du ein Engineering Manager werden möchtest? (27:42) Ist es ab und zu notwendig, seine eigene Entscheidung im Team durchzusetzen? (28:36) Schwierige Konversationen als Engineering Manager (30:49) Ist es ein Rückschritt wenn man als Engineering Manager zurück zum Software Engineer wechselt? (34:42) Wie sieht ein möglicher Karriereweg aus, wenn der Engineering Manager-Weg nichts für mich ist? Hosts
Engineering Kiosk Podcast: Anfragen an stehtisch@engineeringkiosk.dev oder via Twitter an https://twitter.com/EngKiosk | |||
| 17 Dec 2024 | #168 Beyond Learning Budgets: Was Team-Entwicklung wirklich braucht | 01:04:48 | |
Wie entwickle ich meine Teammitglieder eigentlich weiter? “Wer nicht mit der Zeit geht, geht mit der Zeit”. Ob dieses Zitat nun von Schiller oder Stromberg kommt, spielt eigentlich keine Rolle. Einen Funken Wahrheit hat es trotzdem. Denn speziell in der sich schnell entwickelnden IT- und Software-Welt ist das Thema Leveling Up / Lifting Up / Skilling Up oder die ganz klassische Weiterbildung unabdingbar. Und dabei geht es nicht nur um das besser werden im eigentlichen Handwerk, wie der Softwareentwicklung, Data Science oder ähnlichem, sondern auch um die Persönlichkeit und Soft-Skills wie z.B. Kommunikation - Obwohl die Softskills heutzutage auch irgendwie die wahren Hardskills sind. Egal. Nun aber die große Frage: Wie hebe ich denn mein Team auf das nächste Level? Wie kann ich meine Mitarbeiter unterstützen, sich aktiv weiterzuentwickeln? Was kann ich als direkter Kollege tun? Denn dieses Thema betrifft nicht nur Leads, sondern auch dich als Individual Contributor ohne Personalverantwortung. Denn spätestens, wenn sich deine Managerin (noch) nicht um deine Weiterentwicklung kümmert, geben wir dir in dieser Episode ein paar Tipps, wie du auch deine Managerin in die richtige Richtung bewegen kannst. Denkt immer dran: “Wer nicht mit der Zeit geht, geht mit der Zeit”. Bonus: Etwas Streit ist gesund. Unsere aktuellen Werbepartner findest du auf https://engineeringkiosk.dev/partners Das schnelle Feedback zur Episode: Feedback
Links
Sprungmarken(00:00:00) Intro (00:01:15) Leveling up, Lifting up up und Skilling up: Warum es so relevant ist (00:04:54) Info/Werbung (00:05:54) Leveling up, Lifting up up und Skilling up: Warum es so relevant ist (00:16:25) Wo und wie fange ich als Lead mit dem Leveling up an? - Der Status Quo (00:29:14) Der Weiterentwicklungsplan und die Motivation (00:37:56) Die Macht der Delegation (00:46:15) Wie fördern Sie Innovation in Ihrem Team? (00:56:29) Side Projects in Firmen (01:02:16) Und wer denkt an die Leads selbst? Hosts
Feedback
| |||
| 19 Jul 2022 | #28 O(1), O(log n), O(n^2) - Ist die Komplexität von Algorithmen im Entwickler-Alltag relevant? | 00:55:33 | |
Beim Programmieren ist alles ein Algorithmus. Irgendwie zumindest. Doch wie misst man die Zeitkomplexität? Das ganze nennt sich Big-O-Notation, oder zu deutsch "Bachmann-Landau-Notation". Eigentlich ein recht trockenes Thema, doch auch irgendwie relevant in der heutigen Zeit von verteilten Systemen und großen Datenmengen. Doch was ist die Big-O-Notation? Was sagt sie aus? Wo kommt diese in der Praxis vor? Und inwieweit hat das ganze noch eine Relevanz in Zeiten von Cloud Computing und fast unbegrenzten Hardware-Ressourcen? Darum geht es in dieser Episode. Bonus: Wie Andy und Wolfgang in deutscher Grammatik belehrt werden, ob es OK ist in 1on1s zu fluchen und das Hash-Kollisionen mit der ganzen Sache zu tun haben. Feedback an stehtisch@engineeringkiosk.dev oder via Twitter an https://twitter.com/EngKiosk Unsere aktuellen Werbepartner findest du auf https://engineeringkiosk.dev/partners
Links
Sprungmarken(00:00:00) Intro (00:00:49) Intro: Feedback zur Episode #26 - Deutschland spricht schlecht Englisch (00:03:55) Intro: Feedback zur Grammatik - Der, die oder das Kommentar (00:06:05) Wer hört denn so alles das Engineering Kiosk? (00:07:09) Podcast-Player: Pocket Casts (00:08:32) Was sind die Sachen, die oft sinnvoll sind, du aber doch vergessen hast? (00:10:34) Das heutige Thema: Big-O Notation / Bachmann-Landau Notation (Zeitkomplexität von Algorithmen) (00:13:33) Warum ist die Big-O Notation / Bachmann-Landau Notation relevant (00:15:24) Wo war es das letzte mal wo dir die Big-O Notation vorgekommen ist (00:16:05) Was ist die Big-O Notation / Bachmann-Landau Notation? (00:20:59) Geben wir den best, average oder worst-case der Big-O Notation / Bachmann-Landau Notation an? (00:25:15) Konstanten können zur Vereinfachung einfach weggelassen werden (00:27:00) Big-O Notation bei redis: Die Story wie Andy damit in Berührung kam (00:31:16) Zeitkomplexität vs. Space-Complexity / Raumkomplexität: Zeit vs. Memory (00:32:58) Gibt es was besseres als O(1)? (00:34:26) Ist das setzen eines Keys in einer Hashmap immer O(1)? (00:40:03) Inwieweit kann man die Big-O Notation / Bachmann-Landau Notation auf Datenbanken mappen? (00:42:07) Wie relevant ist die Optimierung der Big-O Notation in Zeiten von Cloud und schnellen Servern eigentlich noch? (00:45:52) Batch-Processing vs. Streaming und die Optimierung von Algorithmen (00:48:49) Optimierungen von Algorithmen in JavaScript / auf Client-Seite (00:52:06) Optimierungen können auch schlecht sein bzw. schlecht aussehen (00:53:09) Outro mit Flachwitzen Hosts
Engineering Kiosk Podcast: Anfragen an stehtisch@engineeringkiosk.dev oder via Twitter an https://twitter.com/EngKiosk | |||
| 06 Sep 2022 | #35 Knowledge Sharing oder die Person, die nie "gehen" sollte... | 01:03:04 | |
Der Dauerbrenner in jedem Team: Wie bekommt man ordentliches Knowledge Sharing hin? Jeder kennt's: Die Kollegin ist im Urlaub und genau in dieser Zeit läuft was mit der einen Komponente schief, wo sie das größte Wissen darüber hat. Knowledge Sharing richtig hinzubekommen und das Wissen breit zu verteilen ist eine Mammutaufgabe. Aber eine wichtige, speziell in einer Remote-Umgebung. In dieser Episode gehen wir einige Mythen und Techniken durch, die euch beim Knowledge Sharing unterstützen können: Was ist der Bus-Faktor? Muss jeder im Team alles wissen und übernehmen können? Wobei kann Mob-Programming helfen? Was sind Guilds? Und kann man eigentlich zu viel lernen? Und noch viele weitere Themen. Bonus: Warum das C-Level-Management nicht im selben Flugzeug fliegen darf und ob Podcasts, die Mitarbeiter-Zeitung ablösen. 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 Unsere aktuellen Werbepartner findest du auf https://engineeringkiosk.dev/partners
Links
Sprungmarken(00:00:00) Intro (00:00:45) eBay Kleinanzeigen und Landing-Pages für Auto-Reifen (00:08:20) Das Thema der Episode: Knowledge Sharing (00:11:11) Der Bus-Faktor (00:13:01) Warum Knowledge Sharing wichtig für die Kollaboration und Produktivität ist (00:15:05) Mythos "Jeder im Team muss alles Wissen und übernehmen können" (00:18:05) Möglichkeiten zur internen Dokumentation: Design Documents / Request For Comments / Discover Documents / Architecture Decision Records und Zielgruppe der Dokumentation (00:24:43) Pair- und Mob-Programming (00:28:32) Guilds (Community of Practice), Support vom Management und Kosten von Knowledge Sharing (00:39:38) Interne Konferenzen, Vorträge halten und das Imposter-Syndrom (00:49:37) Lunch-Talks (00:52:21) Welcher Lerntyp bist du? - Viel lesen, Hands-On, Frontal-Lehre, Video-Tutorials, Audio - Das richtige Format (00:57:28) Kann man zu viel lernen? (00:59:09) Ist Knowledge-Sharing schwieriger in einem Remote-Umfeld? (01:02:21) Outro Hosts
Feedback (gerne auch als Voice Message)
| |||
| 13 Dec 2024 | #164 Suchalgorithmen: Lineare- und Binäre Suche & Indizes mit Stefan Macke vom IT Berufe Podcast | 00:14:48 | |
Suchalgorithmen: Lineare- und Binäre Suche mit Stefan Macke vom IT Berufe Podcast. Im Engineering Kiosk Adventskalender 2024 sprechen befreundete Podcaster⋅innen und wir selbst, Andy und Wolfi, jeden Tag kurz & knackig innerhalb von wenigen Minuten über ein interessantes Tech-Thema. Unsere aktuellen Werbepartner findest du auf https://engineeringkiosk.dev/partners Das schnelle Feedback zur Episode: Links
Sprungmarken(00:00:00) Suchalgorithmen: Lineare- und Binäre Suche Hosts
Feedback
| |||
| 08 Aug 2023 | #83 Transparenz im Tech-Leadership & Fehlerkultur: Wie weit kann ich gehen? | 01:04:24 | |
Die Fehlerkultur im Unternehmen, Transparenz in der Kommunikation und eine gewisse Distanz zum Team als Engineering Manager. Diese Episode ist eins unserer Sommergespräche, bei dem nur eine Seite die Fragen kennt. Wolfi stellt die Fragen: Was ist eine gesunde Fehlerkultur? Viele Unternehmen werben damit, eine gute Fehlerkultur zu haben, aus Fehlern zu lernen, Wachstumsmöglichkeiten zu bieten und Experimente zu ermöglichen. Doch ist das wirklich so? Werden Fehler transparent und weitreichend geteilt? In wirklich allen Bereichen und nicht nur im Engineering? Da trennt sich die Spreu vom Weizen. Was darf sich ein Engineering Manager erlauben, mit dem Team zu teilen und wie viel Transparenz ist gesund? Sollte alles direkt mit dem Team geteilt werden? Oder ist eine gewisse Distanz gesund? Wie schlimm ist es, wenn mal beim Feierabendbier etwas raus rutscht? Und kann es einem Lead auch mal schlecht gehen? All das in dieser Episode. Viel Spaß Bonus: Wolfgangs Bio Bike und seine CO2-Emissionen Unsere aktuellen Werbepartner findest du auf https://engineeringkiosk.dev/partners
Das schnelle Feedback zur Episode: 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
Sprungmarken(00:00:00) Intro (00:01:21) Kopf frei bekommen nach langer Arbeit (00:03:10) Fehlerkultur in Firmen und Fehler wiederholen (00:07:36) Incident Konferenz, Geld verbrennen und die Organisation muss daraus lernen (00:09:39) Fehlerkultur und Aufbereitung im Engineering Management beim Recruiting, bei Strategie und Priorisierung (00:18:33) Wie stellt man eine gute Fehlerkultur innerhalb eines Teams her? (00:20:54) Wie geht man mit seinen eigenen Fehlern im Team um? (00:24:48) Wie viele (eigene) negative Ansichten werden mit dem Team geteilt? (00:35:09) Entscheidungen zum positiven wenden, Emotional treiben lassen und distanzierter werden (00:37:06) Ein Feierabend-Bier zusammen trinken (00:41:53) Wie geht man mit schlechter Laune um? Wie viel Transparenz ist angebracht? (00:48:53) Restrukturierungen und die Change-Kurve (00:57:43) Wir müssen Montag mal reden Hosts
Feedback (gerne auch als Voice Message)
| |||
| 19 Sep 2023 | #89 Die Klimakrise und Green IT: unser Einfluss über Hardware, Farben, Web-Performance und Green-Hosting mit Christian Schäfer | 01:16:03 | |
Green IT und die CO2-Emissionen durch die IT, das Internet und die Software-Entwicklung Die Klimakrise ist real. Damit wir das ganze Problem in den Griff bekommen, muss jeder mit anpacken. Doch wie viel Einfluss hat die IT mit der Hardware, dem Internet, auf der Client- und Serverseite? Darüber sprechen wir in dieser Episode. Wie lange solltest du deine Hardware nutzen? Was für eine Rolle spielen Display-Technologien wie Oled und LCD? Sind performante Websites mehr Eco-Friendly? Wie sieht es mit Cloud-Infrastruktur, Build- und CI-Pipelines aus? Wie berechnet man die CO2-Emissionen von Gigabit-Datentransfer? Welche ist die grünste Programmiersprache? Das und noch viel mehr besprechen wir mit unserem Gast Christian "Schepp" Schaefer, der sich mit diesem Thema auseinandergesetzt hat. Bonus: Wo die dreckigsten Industrieunternehmen Deutschlands stehen. Das schnelle Feedback zur Episode: 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
Sprungmarken(00:00:00) Intro (00:01:16) Dirty Thirty, Green IT und Vorstellung von Christian "Schepp" Schaefer (00:06:00) Warum liegt dir das Thema Green IT und CO2-Emissionen von Websiten am Herzen? (00:07:14) Welche Rolle spielt die IT bei den CO2-Emissionen? (00:07:14) Info/Werbung (00:16:06) Welche Komponenten spielen bei Green IT eine Rolle? (00:17:58) Client-Hardware: Herstellung, Nutzungsdauer und Erneuerung (00:22:56) Client-Hardware: Bildschirme und Display-Technologien (00:27:15) Website-Frontend: Farbwahl, Web-Performance, Daten-Volumen und Energie-Verbrauch der Runtime (00:33:20) Kompensation von CO2 durch Bäume (00:35:36) Bekommt Website-Performance durch Green IT einen höheren Stellenwert? (00:39:46) Die meist gemachten Performance-Fehler: Asset-Größe, Bildformate und Kompressionen (00:43:40) Serverseite: Green-Hosting, Carbon Footprint auf GCP, Server erneuern, ARM Prozessoren und Workloads (01:02:26) Build- und CI/CD Pipelines verbrauchen auch Energie (01:03:37) CO2-Emissionen pro Einwohner in China und Deutschland (01:05:01) Effizienz und Energieverbrauch von Programmiersprachen (01:09:59) Was kann ich tun, um zu helfen? Hosts
Feedback (gerne auch als Voice Message)
| |||
| 05 Jul 2022 | #26 My English is not the yellow from the egg - Arbeiten in internationalen Teams | 01:06:10 | |
Der Großteil der IT-Ressourcen wie Dokumentationen, Websites, Präsentationen in Englisch, doch was ist wenn man selbst von sich sagt "My english is not the yellow from the egg"? Diese Episode dreht sich ganz um die englische Sprache und das Arbeiten in internationalen Teams: Welche Hürden haben die meisten deutschen in Bezug auf die englische Sprache? Wie kann man diese überkommen und sicherer mit der englischen Sprache werden? Und was passiert, wenn ich auf der Arbeit auf einmal Englisch sprechen muss? Wie verändert sich mein Arbeitsumfeld, wenn das Team international zusammengestellt ist? Was muss ein Arbeitgeber im Kopf behalten, wenn sich das Team international entwickeln soll? Und wie verhält sich aktuell die Remote-Arbeit mit der ganzen Thematik? All das und noch mehr in dieser Episode. Bonus: Russische Software-Code-Kommentare, die Vertonung von Hollywood Filmen und schnelle deutsche ALDI Kassierer. Feedback an stehtisch@engineeringkiosk.dev oder via Twitter an https://twitter.com/EngKiosk Unsere aktuellen Werbepartner findest du auf https://engineeringkiosk.dev/partners
Links
Sprungmarken(00:00:00) Intro (00:00:46) Ein Dankeschön an unsere Hörer und Deutschlernen mit dem Engineering Kiosk (00:04:52) Das heutige Thema: Das Arbeiten in internationalen Teams (00:05:58) Ein Team, alle deutschsprachig, ein internationale Person: Welche Sprache soll gesprochen werden? (00:13:00) Source-Code-Kommentare in Russisch (00:14:42) Offizielle Team- und Firmen-Sprache (00:16:49) Support von der Firma zum lernen der Firmensprache (00:17:18) Ohne die deutsche Sprache ist man in Deutschland aufgeschmissen (00:23:26) Englisch in der Universität (00:25:06) Englisch als Chance: Der Lern-Einstieg und Übung macht den Meister (00:29:51) Als nicht deutscher in einer deutschen Gruppe: Was kann dies für Folgen haben? (00:35:41) Hören wir mehr Englisch im Alltag und um uns herum? (00:37:54) Wie ändert sich die Softwareentwicklung selbst und im Team in einem internationalen Team? (00:44:42) Die Entwicklung von internationalen Produkten erfordern internationale Teams (00:47:08) Hürden für den Arbeitgeber bei der Einstellung von internationalen Leuten (00:52:34) Schwierigkeiten bei der Zusammenarbeit in einem internationalen Team (00:58:23) Erste Erfahrungen in internationalen Teams in Open Source (01:01:23) Remote-Work fördert internationale Arbeitsumgebungen (01:04:02) Outro Hosts
Engineering Kiosk Podcast: Anfragen an stehtisch@engineeringkiosk.dev oder via Twitter an https://twitter.com/EngKiosk | |||
| 20 Dec 2022 | #50 DEI erhöht Innovation und den finanziellen Erfolg | 00:57:30 | |
Diversity: Das Thema mit hoher Relevanz - Nicht nur in der Gesellschaft, sondern auch in Firmen und Tech-Teams. Forbes berichtet, dass diverse Firmen innovativer und erfolgreicher sind. Doch was ist Diversity eigentlich? Irgendwie wird es überall erwähnt und ist stets präsent. In dieser Episode klären wir was Diversity und DEI ist, warum es wichtig ist, darüber zu sprechen, welchen Effekt es auf Teams haben kann, wie nützlich Frauenquoten sind, wie der Mangel an weiblichen IT-Fachkräften sich auf das Thema auswirkt, was es mit der inklusiven Sprache aufsich hat und wo der Unterschied zwischen Diversität, Inklusion und Gleichberechtigung ist. Bonus: Ob Harvard und Stanford inklusiv sind und was Schokoküsse mit dem Thema zu tun haben. 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 Unsere aktuellen Werbepartner findest du auf https://engineeringkiosk.dev/partners
Links
Sprungmarken(00:00:00) Intro (00:00:38) 50 Episoden und Wolfgangs Wunsch-Thema Diversity (00:01:40) Respekt vor Gesprächen über Diversity (00:04:05) Entwicklungen von Diversity in den News bei Basecamp, Slack und in den USA (00:07:03) Warum können/sollten zwei weiße alte CIS Männer über Diversity sprechen? (00:09:32) Was ist Diversity? (00:15:28) Was ist Inklusion in DEI und wo ist der Unterschied zu Diversity? (00:19:21) Was ist Gleichberechtigung in DEI? (00:21:05) Warum ist es wichtig, über dieses Thema zu sprechen? (00:26:47) Der Effekt eines weiblichen Teammitglieds in einem männlichen Team und der Effekt von Inklusion mittels Sprache (00:32:45) Der Mangel an weiblichen IT-Fachkräften und anonyme Bewerbungen (00:40:21) Diversität in der Personalabteilung und Teams mit Überhang zu einem Geschlecht (00:42:52) Tech-Events nur für Frauen (00:45:04) Diversity-Quoten (00:49:26) Inklusive Sprache (00:54:14) Diversity ist noch mehr: Code of Conduct, Pronomen, Gendern (00:54:41) Nummer eins Tipp um die Diversity im Team zu erhöhen (00:56:01) Outro: Zusammenfassung, Feedback und Bewertungen Hosts
Feedback (gerne auch als Voice Message)
| |||
| 28 Mar 2023 | #64 Infrastruktur-Bingo: Forward-, Reverse-, SOCKS-Proxy, Load Balancing und gibt es einen Unterschied zwischen Load-Balancer und Reverse-Proxy? | 00:56:57 | |
Forward-Proxy, Reverse-Proxy, Bastion-Host, Load Balancer, SOCKS5-Proxy, Edge-Router, Zero-Trust, Geo-Balancing, ... Haltet eure Buzzword-Bingo-Karten bereit. In dieser Episode beschäftigen wir uns mit der Frage "Was ist eigentlich der Unterschied zwischen einem Loadbalancer und einem Reverse Proxy?". Klingt einfach zu beantworten, ist es aber nicht. Zwei (oder sogar mehr) Welten treffen da aufeinander. Um der Antwort näher zu kommen, steigen wir Tief in das Thema ein und klären was eigentlich ein normaler Proxy ist, wo der Unterschied zu einem Reverse Proxy ist, was ein SOCKS5-Proxy kann, wozu Proxies heutzutage eingesetzt werden, was ein Bastion Host ist, wozu Edge Nodes gut sind, was Ihr für Tools einsetzen könnt und klären am Ende auch die Frage, was denn nun eigentlich der Unterschied zu einem Load Balancer ist. Bonus: Ob Wein durch Schläuche schmeckt und was das Düsseldorfer Altbier mit Proxies zu tun hat. Unsere aktuellen Werbepartner findest du auf https://engineeringkiosk.dev/partners
Das schnelle Feedback zur Episode: 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
Sprungmarken(00:00:00) Intro (00:00:50) Unterschied zwischen Loadbalancer und Reverse Proxies, störende und hippe Proxies und deren Relevanz (00:06:31) Was ist ein (normaler) Proxy? (00:13:52) Was ist ein Bastion Host? (00:16:58) SOCKS5-Proxies (00:19:59) Proxy-Anwendungsfall: Hotel W-LAN und die Deutsche Bahn (00:21:14) Was ist ein Reverse Proxy? (00:27:28) Anwendungsfälle für Reverse Proxy (Caching, Load balancing, SSL Terminierung) (00:31:43) Wer braucht einen Reverse Proxy? (00:35:49) Migration von Bildern in die Cloud mit Hilfe eines Reverse Proxies (00:40:41) Was sind Edge Nodes? (00:42:37) Was sind die Nachteile von (Reverse) Proxies? (00:45:58) Neue Namen und alte Methoden: Welches Tooling gibt es auf dem Markt? (00:47:09) Was ist der Unterschied zwischen einem Reverse Proxy und einem Load Balancer? (00:52:31) Anwendungsfall Zero-Trust mit Proxies (00:54:50) Die Kunst: Grundlagen kennen und Marketing-Lingo entschlüsseln Hosts
Feedback (gerne auch als Voice Message)
| |||
| 22 Oct 2024 | #146 Warum ist Doom so faszinierend für die Software-Entwicklung? | 00:58:22 | |
Doom - Das Spiel und warum es ein Engineering Meisterwerk ist Das Spiel Doom beschäftigt viele Software-Entwickler*innen auch noch 31 Jahren nach seiner Veröffentlichung im Jahre 1993. Die Frage “Can it run Doom?” ist allgegenwärtig. Es ist eine Art Sport geworden, das Spiel auf jede Art von Device zu portieren. Doom läuft inzwischen auf einem John Deere Trecker, einem Satelliten und einem digitalen Schwangerschaftstest. Doch was macht dieses Spiel so interessant? Warum wird genau dieses Spiel für die Portierung genutzt? Welche bahnbrechenden Implementierungsdetails haben John Carmack, John Romero und das Team verbaut? Das war meine Ausgangsfrage. Das Resultat? Ein tiefes Loch voller Wow und WTF-Momente. Und diese Podcast-Episode. Es geht um Zufallszahlengeneratoren, Grafik-Engines, Doom-Fun-Facts, Doom Forks und wie du deinen eigenen Doom-Port erstellen kannst. Bonus: Ist es eine Herausforderung ein Device zu finden, das Doom nicht laufen lassen kann? Unsere aktuellen Werbepartner findest du auf https://engineeringkiosk.dev/partners
Das schnelle Feedback zur Episode: Feedback
Gerne behandeln wir auch euer Audio Feedback in einer der nächsten Episoden, einfach die Audiodatei per Email an stehtisch@engineeringkiosk.dev. Links
Sprungmarken(00:00:00) Die Faszination um das Spiel Doom (00:04:20) Werbung/Info (00:05:20) Was ist Doom? (00:09:21) Was ist Doom technisch? (00:12:15) Architektur: Trennung von Engine und Daten (00:14:58) Determinismus und der Zufall (00:21:07) Aufzeichnung der Benutzer-Eingaben und Multiplayer (00:30:19) Grafik-Engine: Visible Surface Determination, Raytracing und Binary Space Partitioning (00:45:30) Doom-Ports und die Weiterentwicklung des Spiels (00:53:12) Can it run Doom? Hosts
Feedback
| |||
| 15 Nov 2022 | #45 Datengetriebene Entscheidungen und der perfekte Dashboard Stack | 00:51:08 | |
Datengetriebene Entscheidungen oder auch "Glaube keiner Statistik, die du nicht selbst gefälscht hast". Entscheidungen treffen und die nächsten Schritte planen ist nicht einfach. Relevante Daten können einem die Entscheidung erleichtern. Doch wie fängt man mit datengetriebenen oder daten-unterstützenden Entscheidungen eigentlich an? Woher weiß man, ob man die richtigen Daten hat? Was wird zur entsprechenden Aufbereitung benötigt und wie kann ich die Daten entsprechend visualisieren? In dieser Episode geben wir einen Einblick in das Feld der datengetriebenen Entscheidungen. Wir beantworten, warum Tortendiagramme blödsinn sind, wie die Architektur aussehen kann, ob das Bauchgefühl überhaupt noch relevant ist und warum man nicht mehr sein eigenes JavaScript Frontend mehr bauen muss. Bonus: Was warmes Bier mit Husten zu tun hat und wie das Oktoberfest unsere Podcast-Statistiken beeinflusst. 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 Unsere aktuellen Werbepartner findest du auf https://engineeringkiosk.dev/partners
Links
Sprungmarken(00:00:00) Intro (00:01:00) Cloud vs. On-Premise im Wartungsfenster Podcast (00:04:32) Das heutige Thema: Datengetriebene und Daten unterstützende Entscheidungen (00:05:16) Was verstehen wir unter datengetriebenen Entscheidungen? (00:08:18) Gefälschte Statistiken und die richtige Daten-Visualisierung (00:10:25) Wer hat Zugang zu den Daten und wie sieht die Daten-Transparenz aus? (00:14:05) Muss jeder Mitarbeiter SQL-Abfragen erstellen können? (00:15:55) Die Architektur für datengetriebene Entscheidungen (00:18:53) Pre-Processing, OLAP, OLTP und Datenbank-Normalformen (00:21:46) Was ist Clickhouse und welche Tools gibt es auf dem Markt? (00:22:59) Sind Tortendiagramme Blödsinn? (00:23:46) Die Visualisierung: Wie finde ich heraus, welche Fragen wir eigentlich aus den Daten beantwortet haben wollen? (00:25:53) Wie verwende ich Datenvisualisierung, ohne ein eigenes Team? (00:28:30) Schnelle Dashboards und Performance von Queries (00:29:28) Was ist bei Datenbanken in Bezug auf Analytics optimiert? (00:31:03) Muss man noch sein eigenes Dashboard-Frontend mit JavaScript bauen? (00:36:21) Welche Tipps würdest du Neulingen zur Dashboards-Erstellungen geben? (00:39:17) Ist das Bauchgefühl noch relevant? (00:41:30) Ab wann sind Daten aussagekräftig (statistisch signifikant)? (00:45:51) Welche Firmen sind Vorreiter im Bereich datengetriebene Entscheidungen? (00:47:29) Kann man zu datengetrieben sein? (00:48:21) Woher weiß ich, auf welche Daten ich gucke? (00:50:10) Outro: Podcast-Statistiken Hosts
Feedback (gerne auch als Voice Message)
| |||
| 13 Feb 2024 | #110 OKRs und Beyond: Agile Unternehmensführung mit Marco Alberti von Murakamy | 01:18:03 | |
Objectives & Key Results (OKRs): Die Wunderwaffe für die Zielsetzung? Google, Adobe und die Gates Foundation schwören auf OKRs als Methode für die Zielsetzung, die Teams beim Festlegen messbarer Ziele unterstützen sollen. Doch was ist wirklich dran am Hype? Ist es wirklich so gut wie geschnitten Brot? Wir sind der Sache auf den Grund gegangen und haben mit Marco Alberti von Murakamy über das Thema gesprochen. Mit seiner Firma berät er Firmen jeglicher Größe zum Thema Vision, Mission und Zielsetzung durch OKRs. Mit ihm klären wir, was OKRs eigentlich sind, wie das ganze zu anderen agilen Methoden wie Scrum und Kanban steht, wie OKRs ein Unternehmen verändern können, ob die AI zur Erstellung von Zielsetzung hilfreich ist, was gute und schlechte Objectives sind und wie man mit Hilfe von OKRs wieder in die Sommer-Badehose passt. Bonus: Wieso es OK ist, SAP mit OKRs zu vergleichen. Unsere aktuellen Werbepartner findest du auf https://engineeringkiosk.dev/partners
Das schnelle Feedback zur Episode: 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
Sprungmarken(00:00:00) Objective & Key Results mit Marco Alberti (00:05:09) Wie verhält sich OKRs im Vergleich zu Scrum und Kanban? (00:10:05) Was sind Objective & Key Results? (00:13:35) Ein praktisches Beispiel für eine Objective mit Key Results (00:17:28) Wer setzt die OKRs im Unternehmen? Wie kommen diese zu mir? (00:23:42) Planungsaufwand und Planungshorizont von OKRs (00:26:30) OKRs für Supporting Functions (00:33:51) OKRs im Vergleich mit anderen Modellen (V2MOM, etc.) (00:37:06) OKRs in traditionellen Industrien (00:42:27) Messbarkeit von OKRs und ambitionierte Ziele (00:47:25) OKRs und die Firmenkultur (00:52:23) Objectives und Key Results mit Hilfe der AI formulieren (00:56:41) Definition seiner Ziele mit Abhängigkeiten zu anderen Teams (01:00:38) Änderung im Unternehmen bei der Einführung von OKRs (01:12:18) Marcos Buch-Empfehlungen Hosts
Feedback (gerne auch als Voice Message)
| |||
| 01 Mar 2022 | #08 Vergiss doch Datenbanken! | 00:52:47 | |
Datenbanken, besonders relationale Datenbanken und im Web ganz besonders MySQL. Jeder kennt sie, jeder nutzt sie, aber keiner gibt zu diese zu nutzen da sie uncool und alt sind und sowieso nicht skalieren. Wolfgang und Andy sprechen ein wenig über dieses Thema: Wie man seine eigene SQL Datenbank schreibt, was der Unterschied von Row-Based und Statement-Based Replication ist, warum simple Dateien oft besser sind als eine Datenbank, ob sqlite helfen kann und MongoDB die Lösung ist, wie Facebook, Booking und GitHub MySQL betreiben, ob PostgreSQL wirklich was kann und welche Schritte ihr unternehmen könnt, um eure Datenbank zu tunen. Bonus: Ob Wolfgang Mickey Krause kennt und ob er ein erfolgreicher MySQL Buchautor war. Feedback an stehtisch@engineeringkiosk.dev oder via Twitter an https://twitter.com/EngKiosk Unsere aktuellen Werbepartner findest du auf https://engineeringkiosk.dev/partners
Links
Erwähnte Personen
Sprungmarken(00:00) Intro (00:15) Wolfgang und Apres-Ski (02:52) Wie programmiert man seine eigene Datenbank? (07:24) Was passiert, wenn eine SQL-Query die Datenbank erreicht? (10:02) Die Schwierigkeiten, wenn man seine eigene Datenbank programmiert (12:35) Sind Dateien besser als Datenbanken? (18:00) Keine Netzwerk-Verbindungen dank sqlite? (20:40) Was ist sqlite? (22:20) Aussprache von sqlite und SQL und woher es kommt (23:33) Wie kam MySQL und MariaDB zu ihrem Namen? (24:17) Was empfiehlst du für kleine Apps? MySQL oder sqlite? (25:06) Replikation von sqlite Daten (26:02) Unterschied zwischen Row- und Statement-Based Replication (27:56) Wie viel Requests kann man mit einer MySQL-Node bedienen? (29:35) Buchempfehlung: Designing Data-Intensive Application (31:42) Was tun, wenn ich Probleme mit MySQL-Performance hab? (33:16) MySQL bei Facebook (36:35) PostgreSQL, der andere Kandidat auf dem Spielfeld (38:33) Tooling um MySQL: ProxySQL und Vitess (43:38) MySQL Performance-Tipps vom Buch-Autor Wolfgang (50:33) Outro Hosts
Engineering Kiosk Podcast: Anfragen an stehtisch@engineeringkiosk.dev oder via Twitter an https://twitter.com/EngKiosk | |||
| 02 Jul 2024 | #130 Wie gutes UX-Design entsteht mit Robin Titus | 01:03:16 | |
Wie technisch sollten UI und UX-Engineers eigentlich sein? Dass gutes Design und eine gute User Experience über den Erfolg oder Misserfolg eines Produktes entscheiden kann, haben Plattformen wie AirBnB oder Docker erfolgreich gezeigt. Denn irgendwie hat jedes Produkt, egal ob Hard- oder Software, eine Oberfläche und Bedienelemente. Deswegen steigen wir mit dieser Episode mal in die Felder User Interface (UI) und User Experience (UX) ein. Wir klären, was es eigentlich ist und wo der Unterschied ist, wie UI und UX-Design eigentlich in einem hoch-technischen Produkt, wie zB einem Datenbank-Hoster, aussehen kann, welchen signifikanten Einfluss gutes UX haben kann, was Primary and Secondary Actions, die first mile of Product, Design Thinking oder Double Diamond ist, wie man eine gute Product Engineering Culture aufbaut, aber auch worauf es bei der Zusammenarbeit beim Produkt-Trio (Produkt Manager, Engineer und Designer) ankommt. Bonus: Culture Eats Process for Breakfast Das schnelle Feedback zur Episode: Feedback
Gerne behandeln wir auch euer Audio Feedback in einer der nächsten Episoden, einfach die Audiodatei per Email an stehtisch@engineeringkiosk.dev. Links
Sprungmarken(00:00:00) Intro (00:01:14) Gewinnspiel We Are Developers Tickets (00:01:38) UI und UX mit Robin Titus (00:08:14) Info/Werbung (00:09:19) UI und UX mit Robin Titus (00:18:44) Unterschied UX Design und UX Research (00:21:55) UX in hochtechnischen Produkten und die First Mile (00:28:32) Der Impact vom Backend auf die User Experience (00:31:56) Das Produkt-Trio (00:42:27) Produktkultur (00:48:41) Wie technisch müssen Designer sein? (00:54:25) Nicht jede Firma ist Apple oder Airbnb Hosts
Feedback
| |||
| 20 Feb 2024 | #111 Side-Projects: Zwei Entwickler overengineeren einen Podcast | 01:24:09 | |
Wie sieht eigentlich der Tech-Stack vom Engineering Kiosk selbst aus? Ein Side-Projekt startet man üblicherweise mit einer Domain. Erst kauft man die Domain und danach überlegt man sich, was man eigentlich machen will. Über Zeit entwickelt sich das Projekt, man holt mehr Technologien rein und experimentiert. Genau so war es auch mit dem Engineering Kiosk Podcast. Nur mit dem Unterschied, dass auch etwas Hardware angeschafft werden musste. Auf unserem letzten Community-Treffen haben wir die Frage nach unserem Tech-Stack vom Podcast bekommen. In dieser Episode führen wir euch mal in den Maschinen-Raum von unserem Audio-Format und zeigen euch, was alles notwendig ist, um dieses Hörerlebnis für euch zu erzeugen. Viel Spaß! Unsere Hardware:
Unsere Software:
Bonus: Was man alles so über die Zeit ansammelt … Unsere aktuellen Werbepartner findest du auf https://engineeringkiosk.dev/partners
Das schnelle Feedback zur Episode: 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
Sprungmarken(00:00:00) FOSDEM, back to the roots und der Tech-Stack vom Engineering Kiosk (00:04:56) Der Start: Domain ohne Website, aber ein Konzept (00:09:59) Unsere Hardware: Mikrofone, Aufnahmegeräte, Licht und mehr (00:23:15) Unsere Software: Audio-Editing, Transkripte, Skripte, Website, Hostung und mehr (00:47:50) Social Media und Marketing-Aktivitäten (00:57:29) Gäste und Interview-Episoden, sowie Checklisten, Templates und Milestone Reviews (01:08:12) Die Zukunft: Dinge, die wir noch vorhaben Hosts
Feedback (gerne auch als Voice Message)
| |||
| 06 Aug 2024 | #135 Design Documents & RFCs: Der Weg zu besserer Software-Architektur | 01:00:06 | |
Design Documents und Request for Comments (RFCs): Die Engineering Art der Planungsphase Wir alle haben schon mal von einer Planungsphase gehört, um ein neues Projekt zu starten, und denken dabei an aufgeblasene Prozesse und lange Wasserfall-Diagramme. Und das Engineering-Team fragt sich oft: Wann kommen wir endlich mal zu den Details? Da kommen die Begriffe Design Documents und Request for Comments (RFCs) ins Spiel. Das doofe nur … Jemand muss diese Dokumente auch schreiben. Und da sind wir bei gleich zwei von Andy's Lieblingsthemen: Schreiben und Design Docs. Wir klären, wozu Design Documents eigentlich gut sind, worauf es ankommt, wo der Unterschied zu RFCs ist, ob das ganze nicht ein riesiger Wasserkopf ist, um einfach Dinge auf die Straße zu bringen und welche Kultur das ganze benötigt. Viel Spaß. Bonus: Wer schreibt, der bleibt. Unsere aktuellen Werbepartner findest du auf https://engineeringkiosk.dev/partners
Das schnelle Feedback zur Episode: Feedback
Gerne behandeln wir auch euer Audio Feedback in einer der nächsten Episoden, einfach die Audiodatei per Email an stehtisch@engineeringkiosk.dev. Links
Sprungmarken(00:00:00) Intro (00:01:15) Welche Relevanz haben Design Documents? (00:07:25) Was ist ein Design Document? (00:15:23) Wer schreibt das Design Document? Wie startet man? (00:21:26) Mein Design hat Abhängigkeiten zu anderen Teams (00:26:59) Design Document als zeitlicher Overhead (00:31:56) Wie detailliert und lang soll ein Design Document sein? (00:41:12) Request for Comments (RFCs) als ursprung für Design Documents (00:50:10) Schreibtipps für dein erstes Design Document (00:56:13) Box ticking exercise und Entscheidungs-Fatigue Hosts
Feedback
| |||
| 26 Dec 2023 | #103 Plattform Engineering und Interne Developer Plattformen mit Puja Abbassi | 01:15:42 | |
Plattform Engineering, Interne Developer Plattformen und das Product-Mindset: 2023 wird als “Das Jahr der Effizienz” bezeichnet. Viele Firmen schauen sich im Detail an, wie die Arbeit der eigenen Software-Entwicklungsteams effizienter gestaltet werden kann. Die Bereiche Infrastruktur, Cloud, Build Pipelines, Deployment und Co stehen oft im Mittelpunkt der Frage “Was kann optimiert werden, damit wir uns schneller bewegen?”. In der Regel dauert es nicht lange, bis die Buzzwords “Interne Developer Plattformen”, “Developer Experience” und “Plattform Engineering” fallen. Doch worum geht es eigentlich beim Plattform Engineering? Was ist eine interne Developer Plattform? Genau darüber sprechen wir mit unserem Gast Puja Abbassi. Wir klären, was das alles ist, welche Probleme eigentlich gelöst werden sollen, wie eine erfolgreiche Plattform aussieht, was klassische Fallstricke sind, ab wann sich die ganze Sache eigentlich lohnt und noch vieles mehr. Bonus: Was ist FinOps? Unsere aktuellen Werbepartner findest du auf https://engineeringkiosk.dev/partners
Das schnelle Feedback zur Episode: 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
Sprungmarken(00:00:00) Intro und unser Gast Puja Abbassi (00:05:00) Was ist Plattform-Engineering? Was ist eine interne Developer Plattform? (00:16:18) Sind die Konsolen der Hyperscaler oder Kubernetes nicht schon eine Plattform? (00:25:28) Platform Engineering bedarf Software-Engineering (00:30:10) Ab wann lohnt sich Platform Engineering und was muss in der Firma gegeben sein? (00:41:34) Ist Spotify's Backstage nicht eine fertige Plattform? (00:50:16) Product Mindset beim entwickeln einer Plattform (00:56:31) Plattform Engineering ist ein Fokus der CNCF und Standardisierung Hosts
Feedback (gerne auch als Voice Message)
| |||
| 26 Nov 2024 | #151 Räumliche Indexstrukturen: Grundpfeiler in Geo-Systemen, Games und Machine Learning | 01:02:10 | |
Mit Hilfe von Spatial Index-Strukturen einen schnellen Zugriff auf Geodaten gewährleisten Die Welt ist groß und wird weiter digitalisiert. Um alles Auffindbar und durchsuchbar zu machen, werden Geodaten von alles und jedem festgehalten: Nicht nur Längen- und Breitengrade (wenn es sich um die Erde handelt), sondern auch Höhe bzw. Tiefe, Zeit und etliche andere Metadaten. Diese Art von Daten nennen sich Spatial-Data oder auch Geospatial-Data. Um in großen Datenmengen einen schnellen Zugriff zu gewährleisten, verwenden Softwaresysteme, wie zB Datenbanken, Indexstrukturen, auch Indizes, genannt. Eine zusätzliche Form der Speicherung durch die Nutzung hoch optimierter Datenstrukturen. Welche Indexstrukturen werden eigentlich bei Geospatial-Daten genutzt? Das ist das Thema dieser Episode. Wir sprechen über die Anwendungsfälle von Geospatial-Data, warum eine klassische Struktur wie ein B-Baum nicht für diese Art von Daten geeignet ist, was Gridfiles, Quadtrees, KD-Trees, R-Trees und Geohashing ist und wie diese funktionieren, ob all dies selbst implementiert werden muss oder wir auf bereits existierende Datenbanksysteme zurückgreifen können und klären, was der Fluch der Dimensionalität ist und was dies mit dem Thema AI zu tun hat. Bonus: MongoDBs Marketing-Initiative auf Basis von Spatial-Index-Strukturen. Unsere aktuellen Werbepartner findest du auf https://engineeringkiosk.dev/partners Das schnelle Feedback zur Episode: Feedback
Links
Sprungmarken(00:00:00) Indizes für Geospatial Data (00:02:54) Was ist Spatial bzw. Geo Spatial? (00:05:06) Info/Werbung (00:06:06) Was ist Spatial bzw. Geo Spatial? (00:17:43) Grid Files (00:21:46) KD Trees und Quad Trees (00:31:43) R-Tree (00:41:29) PostGIS, GeoHash und die Z-Kurve (00:51:26) Welche Libraries kommen zum Einsatz? Hosts
Feedback
| |||
| 10 Sep 2024 | #140 Tech-Leadership: Die technische Vision als Leitfaden für Teams | 01:00:11 | |
Eine technische Vision für die technische Leitlinie. Klare Regeln, eine klare Richtung, in die dein Team läuft, sind essentiell, um schnelle Entscheidungen ohne Streit zu treffen. Jedes Software-Team hat als Ziel, sich schnell zu bewegen, dynamisch und agil zu sein. Doch dafür sind ein paar Leitlinien notwendig und die Richtung muss für alle klar sein. Doch wie macht man dies? Das Stichwort der Stunde heißt “technische Vision”. Wir klären was das für eine Vision ist, wo der Unterschied zur Produkt-Vision ist, warum diese Vision auf Team- oder auf Firmenebene gesetzt werden kann, wer diese setzen sollte, untermalen das ganze mit ein paar griffigen Beispielen, setzen verwandte Hilfsmittel wie das Techradar und ein Engineering Manifesto in Relation und geben euch eine kleine Anleitung wie man eine technische Vision erstellt. Bonus: Wie Berater mit der Antwort “It depends” immer wieder punkten. Das schnelle Feedback zur Episode: Feedback
Gerne behandeln wir auch euer Audio Feedback in einer der nächsten Episoden, einfach die Audiodatei per Email an stehtisch@engineeringkiosk.dev. Links
Sprungmarken(00:00:00) Streit auf LinkedIn (00:03:08) Was ist eine technische Vision? (00:04:16) Werbung/Info (00:05:16) Was ist eine technische Vision? (00:17:52) Product-Vision vs. technische Vision (00:26:06) Wird Innovation durch eine technische Vision verhindert? (00:31:05) Wie kommt man zu einer technischen Vision? (00:38:01) Reichweite und Entscheidungsfindung einer technischen Vision (00:45:18) Woher weiß ich, dass ich eine gute technische Vision habe? (00:51:28) Das Problem mit dem Wort "technische Vision" Hosts
Feedback
| |||