Engineering Kiosk

Welche Rolle spielt Softwareentwicklung im Datenjournalismus? Datenjournalismus ist eine spezialisierte Form des Journalismus, die u.a. darauf abzielt (offene) Daten (und somit auch interessante Fakten) durch interaktive Visualisierungen und Diagramme zugänglich zu machen. Doch um ein konsumierbares Ergebnis zu erhalten, ist viel Arbeit notwendig. Was steckt also dahinter? In dieser Episode sprechen wir mit Michael Kreil. Michael ist freier Datenjournalist und gibt uns Einblicke in seine Arbeit. Wir klären, was Datenjournalismus eigentlich ist, inwieweit das ganze in Relation zu Data Analytics oder Data Science steht, woher eigentlich die Arbeitsgrundlage, also die Daten, stammen, wie viel Software-Engineering in diesem Prozess involviert ist, welche handwerklichen Fehler bei der Arbeit mit Daten gemacht werden können, aber auch wie Datenjournalisten für Open Data und “Public Money, Public Code oder Public Data” kämpfen. Bonus: Wenn Daten präsentiert werden, schalten Menschen ihren Kopf aus. Das schnelle Feedback zur Episode: 👍 (top) 👎 (geht so) Feedback EngKiosk Community: https://engineeringkiosk.dev/join-discord Buy us a coffee: https://engineeringkiosk.dev/kaffee Email: stehtisch@engineeringkiosk.dev LinkedIn: https://www.linkedin.com/company/engineering-kiosk/ Mastodon: https://podcasts.social/@engkiosk Twitter: https://twitter.com/EngKiosk Gerne behandeln wir auch euer Audio Feedback in einer der nächsten Episoden, einfach die Audiodatei per Email an stehtisch@engineeringkiosk.dev. Links Michael Kreil: https://www.michael-kreil.de/ VersaTiles: A complete FLOSS map stack: https://versatiles.org/ Pandas: https://pandas.pydata.org/ d3.js: https://d3js.org/ Chart.js: https://www.chartjs.org/ Statista: https://de.statista.com/ Our World In Data: https://ourworldindata.org/ Destatis: https://www.destatis.de/ Eurostat: https://ec.europa.eu/eurostat/de/ Datenportal Berlin: https://daten.berlin.de/ Open Data Portal der deutschen Bahn: https://data.deutschebahn.com/opendata GOV Data: https://www.govdata.de/ Journalist klagt gegen Freistaat Bayern - Wann Medien Behördendaten veröffentlichen dürfen: https://www.deutschlandfunk.de/journalist-klagt-gegen-den-freistaat-bayern-sind-behoerdendaten-durch-das-urheberrecht-geschuetzt-100.html Kostenlose Basisdaten: https://www.adv-online.de/Veroeffentlichungen/Presse/ Deadlift ETF: https://www.reddit.com/r/atrioc/comments/1ewkatt/some_dude_made_a_deadlift_etf_with_only_companies/ Spurious correlations: https://tylervigen.com/spurious-correlations Per capita consumption of margarine correlates with the divorce rate in Maine: https://www.tylervigen.com/spurious/correlation/5920_per-capita-consumption-of-margarine_correlates-with_the-divorce-rate-in-maine A bad chart got better – and then bad again: https://blog.datawrapper.de/irish-times-chart-redesigned-olympics/ Gap Minder: https://www.gapminder.org/ Hans Rosling Talk https://www.ted.com/talks/hans_rosling_the_best_stats_you_ve_ever_seen Sprungmarken (00:00:00) Datenjournalismus und Open Source Karten mit Michael Kreil (00:04:04) Was hat dich dazu bewegt in den Journalismus zu gehen? (00:05:53) Sponsor/Info (00:06:53) Was ist Datenjournalismus? (00:14:09) Wie verwandt ist der Datenjournalist mit Data Analytics und Data Science? (00:19:00) Sind Datenjournalisten-Projekte "On-Off"-Projekte? (00:20:36) Wo bekommen Datenjournalisten die Rohdaten her? (00:30:52) Was müssen wir beim Umgang mit Daten bzw. Statistiken beachten? (00:39:10) Korrelation ist nicht Kausalität (00:47:56) Typische Fehler bei der Visualisierung von Daten (00:57:47) Die Kunst, Elemente weg zu lassen (01:00:21) Wie werde ich Datenjournalist? Hosts Wolfgang Gassler (https://mastodon.social/@woolf) Andy Grunwald (https://twitter.com/andygrunwald) Feedback EngKiosk Community: https://engineeringkiosk.dev/join-discord Buy us a coffee: https://engineeringkiosk.dev/kaffee Email: stehtisch@engineeringkiosk.dev LinkedIn: https://www.linkedin.com/company/engineering-kiosk/ Mastodon: https://podcasts.social/@engkiosk Twitter: https://twitter.com/EngKiosk

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: 👍 (top) 👎 (geht so) Feedback EngKiosk Community: https://engineeringkiosk.dev/join-discord Buy us a coffee: https://engineeringkiosk.dev/kaffee Email: stehtisch@engineeringkiosk.dev LinkedIn: https://www.linkedin.com/company/engineering-kiosk/ Mastodon: https://podcasts.social/@engkiosk Twitter: https://twitter.com/EngKiosk Gerne behandeln wir auch euer Audio Feedback in einer der nächsten Episoden, einfach die Audiodatei per Email an stehtisch@engineeringkiosk.dev. Links 12 Principles/Agile Manifesto: https://agilemanifesto.org/iso/de/manifesto.html Engineering Kiosk Episode #47 Wer Visionen hat, soll zum Arzt!?: https://engineeringkiosk.dev/podcast/episode/47-wer-visionen-hat-soll-zum-arzt/ Thoughtworks Technology Radar Volume 30: https://www.thoughtworks.com/content/dam/thoughtworks/documents/radar/2024/04/tr_technology_radar_vol_30_en.pdf Zalando Tech Radar - Scaling Contributions to Technology Selection: https://engineering.zalando.com/posts/2021/06/zalando-tech-radar-scaling-contributions.html Zalando Tech Radar: https://opensource.zalando.com/tech-radar/ Thoughtworks - Technology Radar: https://www.thoughtworks.com/radar Engineering Kiosk Episode #62 Technologien konsolidieren, oder wie Startups sammeln?: https://engineeringkiosk.dev/podcast/episode/62-technologien-konsolidieren-oder-wie-startups-sammeln/ Gartner Hype Cycle: https://www.gartner.de/de/methoden/hype-cycle Architectural Decision Records: https://adr.github.io/ Engineering Kiosk Episode #110 OKRs und Beyond: Agile Unternehmensführung mit Marco Alberti von Murakamy: https://engineeringkiosk.dev/podcast/episode/110-okrs-und-beyond-agile-unternehmensf%C3%BChrung-mit-marco-alberti-von-murakamy/ The Delivery Hero Reliability Manifesto: https://tech.deliveryhero.com/our-reliability-manifesto/ 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 Wolfgang Gassler (https://mastodon.social/@woolf) Andy Grunwald (https://twitter.com/andygrunwald) Feedback EngKiosk Community: https://engineeringkiosk.dev/join-discord Buy us a coffee: https://engineeringkiosk.dev/kaffee Email: stehtisch@engineeringkiosk.dev LinkedIn: https://www.linkedin.com/company/engineering-kiosk/ Mastodon: https://podcasts.social/@engkiosk Twitter: https://twitter.com/EngKiosk

