Engineering Kiosk

Eine (Schalt)-Sekunde kann für ganz schön viele Probleme sorgenAlle 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 findenDas schnelle Feedback zur Episode:👍 (top) 👎 (geht so)FeedbackEngKiosk Community: https://engineeringkiosk.dev/join-discord Buy us a coffee: https://engineeringkiosk.dev/kaffeeEmail: stehtisch@engineeringkiosk.devLinkedIn: https://www.linkedin.com/company/engineering-kiosk/Mastodon: https://podcasts.social/@engkioskTwitter: https://twitter.com/EngKioskGerne behandeln wir auch euer Audio Feedback in einer der nächsten Episoden, einfach die Audiodatei per Email an stehtisch@engineeringkiosk.dev.LinksSchaltsekunde: 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.690007ITU in 2015 - Coordinated Universal Time (UTC) to retain “leap second”: https://www.itu.int/net/pressoffice/press_releases/2015/53.aspxProblematic 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-secondThe 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/smearAWS - 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.pdfUnsmear-Library (C++) von Google: https://github.com/google/unsmearMeta - 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.listNTP 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-consistencyThe Unix leap second mess: http://www.madore.org/~david/computers/unix-leap-seconds.htmlIssues involved in computer time stamps and leap seconds: https://www.ucolick.org/~sla/leapsecs/picktwo.htmlSprungmarken(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 SchaltsekundeHostsWolfgang Gassler (https://mastodon.social/@woolf)Andy Grunwald (https://twitter.com/andygrunwald)FeedbackEngKiosk Community: https://engineeringkiosk.dev/join-discord Buy us a coffee: https://engineeringkiosk.dev/kaffeeEmail: stehtisch@engineeringkiosk.devLinkedIn: https://www.linkedin.com/company/engineering-kiosk/Mastodon: https://podcasts.social/@engkioskTwitter: 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)FeedbackEngKiosk Community: https://engineeringkiosk.dev/join-discord Buy us a coffee: https://engineeringkiosk.dev/kaffeeEmail: stehtisch@engineeringkiosk.devLinkedIn: https://www.linkedin.com/company/engineering-kiosk/Mastodon: https://podcasts.social/@engkioskTwitter: https://twitter.com/EngKioskGerne behandeln wir auch euer Audio Feedback in einer der nächsten Episoden, einfach die Audiodatei per Email an stehtisch@engineeringkiosk.dev.LinksPatrick 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-conditionsVideos 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 anfangenHostsWolfgang Gassler (https://mastodon.social/@woolf)Andy Grunwald (https://twitter.com/andygrunwald)FeedbackEngKiosk Community: https://engineeringkiosk.dev/join-discord Buy us a coffee: https://engineeringkiosk.dev/kaffeeEmail: stehtisch@engineeringkiosk.devLinkedIn: https://www.linkedin.com/company/engineering-kiosk/Mastodon: https://podcasts.social/@engkioskTwitter: https://twitter.com/EngKiosk

Design Documents und Request for Comments (RFCs): Die Engineering Art der PlanungsphaseWir 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)FeedbackEngKiosk Community: https://engineeringkiosk.dev/join-discord Buy us a coffee: https://www.buymeacoffee.com/engineeringkioskEmail: stehtisch@engineeringkiosk.devLinkedIn: https://www.linkedin.com/company/engineering-kiosk/Mastodon: https://podcasts.social/@engkioskTwitter: https://twitter.com/EngKioskGerne behandeln wir auch euer Audio Feedback in einer der nächsten Episoden, einfach die Audiodatei per Email an stehtisch@engineeringkiosk.dev.LinksRFC 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.comRFC Proposal von SourceGraph: https://docs.google.com/document/d/1zInJ9mn_SePKjS8dLHS1EDt2_gUEkCKD544bDDSuJek/edit#heading=h.trqab8y0kufpRFC Process von SoundCloud: https://philcalcado.com/2018/11/19/a_structured_rfc_process.htmlRFCs von RazorPay: https://github.com/razorpay/blade/tree/master/rfcsRFCs von Couchbase: https://github.com/couchbaselabs/sdk-rfcs/tree/master/rfcHow 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-LinksKafka Improvement Proposals (KIP): https://cwiki.apache.org/confluence/display/KAFKA/Kafka+Improvement+ProposalsInternet 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_1Sprungmarken(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-FatigueHostsWolfgang Gassler (https://mastodon.social/@woolf)Andy Grunwald (https://twitter.com/andygrunwald)FeedbackEngKiosk Community: https://engineeringkiosk.dev/join-discord Buy us a coffee: https://www.buymeacoffee.com/engineeringkioskEmail: stehtisch@engineeringkiosk.devLinkedIn: https://www.linkedin.com/company/engineering-kiosk/Mastodon: https://podcasts.social/@engkioskTwitter: 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)FeedbackEngKiosk Community: https://engineeringkiosk.dev/join-discord Buy us a coffee: https://engineeringkiosk.dev/kaffeeEmail: stehtisch@engineeringkiosk.devLinkedIn: https://www.linkedin.com/company/engineering-kiosk/Mastodon: https://podcasts.social/@engkioskTwitter: https://twitter.com/EngKioskGerne behandeln wir auch euer Audio Feedback in einer der nächsten Episoden, einfach die Audiodatei per Email an stehtisch@engineeringkiosk.dev.LinksDaniel Stenberg “Thank you Crowdstrike for helping to illustrate that Open Source is not the problem”: https://mastodon.social/@bagder/112812252225104999Daniel 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/1192Open Source is Not About You: https://gist.github.com/richhickey/1563cddea1002958f96e7ba9519972d9Vereine 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.htmlOpen 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 gebenHostsWolfgang Gassler (https://mastodon.social/@woolf)Andy Grunwald (https://twitter.com/andygrunwald)FeedbackEngKiosk Community: https://engineeringkiosk.dev/join-discord Buy us a coffee: https://engineeringkiosk.dev/kaffeeEmail: stehtisch@engineeringkiosk.devLinkedIn: https://www.linkedin.com/company/engineering-kiosk/Mastodon: https://podcasts.social/@engkioskTwitter: https://twitter.com/EngKiosk

