Podcasts about staff engineer

### 関連書籍等- 「Staff Engineer: Leadership beyond the management track」 - [https://amzn.to/3CGI7hd](https://t.co/2wTT0FyOgb) - 邦題「Staff Engineer - 管理職にならずに活躍しつづける最強のソフトウェアエンジニアへ!」- An Elegant Puzzle: Systems of Engineering Management https://amzn.to/4ly22Fv - **エレガントパズル　エンジニアのマネジメントという難問にあなたはどう立ち向かうのか** https://amzn.to/3YFcn8N - See also: The Staff Engineer's Path by [Tanya Reilly](https://www.linkedin.com/in/tanyareilly/)- Ryoichiの2021 読了メモ: https://x.com/ryo1kato/status/1425629458929643523### 関連エピソード- ep3. Thriving on the Technical Leadership Path- ep10. What distinguishes a great software engineer from a good one?- ep64. 技術チームのリーダーが優れた技術者であるべき理由感想をぜひハッシュタグ #todayILearnedFM #tilfm でつぶやいてください!Your co-hosts:- Tomoaki Imai, Noxx CTO https://twitter.com/tomoaki_imai- Ryoichi Kato, Software Engineer https://twitter.com/ryo1kato

Co to znaczy, że organizacja jest efektywna? Czy KPIe to wszystko? Co mierzyć? Jak mierzyć? Kiedy wiemy, że efektywność spada. Tyle pytań... odpowiedzi staraliśmy się dostarczyć w ramach spotkania CTO Morning Coffee #73. W nowej odsłonie, ale z tą samą załogą i merytoryką.!

Tomek, Wojtek i Sebastian o nowościach AI i tech! W odcinku: inwestycje AI w Zatoce Perskiej kontra Europa, nowe modele Claude 4 od Anthropic i Gemini 2.5 Pro (plus Veo) od Google. Omawiają też strategię Airbnb "Services & Experiences", głośny upadek Builder.ai oskarżonego o przekręty oraz problemy Mety z modelem Llama.W tym odcinku między innymi:

In this special episode of Liquid Weekly, Karl and Taylor sit down with Brett, Staff Engineer at Shopify, to unveil an exciting new project: Storefront Web Components.This groundbreaking initiative aims to make Shopify integration accessible to anyone with basic HTML knowledge, allowing merchants to embed commerce functionality anywhere on the web.Episode Highlights:Introduction to Storefront Components and their visionDeep dive into component architecture and implementationHow to handle variants, cart functionality, and market-specific featuresDiscussion of development process at ShopifyComparison with existing solutions like Buy Button SDKFuture roadmap and potential use casesFind Brett OnlineTwitter(X): https://x.com/little_bretLinkedIn: https://www.linkedin.com/in/bretlittle/ Website: https://www.bretlittle.com/ Github: https://github.com/blittle Bluesky: https://bsky.app/profile/bretlittle.comInstagram: https://www.instagram.com/bret.little/ Timestamps:00:00 - Introduction05:30 - What are Storefront Components?15:45 - Technical Implementation Details30:20 - Component Demo45:10 - Development Process at Shopify52:30 - Future Plans57:00 - Picks of the WeekResources:Storefront Web Components: https://webcomponents.shopify.devPlayground: https://webcomponents.shopify.dev/playgroundShopify Editions Summer ‘25: https://www.shopify.com/editions/summer2025Blog post: https://www.shopify.com/news/summer-25-edition-devShopify Headless Documentation: https://shopify.dev/docs/storefronts/headless Web Components Documentation: https://developer.mozilla.org/en-US/docs/Web/API/Web_components Picks of the Week:Brett: Microsoft TypeScript Go Announcement & AI Assistant ArticleKarl: Ben McIntyre's SAS History BooksTaylor: Naked Nutrition Protein PowderSign Up for Liquid Weekly:Don't miss out on expert insights and tips—subscribe to Liquid Weekly for more content like this: https://liquidweekly.com/

Brew #43: Epic vs Apple: 4 Lata Walki. Stripe Platformą Finansową. Worldcoin Wchodzi do USA. Elon.Wróciliśmy! Cisza wyborcza skończona, a my wpadamy z nowym odcinkiem Brew!W tym odcinku:

As a leader that wants to optimize an organization you are bound to fail if you isolate social (culture and people) and technical (tools and process) changes. When we ask Lesley Cordero, Staff Engineer at The New York Times how to solve this dilemma she answers: "Platform Engineering, it can drive organizational sustainability by practicing sociotechnical principles that provide a community driven support system for application developers using our standardized shared platform architecture"Tune in to our latest episode and learn more about the importance of leadership to continuously keep up and balance the tension between "Developers" and "Operations", between "End User Experience" and "Developer Experience" and ultimately between "Culture and People and "Tools and Processes"Links we discussedLesley's LinkedIn: https://www.linkedin.com/in/lesleycordero/GOTO Conference Talk => https://www.youtube.com/watch?v=Jx-XrUONJ-o QCon 2025 Talk Details: https://qconlondon.com/presentation/apr2025/platform-engineering-practice-sociotechnical-excellence DevOpsCon 2024 Talk Details: https://devopscon.io/business-company-culture/platform-engineering-devops/

In this episode of Change Leader Insights, Jessica Crow speaks with Abhijit Patharkar, an entrepreneur and academic, about how artificial intelligence (AI)—a transformational change impacting businesses worldwide—impacts organizational culture and data governance. A serial entrepreneur and Columbia University alum, Abhijit grew up immersed in his family's retail business, giving him an intimate understanding of the industry's challenges. With an engineering background and a Staff Engineer role at VMware's Office of the CTO, he developed a deep love for solving complex problems using technology. Abhijit has set out to bridge the gap between traditional retail and cutting-edge AI-powered solutions. During the conversation, Jessica and Abhijit discussed data governance and AI to understand whether an organization is prepared to undergo the business transformation and changes associated with implementing AI. Abhijit explained that data governance is a critical factor for AI-readiness. In describing how to prepare from a governance perspective, ”Governance is based on three pillars. One is data quality, one is security, and the third is availability.” Highlights from the conversation include: ☑️ Understanding the importance of a unified data approach when leveraging AI for tools to be most useful for employees ☑️ The gap in data governance across organizations and how to address it to better prepare an organization for technological transformation ☑️ Practical steps for change management in AI adoption If you want to learn more about AI and organizational culture change, be sure to tune in and hear what Abhijit has to say!

Jak powszechnie wiadomo, "42" jest odpowiedzią na wielkie pytanie o życie, wszechświat i całą resztę.A w 42. odcinku Brew poruszamy między innymi:

Today's guest is AJ Stuyvenberg, a Staff Engineer at Datadog working on their Serverless observability project. He had a great article recently about how they rewrote their AWS Lambda extension in Rust. It's a really interesting look at a big, hard project, from thinking about when it's a good idea to do a rewrite to talking about their focus on performance and reliability above all else and what he thinks about the Rust ecosystem. Beyond that, AJ is just a learning machine, so I got his thoughts on all kinds of software development topics, from underrated AWS services and our favorite databases to the AWS Free Tier and the annoyances of a new AWS account. Finally, AJ dishes out some career advice for curious, ambitious developers.

W 41. odcinku Brew zagłębiamy się w najgorętsze tematy ze świata technologii! Zbliżamy się do 1000 subskrybentów - podrzućcie w komentarzach swoje pomysły, jak powinniśmy to uczcić! Jeden z nas nadaje z alpejskich warunków polowych, ale nie zwalniamy tempa!

W najnowszym odcinku podcastu Brew zanurzamy się w świat technologii, AI, inwestycji oraz globalnych trendów.

W marcu jak w garncu!

Career progression in IT can feel a bit unclear at times. Start as a Helpdesk, get to be a CPE, what happens next? How does development actually work? What do most organizations do to tier their people? How do you move up as an individual contributor? We're talking with Graham Gilbert of Airbnb about what it's like to move up toward the rarified air of staff engineer and beyond. Hosts: Tom Bridge - @tbridge@theinternet.social Marcus Ransom - @marcusransom Guests: Graham Gilbert - LinkedIn Links: Eisenhower Matrix: https://asana.com/resources/eisenhower-matrix Sponsors: Kandji 1Password iMazing Smallstep Watchman Monitoring If you're interested in sponsoring the Mac Admins Podcast, please email podcast@macadmins.org for more information. Get the latest about the Mac Admins Podcast, follow us on Twitter! We're @MacAdmPodcast! The Mac Admins Podcast has launched a Patreon Campaign! Our named patrons this month include Weldon Dodd, Damien Barrett, Justin Holt, Chad Swarthout, William Smith, Stephen Weinstein, Seb Nash, Dan McLaughlin, Joe Sfarra, Nate Cinal, Jon Brown, Dan Barker, Tim Perfitt, Ashley MacKinlay, Tobias Linder Philippe Daoust, AJ Potrebka, Adam Burg, & Hamlin Krewson  

🎙️ Gabriel Benmergui forjado una trayectoria impresionante como Founder de Silver.dev, destacándose como un visionario y líder innovador en el sector de reclutamiento tecnológico. 👨‍💻 Con una sólida experiencia como Staff Engineer y líder técnico en empresas como OpenSea y Robinhood, Gabriel ha trazado un camino ascendente enfocándose en conectar el talento competitivo de Latinoamérica con startups estadounidenses. 🚀 Bajo su liderazgo, Silver.dev se ha convertido en una agencia de talento pionera que eleva el estándar de calidad, proporcionando a las startups de productos ingenieros de alto nivel y preparados para un nuevo desafío. Deja like, comenta y suscríbete a nuestras redes sociales a través de Opground, el primer reclutador virtual, para estar al día de todas las novedades de DISCOVERING TECH STORIES. Web: https://opground.com YouTube: https://www.youtube.com/playlist?list=PLZh3dyTwySvHI1e6PBNLfitJXJIQ60k4q Spotify: https://open.spotify.com/show/0sXMqFKJDxJu5XDn2NeH0B?si=kG3aYbA-QzamOmkVqx7T0Q&nd=1 Apple Podcast: https://podcasts.apple.com/es/podcast/discovering-tech-stories/id1557637563?l=es #discoveringtechstories #opground #developers #entrevista