Security Engineering und Hacking-Wettbewerbe “Capture the Flag” Alles wird digital und für alles gibt es eine App. Bei einer solch rasanten Verbreitung, weckt dies Begehrlichkeiten bei böswilligen Hackern. Was ist also die passende Gegenwehr? Security Engineering! Doch was ist das eigentlich? Wir sprechen mit Frederik Braun, Security Engineering Manager bei Mozilla und zuständig für den Firefox Browser. Er erklärt uns die Gemeinsamkeiten und Unterschiede von Security und Software-Engineering, wie sich der Bereich Security von einer Web-App und einem Browser unterscheidet, wie Security selbst bei Mozilla aussieht, wie Sicherheitslücken mittels Gamification und Capture The Flag Events gefunden und das suchen geübt werden kann und wie du in das Thema Security Engineering einsteigen kannst. Bonus: Hackerpraktika an der Universität Bochum Das schnelle Feedback zur Episode: 👍 (top) 👎 (geht so) Feedback EngKiosk Community: https://engineeringkiosk.dev/join-discord Buy us a coffee: https://engineeringkiosk.dev/kaffee Email: stehtisch@engineeringkiosk.dev LinkedIn: https://www.linkedin.com/company/engineering-kiosk/ Mastodon: https://podcasts.social/@engkiosk Twitter: https://twitter.com/EngKiosk Gerne behandeln wir auch euer Audio Feedback in einer der nächsten Episoden, einfach die Audiodatei per Email an stehtisch@engineeringkiosk.dev. Links Frederik Braun: https://frederikbraun.de/ Was ist Meltdown/Spectre? https://www.cloudflare.com/de-de/learning/security/threats/meltdown-spectre/ xz-Backdoor – eine Aufarbeitung: https://research.hisolutions.com/2024/04/xz-backdoor-eine-aufarbeitung/ FluxFingers: https://fluxfingers.net/ Hack.lu: https://hack.lu/ Bug Bounty Programm: https://de.wikipedia.org/wiki/Bug-Bounty-Programm Mozilla Security Bug Bounty Program: https://www.mozilla.org/en-US/security/bug-bounty/ Pwn2Own-Hacker attackieren Tesla, Firefox und andere: https://www.golem.de/news/1-1-millionen-usd-gewonnen-pwn2own-hacker-attackieren-tesla-firefox-und-andere-2403-183515.html Mozilla Foundation Security Advisory 2024-15: https://www.mozilla.org/en-US/security/advisories/mfsa2024-15/ Rapidly Leveling up Firefox Security: https://blog.mozilla.org/security/2024/04/04/rapidly-leveling-up-firefox-security/ WebAssembly and Back Again: Fine-Grained Sandboxing in Firefox 95: https://hacks.mozilla.org/2021/12/webassembly-and-back-again-fine-grained-sandboxing-in-firefox-95/ Over the Wire: https://overthewire.org/ CTF Time: https://ctftime.org/ Ruhr Universität Bochum: https://www.ruhr-uni-bochum.de/de Mozilla: https://www.mozilla.org/de/ Mozilla auf Github: https://github.com/mozilla Sprungmarken (00:00:00) Intro (00:00:56) Security Engineering mit Frederik Braun (00:05:01) Frederiks Kontakt mit Security Engineering (00:07:51) Werbung/Info (00:08:51) Frederiks Kontakt mit Security Engineering (00:18:16) Sub-Bereiche im Security Engineering und Software Entwicklung (00:28:00) Softwareentwicklung eines Browsers zu anderen Softwarearten (00:43:34) Was ist Capture the Flag, Bug Bounty und pwn2own? (01:06:31) Der Einstieg in Security Engineering und Capture the Flag Hosts Wolfgang Gassler (https://mastodon.social/@woolf) Andy Grunwald (https://twitter.com/andygrunwald) Feedback EngKiosk Community: https://engineeringkiosk.dev/join-discord Buy us a coffee: https://engineeringkiosk.dev/kaffee Email: stehtisch@engineeringkiosk.dev LinkedIn: https://www.linkedin.com/company/engineering-kiosk/ Mastodon: https://podcasts.social/@engkiosk Twitter: https://twitter.com/EngKiosk

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: 👍 (top) 👎 (geht so) Feedback EngKiosk Community: https://engineeringkiosk.dev/join-discord Buy us a coffee: https://engineeringkiosk.dev/kaffee Email: stehtisch@engineeringkiosk.dev LinkedIn: https://www.linkedin.com/company/engineering-kiosk/ Mastodon: https://podcasts.social/@engkiosk Twitter: https://twitter.com/EngKiosk Gerne behandeln wir auch euer Audio Feedback in einer der nächsten Episoden, einfach die Audiodatei per Email an stehtisch@engineeringkiosk.dev. Links Anna Drüing-Schlüter auf LinkedIn: https://www.linkedin.com/in/anna-dr%C3%BCing-schl%C3%BCter-961796b8/ Twise: https://www.twise.eu/ TWISE auf LinkedIn: https://www.linkedin.com/company/twise-gmbh/ TWISE auf Instagram https://www.instagram.com/twise.eu/ twAIse Matching Algorithmus: https://www.twise.eu/tandem-match-making Wissenschaftliche Befragung zur Tandem-Produktivität und ob Jobsharing sich lohnt: https://uploads-ssl.webflow.com/6098f3c5d7715d4186ff94e2/639cbca09f35afdf7bde60c6_Ergebnisse.Produktivita%CC%88t%20im%20Jobsharing_1.12.22.pdf Ein erfolgreiches Tandem berichtet - “Head of R&D” Topsharing beim Maschinenbauer TRUMPF: https://www.youtube.com/watch?v=rn9bqrIb_IM Modell der Persönlichkeitspsychologie - Big 5: https://de.wikipedia.org/wiki/Big_Five_(Psychologie) 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 Wolfgang Gassler (https://mastodon.social/@woolf) Andy Grunwald (https://twitter.com/andygrunwald) Feedback EngKiosk Community: https://engineeringkiosk.dev/join-discord Buy us a coffee: https://engineeringkiosk.dev/kaffee Email: stehtisch@engineeringkiosk.dev LinkedIn: https://www.linkedin.com/company/engineering-kiosk/ Mastodon: https://podcasts.social/@engkiosk Twitter: https://twitter.com/EngKiosk

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: 👍 (top) 👎 (geht so) Feedback EngKiosk Community: https://engineeringkiosk.dev/join-discord Buy us a coffee: https://engineeringkiosk.dev/kaffee Email: stehtisch@engineeringkiosk.dev LinkedIn: https://www.linkedin.com/company/engineering-kiosk/ Mastodon: https://podcasts.social/@engkiosk Twitter: https://twitter.com/EngKiosk Gerne behandeln wir auch euer Audio Feedback in einer der nächsten Episoden, einfach die Audiodatei per Email an stehtisch@engineeringkiosk.dev. Links Schaltsekunde: https://de.wikipedia.org/wiki/Schaltsekunde “Geht es der Schaltsekunde an den Kragen?”: https://www.nzz.ch/geht_es_der_schaltsekunde_an_den_kragen-ld.690007 ITU in 2015 - Coordinated Universal Time (UTC) to retain “leap second”: https://www.itu.int/net/pressoffice/press_releases/2015/53.aspx Problematic second: https://sarvendev.com/2024/07/problematic-second/ How the Windows Time service treats a leap second: https://learn.microsoft.com/en-us/troubleshoot/windows-server/active-directory/time-service-treats-leap-second The Monotonic Clock and Why You Should Care About It: https://blog.codeminer42.com/the-monotonic-clock-and-why-you-should-care-about-it/ Google Public NTP - Leap Smear: https://developers.google.com/time/smear AWS - Look Before You Leap – The Coming Leap Second and AWS: https://aws.amazon.com/de/blogs/aws/look-before-you-leap-the-coming-leap-second-and-aws/ Meinberg - Leap Second Smearing with NTP: https://www.meinbergglobal.com/download/burnicki/Leap%20Second%20Smearing%20With%20NTP.pdf Unsmear-Library (C++) von Google: https://github.com/google/unsmear Meta - It’s time to leave the leap second in the past: https://engineering.fb.com/2022/07/25/production-engineering/its-time-to-leave-the-leap-second-in-the-past/ Building a more accurate time service at Facebook scale: https://engineering.fb.com/2020/03/18/production-engineering/ntp-service/ Leap Second File at IANA: https://data.iana.org/time-zones/data/leap-seconds.list NTP Leap Second Processing: https://www.ntp.org/documentation/4.2.8-series/leap/ The NTP Timescale and Leap Seconds: https://www.ntp.org/reflib/leap/ Spanner: TrueTime and external consistency: https://cloud.google.com/spanner/docs/true-time-external-consistency The Unix leap second mess: http://www.madore.org/~david/computers/unix-leap-seconds.html Issues involved in computer time stamps and leap seconds: https://www.ucolick.org/~sla/leapsecs/picktwo.html 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 Wolfgang Gassler (https://mastodon.social/@woolf) Andy Grunwald (https://twitter.com/andygrunwald) Feedback EngKiosk Community: https://engineeringkiosk.dev/join-discord Buy us a coffee: https://engineeringkiosk.dev/kaffee Email: stehtisch@engineeringkiosk.dev LinkedIn: https://www.linkedin.com/company/engineering-kiosk/ Mastodon: https://podcasts.social/@engkiosk Twitter: https://twitter.com/EngKiosk