1on1s: Ein starkes Tool - Auch zum halten von MitarbeiternMitarbeiter 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)FeedbackEngKiosk Community: https://engineeringkiosk.dev/join-discord Buy us a coffee: https://engineeringkiosk.dev/kaffeeEmail: stehtisch@engineeringkiosk.devLinkedIn: https://www.linkedin.com/company/engineering-kiosk/Mastodon: https://podcasts.social/@engkioskTwitter: https://twitter.com/EngKioskGerne behandeln wir auch euer Audio Feedback in einer der nächsten Episoden, einfach die Audiodatei per Email an stehtisch@engineeringkiosk.dev.LinksEngineering 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 einfachHostsWolfgang Gassler (https://mastodon.social/@woolf)Andy Grunwald (https://twitter.com/andygrunwald)FeedbackEngKiosk Community: https://engineeringkiosk.dev/join-discord Buy us a coffee: https://engineeringkiosk.dev/kaffeeEmail: stehtisch@engineeringkiosk.devLinkedIn: https://www.linkedin.com/company/engineering-kiosk/Mastodon: https://podcasts.social/@engkioskTwitter: https://twitter.com/EngKiosk

Überwachen von Applikationen in Zeiten von dynamischer InfrastrukturCloud 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)FeedbackEngKiosk Community: https://engineeringkiosk.dev/join-discord Buy us a coffee: https://engineeringkiosk.dev/kaffeeEmail: stehtisch@engineeringkiosk.devLinkedIn: https://www.linkedin.com/company/engineering-kiosk/Mastodon: https://podcasts.social/@engkioskTwitter: https://twitter.com/EngKioskGerne behandeln wir auch euer Audio Feedback in einer der nächsten Episoden, einfach die Audiodatei per Email an stehtisch@engineeringkiosk.dev.LinksJulius Volz: https://juliusv.com/Prometheus: https://prometheus.io/PromLabs YouTube Channel: https://www.youtube.com/@PromLabsPromLabs 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.pdfSoundcloud: https://soundcloud.com/Prometheus: The Documentary https://www.youtube.com/watch?v=rT4fJNbfe14 Demo-Metriken: https://demo.promlabs.com/metricsEngineering Kiosk Episode #101 Observability und OpenTelemetry mit Severin Neumann: https://engineeringkiosk.dev/ep101Sprungmarken(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?HostsWolfgang Gassler (https://mastodon.social/@woolf)Andy Grunwald (https://twitter.com/andygrunwald)FeedbackEngKiosk Community: https://engineeringkiosk.dev/join-discord Buy us a coffee: https://engineeringkiosk.dev/kaffeeEmail: stehtisch@engineeringkiosk.devLinkedIn: https://www.linkedin.com/company/engineering-kiosk/Mastodon: https://podcasts.social/@engkioskTwitter: https://twitter.com/EngKiosk