Czy Jack Dorsey to Satoshi Nakamoto? Czy vibe coding to przyszłość programowania? Dlaczego OpenAI zmienia strategię, a Google chce "deregulować" AI w Polsce? W tym odcinku rozmawiamy o najnowszych technologiach, miliardowych inwestycjach w AI i absurdach świata big techuJuż jest, kolejny odcinek Brew, w którym rozmawiamy między innymi o:✅ Jack Dorsey i Goose – Nowy open-source'owy framework agentowy. Czy Polacy nie gęsi i swoje AI mają?✅ Miliardy na AI – Francja, Emiraty i USA sypią pieniędzmi na rozwój sztucznej inteligencji. Kto wygra ten wyścig?✅ Vibe coding – Programowanie na luzie. Mówisz, nie piszesz, a kod sam się generuje. To przyszłość czy ślepa uliczka?✅ Deep Research od OpenAI – Czy AI przejmie rynek analiz i raportów? Jak wygląda walka OpenAI z Perplexity?✅ Google i Polska – „Strategiczne partnerstwo” z Sandarem Pichaiem. Co realnie oznacza ta inwestycja?✅ GPT-5 i nowa strategia OpenAI – OpenAI zmienia plan na przyszłość. Czy numerowanie modeli to już przeszłość?✅ AI w edukacji – Duolingo i ich kulturowy handbook. Co warto z niego wyciągnąć?✅ Czy Microsoft przegrał AI? – Nikt nie mówi o Copilotach. Czy to znak, że Microsoft przespał rewolucję?Do tego oczywiście hot takes, rekomendacje, szybkie wrzutki i rekord zimna w Polsce

In this episode, Dave and Jamison answer these questions: A listener named Steven says, Long-time listener of the podcast here—it always brings me so much joy! Should I prioritize title over salary? I'm currently based in Europe, working as a Senior Engineer at a big company that pays really well. The problem is, there's almost no chance for promotion due to the economy and budget constraints. Plus, because of the organizational structure, I'm stuck solving small problems that don't have a big impact. It's frustrating—but again, the pay is great. Recently, I got an offer for a Staff Engineer position at another company. The catch is, the pay isn't as good (30%+ cut), and I'm not sure about their culture or structure yet. However, the title could potentially open more doors for me in the future. Should I take the offer, accept the pay cut, and hope it's a step forward for my career? Hello! Long time listener, first-time caller :-) I'm on the final stretch of classes to finish my BS in computer science at WGU, most of which I've done while working. I'm now 40, and I have had 3 previous occupations and employers: aircraft mechanic for 5 years at a small shop, figure skater with Disney on Ice for 6 years, and most recently a partner at an environmental remediation/heavy construction firm for 10 years where my primary responsibilities were field crew management and technical writing for ecology reports. I would love your advice on how I could use these experiences to stand out on a resume or in a job interview. How can I indicate that I'm a hard worker and that I know just enough to know that I know nothing and am ready to learn? Thank you for your time, keep up the good work!

Bielik! Każdy o nim słyszał, niektórzy go nawet widzieli. Polacy nie gęsi i mają swoje AI. Ale skąd? Po co? Czy nie wystarczy nam ChatGPT, Anthropic, Mistral i DeepSeek?  Czy my potrafimy zrobić LLMa? ‼️ WAŻNE‼️ Zespół pracujący na Bielikiem, uruchomił Patronite - wsprzyjcie ich, bo robia to dla mnie, dla Ciebie i dla wszystkich innych jako społeczność -  https://patronite.pl/speakleashOkazało się, że jest grupa ludzi, która uważa, że potrzebujemy takiego modelu i go stworzyła. Co ciekawsze, nie jako rządowy projekt czy zryw narodowy ale jako projekt społecznościowy. Czym jest Bielik? Jak powstał i skąd wziął się pomysł? Czy wymagał setek tysięcy GPU a jeżeli tak to skąd się one wzieły? O tym wszystkim i również o tym, że najważniejsze to jest "zrobić" a nie "mówić, że się zrobi" rozmawiamy w Grind z Sebastianem Kondrackim.

De développeur à architecte d'entreprise, comment naviguer dans la complexité croissante des organisations tech ?Simon Maurin, ancien Staff Engineer chez Leboncoin et aujourd'hui cofondateur et CTO de next-level.run(), partage son expérience sur l'évolution des rôles techniques et l'importance d'une approche sociotechnique dans le développement logiciel.Dans cet épisode, je discute avec Simon de :➡️ La transition d'IC (Individual Contributor) vers des rôles stratégiques ➡️ L'importance de la culture générative et de l'apprentissage continu ➡️ Les défis de la gestion de la complexité dans les grandes organisations ➡️ Le dépassement des étiquettes techniques traditionnelles.Ressources mentionnées :

Après 3 ans sans coder, cette tech s'est lancée à corps perdu dans l'open-source. Et à peine 1 an plus tard, elle en vit à 100%.

W ostatnich tygodniach chiński smok wstrząsnął OpenAI, NVidia i innymi... ale my nie tylko o tym. Znaczy o tym też, ale oprócz tego w nowym Brew rozmawiamy o inwestycji w ElevenLabs (oklaski), innych niż DeepSeek konkurentach z Chin dla firm w branyż AI, inwestycjach InPost w UK, projekcie Stargate Chcesz być na bieżąco w tym co ważne w Tech?!? My Ci to ułatwiamy i podajemy wszystko lekko, strawnie i przyjemnie 

Jeżeli jeszcze nie subskrybujesz naszego kanały

Ready to take your tech career to the cloud and build those awe-inspiring systems you see? Then you're in the right place. This episode of AWS Bites is your blueprint for becoming a successful cloud architect. We're not just going to talk about it; we'll show you what worked for us, sharing the critical skills you need, and a practical path to build your expertise. Whether you're a beginner or looking to take the next step, join us as we equip you with the knowledge and tools to make your mark as a cloud architect! In this episode, we mentioned the following resources: Google Cloud Architecture Definition: https://cloud.google.com/learn/what-is-cloud-architecture Market data about the Cloud Professional Services market: https://www.gminsights.com/industry-analysis/cloud-professional-services-market EP 91 - Our Journeys into Software and AWS: https://awsbites.com/91-our-journeys-into-software-and-aws/ AWS Well-Architected Framework: https://aws.amazon.com/architecture/well-architected/ EP 68 - Are you well architected?: https://awsbites.com/68-are-you-well-architected/ Cloud Design Patterns: https://learn.microsoft.com/en-us/azure/architecture/patterns/ The art of scalability (book): https://www.amazon.com/Art-Scalability-Architecture-Organizations-Enterprise/dp/0134032802 Enterprise integration patterns (book): https://www.amazon.com/Enterprise-Integration-Patterns-Designing-Deploying/dp/0321200683/ Designing Data-Intensive Applications (book): https://www.amazon.com/Designing-Data-Intensive-Applications-Reliable-Maintainable/dp/1449373321 AWS Networking Essentials (free guide): https://aws.amazon.com/getting-started/aws-networking-essentials/ Docker Curriculum (free): https://docker-curriculum.com/ How Linux works (book): https://www.amazon.com/How-Linux-Works-Brian-Ward/dp/1718500408/ Exercism coding challenges: https://exercism.org/ The tangled web (book): https://www.amazon.co.uk/Tangled-Web-Securing-Modern-Applications/dp/1593273886 Low Level YouTube Channel: https://www.youtube.com/lowlevellearning AWS - Best Practices for Security, Identity, & Compliance: https://aws.amazon.com/architecture/security-identity-compliance/ Supercommunicators (book): https://www.amazon.com/Supercommunicators-Unlock-Secret-Language-Connection/dp/0593862066/ An Elegant Puzzle (book): https://www.amazon.com/Elegant-Puzzle-Systems-Engineering-Management/dp/1732265186/ Staff Engineer (book): https://www.amazon.com/Staff-Engineer-Leadership-beyond-management/dp/1736417916/ EP 58 - What can kitties teach us about AWS: https://awsbites.com/58-what-can-kitties-teach-us-about-aws/ AWS User Groups: https://aws.amazon.com/developer/community/usergroups/ Do you have any AWS questions you would like us to address? Leave a comment here or connect with us on X/Twitter: - ⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠https://twitter.com/eoins⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠ - ⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠https://twitter.com/loige⁠⁠⁠⁠

W USA rozwiązał się worek z funduszami i zaczęły latać milardy waluacji? Kto, ile i dlaczego (naszym zdaniem) zgarnął w światecznych "prezentach". Czy Perplexity może pokonać Google? Czy Cursor skończył się na AI czy jeszcze powalczy? Ile kart może kupić Elon Musk za ostatnią rundę finansowania xAI. Czy DataBricks nazbiera dostatecznie dużo $$$, żeby zbudować mur przed AIl?! To wszystko... w Brew! 

$90 MLD stracone w firmach przez duchy? I to nawet nie obcych tylko duchy developerów?  Jak to możliwe!!!! Google wstaje z kolan i jednym modelem powala SORA na kolana, SORA się gubi i kroi pomidory w sposób... jakiego byście nie oczekiwali od AI. Czy zgłosiłeś już swojego "buga" dla Europy?  A co ogłosiło OpenAI w ciągu swojego adwentu? TAK, TAK, TAK - o tym wszystkim i kilku innych rzeczach posłuchasz w nowym "BREW", które właśnie masz przed sobą. Jeżeli jeszcze nie subskrybujesz naszego kanału

No episódio 157 do KUBICAST, mergulhamos fundo no tema gerenciamento de recursos no Kubernetes. Este episódio explora práticas para otimizar custos, escalabilidade e desempenho em ambientes dinâmicos. Com a participação especial de Lucas Duarte, arquiteto de soluções da Amazon e Rafael Brito, Staff Engineer na StormForge, o episódio é um guia essencial para quem busca dominar os desafios de ambientes Kubernetes e implementar estratégias eficazes de gestão de recursos.Destaques do EpisódioIntrodução ao Gerenciamento de RecursosA importância de resolver limites de requisições para evitar problemas de produção.Estratégias para equilibrar custo e confiabilidade.Desafios de Microserviços em EscalaComo implementar um rollout gradual e ajustar métricas para garantir performance.A necessidade de um design eficiente em microserviços, garantindo que cada serviço realize sua tarefa de forma eficaz.Escalonamento no KubernetesExplicação detalhada sobre HPA (Horizontal Pod Autoscaler) e o papel do Scheduler.Estratégias para garantir resiliência e evitar gargalos.Eficiência com KarpenterComparações com outras ferramentas de escalonamento, mostrando como o Karpenter reduz custos e acelera upgrades.Dicas para provedores de nuvem maximizarem a eficiência utilizando essa solução.Visibilidade e Gestão em Ambientes DinâmicosA necessidade de métricas precisas para gerenciar o consumo de recursos.A importância de um alinhamento claro entre equipes para lidar com mudanças frequentes.Alguns links importantes que citamos no episódio:Demo Stormforge: https://www.youtube.com/watch?v=RbOg0aZyQTw&ab_channel=StormForgeDemystifying Kubernetes Resource Management: https://youtu.be/T-LF_0uwFIg?si=mcj30jhgxvPm5y3J The New Stack: https://thenewstack.io/neglect-kubernetes-resource-management-at-your-peril/ Se você trabalha com Kubernetes, sabe que gerenciar recursos de forma eficiente é fundamental para evitar desperdícios e garantir que sua infraestrutura seja escalável e resiliente. Este episódio aborda tanto a teoria quanto a prática, com exemplos reais e ferramentas que podem ser implementadas hoje mesmo no seu ambiente.Ouça em sua plataforma de áudio preferida e no Spotify também! Até a próxima!O Kubicast é uma produção da Getup, empresa especialista em Kubernetes e projetos open source para Kubernetes. Os episódios do podcast estão nas principais plataformas de áudio digital e no YouTube.com/@getupcloud.

