
Sign up to save your podcasts
Or


Ist GitHub Copilot (und AI) wirklich dein fehlender Partner beim Pair-Programming?
AI und speziell auf die Programmierung trainierte Modelle sind angetreten, um die Welt, wie wir programmieren, zu verändern. Doch halten diese auch die Versprechen? GitHub Copilot ist der Platzhirsch im Markt. Viele Software-Entwickler*innen haben den Service bereits ausprobiert. Manche schwören darauf und wollen nicht mehr ohne. Manche sagen "Och, ganz nett", aber nutzen es nicht regelmäßig und andere wiederum, "hatten noch nicht die Zeit rein zu schauen".
Wolfgang ist einer der Early Adopter und nutzt GitHub Copilot täglich. In dieser Episode teilt er seine Erfahrungen und wir sprechen über Themen wie GitHub Copilot effektiv genutzt werden kann, Training Bias, den möglichen Produktivitäts Boost, Bugs die durch die AI generiert werden, die Auslagerung von langweiligen Arbeiten und warum die Nutzung von solchen AI Modellen die Priorität Nummer 1 für euren CTO sein sollte.
Bonus: Die richtige Schnitthöhe von Rasen bei Trockenperioden und ob Shell eine Programmiersprache ist.
Das schnelle Feedback zur Episode:
👍 (top) 👎 (geht so)
Feedback (gerne auch als Voice Message)
Gerne behandeln wir auch euer Audio Feedback in einer der nächsten Episoden, einfach Audiodatei per Email oder WhatsApp Voice Message an +49 15678 136776
(00:00:00) Intro
(00:01:21) Der AI-Hypetrain und GitHub Co-Pilot
(00:04:22) Info/Werbung
(00:06:50) Was ist GitHub Co-Pilot und was steckt hinter GitHub Co-Pilot?
(00:10:56) Pair-Programming: Driver und Navigator
(00:12:17) Was war deine Motivation gewesen, mittels AI zu programmieren?
(00:16:56) Kontext bei AI-Modellen
(00:21:46) Große Probleme in mehrere kleine Probleme unterteilen und die Kombination von Chat GPT und GitHub Co-Pilot
(00:25:44) Das Limit von Kontext und existierende Softwareprojekte mit mehrere Dateien als Kontext
(00:30:38) Nutzungen von 3rd-Party APIs mit GitHub Co-Pilot
(00:32:58) Woher kommen die Trainingsdaten und auf welcher Basis wurde das Codex-Modell trainiert?
(00:37:39) Training-Bias
(00:40:19) Hat GitHub Co-Pilot dir Code vorgeschlagen, den du nicht verstanden hast?
(00:42:21) Wie viel Prozent der Vorschläge der KI akzeptierst du initial?
(00:46:21) Test-Case-Generierung durch AI und die Art der Arbeit, die an GitHub Co-Pilot ausgelagert wird
(00:48:34) Inwieweit ist eine innovative Arbeit mit AI möglich, wenn keine Trainingsdaten vorhanden sind?
(00:52:13) Ist es empfehlenswert mit GitHub Co-Pilot programmieren zu lernen?
(00:53:44) Was ändert sich in meinem Programmier-Workflow bei der Nutzung von GitHub Co-Pilot?
(00:54:59) AI in der Firma und die rechtliche Situation bei der Nutzung von Code
(00:59:45) Werden Programmierer nun von der KI ersetzt? Können Nicht-Programmierer mit der KI programmieren?
(01:02:27) GitHub Copilot X, andere Coding-AI-Services und andere Podcast-Episoden
Alle Firmen suchen nur Senior-Engineers - Steckt in Junior-Engineers das wahre Potential?
Nachwuchs im Software-Engineering-Bereich zu bekommen ist nicht einfach. Die meisten Stellenanzeigen im Internet suchen Senior-Engineers mit über 5 Jahren Erfahrung. Doch wie sieht es denn mit Junior-Developer aus? Wie erkennt man motivierende Junior-Engineers in Interviews? Wie reagiert ein Team aus Senior-Engineers auf unerfahrene Personen? Welche Rolle spielen strukturierte Interviews und Entscheidungen aus dem Bauch heraus? Und was ist das richtige Verhalten, wenn man Zeit und Geld in die Weiterentwicklung einer Person investiert hat, aber die Person nach 2 Jahren kündigt?
In dieser Episode teilen Wolfgang und Andy ihre Erfahrungen im Recruiting, in der Weiterentwicklung und bei Kündigungen von Junior Engineers.
Bonus: Warum goto Statements böse sind und was Korn-Brause mit Sommer zu tun hat.
Unsere aktuellen Werbepartner findest du auf https://engineeringkiosk.dev/partners
Das schnelle Feedback zur Episode:
👍 (top) 👎 (geht so)
Feedback (gerne auch als Voice Message)
Gerne behandeln wir auch euer Audio Feedback in einer der nächsten Episoden, einfach Audiodatei per Email oder WhatsApp Voice Message an +49 15678 136776
(00:00:00) Intro
(00:00:46) Die ursprüngliche Idee des Podcasts, Alps Meetup und Juniors einstellen
(00:05:40) Warum suchen alle Firmen nach Seniors und keine Juniors?
(00:09:30) Juniors haben die Freiheit die dummen Fragen zu stellen
(00:11:46) Die Förderung von Junior-Engineers ist Teamaufgabe
(00:13:23) Vorwürfe zur Bevorzugung von speziellen Personen
(00:17:31) Persönlicher Bias und intrinsische Motivation beim Recruiting von Junioren und strukturierte Interviews
(00:21:40) Wie findet man die Motivation einer Kandidatin im Interview?
(00:28:32) Public Profiles sind kein Vorteil und kein Nachteil
(00:31:02) Die Probezeit ist für beiden Seiten: Die Firma und der Kandidatin
(00:34:46) Studenten während des Studiums einstellen als Recruiting-Strategie
(00:43:46) Aufwand der Mitarbeiter-Förderung vs. Kündigungen, Kosten von Recruiting und Regrettable losses
(00:52:55) Wie coached man Junior-Engineers hoch?
(00:56:47) Es werden nur Senior-Positionen ausgeschrieben - Doch warum?
(00:59:09) Keyword-Matching im Lebenslauf und Aussortierung von Bewerbungen
(01:04:29) Wie hieß das Thema der heutigen Episode?
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:
👍 (top) 👎 (geht so)
Feedback (gerne auch als Voice Message)
Gerne behandeln wir auch euer Audio Feedback in einer der nächsten Episoden, einfach Audiodatei per Email oder WhatsApp Voice Message an +49 15678 136776
(00:00:00) Intro
(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?
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:
👍 (top) 👎 (geht so)
Feedback (gerne auch als Voice Message)
Gerne behandeln wir auch euer Audio Feedback in einer der nächsten Episoden, einfach Audiodatei per Email oder WhatsApp Voice Message an +49 15678 136776
(00:00:00) Intro
(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
Wie bringen wir der nächsten Generation, unseren Kindern, die Welt der Informatik und Software-Entwicklung näher?
Über diese Frage sprechen wir mit der Expertin Dr. Diana Knodel. studierte Informatikerin mit Schwerpunkt Psychologie, Autorin von zwei Kinderbüchern zum Thema Programmieren für Kinder sowie Gründerin von zwei Firmen, AppCamps und fobizz, im Bereich Bildung mit Schwerpunkt IT und Softwareentwicklung. Wir sprechen über aktuelle Vorbilder in der Informatik bzw. Programmierung für Kinder, ab welchem Alter Kinder mit der Programmierung starten können, welche Code-Editoren sind speziell für Kinder geeignet, wie können wir Lehrkräfte weiterbilden, damit diese das Thema in den Schulen vorantreiben, wie ChatGPT und KI im Allgemeinen die Bildung verändert wird und vieles mehr. Viel Spaß.
Bonus: Warum ChatGPT der neue Taschenrechner wird.
Unsere aktuellen Werbepartner findest du auf https://engineeringkiosk.dev/partners
Das schnelle Feedback zur Episode:
👍 (top) 👎 (geht so)
Feedback (gerne auch als Voice Message)
Gerne behandeln wir auch euer Audio Feedback in einer der nächsten Episoden, einfach Audiodatei per Email oder WhatsApp Voice Message an +49 15678 136776
(00:00:00) Intro
(00:01:33) Unser Gast: Dr. Diana Knodel
(00:03:24) Wie kommt man dazu, eine Firma im Bereich Bildung zu gründen?
(00:10:00) Wie groß ist das App Camps-Team aktuell und wie hat sich der Fokus geändert?
(00:10:36) Wie kann ich als Lehrkraft die Unterrichtsmaterialien für meine Klasse nutzen?
(00:11:00) Wie gut wird App Camps von den Lehrkräften angenommen?
(00:12:25) Was sind die populärsten Unterrichtsmaterialien?
(00:13:36) Welche (Code)-Editoren kommen dabei zum Einsatz?
(00:15:05) Ab welchem Alter kann mit der Programmierung gestartet werden?
(00:19:18) Was sind aktuelle Vorbilder in der Informatik bzw. Programmierung?
(00:21:54) Die ersten Unterrichtsmaterialien und Workshops
(00:24:12) Class Chats
(00:25:22) Sind die Unterrichtsmaterialien auch für Eltern zugänglich und sinnvoll?
(00:26:59) Weiterbildung der Lehrkräfte durch fobizz
(00:30:48) Künstliche Intelligenz und Chat GPT in der Bildung und bei den Ämtern in Deutschland
(00:33:34) Wie viel Zeit und Ressourcen steht den Lehrkräften für die Weiterbildung zur Verfügung?
(00:35:12) Kosten und Tools für die Weiterbildung von Lehrkräften durch fobizz
(00:37:15) DigitalPakt Schule und Hardware an den Schulen
(00:38:50) Die Chancen mit Chat GPT und KI die theoretischen Fächer der Informatik, Kindern zugänglicher zu machen
(00:40:51) Ändert sich die Bildung von Software Engineering zu Prompt Engineering?
(00:41:51) Wird in Zukunft logisches und analytisches Denken weniger relevant?
(00:43:27) Programmierung und Informatik ist nicht für jeden und den Einstieg zu einem späteren Zeitpunkt
(00:46:52) Was sind Elemente, die Kinder für die MINT-Bereiche abschrecken?
(00:48:15) Wie bewahren wir Kinder davor, falsche Vorstellung zur Erstellung von Apps zu haben?
(00:50:46) In wie weit müssen Aufgaben, die in der Schule gestellt werden, auf Basis von KI und Chat GPT abgeändert werden?
(00:54:59) Wie wichtig ist der Mensch im Bereich der Bildung noch?
(00:56:21) Wie kann man sich in das Thema der Bildung für Informatik/Software-Entwicklung für Kinder einbringen?
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:
👍 (top) 👎 (geht so)
Feedback (gerne auch als Voice Message)
Gerne behandeln wir auch euer Audio Feedback in einer der nächsten Episoden, einfach Audiodatei per Email oder WhatsApp Voice Message an +49 15678 136776
(00:00:00) Intro
(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
Woher weißt du eigentlich, ob du einen guten Job machst? Wie erkennst du Blindspots oder ob du an den richtigen Dingen arbeitest?
Das ist eine Frage, die sich jeder im Arbeitsleben mal stellen sollte. Weiß ich, was von mir erwartet wird? Kann ich sagen, wie Erfolg in meiner Rolle aussieht? Bzw. Was ist das ursprüngliche Problem-Statement, welches ich mit meiner Rolle lösen soll? Alles keine einfachen Fragen, jedoch notwendig, um beim nächsten Performance-Cycle und Gehaltsgespräch nicht enttäuscht zu werden.
In dieser Episode sprechen wir genau darüber: Wir geben Tipps, wie du eine Art Selbst-Evaluierung zu deiner Arbeitsleistung durchführen kannst oder welche Schritte du gehen kannst, um den Prozess zu starten. Wir sprechen über die Schwierigkeit von gutem Feedback, über Job-Beschreibungen, Peer-Coaching, konkrete Arbeit als Team-Lead, Feedback-Cycle in deinem Job, wie wichtig es ist, das Business-Model der Firma zu verstehen und über Schubladendenken bei Leverage, Neutralen und Overhead-Aufgaben.
Bonus: Ob CV Driven Development was schlechtes ist und ob "Da kann man nicht meckern" das Lob der Deutschen ist.
Unsere aktuellen Werbepartner findest du auf https://engineeringkiosk.dev/partners
Das schnelle Feedback zur Episode:
👍 (top) 👎 (geht so)
Feedback (gerne auch als Voice Message)
Gerne behandeln wir auch euer Audio Feedback in einer der nächsten Episoden, einfach Audiodatei per Email oder WhatsApp Voice Message an +49 15678 136776
(00:00:00) Intro
(00:01:03) Imposter-Syndrom
(00:02:12) Selbstevaluierung, "Bin ich gut genug?" Und mach ich noch einen guten Job?
(00:04:20) Was ist denn eigentlich dein Job, hast du eine Job-Beschreibung und Selbst-Reflektion
(00:10:06) Was ist dein konkreter Beitrag zum Erfolg des Teams? Wie sieht Erfolg in deiner Rolle aus?
(00:17:01) Tech-Lead-Mythos: Keine Beförderung, sondern ein Karrierewechsel
(00:22:51) Konkrete Beispiele für deine Arbeit als Lead und messbare Ergebnisse
(00:28:08) Team-Umfragen
(00:30:17) Ehrliches Feedback benötigt Mut und was gutes Feedback eigentlich ausmacht
(00:34:15) 360°-Evaluierungen, Gruppen-Feedback und Blindspots finden
(00:41:57) Ergebnisse und Ziele transparent machen
(00:45:32) Peer-Coaching und Peer-Groups
(00:47:48) Nachdenken ist ein aktiver Teil deiner Arbeit und arbeite ich an den richtigen Dingen?
(00:51:56) Verstehe das Business-Modell deiner Firma und wer ist der Kunde
(00:56:13) LNO Effectiveness Framework
(01:00:03) Outro
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:
👍 (top) 👎 (geht so)
Feedback (gerne auch als Voice Message)
Gerne behandeln wir auch euer Audio Feedback in einer der nächsten Episoden, einfach Audiodatei per Email oder WhatsApp Voice Message an +49 15678 136776
(00:00:00) Intro
(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
There are only two hard things in Computer Science: cache invalidation and naming things.
Caches sind einfach überall. Jede Aktion auf einem Computer nutzt eine Vielzahl an Caches. Sei es der Browser Cache, DNS-Cache, In-Memory Cache auf dem Server oder dein lokaler CPU Cache L1-L4. Doch was sind Caches eigentlich? Welche Cache-Layer und Cache-Hierarchien gibt es? Wie funktionieren Caches? Wie kann ich Cache-freundlich programmieren? Was passiert, wenn der Cache voll ist und was sind Eviction-Policies? Wie relevant sind heutzutage eigentlich die CPU-Caches L1 bis L4 für die normalen Software-Entwickler*innen? Wie kann ich verifizieren, ob mein Code Cache-freundlich ist? Und warum ist Cache Invalidation eigentlich ein hartes Problem?
Bonus: Was Bandlaufwerke mit Caching und niederländisches Hähnchen mit Queues zu tun haben.
Unsere aktuellen Werbepartner findest du auf https://engineeringkiosk.dev/partners
Das schnelle Feedback zur Episode:
👍 (top) 👎 (geht so)
Feedback (gerne auch als Voice Message)
Gerne behandeln wir auch euer Audio Feedback in einer der nächsten Episoden, einfach Audiodatei per Email oder WhatsApp Voice Message an +49 15678 136776
(00:00:00) Intro
(00:01:02) Es gibt nur zwei harte Probleme in der Informatik
(00:06:56) Caching und Cache Invalidierung
(00:07:25) Was ist ein Cache?
(00:10:36) Jeder nutzt Caches jeden Tag: Cache-Layer
(00:12:34) Cache-Hierarchien und wie relevant sind CPU Caches (L1 bis L4) heute noch?
(00:16:39) Wie funktioniert eigentlich ein Cache? Cache Hit, Cache Miss, Cache Ratio
(00:21:27) Ersetzungsstrategien / Eviction-Policies: FIFO, LIFO, LRU, TTL, MRU, LFU
(00:31:57) Wie kann ich Cache-Freundlich programmieren um den L1 bis L4 Cache richtig zu nutzen und Monitoring von L1 bis L4 Caches
(00:48:39) Ist die Funktionsweise von L1 bis L4 Caches valide für andere Arten von Caches?
(00:51:12) Warum ist Cache Invalidierung ein hartes Problem?
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
(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?
From the publisher's feed
Der Engineering Kiosk ist der deutschsprachige Software-Engineering-Podcast mit Wolfgang Gassler und Andy Grunwald rund um die Themen Engineering-Kultur, Open Source, Menschen, Technologie und…