Philipp 'Pip' Klöckner, Experte für Equity in Tech-Startups, erklärt die komplexe Welt der Mitarbeiterbeteiligung am Beispiel von Startups. Von ESOPs über VSOPs bis hin zur Motivation von Mitarbeitern durch Aktienoptionen. Diskussion über die Bedeutung von Verhandlungen über Gehalt und Leistungen im Arbeitsumfeld.

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 BreakfastDas schnelle Feedback zur Episode:👍 (top) 👎 (geht so)FeedbackEngKiosk Community: https://engineeringkiosk.dev/join-discord Buy us a coffee: https://www.buymeacoffee.com/engineeringkioskEmail: stehtisch@engineeringkiosk.devLinkedIn: https://www.linkedin.com/company/engineering-kiosk/Mastodon: https://podcasts.social/@engkioskTwitter: https://twitter.com/EngKioskGerne behandeln wir auch euer Audio Feedback in einer der nächsten Episoden, einfach die Audiodatei per Email an stehtisch@engineeringkiosk.dev.LinksRobin 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-7ed25e8f1027Core 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 AirbnbHostsWolfgang Gassler (https://mastodon.social/@woolf)Andy Grunwald (https://twitter.com/andygrunwald)FeedbackEngKiosk Community: https://engineeringkiosk.dev/join-discord Buy us a coffee: https://www.buymeacoffee.com/engineeringkioskEmail: stehtisch@engineeringkiosk.devLinkedIn: https://www.linkedin.com/company/engineering-kiosk/Mastodon: https://podcasts.social/@engkioskTwitter: 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)FeedbackEngKiosk Community: https://engineeringkiosk.dev/join-discord Buy us a coffee: https://engineeringkiosk.dev/kaffeeEmail: stehtisch@engineeringkiosk.devLinkedIn: https://www.linkedin.com/company/engineering-kiosk/Mastodon: https://podcasts.social/@engkioskTwitter: https://twitter.com/EngKioskGerne behandeln wir auch euer Audio Feedback in einer der nächsten Episoden, einfach die Audiodatei per Email an stehtisch@engineeringkiosk.dev.LinksWolfi’s Vortag “Forget databases - use files!”: https://docs.google.com/presentation/d/e/2PACX-1vRRtmoWcNUgnCb2kbnVQWiS0R1NlVrGenp_V42HS3GOuXvfO4IRLKZ1eX94gyerV-6awH1k6Xrc4Xhi/pubPerfomance Tests zu Wolfi’s Vortrag: https://github.com/woolfg/no-dbms-use-files/ 1 billion row challenge: https://github.com/gunnarmorling/1brcHackerNews-Kommentar über erfahrene Entwickler*innen: https://news.ycombinator.com/item?id=21377349tailscale blog “An unlikely database migration”: https://tailscale.com/blog/an-unlikely-database-migrationLinkedIn-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 seinHostsWolfgang Gassler (https://mastodon.social/@woolf)Andy Grunwald (https://twitter.com/andygrunwald)FeedbackEngKiosk Community: https://engineeringkiosk.dev/join-discord Buy us a coffee: https://engineeringkiosk.dev/kaffeeEmail: stehtisch@engineeringkiosk.devLinkedIn: https://www.linkedin.com/company/engineering-kiosk/Mastodon: https://podcasts.social/@engkioskTwitter: 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)!FeedbackEngKiosk Community: https://engineeringkiosk.dev/join-discord Buy us a coffee: https://www.buymeacoffee.com/engineeringkioskEmail: stehtisch@engineeringkiosk.devLinkedIn: https://www.linkedin.com/company/engineering-kiosk/Mastodon: https://podcasts.social/@engkioskTwitter: https://twitter.com/EngKioskGerne behandeln wir auch euer Audio Feedback in einer der nächsten Episoden, einfach die Audiodatei per Email an stehtisch@engineeringkiosk.dev.LinksDynamo - Amazon’s Highly Available Key Value Store: https://www.allthingsdistributed.com/files/amazon-dynamo-sosp2007.pdfGoogle File System: Insights into a highly scalable file system: https://static.googleusercontent.com/media/research.google.com/de//archive/gfs-sosp2003.pdfScaling Memcached at Facebook: A look at the complexities of Caching: https://www.usenix.org/system/files/conference/nsdi13/nsdi13-final170_update.pdfBorg - Large Scale Cluster Management at Google: https://static.googleusercontent.com/media/research.google.com/de//pubs/archive/43438.pdfCassandra: A look at the design and architecture of a distributed NoSQL database: https://www.cs.cornell.edu/projects/ladis2009/papers/lakshman-ladis2009.pdfKafka: Internals of the distributed messaging platform: https://notes.stephenholiday.com/Kafka.pdfSpanner: Design and architecture of Google’s globally distributed database: https://static.googleusercontent.com/media/research.google.com/de//archive/spanner-osdi2012.pdfMapReduce: 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.pdfBitcoin: 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.pdfMyRocks: LSM-Tree Database Storage Engine: https://www.vldb.org/pvldb/vol13/p3217-matsunobu.pdfRaft Consensus Algorithm: To learn about the more understandable consensus algorithm: https://web.stanford.edu/~ouster/cgi-bin/papers/raft-atc14.pdfTime 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.pdfTwo Minute Papers YouTube Channel: https://www.youtube.com/@TwoMinutePapersOrganization and Maintenance of Large Ordered Indexes: https://www.inf.fu-berlin.de/lehre/SS10/DBS-Intro/Reader/BayerBTree-72.pdfACM 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_groupPapers we love: https://paperswelove.org/Papers we love auf GitHub: https://github.com/papers-we-love/papers-we-loveSprungmarken(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 zusammenfassenHostsWolfgang Gassler (https://mastodon.social/@woolf)Andy Grunwald (https://twitter.com/andygrunwald)FeedbackEngKiosk Community: https://engineeringkiosk.dev/join-discord Buy us a coffee: https://www.buymeacoffee.com/engineeringkioskEmail: stehtisch@engineeringkiosk.devLinkedIn: https://www.linkedin.com/company/engineering-kiosk/Mastodon: https://podcasts.social/@engkioskTwitter: https://twitter.com/EngKiosk