Stan TECH w Europie - co wynika z raportu i co warto wiedzieć, plus oczywiście nasze komentarze do tego raportu. Kto z branży TECH  się wprowadza do Warszawy? Jak odpalić swojego emem coina i czy to napewno dobry pomysł, a co mogło i poszło źle? Oprócz tego rundy, przemyślenia, narzędzia, gwałtowny wzrost BlueSky, nowości od Kagi i Perplexity ... and so much more. Czyli BREW wjechało na pełnej petardzie! Zapraszamy ========================================================"Brew" jest częścią projekty "CTO Morning Coffee". Najlepsze miejsce w polskim Internecie dla liderów w technologii

No episódio de hoje, exploramos o mundo da arquitetura de software e seu impacto nas finanças das empresas. Com a presença especial de um Staff Engineer experiente, vamos entender o que faz uma arquitetura ser eficiente e como decisões arquiteturais afetam diretamente os custos operacionais, desde a escolha de cloud providers até o uso de microservices. Além disso, falamos sobre FinOps e como essa prática pode ajudar a otimizar custos em ambientes de nuvem. Descubra as melhores estratégias para evitar armadilhas financeiras e como o futuro da arquitetura e a IA estão transformando o cenário! Edição completa por Rádiofobia Podcast e Multimídia: ⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠https://radiofobia.com.br/⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠ --- Nos siga no Twitter e no Instagram: @luizalabs @cabecadelab Dúvidas, cabeçadas e sugestões, mande e-mail para o ⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠cabecadelab@luizalabs.com⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠ ou uma DM no Instagram Participantes: YOHAN RODRIGUES | https://www.linkedin.com/in/yohan-rodrigues/ CASSIO BOTARO | https://br.linkedin.com/in/cassiobotarohttps://github.com/cassiobotarohttps://www.instagram.com/cassiobotaro/ Links úteis: https://www.amazon.com.br/Fundamentos-Arquitetura-Software-Abordagem-Engenharia/dp/8550819859 https://www.amazon.com.br/Arquitetura-Software-Trade-off-Arquiteturas-Distribu%C3%ADdas/dp/8550819840 https://www.amazon.com.br/Cloud-FinOps-Edi%C3%A7%C3%A3o-decis%C3%B5es-colaborativas/dp/8575228978 https://www.amazon.com.br/Cost-Effective-Data-Pipelines/dp/1492098647 https://www.finops.org

Send us a textThis is a continuation in our ongoing series about How to Accelerate the Speed of Engineering. The discussion covers topics such as the importance of planning and execution, balancing problem-solving and asking for help, the role of checklists, the impact of leadership and team culture, effective communication and collaboration, risk management and building relationships, and lessons learned from past challenges.Main Topics:The balance between speeding up projects and avoiding unforced errorsThe use of tools like Notion and Loom to improve productivity and efficiencyThe role of leadership in building a strong team cultureApproaches to risk management and the value of building relationshipsLessons learned from implementing new processes and toolsAbout the guest: Brad Hirayama is an experienced engineer and program manager specializing in medical devices, with a focus on new product development (NPD), biomedical devices, and process validation. Currently a Staff Engineer, he drives innovation in electrophysiology (EP) products. Brad's background includes roles at Abbott and NuVera Medical, where he contributed to the development of catheters and other vascular technologies. He has expertise in design thinking, FDA compliance, and leadership, all while embodying a passion for connecting people and technologies in impactful ways.Links:Brad Hirayama - LinkedInAbout Being An Engineer The Being An Engineer podcast is a repository for industry knowledge and a tool through which engineers learn about and connect with relevant companies, technologies, people resources, and opportunities. We feature successful mechanical engineers and interview engineers who are passionate about their work and who made a great impact on the engineering community. The Being An Engineer podcast is brought to you by Pipeline Design & Engineering. Pipeline partners with medical & other device engineering teams who need turnkey equipment such as cycle test machines, custom test fixtures, automation equipment, assembly jigs, inspection stations and more. You can find us on the web at www.teampipeline.us

On this episode, I'm joined by Joel Hawksley, Staff Engineer at GitHub for a discussion of code ownership with regards to a 3-year WCAG (Web Content Accessibility Guidelines) project at GitHub, benevolent dictatorship, collective ownability, terrible code vs acceptable code vs the viability of a project, writing good code vs solving problems, defining quality code, quality code resulting from clear conceptualization, the desirability (or not!) of perfect adherence to standards, reducing defect rate, and meaningful testing goals. Code Complete by Steve McConnellJoel Hawksley at GitHubJoel Hawksley at TwitterHawksley.orgEpisode 88 - ViewComponent with Joel HawksleyLive From Ruby Conf 2021, Joel Hawksley Tells Me About His DrinkEpisode 130 - ViewComponent with Joel Hawksley

This interview was recorded for the GOTO Book Club.http://gotopia.tech/bookclubRead the full transcription of the interview hereNick Tune - Author of "Architecture Modernization" & Staff Engineer at PayFitEduardo da Sliva - Independent Consultant on Socio-technical Systems, Architecture & Leadership ModernizationRESOURCESNickhttps://hachyderm.io/@nick_tunehttps://www.linkedin.com/in/nick-tunehttps://nick-tune.mehttps://medium.com/nick-tune-tech-strategy-blogEduardohttps://x.com/emgsilvahttps://mastodon.social/@eduardodasilvahttps://www.linkedin.com/in/emgsilvahttps://github.com/emgsilvahttps://esilva.nethttps://esilva.net/ametDESCRIPTIONEduardo da Silva interviews Nick Tune about his book "Architecture Modernization." Nick Tune shares his motivations for writing the book, emphasizing the socio-technical alignment of software, strategy, and structure. They discuss the importance of business objectives, the role of Architecture Modernization Enabling Teams (AMET), and practical steps to initiate and sustain modernization efforts. Nick Tune also highlights the continuous nature of modernization and the need for organizations to adapt and learn over time.The conversation provides valuable tips for effectively approaching architecture modernization and ensuring long-term success.RECOMMENDED BOOKSNick Tune & Jean-Georges Perrin • Architecture ModernizationScott Millett & Nick Tune • Patterns, Principles, and Practices of DDDMatthew Skelton & Manuel Pais • Team TopologiesFord, Richards, Sadalage & Dehghani • Software Architecture: The Hard PartsSimon Brown • Software Architecture for Developers Vol. 2Woods, Erder & Pureur • Continuous Architecture in PracticeTwitterInstagramLinkedInFacebookLooking 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!

“The three core expectations of a Staff+ engineer are having a high blast radius impact, able to do multi-scale planning & influence, and having high ownership & autonomy level.” What does it take to become a Staff+ engineer? Thiago Ghisi, an experienced engineering leader and a Director of Engineering at Nubank, reveals the secrets in this episode. We discuss the path to becoming a Staff+ engineer and explore the attributes that set successful Staff+ engineers apart. Thiago emphasizes that technical skills alone are not enough and outlines the three core expectations and three key behaviors for Staff+ engineers to demonstrate. Our conversation concludes with a discussion of the importance of finding role models and learning from their behaviors and approaches rather than following checklists. If you're an aspiring Staff+ engineer or simply interested in career growth in tech, don't miss this episode! Tune in now to unlock the secrets to Staff+ success.   Listen out for: Career Journey - [00:02:11] Definition of a Staff+ Engineer - [00:04:24] The Different Level & Scope of Responsibilities - [00:09:43] What You Got Here Won't Get You There - [00:18:54] High Blast Radius Impact - [00:23:34] Multi-Scale Planning & Influence - [00:27:23] Stakeholder Management - [00:31:06] Ownership & Autonomy Level - [00:35:52] Behaviors & Patterns - [00:43:51] Role Models Over Checklists - [00:51:53] 3 Tech Lead Wisdom - [00:55:56] _____ Thiago Ghisi's BioThiago Ghisi is the Director of Engineering for the Mobile Platform team at Nubank. He has nearly 20 years of experience in the software industry, having worked at companies like Apple, ThoughtWorks, and Amex. Ghisi has worn multiple hats - from Programmer to Project Manager to Quality Engineer, back to Engineering, and finally, Engineering Management, where he has been leading cross-functional teams in the Mobile FinTech space for the past eight years. He also hosts a podcast called “Engineering Advice You Didn't Ask For” and writes extensively about Career & Leadership in Tech on LinkedIn & Twitter. Follow Thiago: LinkedIn – linkedin.com/in/thiagoghisi Twitter – @thiagoghisi _____ Our Sponsors Enjoy an exceptional developer experience with JetBrains. Whatever programming language and technology you use, JetBrains IDEs provide the tools you need to go beyond simple code editing and excel as a developer.Check out FREE coding software options and special offers on jetbrains.com/store/#discounts.Make it happen. With code. Manning Publications is a premier publisher of technical books on computer and software development topics for both experienced developers and new learners alike. Manning prides itself on being independently owned and operated, and for paving the way for innovative initiatives, such as early access book content and protection-free PDF formats that are now industry standard.Get a 40% discount for Tech Lead Journal listeners by using the code techlead24 for all products in all formats. Like this episode?Show notes & transcript: techleadjournal.dev/episodes/190.Follow @techleadjournal on LinkedIn, Twitter, and Instagram.Buy me a coffee or become a patron.