Gesundheit ist das höchste Gut des Menschen (welches wir noch nicht kaufen können) Als Tech- bzw. Knowledger-Worker*in arbeiten wir zwar alle an unterschiedlichen Projekten, Produkten und in anderen Kontexten, doch eins haben wir (leider) alle gemeinsam: Wir sitzen den Großteil des Tages recht statisch auf einem Stuhl vor einem Computer. Es ist zwar oft bequem, aber wie gut ist es für den eigenen Körper? Und auch sonst: Der Alltag ist oft stressig. Eine Deadline jagt die nächste. Back to back Meetings stehen an und niemand hat bzw. nimmt sich die Zeit, sich mal was halbwegs gesundes zu kochen. Stattdessen: Schnell zum Imbiss nebenan. Deswegen widmen wir uns mal diesem wichtigen, doch recht techniklosen Thema der eigenen Fitness und Gesundheit und sprechen über die Probleme beim dauerhaften Sitzen, die Folgen von Stress, die Bedeutung von Fitness und die die Extreme in Social Media. Und das ganze mit Patrick Cole, einem Personal Trainer. Bonus: Es gibt Bandscheibenvorfälle im oberen Rücken. Videos von Andy und Patrick findet ihr unter https://www.instagram.com/engineeringkiosk/ Das schnelle Feedback zur Episode: 👍 (top) 👎 (geht so) Feedback EngKiosk Community: https://engineeringkiosk.dev/join-discord Buy us a coffee: https://engineeringkiosk.dev/kaffee Email: stehtisch@engineeringkiosk.dev LinkedIn: https://www.linkedin.com/company/engineering-kiosk/ Mastodon: https://podcasts.social/@engkiosk Twitter: https://twitter.com/EngKiosk Gerne behandeln wir auch euer Audio Feedback in einer der nächsten Episoden, einfach die Audiodatei per Email an stehtisch@engineeringkiosk.dev. Links Patrick Cole auf LinkedIn: https://www.linkedin.com/in/pcfitwithpc/ Website von Patrick Cole: https://www.patrick-cole.com/ Musculoskeletal health: https://www.who.int/news-room/fact-sheets/detail/musculoskeletal-conditions Videos von Andy und Patrick findet ihr unter https://www.instagram.com/engineeringkiosk/ Sprungmarken (00:00:00) Fitness mit Patrick Cole (00:04:46) Viele Knowledge-Worker haben die gleichen Probleme (00:05:43) Info/Werbung (00:06:48) Viele Knowledge-Worker haben die gleichen Probleme (00:13:11) Bandscheibenvorfall, Migräne, Stress und mentale Gesundheit (00:18:38) Verantwortung von Arbeitnehmer und Arbeitgeber (00:24:01) Welche "Körperschäden" sind korrigierbar und Arten des Muskelaufbaus (00:30:30) Einfache Übungen zum Start für zuhause (00:38:05) Ernährung: Zugang zum Essen, unter Stress essen und Kalorien zählen (00:53:51) Der Effekt von Alkohol und Fitness erkennt man nicht anhand der Körperform (00:58:37) Gadgets und Technik (01:01:50) Einfach mal anfangen Hosts Wolfgang Gassler (https://mastodon.social/@woolf) Andy Grunwald (https://twitter.com/andygrunwald) Feedback EngKiosk Community: https://engineeringkiosk.dev/join-discord Buy us a coffee: https://engineeringkiosk.dev/kaffee Email: stehtisch@engineeringkiosk.dev LinkedIn: https://www.linkedin.com/company/engineering-kiosk/ Mastodon: https://podcasts.social/@engkiosk Twitter: https://twitter.com/EngKiosk

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: 👍 (top) 👎 (geht so) Feedback EngKiosk Community: https://engineeringkiosk.dev/join-discord Buy us a coffee: https://www.buymeacoffee.com/engineeringkiosk Email: stehtisch@engineeringkiosk.dev LinkedIn: https://www.linkedin.com/company/engineering-kiosk/ Mastodon: https://podcasts.social/@engkiosk Twitter: https://twitter.com/EngKiosk Gerne behandeln wir auch euer Audio Feedback in einer der nächsten Episoden, einfach die Audiodatei per Email an stehtisch@engineeringkiosk.dev. Links RFC und Design Doc Templates von verschiedenen Firmen: https://blog.pragmaticengineer.com/rfcs-and-design-docs/ Public RFCs von SourceGraph: https://drive.google.com/drive/folders/1zP3FxdDlcSQGC1qvM9lHZRaHH4I9Jwwa?ref=blog.pragmaticengineer.com RFC Proposal von SourceGraph: https://docs.google.com/document/d/1zInJ9mn_SePKjS8dLHS1EDt2_gUEkCKD544bDDSuJek/edit#heading=h.trqab8y0kufp RFC Process von SoundCloud: https://philcalcado.com/2018/11/19/a_structured_rfc_process.html RFCs von RazorPay: https://github.com/razorpay/blade/tree/master/rfcs RFCs von Couchbase: https://github.com/couchbaselabs/sdk-rfcs/tree/master/rfc How to write an effective design document: https://rinaarts.com/how-to-write-an-effective-design-document/ Design Docs at Google: https://www.industrialempathy.com/posts/design-docs-at-google/ Design Documents vom Service Mesh Istio: https://github.com/istio/istio/wiki/Design-Doc-Links Kafka Improvement Proposals (KIP): https://cwiki.apache.org/confluence/display/KAFKA/Kafka+Improvement+Proposals Internet Engineering Task Force RFCs: https://www.ietf.org/process/rfcs/ How and Why RFCs Fail: https://candost.blog/how-and-why-rfcs-fail/ Oxides Request For Discussions: https://rfd.shared.oxide.computer/ Engineering Episode #130 Wie gutes UX-Design entsteht mit Robin Titus: https://engineeringkiosk.dev/podcast/episode/130-wie-gutes-ux-design-entsteht-mit-robin-titus/ Engineering Kiosk Episode #66 Stressfreie Produktivität in der hektischen Welt mit Getting Things Done: https://engineeringkiosk.dev/podcast/episode/66-stressfreie-produktivit%C3%A4t-in-der-hektischen-welt-mit-getting-things-done/ Checklist Manifesto: How to Get Things Right: https://www.amazon.de/Checklist-Manifesto-ATUL-GAWANDE/dp/0312430000/ref=sr_1_1 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 Wolfgang Gassler (https://mastodon.social/@woolf) Andy Grunwald (https://twitter.com/andygrunwald) Feedback EngKiosk Community: https://engineeringkiosk.dev/join-discord Buy us a coffee: https://www.buymeacoffee.com/engineeringkiosk Email: stehtisch@engineeringkiosk.dev LinkedIn: https://www.linkedin.com/company/engineering-kiosk/ Mastodon: https://podcasts.social/@engkiosk Twitter: https://twitter.com/EngKiosk

