POPULARITY
3 episodes with gergely orosz
3 episodes with gergely orosz
Last week, our colleague (and frequent Oxide and Friends guest) Steve Klabnik made some new friends on the Internet with a blog entry on AI discourse. Bryan and Adam were joined by Steve to try to de-polarize the discussion a little.In addition to Bryan Cantrill and Adam Leventhal, we were joined by special guest, Steve Klabnik, and valued listener, Julian Giamblanco (aka "Oatmealdealer").Some of the topics we hit on, in the order that we hit them:Steve's blog post: I am disappointed in the AI discourseOxF: A Baseball Startup with Paul Freedman and Bryan Carmel (The Ballers)OxF: Adversarial Machine Learning with Nicholas CarliniOxF: Hiring Processes with Gergely Orosz ("the RFD 3 podcast episode")OxF: AI Disruption: DeepSeek and CerebrasOxF: Reflecting on Founder Mode ("ego con")If we got something wrong or missed something, please file a PR! Our next show will likely be on Monday at 5p Pacific Time on our Discord server; stay tuned to our Mastodon feeds for details, or subscribe to this calendar. We'd love to have you join us, as we always love to hear from new speakers!
In this episode, Gergely Orosz joins Carter and Nathan to discuss his book The Software Engineer's Guidebook. Join them as Gergely reflects on the differences between writing a book and The Pragmatic Engineer newsletter, the importance of professional networks, and the state of the hiring market today!https://www.pragmaticengineer.com/-- Books Mentioned in this Episode --Note: As an Amazon Associate, we earn from qualifying purchases.----------------------------------------------------------The Software Engineer's Guidebookhttps://amzn.to/41AxMAL (Paid Link)Thinking in Systems by Donella H. Meadows https://amzn.to/4kGtmkI (Paid Link)Tidy First?: A Personal Exercise in Empirical Software Design by Kent Beckhttps://amzn.to/4bHoNCv (Paid Link)Become an Effective Software Engineering Manager: How to Be the Leader Your Development Team Needs by Dr. James Stanierhttps://amzn.to/4kCzvhD (Paid Link)The Engineering Executive's Primer: Impactful Technical Leadership by Will Larsonhttps://amzn.to/4hpRDIS (Paid Link)----------------00:00 Intro02:11 What inspired you to write the book?08:46 Gaining the Vocabulary and learning on your own13:45 Writing a Newsletter vs Writing a Book22:55 Taking initiative and Embracing Curiosity35:30 Working Remotely and Cultivating Connections41:13 Periodic Effort: Stretching, Executing, and Coasting46:41 Navigating Company Cultures50:05 The Future of Interviews: AI Cheating and the end of the Remote Interviews58:33 How the job market has changed01:05:10 Closing Thoughts Spotify: https://open.spotify.com/show/5kj6DLCEWR5nHShlSYJI5LApple Podcasts: https://podcasts.apple.com/us/podcast/book-overflow/id1745257325X: https://x.com/bookoverflowpodCarter on X: https://x.com/cartermorganNathan's Functionally Imperative: www.functionallyimperative.com----------------Book Overflow is a podcast for software engineers, by software engineers dedicated to improving our craft by reading the best technical books in the world. Join Carter Morgan and Nathan Toups as they read and discuss a new technical book each week!The full book schedule and links to every major podcast player can be found at https://www.bookoverflow.io
In this episode of Book Overflow, Carter and Nathan discuss the second half of The Software Engineer's Guidebook by Gergely Orosz. Join them as they discuss work/life balance, project management, and which computer science subreddits to avoid! (We're about 95% sure that Carter recorded with the wrong microphone accidentally, so his audio is a little rough this episode. Sorry!) -- Books Mentioned in this Episode -- Note: As an Amazon Associate, we earn from qualifying purchases. ---------------------------------------------------------- The Software Engineer's Guidebook by Gergely Orosz https://amzn.to/3C503GQ (paid link) ---------------- Spotify: https://open.spotify.com/show/5kj6DLCEWR5nHShlSYJI5L Apple Podcasts: https://podcasts.apple.com/us/podcast/book-overflow/id1745257325 X: https://x.com/bookoverflowpod Carter on X: https://x.com/cartermorgan Nathan's Functionally Imperative: www.functionallyimperative.com ---------------- Book Overflow is a podcast for software engineers, by software engineers dedicated to improving our craft by reading the best technical books in the world. Join Carter Morgan and Nathan Toups as they read and discuss a new technical book each week! The full book schedule and links to every major podcast player can be found at https://www.bookoverflow.io
In this episode of Book Overflow, Carter and Nathan discuss The Software Engineer's Guidebook by Gergely Orosz. Join them as they discuss software engineering compensation, how to ace your performance reviews, and what "getting things done" means! -- Books Mentioned in this Episode -- Note: As an Amazon Associate, we earn from qualifying purchases. ---------------------------------------------------------- The Software Engineer's Guidebook by Gergely Orosz https://amzn.to/3C503GQ (paid link) ---------------- Spotify: https://open.spotify.com/show/5kj6DLCEWR5nHShlSYJI5L Apple Podcasts: https://podcasts.apple.com/us/podcast/book-overflow/id1745257325 X: https://x.com/bookoverflowpod Carter on X: https://x.com/cartermorgan Nathan's Functionally Imperative: www.functionallyimperative.com ---------------- Book Overflow is a podcast for software engineers, by software engineers dedicated to improving our craft by reading the best technical books in the world. Join Carter Morgan and Nathan Toups as they read and discuss a new technical book each week! The full book schedule and links to every major podcast player can be found at https://www.bookoverflow.io
This interview was recorded for the GOTO Book Club.http://gotopia.tech/bookclubRead the full transcription of the interview hereJames Stanier - Director of Engineering at Shopify & Author of "Become an Effective Software Engineering Manager"Gergely Orosz - Writing The Pragmatic Engineer & Author of "The Software Engineer's Guidebook"RESOURCESJameshttps://twitter.com/jstanierhttps://www.linkedin.com/in/jstanierhttps://github.com/jstanierhttps://www.theengineeringmanager.comhttps://www.theengineeringmanager.com/management-101/contractingGergelyhttps://twitter.com/gergelyoroszhttps://www.linkedin.com/in/gergelyoroszhttps://www.pragmaticengineer.comhttps://github.com/gergelyoroszDESCRIPTIONSoftware startups make global headlines every day. As technology companies succeed and grow, so do their engineering departments.In your career, you'll may suddenly get the opportunity to lead teams: to become a manager. But this is often uncharted territory.How do you decide whether this career move is right for you?And if you do, what do you need to learn to succeed?Where do you start?How do you know that you're doing it right?What does “it” even mean?And isn't management a dirty word?This book will share the secrets you need to know to manage engineers successfully.* Book description: © Pragmatic Programmers:RECOMMENDED BOOKSJames Stanier • Become an Effective Software Engineering ManagerJames Stanier • Effective Remote WorkGergely Orosz • The Software Engineer's GuidebookGergely Orosz • Building Mobile Apps at ScaleDavid Farley • Modern Software EngineeringWilliam B. Irvine • A Guide to the Good LifeTwitterInstagramLinkedInFacebookLooking for a unique learning experience?Attend the next GOTO conference near you! Get your ticket: gotopia.techSUBSCRIBE TO OUR YOUTUBE CHANNEL - new videos posted daily!
They say the best way to learn is by doing, but is that always true? Does the way people effectively learn change the further they get into their career? Join Luc and Allen as they discuss continuing education as a developer and what they've experienced over the last decade. The two cover the benefits of side projects and the impact taking them to production has both from a learning perspective and the effectiveness of how it sharpens your skills. About LucLuc is an AWS Serverless Hero and Principal Engineer at PostNL, where he designs and builds enterprise-scale serverless architectures. He is well known for his articles, presentations, videos, and podcasts about AWS. Luc strives to help team members, colleagues, and local and global AWS communities embrace and grow their skill sets so they too can experience the joy, fun, and sheer scale serverless brings to application development. Links Twitter - https://twitter.com/donkersgood LinkedIn - https://www.linkedin.com/in/donkersgoed Blog - https://lucvandonkersgoed.com AWS News - https://aws-news.com Empowered by Marty Cagan - https://rdyset.click/GDix65 The Software Engineer's Guidebook by Gergely Orosz - https://rdyset.click/inkhV2 Team Topologies by Matthew Skelton - https://rdyset.click/qyGDyv Learning Domain Driven Design by Vlad Khononov - https://rdyset.click/iMfBjo Architecture Patterns with Python by Bob Gregory and Harry Percival - https://rdyset.click/ambmw2 --- Send in a voice message: https://podcasters.spotify.com/pod/show/readysetcloud/message Support this podcast: https://podcasters.spotify.com/pod/show/readysetcloud/support
The fantastic opportunity Google is letting slip through its hands, and why Apple might win the consumer LLM race.
Gergely Orosz is back for our annual year-end update on the tech market, writ large. How is hiring? Has AI really changed the game? What about that OpenAI fiasco? We also talk in-depth about Gergely's self-published book, The Software Engineer's Guidebook, which has been four years in the making.
Gergely Orosz is back for our annual year-end update on the tech market, writ large. How is hiring? Has AI really changed the game? What about that OpenAI fiasco? We also talk in-depth about Gergely's self-published book, The Software Engineer's Guidebook, which has been four years in the making.
Don't minimise your Teams Meeting video call too hastily, you might reveal your dirty secrets! Would you be prepared to pay for Facebook and Instagram? And who is being faked to promote cryptocurrency scams?All this and much more is discussed in the latest edition of the “Smashing Security” podcast by cybersecurity veterans Graham Cluley and Carole Theriault, joined this week by technology journalist Jane Wakefield.Plus - don't miss our featured interview with Push Security founder and CEO Adam Bateman.Warning: This podcast may contain nuts, adult themes, and rude language.Episode links:XtraVue Trailer demo - YouTube.Nvidia sued after video call mistake showed 'stolen' data - BBC News.Valeo v. Nvidia complaint - DocumentCloud.Fake BBC news article using Jane Wakefield's name - Twitter.Report a fraudulent webpage to Google Safe Browsing - Google.Meta's EU ad-free subscription faces early privacy challenge - Yahoo!Meta to offer ad-free subscription in Europe in bid to keep tracking other users - TechCrunch.Meta's EU ad-free subscription faces early privacy challenge - TechCrunch.Facebook and Instagram to Offer Subscription for No Ads in Europe - Facebook. noyb files GDPR complaint against Meta over “Pay or Okay” - NOYB. Big Mac index 2023 - Statista.Euro aea wages 2023 - Take-profit.org.Boat Story review - The Guardian.GlasgowGPT - the world's first Scottish artificial intelligence chatbot.Gergely Orosz uncovers fake female speakers at a tech conference - Twitter. Eliza-May Austin shares her experiences of being invited to speak at tech conferences - LinkedIn.
Bryan and Adam were joined by Gergely Orosz, the Pragmatic Engineer, to talk about Oxide's hiring process, the experiences that led to that process, and hiring generally. There's a lot there for anyone interested in hiring or being hired... and especially for anyone who's considered applying to Oxide!In addition to Bryan Cantrill and Adam Leventhal, we were joined by special guest Gergely Orosz.The "Litter Box" is what we call the recording studio... thus named for reasons best left to the imagination Oxide Hiring Process The Pragmatic Engineer Oxide and Friends: Tech Layoffs (Nov. 8, 2022) The Oxide RFD process The Psychopath Test Oxide Principles and Values Adam's detente with the American Hockey League Leventhal's conundrum - there is a performance pathology, find the butterfly that caused the hurricane. Compensation as a Reflection of Values Light's Out: Pride, Delusion, and the Fall of GE Gergely's new book The Software Engineer's Guidebook If we got something wrong or missed something, please file a PR! Our next show will likely be on Monday at 5p Pacific Time on our Discord server; stay tuned to our Mastodon feeds for details, or subscribe to this calendar. We'd love to have you join us, as we always love to hear from new speakers!
The debate on measuring developer productivity has arrived - and it's here to stay. On this week's episode of Dev Interrupted, cohost Conor Bronsdon welcomes LinearB cofounder & CEO Ori Keren and Kelly Vaughn, Director of Engineering at Spot AI, to offer their critiques of a debate that has captured the attention of the engineering community: can you measure developer productivity?Consulting giant McKinsey published an article that ignited a firestorm, prompting industry leaders Kent Beck and Gergely Orosz to counter with a detailed 2-part response via the Pragmatic Engineer.Believing the industry to be at a crossroads, Ori and Kelly combine forces to offer their perspective on the debate, sharing why it's an opportunity for dev teams everywhere to “roll out metrics the right way.”Show Notes:The McKinsey article: Yes, you can measure software developer productivityOrosz & Beck 1: Measuring developer productivity? A response to McKinsey, Part 1Orosz & Beck 2: Measuring developer productivity? A response to McKinsey, Part 2CTO Board SlidesKelly's newsletter: Lessons in Engineering LeadershipRegister for the 2023 Engineering Benchmarks Report Release WebinarSupport the show: Subscribe to our Substack Leave us a review Subscribe on YouTube Follow us on Twitter or LinkedIn Offers: Learn about Continuous Merge with gitStream Want to try LinearB? Book a Demo & use discount code "Dev Interrupted Podcast"
Dans cet épisode de rentrée, Antonio et Arnaud ont le plaisir d'accueillir Katia Aresti dans l'équipe. Ils passent en revue les dernières nouveautés et sujets chauds de cette rentrée, notamment la sortie de Java 21, les nouvelles versions de Quarkus, Micronaut, Hibernate, NodeJS, Redis, et bien d'autres encore. Ils discutent de sujets plus généraux tels que l'observabilité, la nouvelle tendance “Platform Engineering”, et la productivité des développeurs. Ils abordent aussi les sujets sur la sécurité, tels que les failles sur les CPUs Intel et AMD, ainsi que la vie privée, avec les Tracking APIs de Chrome, Firefox et le projet de loi SREN. Le tout est agrémenté de sa dose d'IA, avec des librairies telles que Semantic Kernel, ainsi que des sujets plus haut niveau tels que Google Gemini, Meta GPT, LLama 2, et les biais et la consommation énergétique de l'IA. Enregistré le 8 septembre 2023 Téléchargement de l'épisode LesCastCodeurs-Episode–299.mp3 News Langages Apache Groovy a 20 ans! https://twitter.com/ApacheGroovy/status/1695388098950217909 L'annonce du lancement du projet par James Strachan https://web.archive.org/web/20030901064404/http://radio.weblogs.com/0112098/2003/08/29.html Le projet a depuis énormément évolué et après plusieurs vies a été adopté par la fondation Apache en 2015 Java 21 arrive le 19 septembre https://www.infoworld.com/article/3689880/jdk–21-the-new-features-in-java–21.html. C'est la nouvelle LTS Pas mal de nouvelles fonctionnalités comme les virtual threads, le pattern matching sur les switch, sequenced collections … Retrouvez le 19 septembre une interview de Jean-Michel Doudoux par Charles Sabourdin pour l'épisode 300 des castcodeurs! Librairies Semantic Kernel pour Java est (en train de) sorti: https://devblogs.microsoft.com/semantic-kernel/introducing-semantic-kernel-for-java/ Framework OSS pour faire de l'IA .Net et Python Java 0.2.7 Alpha est publié Kernel car il est tout petit Se connecte à plusieurs fournisseurs (aujourd'hui OpenAI, Azure AI, Hugging Face), plusieurs DB vectorielles, plusieurs template de prompt (suit la specification de OpenAI) OpenSSL qui committe https://www.openssl.org/blog/blog/2023/07/17/who-writes-openssl/ en majorité des OSS payés puis des gens payés par leur boite et enfi des contributeurs non payés c'est ne passant rapide mais ca montre que depuis heartbleed, ca a changé Micronaut 4.1.0 https://micronaut.io/2023/09/01/micronaut-framework–4–1–0-released/ Bean Mappers pour créer automatiquement une correspondance entre un type et un autre un Introspection Builder l'annotation @Introspected pour générer un builder dynamique si un type ne peut être construit que via un modèle builder améliorations pour les développeurs utilisant Kotlin Symbol Processing (KSP) Quarkus 3.3.1 / 3.3.2 https://quarkus.io/blog/quarkus–3–3–1-released/ https://quarkus.io/blog/quarkus–3–3–2-released/ Pas mal de fixes https://github.com/quarkusio/quarkus/releases/tag/3.3.1 https://github.com/quarkusio/quarkus/releases/tag/3.3.2 Il est important de noter qu'un problème de dégradation des performances et de la mémoire a été introduit dans Quarkus 3.3. Ce problème est corrigé dans Quarkus 3.3.2. Hibernate ORM 6.3.0 et 6.2.8 https://hibernate.org/orm/ et Hibernate Reactive 2.0.5 un support initial de la spécification Jakarta Persistence 3.2 Un nouveau guide d'introduction Hibernate 6, un nouveau guide de syntaxe et de fonctionnalités pour le langage de requête Hibernate (Hibernate Query Language) Annotation @Find sur des méthodes -> créer des méthodes de recherche similaires aux méthodes de requête Reactive compatible avec Hibernate ORM 6.2.8.Final, certains changements d'api Infrastructure Une série d'articles sur l'observabilité par Mathieu Corbin Observability: tout ce que vous avez toujours voulu savoir sur les métriques: https://www.mcorbin.fr/posts/2023–07–04-metriques/ Tracing avec Opentelemetry: pourquoi c'est le futur (et pourquoi ça remplacera les logs): https://www.mcorbin.fr/posts/2023–08–20-traces/ L'auteur reprend les bases sur l'observabilité. Qu'est ce qu'une métrique ? Les labels, les cardinalités Les types de métriques (Compteurs, jauges, quantiles et histogrammes) C'est quoi le tracing ? Traces, Spans, Resources, Scopes qu'est ce que c'est? Les Events pour remplacer les logs? Web NodeJS 20.6.0 est disponible et ajoute le support des fichiers .env https://philna.sh/blog/2023/09/05/nodejs-supports-dotenv/ Configurable avec l'option --env-file Le fichier .env peut contenir des variables d'environnement et commentaires # Attention par contre: pas de lignes multiples ni d'extension de variables Vous pouvez par exemple configurer NODE_OPTIONS avec ce système Data Redis 7.2 est sorti ! https://redis.com/blog/introducing-redis–7–2/ Auto-tiering : cette nouvelle fonctionnalité permet de stocker les données sur des supports de stockage différents, en fonction de leur importance et de leur fréquence d'accès. Cela permet d'améliorer les performances et la scalabilité de Redis. RESP3 : cette nouvelle version du protocole RESP permet une communication plus efficace entre Redis et les clients. Improvements to performance : de nombreuses améliorations de performances ont été apportées à Redis 7.2, notamment pour les opérations de lecture et d'écriture. New commands : plusieurs nouvelles commandes ont été ajoutées à Redis 7.2, notamment : CLIENT NO-TOUCH : cette commande permet d'empêcher un client d'être touché par une opération AOF ou RDB. WAITAOF : cette commande permet d'attendre que l'AOF soit écrite avant de poursuivre l'exécution. Dans le podcast sont cités les hot replacement des Redis, comme https://www.dragonflydb.io/ Architecture Article sur Google Gemini et sa capacité a battre ChatGPT https://www.semianalysis.com/p/google-gemini-eats-the-world-gemini Google a raté les premiers pas (ils avient le meilleur LLM public avant ChatGPT 3) ET les chercheurs qui invente le champs des LLMs Google va 5x ChatGPT–4 avant al fin de l'année, mais vont-il les publier les chercheurs se tirent la bourre sur le nombre de GPU (H100) auxquels ils ont accès ; ce sont lers grosses orga comme Meta OpenAI Google et les autres qui lutent avec des GPU qui n'ont pas assez de VRAM et ce qu'ils vont faire c'est de la merde et sans consequence le peuple utilise le modele dense de LLAMA mais pour les environnements contraints ca serait mieux des sparse models et du speculative decoding. ils devraient se concentre sur la performance de modele qui utilise plus de compute et memoire en evitant de consommer de la bande passante de memoire, c'est ce que l'edge a besoin les benchmarks public ne mesurent pas des choses utiles meme hugging faces est dans la category des pauvres de GPU Nvidia est entrain de se construire une machine de guerre (service) la chine et les us vont etre en competition mais l'europe qui fait du GPU pauvre ne va pas s'en sortir les startups ne peuvent pas payer les GPU en actiosn, il faut du cash Tout le monde rempli les poches de NVidia, sand Google Gogole grossi exponentiellement ses propres GPUs Meta GPT https://www.infoq.com/news/2023/08/metagpt-agent-collaboration/ IA: les biais et énergie qui consomme par Leslie Miley tech advisor du CTO de Microsoft https://www.infoq.com/presentations/ai-bias-sustainability nouvels infranstructures consommation énergétique et d'eau des data center pour IA est terriblement coûteuse l'impact des infrastructures sur les comunautés (bruit) explique bien son point de vu sur les problèmes d'amplification des biais du IA propose des stratégies pour mitiger l'impact negatif Kubeflow toolkit pour deployer machine learning (ML) workflow en Kubernetes est accepté par la CNCF (Cloud Native Computing Foundation) https://www.infoq.com/news/2023/08/kubeflow-cncf-project Méthodologies Measuring developer productivity? A response to McKinsey by Kent Beck and Gergely Orosz (pragmaticengineer.com) https://tidyfirst.substack.com/p/measuring-developer-productivity McKinsey a sorti un article où ils expliquent la recette miracle recherchée par tous les managers comme le graal: Comment mesurer la productivité des développeurs? (faut bien vendre du conseil) Kent et Gergely partent d'un model mental de description de la création de valeur par le développeur pour ensuite voir quels sont les besoins de mesurer la productivité et comparent cela avec d'autres secteurs (la vente, le support, le recrutement). Ils concluent cette première partie avec les compromis à faire pour que ce type de mesures ait un intérêt sans impacter trop négativement les développeurs un autre article dans la même lignée de Martin Fowler https://martinfowler.com/bliki/CannotMeasureProductivity.html Et si on parlait de Platform Engineering ? DevOps vs. SRE vs. Platform Engineering (humanitec.com) What is platform engineering? (gartner.com) / What is platform engineering? (platformengineering.org) Internal Developer Platform Cognitive load Team topologies Engineering Effectiveness (thoughtworks.com) and Maximize your tech investments with Engineering Effectiveness (thoughtworks.com) Ces différents articles retracent la génèse du concept de Platform Engineering L'activité de Platform Engineering vient en réponse à la charge cognitive rajoutée aux équipes techs dans des transitions DevOps loupées (You build it, you run it … et vous vous débrouillez). Cela conduit à la création de golden paths et d'une Internal Developers Platform qui doit proposer en interne les services nécessaires aux équipes pour livrer leurs produits le lus efficacement possible tout en suivant les critères de qualité, de compliance de l'entreprise. Pour en savoir plus, une table ronde à laquelle Arnaud a participé en Juillet : https://youtu.be/N-tN7HUA4No?si=2P0wSqG32MLWUlGq On call Process (Astreinte) , startup TinyBird par VP Engineering Félix López (ex google, ex eventbrite) https://thenewstack.io/keeping-the-lights-on-the-on-call-process-that-works/ Si votre produit est SAAS, on doit avoir des astreintes. Cela impose un lourd fardeau à ceux qui doivent être en astreinte,, surtout en petite entreprise Petites entreprises évitent avoir un processus d'astreinte formel pour éviter le stress. Cela crée dans la pratique plus de stress: Si personne n'est responsable, tout le monde est responsable. Tinybird est la plateforme de données en temps réel pour les développeurs et les équipes de données. Pré création du process formel chez Tinybird: désorganisé, non structuré et stressant Mise en place: Principes fondamentaux d'un processus d'astreinte: L'astreinte n'est pas obligatoire, minimiser le bruit, pas seulement pour les SRE, alert = runbook, avoir des backups pour la personne en astreinte, appeler quelqu'un devrait être la dernière solution, minimiser le temps en astreinte L'article explique comment ils sont passé regarder chaque alerte (comprehensible?, exploitable?), puis avoir un board grafana pour chacune et plan spécifique. Une fois le tri fait, tout migré vers un seul channel de com, et manuel d'astreinte pour chaque alerte. Itérer. Multiples benefices sur le long terme: rapports d'incident ouvert, atténuer les problèmes futurs, renforcement la propriété et les connaissances du code et systèmes au sein de toute l'équipe etc. Sécurité Downfall, une nouvelle faille de sécurité sur les processeurs intel ( https://www.lemondeinformatique.fr/actualites/lire-la-faille-downfall-met-a-mal-des-milliards-de-processeurs-intel–91247.html ) et AMD ne fait pas mieux avec une faille nommée Inception (https://www.lemondeinformatique.fr/actualites/lire-les-puces-amd-vulnerables-a-la-faille-inception–91273.html) Downfall, La vulnérabilité est due à des fonctions d'optimisation de la mémoire dans les processeurs Intel qui révèlent involontairement les registres matériels internes aux logiciels. Cela permet à des logiciels non-fiables d'accéder à des données stockées par d'autres programmes, qui ne devraient normalement pas être accessibles. Tous les PC ou ordinateurs portables équipés de processeurs Intel Core de la 6e génération Skylake jusqu'aux puces Tiger Lake de 11e génération incluses contiennent cette faille. Les derniers processeurs Core 12e et 13e génération d'Intel ne sont pas concernés. Inception, nécessite un accès local au système pour être potentiellement exploité ce qui en limite de fait la portée. Tous les processeurs AMD depuis 2017 sont touchés, incluant les derniers modèles Zen 4 Epyc et Ryzen Comment désactiver le nouveau tracking publicitaire ciblé sur Chrome https://www.blogdumoderateur.com/chrome-comment-desactiver-tracking-publicitaire-cible/ Google a annoncé en juillet le déploiement de sa nouvelle API Topics, permettant « à un navigateur de partager des informations avec des tiers sur les intérêts d'un utilisateur tout en préservant la confidentialité ». C'est cette API, incluse dans la version Chrome 115 de juillet 2023, qui est censée remplacer les cookies tiers. Loi, société et organisation Une nouvelle definition d'open pour Llama 2? https://opensourceconnections.com/blog/2023/07/19/is-llama–2-open-source-no-and-perhaps-we-need-a-new-definition-of-open/ c'est relativement “open” mais il y a des restrictions donc pas open source pas plus de 700 M d'utilisateurs par mois pas le droit d'utiliser Llama pour améliorer d'autres modèles autres que dse dérivés de Llama et c'est le modele final qui est ouvert, pas la sauce pour le construire, donc pas de maven build ni le “source code” pour y arriver “from scratch” attention au risuqe de sacrivier open source pour avoir l'IA plus vite, plus facile HashiCorp passe tous ses projets open source en BSL, comme Confluent, Mongo, Redis, Elastic, etc https://thenewstack.io/hashicorp-abandons-open-source-for-business-source-license/ Couverture par InfoQ https://www.infoq.com/news/2023/08/hashicorp-adopts-bsl/ Fork de Terraform : OpenTF, avec pour objectif de rejoindre la CNCF https://opentf.org/announcement Stack overflow annonce Overflow AI https://www.infoq.com/news/2023/09/stackoverflow-overflowai/ l'intégration de l'IA générative dans leur plateforme publique, Stack Overflow for Teams, ainsi que de nouveaux domaines de produits IA/ML aident à générer des balises initiales et à suggérer des paires question-réponse, permettant aux développeurs de se concentrer sur l'amélioration et la précision Amélioration des Capacités de Recherche Les forums de questions-réponses basés sur la communauté sont le cœur battant de Stack Overflow. Selon Prashanth Chandrasekar, PDG de Stack Overflow, l'objectif d'OverflowAI est d'améliorer la communauté de diverses manières plutôt que de la remplacer complètement. Vous avez entendu parler du projet de loi SREN ? http://share.mozilla.org/817319645t Le gouvernement français prépare une loi qui pourrait menacer la liberté sur Internet. Le projet de loi visant à sécuriser et réguler l'espace numérique (SREN) obligerait les navigateurs web, comme Mozilla Firefox, à bloquer des sites web directement au niveau du navigateur. Mozilla lance une pétition pour retirer cette n-ieme solution stupide pour censurer Internet Conférences La liste des conférences provenant de Developers Conferences Agenda/List par Aurélie Vache et contributeurs : 8 septembre 2023 : JUG Summer Camp - La Rochelle (France) 14 septembre 2023 : Cloud Sud - Toulouse (France) & Online 18 septembre 2023 : Agile Tour Montpellier - Montpellier (France) 19 septembre 2023 : Salon de la Data Nantes - Nantes (France) & Online 19–20 septembre 2023 : Agile en Seine - Paris (France) 21–22 septembre 2023 : API Platform Conference - Lille (France) & Online 22 septembre 2023 : Agile Tour Sophia Antipolis - Valbonne (France) 25–26 septembre 2023 : BIG DATA & AI PARIS 2023 - Paris (France) 28–30 septembre 2023 : Paris Web - Paris (France) 2–6 octobre 2023 : Devoxx Belgium - Antwerp (Belgium) 6 octobre 2023 : DevFest Perros-Guirec - Perros-Guirec (France) 10 octobre 2023 : ParisTestConf - Paris (France) 11–13 octobre 2023 : Devoxx Morocco - Agadir (Morocco) 12 octobre 2023 : Cloud Nord - Lille (France) 12–13 octobre 2023 : Volcamp 2023 - Clermont-Ferrand (France) 12–13 octobre 2023 : Forum PHP 2023 - Marne-la-Vallée (France) 13–14 octobre 2023 : SecSea 2K23 - La Ciotat (France) 17–20 octobre 2023 : DrupalCon Lille - Lille (France) 19–20 octobre 2023 : DevFest Nantes - Nantes (France) 19–20 octobre 2023 : Agile Tour Rennes - Rennes (France) 26 octobre 2023 : Codeurs en Seine - Rouen (France) 30 septembre 2023 : ScalaIO - Paris (France) 26–27 octobre 2023 : Agile Tour Bordeaux - Bordeaux (France) 26–29 octobre 2023 : SoCraTes-FR - Orange (France) 10 novembre 2023 : BDX I/O - Bordeaux (France) 15 novembre 2023 : DevFest Strasbourg - Strasbourg (France) 16 novembre 2023 : DevFest Toulouse - Toulouse (France) 18–19 novembre 2023 : Capitole du Libre - Toulouse (France) 23 novembre 2023 : DevOps D-Day #8 - Marseille (France) 23 novembre 2023 : Agile Grenoble - Grenoble (France) 30 novembre 2023 : PrestaShop Developer Conference - Paris (France) 30 novembre 2023 : WHO run the Tech - Rennes (France) 6–7 décembre 2023 : Open Source Experience - Paris (France) 7 décembre 2023 : Agile Tour Aix-Marseille - Gardanne (France) 7–8 décembre 2023 : TechRocks Summit - Paris (France) 8 décembre 2023 : DevFest Dijon - Dijon (France) 31 janvier 2024–3 février 2024 : SnowCamp - Grenoble (France) 6–7 mars 2024 : FlowCon 2024 - Paris (France) 19–22 mars 2024 : KubeCon + CloudNativeCon Europe 2024 - Paris (France) 28–29 mars 2024 : SymfonyLive Paris 2024 - Paris (France) 17–19 avril 2024 : Devoxx France - Paris (France) 25–26 avril 2024 : MiXiT - Lyon (France) 25–26 avril 2024 : Android Makers - Paris (France) 6–7 juin 2024 : DevFest Lille - Lille (France) Nous contacter Pour réagir à cet épisode, venez discuter sur le groupe Google https://groups.google.com/group/lescastcodeurs Contactez-nous via twitter https://twitter.com/lescastcodeurs Faire un crowdcast ou une crowdquestion Soutenez Les Cast Codeurs sur Patreon https://www.patreon.com/LesCastCodeurs Tous les épisodes et toutes les infos sur https://lescastcodeurs.com/
In this episode we cover "How to Lead a Project - as a Software Engineer" by Gergely Orosz. This is a practical, step-by-step guide on crushing the soft-skills portion of a project. We cover how to set a good foundation of communication, how to effectively manage risk, best practices for updates, and a whole lot more. No matter what level you are in your career, following this guide for your next project (big or small) will definitely set you apart as an effective leader. We get back to our roots and deliver some new learning and some great news to sail away on. Also, we are still tinkering with our into and outtro...so we're sorry about that. As always, visit Runtime Rundown to drop us a suggestion, listen, and comment on episodes. Thanks for listening!
Jean Yang, CEO of Akita Software, joins Corey on Screaming in the Cloud to discuss how she went from academia to tech founder, and what her company is doing to improve monitoring and observability. Jean explains why Akita is different from other observability & monitoring solutions, and how it bridges the gap from what people know they should be doing and what they actually do in practice. Corey and Jean explore why the monitoring and observability space has been so broken, and why it's important for people to see monitoring as a chore and not a hobby. Jean also reveals how she took a leap from being an academic professor to founding a tech start-up. About JeanJean Yang is the founder and CEO of Akita Software, providing the fastest time-to-value for API monitoring. Jean was previously a tenure-track professor in Computer Science at Carnegie Mellon University.Links Referenced: Akita Software: https://www.akitasoftware.com/ Aki the dog chatbot: https://www.akitasoftware.com/blog-posts/we-built-an-exceedingly-polite-ai-dog-that-answers-questions-about-your-apis Twitter: https://twitter.com/jeanqasaur TranscriptAnnouncer: Hello, and welcome to Screaming in the Cloud with your host, Chief Cloud Economist at The Duckbill Group, Corey Quinn. This weekly show features conversations with people doing interesting work in the world of cloud, thoughtful commentary on the state of the technical world, and ridiculous titles for which Corey refuses to apologize. This is Screaming in the Cloud.Corey: Welcome to Screaming in the Cloud. I'm Corey Quinn. My guest today is someone whose company has… well, let's just say that it has piqued my interest. Jean Yang is the CEO of Akita Software and not only is it named after a breed of dog, which frankly, Amazon service namers could take a lot of lessons from, but it also tends to approach observability slash monitoring from a perspective of solving the problem rather than preaching a new orthodoxy. Jean, thank you for joining me.Jean: Thank you for having me. Very excited.Corey: In the world that we tend to operate in, there are so many different observability tools, and as best I can determine observability is hipster monitoring. Well, if we call it monitoring, we can't charge you quite as much money for it. And whenever you go into any environment of significant scale, we pretty quickly discover that, “What monitoring tool are you using?” The answer is, “Here are the 15 that we use.” Then you talk to other monitoring and observability companies and ask them which ones of those they've replace, and the answer becomes, “We're number 16.” Which is less compelling of a pitch than you might expect. What does Akita do? Where do you folks start and stop?Jean: We want to be—at Akita—your first stop for monitoring and we want to be all of the monitoring, you need up to a certain level. And here's the motivation. So, we've talked with hundreds, if not thousands, of software teams over the last few years and what we found is there is such a gap between best practice, what people think everybody else is doing, what people are talking about at conferences, and what's actually happening in software teams. And so, what software teams have told me over and over again, is, hey, we either don't actually use very many tools at all, or we use 15 tools in name, but it's you know, one [laugh] one person on the team set this one up, it's monitoring one of our endpoints, we don't even know which one sometimes. Who knows what the thresholds are really supposed to be. We got too many alerts one day, we turned it off.But there's very much a gap between what people are saying they're supposed to do, what people in their heads say they're going to do next quarter or the quarter after that and what's really happening in practice. And what we saw was teams are falling more and more into monitoring debt. And so effectively, their customers are becoming their monitoring and it's getting harder to catch up. And so, what Akita does is we're the fastest, easiest way for teams to quickly see what endpoints you have in your system—so that's API endpoints—what's slow and what's throwing errors. And you might wonder, okay, wait, wait, wait, Jean. Monitoring is usually about, like, logs, metrics, and traces. I'm not used to hearing about API—like, what do APIs have to do with any of it?And my view is, look, we want the most simple form of what might be wrong with your system, we want a developer to be able to get started without having to change any code, make any annotations, drop in any libraries. APIs are something you can watch from the outside of a system. And when it comes to which alerts actually matter, where do you want errors to be alerts, where do you want thresholds to really matter, my view is, look, the places where your system interfaces with another system are probably where you want to start if you've really gotten nothing. And so, Akita view is, we're going to start from the outside in on this monitoring. We're turning a lot of the views on monitoring and observability on its head and we just want to be the tool that you reach for if you've got nothing, it's middle of the night, you have alerts on some endpoint, and you don't want to spend a few hours or weeks setting up some other tool. And we also want to be able to grow with you up until you need that power tool that many of the existing solutions out there are today.Corey: It feels like monitoring is very often one of those reactive things. I come from the infrastructure world, so you start off with, “What do you use for monitoring?” “Oh, we wait till the help desk calls us and users are reporting a problem.” Okay, that gets you somewhere. And then it becomes oh, well, what was wrong that time? The drive filled up. Okay, so we're going to build checks in that tell us when the drives are filling up.And you wind up trying to enumerate all of the different badness. And as a result, if you leave that to its logical conclusion, one of the stories that I heard out of MySpace once upon a time—which dates me somewhat—is that you would have a shift, so there were three shifts working around the clock, and each one would open about 5000 tickets, give or take, for the monitoring alerts that wound up firing off throughout their infrastructure. At that point, it's almost, why bother? Because no one is going to be around to triage these things; no one is going to see any of the signal buried and all of that noise. When you talk about doing this for an API perspective, are you running synthetics against those APIs? Are you shimming them in order to see what's passing through them? What's the implementation side look like?Jean: Yeah, that's a great question. So, we're using a technology called BPF, Berkeley Packet Filter. The more trendy, buzzy term is EBPF—Corey: The EBPF. Oh yes.Jean: Yeah, Extended Berkeley Packet Filter. But here's the secret, we only use the BPF part. It's actually a little easier for users to install. The E part is, you know, fancy and often finicky. But um—Corey: SEBPF then: Shortened Extended BPF. Why not?Jean: [laugh]. Yeah. And what BPF allows us to do is passively watch traffic from the outside of a system. So, think of it as you're sending API calls across the network. We're just watching that network. We're not in the path of that traffic. So, we're not intercepting the traffic in any way, we're not creating any additional overhead for the traffic, we're not slowing it down in any way. We're just sitting on the side, we're watching all of it, and then we're taking that and shipping an obfuscated version off to our cloud, and then we're giving you analytics on that.Corey: One of the things that strikes me as being… I guess, a common trope is there are a bunch of observability solutions out there that offer this sort of insight into what's going on within an environment, but it's, “Step one: instrument with some SDK or some agent across everything. Do an entire deploy across your fleet.” Which yeah, people are not generally going to be in a hurry to sign up for. And further, you also said a minute ago that the idea being that someone could start using this in the middle of the night in the middle of an outage, which tells me that it's not, “Step one: get the infrastructure sparkling. Step two: do a global deploy to everything.” How do you go about doing that? What is the level of embeddedness into the environment?Jean: Yeah, that's a great question. So, the reason we chose BPF is I wanted a completely black-box solution. So, no SDKs, no code annotations. I wanted people to be able to change a config file and have our solution apply to anything that's on the system. So, you could add routes, you could do all kinds of things. I wanted there to be no additional work on the part of the developer when that happened.And so, we're not the only solution that uses BPF or EBPF. There's many other solutions that say, “Hey, just drop us in. We'll let you do anything you want.” The big difference is what happens with the traffic once it gets processed. So, what EBPF or BPF gives you is it watches everything about your system. And so, you can imagine that's a lot of different events. That's a lot of things.If you're trying to fix an incident in the middle of the night and someone just dumps on you 1000 pages of logs, like, what are you going to do with that? And so, our view is, the more interesting and important and valuable thing to do here is not make it so that you just have the ability to watch everything about your system but to make it so that developers don't have to sift through thousands of events just to figure out what went wrong. So, we've spent years building algorithms to automatically analyze these API events to figure out, first of all, what are your endpoints? Because it's one thing to turn on something like Wireshark and just say, okay, here are the thousand API calls, I saw—ten thousand—but it's another thing to say, “Hey, 500 of those were actually the same endpoint and 300 of those had errors.” That's quite a hard problem.And before us, it turns out that there was no other solution that even did that to the level of being able to compile together, “Here are all the slow calls to an endpoint,” or, “Here are all of the erroneous calls to an endpoint.” That was blood, sweat, and tears of developers in the night before. And so, that's the first major thing we do. And then metrics on top of that. So, today we have what's slow, what's throwing errors. People have asked us for other things like show me what happened after I deployed. Show me what's going on this week versus last week. But now that we have this data set, you can imagine there's all kinds of questions we can now start answering much more quickly on top of it.Corey: One thing that strikes me about your site is that when I go to akitasoftware.com, you've got a shout-out section at the top. And because I've been doing this long enough where I find that, yeah, you work at a company; you're going to say all kinds of wonderful, amazing aspirational things about it, and basically because I have deep-seated personality disorders, I will make fun of those things as my default reflexive reaction. But something that AWS, for example, does very well is when they announce something ridiculous on stage at re:Invent, I make fun of it, as is normal, but then they have a customer come up and say, “And here's the expensive, painful problem that they solved for us.”And that's where I shut up and start listening. Because it's a very different story to get someone else, who is presumably not being paid, to get on stage and say, “Yeah, this solved a sophisticated, painful problem.” Your shout-outs page has not just a laundry list of people saying great things about it, but there are former folks who have been on the show here, people I know and trust: Scott Johnson over at Docker, Gergely Orosz over at The Pragmatic Engineer, and other folks who have been luminaries in the space for a while. These are not the sort of people that are going to say, “Oh, sure. Why not? Oh, you're going to send me a $50 gift card in a Twitter DM? Sure I'll say nice things,” like it's one of those respond to a viral tweet spamming something nonsense. These are people who have gravitas. It's clear that there's something you're building that is resonating.Jean: Yeah. And for that, they found us. Everyone that I've tried to bribe to say good things about us actually [laugh] refused.Corey: Oh, yeah. As it turns out that it's one of those things where people are more expensive than you might think. It's like, “What, you want me to sell my credibility down the road?” Doesn't work super well. But there's something like the unsolicited testimonials that come out of, this is amazing, once people start kicking the tires on it.You're currently in open beta. So, I guess my big question for you is, whenever you see a product that says, “Oh, yeah, we solve everything cloud, on-prem, on physical instances, on virtual machines, on Docker, on serverless, everything across the board. It's awesome.” I have some skepticism on that. What is your ideal application architecture that Akita works best on? And what sort of things are you a complete nonstarter for?Jean: Yeah, I'll start with a couple of things we work well on. So, container platforms. We work relatively well. So, that's your Fargate, that's your Azure Web Apps. But that, you know, things running, we call them container platforms. Kubernetes is also something that a lot of our users have picked us up and had success with us on. I will say our Kubernetes deploy is not as smooth as we would like. We say, you know, you can install us—Corey: Well, that is Kubernetes, yes.Jean: [laugh]. Yeah.Corey: Nothing in Kubernetes is as smooth as we would like.Jean: Yeah, so we're actually rolling out Kubernetes injection support in the next couple of weeks. So, those are the two that people have had the most success on. If you're running on bare metal or on a VM, we work, but I will say that you have to know your way around a little bit to get that to work. What we don't work on is any Platform as a Service. So, like, a Heroku, a Lambda, a Render at the moment. So those, we haven't found a way to passively listen to the network traffic in a good way right now.And we also work best for unencrypted HTTP REST traffic. So, if you have encrypted traffic, it's not a non-starter, but you need to fall into a couple of categories. You either need to be using Kubernetes, you can run Akita as a sidecar, or you're using Nginx. And so, that's something we're still expanding support on. And we do not support GraphQL or GRPC at the moment.Corey: That's okay. Neither do I. It does seem these days that unencrypted HTTP API calls are increasingly becoming something of a relic, where folks are treating those as anti-patterns to be stamped out ruthlessly. Are you still seeing significant deployments of unencrypted APIs?Jean: Yeah. [laugh]. So, Corey—Corey: That is the reality, yes.Jean: That's a really good question, Corey, because in the beginning, we weren't sure what we wanted to focus on. And I'm not saying the whole deployment is unencrypted HTTP, but there is a place to install Akita to watch where it's unencrypted HTTP. And so, this is what I mean by if you have encrypted traffic, but you can install Akita as a Kubernetes sidecar, we can still watch that. But there was a big question when we started: should this be GraphQL, GRPC, or should it be REST? And I read the “State of the API Report” from Postman for you know, five years, and I still keep up with it.And every year, it seemed that not only was REST, remaining dominant, it was actually growing. So, [laugh] this was shocking to me as well because people said, well, “We have this more structured stuff, now. There's GRPC, there's GraphQL.” But it seems that for the added complexity, people weren't necessarily seeing the value and so, REST continues to dominate. And I've actually even seen a decline in GraphQL since we first started doing this. So, I'm fully on board the REST wagon. And in terms of encrypted versus unencrypted, I would also like to see more encryption as well. That's why we're working on burning down the long tail of support for that.Corey: Yeah, it's one of those challenges. Whenever you're deploying something relatively new, there's this idea that it should be forward-looking and you, on some level, want to modernize your architecture and infrastructure to keep up with it. An AWS integration story I see that's like that these days is, “Oh, yeah, generate an IAM credential set and just upload those into our system.” Yeah, the modern way of doing that is role assumption: to find a role and here's how to configure it so that it can do what we need to do. So, whenever you start seeing things that are, “Oh, yeah, just turn the security clock back in time a little bit,” that's always a little bit of an eyebrow raise.I can also definitely empathize with the joys of dealing with anything that even touches networking in a Lambda context. Building the Lambda extension for Tailscale was one of the last big dives I made into that area and I still have nightmares as a result. It does a lot of interesting things right up until you step off the golden path. And then suddenly, everything becomes yaks all the way down, in desperate need of shaving.Jean: Yeah, Lambda does something we want to handle on our roadmap, but I… believe we need a bigger team before [laugh] we are ready to tackle that.Corey: Yeah, we're going to need a bigger boat is very often [laugh] the story people have when they start looking at entire new architectural paradigms. So, you end up talking about working in containerized environments. Do you find that most of your deployments are living in cloud environments, in private data centers, some people call them private cloud. Where does the bulk of your user applications tend to live these days?Jean: The bulk of our user applications are in the cloud. So, we're targeting small to medium businesses to start. The reason being, we want to give our users a magical deployment experience. So, right now, a lot of our users are deploying in under 30 minutes. That's in no small part due to automations that we've built.And so, we initially made the strategic decision to focus on places where we get the most visibility. And so—where one, we get the most visibility, and two, we are ready for that level of scale. So, we found that, you know, for a large business, we've run inside some of their production environments and there are API calls that we don't yet handle well or it's just such a large number of calls, we're not doing the inference as well and our algorithms don't work as well. And so, we've made the decision to start small, build our way up, and start in places where we can just aggressively iterate because we can see everything that's going on. And so, we've stayed away, for instance, from any on-prem deployments for that reason because then we can't see everything that's going on. And so, smaller companies that are okay with us watching pretty much everything they're doing has been where we started. And now we're moving up into the medium-sized businesses.Corey: The challenge that I guess I'm still trying to wrap my head around is, I think that it takes someone with a particularly rosy set of glasses on to look at the current state of monitoring and observability and say that it's not profoundly broken in a whole bunch of ways. Now, where it all falls apart, Tower of Babelesque, is that there doesn't seem to be consensus on where exactly it's broken. Where do you see, I guess, this coming apart at the seams?Jean: I agree, it's broken. And so, if I tap into my background, which is I was a programming languages person in my very recently, previous life, programming languages people like to say the problem and the solution is all lies in abstraction. And so, computing is all about building abstractions on top of what you have now so that you don't have to deal with so many details and you got to think at a higher level; you're free of the shackles of so many low-level details. What I see is that today, monitoring and observability is a sort of abstraction nightmare. People have just taken it as gospel that you need to live at the lowest level of abstraction possible the same way that people truly believe that assembly code was the way everybody was going to program forevermore back, you know, 50 years ago.So today, what's happening is that when people think monitoring, they think logs, not what's wrong with my system, what do I need to pay attention to? They think, “I have to log everything, I have to consume all those logs, we're just operating at the level of logs.” And that's not wrong because there haven't been any tools that have given people any help above the level of logs. Although that's not entirely correct, you know? There's also events and there's also traces, but I wouldn't say that's actually lifting the level of [laugh] abstraction very much either.And so, people today are thinking about monitoring and observability as this full control, like, I'm driving my, like, race car, completely manual transmission, I want to feel everything. And not everyone wants to or needs to do that to get to where they need to go. And so, my question is, how far are can we lift the level of abstraction for monitoring and observability? I don't believe that other people are really asking this question because most of the other players in the space, they're asking what else can we monitor? Where else can we monitor it? How much faster can we do it? Or how much more detail can we give the people who really want the power tools?But the people entering the buyer's market with needs, they're not people—you don't have, like, you know, hordes of people who need more powerful tools. You have people who don't know about the systems are dealing with and they want easier. They want to figure out if there's anything wrong with our system so they can get off work and do other things with their lives.Corey: That, I think, is probably the thing that gets overlooked the most. It's people don't tend to log into their monitoring systems very often. They don't want to. When they do, it's always out of hours, middle of the night, and they're confronted with a whole bunch of upsell dialogs of, “Hey, it's been a while. You want to go on a tour of the new interface?”Meanwhile, anything with half a brain can see there's a giant spike on the graph or telemetry stop coming in.Jean: Yeah.Corey: It's way outside of normal business hours where this person is and maybe they're not going to be in the best mood to engage with your brand.Jean: Yeah. Right now, I think a lot of the problem is, you're either working with monitoring because you're desperate, you're in the middle of an active incident, or you're a monitoring fanatic. And there isn't a lot in between. So, there's a tweet that someone in my network tweeted me that I really liked which is, “Monitoring should be a chore, not a hobby.” And right now, it's either a hobby or an urgent necessity [laugh].And when it gets to the point—so you know, if we think about doing dishes this way, it would be as if, like, only, like, the dish fanatics did dishes, or, like, you will just have piles of dishes, like, all over the place and raccoons and no dishes left, and then you're, like, “Ah, time to do a thing.” But there should be something in between where there's a defined set of things that people can do on a regular basis to keep up with what they're doing. It should be accessible to everyone on the team, not just a couple of people who are true fanatics. No offense to the people out there, I love you guys, you're the ones who are really helping us build our tool the most, but you know, there's got to be a world in which more people are able to do the things you do.Corey: That's part of the challenge is bringing a lot of the fire down from Mount Olympus to the rest of humanity, where at some level, Prometheus was a great name from that—Jean: Yep [laugh].Corey: Just from that perspective because you basically need to be at that level of insight. I think Kubernetes suffers from the same overall problem where it is not reasonably responsible to run a Kubernetes production cluster without some people who really know what's going on. That's rapidly changing, which is for the better, because most companies are not going to be able to afford a multimillion-dollar team of operators who know the ins and outs of these incredibly complex systems. It has to become more accessible and simpler. And we have an entire near century at this point of watching abstractions get more and more and more complex and then collapsing down in this particular field. And I think that we're overdue for that correction in a lot of the modern infrastructure, tooling, and approaches that we take.Jean: I agree. It hasn't happened yet in monitoring and observability. It's happened in coding, it's happened in infrastructure, it's happened in APIs, but all of that has made it so that it's easier to get into monitoring debt. And it just hasn't happened yet for anything that's more reactive and more about understanding what the system is that you have.Corey: You mentioned specifically that your background was in programming languages. That's understating it slightly. You were a tenure-track professor of computer science at Carnegie Mellon before entering industry. How tied to what your area of academic speciality was, is what you're now at Akita?Jean: That's a great question and there are two answers to that. The first is very not tied. If it were tied, I would have stayed in my very cushy, highly [laugh] competitive job that I worked for years to get, to do stuff there. And so like, what we're doing now is comes out of thousands of conversations with developers and desire to build on the ground tools that I'm—there's some technically interesting parts to it, for sure. I think that our technical innovation is our moat, but is it at the level of publishable papers? Publishable papers are a very narrow thing; I wouldn't be able to say yes to that question.On the other hand, everything that I was trained to do was about identifying a problem and coming up with an out-of-the-box solution for it. And especially in programming languages research, it's really about abstractions. It's really about, you know, taking a set of patterns that you see of problems people have, coming up with the right abstractions to solve that problem, evaluating your solution, and then, you know, prototyping that out and building on top of it. And so, in that case, you know, we identified, hey, people have a huge gap when it comes to monitoring and observability. I framed it as an abstraction problem, how can we lift it up?We saw APIs as this is a great level to build a new level of solution. And our solution, it's innovative, but it also solves the problem. And to me, that's the most important thing. Our solution didn't need to be innovative. If you're operating in an academic setting, it's really about… producing a new idea. It doesn't actually [laugh]—I like to believe that all endeavors really have one main goal, and in academia, the main goal is producing something new. And to me, building a product is about solving a problem and our main endeavor was really to solve a real problem here.Corey: I think that it is, in many cases, useful when we start seeing a lot of, I guess, overflow back and forth between academia and industry, in both directions. I think that it is doing academia a disservice when you start looking at it purely as pure theory, and oh yeah, they don't deal with any of the vocational stuff. Conversely, I think the idea that industry doesn't have anything to learn from academia is dramatically misunderstanding the way the world works. The idea of watching some of that ebb and flow and crossover between them is neat to see.Jean: Yeah, I agree. I think there's a lot of academics I super respect and admire who have done great things that are useful in industry. And it's really about, I think, what you want your main goal to be at the time. Is it, do you want to be optimizing for new ideas or contributing, like, a full solution to a problem at the time? But it's there's a lot of overlap in the skills you need.Corey: One last topic I'd like to dive into before we call it an episode is that there's an awful lot of hype around a variety of different things. And right now in this moment, AI seems to be one of those areas that is getting an awful lot of attention. It's clear too there's something of value there—unlike blockchain, which has struggled to identify anything that was not fraud as a value proposition for the last decade-and-a-half—but it's clear that AI is offering value already. You have recently, as of this recording, released an AI chatbot, which, okay, great. But what piques my interest is one, it's a dog, which… germane to my interest, by all means, and two, it is marketed as, and I quote, “Exceedingly polite.”Jean: [laugh].Corey: Manners are important. Tell me about this pupper.Jean: Yeah, this dog came really out of four or five days of one of our engineers experimenting with ChatGPT. So, for a little bit of background, I'll just say that I have been excited about the this latest wave of AI since the beginning. So, I think at the very beginning, a lot of dev tools people were skeptical of GitHub Copilot; there was a lot of controversy around GitHub Copilot. I was very early. And I think all the Copilot people retweeted me because I was just their earlies—like, one of their earliest fans. I was like, “This is the coolest thing I've seen.”I've actually spent the decade before making fun of AI-based [laugh] programming. But there were two things about GitHub Copilot that made my jaw drop. And that's related to your question. So, for a little bit of background, I did my PhD in a group focused on program synthesis. So, it was really about, how can we automatically generate programs from a variety of means? From constraints—Corey: Like copying and pasting off a Stack Overflow, or—Jean: Well, the—I mean, that actually one of the projects that my group was literally applying machine-learning to terabytes of other example programs to generate new programs. So, it was very similar to GitHub Copilot before GitHub Copilot. It was synthesizing API calls from analyzing terabytes of other API calls. And the thing that I had always been uncomfortable with these machine-learning approaches in my group was, they were in the compiler loop. So, it was, you know, you wrote some code, the compiler did some AI, and then it spit back out some code that, you know, like you just ran.And so, that never sat well with me. I always said, “Well, I don't really see how this is going to be practical,” because people can't just run random code that you basically got off the internet. And so, what really excited me about GitHub Copilot was the fact that it was in the editor loop. I was like, “Oh, my God.”Corey: It had the context. It was right there. You didn't have to go tabbing to something else.Jean: Exactly.Corey: Oh, yeah. I'm in the same boat. I think it is basically—I've seen the future unfolding before my eyes.Jean: Yeah. Was the autocomplete thing. And to me, that was the missing piece. Because in your editor, you always read your code before you go off and—you know, like, you read your code, whoever code reviews your code reads your code. There's always at least, you know, two pairs of eyes, at least theoretically, reading your code.So, that was one thing that was jaw-dropping to me. That was the revelation of Copilot. And then the other thing was that it was marketed not as, “We write your code for you,” but the whole Copilot marketing was that, you know, it kind of helps you with boilerplate. And to me, I had been obsessed with this idea of how can you help developers write less boilerplate for years. And so, this AI-supported boilerplate copiloting was very exciting to me.And I saw that is very much the beginning of a new era, where, yes, there's tons of data on how we should be programming. I mean, all of Akita is based on the fact that we should be mining all the data we have about how your system and your code is operating to help you do stuff better. And so, to me, you know, Copilot is very much in that same philosophy. But our AI chatbot is, you know, just a next step along this progression. Because for us, you know, we collect all this data about your API behavior; we have been using non-AI methods to analyze this data and show it to you.And what ChatGPT allowed us to do in less than a week was analyze this data using very powerful large-language models and I have this conversational interface that both gives you the opportunity to check over and follow up on the question so that what you're spitting out—so what we're spitting out as Aki the dog doesn't have to be a hundred percent correct. But to me, the fact that Aki is exceedingly polite and kind of goofy—he, you know, randomly woofs and says a lot of things about how he's a dog—it's the right level of seriousness so that it's not messaging, hey, this is the end all, be all, the way, you know, the compiler loop never sat well with me because I just felt deeply uncomfortable that an AI was having that level of authority in a system, but a friendly dog that shows up and tells you some things that you can ask some additional questions to, no one's going to take him that seriously. But if he says something useful, you're going to listen. And so, I was really excited about the way this was set up. Because I mean, I believe that AI should be a collaborator and it should be a collaborator that you never take with full authority. And so, the chat and the politeness covered those two parts for me both.Corey: Yeah, on some level, I can't shake the feeling that it's still very early days there for Chat-Gipity—yes, that's how I pronounce it—and it's brethren as far as redefining, on some level, what's possible. I think that it's in many cases being overhyped, but it's solving an awful lot of the… the boilerplate, the stuff that is challenging. A question I have, though, is that, as a former professor, a concern that I have is when students are using this, it's less to do with the fact that they're not—they're taking shortcuts that weren't available to me and wanting to make them suffer, but rather, it's, on some level, if you use it to write your English papers, for example. Okay, great, it gets the boring essay you don't want to write out of the way, but the reason you write those things is it teaches you to form a story, to tell a narrative, to structure an argument, and I think that letting the computer do those things, on some level, has the potential to weaken us across the board. Where do you stand on it, given that you see both sides of that particular snake?Jean: So, here's a devil's advocate sort of response to it, is that maybe the writing [laugh] was never the important part. And it's, as you say, telling the story was the important part. And so, what better way to distill that out than the prompt engineering piece of it? Because if you knew that you could always get someone to flesh out your story for you, then it really comes down to, you know, I want to tell a story with these five main points. And in some way, you could see this as a playing field leveler.You know, I think that as a—English is actually not my first language. I spent a lot of time editing my parents writing for their work when I was a kid. And something I always felt really strongly about was not discriminating against people because they can't form sentences or they don't have the right idioms. And I actually spent a lot of time proofreading my friends' emails when I was in grad school for the non-native English speakers. And so, one way you could see this as, look, people who are not insiders now are on the same playing field. They just have to be clear thinkers.Corey: That is a fascinating take. I think I'm going to have to—I'm going to have to ruminate on that one. I really want to thank you for taking the time to speak with me today about what you're up to. If people want to learn more, where's the best place for them to find you?Jean: Well, I'm always on Twitter, still [laugh]. I'm @jeanqasaur—J-E-A-N-Q-A-S-A-U-R. And there's a chat dialog on akitasoftware.com. I [laugh] personally oversee a lot of that chat, so if you ever want to find me, that is a place, you know, where all messages will get back to me somehow.Corey: And we will, of course, put a link to that into the [show notes 00:35:01]. Thank you so much for your time. I appreciate it.Jean: Thank you, Corey.Corey: Jean Yang, CEO at Akita Software. I'm Cloud Economist Corey Quinn, and this is Screaming in the Cloud. If you've enjoyed this podcast, please leave a five-star review on your podcast platform of choice, whereas if you've hated this podcast, please leave a five-star review on your podcast platform of choice, along with an angry insulting comment that you will then, of course, proceed to copy to the other 17 podcast tools that you use, just like you do your observability monitoring suite.Corey: If your AWS bill keeps rising and your blood pressure is doing the same, then you need The Duckbill Group. We help companies fix their AWS bill by making it smaller and less horrifying. The Duckbill Group works for you, not AWS. We tailor recommendations to your business and we get to the point. Visit duckbillgroup.com to get started.
We cover building community & digital transformation with Yvette Pasqua, CTO @ Exos! She shares her leadership journey from MeetUp to Exos and how her experiences shaped her views on the importance of community and effective networking. We also discuss principles for creating authentic meetup experiences, how Yvette navigated her Head of Eng search without a recruiter, the importance of asking others for help, and how Exos navigated the opportunities & challenges through their digital transformation.ABOUT YVETTE PASQUAYvette (@lolarobot) is the CTO of Exos where she leads the product and engineering teams with a focus on continuous improvement, iteration, and using data to launch products that help our members become healthier and achieve their wellness, life, and work goals.Prior to joining Exos, Yvette led Product and Engineering at Haven, a health tech startup, and was the CTO at Meetup. Yvette's career has included leadership roles at startups and product development firms building products like Grindr and the Olympics video player. She's on the Board at Chloe Capital, a VC firm that invests in women-led seed-stage companies.Yvette lives in Brooklyn and Rhinebeck, NY with her wife, daughter, and wheaten terrier.“Yeah, of course during the conversation I will bring up, ‘Hey, I'm looking for a head of engineering. do you know anything? Do you have any advice? What have you thought of are the best characteristics for someone in that role?”It's a long-term play, but I think the important thing is to be really upfront with your intention for the chat. And to deliver on that in an authentic way. And to not BS someone and say, ‘Hey, I wanna network!' And then throw a job in their face and a job description.-Yvette PasquaInterested in joining an ELC Peer Group?ELCs Peer Groups provide a virtual, curated, and ongoing peer learning opportunity to help you navigate the unknown, uncover solutions and accelerate your learning with a small group of trusted peers.Apply to join a peer group HERE: sfelc.com/peerGroupsSHOW NOTES:Building technology with community in mind at MeetUp and Exos (2:20) (0:07)How community and in-person experiences inspire Yvette's career decisions (5:40)What Yvette learned about networking / community building from MeetUp (7:10)Principles for creating meaningful, authentic gatherings (10:54)Why setting boundaries & expectations encourages group psychological safety (12:38)How Yvette successfully navigated her Head of Eng search without a recruiter (14:32)Strategies for targeting potential hires that you haven't met before (17:40)Ask others for advice (21:31)Tactics for reaching out to people in an authentic way (23:40)Prioritizing time for networking conversations (27:55)Behind the digital transformation at Exos from a primarily coaching model (32:37)How Exos continuously models growth mindset (37:42)When digital transformation reaches a turning point (39:44)Rapid fire questions (42:38)LINKS AND RESOURCESThe Pragmatic Engineer by Gergely Orosz (blog/newsletter) - The #1 technology newsletter on Substack. Highly relevant for software engineers and engineering managers, useful for those working in tech. Written by engineering manager and software engineer Gergely Orosz who was previously at Uber, Skype/Microsoft, and at high-growth startups. (follow Gergely on Twitter @GergelyOrosz)Software Lead Weekly by Oren Ellenbogen (newsletter) - A weekly email for busy people who care about people, culture and leadership.Level Up by Patrick Kua (newsletter) - Level Up delivers a curated newsletter for leaders in tech. Ideal for busy people such as Tech Leads, Engineering Managers, VPs of Engineering, CTOs and more.Lenny's Newsletter by Lenny Rachitsky - A weekly advice column about product, growth, and your career.The Art of Gathering by Priya Parker (book) - Priya argues that the gatherings in our lives are lackluster and unproductive — and they don't have to be. At a time when coming together is more important than ever, Parker sets forth a human-centered approach to gathering that will help everyone create meaningful, memorable experiences, large and small, for work and for play. (Patrick's most gifted book)
This week we're back talking to Gergely Orosz — this time not quite about the insane tech hiring market, but more so the flip side, the 180, the not so good tech hiring market, the layoff market and what you can expect. There's a lot of FUD out there, so hopefully this show gives you a lens into what's really going on, and what to really expect. Maybe more so, how to keep your job or find a new job. We come to this topic with great compassion and great understanding, so please…there is a community here for you. There's a lot of people in our Slack. Call it your home, it's free to join and everyone is welcome.
This week we're back talking to Gergely Orosz — this time not quite about the insane tech hiring market, but more so the flip side, the 180, the not so good tech hiring market, the layoff market and what you can expect. There's a lot of FUD out there, so hopefully this show gives you a lens into what's really going on, and what to really expect. Maybe more so, how to keep your job or find a new job. We come to this topic with great compassion and great understanding, so please…there is a community here for you. There's a lot of people in our Slack. Call it your home, it's free to join and everyone is welcome.
Gergely Orosz writes the #1 technology newsletter at Substack, called The Pragmatic Engineer. He started his career as a software developer in the U.K., spent three years at Skype, and followed that role with four years as an engineering manager at Uber before deciding to leave big tech and work for himself. Gergely began pursuing his newsletter full-time in September 2021 and in just one year has amassed 200,000 subscribers. He now makes more money than he did at his salaried tech job, and with freedom and flexibility. In today's podcast, Gergely shares why he left his well-paying job at Uber, how he got his first 1,000 subscribers, why this kind of work can be stressful and lonely (but ultimately rewarding), and why it takes hard work to build authority and become a great writer. Working solo can be challenging, and in this episode, both Lenny and Gergely offer tips for structuring your unstructured time and finding your focus.—Find the full transcript here: https://www.lennyspodcast.com/leaving-big-tech-to-build-the-1-technology-newsletter-gergely-orosz-the-pragmatic-engineer/#transcript—Where to find Gergely Orosz:• Website: https://www.pragmaticengineer.com/• Newsletter: https://newsletter.pragmaticengineer.com• Twitter: https://twitter.com/GergelyOrosz• LinkedIn: https://www.linkedin.com/in/gergelyorosz/—Where to find Lenny:• Newsletter: https://www.lennysnewsletter.com• Twitter: https://twitter.com/lennysan• LinkedIn: https://www.linkedin.com/in/lennyrachitsky/—Thank you to our wonderful sponsors for making this episode possible:• Lemon.io: https://lemon.io/lenny• Eppo: https://www.geteppo.com/• Vanta: https://vanta.com/lenny—Referenced:• Gergely's books: https://blog.pragmaticengineer.com/books/• Centered: https://www.centered.app/• The Pomodoro technique: https://www.forbes.com/sites/bryancollinseurope/2020/03/03/the-pomodoro-technique/• Coding Horror: https://blog.codinghorror.com/• How to Achieve Ultimate Blog Success in One Easy Step: https://blog.codinghorror.com/how-to-achieve-ultimate-blog-success-in-one-easy-step/• A Comment Is an Invitation for Refactoring: https://blog.pragmaticengineer.com/a-comment-is-an-invitation-for-refactoring/• Kent Beck's website: https://www.kentbeck.com/• Steve Yegge's famous rant on Google vs. Amazon: https://www.alexanderjarvis.com/steve-yegges-famous-rant-on-google-vs-amazon/• Stevey's Tech Talk: https://www.youtube.com/playlist?list=PLZfuUWMTtMcC1DZF6HxJhqsGrBXu8Jzi7—In this episode, we cover:(04:32) Gergely's background(07:19) The Pragmatic Engineer, growth and current subscribers (08:59) Compensation with a subscription-based newsletter vs. his salaried position at Uber(10:55) How the onset of Covid and layoffs at Uber prompted Gergely to start his newsletter(23:10) What he did immediately after leaving Uber(25:41) The day-to-day of writing a newsletter(35:08) Tips for productivity(41:19) Gergely's favorite parts of entrepreneurship (43:15) The downsides of solo work(50:39) Why Gergely stopped making long-term plans(54:30) How to get started writing a newsletter(1:04:48) Key advice on building a successful newsletter—Production and marketing by https://penname.co/. For inquiries about sponsoring the podcast, email podcast@lennyrachitsky.com. Get full access to Lenny's Newsletter at www.lennysnewsletter.com/subscribe
Article about Louie's Career Trajectory by Gergely Orosz on PragmaticEngineer.com: https://newsletter.pragmaticengineer.com/p/from-engineer-to-director?s=r
Gergely Orosz of The Pragmatic Engineer helps us figure out the strategy and expectations of joining a high profile startup, vs. the expectations and reality of joining a FAANG company. Also: the perils and promise and best practices of joining a startup, vs. the perils and promise and best practices of joining a big tech company. Hopefully, if you are a tech worker, an engineer, a designer, what have you, there will be some valuable learnings for you. Oh, and Chris and I try our hand at Elon punditry.Sponsors:Composer.trade/rideSee Privacy Policy at https://art19.com/privacy and California Privacy Notice at https://art19.com/privacy#do-not-sell-my-info.
Leland Takamine, CEO & Co-founder, mobile.dev Leland Co-founder & CEO of mobile.dev, the first "shift left" mobile development platform for high-quality mobile experiences. Their software finds bugs and performance issues before a new mobile release goes out. The origins of mobile.dev are in the project nanoscope, which Leland open-sourced while at Uber. The number and quality of companies using nanoscope signaled the need for better mobile development tooling. Since launching, mobile.dev has signed enterprise customers such as Reddit and raised funding from Cowboy Ventures along with strategic funds and angels such as Essence VC, President of Coinbase Emilie Choi, VP Engineering from Robinhood Surabhi Gupta, "Building Mobile Apps at Scale" author Gergely Orosz, Founder of Kong Marco Palladino, and mobile influencer PY Ricau among others. In this episode, we discuss the decision to create and open-source nanoscope, how nanoscope led to mobile.dev, the "Shift Left Mobile" movement, and Leland's journey as a leader - particularly on going from technologist to CEO. mobile.dev is also hiring. Check out open reqs for Android Lead, Frontend Lead, and Device Cloud Engineering Lead (all remote)!
This week we're joined by Gergely Orosz and we're talking about the insane tech hiring market we're in right now. Gergely was on the show a year ago talking about growing as a software engineer and his book The Tech Resume Inside Out. Now he's laser focused on Substack with actionable advice for engineering managers and engineers, with a focus on big tech and high-growth startups. On today's show we dig into his recent coverage of “the perfect storm” that's causing this insane tech hiring market.
This week we're joined by Gergely Orosz and we're talking about the insane tech hiring market we're in right now. Gergely was on the show a year ago talking about growing as a software engineer and his book The Tech Resume Inside Out. Now he's laser focused on Substack with actionable advice for engineering managers and engineers, with a focus on big tech and high-growth startups. On today's show we dig into his recent coverage of “the perfect storm” that's causing this insane tech hiring market.
In this episode, Jean Hsu, VP of Engineering at Range, chats with Gergely Orosz — formerly at Uber, Skyscanner, and Skype — about the decision to go into management.Jean and Gergely chat about:Why Gergely thought management was LAME - and resisted becoming a managerThe huge contrast between becoming an “accidental manager” at a startup and becoming a manager at UberDefining his leadership by having a list he had created of all the managers he wanted to avoid beingHow to support new managers and set them up for successHow a checklist of management activities can create a tighter feedback loop for new managersThe unexpected loneliness of being a managerYou can find the manager checklist Gergely used for new managers here: https://blog.pragmaticengineer.com/checklist-for-first-time-managers
Modern applications are increasingly built as large, distributed systems. A distributed system is a program where its components are located on different machines that communicate with one another to create a single cohesive app. Components may exist as multiple instances across “nodes,” the computers hosting them, which form clusters of nodes that span across geographic The post Uber Mobile Engineering: Distributed Payment Systems with Gergely Orosz appeared first on Software Engineering Daily.
Modern applications are increasingly built as large, distributed systems. A distributed system is a program where its components are located on different machines that communicate with one another to create a single cohesive app. Components may exist as multiple instances across “nodes,” the computers hosting them, which form clusters of nodes that span across geographic The post Uber Mobile Engineering: Distributed Payment Systems with Gergely Orosz appeared first on Software Engineering Daily.
Modern applications are increasingly built as large, distributed systems. A distributed system is a program where its components are located on different machines that communicate with one another to create a single cohesive app. Components may exist as multiple instances across “nodes,” the computers hosting them, which form clusters of nodes that span across geographic
Modern applications are increasingly built as large, distributed systems. A distributed system is a program where its components are located on different machines that communicate with one another to create a single cohesive app. Components may exist as multiple instances across “nodes,” the computers hosting them, which form clusters of nodes that span across geographic The post Uber Mobile Engineering: Distributed Payment Systems with Gergely Orosz appeared first on Software Engineering Daily.
This Clubhouse-style Q&A was held as part of my support for React Summit 2021 (https://remote.reactsummit.com/). Moderated by Robert Haritonov, CEO of GitNation.Timestamps 2:30 How do you keep up with the changing landscape? 5:00 Balancing Learning Time with a Job 7:15 What are the top technical and soft skills to transition from junior to senior? 12:30 The Importance of Communication and How to Do it Well 17:30 Prioritization, Batching and Pair Programming 19:20 What can Seniors Do to Help Foster Juniors? Apprenticeships, Mentoring, Sponsorship and Allyship 23:15 How to convince older devs to try new tech? Address their concerns, do proofs of concept, know when to fold. 28:45 Nontraditional background. How to convince people to let you through the door? Networking and Personal Content Marketing. 34:00 How do you make technical decisions as a senior and avoid getting stuck? Innovation Tokens, Action Produces Information, Pay for Advice 40:30 Fall in Love with the Problem, Not the Solution 42:00 Can you still be a fullstack engineer? If you enjoyed this chat, you're welcome to check out our career community for 30% off!Mentioned Links Chapter 5 - Junior to Senior (free PDF) Gergely Orosz's Tech Resume Inside Out My Podcast Recommendations Every Public Engineering Career Ladder Sponsorship: https://larahogan.me/blog/what-sponsorship-looks-like/ Allyship: https://www.samanthabretous.com/blog/black-women-equal-pay-day-heres-how-you-can-help/ Diversity Resources (this is a work in progress list, hence not yet published, but i've been sharing these with pple who ask): https://gist.github.com/sw-yx/7aeedbeac1bb81017cd4f9d66b223b63 Ninah Mufleh Airbnb Resume Innovation Tokens If you'd like to see my React Summit talk, check out: https://youtu.be/yLgq-Foc1EE TranscriptRobert Haritonov: [00:00:00] So yeah, I'll let you get to your Shawn just, go ahead as you please? swyx: [00:00:03] Hey everyone. Hey, I'm Shawn, also known as Swyx on the internet.I'm a React fan and but also a Svelte fan and one of my talks, that I speaking later on in an hour or so is seven Lessons to Outlive React. But this discussion room is a different topic. It's a non-technical topic. It's related to the book I published last year.Basically talking about how people can go from junior to senior, how the non-technical elements of the software engineering job is very relevant for our career progression and something that we don't really talk about enough. And yeah, I'm very interested in sharing my experience, the experiences of the people that I learned from.If you wanna check out the, the amount of research I did you can check out the site at LearnInPublic.org.I'm going to just explain a little bit of what I wrote on the junior and senior chapter. So essentially part of what I was trying to do here was define what a senior engineer is.And it's one of those things where everyone has a different opinion and it's more of a pay scale than it is a well accepted metric. To some people you have to have at least three years at a high growth startup. Others can take up to eight years to become a senior engineer. Or there's, let's just say they don't care about the number of years, right? It's more about what you can do. And ultimately I think for me is what I really care about is for everyone to have the prerequisite skills enough of the prerequisite skills, and accomplishments that you can make a strong case for a senior developer, but then also market yourself as meeting enough so that people notice you and hire you whether, internal promotion or externally when you do a lateral transfer to another company. And I think a lot of times it involves acting like a senior engineer before you officially become one. So it's a bit of a chicken and egg, right? And I think that's something that we have to recognize more and study more. . Because I don't think we have enough of a conversation about how to convert juniors to seniors and It's the biggest gap in the industry, everyone wants to hire seniors, but there are so many juniors trying to try to upskill themselves. 2:30 How do you keep up with the changing landscape?I've just invited avocado Mayo. Are you able to speak hi, can you hear me? Hey, how's it going? Shawn? The eye. Good. Thank you. I'm a developer based in Canada. I am, I have a question for you a general career advice.So I, I feel that the front end landscape is constantly changing and the web is constantly evolving. A question that I have for you is what are some ways that you kept up with the cutting edge so that your call I'll still the learning and what are some ways that you kept up with the changing landscape in development?Great question. It's something I get a lot, but honestly I don't, I haven't really slowed down to like document a process. I just do whatever comes to mind. So this is a bit off the cuff. So something I care a lot about I think it would not be an exaggeration to say that I do get a lot of my tech news off of Twitter and the things that, so I tend to do this strategy, which I call following the graph, which is like figuring out what the smart people that have effect they have built, the things that you use, like the reacts and the babbles and the WebEx, figuring out what they, how they got where they are and what they're working on today, because they're also excited about other things they didn't stop just because they were done working on, on, on the tool.So I follow the graph, like I follow who they follow, and then I figured out who their influences are and try to understand the historical context of where these technologies fit in. And that's all an attempt to try to figure out like what themes I should focus on for the future. So every now and then I try to step back and go okay what am I interested in?Because I think honestly the reality is that there's too much to keep up on. And I think if you try to keep up on everything, it's a full-time job and you'll never go deep on any particular topic. And that's also really bad. It's not enough to just know the names of every project.You actually have to have tried it out to know the philosophy. You have an opinion when you're, in your company, you're asked for it. So that's why I try to do I tried to have a thesis. I tried to inform it by following people who I think are doing interesting things in the ecosystem. I think attending conferences actually really helps a lot because the people who are excited enough to give a talk about something, it's probably something I should at least be aware of, like what it's about.And I have this four-step framework that I borrow from thought bot I think, or thought works. Where it's it's like assess adopt, avoid. And I forget what the fourth category is, but basically just have an idea of what you are choosing to focus on what you're monitoring and not really getting into right now, but could be, and what you've just decided.Okay. Hey, there's just too much going on. I need to filter something out. And I think that's a very healthy way to stay on top of things.5:00 Balancing Learning Time with a JobThank you so much, Shawn. I have one follow-up question before I I go back to the audience. So as you mentioned, it's I feel like when I, whenever I get on Twitter, there's an overwhelming amount of information. And I find it also really hard with all these emerging technologies to balance. I like the, my actual job and learning these new things.Do you have any advice for how you manage your time for learning new things and actually, getting your job done? Wow. That's a, that's an awesome question. I think it will be it's very nice. A lot of companies have this idea of some learning time.For some companies that's half a day, every week. So I'm going to be just like one day, every two weeks, whatever it is. If your company can budget in some learning time on the side, I think that really is very helpful. For me, I do a lot of side projects. I will dive into to things outside of company time.That's something that's not necessarily something that everyone can do because they have a life for her family outside of outside of work. But I don't know that there's, you can find ways to. I guess keep tabs. And if something's not working out for you, be okay with letting it go and try something else.So if you're doing X, if you're doing, if you're working out, there's plenty of podcasts, I can recommend to you. Just go on my blog and look for a podcast. I have list of like 250 podcasts. And and you can keep up that way, right? Like you, you could be doing something active and still learning.You could be, just experiment with different forms of learning, in, in different people learn in different ways. So I definitely think that I learned best by, by keeping my focus small on like the number of topics and themes I get excited about and just ignoring the rest and then actually trying stuff out because.You really only go get so much just like looking at tweets and reading, readme's. It's once you actually have tried the thing out, then you have a strong opinion. And you pretty soon find yourself like recommending it at work. And it's pretty cool when like the stuff you learn on the side comes in and actually has a positive impact on something you do at work.And that's where I think people start to really see the value of you learning during work as well. So you can make a case for that.Robert Haritonov: [00:06:56] So Shawn, I've been doing some discord management, created the channel. People can ask a question there as well. It's right. The whole discussion around what's called discussion. I'm going from junior to senior. There was one questionnaire, but we also have two people joining here with voice, so Kwan and dome.swyx: [00:07:12] I think Dom raised his hand first. I'll go first. 7:15 What are the top technical and soft skills to transition from junior to senior?Robert Haritonov: [00:07:16] So I have two questions. The first question would be what are like your top evaluation of skills for technical and soft skills for that transition from junior to senior.And second, my question is my second question is regarding how do you know you're in that same like level of senior after, when you start off as a junior without having that swyx: [00:07:39] imposter syndrome? The second one is it's closer to home. The first one, let me try and rephrase the first question. Cause I don't think I really got it.What level of technical skills are required? You said Robert Haritonov: [00:07:48] What do you think differentiates a junior dev on a technical level from a senior dev both texts like technical level swyx: [00:07:56] and soft skills. Yeah. It's it, obviously we're at a front end focus conference, but I try to keep my answers agnostic or front end or back end, and it's going to depend on, whatever team you work on.But here's the bottom line, right? I think that seniors should be able to independently ship something from beginning to end, like the buck stops with you. And for most things I can just give you an assignment and you can basically ship. That feature or that issue or that Epic basically on your own, without much guidance, whereas a junior obviously would be expected to to be given as much resources as possible.So that independence is a very, very key part of the senior definition. The non-technical elements there, there are a lot of other definitions as well. Mentorship is a key one. Once you get to a point where people start coming to you for advice that's a strong sign of a senior developer and being able to be a force multiplier for the rest of your team.So, you're not just concerned with your own performance. You're also concerned about your team's performance and working on. Either processes or even dev tools or infrastructure tools to make them all more productive. These are all qualities that people shout out as as positive aspects of a senior developer.I have this essay called junior engineers, senior engineer, and I have a list of like little quotes that distinguish things between junior and senior, which I could read out (see the PDF linked above). I don't know if that would be helpful. But then I can also talk about, I guess I'll squeeze in one more thing before I, I give I talk about the.The katas which is career letters, right? Study your company's career ladder. If your company doesn't have one, try to get involved in in creating, defining one, because if you get a hand in defining your own career ladder, then you get to, nudge things in a way that you like, which is very nice.But if you need help if a company doesn't have one, there are a lot of public career letters out there. So I have a blog posts. That's literally just Google every engineering career ladder. And it's, I've just compiled like 30 different career letters from the financial times Kickstarter rent, the runway medium all sorts of career letters that is done in public.And you can just study them Circle CI has a really, really good career ladder, by the way. And just study, like what they define to be the qualities of a software engineer, one versus two, versus a senior versus principal versus staff. You get to see the difference. There's more and more industry impact.There's more and more emphasis on communication. In fact, the more senior you go, it's the less technical elements are still a big part of it. But then you're also expected to be able to contribute on non technical elements, which I really. I want people to wake up to essentially even if you look at circle CII, which is one of the most technically rigorous companies out there something like 75% of their promotion criteria are essentially non-technical which people don't really realize.Like it's not something that you learn in bootcamp or in, your CS degree that, Hey, you should be good at communication or understanding how your technology fits into the broader business strategy. But that's something that people put on the career letter. And therefore you are incentivized to learn about that as you want to progress in your junior and senior path. Does that, I want to pause cause I've gone on for a bit does that help it? Yeah. Yeah, Robert Haritonov: [00:10:58] for sure. I'll have to. Search your your resources, swyx: [00:11:01] but I'll definitely check that out. By the way, talking with me is like this I always go I have a blog post of that, and that's a strategy to, you like straight up, like I'm someone making fun of myself, but think about what if you had that at work, right?What if you you had a conversation, but then you had a really well thought through written thing to back it up so you can send it to whoever you're talking to. Like people will just like you, you're not only sound smarter. I don't sound super smart right now because I haven't really been thinking about this topic recently but.You just sound more prepared like you've covered all your bases and like... the bit rate of trends of information transfer right now from me to you is not very high, right? Like it's just whatever I can think of. And I'm not very good on the wall, but while I'm writing, I can structure things, organize things, make links and follow up references and stuff like that.That's just really, really smart. Write things down and I think it's a really good skill of a senior developer. Yeah. Shawn, sorry, I'll Robert Haritonov: [00:11:53] stop you here. We've been swyx: [00:11:54] Hiked out. We have Robert Haritonov: [00:11:55] so many listeners here. There is all the questions and the ex chat as well. People do have some issues when they try to get on stage.So I suggest people also to ask the question in check, swyx: [00:12:07] And Shawn, the kitchen since there all the Robert Haritonov: [00:12:09] questions. Maybe let's live with one swyx: [00:12:11] question for the first time, Robert Haritonov: [00:12:12] Just to try covering water base as, yeah. There's just a swyx: [00:12:15] lot of Devin chatter here. People might have been with Q as first, Robert Haritonov: [00:12:19] like you.And swyx: [00:12:20] then there are questions. Yeah. And feel free to just ask stuff in and I can answer asynchronously on the text chat. 12:30 The Importance of Communication and How to Do it WellQuestioner: [00:12:34] Your previous answer really helps the transition to this question.As far as I know, something super important to become a senior, our communication skills. Do you agree with this? I guess you do. If you do, what resources do you recommend and what tips do you have? The things that you wished you knew during the transition process, when you might've felt lost.swyx: [00:12:50] Oh, that's an interesting question. So of course I believe that communication skills are very important. In fact, it's probably one of the most common things that are in the career ladder. If you study them so very important and I will also volunteer that. I don't think I'm very good at it.I'm decent. I, I don't fail my own evaluation, but I've seen people who are way better than me about it. So I think resources wise there's a lot about communication across cultures, which is something I think about a lot. One thing I can point you to is I think the lady bug podcast, I think a lady bug FM or something like that, they did a whole episode on communication skills, which I quite recommend the D they have some tips about just.Understanding how it comes across how you come across. And really having empathy for what the other person is thinking and feeling. A lot of the times we have to understand that we're not just, let's say you're doing a code review you and you're pointing out flaws in somebody's code.It doesn't reach them that you're trying to help. Unless you break down that barrier, that kid and remind them like, Hey, I'm on your side. You have to break, go past like the emotional barrier of Hey, does this is this person a threat? Are they making fun of me? There's all sorts of things going on the other person's head.And you have to reassure them like, no, I'm really, I'm your partner. I'm here to help. And that's something that is, it is a skill as well. And particularly in some some cultures where. Sometimes the respect for authority is, can be very different. The the expectation of like your, the message that, that has received.If it, if you say something once, do they, is the responsibility on the recipient or on the deliverer to make sure that the message went through. These are all things where communication has led to real disasters before like planes crashing, because People thought that, the message was delivered and it wasn't.So I don't know. I don't like, this is a huge topic. I don't know if I've fully answered your question, but I think when in doubt, just write more whether it's like writing up your decision on, like, why you make a technical choice, they just write it in a comment, I think or just like your PR.One of my most popular interview blog posts when I was at Netlify was how we do feedback ladders.So I think if you do, if you look, if you Google, like Netlify code review or Netlify feedback ladders, you'll get this post where we actually have a system for encoding what we're trying to say, because it's when it, when you're in a, when you're in a cold, medium there's a difference between cold and hot mediums.When you're in a cold, medium, like a GitHub PR review, people can read a lot into, like, where do you put it? A period at the end of your sentence are you being passive aggressive right now or are you just, making a joke or are you, is there a sarcasm? Is there do you think this is a big deal and I should handle it right now? Or is this just a comment? Take it or leave it. There are all these little subtle nuances that you can skip. If you have a clear code that you communicate with your coworkers with. And I think the last point I'll make is for feedback reviews which I really like is preemptively review your own code. So that you save one round trip. So when you make a PR you just think about okay, what is this person going to say? I've worked with them enough. Let's like emulate them in my head and go like, all right, what are the typical comments that they would make and just anticipate them and then write your response.And just by the sheer act of doing that, people would really appreciate it. And they understand that you've addressed their concerns and now they can move on to you with the more important stuff that they sell them, get the chance to get to. So I there's a lot here, communication is a really deep topic.And I'm not the authority on that. Like I just think that people should practice it more and realize that it is as important to them as their coding skills. Questioner: No. Yeah. That makes a lot of sense. Thank you for your answer. Do you have any resources that you're looking at? I don't want it to be like a one way street. Not me specifically. I'm trying to ask around as well, just to learn as much as possible. It has a communication resources. Just pop it in a discord channel. That's next to this room. That's a crowdsource. This thing. That sounds amazing, actually. Yes. Yes. On the same note you already answered this as well. How do you describe a senior? What should developers aim for mostly, if there's anything else you want to add and regarding the resources, how can we get your senior to junior coach?swyx: [00:16:37] Oh yeah. So that's a chapter in the book. I can I will look at releasing I'll look at printing it out so that I can just release it for free in the channel. But essentially, yeah I, I wrote this, I wrote the, I wrote my book Linden, public.org. I wrote the whole thing just to address this answer of the principles, strategies, and tactics that I use to get to where I am, and also the behaviors that I observed in the people that I really admire.So I have about 1400 links for people that go down a lot of rabbit holes. Yeah, hopefully that helps. But I can read out, do I don't, do we have a lot of time left? I feel like we're, we might be a bit out of time. Cause we have, we can create, we can do Robert Haritonov: [00:17:18] like a microphone, 34 hours myself, but let's first go through the majority of general questions as an exit face. Yeah. So based on gone, sorry, I'll remove you from the audience so that people can ask questions. Thanks, CRS. Joining us for awhile. CRS, whatnot. And three eight, go ahead and ask your question.17:30 Prioritization, Batching and Pair Programming swyx: [00:17:36] I guess they think that and answering questions for all your junior developers. How do you go about that? Yeah, it's a fair question. I think the vast majority of senior developers should be writing their own code still. There are more senior positions especially management as well as architects positions, where you might be writing a lot less code.But a lot of times you'll will be balancing between reviewing and mentoring others versus writing your own code and being an individual contributor. And that's a little bit challenging. But I think you should be able to find time like obviously mentoring and working with the team is very important.And then you should be able to figure it out. How to fit in your your individual work separately, on your own something I picked up from my ex boss, Sarah Drasner is that she actually batches her work. So if you look at her blog posts, CSS tricks, prioritization, just Google that she laid down this philosophy of basically batching this work, like individual work goes on Thursdays and maybe a bit of Fridays and then meetings are Mondays and Tuesdays, and she is coming at it from a management point of view.But I really think that it also applies to an individual contributor as senior dev, right? If you have a lot of sort of review work batch those meetings together and also try to upgrade your bandwidth again make it very, it's very easy to pair program. People don't do it. And th the every time you do it, both sides learn something about either the way you work, or learn a new trick in the editor.It's a very high bandwidth communication skill. I would recommend that batching and then pair programming.Robert Haritonov: [00:19:06] So have a role SKUs that I joined and then a super Shawn quick. Now it's there, there's some voice of community that's me as with you. So there's no big on nice push check, push. You brought up because it's constant sound from your diagnostics and they're all discussed definitely to not having to ask your question. 19:20 What can Seniors Do to Help Foster Juniors? Apprenticeships, Mentoring, Sponsorship and AllyshipQuestioner: [00:19:23] Okay. So my question is more coming from the other end. I'm a senior kind of more experienced developer and I'm wondering. Kind of what I can do to help people, or what are things senior does or not doing to help foster junior devs? Cause I don't, I want to know what I can do to make more people more diversity, like the industry, a better place to work in.Wow. Okay. This, so I thought there was this was a question about people already on your team, but you're still saying the industry as a whole. That's great. Questioner: [00:19:53] Yeah. I know. Like I can start with my team, but obviously one good safe, it's going to be a ripple effect.swyx: [00:20:01] So my direct answer is someone who changed.I changed careers at age 30, right? The right answer is more internships and apprenticeships for people with non-traditional backgrounds. We at tech companies have a lot of re entry routes for people for traditional degrees, like CS degrees. But then if you just went a different way and then came in to, to the tech industry later in life, you don't have those opportunities.And I think a lot of people, especially of, diverse backgrounds would benefit from that. So that's my immediate shout out. And my wishlist is if I could wave a wand and have every single company take in, two more. Interns or apprentices. I think that we do a lot better just because the main thing is to get people to experience, and after, six months, a year of apprenticing and interning under someone else, they will have a lot better of a resume to, to go job hunt. And that then they're off, they're they're off to the races. I think the other thing I think is also opening up opportunities for people.So as someone who's a very plugged in and very capable. People will throw a lot of opportunities to you and you need to be aware of what you don't necessarily you, you could do in your sleep, but you don't necessarily have to do, and it doesn't have to be done right this second that you can actually hold off and just go - Hey and open up this opportunity for someone more junior on your team to let them do it and you can start supervising.So I hope that's not like too, I don't know. It's not like delegation. Yeah. More, so much as like mentoring, right? Because ultimately your success is you make another one of yourself. I always say the best way to be a 10 X developer is to teach everything, to 10 people around you.Rather than the individually 10 X and do everything yourself. So I hope that those are the immediate things that come to mind. Obviously, I think donating actually helps a lot, like your money goes a long way with free code camp. And and also getting your company to sponsor those those diverse organizations and hire make sure make sure you like the hiring pipeline is equally diverse.That I feel like I feel like I'm saying obvious things, but how does that resonate when you think about your question? Questioner: No, that, that makes sense. Especially yeah, the letting go, the things like I know, as a know, sometimes it is hard to let go something where you're like, this would take me, very quickly this time, but the mentorship which takes, a little bit longer is way more beneficial to everyone in the long run.swyx: Yeah. Yeah, exactly, exactly. So I w I would call out, so some I actually forget who came up with this idea, I think was Lara Hogan. She defined a difference between sponsorship and mentorship and, or I think sponsorship in allyship as well. It's I feel like it's so weird for me to tell a woman this cause I'm not the expert on that myself.So I would recommend those resources as well. And I'm going to paste the list of diversity and tech organizations, which I've been really following and has been helping me learn a lot about this as well. Veni Kunche has a newsletter, which I encourage everybody here to sign up because she really has a balanced view, which I love which is okay, like we're not doing well.But she doesn't damn you for it. She just says, gives you a stern look and goes like you can do better in any way. Yeah. Yeah. We know. Vinnie crunchy of diversified tech. She has a great newsletter and if you want to, hire people of diverse backgrounds definitely go sponsor her.Awesome. Thank you so much. Thank you. 23:15 How to convince older devs to try new tech?Robert Haritonov: [00:23:16] know, let me try it on a museum. Supertramp can you Questioner: [00:23:21] ask your question? Yeah. Okay, great. Hey Shawn. I had a question where essentially I don't enjoy working where I am right now.Mostly due to the lack of kind of the learning opportunities. Primarily my team, they really enjoy a very old version of PHP and I'm trying to convince them that there is some proof in the success of modern react or JavaScript or modern frameworks. I just wanted to ask if, did you have any tips to convince old PHP data's or old kind of web developers that it's okay to give some jobs could swyx: [00:23:57] Wow. Hmm. Why are they? I T I have to dig into that further. Why are they opposed to adding new frameworks and stuff? What is their stated reason. Questioner: [00:24:07] A lot of our products are very public facing. So they fear that if we make any kind of change that might affect like client facing products, they worry that it might break. So they just say, all right, we see what you're trying to do here. We want to, we understand that you want to improve our code, but it's currently working. So why do we need to fix it? swyx: [00:24:28] I have a lot of sympathy with the don't fix one in Brooklyn thing. I think that's actually something that people get to after a lot of pain.They're not necessarily wrong. But obviously what you're trying to do is also improve the user experience. And that's something that they should be prioritizing as well. Are they optimizing for their own comfort or are they really, making a technical trade off.Here. So it's not clear to me, obviously I'm not in your situation. And I can't really speak for them. But ultimately I think there's only so much you can do as an engineer. That's probably junior to them. You make your case and you make a S a strong, where you can do is for example, like a proof of concept.I'll give you one example, the a friend of mine, Zach Argyle he actually worked at Pinterest where he was trying to advocate really strongly for a progressive web app. And everyone at Pinterest was just like, no, like it's a waste of time, whatever. And he was ignored for two years. And the way he got through was he did a hackathon where he just built a basic Pinterest PWA and shown the really high.And, metrics that you can get in performance as a PWA, directly to the CEO and that impressed them so much that they converted themselves to a PWA. So sometimes you have to do a stunt like that to get through to people. But ultimately you cannot convince someone who doesn't want to be convinced.It just doesn't have an open mind. And I was already decided that their answer is right. And in that sense, you got to look out for yourself, right? So there are plenty of other developer companies will love to hire someone like you who's passionate about modern technology and no judgment on them.Right? Like they're B they probably, they think they know what's best. But you should also figure out what's best for you.Questioner: [00:26:05] Thank you. I like I totally. Yeah I'm totally happy to hear that. There are potential solutions for like more and water like solutions for the problems that I'm facing at my convenience facing. But if he has, like, whenever I try to present them, they Shut me off because of the fact that I'm like more of a junior developerswyx: [00:26:23] You have to earn it, right? There's a given get here. Like they have to make room for you. And if they're not the they're making a mistake but then also you shouldn't come in and just have them listen, like demand that they listen to you have to earn it as well. Maybe also look for small projects, too side projects that that they could split off to let you experiment. That don't matter as much to them. Sometimes you can do a lot of this through internal tooling, right? What do your sales or marketing or product managers need, build that for them and see that, see the benefits internally before rolling it out externally, right? These are all things that I've actually done because people weren't letting me do it. People don't let you through the front door, go to the side, go on the back figure it out. That's cool. Yeah, Questioner: [00:27:02] I'm actually only point of that topic. I did design like a next JS version of a, so what we did here is generate like what forms for people to put their data.And then we we do lead generation based off that data. And I did take that initiative and create a kind of like a front end, like next JS project. But then they looked at it and they thought that this was cool, but then they didn't think it was scalable.And they, I tried to have like more of a conversation with them about that, but then they were well, yeah, we've been doing like HP or he needs it. He's older, like pretty much for a longer time. So it just felt like. At that point in, in the one that I was presenting the project I should also say that they were they're currently sponsoring me.I'm from Canada, I'm trying to like, I'm currently working in the UK. So at that point in time, I was thinking like, this is I think the third or fourth time, they disregarded my kind of my attempt, to improve the, let's just say the initial code base. swyx: [00:28:02] I appreciate your Tufts situation supertramp and happy to chat with you. Async as well on the discord. Yeah, of course. Thank you. Robert Haritonov: [00:28:09] All right. So if anyone else wants to ask a question, raise your hand. We'll set the stage. Meanwhile, Shawn, you can just cram maybe swyx: [00:28:16] through your questions Robert Haritonov: [00:28:17] in the light. Maybe you get a big swyx: [00:28:21] face on that.If people were trying to hire a super Supertramp andIt's a good idea to, yeah. Honestly, I find a lot of people changing jobs at conferences. It's a really nice thing to see and good for labor mobility, but maybe not so good for employers sending people to conferences. I don't know, but if you're confident in your employer brand, then you should be a net hire from conferences.And if you're not, then it should not be so good for you. 28:45 Nontraditional background. How to convince people to let you through the door? Networking and Personal Content Marketing.questioner: Hey Lucy. Lucia. Yeah, Lucy was here. I don't know. So I'm actually a developer who came from a very non-traditional background. And they did a bootcamp to get into our changed careers about two years ago now. So I did a four-month bootcamp and I managed to secure my first job, which was amazing. When I was transitioning from my first job to my second job, the issue I was encountering was I wasn't even really being given the chance to get through the door for the interview.The few interviews I did get, I found that if I got to that stage, I was able to convince them that I was a good candidate. I got a couple of offers, which was amazing. So my question was like, how do you convince people to let you through the door? Just from your CV, if you're forming a more non-traditional background.Wow. Yeah, that's a challenging one and there are a number of ways, essentially networking is the one that comes to mind, it's my friend Gergely Orosz wrote a... Little, I think it's a free book called the tech resume inside out maybe. I'm not exactly sure. What his book is.I want it, someone, let me look it up. But he actually had this, he had he'd look at the numbers, and a lot of people don't get through the first screen, which is the resume review screen. Cause people take a look at your resume for 30 seconds. And it's a very inefficient transmission format.Cause you're supposed to serialize your experience and your potential down to a single piece of paper. And you hope that they have the correct deserialization algorithm to, to do that and figure out that Hey, you're someone that they should be talking to. So I really liked the other way of networking within the company and getting a warm introduction so that they not only skip you to like the next step where you actually do a proper interview, a phone screen. They also give you a few hints as to what the company values and what you could be doing there because ultimately you want to have a good answer for like, why are you interested in working with us?And that's something that you really get from like understanding the company really well and talking to people internally within the company. So that's one thing, I it's, I think it's a very common thing to say Hey if I buy your coffee we we let me pick your brain. Don't use those exact words because picking your brain is extremely overrated in 2021, but you could go I'm interested in applying I, and I'd love to learn more about your day to day stuff like that. It's just a very genuine people know what you're trying to do.And we've all been in your shoes. That'd be not all, but we appreciate that. You're trying to get somewhere and I think people really appreciate the effort that you put in to even like a cold email, right? To say Hey, we've never met, but like you work at this company, I really interested in it.Do you have 15 minutes to chat? Most people will say yes. And I think that's a good way to get going. If we're doing this in person, I would actually not recommend coffee. I'd recommend a walk in the park which is something I used to do in New York. Okay. The other thing I really like is the permissionless application, right? You're applying through a CV and, you may have a portfolio if you're a more design and front end oriented person. But you can also do Like a breakdown. So some, a story I really liked was this woman who was very interested in working on marketing for Airbnb and realize that, she was wanting to show some in the middle East.And she realized that the Airbnb didn't really have an middle Eastern presence. So she mocked up a fake site. That just looked like Airbnb and just demonstrated her potential as someone who could do that. She worked in marketing, but you could equally work, do that for engineering, right?Like just do a simple CLO and talk about a specific algorithm that that you could work on. A friend of mine from my bootcamp actually broke down the collaborative filtering algorithm of Spotify and she got an interview there. Because it, it went viral.So like people were Spotify would definitely noticed. But it just shows a level of commitment and interest that most people don't have because you're not praying. It's the industry term is called spraying and praying, like anything that you think that you can do to show that you genuinely have interest, and you're not just like throwing your resume every which way.I think that actually just puts you in front of the line. So that's my quick take. Yeah. Ultimately, so ultimately you won't start this way, but ultimately what you want to get to is you want to be, you want to have your domain and your sort of expertise. So well-marketed that people come to you, right?Whatever you're particularly interested in winter where there's animation or accessibility, or responsive design, whatever it is, you want to be such an authority on that. And people come to you for things that you're interested in. And then the hiring conversation becomes very different.It's more about whether they're a fit for your interests whether as compared to, can you contort yourself to something that they need right now, which is at the end of the day, like if you apply to the company in the end, they're just not hiring. You're not getting in the middle of what so it's really dependent on those things, but hopefully I've given you some ideas here.Yeah. That actually has been really helpful because it actually talks with. My experience in that, one of the offers that I got was specifically because I've been to around them meetup talk and messaged someone who'd been talking and was basically saying saying things like I'm struggling to, to get people to listen to me, but I feel like I'm a really good candidate.Yeah. And then I just struck up a conversation with him online reading 10 and from that I then got an interview which then led to an offer which was awesome. But yeah, I actually hadn't really thought about it in that way, but actually yet it really does make sense. What we're really doing here for those interested is we're doing personal content marketing is the same thing that companies are doing for their brands and their products.And we can do it on a personal level. Cool. Lucy, thanks, sir. That's a great question. Go ahead and answer your question.Just remember to push book. 34:00 How do you make technical decisions as a senior and avoid getting stuck? Innovation Tokens, Action Produces Information, Pay for AdviceQuestioner: [00:34:07] Hi I'm a big fan of your writing in your blog, Shawn, thank you. What I wanted to ask is related to in a situation where you're given a bit more responsibility as a senior, and you have to start making decisions, especially technical ones regarding the stack regarding specific things you need to accomplish for a client or a project.And how do you maybe are how do you not get stuck in that, in the, over analyzing the specific decision, not just to not make a mistake for your client or for your product, but also not bother your, or add overhead to your teammates as well and your colleagues in. To not to create issues later on, on a project, sometimes you get stuck in the decisions so much that you feel like you can move on. I dunno if there's something that all the time swyx: [00:34:57] Are you familiar with the concept of innovation tokens? And no, actually kind of her. Yeah. I think this camp I'm not sure where this idea came from, but people who'd go Google the source, but essentially the idea is to minimize risks but to allow some innovation, right?The tech stack that you work on work with for a client it should be something that you're mostly familiar with and you're confident that you can ship in time and on budget. But you allow yourself, to innovate or try new things in one or two areas of your tech stack, and that's your sort of innovation credit or innovation budget.And yeah, so to me, that's where you want to get to that may not necessarily be where you are right now. First job is to have a set of technologies, which are. Which the whole team is confident in, right? To me, I call this like a minimum spanning set of technologies that like, you can pretty much string together to accomplish any tasks.They may not be the best tool for the job. They might, wanna be the trendiest tool, but they do the job. And then you allow yourself in every project to try a new piece of technology that you want to include in your tech stack and try it out on a real project.So that's what comes to mind for now, I think obviously where I don't really understand why you're paralyzed. I think that there's something deeper there. Can you tell me more about the analysis paralysis or I forget what you call it, like the stalled decision.Questioner: Yeah, I guess it was not a, it's not just a specific situation I'm talking about. Maybe, Maybe does happen when you you were given more responsibility. I do not, you don't know how to approach it. It's not necessarily choosing a JavaScript framework, but making also bigger decision on on different elements of how the team is supposed to work together either technically or not. And sometimes it does happen. I don't have I don't want to go into very specific because there's multiple cases where it does happen. Maybe it's personal to me and just wanted to hear about maybe similar situation and how other people dealt with it. And you were, I mean, perfect example.swyx: [00:36:43] Yeah. If anyone has ideas let's cross source this as well. Cause I, I feel like I don't really it's so broad this question and it can go so many different ways. To me, it's something that you have to agree on it as a team. If you have a.I guess if you're in the position of leadership, then obviously you're in charge of proposing and helping, having to serve as a tie breaker. If you have a client, sometimes they have a very strong opinion and you can present them, twice HSB and then let them choose. These are all really nice ways to basically offload the decision.Ultimately I think a lot of things are a lot of decisions are reversible, right? If you think about type one and type two decisions which is a Jeff Bezos type of framework, I'm trying to understand if your decision is reversible or not. And if it is then just doesn't matter which one you try it out, just try it, try something out for a few weeks.And then if you don't, if it's not going the way you think it is, then you can go try the other thing. Ultimately the way I approach any sort of analysis paralysis now is this idea which I got from the sun newsletter called common cog. It's called action produces information, right? If you've done any, if you've done all your research, you've asked everyone and you're still stuck between two options or three options.Then no amount of further studying and worrying and hand-wringing is going to help you. You need to take action, whether it is commitment to one thing. And then you realize that no, actually everyone did the other thing. Or it is taking ticket for this step of running a small proof of concept or asking for more mentorship somewhere within your organization or just your, an external mentors.These are all like, you can even go as far as like paying someone for their advice, right? These are, this is a super, highly underrated thing in the company environments. Like people are available for hire, like max Storybird is available for hire. If you want any react to architecture advice, he's not cheap.But he's available. And so what other people so yeah, that's as much as I get, I can go I don't have much to work with on the question. Robert Haritonov: [00:38:35] That was very, very helpful actually. swyx: [00:38:37] From my perspective. So, thanks. Yeah. Thank you. It's given me something to think about as well, and hopefully I can write a better answer in the future. All right. We have a couple other questions and I have a few more minutes, so let's get this going. Pokey juice from Poland. I'm guessing. I'm inviting them. I'm going to drop by the way for those still in the room, I'm going to drop the chapter for junior engineer versus CD engineer.And we can have a better discussion there because I feel like I didn't really do enough prep for that. Hey pokey. Hello. So I would like to address the previous in person or in, at talk question, and because I had a very similar situation that I'm like slowly progressing to higher roles.And it sounds so overly stressful to decide yeah. And good to make the decisions. And the thing that helped me that, which I have recently found out is that unless you are in a company, which has two people and you are the most experienced one in that company, then there's always slept the bigger fish in the company, more experienced.And you can ask them for for help or you can ask older people who maybe are not to give them the seminar. But to have more expertise in certain fields, or they haven't been working with certain technology and you can ask them how we do work for them. Yeah. So I have no question.This one. No. That's great. Thank you for chiming in yeah, it's a challenging position to be in and that's why you've made more money. Hopefully they're paying you for all this stress that you're taking. Great. All right. I am, by the way, I'm extracting my junior to senior chapter so we can invite more questions.I see a lot of questions also piling up in the text chat and I will drop my PDF in there so people can talk more stuff. Okay. All right. So yeah, I've just posted that in the room. What else can I say about this? 40:30 Fall in Love with the Problem, Not the SolutionSomething I really want to emphasize, and I've been really trying to find the best words for this which is essentially that we should. Fall in love with the problem rather than the solution.And I think that's juniors may be defined, maybe falling over themselves to define themselves by the solution, right? Like I'm a react developer. Whereas seniors have probably been through a few of these cycles where like they've had, they've been super into something else before, and then they had to change frameworks and get changed frameworks again.And by the time you get to your second or third framework, you're just like, all right, this is another tool to solve the same problem. And ultimately the thing that lasts longer than the solution itself is the problem, because that will never go away. It will. It w it will just have different solutions that come along and with, and solve it with different trade-offs.So I hope that's a message that I want to get across that seniors. Basically collect patterns and problems and juniors collect solutions. And I want to guide people towards understanding problems deeply. And that's a lot of the way that, that the way that I structured my thinking and learning and speaking as well.So the talk that I'm going to give later in about 30 minutes is focused on what problems does react solve, and what can we learn that will outlast react? I think that's, that's one way to go from junior to senior. Okay. I don't see any other questions I do have okay. Robert Haritonov: [00:41:55] All right.I just want more,even the act of discussion I'll be full if there's a topic. Thank you so much for everyone. Who's come by. Thanks. Yep. Hey Darren. Hello. 42:00 Can you still be a fullstack engineer?Questioner: Hey, how are you doing? I just asked the question in the discussion, but I thought maybe you could ask her near him suggested that. So myself, I'm a full stack engineer, but.And the more I look at these big companies. Now you see all the postings are from our backend or our front end and not really CFO's stacks. I was just wondering your opinion on maybe focusing on one of those things that you're more well versed in, or is it still that it's supposed to engineer still an achievable thing to work towards these days?swyx: Wow. Ah, great question. There are definitely people hiring full stack developers. You just got to find them. I don't know where you're getting this impression that people aren't hiring full stack. I feel like they're, it's actually a lot, it's a meme in the U S where they, once someone to do everything.I would say, yeah, I'd say it's definitely achievable. I just think it's not as realistic at some level of scale because ultimately there's, this is meme where it's like this. Horse where either your joint you're during the front end really well. And then the back end is like a really crappy children's drawing or are you drawing the back really well in the front is just like this really really childish imitation version.There's some trade-off to be made. And ideally there's some level of specialization that you have where you can actually, market your skills in in, in a good way to and it probably involves specialization as well is what I'm trying to say. So full-stack is great for people who want generalists.And if you want to, for example, be a startup founder or an indie hacker yourself that's definitely something to pursue and to be well rounded. But if you want to be a specialist, a consultant an industry authority, you probably should specialize. And those two are not at odds, but you probably want to market yourself in some, in based on what you're trying to tell to your clients and your employers right now.Great. Thank you very much. Yeah, I've heard the thoughts on like specialization versus generalization. There's a separate chapter of mine but essentially the TLDR is that everyone is a generalist in some way. And when in doubt, you should be specializing because that's where you learn how to be an expert and learning to be an expert and crossing that sort of learning gap in itself is a skill.And then also marketing it's way easier to market yourself. So I have a friend who's called, who is Cory house. He's a reacts consultant. He specializes in transitioning big companies mostly from angular to react. But that's not his only interest. He's got a lot of other interests and he actually is a pretty full stack developer just based on a history, but he chooses to market himself as a reactive Oliver.And he, and when he did that, his consulting practice 15 in one year, And in terms of inbound inquiries, you can go look up his his tweet channel he'll he'll back that up. And that's just because marketing a response to niches, it's like a specialization. If you see any expert in something people believe in more rather than I can do anything.Forget. Thanks very much for that. Yeah. Great questions everyone. I see a lot more in in the chat and I have to go through and answer them. But hopefully this is useful and this is fine. I had no idea what to expect a new media. Thanks all Shawn for drink. Hopefully we'll be able to replace it Robert Haritonov: [00:45:11] again.Yeah, the topic is really, really in demand. You had a really solid conference level audience and just this small room for joining these for all your insights. swyx: [00:45:20] So yeah, Robert Haritonov: [00:45:21] hopefully you'll be able to reply there. Any questions and shout whenever you have time. swyx: [00:45:27] 30 minutes. I'm excited.It's is yeah, I love the sock. All right. Thanks for having me, Robert. And thanks everyone for coming. Bye. See you soon. Robert Haritonov: [00:45:34] Cheers. swyx: [00:45:35] Bye.
Gergely Orosz (ex-Uber, Skyscanner) is an engineering manager, blogger and author. In this podcast episode, we talk about tech recruitment, career progression, managing teams and his book “The tech resume, inside out”. His book is full of actionable advice on how to write a good tech resume for developer or manager positions. Hope you enjoy! Links to Gergely's profile: https://www.linkedin.com/in/gergelyorosz/ https://blog.pragmaticengineer.com/ https://thetechresume.com/ https://www.engguidebook.com/ --- Send in a voice message: https://anchor.fm/coffeewitharecruiter/message
© 2020-2025 Ivy Podcast Discovery LLC