In this episode of the Maintainable Software Podcast, Robby is joined by Noel Rappin, Staff Engineer at Chime Financial, and the mind behind the latest edition of the classic Programming Ruby book, affectionately known as the "Pickaxe." Noel delves into the intricate process of modernizing a legacy technical book and the lessons learned along the way.Episode Highlights[00:05:32] A Legacy Revisited: Noel Rappin reflects on the process of updating the Programming Ruby book, navigating the balance between preserving its legacy and making it relevant for today's Ruby community.[00:10:17] The Challenges of Modernizing: Noel discusses the complexities of working on a legacy book, including maintaining a consistent tone, updating technical content, and making strategic decisions about what to include or omit.[00:16:12] Parallels with Legacy Code: Noel shares his insights on the similarities between updating a legacy book and maintaining legacy software, emphasizing the importance of understanding past decisions before making changes.[00:21:00] Curating Ruby's Evolution: How Noel approached the task of deciding which Ruby features and practices to highlight in the new edition, considering the evolution of the Ruby community since the book's last update.[00:27:00] The Ruby Ecosystem as a Legacy System: Exploring the idea that the entire Ruby ecosystem can be seen as a legacy system, shaped by past decisions and community standards.[00:33:47] Advice for Aspiring Technical Authors: Noel offers practical tips for those interested in contributing to or updating legacy technical books, including how to pitch ideas to publishers and navigate the challenges of working on established projects.[00:40:00] Maintaining Relevance: Strategies for keeping both software and technical books up-to-date, including Noel's thoughts on the importance of documentation and regular updates.Key TakeawaysUpdating a legacy technical book requires a deep understanding of the community's current needs and the ability to balance respect for the original work with the necessity of modern relevance.The process of modernizing a book like Programming Ruby shares many similarities with maintaining legacy software, including the importance of understanding past decisions and the challenges of working with outdated practices.Community standards play a crucial role in both software maintenance and technical writing, guiding the evolution of both fields.Noel emphasizes the importance of documentation in legacy projects, whether in software or publishing, as a tool for preserving context and aiding future contributors.Resources MentionedProgramming Ruby 3.3 (5th Edition) - The latest "Pickaxe" book, authored by Noel Rappin. Use promo code maintainablefm2024 to get 35% off the ebook.Chime FinancialMurderbot Diaries by Martha WellsWayfarers series by Becky ChambersRubular - Ruby Regular Expression EditorNoel Rappin's WebsiteNoel Rappin on LinkedInNoel Rappin on TwitterFor more episodes like this, be sure to subscribe to the Maintainable Software Podcast.Thanks to Our Sponsor!Turn hours of debugging into just minutes! AppSignal is a performance monitoring and error-tracking tool designed for Ruby, Elixir, Python, Node.js, Javascript, and other frameworks.It offers six powerful features with one simple interface, providing developers with real-time insights into the performance and health of web applications.Keep your coding cool and error-free, one line at a time! Use the code maintainable to get a 10% discount for your first year. Check them out! Subscribe to Maintainable on:Apple PodcastsSpotifyOr search "Maintainable" wherever you stream your podcasts.Keep up to date with the Maintainable Podcast by joining the newsletter.

Allen Wyma talks with Andrew Lamb about InfluxDB's rewrite. InfluxDB is an open-source time series database. As a Staff Engineer at InfluxData, he works on InfluxDB 3.0, a new time series database written in Rust, focusing on query processing and the Apache Arrow DataFusion and Apache Arrow ecosystems. In that capacity, he is a member and past chair of the Apache Arrow PMC and actively contributes to Apache Arrow DataFusion and the Apache Rust implementation query engine. Andrew was a professional C/C++ programmer for 10 years before switching to Rust. His experience ranges from startups to large multinational corporations and distributed open source projects, and has paid leadership dues as an architect and manager/VP. He holds an SB and MEng from MIT in Electrical Engineering and Computer Science. Contributing to Rustacean Station Rustacean Station is a community project; get in touch with us if you'd like to suggest an idea for an episode or offer your services as a host or audio editor! Twitter: @rustaceanfm Discord: Rustacean Station Github: @rustacean-station Email: hello@rustacean-station.org Timestamps [@0:52] - Meet Andrew Lamb, Staff Engineer at InfluxData, working on InfluxDB IOx [@2:57] - Transitioning from C++ to Rust: Andrew's story [@11:24] - InfluxDB rewrite and its use cases [@22:13] - Compatibility of InfluxDB [@26:58] - Downsides of using Rust and other languages [@32:40] - Plans for the 3.0 alpha/beta release and different versions [@34:54] - Unique use of the async runtime Tokio [@55:28] - Rust as a tool for recruitment [@58:16] - Closing discussion Other links Andrew's X Account Using Rustlang's Async Tokio Runtime for CPU-Bound Tasks Using the FDAP Architecture to build InfluxDB 3.0 RustASIA Conf 2025 Credits Intro Theme: Aerocity Audio Editing: Plangora Hosting Infrastructure: Jon Gjengset Show Notes: Plangora Hosts: Allen Wyma

Dan Neciu, technical co-founder and tech lead of CareerOS, shares intriguing production horror stories, discusses the importance of rigorous testing, and provides valuable insights into preventing and managing software bugs in both backend and frontend development. Links https://neciudan.dev https://www.youtube.com/@NeciuDan https://www.linkedin.com/in/neciudan https://x.com/neciudan We want to hear from you! How did you find us? Did you see us on Twitter? In a newsletter? Or maybe we were recommended by a friend? Let us know by sending an email to our producer, Emily, at emily.kochanekketner@logrocket.com (mailto:emily.kochanekketner@logrocket.com), or tweet at us at PodRocketPod (https://twitter.com/PodRocketpod). Follow us. Get free stickers. Follow us on Apple Podcasts, fill out this form (https://podrocket.logrocket.com/get-podrocket-stickers), and we'll send you free PodRocket stickers! What does LogRocket do? LogRocket provides AI-first session replay and analytics that surfaces the UX and technical issues impacting user experiences. Start understand where your users are struggling by trying it for free at [LogRocket.com]. Try LogRocket for free today.(https://logrocket.com/signup/?pdr) Special Guest: Dan Neciu.

Just because the AWS Cloud hangs above our heads, doesn't mean your bill needs to be just as sky-high. In this Screaming in the Cloud Summer Replay, Corey is joined by Airbnb Staff Software Engineer Melanie Cebula. Her job is to ensure they keep their monthly cloud bill low, and that the cost isn't just there for a temporary stay. Hear Melanie and Corey chat about the vital role engineers play in helping balance the company books, tricks to optimizing your organization's cloud spending, how inexperience can have a dangerous effect on cost-cutting, and the growing pains facing today's world of data infrastructure. We hope you enjoy this trip down memory lane (just be sure you checkout on time to avoid any fees).Show Highlights: (0:00) Intro to episode(0:27) Backblaze sponsor read(0:54) The role of a Staff Engineer(2:09) Working for a large company reliant on the cloud(3:59) Melanie's Area of Expertise(5:58) Efficiently Managing AWS Bills(11:33) Optimizing cloud spend(14:50) The harmful hesitancy to turn things off(18:17) Inexperience and cost-saving measures(21:17) Firefly sponsor read(21:53) How to avoid snowballing cloud bills(23:40) Kuberentes and cloud billing(27:12) The perks of compounding microservices(29:19) Misconceptions about Kuberentes(31:10) Growing pains of data infrastructure(34:44) Where you can find MelanieAbout Melanie CebulaMelanie Cebula is an expert in Cloud Infrastructure, where she is recognized worldwide for explaining radically new ways of thinking about cloud efficiency and usability. She is an international keynote speaker, presenting complex technical topics to a broad range of audiences, both international and domestic. Melanie is a staff engineer at Airbnb, where she has experience building a scalable modern architecture on top of cloud-native technologies.Besides her expertise in the online world, Melanie spends her time offline on the “sharp end” of rock climbing. An adventure athlete setting new personal records in challenging conditions, she appreciates all aspects of the journey, including the triumph of reaching ever higher destinations.On and off the wall, Melanie focuses on building reliability into critical systems, and making informed decisions in difficult situations. In her personal time, Melanie hand whisks matcha tea, enjoys costuming and dancing at EDM festivals, and she is a triplet.Links Referenced:Twitter: https://twitter.com/melaniecebulaMelanie Cebula's website: https://melaniecebula.com/SponsorsBackblaze: https://www.backblaze.com/Firefly: https://www.firefly.ai/

In this episode of the Maintainable Software Podcast, Robby Russell sits down with James Socol, a Staff Engineer at Fastly, to discuss the art of maintaining legacy code and the nuances of technical debt versus technical depreciation.Key Topics Discussed:Characteristics of Well-Maintained Code: James shares his insights on what defines well-maintained code, emphasizing the importance of continuous maintenance, testing, and encapsulation.Technical Debt vs. Technical Depreciation: James introduces the concept of technical depreciation, distinguishing it from technical debt and explaining how time affects software maintenance.Balancing Old and New Patterns: The discussion explores the challenges of integrating modern standards into legacy systems and finding a healthy balance.20% Time for Maintenance: James advocates for dedicating a portion of engineering capacity to maintenance tasks, drawing parallels to Google's 20% time concept.Onboarding Strategies: James offers valuable advice for new hires, emphasizing observation, gradual involvement, and building social capital within the team.Continuous Delivery and Big Changes: Insights into managing significant changes in a continuous delivery environment, with practical strategies for maintaining stability.Resources Mentioned:Riot Engineering Blog: A Taxonomy of Tech DebtSilicon Valley Product GroupLaura Hogan's Donut TheoryBooks:Getting to Yes by Roger Fisher & William UryTurn the Ship Around by L. David MarquetThanks to Our Sponsor!Turn hours of debugging into just minutes! AppSignal is a performance monitoring and error tracking tool designed for Ruby, Elixir, Python, Node.js, Javascript, and soon, other frameworks.It offers six powerful features with one simple interface, providing developers with real-time insights into the performance and health of web applications.Keep your coding cool and error-free, one line at a time! Check them out! Subscribe to Maintainable on:Apple PodcastsSpotifyOr search "Maintainable" wherever you stream your podcasts.Keep up to date with the Maintainable Podcast by joining the newsletter.