Open Source: Die schöne heile Welt - Oder doch nicht? Die meisten sprechen über Open Source mit einem positiven Mindset. Die Kultur ist einzigartig. Leute, die sich noch nie gesehen haben, arbeiten zusammen an etwas Großem. Als Anwender ist man oft beeindruckt, was für eine großartige Software allein durch freiwillige Arbeit erschaffen und auch bereitgestellt wird. Doch in der Realität sieht es oft ganz anders aus. Wenn mal wieder einer der Open Source Incidents in die Tagesschau geschafft hat, wird das ganze Set an Problemen, die es in der Maintainership von Open Source Projekten gibt, sichtbar. Und genau darüber geht es in dieser Episode. Wir klären, welche Probleme es beim Maintainen von Open Source gibt, warum diese nur auf wenige Schultern verteilt sind, aber Milliarden Menschen vom positiven Open Source Output profitieren und welche Lösungen es dafür gibt. Viel Spaß. Bonus: Viel Negativität auf wenigen Schultern verteilt. Das schnelle Feedback zur Episode: 👍 (top) 👎 (geht so) Feedback EngKiosk Community: https://engineeringkiosk.dev/join-discord Buy us a coffee: https://engineeringkiosk.dev/kaffee Email: stehtisch@engineeringkiosk.dev LinkedIn: https://www.linkedin.com/company/engineering-kiosk/ Mastodon: https://podcasts.social/@engkiosk Twitter: https://twitter.com/EngKiosk Gerne behandeln wir auch euer Audio Feedback in einer der nächsten Episoden, einfach die Audiodatei per Email an stehtisch@engineeringkiosk.dev. Links Daniel Stenberg “Thank you Crowdstrike for helping to illustrate that Open Source is not the problem”: https://mastodon.social/@bagder/112812252225104999 Daniel Stenberg “You too could have made curl!”: https://fosdem.org/2024/schedule/event/fosdem-2024-1931-you-too-could-have-made-curl-/ "Für 50 Prozent der Entwickler ist Open Source ein 9-to-5-Job": https://www.techrepublic.com/article/for-50-percent-of-developers-open-source-is-a-9-to-5-job/ Engineering Kiosk Episode #59: Kann man mit Open Source Geld verdienen?: https://engineeringkiosk.dev/podcast/episode/59-kann-man-mit-open-source-geld-verdienen/ Engineering Kiosk Episode #42 Lexer, Parser und Open Source in Counterstrike: https://engineeringkiosk.dev/podcast/episode/42-lexer-parser-und-open-source-in-counterstrike/ Open Source Episoden im Engineering Kiosk: https://engineeringkiosk.dev/tag/open-source/ Open Source Maintainers Owe You Nothing: https://mikemcquaid.com/open-source-maintainers-owe-you-nothing/ The Pull Request Hack: https://felixge.de/2013/03/11/the-pull-request-hack/ Github Issue “fucking project”: https://github.com/lansuite/lansuite/issues/1192 Open Source is Not About You: https://gist.github.com/richhickey/1563cddea1002958f96e7ba9519972d9 Vereine zur Förderung von Open Source in Schulen: https://linux-bildung.at/osos-austria/ Google Open Source Peer Bonus program recognizes first group of 2024 recipients: https://opensource.googleblog.com/2024/06/google-open-source-peer-bonus-program-first-group-2024-recipients.html Open Source And Responsibility: https://felixge.de/2013/03/07/open-source-and-responsibility/ Prototypefund: https://prototypefund.de/en/ Sprungmarken (00:00:00) Intro (00:00:57) Die positive Energie rund um Open Source (00:07:19) Info/Werbung (00:08:42) Die positive Energie rund um Open Source (00:25:44) Full-Time-Open-Source: Ein Platz auf dem Schleudersitz? (00:32:51) Gute Arbeit vs. Miete zahlen vs. Bugs für andere zu beheben (00:48:18) Business-Customer-Relationship (00:54:39) Als Firma etwas zurück geben Hosts Wolfgang Gassler (https://mastodon.social/@woolf) Andy Grunwald (https://twitter.com/andygrunwald) Feedback EngKiosk Community: https://engineeringkiosk.dev/join-discord Buy us a coffee: https://engineeringkiosk.dev/kaffee Email: stehtisch@engineeringkiosk.dev LinkedIn: https://www.linkedin.com/company/engineering-kiosk/ Mastodon: https://podcasts.social/@engkiosk Twitter: https://twitter.com/EngKiosk

1on1s: Ein starkes Tool - Auch zum halten von Mitarbeitern Mitarbeiter zu finden ist schwierig. Gute und produktive Mitarbeiter zu halten kann unter Umständen sogar noch schwieriger sein. Auf der anderen Seite sind die Zeiten vorbei, wo ein Mitarbeiter bei einem Unternehmen bis zur Rente bleibt. Das ist vielen bekannt und ein alter Hut. Als wir diesen Podcast gestartet haben, dachten wir ebenfalls, 1on1s wären ein alter Hut. Nach der Veröffentlichung unserer Episode #10 zum 1on1 Meeting haben wir sehr viel positives Feedback bekommen, dass dieses Ritual nun Einzug in diversen Firmen gehalten hat. In dieser Episode bringen wir beide Themen zusammen: Wie kann man mit Hilfe von 1on1s ein positives Signal zum Mitarbeiter senden, um diesen längerfristig zu halten? Wir sprechen über die Herausforderung und Kosten, wenn Mitarbeiter das Unternehmen verlassen, übers aktive Zuhören, nicht alle Probleme als Manager selbst lösen, aktives Feedback einholen, aber auch Grenzen setzen sowie Accountability einfordern. Bonus: Wie bewertest du die Qualität des Essens in der Kantine? Das schnelle Feedback zur Episode: 👍 (top) 👎 (geht so) Feedback EngKiosk Community: https://engineeringkiosk.dev/join-discord Buy us a coffee: https://engineeringkiosk.dev/kaffee Email: stehtisch@engineeringkiosk.dev LinkedIn: https://www.linkedin.com/company/engineering-kiosk/ Mastodon: https://podcasts.social/@engkiosk Twitter: https://twitter.com/EngKiosk Gerne behandeln wir auch euer Audio Feedback in einer der nächsten Episoden, einfach die Audiodatei per Email an stehtisch@engineeringkiosk.dev. Links Engineering Kiosk Episode #112 Das Engineering Manager Pendulum: Zwischen Coding und Leadership mit Tom Bartel: https://engineeringkiosk.dev/podcast/episode/112-das-engineering-manager-pendulum-zwischen-coding-und-leadership-mit-tom-bartel/ Engineering Kiosk Episode #10 Das Karriere Booster Meeting 1:1s: https://engineeringkiosk.dev/podcast/episode/10-das-karriere-booster-meeting-11s/ Alle Engineering Kiosk Episoden zum Thema Karriere: https://engineeringkiosk.dev/tag/karriere/ Alle Engineering Kiosk Episoden zum Thema Leadership: https://engineeringkiosk.dev/tag/leadership/ One-on-Ones: Beyond Status Update: https://www.tombartel.me/blog/one-on-ones-beyond-status-update/ A 101 on 1:1s: https://engineering.atspotify.com/2015/12/a-101-on-11s/ Sprungmarken (00:00:00) Intro (00:00:47) Die Arbeiterlosigkeit und die 4 Tage Woche (00:05:04) Was kostet die Wiederbesetzung einer offenen Stelle? (00:07:34) Info/Werbung (00:08:41) Was kostet die Wiederbesetzung einer offenen Stelle? (00:17:08) Aktives zuhören um Mitarbeiter zu halten (00:22:05) Meine Tür steht dir immer offen (00:34:22) Erwartungen und Grenzen setzen (00:42:16) Ziele setzen und "Arbeit ist Arbeit" (00:50:17) Wenn du selbst der schlechte Manager bist und Feedback einholen (01:02:27) Leadership ist nicht einfach Hosts Wolfgang Gassler (https://mastodon.social/@woolf) Andy Grunwald (https://twitter.com/andygrunwald) Feedback EngKiosk Community: https://engineeringkiosk.dev/join-discord Buy us a coffee: https://engineeringkiosk.dev/kaffee Email: stehtisch@engineeringkiosk.dev LinkedIn: https://www.linkedin.com/company/engineering-kiosk/ Mastodon: https://podcasts.social/@engkiosk Twitter: https://twitter.com/EngKiosk