In this episode of Maintainable, Robby chats with Paola Ducolin, Staff Engineer at Datadog. Paola shares her insights on the characteristics of well-maintained software, the common struggles teams face, and effective strategies for working with stakeholders to prioritize refactoring.Key Topics Discussed:Characteristics of Maintainable Software: Paola explains the importance of well-documented code and having tests that automatically detect breaks.Challenges in Maintaining Software: The impact of business pressures on maintaining code quality and how teams can navigate these challenges.Working with Stakeholders: Strategies for communicating the importance of refactoring and measuring the impact of technical debt on business objectives.Role of Staff Engineers: Paola's journey to becoming a staff engineer and the responsibilities that come with the role, including coordination and networking.Documentation and Design Systems: The power of documentation and how design systems can serve as a model for well-documented and maintainable code.Observability and Monitoring: An overview of Datadog's tools for observability and monitoring, and how they help in maintaining software quality.Resources Mentioned:DatadogMy Path to Staff EngineerSarah Drasner: The Art of Code CommentsBook RecommendationsRadical CandorCrucial ConversationsBe sure to follow Paola on LinkedIn and stay tuned for more insightful conversations on Maintainable.Thanks to Our Sponsor!Turn hours of debugging into just minutes! AppSignal is a performance monitoring and error tracking tool designed for Ruby, Elixir, Python, Node.js, Javascript, and soon, other frameworks.It offers six powerful features with one simple interface, providing developers with real-time insights into the performance and health of web applications.Keep your coding cool and error-free, one line at a time! Check them out! Subscribe to Maintainable on:Apple PodcastsSpotifyOr search "Maintainable" wherever you stream your podcasts.Keep up to date with the Maintainable Podcast by joining the newsletter.

[קישור לקובץ mp3]פרק 473 של רברס עם פלטפורמה, שהוקלט ב-27 ביוני 2024 - אורי ורן מארחים את הילה פוקס מ-Forter, כדי לדבר על “איך חושבים מוצרית” לאנשי טכנולוגיה או - איך אנשי טכנולוגיה חושבים (יכולים לחשוב? עלולים לחשוב?) מוצרית.00:40 הילה והצוות המועצם(רן) אז קצת לפני שנצלול בפנים, הילה - בואי נכיר אותך קצת . . . אז קצת עלייך?(הילה) אז אני הילה - אני מובילה טכנולוגית, עם מעל עשר שנות ניסיון.עבדתי ב-Intel וב-Fiverr, וגם בחברה בשם Augury, לפעמים קצת פחות מוכרת . . . ועכשיו אני Staff Engineer ב-Forter - כש-”Staff Engineer” זה “Tech Lead”, אפשר לומר.(רן) משום מה, חבריי ב-Augury - לא שיש לי - אבל תמיד אומרים שאתם לא מוכרים, ותמיד כולם מכירים אתכם . . . סנסורים למנועים, למכונות וכל זה.(הילה) נכון, יפה . . . . כן, זו חברה חיפאית, מי בכלל זוכר, מי יודע?(רן) אולי בגלל ה”חיפה” זה עובד . . . אז יאללה, נרים לכולם. טוב - אז את עובדת ב-Forter עכשיו, כ-Staff Engineer. למה מעניין אותך מוצר? כאילו - את מי זה מעניין? את רק רוצה להעביר ביטים, לא?(הילה) אז לא . . . אולי אני אביא את זה קצת גם מתוך הסיפור … קרא עוד

Join us in this episode as we dive into the world of scalable and resilient backend infrastructure with Konrad Reiche. A Berlin-transplant living in San Francisco, Konrad is a seasoned software engineer who brings a wealth of experience and insight into designing abstractions that add immense value. Currently a Staff Engineer at Reddit, Konrad's initial background is in audio and video streaming, where he made significant contributions to backend systems. His work, largely inspired by the Go programming language, reflects his dedication to innovation and excellence. Konrad is also a regular speaker at conferences and meetups, sharing his knowledge and passion with the broader tech community. Tune in to learn more about his journey and challenges along the way.00:00 Introduction01:04 What is Konrad Doing Today?12:07 First Memory of a Computer24:30 Going to University43:50 Joining the Workforce 53:40 Working with Go1:07:40 Getting Hired Through the Gopher Slack1:23:50 Working at Reddit1:30:43 Contact Info  Connect with Konrad: Twitter: https://twitter.com/@konradreicheKonrad's Website: https://konradreiche.com/Mentioned in today's episode:Reddit: https://www.reddit.com/Gopher Slack: https://gophers.slack.com/Want more from Ardan Labs? You can learn Go, Kubernetes, Docker & more through our video training, live events, or through our blog!Online Courses : https://ardanlabs.com/education/ Live Events : https://www.ardanlabs.com/live-training-events/ Blog : https://www.ardanlabs.com/blog Github : https://github.com/ardanlabs

“Always remember that system design interview is not about perfection. It is about trade-offs and being able to communicate them clearly and concisely." Zhiyong Tan is the author of “Acing the System Design Interview”. In this episode, he joins me in demystifying the system design interview process. He shares insights into what to expect, how to tackle common challenges like time management, anxiety, and knowledge gaps, and reveals the core principles that guide successful system design interview. Zhiyong dives deep into common pitfalls, offering advice on handling tricky topics like requirements gathering, data consistency, scaling problems, and service design. He also provides practical tips on how to learn and grow from system design interview failures, turning setbacks into stepping stones towards success. Whether you're a seasoned engineer or just starting your tech career, this episode offers valuable insights and actionable advice to help you ace your next system design interview.   Listen out for: Career Journey - [00:01:43] System Design Interview - [00:05:03] Trade-offs - [00:07:36] Managing the Time - [00:09:51] Handling What You Don't Know - [00:13:27] Managing Anxiety - [00:15:40] System Design Interview Principles - [00:18:32] Non-Functional Requirements - [00:21:22] Data Consistency - [00:25:11] Database Scaling Problem - [00:28:41] Distributed Transactions - [00:33:09] Functional Requirements & API Design - [00:36:31] Failing System Design Interview - [00:38:38] 3 Tech Lead Wisdom - [00:42:02] _____ Zhiyong Tan's BioZhiyong Tan is the author of Acing the System Design Interview. He is the founder of Tingxie, an app for learning Chinese as a second language. Previously, he was an Engineering Manager and Staff Engineer at PayPal, a senior software engineer at Uber, and a software and data engineer at various startups. Follow Zhiyong: LinkedIn – linkedin.com/in/zytan Acing System Design Interview – https://www.manning.com/books/acing-the-system-design-interview Tingxie (iOS) – https://apps.apple.com/us/app/%E5%90%AC%E5%86%99-chinese-spelling-dictation/id6462944919 Tingxie (Android) – https://play.google.com/store/apps/details?id=com.zhiyong.tingxie Jointgoals.com – https://www.jointgoals.com/ Manning forum – https://livebook.manning.com/forum _____ Our Sponsors Enjoy an exceptional developer experience with JetBrains. Whatever programming language and technology you use, JetBrains IDEs provide the tools you need to go beyond simple code editing and excel as a developer.Check out FREE coding software options and special offers on jetbrains.com/store/#discounts.Make it happen. With code. Manning Publications is a premier publisher of technical books on computer and software development topics for both experienced developers and new learners alike. Manning prides itself on being independently owned and operated, and for paving the way for innovative initiatives, such as early access book content and protection-free PDF formats that are now industry standard.Get a 45% discount for Tech Lead Journal listeners by using the code techlead45 for all products in all formats. Like this episode? Show notes & transcript: techleadjournal.dev/episodes/176. Follow @techleadjournal on LinkedIn, Twitter, and Instagram. Buy me a coffee or become a patron.

As the podcast host of The Builders, member of Postgres Women, and Staff Engineer at EDB, Gülçin Yıldırım Jelínek is passionate to see where this space will take us. We kick off Season 2 with Gülçin as she shares her journey in the tech industry, CloudNativePG, the impact of AI on Postgres, and the representation of women in the Postgres community.In this episode we explore:CloudNativePG in Gülçin's products and the new SPGVector releaseWelcoming new developers to the PostgreSQL communityTembo Cloud, PG vector, and the challenges and rewards of contributing to such innovative projectsImproving inclusivity and support for women in the tech industryThe use of Postgres in AI workloadsLinks mentioned:The Builders: A Postgres PodcastGülçin Yıldırım Jelínek on X EDBPostgres Women on X

Embrace the Site Reliability Mindset with Alex Ewerlöf, Sr. Staff Engineer @ Volvo Cars

In this conversation, Fable and Ben dig deep on building a technical career that balances programming and company leadership. Fable shares their experience working at Stripe and the different roles they have held, including being a technical advisor to the CTO. They also discuss Fable's career move from being a hands-on programmer to role where less hands-on coding is required, Fable's take on "code crimes", and how to find enjoyment and fulfillment in solving complex problems.LinksTuple.app - The best app for pair programmingStripe - The company Fable works atRuby Kaigi - An annual conference dedicated to the Ruby programming language.Sidekiq - A simple, efficient background processing library for RubySorbet - A fast, powerful type checker designed for Ruby.YubiKey - A hardware device designed for high-security two-factor authentication.Key TakeawaysMaking connections and friendships at conferences can be valuable in the programming community.Debugging and problem-solving skills are crucial for software engineers.Being willing to learn and work with different programming languages can enhance your skills.Prototyping and spiking can be effective ways to test and develop new ideas.Chapters(00:00) - Introduction and Conference Interaction (00:38) - Making Friends at Conferences (04:13) - Work at Stripe (06:17) - Becoming a Staff Engineer (06:53) - Getting Good at Programming (08:46) - Debugging and Problem Solving (11:22) - Working with C and C++ (13:13) - Debugging with Print Statements and Debuggers (17:06) - Prototyping and Spiking (24:11) - Technical Advisor to the CTO (27:26) - Coding Hill to Die On (29:52) - Workflow Optimization (36:53) - Coding vs Non-Coding Time (39:08) - Transition to Leadership (41:07) - Motivation and Impact (42:13) - Love for Programming (44:14) - Coding Style: Short Methods and Small Classes (48:48) - Personal Style and Code Crimes (52:18) - Commercial Open Source (56:08) - Getting Involved in Open Source (01:04:52) - Wrap-up

After 17 years building SRE teams at Google and serving as the Site Lead for Engineering in Dublin, Dave joined Elastic as the Sr Director of Engineering and later VP of Engineering at Twilio. Following a recent career break, Dave now divides his time between coaching engineering leaders and consulting to help busy teams be more effective. In the heart of our conversation, Dave shares the frameworks and practical tips he's amassed for making the most of the mentorship experience.   Segments: [00:01:45] Growing remote SRE team as the Google Dublin Site Lead [00:19:49] Company Culture vs Company Values [00:23:47] How to find companies that are serious about remote work [00:34:26] Coaching vs Mentoring at Big vs Small companies [00:38:35] How Google does coaching & mentoring [00:41:38] What makes a good 1-1 [00:46:56] Considerations for seeking out a mentor [01:03:27] Getting external mentorship while working at a small company [1:08:20] How to set specific goals for mentorship [1:20:13] The “CIA” Method for career decision making [1:31:08] How to sunset mentorship 1-1s [1:35:20] Venturing into consulting to help busy teams be more effective [1:42:13] How to get started with consulting   Show Notes: Dave on LinkedIn: https://www.linkedin.com/in/gerrowadat/ Dave's personal website: https://log.andvari.net/pages/about.html Dave's coaching website: https://www.strategichopes.co/ Service Level Objectives by Alex Hidalgo: https://www.oreilly.com/library/view/implementing-service-level/9781492076803/ The Staff Engineer's Path by Tanya Reilly: https://www.oreilly.com/library/view/the-staff-engineers/9781098118723/   Stay in touch:

Will Larson is the CTO at Carta, an ownership and equity management platform that raised at a $7.4b valuation in 2021. Prior to joining Carta, Will was CTO at Calm, founded Stripe's Foundation Engineering org, and led Uber's Platform Engineering people and strategy. Will also writes extensively about engineering leadership, and has authored two books in this area: Staff Engineer, and An Elegant Puzzle. — In today's episode we discuss: How to form an engineering strategy Common engineering management mistakes, and how to avoid them Advice for explaining, measuring, and optimizing engineering velocity Will's nuanced approach to organizational policies Why it's sometimes counterproductive to tell someone not to micromanage — Referenced: Accelerate (book): https://www.amazon.com/Accelerate-Software-Performing-Technology-Organizations/dp/1942788339 Calm: https://www.calm.com/ Carta: https://www.carta.com/ DORA: https://dora.dev/ Good Strategy, Bad Strategy (book): https://www.amazon.com/Good-Strategy-Bad-Difference-Matters/dp/0307886239 JavaScript: https://www.javascript.com/ KAFKA: https://kafka.apache.org/ Minto Pyramid (framework): https://untools.co/minto-pyramid Ruby on Rails: https://rubyonrails.org/ SPACE (framework): https://queue.acm.org/detail.cfm Stripe: https://www.stripe.com/ — Where to find Brett Berson: Twitter/X: https://twitter.com/brettberson LinkedIn: https://www.linkedin.com/in/brett-berson-9986094/ — Where to find Will Larson: Twitter/X: https://twitter.com/lethain LinkedIn: https://www.linkedin.com/in/will-larson-a44b543/ Personal website/blog: https://lethain.com/ An Elegant Puzzle (book): https://www.amazon.com/Elegant-Puzzle-Systems-Engineering-Management/dp/1732265186 Staff Engineer (book): https://staffeng.com/book — Where to find First Round Capital: Website: https://firstround.com/ First Round Review: https://review.firstround.com/ Twitter: https://twitter.com/firstround Youtube: https://www.youtube.com/@FirstRoundCapital This podcast on all platforms: https://review.firstround.com/podcast — Timestamps: (00:00) Introduction (03:03) The nuances of taking lessons from old companies (14:28) The value of writing down engineering principles (17:03) How to structure a strategy document (18:48) The 2 parts of any engineering strategy (21:08) Advice for turning strategy into action (23:44) Carta's unique "navigator" model (24:50) The Hidden Variable Problem (29:59) Explaining, measuring, and optimizing velocity (35:28) Useful metrics for engineering orgs (39:08) The balance between micromanagement and understanding details (43:03) Management anti-patterns (45:49) How to execute policies whilst managing their exceptions (47:56) What an excellent engineering executive looks like (53:53) How Will has evolved as an engineering executive (56:56) How to communicate with executives (63:18) Things that derail meetings (66:10) How to approach presentation feedback (67:30) A bad sign when working with direct reports (69:13) Advice for growing as an early-career engineer (71:11) Will's model for developing engineering teams (74:33) Sources of inspiration for Will's views on engineering management