Überwachen von Applikationen in Zeiten von dynamischer Infrastruktur Cloud hier, Serverless da, Container-Scheduler dort. In Zeiten von dynamischen Infrastrukturen weiß man gar nicht mehr so genau, auf welchem Server und Port deine Applikation eigentlich läuft. Dies wirft die große Frage auf: Wie überwache ich meine Applikation denn eigentlich so ordentlich, dass ich sicherstellen kann, dass diese so funktioniert, wie ich mir das initial gedacht habe? Die Antwort dreht sich oft um den de facto Standard im Cloud Native Monitoring-Segment: Prometheus. In dieser Episode sprechen wir mit Julius Volz, einem der zwei initialen Autoren von Prometheus. Mit ihm sprechen wir über die Entstehungsgeschichte von Prometheus bei SoundCloud, wie sich das System von traditionellen Monitoring-Systemen unterscheidet, warum mit PromQL eine eigene Query-Language ins leben gerufen wurde aber auch welche Flaws er nach 12 Jahren Entwicklung gerne beheben würde. Bonus: Wer kennt noch Nagios, Ganglia oder Graphite? Unsere aktuellen Werbepartner findest du auf https://engineeringkiosk.dev/partners Das schnelle Feedback zur Episode: 👍 (top) 👎 (geht so) Feedback EngKiosk Community: https://engineeringkiosk.dev/join-discord Buy us a coffee: https://engineeringkiosk.dev/kaffee Email: stehtisch@engineeringkiosk.dev LinkedIn: https://www.linkedin.com/company/engineering-kiosk/ Mastodon: https://podcasts.social/@engkiosk Twitter: https://twitter.com/EngKiosk Gerne behandeln wir auch euer Audio Feedback in einer der nächsten Episoden, einfach die Audiodatei per Email an stehtisch@engineeringkiosk.dev. Links Julius Volz: https://juliusv.com/ Prometheus: https://prometheus.io/ PromLabs YouTube Channel: https://www.youtube.com/@PromLabs PromLabs Trainngs: https://training.promlabs.com/ Large-scale cluster management at Google with Borg: https://static.googleusercontent.com/media/research.google.com/de//pubs/archive/43438.pdf Soundcloud: https://soundcloud.com/ Prometheus: The Documentary https://www.youtube.com/watch?v=rT4fJNbfe14 Demo-Metriken: https://demo.promlabs.com/metrics Engineering Kiosk Episode #101 Observability und OpenTelemetry mit Severin Neumann: https://engineeringkiosk.dev/ep101 Sprungmarken (00:00:00) Prometheus mit Julius Volz (00:07:58) Was ist Prometheus? (00:16:24) Observability, Service Discovery (00:21:04) Selbstentwicklung eines Monitoring-Tools innerhalb einer Audio-Firma (00:27:33) MVP und Inspiration von Borgmon (00:34:17) Pull- vs. Push-Modell (00:53:28) PromQL und der Vergleich zu SQL (01:01:59) Visualisierung von Metriken (01:04:48) Flaws in Prometheus (01:13:30) Wie steige ich ins Thema Prometheus ein? Hosts Wolfgang Gassler (https://mastodon.social/@woolf) Andy Grunwald (https://twitter.com/andygrunwald) Feedback EngKiosk Community: https://engineeringkiosk.dev/join-discord Buy us a coffee: https://engineeringkiosk.dev/kaffee Email: stehtisch@engineeringkiosk.dev LinkedIn: https://www.linkedin.com/company/engineering-kiosk/ Mastodon: https://podcasts.social/@engkiosk Twitter: https://twitter.com/EngKiosk

Ich habe Equity von meinem Arbeitgeber … Doch was bedeutet dies eigentlich? Knowledge-Worker im Tech-Bereich kommen oft in den Genuss einer guten Vergütung. In der Regel hat die Vergütung bei Startups neben dem Basis-Gehalt auch noch sogenannte Equity - also Firmenanteile. Die Idee? Die Motivation und Zielsetzung von Mitarbeitern und Gründern zu vereinen und jeden Mitarbeiter am Gewinn, im Falle eines Börsengangs, zu beteiligen. Obwohl die ganze Thematik recht simpel klingt, kann dies sehr undurchsichtig sein. ESOPs, VSOPs, Cliff, Strike Price, Options, Exercise Window, Liquidationspräferenz, Verwässerung, und und und. Die Buzzword-Bingo Karte ist recht schnell voll. Mit Hilfe des Angel-Investors Philipp “Pip” Klöckner versuchen wir, etwas Licht ins Dunkle zu bringen. Pip beschäftigt sich fast täglich mit Firmenanteilen und kennt die Szene in und auswendig. Das schnelle Feedback zur Episode: 👍 (top) 👎 (geht so) Feedback EngKiosk Community: https://engineeringkiosk.dev/join-discord Buy us a coffee: https://engineeringkiosk.dev/kaffee Email: stehtisch@engineeringkiosk.dev LinkedIn: https://www.linkedin.com/company/engineering-kiosk/ Mastodon: https://podcasts.social/@engkiosk Twitter: https://twitter.com/EngKiosk Gerne behandeln wir auch euer Audio Feedback in einer der nächsten Episoden, einfach die Audiodatei per Email an stehtisch@engineeringkiosk.dev. Links Philipp Klöckner auf LinkedIn: https://www.linkedin.com/in/kloeckner/ Doppelgänger Podcast: https://www.doppelgaenger.io/ Wo wir in Sachen KI wirklich stehen und was uns erwartet: Deep Dive mit Philipp "Pip" Klöckner: https://www.youtube.com/watch?v=-srCUoQnB2o ESOP/VSOP: https://gruenderplattform.de/startup-gruenden/esop-vsop Revolut Share Sale: https://news.sky.com/story/employees-at-fintech-giant-revolut-to-cash-in-with-500m-share-sale-13138225 Canva Share Sale: https://www.linkedin.com/posts/goldman-sachs-investment-banking_mission-empower-everyone-in-the-world-to-activity-7197329900242878465-UKhf/ Engineering Kiosk Episode #127 Imposter-Syndrom & Peter-Prinzip mit Dr. Fanny Jimenez: https://engineeringkiosk.dev/podcast/episode/127-imposter-syndrom-peter-prinzip-mit-dr-fanny-jimenez/ Engineering Kiosk Episode #28 O(1), O(log n), O(n^2) - Ist die Komplexität von Algorithmen im Entwickler-Alltag relevant?: https://engineeringkiosk.dev/podcast/episode/28-o1-olog-n-on2-ist-die-komplexit%C3%A4t-von-algorithmen-im-entwickler-alltag-relevant/ Engineering Kiosk Episode #46 Welches Problem löst Docker?: https://engineeringkiosk.dev/podcast/episode/46-welches-problem-l%C3%B6st-docker/ Engineering Kiosk Episode #05 Team Lead - der einzige Ausweg: https://engineeringkiosk.dev/podcast/episode/05-team-lead-der-einzige-ausweg/ Alle Episoden vom Engineering Kiosk: https://engineeringkiosk.dev/podcast/ Sprungmarken (00:00:00) Intro (00:01:03) Equity mit Philipp "Pip" Klöckner (00:08:43) Warum geben Firmen Anteile an Mitarbeiter? Wie verbreitet ist dies? (00:19:16) Info/Werbung (00:20:13) Geld vs. Firmenanteile - Existiert ein Risiko? (00:22:21) Equity Explained: RSUs, ESOPs und VSOPs (00:34:27) Buzzword-Bingo: Vesting, Cliff, Waiting Period, Strike Price (00:47:27) Negative Seiten von Equity: Liquidationspräferenz, Verwässerung und Downrounds (00:58:47) Golden Handcuffs und erfolgreiche Mitarbeiter (01:05:10) Liquiditätsevent: IPOs und Secondary Sales Hosts Wolfgang Gassler (https://mastodon.social/@woolf) Andy Grunwald (https://twitter.com/andygrunwald) Feedback EngKiosk Community: https://engineeringkiosk.dev/join-discord Buy us a coffee: https://engineeringkiosk.dev/kaffee Email: stehtisch@engineeringkiosk.dev LinkedIn: https://www.linkedin.com/company/engineering-kiosk/ Mastodon: https://podcasts.social/@engkiosk Twitter: https://twitter.com/EngKiosk

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: 👍 (top) 👎 (geht so) Feedback EngKiosk Community: https://engineeringkiosk.dev/join-discord Buy us a coffee: https://www.buymeacoffee.com/engineeringkiosk Email: stehtisch@engineeringkiosk.dev LinkedIn: https://www.linkedin.com/company/engineering-kiosk/ Mastodon: https://podcasts.social/@engkiosk Twitter: https://twitter.com/EngKiosk Gerne behandeln wir auch euer Audio Feedback in einer der nächsten Episoden, einfach die Audiodatei per Email an stehtisch@engineeringkiosk.dev. Links Robin Titus auf LinkedIn: https://www.linkedin.com/in/robin-titus-product-design/ Double Diamond (Designprozessmodell): https://de.wikipedia.org/wiki/Double_Diamond_(Designprozessmodell) Crafting The First Mile Of Product: https://medium.com/positiveslope/crafting-the-first-mile-of-product-7ed25e8f1027 Core Concept: The Product Trio: https://www.producttalk.org/2021/05/product-trio/ Was ist Design Thinking?: https://hpi-academy.de/design-thinking/was-ist-design-thinking/ 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 Wolfgang Gassler (https://mastodon.social/@woolf) Andy Grunwald (https://twitter.com/andygrunwald) Feedback EngKiosk Community: https://engineeringkiosk.dev/join-discord Buy us a coffee: https://www.buymeacoffee.com/engineeringkiosk Email: stehtisch@engineeringkiosk.dev LinkedIn: https://www.linkedin.com/company/engineering-kiosk/ Mastodon: https://podcasts.social/@engkiosk Twitter: https://twitter.com/EngKiosk