Stephanie discovered a new book: The Staff Engineer's Path! Joël's got some D&D goodness. Together, they revisit a decade-old blog post initially published in 2013, which discussed the application of Sandi Metz's coding guidelines and whether these rules remain relevant and practiced among developers today. Transcript: JOËL: Hello and welcome to another episode of The Bike Shed, a weekly podcast from your friends at thoughtbot about developing great software. I'm Joël Quenneville. STEPHANIE: And I'm Stephanie Minn. And together, we're here to share a bit of what we've learned along the way. JOËL: So, Stephanie, what's new in your world? STEPHANIE: So, I picked up a new book from the library [laughs], which that in itself is not very new. That is [laughs] a common occurrence in my world. But it was kind of a fun coincidence that I was just walking around the aisles of what's new in nonfiction, and staring me right in the face was an O'Reilly book, The Staff Engineer's Path. And I think in the past, I've plugged The Manager's Path by Camille Fournier on the show. And in recent years, this one was published, and it's by Tanya Reilly. And it is kind of, like, the other half of a career path for software engineers moving up in seniority at those higher levels. And it has been a really interesting companion to The Manager's Path, which I had read even though I wasn't really sure I wanted to be manager [laughs]. And now I think I get that, like, accompaniment of like, okay, like, instead of walking that path, like, what does a staff plus engineer look like? And kind of learning a little bit more about that because I know it can be really vague or ambiguous or look very different at a lot of different companies. And that has been really helpful for me, kind of looking ahead a bit. I'm not too far into it yet. But I'm looking forward to reading more and bringing back some of those learnings to the show. JOËL: I feel like at the end of the year, Stephanie, you and I are probably going to have to sit down and talk through maybe your reading list for the year and, you know, maybe shout out some favorites. I think your reading list is probably significantly longer than mine. But you're constantly referencing cool books. I think that would probably be a fun, either end-of-year episode or a beginning-of-year episode for 2024. One thing that's really interesting, though, about the contrast of these two particular books you're talking about is how it really lines up with this, like, fork in the road that a lot of us have in our careers as we get more senior. You either move into more of a management role, which can be a pretty significant departure from what you have to do as a developer, or you kind of go into this, like, ultra-senior individual contributor path. But how that looks day to day can be very different from your sort of just traditional sitting down and banging out tickets. So, it's really cool there's two books looking at both of those paths. STEPHANIE: Yeah, absolutely. And I think the mission that they were going for with these books was to kind of illuminate a little bit more about that fork and that decision because, you know, it can be easy for people to maybe just default into one or the other based on what their organization wants for them without, like, fully knowing what that means. And the more senior you get, the more vague and, like, figure it out yourself [laughs] the work becomes. And it can be very daunting to kind of just be thrown into that and be like, well, I'm in this leadership position now. People are looking to me, and I have all this responsibility, but, like, what do I do? Yeah, so I'm kind of enjoying this book, that is...it's not a technical book, which is actually kind of what I like about it. It's actually more of a leadership book, which is really important for that kind of role. Even though, you know, they are still in that IC track, but it does come with a lot of leadership responsibility. JOËL: Yes, leadership in a very different way than management. But—and this may be counterintuitive for some people, especially earlier on in their careers—going further up that individual contributor track doesn't just mean getting more intense technically. It often means you've got to focus on things more like leadership, like being a bit more strategic, aligning technical initiatives with strategic goals. STEPHANIE: Yeah, and having a bigger impact and being a force multiplier, even in both the manager and, like, the staff plus role, like, that, you know, is the thing that ties the rising level. JOËL: Yeah, in many ways, maybe the individual contributor track is slightly misnamed because while, yes, you're not managing a sort of sub-organization within the company, it's still about being a force multiplier. STEPHANIE: Yeah, that's a really great point [laughs]. Maybe we'll be able to come up with a better [laughs] name for that. JOËL: I've mentioned several times on this podcast that I've been enjoying playing Dungeons & Dragons, D&D, with some friends and some colleagues. And something that was particularly fun that some friends and I did this summer is we hired a professional DM to run one shot for us. And that was just an absolutely lovely experience. Well, as a result of that, I am now subscribed to this guy's newsletter. And he'll do, like, various D&D events at different times. One thing that was really cool that I found out recently...as we're recording this, it's the week before election day in the U.S. And because a lot of voting happens in schools, typically, schools have the day off. And so, this guy sent out an email saying he was offering to run a, like, all day...effectively, a little mini-D&D camp for school-age kids on election day so that you can do your work. You can go vote, and you don't have to...basically, he'll watch your kids for you and, like, get them introduced to playing D&D, which I think is just a really cool thing to do. STEPHANIE: I love that. It's so heartwarming [laughs]. And it's such a great idea because, oftentimes, people are still working, and so they need childcare, like, on those kinds of days. And yeah, I think D&D is such a fun thing for kids to get into, too. You know, it requires so much, like, imagination, and I can imagine it's such a blast. JOËL: I got that email, and I was like, that is such a perfect idea. I love it so much. STEPHANIE: I wanted to plug my D&D recommendation. I'm pretty sure I have mentioned it on the show before. But there is a podcast that I listen to called Not Another D&D Podcast, which is, you know, a live play Dungeons & Dragons podcast campaign that's hosted by these comedians, formerly of CollegeHumor, and it's very fun. I always laugh. They have this, like, a kind of offshoot of the main show that they do called D&D Court, which is very fun. Because, as you were saying, like, you know, you hired a DM to run your game. And I know that...I'm sure lots of people have fun stories about their home games and, like, the drama that happens [laughs] with their friends. JOËL: Absolutely. Absolutely. STEPHANIE: And so, with D&D Court, listeners can write in with their drama or their conflicts and get an official ruling from the hosts about who was right [laughs] in the situation that they write in about. JOËL: So, you get to bring your best rules lawyering to the D&D Court. STEPHANIE: Yeah, exactly [laughs]. JOËL: That sounds kind of amazing. Recently, I had someone reach out to me asking about an older blog post that we'd written about the Sandi Metz Rules. This blog post was initially published in 2013, so ten years ago, and was talking about some guidelines that Sandi Metz at the time was talking about that she was using in some of her code. And we talked about how our experience was applying those to some of our work as well. And so, the question was, you know, ten years later, is that still something that thoughtbot developers like to follow in their code? We'll link to the article in the show notes. But I'll just read out the rules here real quick. So, there's four of them. The first one is a class can be no longer than 100 lines of code. The second is a method can be no longer than five lines of code. The third is pass no more than four parameters into a method, and hash options count, so no getting clever with those. And then, finally, controllers can only instantiate one object. You only get one instance variable. And views can only talk to that one instance variable. Had you or are you familiar with these rules? Is that something that you think about or use in your daily writing of code? STEPHANIE: Yeah. So, when you proposed this topic, I had to revisit these rules. And I can't recall if I had seen them before. They seemed familiar. And I've read, you know, a couple of Sandi Metz's books, so maybe those were places where she had mentioned them. But the one thing that really struck me when I was first reading the rules was how declarative they were in terms of, like, kind of just telling you what the results should be without really saying how. So, for example, the one where you said, you know, a method should not be more than five lines [laughs], I had the silly thought of, like, well, you could just, you know, stuff everything into a single line [laughs] and just completely disregard line limit if you wanted, and it would technically still follow the rule. JOËL: If they didn't want us to do that, they wouldn't give us semicolons in Ruby. STEPHANIE: Exactly [laughs]. So, that is kind of what struck me at first. Is that something you noticed? JOËL: I think what is interesting with them is that there's not always a ton of rationale given behind them. Our article talks a little bit about some of the why that might be helpful and how that might look like in practice. I'm not sure what Sandi's original...I don't know if it was one of her books or maybe on a...it might have been on a podcast appearance she talked about them, so she might go more in-depth there. But yeah, they are a little bit declarative. It's just like, hey, here's...it's almost basically the kind of thing that can be enforced by a linter, which is perhaps the point. STEPHANIE: Ooh, that's really interesting. It's like, on one hand, I like how simple they are, right? It's like, they're very obvious. If you're not following them, you can tell. But on the other hand, they seem to be more of a supplement to the gained knowledge and experience that you kind of get from knowing how to implement those rules. I think you and I will both agree that we don't want to stuff everything [laughs] into a single line with semicolons. But if someone who maybe is newer to development and is coming to these rules, I think they might be wondering, like, how do I do this? JOËL: Do you follow these rules in your own code? STEPHANIE: I think the ones that are easier to follow, for me, and that I think I've come to do more instinctually, are the rules about class line length and method line length just because I'm kind of looking out for opportunities to pull out a method or, you know, make sure that this class is just doing one thing. And if it's starting to seem to cover a couple of different responsibilities, I'm a little bit more on the lookout. But I do like these rules as like, you know, like, hey, once you hit, you know, 100 lines in a class, like, maybe that's your cue to start thinking about opportunities for extraction. JOËL: Do you sort of consciously follow these rules or have them maybe even encoded in a linter? Or is it more you're following other things, and somehow, it just lines up with these principles? STEPHANIE: I would say that, like, I'm not thinking about them very actively. But that could be a very interesting exercise, and I think, you know, that's what folks did in the blog post. They were like, hey, we took these rules, and we really kept them in mind as we were developing. But I think kind of what we were talking about earlier about, like, what we've learned or the strategies we've learned to implement kind of converge on these rules. And the rules actually are more of the result of other ideas or heuristics that we follow. JOËL: I mean, you dropped the keyword heuristics there. And I think that brings me back to an earlier episode we did where we talked about heuristics. And one of the things that came up on that episode was the idea that, oftentimes, we use heuristics as a way to sort of flatten a lot of experience and knowledge into sort of one, like, short rule, or short phrase, or something, one guideline, even though it's sort of trying to just summarize a mountain of wisdom. And so, oftentimes, you can look at something like these rules and be like, okay, well, what's the point? Or maybe you even just follow it to the letter without really thinking about the why behind it, and that can sometimes be problematic. And on the other hand, you might know all of the ideas that go behind them. And without necessarily knowing the rule itself, you just kind of happen to follow it because you're intimately familiar with all of these other software principles that converge on those same ideas. STEPHANIE: Yeah, agreed. I think that the more interesting ones to me are the no more than four method arguments and only one instance variable per controller. JOËL: Interesting. STEPHANIE: I'm curious if those are sparking anything for you [laughs]. JOËL: I think the no more than four method arguments, to me, is probably the least controversial. It's generally accepted that having many arguments to a method is a code smell. And there's a few different code smells that are related to that. There's forms of coupling incandescence; there are data clumps, things like that. I've often heard a sort of rule of three. And so, if you're going more than three, then you might want to revisit the structure of what you're building. Four is a bit of an arbitrary cut-off, I'll agree. Most of these are arbitrary cut-offs. But I think the idea to maybe keep your method to fewer arguments is generally a good thing to do. STEPHANIE: I liked that the rule points out that hash options account because I think that's maybe where people get a little more hand-wavy, or you have your ops hash [laughs] that can be just a catch-all for anything. You know, it's like, once you start putting stuff in there, I don't know, I feel like it's a like a law of the universe. It's like, oh, people will just stuff more things in there [laughs]. And it takes obviously more effort or, like, specific energy to, like, think through what those things might represent, or some alternative ways of handling those arguments. We definitely do have, I think, a couple of episodes on value objects. But that's something that we have talked a lot about before in terms of, you know, how can we take some kind of primitive data, hashes included, and turn them into a richer object that can then be passed on its own? JOËL: Right. And an options hash is generally...it's too much of a catch-all to really have an identity as its own sort of value object. It doesn't really represent any single thing. It's just everything else bag of data. One thing that's interesting that the article notes is that a lot of the helpers in Rails take a lot of arguments and that it is absolutely not worth trying to fight the framework to try to follow these rules. So, the article does take a very pragmatic approach, I think, to the idea of these rules. STEPHANIE: Yeah. And I think there is even a caveat to the rules where it's like, you can break them if you have a good reason, or if you're working with someone else and they give you the thumbs up [laughs], which I really like a lot because it almost kind of compels you to stop and be like, do I have a good reason of doing this? Just making sure, or I'll run it by a friend. And shifting that, I guess, that focus from kind of just coding from, like, your default mode of thinking to a more active one. JOËL: Right. There is a rule zero, which says you can break any of the other rules as long as you convince either your pair or your reviewer to give you a thumbs up on breaking the rule. So, you'd mentioned the fourth rule about a single instance variable in a controller kind of was one of the ones that stood out to you. What is particularly striking about that rule? STEPHANIE: I think this one is hard to follow, and I think the blog post mentions that as well. Because at least I've seen our web applications grow more and more complex. And it can be really challenging to just be like, what is this page doing? Like, what, you know, data does it need to know? And have that be the single thing. Because really, a lot of our web apps have a lot of things [laughs] that they're doing, and sometimes it feels like you have to capture more than one object or at least, like, a responsibility in this way. I think that's the one that I, you know, in my ideal world, I'm like, yeah, like, we have all these, like, perfectly RESTful routes. And, you know, we're only dealing with, you know, a single resource. But once you start to have some more complexity, I think that can be a little more challenging. JOËL: I think it's interesting that you mentioned RESTful routing because I think that is maybe one of the bigger things that does trigger having more instance variables in your controller actions. If you're following sort of the traditional Rails RESTful routes, every page is generally focused on a singular resource. Now, that may not necessarily line up with a table in your database, and that's fine. But you're dealing with a singular thing or perhaps, you know, in the case of an index page, a singular collection of things, which can be represented with a single instance variable. Once you start adding custom routes that may not be necessarily tied to a particular resource, now you can very easily kind of have a proliferation of all sorts of different things that interact with each other because you're no longer centered on a single thing. STEPHANIE: Yeah, that's true, which actually reminds me of something we've talked about before, too, when we were both reading Sustainable Rails. The author talks about custom routes and actually advocates for making all routes RESTful. And if you need a vanity URL or something like that, you can always alias it. That I liked, right? It's like, okay, even if, you know, your resource is not something that's like, ActiveRecord-backed, is there some abstraction or concept of a resource in there? And I actually did really like in the blog post in the example; that is one that I've used before, too. They were dealing with this idea of a dashboard, which I would, you know, say is pretty common in a lot of web applications these days. And it's funny because a dashboard can hold so much data, right? It's really, like, a composite of a lot of different things, you know, what is most, like, useful for the user to see in one place. But they were in the blog post. And this, again, this is kind of something that I've done before. They were able to capture that with the idea of, like, a dashboard as an object and that being codified using a presenter or a facade. JOËL: Right. So, instead of having a group, and a status, and a user, and all these, like, separate things that your page that you're showing is a sort of collection of all these different types of objects, you wrap them together in a dashboard object that's kind of a facade. And I guess that really does line up with the idea of RESTful routing because you're likely going to have a dashboard's controller show action that's showing the user's dashboard. So, it makes sense, you know, that show page is rendering a dashboard object. STEPHANIE: Can we talk a little bit about things not to do, or maybe things that might be a little more questionable [laughs], and if you've seen them and how you felt about them? JOËL: I think it is sometimes tricky to define your boundaries right in that sometimes you create a facade object that really is just...it doesn't really represent anything. It's just there to wrap around some other things. And sometimes that can be awkward. I think the dashboard works partly because it lines up so neatly with the sort of RESTful routing and thinking in terms of resources that you want to do at the controller layer. But drawing boundaries incorrectly or just trying to throw everything in some kind of grab bag object can...it's not a magic bullet, right? You've got to put some thought into the data modeling, even when you are pulling the facade pattern. STEPHANIE: Yeah, I think other things that I've seen before that could theoretically follow this rule maybe [laughs], you know, I'd love to hear your thoughts about it. When you start, you're like, oh, like, my controller action method does just, you know, set one instance variable. But it turns out that there's all these other instance variables that either through a hook or, like, in the parent controller or even in the view I've seen before, too [laughs]. And I'm just kind of curious if that kind of raises your eyebrow at all or if you've seen any good reasons for doing so. JOËL: I think setting instance variables in a view would absolutely cause me to raise an eyebrow. STEPHANIE: [laughs] Agreed. JOËL: Generally, don't put logic in the view. I think that we definitely have in parent controllers; we'll set other instance variables for things like maybe a current user, right? That's how we store that state. And I think that is totally fine to have around. Typically, we don't access that instance variable directly. We're referencing some kind of helper method. But yeah, I would not consider that a violation of the rule. I think another common one that might come up is when you have some kind of nested resource. And so, in your URL, you might have a nested resource where you're saying, "Oh, I'm looking at specifically this comment under this article or something like that." And then, you want to have access to both objects in the controller. So, I think that's a pretty common scenario where you might want to have both instance variables. Something that I'm thinking about...this is not a fully formed thought, so I'm curious about your opinions here. Is there an interesting distinction between variables in code that you want to use within a controller versus variables that you want to be accessible from a view? Because instance variables in a controller are kind of overloaded. They're a way of having state in a controller, but they're also a way of passing data into a view. And so, that sort of dual purpose there maybe causes them to be a little bit trickier to reason about than instance variables in a random Ruby object. What do you think? STEPHANIE: Yeah, I was actually having the same thought as you were going there, which is that it is kind of interesting that the view, you know, is that level of what you want to display to your user. But it can have access to, like, whatever you put in the controller [laughs], and that is...and, you know, in some ways, it's like, that connection needs to happen somewhere, right? And it's here. But I think that can definitely be abused sometimes, too. So, this, you know, fourth rule that we're talking about really has to do with a more traditional Rails app. But, again, with the complexity of web apps in 2023 [chuckles], you know, we also see Rails used just as an API a lot with a separate front-end framework. And your controller is rendering some JSON, which I think has that harder boundary between what is the data that the server is involved with and what we want to send to our client. And I'm curious if you have any thoughts about how this rule applies in that situation. JOËL: I think I tend to see not really any difference there. If I'm building an API, typically, I'm trying to do so in a pretty RESTful manner. Maybe I'm doing a GraphQL API, and things might be different for that. But for a traditional REST API, yeah, typically, you're fetching one resource or some sort of compound resource, in which case, you're representing that with a facade object. And yep, you can generally get away, I think, with a single instance variable with, you know, a few exceptions around maybe some extra context about maybe something like the current user, or a parent object, or something like that. I guess the view is really you're using a different mechanism for rendering JSON, and there are a bunch out there that the community uses. I think I don't really see a difference between rendering to HTML versus rendering to JSON, or XML, or whatever. How about you? STEPHANIE: That's a good point. I think I'm with you where the rule still applies. But I have also seen things get really loosey-goosey [laughs] when we decide we're rendering JSON, and now we're suddenly putting the instance variables into a hash along with other stuff. But what you said was interesting about, like, sometimes you do need that extra context, right? And, like, figuring out what the best way to package that requires a bit of, like, sustained thought, I think, because it can, you know, be really easy to be like, oh well, this is the one interface that I have to get data from the server. So, if I just sneak this in here [laughs], what's the matter? But yeah, I think, you know, that's probably why rules like this exist [laughs] to help provide some guardrails and make us think a little deeper about it. JOËL: I think sometimes, as a community, we maybe exaggerate the differences between, like, RESTful HTML view and a RESTful JSON API. I tend to think of them as more or less the same. We just have, you know, a different representation the V layer of our MVC framework. Everything else still kind of lines up. STEPHANIE: Yeah, that's a really good point. I actually hadn't thought about it that way. Because I think maybe I have been influenced by the world of GraphQL [laughs] a little bit, or it's kind of hard to have a foot in both worlds, where you maybe have to context switch a little bit about, like, the paradigms, and then you find them influencing you in different ways. Because I have seen sometimes, like, what maybe initially were meant to be traditional more, like, RESTful JSON APIs kind of start to turn into that, like, how do we get what we need from this endpoint? JOËL: I'm curious how you feel in general about the facade pattern. Is that something that you've used, something that you like? STEPHANIE: I think I would say that I don't actually reach for it, like, upfront, right? Usually, I'm still trying to maybe put some things in my models [laughs]. But I have used it before once; it kind of became clear that, like, a lot of the methods on the model had to do with more really server-side concerns. And I was, like, wanting to just pull out some presentational pieces. I think the hardest part with the facade pattern is naming. I have really struggled sometimes to think of, like, it's not quite the component that makes it up. So, what is it instead? JOËL: Right. Right. I think, for me, sometimes the naming goes the other way around in that I'll start more to kind of, like, routing our resource level and try to think about, okay, this particular view of the data that I want to have, or this particular operation that I want to do, what am I actually dealing with? What is the resource here? So, maybe I'm viewing a dashboard. Or maybe what I'm doing is creating or destroying a subscription, even though those are not necessarily tables in the database. And once I have that underlying concept, then I can start creating an object that represents that, which might be a combination of multiple ActiveRecord models that represent tables. STEPHANIE: Yeah. You're actually pointing out, like, a really great use case that we see a lot, I think, is when you start to have to reach for resources, you know, that are different ActiveRecord classes. And how do you combine them together to represent the idea that you want, you know, for your feature? JOËL: I think it's more of, like, an outside-facing perspective rather than an inside-facing perspective. So, instead of looking at, hey, these are the set of ActiveRecord classes I have because these are my database tables, how can I, like, tack on to them to make this operation work? I'll sort of start almost from, like, a zoomed-out perspective, blank slate to say, "Hey, this is the kind of operation that I'm trying to do. What sort of resource am I dealing with ideally?" And, you know, maybe the idea is, okay, I'm dealing with a dashboard. I'm trying to subscribe to something...a newsletter, so the idea is I'm creating a subscription. Then, from there, I can start looking at, okay, do I have the concept of a subscription in this application? Oh, I don't. There is no subscriptions table because that's not a thing that we track in our data mode. That's fine. But I probably need at least some kind of in-memory object to track the idea of a subscription, and then maybe from there, that grows. So, I'm kind of working from the problem towards the database rather than from the database out. STEPHANIE: Yeah, I like that a lot. The outside-in phrase that you used really triggered something for me, which is being product engineers, right? Like, having a seat at the table when the feature is in that, like, ideation phase, I think is also really important because that's where you really learn what that like, abstraction is at the user level. And also, it could be a really good place to give your input if the feature is being designed in a way that doesn't really support the, you know, kind of quality of code and, like, separation that you would like. That's the part that I'm still working on and still learning how to do. But sometimes, you know, it's, like, really critical to the job to, like, be in that room and be like, these designs; what are some places that we could extract it at that level even? And kind of, like, separate things out from there rather than having to deal with it [laughs] deep in your codebase. JOËL: I think what I'm really kind of hearing and emphasizing in what you just said is the importance of not just writing code but being involved in the product and how that really enriches you because you know the problem domain. And that allows you to then write the code that you need at the different levels of the app to best model the situation you're working with. So, we've kind of gone through all the rules and talked about them. I'm curious, though, for you, are these rules that you follow in your code? How closely do you adhere to this set of rules? Is this still something that's relevant to you in 2023 as much as it was to the authors of that blog post in 2013? STEPHANIE: I have to say they're not ones that I have thought about on a daily basis, but after this conversation, maybe they will be. And I am kind of excited to maybe, like, bring this up to other people on my team and be like, "What do you think about these rules?" Just, like, revisiting them as a group or just, like, having that conversation. Because I think that's, you know, where I am most interested in is, like, is wondering how other people incorporate them into their work and hearing different opinions from the team. And I think there's a lot of, like, generative discussion that ultimately leads to better code as a result. JOËL: I think for myself, I'm not following the rules directly. But a lot of my code ends up approximating those rules anyway because of other principles that I follow. So, in practice, while my code doesn't strictly follow those rules, it does look pretty close to that anyway. STEPHANIE: I almost think this could be a great, you know, discussion for your team, too, like, if any listeners want to...not quite a book club but kind of an article club, if you will [laughs], and see how other people on your team feel about it. Because I think that's kind of where there is, like, a really sweet spot in terms of learning and development. JOËL: On that note, shall we wrap up? STEPHANIE: Let's wrap up. Show notes for this episode can be found at bikeshed.fm. JOËL: This show has been produced and edited by Mandy Moore. STEPHANIE: If you enjoyed listening, one really easy way to support the show is to leave us a quick rating or even a review in iTunes. It really helps other folks find the show. JOËL: If you have any feedback for this or any of our other episodes, you can reach us @_bikeshed, or you can reach me @joelquen on Twitter. STEPHANIE: Or reach both of us at hosts@bikeshed.fm via email. JOËL: Thanks so much for listening to The Bike Shed, and we'll see you next week. ALL: Byeeeeeee!!!!!!!! AD: Did you know thoughtbot has a referral program? If you introduce us to someone looking for a design or development partner, we will compensate you if they decide to work with us. More info on our website at tbot.io/referral. Or you can email us at referrals@thoughtbot.com with any questions.

Bailey and Jesse chat with Travis Haby 1507 alum and Staff Engineer at Guild. They discuss his Turing story, his roots in education, his background in physics, the Blakement, his job as the first engineer at Guild, watching engineering culture grow at Guild, hiring at Guild, the Climate Crisis, and some advice. If you or someone you know are code curious, we encourage you to attend a Turing Try Coding Event. You can register for a Try Coding class at turing.edu/try-coding.

Hoje o papo é sobre cargos! Nesta conversa, vamos falar sobre as tendências, os desafios e as responsabilidades que vêm com o avanço da carreira no cargo de engenharia. Vem ver quem acompanha a gente neste papo!

In this episode, Dave and Jamison answer these questions: Love the show, you guys have saved my bacon more times than I can count! I interviewed at an organization for a Senior Engineering role, but the interview went so well, they actually offered me the option to accept a Staff role! I definitely didn't feel ready for that, but I accepted as a way to stretch and challenge myself. The company has been through some internal churn and re-arranging for most of my time there, and I bounced between a lot of projects, which means I've now been at the company coming up on 2 years, but not really had the chance to grow into the role. Now, I've been here awhile, don't have a lot of excuses, and am bad at being a Staff Engineer. My biggest failing, is that I lack a bigger vision for our project, beyond just meeting customer needs for today. I'm not even sure how to start building that bigger vision! In my current project, this is especially apparent, because we do need to meet internal customer needs, but the end goal is a larger platform. We need features that inspire new avenues of work as well as enable current ones. How the heck do I even begin to start imagining what this bigger vision could be? Moreover, once I have that vision, how do I get buy in for that vision? My inability to do this kind of forward thinking has been a boat anchor around my ankles my entire career, and I'm lost as to where to even start. Help me guys, I love my job, but I fear I've become the embodiment of the Peter Principle. Help me chew my ankles off to save my career Listener Trevor asks, ‌ I work as a data scientist at a small company. I joined the company specifically because of the positive work environment. I do mostly software development and until recently have only received positive reviews. Recently we had a heated meeting with the CTO and CFO where we demonstrated that a customer's request wasn't feasible. The CTO challenged and expressed disbelief in our numbers which we had thoroughly analyzed and confirmed as accurate. I felt like their reaction was due to our results conflicting with our business needs. After that, my manager began pushing me to prioritize data science tasks. He attributed the outcome of the meeting to my lack of attention to detail, even though the results were accurate. He also said this would affect my next performance review. We reached a resolution when I apologized and committed to improvement. I've only received positive feedback since, but I still feel the assessment was unfairly based on such a brief meeting. Now I view the company and my manager differently. Without the positive work relationships with management and colleagues, I'm not sure what is keeping me here. Our tech stack is outdated, and there's reluctance to change practices. For example, we didn't have a CICD pipeline until only a few months ago. Additionally, the performance review and promotion schedules are nebulous and irregular. I'm uncertain about my next steps. Should I address the perceived unfairness of the meeting feedback? Or would it be better to start exploring other job opportunities?

I am joined today by Ryan Nel, Staff Engineer, and Joel Segerlind, Director of Engineer at Volvo Cars. We are going to dive into how they hired 300+ developers in a year. Come hang with us! Like what you hear? Connect with me - Website: ⁠solo.to/tdesseyn⁠ LinkedIn: Taylor Desseyn Tweet me: @tdesseyn Pics of the life, wife, daughter & dog: @tdesseyn