Vergiss Datenbanken - Benutze mehr Files! Warum denkst du eigentlich, dass du eine Datenbank brauchst? Würde deine Applikationskomplexität nicht deutlich niedriger sein, wenn du alles in einer Datei abspeichern würdest? Hast du wirklich so dynamische Daten? Liest du deine Daten nicht deutlich öfter, als dass du diese schreibst? Und macht die Datenbank deine Applikation nicht langsamer? Mit dieser steilen These kommt Wolfgang um die Ecke. Obwohl dies gegen alles geht, was wir sonst normalerweise so lernen und beigebracht bekommen. Und das von jemandem, der in dem Bereich Datenbanken studiert hat. Darum geht es in dieser Episode. Bonus: 1 Jahr Engineering Kiosk Alps Meetup. **** Diese Episode wird gesponsert von WeAreDevelopers World Congress Nimm am WeAreDevelopers World Congress teil, der weltweit führenden Veranstaltung für Entwickler*innen vom 17. bis 19. Juli 2024 in Berlin. WeAreDevelopers begrüßt 15.000+ Entwickler*innen und 500+ Speaker zu einem unvergesslichen Event in diesem Sommer. Nutze unseren exklusiven Rabattcode "WWC_EngineeringKiosk15" für 15% Rabatt. Zu den Speakern gehören: Scott Hanselman, Scott Farquhar, Douglas Crockford, Thomas Dohmke, Demetris Cheatham, John & Brenda Romero, Prashanth Chandrasekar, Madona Wambua, Jonas Andrulis, Denis Yarats, Scott Chacon und viele mehr! Mehr Infos unter https://worldcongress.dev/ Hier geht es zum Gewinnspiel: https://www.linkedin.com/feed/update/urn:li:share:7211263176640729088/ **** Das schnelle Feedback zur Episode: 👍 (top) 👎 (geht so) Feedback EngKiosk Community: https://engineeringkiosk.dev/join-discord Buy us a coffee: https://engineeringkiosk.dev/kaffee Email: stehtisch@engineeringkiosk.dev LinkedIn: https://www.linkedin.com/company/engineering-kiosk/ Mastodon: https://podcasts.social/@engkiosk Twitter: https://twitter.com/EngKiosk Gerne behandeln wir auch euer Audio Feedback in einer der nächsten Episoden, einfach die Audiodatei per Email an stehtisch@engineeringkiosk.dev. Links Wolfi’s Vortag “Forget databases - use files!”: https://docs.google.com/presentation/d/e/2PACX-1vRRtmoWcNUgnCb2kbnVQWiS0R1NlVrGenp_V42HS3GOuXvfO4IRLKZ1eX94gyerV-6awH1k6Xrc4Xhi/pub Perfomance Tests zu Wolfi’s Vortrag: https://github.com/woolfg/no-dbms-use-files/ 1 billion row challenge: https://github.com/gunnarmorling/1brc HackerNews-Kommentar über erfahrene Entwickler*innen: https://news.ycombinator.com/item?id=21377349 tailscale blog “An unlikely database migration”: https://tailscale.com/blog/an-unlikely-database-migration LinkedIn-Post zum WeAreDevelopers World Congress Gewinnspiel: https://www.linkedin.com/feed/update/urn:li:share:7211263176640729088/ Sprungmarken (00:00:00) Happy Birthday zu 1 Jahr Engineering Kiosk Meetup Alps (00:03:05) Gewinnspiel WeAreDevelopers World Congress (00:04:19) Happy Birthday zu 1 Jahr Engineering Kiosk Meetup Alps (00:13:19) Migrationen, Deployments und Schema-Versionierung (00:20:17) tailscale, sqlite, JSON-Files und etcd (00:27:00) Files sind schneller als Datenbanken (00:30:56) Mehrdimensionale Daten und Relationen (00:35:34) Schreibzugriffe und Schema-Sicherheit (00:39:56) Performance-Overhead, Files zu parsen (00:47:49) File as a Service und sqlite (00:54:04) Das schlechte Gefühl, ein Junior zu sein Hosts Wolfgang Gassler (https://mastodon.social/@woolf) Andy Grunwald (https://twitter.com/andygrunwald) Feedback EngKiosk Community: https://engineeringkiosk.dev/join-discord Buy us a coffee: https://engineeringkiosk.dev/kaffee Email: stehtisch@engineeringkiosk.dev LinkedIn: https://www.linkedin.com/company/engineering-kiosk/ Mastodon: https://podcasts.social/@engkiosk Twitter: https://twitter.com/EngKiosk

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: 👍 (top) 👎 (geht so)! Feedback EngKiosk Community: https://engineeringkiosk.dev/join-discord Buy us a coffee: https://www.buymeacoffee.com/engineeringkiosk Email: stehtisch@engineeringkiosk.dev LinkedIn: https://www.linkedin.com/company/engineering-kiosk/ Mastodon: https://podcasts.social/@engkiosk Twitter: https://twitter.com/EngKiosk Gerne behandeln wir auch euer Audio Feedback in einer der nächsten Episoden, einfach die Audiodatei per Email an stehtisch@engineeringkiosk.dev. Links Dynamo - Amazon’s Highly Available Key Value Store: https://www.allthingsdistributed.com/files/amazon-dynamo-sosp2007.pdf Google File System: Insights into a highly scalable file system: https://static.googleusercontent.com/media/research.google.com/de//archive/gfs-sosp2003.pdf Scaling Memcached at Facebook: A look at the complexities of Caching: https://www.usenix.org/system/files/conference/nsdi13/nsdi13-final170_update.pdf Borg - Large Scale Cluster Management at Google: https://static.googleusercontent.com/media/research.google.com/de//pubs/archive/43438.pdf Cassandra: A look at the design and architecture of a distributed NoSQL database: https://www.cs.cornell.edu/projects/ladis2009/papers/lakshman-ladis2009.pdf Kafka: Internals of the distributed messaging platform: https://notes.stephenholiday.com/Kafka.pdf Spanner: Design and architecture of Google’s globally distributed database: https://static.googleusercontent.com/media/research.google.com/de//archive/spanner-osdi2012.pdf MapReduce: A detailed look at how MapReduce enables parallel processing of massive volumes of data: https://static.googleusercontent.com/media/research.google.com/de//archive/mapreduce-osdi04.pdf Bitcoin: The ground-breaking introduction to the peer-to-peer electronic cash system: https://www.ussc.gov/sites/default/files/pdf/training/annual-national-training-seminar/2018/Emerging_Tech_Bitcoin_Crypto.pdf MyRocks: LSM-Tree Database Storage Engine: https://www.vldb.org/pvldb/vol13/p3217-matsunobu.pdf Raft Consensus Algorithm: To learn about the more understandable consensus algorithm: https://web.stanford.edu/~ouster/cgi-bin/papers/raft-atc14.pdf Time Clocks and Ordering of Events: The extremely important paper that explains the concept of time and event ordering in a distributed system: https://lamport.azurewebsites.net/pubs/time-clocks.pdf Two Minute Papers YouTube Channel: https://www.youtube.com/@TwoMinutePapers Organization and Maintenance of Large Ordered Indexes: https://www.inf.fu-berlin.de/lehre/SS10/DBS-Intro/Reader/BayerBTree-72.pdf ACM Conference Series on Recommender Systems: https://recsys.acm.org/recsys23/workshops/ Google Scholar: https://scholar.google.com/ dblp: https://dblp.org/ Wikicfp: http://www.wikicfp.com/cfp/ SIG Special Interest Groups: https://en.wikipedia.org/wiki/Special_interest_group Papers we love: https://paperswelove.org/ Papers we love auf GitHub: https://github.com/papers-we-love/papers-we-love 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 Wolfgang Gassler (https://mastodon.social/@woolf) Andy Grunwald (https://twitter.com/andygrunwald) Feedback EngKiosk Community: https://engineeringkiosk.dev/join-discord Buy us a coffee: https://www.buymeacoffee.com/engineeringkiosk Email: stehtisch@engineeringkiosk.dev LinkedIn: https://www.linkedin.com/company/engineering-kiosk/ Mastodon: https://podcasts.social/@engkiosk Twitter: https://twitter.com/EngKiosk

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: 👍 (top) 👎 (geht so) Feedback EngKiosk Community: https://engineeringkiosk.dev/join-discord Buy us a coffee: https://www.buymeacoffee.com/engineeringkiosk Email: stehtisch@engineeringkiosk.dev LinkedIn: https://www.linkedin.com/company/engineering-kiosk/ Mastodon: https://podcasts.social/@engkiosk Twitter: https://twitter.com/EngKiosk Gerne behandeln wir auch euer Audio Feedback in einer der nächsten Episoden, einfach die Audiodatei per Email an stehtisch@engineeringkiosk.dev. Links Fanny Jimenez auf LinkedIn: https://www.linkedin.com/in/dr-fanny-jimenez-3055a0188/ Fanny Jimenez auf Instagram: https://www.instagram.com/fannyjimenezofficial/ Hochstapler-Syndrom auf Wikipedia: https://de.wikipedia.org/wiki/Hochstapler-Syndrom Dunning-Kruger-Effekt auf Wikipedia: https://de.wikipedia.org/wiki/Dunning-Kruger-Effekt Peter Prinzip auf Wikipedia: https://de.wikipedia.org/wiki/Peter-Prinzip Never Mind Podcast: https://www.businessinsider.de/podcasts/never-mind/ Buch “Ich und mein Spleen: Was wir tun, wenn wir alleine sind”: https://www.amazon.de/Ich-mein-Spleen-wenn-alleine/dp/3406698328/ 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 Wolfgang Gassler (https://mastodon.social/@woolf) Andy Grunwald (https://twitter.com/andygrunwald) Feedback EngKiosk Community: https://engineeringkiosk.dev/join-discord Buy us a coffee: https://www.buymeacoffee.com/engineeringkiosk Email: stehtisch@engineeringkiosk.dev LinkedIn: https://www.linkedin.com/company/engineering-kiosk/ Mastodon: https://podcasts.social/@engkiosk Twitter: https://twitter.com/EngKiosk

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: 👍 (top) 👎 (geht so) Feedback EngKiosk Community: https://engineeringkiosk.dev/join-discord Buy us a coffee: https://www.buymeacoffee.com/engineeringkiosk Email: stehtisch@engineeringkiosk.dev LinkedIn: https://www.linkedin.com/company/engineering-kiosk/ Mastodon: https://podcasts.social/@engkiosk Twitter: https://twitter.com/EngKiosk Gerne behandeln wir auch euer Audio Feedback in einer der nächsten Episoden, einfach die Audiodatei per Email an stehtisch@engineeringkiosk.dev. Links Sebastian Bergmann: https://sebastian-bergmann.de/ Sebastian Bergmann auf LinkedIn: https://www.linkedin.com/in/sebastian-bergmann-phpunit/ The PHP Consulting Company: https://thephp.cc/ PHPUnit: https://phpunit.de/ Sebastian Bergmann Amiga Retrocomputing: https://amiga.sebastian-bergmann.de/ Sebastian Bergmann's Boardgame Collection: https://sebastian-bergmann.de/boardgames.html YAM (short for 'Yet Another Mailer') für Amiga: https://github.com/jens-maus/yam Chrysler Comprehensive Compensation project: https://www.martinfowler.com/bliki/C3.html End-to-End-Testing Framework PlayWright: https://playwright.dev/ Infection - PHP Mutation Testing Framework: https://infection.github.io/ Mutation testing systems for Java compared: https://pitest.org/java_mutation_testing_systems/ Bretterwisser - Boardgame Podcast: https://bretterwisser.de/ 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 Wolfgang Gassler (https://mastodon.social/@woolf) Andy Grunwald (https://twitter.com/andygrunwald) Feedback EngKiosk Community: https://engineeringkiosk.dev/join-discord Buy us a coffee: https://www.buymeacoffee.com/engineeringkiosk Email: stehtisch@engineeringkiosk.dev LinkedIn: https://www.linkedin.com/company/engineering-kiosk/ Mastodon: https://podcasts.social/@engkiosk Twitter: https://twitter.com/EngKiosk

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: 👍 (top) 👎 (geht so) Feedback EngKiosk Community: https://engineeringkiosk.dev/join-discord Buy us a coffee: https://www.buymeacoffee.com/engineeringkiosk Email: stehtisch@engineeringkiosk.dev LinkedIn: https://www.linkedin.com/company/engineering-kiosk/ Mastodon: https://podcasts.social/@engkiosk Twitter: https://twitter.com/EngKiosk Gerne behandeln wir auch euer Audio Feedback in einer der nächsten Episoden, einfach die Audiodatei per Email an stehtisch@engineeringkiosk.dev. Links Jana Aydinbas auf LinkedIn: https://www.linkedin.com/in/jana-aydinbas/ Google Season of Docs: https://developers.google.com/season-of-docs?hl=de Vortrag: Daniele Procida - Always complete, never finished: https://www.writethedocs.org/videos/portland/2021/always-complete-never-finished-daniele-procida/ Write the Docs Website: https://www.writethedocs.org/ Write the Docs Slack: https://www.writethedocs.org/slack/ Write the Docs Guide: https://www.writethedocs.org/guide/writing/beginners-guide-to-docs/ Write the Docs Meetups: https://www.writethedocs.org/meetups/ Diátaxis (Framework für Softwaredokumentation): https://diataxis.fr/ The Good Docs Project (Templates, Prozesse und Beispiele): https://thegooddocsproject.dev/ 5C’s of Technical Writing: https://medium.com/technical-writing-is-easy/5cs-of-technical-writing-7e5039917801 Stripe Documentation: https://docs.stripe.com/ React Quickstart Guide: https://react.dev/learn tekom “Was ist technische Kommunikation?”: https://www.tekom.de/technische-kommunikation-das-fach/was-ist-technische-kommunikation 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 Wolfgang Gassler (https://mastodon.social/@woolf) Andy Grunwald (https://twitter.com/andygrunwald) Feedback EngKiosk Community: https://engineeringkiosk.dev/join-discord Buy us a coffee: https://www.buymeacoffee.com/engineeringkiosk Email: stehtisch@engineeringkiosk.dev LinkedIn: https://www.linkedin.com/company/engineering-kiosk/ Mastodon: https://podcasts.social/@engkiosk Twitter: https://twitter.com/EngKiosk

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: 👍 (top) 👎 (geht so) Feedback EngKiosk Community: https://engineeringkiosk.dev/joindiscord Buy us a coffee: https://www.buymeacoffee.com/engineeringkiosk Email: stehtisch@engineeringkiosk.dev LinkedIn: https://www.linkedin.com/company/engineeringkiosk/ Mastodon: https://podcasts.social/@engkiosk Twitter: https://twitter.com/EngKiosk Gerne behandeln wir auch euer Audio Feedback in einer der nächsten Episoden, einfach die Audiodatei per Email an stehtisch@engineeringkiosk.dev. Links Engineering Kiosk #85 Von Entwicklerin zur Engineering Managerin: Erfahrungen und Learnings mit Isabelle Glasmacher: https://engineeringkiosk.dev/podcast/episode/85-von-entwicklerin-zur-engineering-managerin-erfahrungen-und-learnings-mit-isabelle-glasmacher/ Engineering Kiosk Episode #112 Das Engineering Manager Pendulum: Zwischen Coding und Leadership mit Tom Bartel: https://engineeringkiosk.dev/podcast/episode/112-das-engineering-manager-pendulum-zwischen-coding-und-leadership-mit-tom-bartel/ Engineering Kiosk Episode #51 Was ist das Staff (Engineer) Level?: https://engineeringkiosk.dev/podcast/episode/51-was-ist-das-staff-engineer-level/ German Tech Podcast Liste: https://engineeringkiosk.dev/deutsche-tech-podcasts/ Udemy: https://www.udemy.com Coursera: https://www.coursera.org O'Reilly Library: https://www.oreilly.com/online-learning/teams.html Hacker News: https://news.ycombinator.com Pragmatic Engineer Newsletter: https://newsletter.pragmaticengineer.com Advent of Code: https://adventofcode.com SadServers: https://sadservers.com/ 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 Wolfgang Gassler (https://mastodon.social/@woolf) Andy Grunwald (https://twitter.com/andygrunwald) Feedback EngKiosk Community: https://engineeringkiosk.dev/joindiscord Buy us a coffee: https://www.buymeacoffee.com/engineeringkiosk Email: stehtisch@engineeringkiosk.dev LinkedIn: https://www.linkedin.com/company/engineeringkiosk/ Mastodon: https://podcasts.social/@engkiosk Twitter: https://twitter.com/EngKiosk

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: 👍 (top) 👎 (geht so) Feedback EngKiosk Community: https://engineeringkiosk.dev/join-discord Buy us a coffee: https://www.buymeacoffee.com/engineeringkiosk Email: stehtisch@engineeringkiosk.dev LinkedIn: https://www.linkedin.com/company/engineering-kiosk/ Mastodon: https://podcasts.social/@engkiosk Twitter: https://twitter.com/EngKiosk Gerne behandeln wir auch euer Audio Feedback in einer der nächsten Episoden, einfach die Audiodatei per Email an stehtisch@engineeringkiosk.dev. Links Hendrik Kleinwächter: https://www.hkleinwaechter.com/ theBread.code(); https://www.the-bread-code.io/ The Sourdough Framework: https://www.the-sourdough-framework.com/ The Bread Code auf YouTube: https://www.youtube.com/@the_bread_code dyve Purpose Unternehmen: https://dyve.agency/de/steward-ownership The Bread Code auf GitHub: https://github.com/hendricius/the-bread-code Pizza Dough auf GitHub: https://github.com/hendricius/pizza-dough The Sourdough Framework auf GitHub: https://github.com/hendricius/the-sourdough-framework OMR Podcast: https://omr.com/de/podcast Kassenzone Podcast: https://www.kassenzone.de/ Simple Flatbread Recipe: https://www.the-sourdough-framework.com/Breadtypes.html#simple-flatbread-recipe 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 Wolfgang Gassler (https://mastodon.social/@woolf) Andy Grunwald (https://twitter.com/andygrunwald) Feedback EngKiosk Community: https://engineeringkiosk.dev/join-discord Buy us a coffee: https://www.buymeacoffee.com/engineeringkiosk Email: stehtisch@engineeringkiosk.dev LinkedIn: https://www.linkedin.com/company/engineering-kiosk/ Mastodon: https://podcasts.social/@engkiosk Twitter: https://twitter.com/EngKiosk

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: 👍 (top) 👎 (geht so) Feedback EngKiosk Community: https://engineeringkiosk.dev/join-discord Buy us a coffee: https://engineeringkiosk.dev/kaffee Email: stehtisch@engineeringkiosk.dev LinkedIn: https://www.linkedin.com/company/engineering-kiosk/ Mastodon: https://podcasts.social/@engkiosk Twitter: https://twitter.com/EngKiosk Gerne behandeln wir auch euer Audio Feedback in einer der nächsten Episoden, einfach die Audiodatei per Email an stehtisch@engineeringkiosk.dev. Links Why I Quit Google to Work for Myself https://mtlynch.io/why-i-quit-google/ Killed by Google: https://killedbygoogle.com/ Spotify Engineering Culture (aka the "Spotify Model"): https://www.youtube.com/watch?v=Yvfz4HGtoPc How we structure our work and teams at Basecamp: https://medium.com/signal-v-noise/how-we-set-up-our-work-cbce3d3d9cae Brooks’ Law: https://www.leadingagile.com/2018/02/lines-of-communication-team-size-applying-brooks-law/ Gesetz von Conway: https://de.wikipedia.org/wiki/Gesetz_von_Conway Concepts I use every day: BAPO: https://medium.com/nerd-for-tech/concepts-i-use-every-day-bapo-896d0ba0ccbb Coordination models - tools for getting groups to work well together: https://www.rubick.com/coordination-models/ 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 Wolfgang Gassler (https://mastodon.social/@woolf) Andy Grunwald (https://twitter.com/andygrunwald) Feedback EngKiosk Community: https://engineeringkiosk.dev/join-discord Buy us a coffee: https://engineeringkiosk.dev/kaffee Email: stehtisch@engineeringkiosk.dev LinkedIn: https://www.linkedin.com/company/engineering-kiosk/ Mastodon: https://podcasts.social/@engkiosk Twitter: https://twitter.com/EngKiosk