Podcasts about frontend masters

In this episode, Richard Feldman (creator of Roc, Elm educator, and Zed engineer) discusses AI's focus on "vibe coding" over high-quality tools, why functional programming's real value lies in ecosystems—not dogma—and how frustration with slow compilers led him to design the Roc programming language. He shares Zed's pragmatic use of AI for code "rough drafts," lessons learned from teaching Elm and Rust, and why prioritizing outcomes always beats out industry hype. He shares some Java war stories, JSX's early controversy, and why Zed's performance-first approach defies today's norms. Tune in for deep dives on language design, where he sees AI's potential, and the myth about using "boring" tech.Check out Richard's Frontend Masters courses here: https://frontendmasters.com/teachers/richard-feldmanFrontend Masters Online:Twitter: https://twitter.com/FrontendMastersLinkedIn: https://www.linkedin.com/company/frontend-masters/Facebook: https://www.facebook.com/FrontendMastersInstagram: https://instagram.com/FrontendMastersAbout Us:Advance your skills with in-depth, modern front-end engineering courses — our 150+ high-quality courses and 18 curated learning paths will guide you from mid-level to senior developer! https://frontendmasters.com/?utm_source=youtube&utm_medium=home_link&utm_campaign=podcastepisode24

In this episode of the Frontend Masters Podcast, host Marc Grabanski chats with Jon Kuperman, a seasoned developer, educator, and TC39 delegate. Jon shares insights into his journey from juggling enthusiast to JavaScript language contributor, his experiences at companies like Twitter, Brave, Adobe, and Bloomberg, and his passion for teaching and accessibility. He also dives into the complexities of evolving JavaScript, the challenges of browser development, and the future of reactive programming with signals. Tune in for a deep dive into the world of frontend development, open source, and the collaborative process behind shaping the future of JavaScript.Check out Jon's Frontend Masters courses here: https://frontendmasters.com/teachers/jon-kuperman/Frontend Masters Online:Twitter: https://twitter.com/FrontendMastersLinkedIn: https://www.linkedin.com/company/frontend-masters/Facebook: https://www.facebook.com/FrontendMastersInstagram: https://instagram.com/FrontendMastersAbout Us:Advance your skills with in-depth, modern front-end engineering courses — our 150+ high-quality courses and 18 curated learning paths will guide you from mid-level to senior developer! https://frontendmasters.com/?utm_source=youtube&utm_medium=home_link&utm_campaign=podcastepisode23

In this episode of The Frontend Masters Podcast, Kevin Powell, a CSS educator and YouTuber,  describes his transition from print design to web development before finding his niche in teaching CSS online. Kevin started his YouTube channel eight years ago as a creative outlet while teaching at a vocational school. He grew it from 100 initial subscribers to a full-time career through consistent weekly content focused exclusively on CSS and HTML. Throughout the podcast, Kevin shares insights on modern CSS features like container queries and view transitions while emphasizing the importance of understanding fundamentals before adopting frameworks like Tailwind. His success stems from deliberately maintaining a narrow focus on CSS despite pressure to cover other technologies, and his journey exemplifies how specializing in one area and maintaining consistency can lead to sustainable content creation. The interview concludes with Kevin reflecting on how he "accidentally" found his path through trying different careers and hobbies until finding what stuck. Check out Kevin's Frontend Masters courses here: https://frontendmasters.com/teachers/kevin-powell/ Frontend Masters Online: Twitter: https://twitter.com/FrontendMastersLinkedIn: https://www.linkedin.com/company/frontend-masters/ Facebook: https://www.facebook.com/FrontendMasters Instagram: https://instagram.com/FrontendMasters About Us: Advance your skills with in-depth, modern front-end engineering courses — our 150+ high-quality courses and 18 curated learning paths will guide you from mid-level to senior developer! https://frontendmasters.com/?utm_source=youtube&utm_medium=home_link&utm_campaign=podcastepisode22

On this Screaming in the Cloud Replay, Corey is joined by Emma Bostian, an Engineering Manager at Spotify in Stockholm. Emma is also an author, co-host of the Ladybug Podcast, and has a strong following on social media. She goes into the details on her podcast and the varied nature of her and her co-hosts, she also discusses her book Decoding the Technical Interview Process, in which she breaks down the seemingly esoteric nature of interviewing for these highly technical jobs—but her focus is on the frontend. She and Corey discuss the general banality of these interviews and the direction they can, and should, go in to improve. Emma also loves to teach, to add even more to her portfolio! She goes into the five w's of her work with LinkedIn Learning and Frontend Masters. Emma also has some excellent insights into her sizable Twitter presence. Tune in for Emma's variegated offerings!Show Highlights(0:00) Intro(0:58) The Duckbill Group sponsor read(1:31) Hosting the Ladybug Podcast and teaching online courses(3:13) Why Emma wrote Decoding the Technical Interview Process(7:01) Corey's qualms with how people interview in tech(12:03) Why Corey appreciates Emma's guidance on how to interview(14:50) Bizarre hiring practices that some interviewers use(18:20) Passion, work/life balance, and seeking out new employees(19:41) Turning side projects into revenue streams(22:23) Seeking out sponsors instead of monetizing your audience (26:06) The Duckbill Group sponsor read(26:49) Balancing customer service with piracy(29:35) Letting your online following become your resume(36:01) Where you can find more from EmmaAbout Emma BostianEmma Bostian is an Engineering Manager at Spotify in Stockholm. She is also a co-host of the Ladybug Podcast, author of Decoding The Technical Interview Process, and an instructor at LinkedIn Learning and Frontend Masters.LinksLadybug Podcast: https://www.ladybug.devLinkedIn Learning: https://www.linkedin.com/learning/instructors/emma-bostianFrontend Masters: https://frontendmasters.com/teachers/emma-bostian/Decoding the Technical Interview Process: https://technicalinterviews.devEmma's Twitter: https://twitter.com/emmabostianOriginal Episodehttps://www.lastweekinaws.com/podcast/screaming-in-the-cloud/changing-the-way-we-interview-with-emma-bostian/SponsorThe Duckbill Group: duckbillgroup.com

In this episode of The Frontend Masters Podcast, Todd Gardner, co-founder of TrackJS and RequestMetrics, discusses his journey from consultant to entrepreneur. He shares insights on bootstrapping SaaS products, competing against VC-backed companies, and the importance of charging customers for your product or service early. Todd delves into technical aspects of his products' stacks, including the use of .NET Core, Clickhouse, and HTMX. He offers advice on public speaking, teaching, and maintaining healthy co-founder relationships. The conversation covers web performance optimization, JavaScript error monitoring, and the challenges of balancing product development with marketing efforts. Todd also reflects on his career philosophy of continuous learning and adaptation in the fast-paced tech industry. Marc has captured his advice on startups in this article, originally an email to Todd in 2014: https://marcgrabanski.com/articles/your-advice-startups/ Check out Todd's Frontend Masters courses here: https://frontendmasters.com/teachers/todd-gardner/ Frontend Masters Online: Twitter: https://twitter.com/FrontendMasters LinkedIn: https://www.linkedin.com/company/frontend-masters/ Facebook: https://www.facebook.com/FrontendMasters Instagram: https://instagram.com/FrontendMasters About Us: Advance your skills with in-depth, modern front-end engineering courses — our 150+ high-quality courses and 18 curated learning paths will guide you from mid-level to senior developer! https://frontendmasters.com/?utm_source=spotify&utm_medium=home_link&utm_campaign=podcastepisode21

In this 20th episode of The Frontend Masters Podcast, Francesca Sadikin, a software engineer at Netflix, shares her journey from architecture to tech. She discusses her experience at a software engineering consulting firm, rapid career progression, and landing a role at Netflix. Sadikin offers insights on transitioning into tech, the benefits of software consulting for skill accumulation, and the challenges of working at a top-tier tech company. She also delves into her approach to teaching and public speaking, emphasizing the importance of practice and preparation. The conversation covers strategies for managing imposter syndrome, the value of autonomy in Netflix's work culture, and balancing career growth with personal life as a new parent. Check out Francesca's Frontend Masters courses here: https://frontendmasters.com/teachers/francesca-sadikin/ Frontend Masters Online: Twitter: https://twitter.com/FrontendMasters LinkedIn: https://www.linkedin.com/company/frontend-masters/ Facebook: https://www.facebook.com/FrontendMasters Instagram: https://instagram.com/FrontendMasters About Us: Advance your skills with in-depth, modern front-end engineering courses — our 150+ high-quality courses and 18 curated learning paths will guide you from mid-level to senior developer!  https://frontendmasters.com/?utm_source=youtube&utm_medium=home_link&utm_campaign=podcastepisode20

Elm pioneer Richard Feldman returns to explain why he made Roc, a direct descendant of Elm. He notes a distinct trade-off of choosing not to have persistent data structures. Later, he shares how his experience teaching Elm informed Roc's design. We even learn about the power of platforms.Thanks to our sponsor, Logistically. Email: elmtown@logisticallyinc.com.Music by Jesse Moore.Recording date: 2024.05.23GuestRichard FeldmanShow notes[00:00:20] Non-introductionRocSoftware Unscripted"Making Impossible States Impossible""Scaling Elm Apps"Elm in ActionElm courses on Frontend Masters[00:01:47] Motivations to make Roc[00:04:53] Back to the beginnings in 2018[00:15:25] How Roc compares to ElmAaron VonderHaar's elm-formatElm Style Guide"Bret Victor style reactive debugging" by Laszlo Pandy at Elm Workshop 2013 (YouTube)"Functional Semantics in Imperative Clothing"[00:25:18] Minimizing the erosion of simplicity (governance models)"BDFN" on roc-lang.orgEpisode "Programming and Industrial Design with Greg Wilson" of Software Unscripted[00:31:36] How teaching Elm informed Roc's design[00:40:34] Design processEpisode "The Roc Programming Language with Richard Feldman" of Software Unscripted[00:45:04] Working at Zed IndustriesZed[00:50:28] Platforms[00:58:03] PicksRichard's picksPerformance-Aware Programming Series by Casey MuratoriSoftware You Can Love (SYCL) Milan 2024 playlist (YouTube)"Hybrid-Level Programming" by Richard Feldman at SYCL Milan 2024 (YouTube)ReliqaJared's picksUmphrey's McGeeBret Victor

In this episode, Kadi Kraman, a software developer at Expo, discusses her journey from scientific programming to React Native development. She shares insights on her experiences at companies like Formidable and her work on projects such as the Puma app. Kadi delves into the evolution of Expo, explaining how it has addressed previous limitations and become the recommended framework for React Native. She explores the concept of React Native frameworks, the benefits of Expo Go, and the introduction of development builds. The conversation also touches on emerging trends in React Native, including React Strictum and efforts to align React Native more closely with web standards. Finally, Kadi offers advice on getting into tech speaking and teaching, and reflects on the importance of tackling challenges and continuous learning in software development. Check out Kadi's Frontend Masters courses here: https://frontendmasters.com/teachers/kadi-kraman/ Frontend Masters Online: Twitter: https://twitter.com/FrontendMasters LinkedIn: https://www.linkedin.com/company/frontend-masters/ Facebook: https://www.facebook.com/FrontendMasters Instagram: https://instagram.com/FrontendMasters About Us: Advance your skills with in-depth, modern front-end engineering courses — our 150+ high-quality courses and 18 curated learning paths will guide you from mid-level to senior developer! https://frontendmasters.com/?utm_source=youtube&utm_medium=home_link&utm_campaign=podcastepisode19

In this episode, Maximiliano Firtman discusses his journey as a web and mobile developer spanning over 20 years. He shares insights on the evolution of mobile web development, from early WAP and J2ME applications to modern Progressive Web Apps (PWAs). Firtman reflects on his experiences teaching, speaking at conferences, and consulting internationally from his base in Buenos Aires. He explores the changing landscape of web technologies, the current state of PWAs, and the industry's shift in terminology from "PWAs" to "web apps." Firtman also delves into the importance of understanding vanilla JavaScript in today's development ecosystem and offers advice for aspiring speakers and teachers in the tech industry.Check out Maximiliano's Frontend Masters courses here: https://frontendmasters.com/teachers/firt/Find Frontend Masters Online:Twitter: https://twitter.com/FrontendMastersLinkedIn: https://www.linkedin.com/company/frontend-masters/Facebook: https://www.facebook.com/FrontendMastersInstagram: https://instagram.com/FrontendMastersAbout Us:Advance your skills with in-depth, modern front-end engineering courses — our 150+ high-quality courses and 18 curated learning paths will guide you from mid-level to senior developer! https://frontendmasters.com/?utm_source=youtube&utm_medium=home_link&utm_campaign=podcastepisode18

In this episode, Evgenii Ray discusses his journey from a remote, economically challenged region to becoming a software engineer at Meta and a Frontend Masters instructor. He shares insights on transitioning from backend to frontend development, the importance of persistence in learning, and his experience creating educational content on YouTube. Ray emphasizes the value of internships, studying abroad, and continuous learning in advancing one's tech career. He also touches on his work at JetBrains and his current role at Meta, his preparation for technical interviews, and his passion for teaching and sharing knowledge with the developer community. The conversation covers topics such as system design for frontend, the benefits of teaching as a learning tool, and the challenges of overcoming significant cultural and geographic barriers for career growth.Check out Evgenii's Frontend Masters courses here: https://frontendmasters.com/teachers/evgenii-ray/Find Frontend Masters Online:Twitter: https://twitter.com/FrontendMastersLinkedIn: https://www.linkedin.com/company/frontend-masters/Facebook: https://www.facebook.com/FrontendMastersInstagram: https://instagram.com/FrontendMastersAbout Us:Advance your skills with in-depth, modern front-end engineering courses — our 150+ high-quality courses and 18 curated learning paths will guide you from mid-level to senior developer! https://frontendmasters.com/?utm_source=spotify&utm_medium=home_link&utm_campaign=podcastepisode17

In this episode, Marc sits down with Charlie Gerard as she shares her cutting-edge experiments, including hacking a car using JavaScript, tracking live data from airplanes, and controlling interfaces with brain sensors. Charlie also discusses using machine learning with TensorFlow.js, her creative projects during the pandemic like detecting running movements to play videos, and her journey from marketing to coding. This episode offers deep insights into the practical applications of JavaScript and the importance of mentorship in a tech career.Check out Charlie's Frontend Masters courses here: https://frontendmasters.com/teachers/charlie-gerard/Find Frontend Masters Online:Twitter: https://twitter.com/FrontendMastersLinkedIn: https://www.linkedin.com/company/frontend-masters/Facebook: https://www.facebook.com/FrontendMastersInstagram: https://instagram.com/FrontendMastersAbout Us:Advance your skills with in-depth, modern front-end engineering courses — our 150+ high-quality courses and 18 curated learning paths will guide you from mid-level to senior developer! https://frontendmasters.com/?utm_source=youtube&utm_medium=home_link&utm_campaign=podcastepisode16

In this episode, Marc Grabanski speaks with Paul Boag, a veteran web designer with over 20 years of experience. We talk about the early days of podcasting with the Boagworld podcast. Marc explores Paul's transition from traditional web design to modern practices, focusing on CSS adoption and the impact of web standards. Paul also shares insights from his shift away from agency life towards a more flexible, travel-oriented work style. The discussion covers technical evolutions in web design, the critical importance of accessibility, and practical challenges faced by web professionals today. Check out Paul's Frontend Masters courses here:  https://frontendmasters.com/teachers/paul-boag/ Find Frontend Masters Online: Twitter: https://twitter.com/FrontendMasters LinkedIn: https://www.linkedin.com/company/frontend-masters/ Facebook: https://www.facebook.com/FrontendMastersInstagram: https://instagram.com/FrontendMasters About Us: Advance your skills with in-depth, modern front-end engineering courses — our 150+ high-quality courses and 18 curated learning paths will guide you from mid-level to senior developer! https://frontendmasters.com/?utm_source=youtube&utm_medium=home_link&utm_campaign=podcastepisode15

In this episode, we talk with Melkey, a popular Twitch streamer (and Twitch employee) with a unique background in robotics, machine learning, and a wide range of sports. We talk about the technical challenges of machine learning, wrestling to rugby, his first job fixing go-karts, and eventually getting into software dev and landing at Twitch. Expect tech and career advice mixed with lighthearted banter as Melkey shares his experiences and insights, significantly impacting tech and streaming content.  Check out Melkey's Frontend Masters courses here: https://frontendmasters.com/teachers/melkey/ Find Frontend Masters Online: Twitter: https://twitter.com/FrontendMasters LinkedIn: https://www.linkedin.com/company/frontend-masters/ Facebook: https://www.facebook.com/FrontendMasters Instagram: https://instagram.com/FrontendMasters About Us: Advance your skills with in-depth, modern front-end engineering courses — our 150+ high-quality courses and 18 curated learning paths will guide you from mid-level to senior developer! https://frontendmasters.com/?utm_source=youtube&utm_medium=home_link&utm_campaign=podcastepisode14

(Video Podcast available on Spotify and Youtube) In this episode Marcy Sutton Todd shares her deep dive into web accessibility, emphasizing the critical role of foundational HTML and CSS, and the nuanced application of ARIA for enhancing web user experiences. With her background in working on the Axe accessibility tool, Sutton Todd underscores the importance of screen reader testing and leveraging accessibility tools to identify and rectify common web accessibility issues. She reflects on her journey into accessibility, marked by a pivotal moment at the CSUN conference, which solidified her commitment to advocating for digital access rights. The episode also explores Sutton Todd's creative side, revealing how her visual skills and passion for photography have influenced her web development career. She discusses the evolving job market, highlighting how expertise in accessibility can distinguish developers and the strategic importance of contributing to open source projects to gain visibility and experience. Sutton Todd's narrative is a blend of technical guidance, career advice, and personal insights, offering listeners a comprehensive view of the importance of accessibility in web development and the potential paths for professional growth in this field. Check out Marcy's Frontend Master's courses here: https://frontendmasters.com/teachers/marcy-sutton/ Find Frontend Masters Online: Twitter: ⁠https://twitter.com/FrontendMasters⁠  LinkedIn: ⁠https://www.linkedin.com/company/frontend-masters/⁠  Facebook: ⁠https://www.facebook.com/FrontendMasters⁠  Instagram: ⁠https://instagram.com/FrontendMasters⁠ About Us: Advance your skills with in-depth, modern front-end engineering courses — our 150+ high-quality courses and 18 curated learning paths will guide you from mid-level to senior developer! ⁠https://frontendmasters.com/

(Video Podcast available on Spotify and Youtube) In Episode 12, Lydia Hallie takes us through her tech journey, from early coding experiments to becoming a prominent figure in the developer community as a Staff Developer Relations Engineer for Vercel. Lydia shares her unique approach to tech talks, emphasizing authenticity and leveraging visual storytelling to make complex concepts accessible. She discusses the challenges of public speaking, her collaboration with Addy Osmani on patterns.dev, and her strategies for engaging with her audience beyond conventional presentation styles. Lydia also opens up about her personal struggles with burnout, highlighting the critical need for balance between work intensity and self-care. Her story is not just about her technical achievements but also about her insights into maintaining passion and productivity in tech. Lydia's reflections offer valuable lessons on the importance of self-awareness and the courage to prioritize well-being alongside professional growth. Check out Lydia Hallie's Frontend Master's courses here: https://frontendmasters.com/teachers/lydia-hallie/ Find Frontend Masters Online: Twitter: ⁠https://twitter.com/FrontendMasters⁠ LinkedIn: ⁠https://www.linkedin.com/company/frontend-masters/⁠ Facebook: ⁠https://www.facebook.com/FrontendMasters⁠ Instagram: ⁠https://instagram.com/FrontendMasters⁠ About Us: Advance your skills with in-depth, modern front-end engineering courses — our 150+ high-quality courses and 18 curated learning paths will guide you from mid-level to senior developer! ⁠https://frontendmasters.com/

Episode Description:(Video Podcast available on Spotify and Youtube) Episode 11 of the Frontend Masters Podcast welcomes Anjana Vakil, a distinctive voice in software development. In this engaging conversation with Marc, they delve into the philosophy and linguistics behind coding, exploring its purpose and broader implications in computer science. Anjana takes us on a journey from her beginnings in philosophy and English teaching to her current role in the tech world, emphasizing the profound connection between human communication and software. She delves into the essence of functional programming and its power to model complex ideas simply, while also exploring the social implications of technology. This episode is a thought-provoking exploration of how coding transcends mere syntax, touching on societal issues and the importance of sharing knowledge. Anjana's reflections inspire listeners to consider not just the code they write, but also the impact it has on the world and the people around them.Check out Anjana Vakil's Frontend Master's courses here: https://frontendmasters.com/teachers/anjana-vakil/ Find Frontend Masters Online: Twitter: ⁠https://twitter.com/FrontendMasters⁠  LinkedIn: ⁠https://www.linkedin.com/company/frontend-masters/⁠  Facebook: https://www.facebook.com/FrontendMasters⁠  Instagram: ⁠https://instagram.com/FrontendMasters⁠ About Us: Advance your skills with in-depth, modern front-end engineering courses — our 150+ high-quality courses and 18 curated learning paths will guide you from mid-level to senior developer! ⁠https://frontendmasters.com/

(Video Podcast available on Spotify and Youtube)In Episode 10, Mark Techson shares his inspiring journey from an early fascination with coding to becoming an influential figure in Google's Angular team. Mark shares how he learned programming at a public school in Chicago. In college, he was interested in game development but eventually got a web development job. He started teaching at a boot camp on top of his day job to pay for unexpected family medical expenses, which opened the door to teaching for Harvard's extension school. He shares his gripping story of interviewing at Google and landing his job on the Angular team for the last 3 1/2 years. All along the way, he emphasizes service to others and building a positive community. This is an inspiring episode – we can all learn so much from Mark's journey! Check out Mark Techson's Frontend Master's courses here: https://frontendmasters.com/teachers/mark-techson/ Find Frontend Masters Online: Twitter: ⁠https://twitter.com/FrontendMasters⁠  LinkedIn: ⁠https://www.linkedin.com/company/frontend-masters/⁠  Facebook: ⁠https://www.facebook.com/FrontendMasters⁠ Instagram: ⁠https://instagram.com/FrontendMasters⁠ About Us: Advance your skills with in-depth, modern front-end engineering courses — our 150+ high-quality courses and 18 curated learning paths will guide you from mid-level to senior developer! ⁠https://frontendmasters.com/

(Video Podcast available on Spotify and Youtube) Episode 9 of the Frontend Masters Podcast features ThePrimeagen, Netflix engineer and NeoVim enthusiast (by the way). In this episode he discusses the challenges of developer productivity, his experience with various programming roles, and his passion for Vim, and tooling. ThePrimeagen also delves into balancing work with personal life, the intricacies of content creation, and his excitement for future projects, including live reacting to tech conferences. Additionally, ThePrimeagen reflects on his journey, offering a rare glimpse into the life lessons learned along the way. Check out ThePrimeagen's Frontend Master's courses here: https://frontendmasters.com/teachers/the-primeagen/ Find Frontend Masters Online: Twitter: ⁠https://twitter.com/FrontendMasters⁠  LinkedIn: ⁠https://www.linkedin.com/company/frontend-masters/⁠  Facebook: ⁠https://www.facebook.com/FrontendMasters⁠ Instagram: ⁠https://instagram.com/FrontendMasters⁠ About Us: Advance your skills with in-depth, modern front-end engineering courses — our 200+ high-quality courses and 18 curated learning paths will guide you from mid-level to senior developer! ⁠https://frontendmasters.com/

(Video Podcast available on Spotify and Youtube)In this 8th episode of "The Frontend Masters Podcast," Marc interviews Jem Young, a seasoned software engineer and engineering manager at Netflix. We talk about the evolution of frontend development, teaching technical skills, and the impact of emerging technologies like AI and quantum computing on our industry. Jem shares his journey from organizing college LAN parties to his tenure at Netflix, emphasizing the importance of public speaking and communication in tech roles. This episode will give you insights on navigating your career and enhancing your skills. Check out Jem Young's Frontend Master's courses here: https://frontendmasters.com/teachers/jem-young/ Check out Jem Young's Frontend Master's courses here: https://frontendmasters.com/teachers/jem-young/ Find Frontend Masters Online: Twitter: ⁠https://twitter.com/FrontendMasters⁠ LinkedIn: ⁠https://www.linkedin.com/company/frontend-masters/⁠ Facebook: ⁠https://www.facebook.com/FrontendMasters⁠ Instagram: ⁠https://instagram.com/FrontendMasters⁠ About Us: Advance your skills with in-depth, modern front-end engineering courses — our 150+ high-quality courses and 18 curated learning paths will guide you from mid-level to senior developer! ⁠https://frontendmasters.com/

There are many options to learn about software development and how to code. In this episode, we are joined by the CEO of Frontend Masters, Marc Grabanski to get his insights into online learning and what to expect in the future. Items mentioned in the episode: Frontend Masters, Going phoneless Guests: Marc Gabanski - @1Marc Panelists: Ryan Burgess - @burgessdryan Jem Young - @JemYoung Picks: Marc Gabanski - Askinosie chocolate Marc Gabanski - Not having a phone Ryan Burgess - Glass straws Ryan Burgess - Sunlighten Infrared Sauna Jem Young - Beef coast jerky Jem Young - Anti-pick: Rebel Moon Episode transcript: https://www.frontendhappyhour.com/episodes/online-learning-on-the-rocks

Episode Description:(Video Podcast available on Spotify and Youtube)In this 7th episode of The Frontend Masters Podcast, host Marc Grabanski chats with Mike North, Developer Platform Tech Lead at Stripe, in a deep dive into the evolution of web development. The conversation traverses Mike's journey from tinkering with TI-83 calculators to mastering frontend development and beyond. They discuss the intricacies of working with large-scale projects, the transition from frontend to full-stack development, and the importance of TypeScript in modern web development. Mike also shares his insights on developing effective APIs and his approach to teaching and mentoring in the tech space. This episode is a treasure trove for developers looking to deepen their understanding of frontend technologies and career progression in software engineering. Check out Mike North's Frontend Master's courses here: https://frontendmasters.com/teachers/mike-north/Find Frontend Masters Online: Twitter: ⁠https://twitter.com/FrontendMasters⁠ LinkedIn: ⁠https://www.linkedin.com/company/frontend-masters/⁠ Facebook: ⁠https://www.facebook.com/FrontendMasters⁠ Instagram: ⁠https://instagram.com/FrontendMasters⁠About Us: Advance your skills with in-depth, modern front-end engineering courses — our 150+ high-quality courses and 18 curated learning paths will guide you from mid-level to senior developer! ⁠https://frontendmasters.com/

Kent C. Dodds, a JavaScript engineer and teacher known for Epic Web Dev and the Remix web framework, reflects on his journey in tech, including his tenure at PayPal and his transition to full-time teaching. Kent's passion for teaching is a constant theme throughout. He transitioned from corporate roles to full-time education, capitalizing on his ability to explain complex concepts in an accessible manner. This transition was marked by the creation of successful online courses like "Testing JavaScript and Epic React," which have significantly influenced the web development community. An interesting aspect of Kent's career is his involvement with Remix, including his decision to leave Shopify (which acquired Remix) to return to teaching, which led to the development of his latest project, Epic Web Dev, an extensive and innovative web development course. This interview provides a comprehensive view of Kent C. Dodds's life and career, showcasing his professional achievements in web development and teaching, his personal life as a family man, and his unique upbringing in a large family. Epic Web (https://www.epicweb.dev/) Remix (https://remix.run/) Follow Kent C. Dodds on LinkedIn (https://www.linkedin.com/in/kentcdodds/) or X (https://twitter.com/kentcdodds). Visit his website at kentcdodds.com (https://kentcdodds.com/). Follow thoughtbot on X (https://twitter.com/thoughtbot) or LinkedIn (https://www.linkedin.com/company/150727/). Become a Sponsor (https://thoughtbot.com/sponsorship) of Giant Robots! Transcript: WILL: This is the Giant Robots Smashing Into Other Giant Robots podcast, where we explore the design, development, and business of great products. I'm your host, Will Larry. And with me today is Kent C. Dodds. Kent is a JavaScript engineer and teacher. He has recently released a massive workshop called epicweb.dev. And he is the father of four kids. Kent, thank you for joining me. KENT: Thank you so much for having me. It's an honor to be here. WILL: Yeah. And it's an honor for me to have you. I am a huge fan. I think you're the one that taught me how to write tests and the importance of it. So, I'm excited to talk to you and just pick your brain and learn more about you. KENT: Oh, thank you. WILL: Yeah. So, I just want to start off just: who is Kent? What do you like to do? Tell us about your family, your hobbies, and things like that. KENT: Yeah, sure. So, you mentioned I'm the father of four kids. That is true. We are actually expecting our fifth child any day now. So, we are really excited to have our growing family. And when I'm not developing software or material for people to learn how to develop software, I'm spending time with my family. I do have some other hobbies and things, but I try to share those with my family as much as I can. So, it's starting to snow around here in Utah. And so, the mountains are starting to get white, and I look forward to going up there with my family to go skiing and snowboarding this season. During the summertime, I spend a lot of time on my one-wheel just riding around town and bring my kids with me when I can to ride bikes and stuff, too. So, that's sort of the personal side of my life. And then, professionally, I have been in this industry developing for the web professionally for over a decade. Yeah, web development has just worked out super well for me. I kind of focused in on JavaScript primarily. And when I graduated with a master's degree in Information Systems at Brigham Young University, I started working in the industry. I bounced around to a couple of different companies, most of them you don't know, but you'd probably be familiar with PayPal. I was there for a couple of years and then decided to go full-time on teaching, which I had been doing as, like, a part-time thing, or, like, on the side all those years. And yeah, when teaching was able to sustain my family's needs, then I just switched full-time. So, that was a couple of years ago that I did that. I think like, 2018 is when I did that. I took a 10-month break to help Remix get off the ground, the Remix web framework. They got acquired by Shopify. And so, I went back to full-time teaching, not that I don't like Shopify, but I felt like my work was done, and I could go back to teaching. So, that's what I'm doing now, full-time teacher. WILL: Wow. Yes, I definitely have questions around that. KENT: [laughs] Okay. WILL: So many. But I want to start back...you were saying you have four kids. What are their ages? KENT: Yeah, my oldest is 11, youngest right now is 6, and then we'll have our fifth one. So, all four of the kids are pretty close in age. And then my wife and I thought we were done. And then last December, we kind of decided, you know what? I don't think we're done. I kind of think we want to do another. So, here we go. We've got a larger gap between my youngest and the next child than we have between my oldest and the youngest child. WILL: [chuckles] KENT: So, we're, like, starting a new family, or [laughs] something. WILL: Yeah [laughs]. I just want to congratulate you on your fifth child. That's amazing. KENT: Thank you. WILL: Yeah. How are you feeling about that gap? KENT: Yeah, we were pretty intentional about having our kids close together because when you do that, they have built-in friends that are always around. And as they grow older, you can do the same sorts of things with them. So, like, earlier this year, we went to Disneyland, and they all had a great time. They're all at the good age for that. And so, they actually will remember things and everything. Yeah, we were pretty certain that four is a good number for us and everything. But yeah, we just started getting this nagging feeling we wanted another one. So, like, the fact that there's a big gap was definitely not in the plan. But I know a lot of people have big gaps in their families, and it's just fine. So, we're going to be okay; just it's going to change the dynamic and change some plans for us. But we're just super excited to have this next one. WILL: I totally understand what you mean by having them close together. So, I have three little ones, and my oldest and my youngest share the same exact birthday, so they're exactly three years apart. KENT: Oh, wow. Yeah, that's actually...that's fun. My current youngest and his next oldest brother are exactly two years apart. They share the same birthday, too [laughs]. WILL: Wow. You're the first one I've heard that their kids share a birthday. KENT: Yeah, I've got a sister who shares a birthday with her son. And I think we've got a couple of birthdays that are shared, but I also have 11 brothers and sisters [laughs]. And so, I have got a big family, lots of opportunity for shared birthdays in my family. WILL: Yeah, I was actually going to ask you about that. How was it? I think you're the 11th. So, you're the youngest of 11? KENT: I'm the second youngest. So, there are 12 of us total. I'm number 11. WILL: Okay, how was that growing up with that many siblings? KENT: I loved it. Being one of the youngest I didn't really...my experience was very different from my older siblings. Where my older siblings probably ended up doing a fair bit of babysitting and helping around the house in that way, I was the one being babysat. And so, like, by the time I got to be, like, a preteen, or whatever, lots of my siblings had already moved out. I was already an uncle by the time I was six. I vaguely remember all 12 of us being together, but most of my growing up was just every other year; I'd have another sibling move out of the house, which was kind of sad. But they'd always come back and visit. And now I just have an awesome relationship with every one of my family members. And I have something, like, 55 nieces and nephews or more. Yeah, getting all of us together every couple of years for reunions is really a special experience. It's a lot of fun. WILL: Yeah. My mom, she had 12 brothers and sisters. KENT: Whoa. WILL: And I honestly miss it because we used to get together all the time. I used to live a lot closer. Most of them are in Louisiana or around that area, and now I'm in South Florida, so I don't get to see them as often. But yeah, I used to love getting together. I had so many cousins, and we got in so much trouble...and it was -- KENT: [laughs] WILL: We loved it [laughs]. KENT: Yeah, that's wonderful. I love that. WILL: Yeah. Well, I want to start here, like, how did you get your start? Because I know...I was doing some research, and I saw that, at one point, you were an AV tech. You were a computer technician. You even did maintenance. Like, what was the early start of your career like, and how did you get into web dev? KENT: I've always been very interested in computers, my interest was largely video games. So, when I was younger, I had a friend who was a computer programmer or, like, would program stuff. We had visions of...I don't know if you're familiar with RuneScape, but it's this game that he used to play, and I would play a little bit. It was just a massive online multiplayer game. And so, we had visions of building one of those and having it just running in the background, making us money, as if that's how that works [laughter]. But he tried to teach me programming, and I just could not get it at all. And so I realized at some point that playing video games all the time wasn't the most productive use of my time on computers, and if I wanted my parents to allow me to be on computers, I needed to demonstrate that I could be productive in learning, and making things, and stuff. So, I started blogging and making videos and just, like, music videos. My friend, who was the programmer, he was into anime, or anime, as people incorrectly pronounce it. And [laughs] there was this website called amv.com or .org or something. It's Anime Music Videos. And so, we would watch these music videos. And I'd say, "I want to make a music video with Naruto." And so, I would make a bunch of music videos from the Naruto videos I downloaded, and that was a lot of fun. I also ran around with a camera to do that. And then, with the blog, I wrote a blog about Google and the stuff that Google was, like, doing because I just thought it was a fascinating company. I always wanted to work at Google. In the process of, like, writing the blog, I got exposed to CSS and HTML, but I really didn't do a whole lot of programming. I also did a little bit of Google Docs. Spreadsheets had some JavaScript macros-type things that you could do. So, I did a little bit of that, but I never really got too far into programming. Then I go to college, I'm thinking, you know what? I think I want to be a video editor. I really enjoy that. And so, my brother, who at the time was working at Micron, he did quality assurance on the memory they were making. So, he would build test automation, software and hardware for testing the memory they build. And so, he recommended that I go into electrical engineering. Because what he would say is, "If you understand computers at that foundational level, you can do anything with computers." And I'd say, "Well, I like computers. And if I go into video editing, I'm going to need to understand computers, too. So yeah, sure, let's let's do that." I was also kind of interested in 3D animation and stuff like that, too. Like, I wasn't very good at it, but I was kind of interested in that, too. So, I thought, like, having a really good foundation on computers would be a good thing for me. Well, I was only at school for a semester when I took a break to go on a mission for my church [inaudible 09:42] mission. And when I got back and started getting back into things, I took a math refresher course. That was, like, a half a credit. It wasn't really a big thing, but I did terrible in it. I did so bad. And it was about that time that I realized, you know what? I've been thinking my whole life that I'm good at math. And just thinking back, I have no idea why or any justification for why I thought I was good at math because in high school, I always struggled with it. I spent so much time with it. And in fact, my senior year, I somehow ended up with a free period of nothing else to do. I don't know how this happened. But, I used that free period to go to an extra edition of my calculus class. So, I was going to twice as much calculus working, like, crazy hard and thinking that I was good at this, and I superduper was not [laughter]. And so, after getting back from my mission and taking that refresher course, I was like, you know what? Math is a really important part of engineering, and I'm not good at it at all, obviously. And so, I've got to pivot to something else. Well, before my mission, as part of the engineering major, you needed to take some programming classes. So, there was a Java programming class that I took and a computer systems class that included a lot of programming. The computer systems was very low level, so we were doing zeros and ones. And I wrote a program in zeros and ones. All that it did was it would take input from the keyboard, and then spit that back out to you as output. That was what it did. But still, you know, many lines of zeros and ones and just, like, still, I can't believe I did that [laughter]. And then we upgraded from that to Assembly, and what a godsend that was [laughs], how wonderful Assembly was after working in machine code. But then we upgraded from that to C, and that's as far as that class went. And then, yeah, my Java class, we did a bunch of stuff. And I just remember thinking or really struggling to find any practicality to what we were doing. Like, in the Java class, we were implementing the link to list data structure. And I was like, I do not care about this. This does not make any sense. Why should I care? We were doing these transistor diagrams in the computer systems class. And why do I care about that? I do not care about this at all. Like, this is not an interesting thing for me. So, I was convinced computer programming was definitely not what I wanted to do. So, when I'm switching from electrical engineering, I'm thinking, well, what do I do? And my dad convinced me to try accounting. That was his profession. He was a certified public accountant. And so, I said, "Okay, I'll try that." I liked the first class, and so I switched my major to go into the business school for accounting. I needed to take the next accounting class, and I hated that so much. It was just dull and boring. And I'm so glad that I got out of that because [laughs] I can't imagine doing anything like that. WILL: [laughs] KENT: But as part of switching over to business school, I discovered information systems. What's really cool about that is that we were doing Excel spreadsheets and building web pages. But it was all, like, with a practical application of business and, like, solving business problems. And then, I was like, oh, okay, so I can do stuff with computers in a practical setting, and that's what got me really interested. So, I switched, finally, to information systems–made it into that program. And I was still not convinced I wanted to do programming. I just wanted to work with computers. What ended up happening is the same time I got into the information systems program, I got married to my wife, and then I got this part-time job at a company called the More Good Foundation. It's a non-profit organization. And one of my jobs was to rip DVDs and upload those videos to YouTube, and then also download videos from one site and upload those to YouTube as well. And so, I was doing a lot of stuff with YouTube and video stuff. And as part of my information systems class, I was taking another Java class. At that same time, I was like, you know, what I'm doing at work is super boring. Like, can you imagine your job is to put in a [inaudible 13:45] and then click a couple of buttons? And, like, it was so boring and error-prone, too. Like, okay, now I've got to type this out and, you know, I got to make sure it's the same, try and copy-paste as much as I can. And it was not fun. And so, I thought, well, I'm pretty sure there are pieces of this that I could automate. And so, with the knowledge that I was getting in my information systems programming class, that was another Java class, I decided to write a program that automated a bunch of my stuff. And so, I asked my boss, like, "Can I automate this with writing software?" And I'm so glad that they said I could. WILL: [laughs] KENT: Because by the end of it, I had built software that allowed me to do way more than I ever could have before. I ended up uploading thousands of videos to their YouTube channels, which would have taken years to do. And they ended up actually being so happy with me. They had me present to the board of directors when they were asking for more money [laughs] and stuff. And it was really awesome. But still, I was not interested in being a programmer. Programming, to me, was just a means to an end. WILL: Oh, wow. KENT: Yeah, I guess there was just something in me that was like, I am not a programmer. So, anyway, further into the program of information systems, I interned as a business intelligence engineer over that next summer, and I ended up staying on there. And while I was supposed to be a business intelligence engineer, I did learn a lot about SQL, and star schema, and denormalized databases to optimize for read speed and everything. I learned a lot about that. But I just kept finding myself in positions where I would use my programming experience to automate things that were problematic for us in the business realm. And this was all still Java. It was there that I finally realized, you know what? I think I actually do want to be a programmer. I actually really do enjoy this. And I like that it's practical, and it makes sense for me, so… WILL: What year was that? KENT: That would have been 2012. Then I got a new job where my job was actually to be a programmer at a company called Domo, where they do business intelligence, actually. So, it got my foot in the door a little bit since I was a business intelligence engineer already. I got hired on, actually, as a QA engineer doing automated testing, but I never really got into that. And they shifted me over pretty quick into helping with the web app. And that is when I discovered JavaScript, and the whole, like, everything flooded out from there. I was like, wow, I thought I liked programming, but I had no idea how fun it could be. Because I felt like the chains had been broken. I no longer have to write Java. I can write JavaScript, and this was just so much better. WILL: [laughs] KENT: And so, yeah, I was there for a year and a half before I finally graduated. And I took a little break to work at USAA for a summer internship. And when I came back, I had another year and then converted to full-time. And so, yeah, there's my more detail than you were probably looking for, story of how I got into programming [laughs]. WILL: No, I actually love it because like I said, I've used your software, your teachings, all that. And it's amazing to hear the story of how you got there. Because I feel like a lot of times, we just see the end result, but we don't know the struggle that you went through of even trying to find your way through what your purpose was, what you're trying to do. Because, at one point, you said you were trying to do accounting, then you were trying to do something else. So, it's amazing to see, like, when it clicked for you when you got into JavaScript, so that's amazing. KENT: Yeah, it is kind of funny to think, like, some people have the story of, like, I knew I wanted to be a programmer from the very beginning, and it's just kind of funny for me to think back and, like, I was pretty certain I didn't want to be a programmer. WILL: [laughs] KENT: Like, not only did I, like, lots of people will say, "I never really thought about it, and then I saw it, and it was great." But I had thought about it. And I saw it, and I thought it was awful [laughter]. And so, yeah, I'm really glad that it worked out the way it did, though, because programming has just been a really fun thing. Like, I feel so blessed to be doing something that I actually enjoy doing. Like so many of our ancestors, they would go to work because they cared about their family and they just wanted to feed their family. I'm so grateful to them for doing that. I am so lucky that I get to go to work to take care of my family, but also, I just love doing it. WILL: Yeah, I feel the same way, so yeah, totally agree. After you found out about JavaScript, when did you figure out that you want to teach JavaScript? What was that transition like? KENT: I've been teaching for my whole life. It's ingrained in my religion. Even as a kid, you know, I'd prepare a talk, a five-minute talk, and stand up in front of 30 of my peers. And even when you're an early teenager, you get into speaking in front of the entire congregation. It took a while before I got good enough at something, enough hubris to think that people would care about what I have to say -- WILL: [laughs] KENT: Outside of my religion where, like, they're sitting there, and I've been asked to speak, and so they're going to listen to me. And so, when I started getting pretty good at programming, I decided, hey, I want to teach this stuff that I'm learning. And so, when I was still at school and working at Domo, the business intelligence company, one of our co-workers, Dave Geddes, he put together a workshop to teach AngularJS because we were migrating from Backbone to Angular. And I asked him if I could use his workshop material to teach my classmates. This was, like, soon after ng-conf, the first ng-conf, which my co-workers at Domo actually put on. So, I wasn't involved in the organization, but I was very much present when it was being organized. I attended there and developed a relationship with Firebase with the people there. I was actually...they had a developer evangelist program, which they called Torchbearers or something. And actually, that was my idea to call them Torchbearers. I think they wanted to call us torches, and I'm like, that just doesn't make sense. WILL: [laughs] KENT: I developed a relationship with them. And I asked them, "Hey, I want to teach my classmates AngularJS. Would you be interested in sponsoring some pizza and stuff?" And they said, "Yeah, we'll send you stickers, and hot sauce, and [laughs] a bunch of..." Like, they sent us, like, headphones [laughs] and stuff. So, I was like, sweet. I taught my classmates AngularJS in a workshop, brought a bunch of pizza, and it was, you know, just an extracurricular thing. And actually, the recording is still on my YouTube channel, so if you want to go look at one of my early YouTube videos. I was very into publishing video online. So, if you are diligent, you'll be able to find some of my very early [laughter] videos from my teenage years. But anyway, so, yes, I've been teaching since the very beginning. As soon as I graduated from college, I started speaking at meetups. I'd never been to a meetup before, and I just saw, oh, they want a speaker. I can talk about something. WILL: Wow. KENT: And not realizing that, like, meetups are literally always looking for speakers. This wasn't some special occasion. WILL: [laughs] KENT: And one of the meetups I spoke at was recorded and put on YouTube. And the guy who started Egghead io, John Lindquist, he is local here in Utah. And he saw that I spoke at that meetup, but he wasn't able to attend. So, he watched the recording, and he thought it was pretty good. He thought I would do a good job turning that into a video course. And that first video course paid my mortgage. WILL: Wow. KENT: And I was blown away. This thing that I had been doing just kind of for fun speaking at meetups, and I realized, oh, I can actually, like, make some legit good money out of this. From there, I just started making more courses on the side after I put the kids to bed. My wife is like, "Hey, I love you, but I want you to stay away for now because I've just been with these tiny babies all day. WILL: [laughs] KENT: And I just need some alone time." WILL: Yes. KENT: And so, I was like, okay. WILL: [laughs] KENT: I'll just go and work on some courses. And so, I spent a lot of time for the next couple of years doing course material on the side. I reached out to Frontend Masters and just told them, "Hey, I've been doing courses for Egghead." I actually met Marc Grabanski at a conference a couple of years before. And so, we established a little bit of relationship. And I just said, "Hey, I want to come and teach there." So, I taught at Frontend Masters. I started putting on my own workshops at conferences. In fact, just a few months after graduating, I got accepted to speak at a conference. And only after I was accepted did I realize it was in Sweden [laughter]. I didn't think to look where in the world this conference was. So, that was my first international trip, actually, and I ended up speaking there. I gave, actually, two talks. One of them was a three-hour talk. WILL: Whoa. KENT: Which was, yeah, that was wild. WILL: [laughs] KENT: And then, yeah, I gave a two-day workshop for them. And then, I flew straight from there to Amsterdam to give another talk and also do a live in-person podcast, which I'd been running called ngAir, an Angular podcast. It just kept on building from there until finally, I created testingjavascript.com. And that was when I realized, oh, okay, so this isn't just a thing I can use to pay my mortgage, and that's nice. This is, like, a thing I can do full-time. Because I made more with Testing JavaScript than I made from my PayPal salary. WILL: Oh wow. KENT: I was like, oh, I don't need both of these things. I would rather work half as much one full-time job; that's what I want, one full-time job and make enough to take care of my family. And I prefer teaching. So, that's when I left PayPal was when I released Testing JavaScript. WILL: Wow. So, for me, I think so many times the imposter syndrome comes up whenever I want to teach or do things at the level you're saying you're doing. Because I love teaching. I love mentoring. I remember when I came into development, it was hard. I had to find the right person to help me mentor. So now, I almost made a vow to myself that if someone wants to learn and they're willing to put in the energy, I'm going to sit down however long it takes to help them because I remember how hard it was for me whenever I was doing it. So, you said in 2014, you were only a couple years doing development. How did you overcome impostor syndrome to stand in front of people, teach, go around the world, and give talks and podcasts? Like, how did you do that portion? KENT: Part of it is a certain level of hubris like I said. Like, you just have to be willing to believe that somebody's going to care. You know, the other part of it is, it's a secret to getting really, really good at something. They sometimes will say, like, those who can't do teach. That's total baloney because it requires a lot of being able to do to get you in a position where you can teach effectively. But the process of teaching makes you better at the process of doing as well. It's how you solidify your experience as a whatever. So, if you're a cook, you're really good at that; you will get better by teaching other people how to cook. There's an element of selfishness in what I do. I just want to get really, really good at this, and so I'm going to teach people so that I can. So yeah, I think there's got to be also, like, a little bit of thick skin, too, because people are going to maybe not like what you have to share or think that you're posing or whatever. Learn how to let that slide off you a little bit. But another thing is, like, as far as that's concerned, just being really honest about what your skill set is. So, if somebody asks me a question about GraphQL, I'm going to tell them, "Well, I did use GraphQL at PayPal, but I was pretty limited. And so, I don't have a lot of experience with that," and then I'll answer their question. And so, like, communicating your limitations of knowledge effectively and being okay being judged by people because they're going to judge you. It just is the way it is. So, you just have to learn how to cope well with that. There are definitely some times where I felt like I was in over my head on some subjects or I was involved in a conversation I had no business being there. I actually felt that a lot when I was sent as PayPal's delegate to the TC39 meetings. Wow, what am I doing here? I've only been in the industry for, like, two or three years at [laughter] that point. It takes a certain level of confidence in your own abilities. But also, like, being realistic about your inexperience as well, I think, is important too. WILL: Yeah, I know that you had a lot of success, and I want to cover that next. But were there any failures when you were doing those teaching moments? KENT: Years ago, Babel was still a new thing that everybody was using to compile their JavaScript with new syntax features down to JavaScript that the browser could run. There was ES Modules that was introduced, and lots of us were doing global window object stuff. And then we moved to, like, defining your dependencies with r.js or RequireJS. And then, there was CommonJS, and Universal Module Definition, and that sort of thing. So, ECMAScript modules were very exciting. Like, people were really interested in that. And so, Babel added support to it. It would compile from the module syntax down to whatever you wanted: CommonJS or...well, I'm pretty sure it could compile to RequireJS, but I compiled it to CommonJS. And so, there was a...yeah, I would say it's a bug in Babel at that time, where it would allow you to write your ES modules in a way that was not actually spec-compliant. It was incorrect. So, I would say export default some object, and then in another module, I would say import. And then, I'd select properties off of the object that I exported, that default I exported. That was allowed by Babel, but it is superduper, not how ECMAScript modules work. Well, the problem is that I taught, like, a ton of people how to use ECMAScript modules this way. And when I realized that I was mistaken, it was just, like, a knife to the heart because I was, like, I taught so many people this wrong thing. And so, I wrote a blog post about it. I gave a big, long talk titled “More Than You Want to Know About ECMAScript Modules,” where I talk about that with many other things as well. And so, yeah, just trying to do my part to make up for the mistake that I made. So yes, I definitely have had mistakes like that. There's also, like, the aspect that technology moves at a rapid pace. And so, I have old things that I would show people how to do, which they still work just as well as they worked back then. But I wouldn't recommend doing it that way because we have better ways now. For some people, the old way to do it is the only way they can do it based on the constraints they have and the tools that they're using and stuff. And so, it's not, like, it's not valuable at all. But it is a struggle to make sure that people understand that, like, this is the way that you do it if you have to do it this way, but, like, we've got better ways. WILL: I'm glad you shared that because it helps. And I love how you say it: when I make a mistake, I own up to it and let everyone know, "Hey, I made a mistake. Let's correct it and move on." So, I really like that. KENT: Yeah, 100%. MID-ROLL AD: Are your engineers spending too much time on DevOps and maintenance issues when you need them on new features? We know maintaining your own servers can be costly and that it's easy for spending creep to sneak in when your team isn't looking. By delegating server management, maintenance, and security to thoughtbot and our network of service partners, you can get 24x7 support from our team of experts, all for less than the cost of one in-house engineer. Save time and money with our DevOps and Maintenance service. Find out more at: tbot.io/devops. WILL: I want to go back to what you were saying. When you left PayPal, you released Testing JavaScript. How did you come up with the idea to write a Testing JavaScript course? And, two, how long did it take to take off and be successful? KENT: That was a pretty special thing, honestly. In 2018, I had put together a bunch of workshops related to testing. There was this conference called Assert(js) that invited me to come, taught them. In the year prior, I went to Midwest JS and taught how to test React. I had this material about testing. I'd gotten into testing just because of open-source stuff. I didn't want to have to manually go through all my stuff again every time I wanted to check for breakages and stuff, so that got me into testing. And whatever I'm into is what I'm going to teach. So, I started teaching that testing. And then my friend, Ryan Florence, put together...he separated from Michael Jackson with React Training, and built his own thing called Workshop.me. He asked me to join up with him. And he would, like, put together these workshops for me, and I would just...my job was just to show up and teach. And so, I did that. I have a picture, actually, in this blog post, The 2010s Decade in Review, of me in front of 60 people at a two-day workshop at Trulia in San Francisco. WILL: Oh, wow. KENT: And this is where I was teaching my testing workshop. Well, what's interesting about that photo is that two weeks before that, I had gotten really frustrated with the tool that everybody uses or used at the time for testing React, and that was Enzyme. And so I was preparing this workshop or working on it. I had already delivered it a number of times, but I was working on it, improving it, as I always do [laughs] when I'm preparing. WILL: [laughs] KENT: I can never give the same workshop twice, I guess. And I was just so frustrated that Enzyme was so difficult to work with. And, like, I was going to prepare this document that said, "Here are all the things you should never do with Enzyme. Like, Enzyme encourages you to do these things; you should not do these things. And let me explain why." And I just hated that I needed a document like that. And so, I tweeted, "I'm seriously starting to think that I should make my own very small testing lib and drop Enzyme entirely. Most of Enzyme's features are not at all useful and many damaging to my test bases. I'd rather have something smaller that encourages better practices." And so, I tweeted that March 15th, 2018. I did that. I did exactly that. What I often do in my workshops is I try to build the abstraction that we're going to use so that you can use it better. So, I was, like, building Enzyme, and I realized the jump between what I had built, the little utilities that I had built as part of the workshop, from that to Enzyme was just a huge leap. And so, I thought, you know what? These utilities that I have built to teach Enzyme are actually really good. What if I just turned that into a testing utility? And that became Testing Library, which, fast forward to today, is the number one testing library for React. And it's recommended for testing React, and Vue, and Angular. The ideas that are in Testing Library got adopted by Playwright. If you're writing tests for anything in the browser, you are very likely using something that was either originally developed by me or inspired by the work that I did. And it all came from that testing workshop that I was working on. So, with that, I had not only that testing workshop; I had a number of other workshops around testing. And so I approached Joel Hooks from Egghead.io. I say, "Hey, I'm getting ready to record a bunch of Egghead courses. I've got, like, six or seven courses I want to do." And he'd seen my work before, you know, I was a very productive course creator. And he said, "Hey, how about we, you know, we've been thinking about doing this special thing. How about we make a website just dedicated to your courses?" And I said, "That sounds great." I was a little bit apprehensive because I knew that putting stuff on Egghead meant that I had, like, a built-in audience and everything that was on Egghead, so this would be really the first time of me just branching out with video material on my own. Because, otherwise, if it wasn't Egghead, it was Frontend Masters, and there was the built-in audience there. But yeah, we decided to go for it. And we released it in, I think, November. And it was that first week...which is always when you make the most is during the launch period. But that launch week, I made more than my PayPal salary for the entire year. And so, that was when I realized, oh, yeah, okay, let's go full-time on this because I don't need two PayPal salaries. I just need one. And then I can spend more time with my family and stuff. And especially as the kids are getting older, they're staying up later, and I want to hang out with them instead of with my computer at night [laughter], and so... WILL: I love how you explain that because I came in around 2018, 2019. And I remember Enzyme, and it was so confusing, so hard to work with, especially for, you know, a junior dev that's just trying to figure it out. And I remember Testing JavaScript and then using that library, and it was just so much easier to, like, grab whatever you needed to grab. Those utils made the biggest difference, and still today, they make a huge difference. So yes, I just resonate with what you're saying. That's amazing. KENT: Aw, thank you so much. WILL: Yeah. You did Testing JavaScript. And then what was your next course that you did? KENT: I quit PayPal, go full-time teaching. That first year, I actually did an update to Testing JavaScript. There were a couple of changes in Testing Library and other things that I needed to update it for. And then I started working on Epic React. So, while I was doing all this testing stuff, I was also very into React, creating a bunch of workshops around that. I was invited to speak all over the world to talk about React. And I had a couple of workshops already for React. So, I was invited to give workshops at these conferences about React. And so, I thought, you know, let's do this again, and we'll do it with React this time. The other thing was, I'd never really planned on being the testing guy. It just kind of happened, and I actually didn't really like it either. I wanted to be more broad than just testing. So, that kind of motivated me to say, hey, let's do something with React to be a little bit more broad. Yeah, so I worked on putting those workshops together and delivered them remotely. And then, yeah, COVID hit, and just really messed everything up [laughs] really bad. So, I had everything done on my end for Epic React by March of 2020, which is, like, immediately after COVID got started, in the U.S. at least. And so, yeah, then we actually didn't end up releasing Epic React until October that year, which, honestly [laughs], was a little bit frustrating for me because I was like, "Hey, guys, I have recorded all the videos and everything. Can we get this released?" But, like, that just was a really rough year for everybody. But yeah, so Egghead got the site put together. I did a bunch of interviews and stuff. And then we launched in October of 2020. That was way bigger than Testing JavaScript because Testing JavaScript was still very informed by my experience as an Egghead instructor, which, typically, the Egghead courses are, like, a video where watch me do this thing, and then you'll learn something and go apply it to your own stuff. And that's kind of what Testing JavaScript was built as. But as part of the update of Testing JavaScript in 2019, I added another workshop module called Testing Node Applications. And in that one, I decided, hey, typically, I would have a workshop version of my material and a course version. The workshop version had like instructions and exercises. And the course version was no instructions or anything. It was just, like, watch these videos. And it was just me doing the exercises. And with the update of Testing JavaScript, I added that Testing Node workshop, and I said, hey, what if we just, like, embrace the fact that these are exercises, and it's just, like, me recording the workshop? How I would deliver the workshop? And so, I tested that out, and that went really well. And so, I doubled down on that with Epic React. And I said, okay, now, this isn't just, like, watch these videos. This is a do the exercise and then watch me do the exercise. So, Epic React was not only a lot more material but the format of the material was more geared for retention and true practice and learning. And so, Epic React ended up doing much better than Testing JavaScript, and even still, is still doing a remarkable job as far as course material is concerned. And, like, so many people are getting a lot of really great knowledge from Epic React. So yeah, very gratifying to have that. WILL: Once again, I've used Epic React. It's taught me so many...stretched me. And I do like the format, so yes, I totally agree with that, yeah. The next thing, Remix, correct? KENT: Yeah. So, how I got into Remix, around the same time we finished recording Epic React videos, I was doing some other stuff kind of to keep content going and stuff while we were waiting to launch Epic React. And around that same time, my friend Ryan Florence and Michael Jackson––they were doing the React training thing. And so, we were technically competitors. Like I said, Ryan and I kind of joined forces temporarily for his Workshop Me thing, but that didn't end up working out very well. And Michael really wanted Ryan back, and so they got back together. And their React training business went way better than it had before. They were hiring people and all sorts of stuff. And then, a training business that focuses on in-person training just doesn't do very well when COVID comes around. And so, they ended up having to lay off everybody and tried to figure out, okay, now what are we going to do? Our income has gone overnight. This is a bit of a simplification. But they decided to build software and get paid for it like one does. So, they started building Remix. Ryan, actually, around that time, moved back to Utah. He and I would hang out sometimes, and he would share what he was working on with Michael. We would do, like, Zoom calls and stuff, too. I just got really excited about what they were working on. I could see the foundation was really solid, and I thought it was awesome. But I was still working on Epic React. I end up launching Epic React. He launches Remix the very next month as a developer preview thing. Yeah, it definitely...it looked a lot like current Remix in some ways but very, very different in lots of others. But I was super hooked on that. And so, I paid for the developer preview and started developing my website with it. And around the next year in August, I was getting close to finishing my website. My website is, like, pretty legit. If you haven't gone to kentcdodds.com. Yet, it is cooler than you think it is. There's a lot that goes into that website. So, I had a team help me with the product planning and getting illustrations and had somebody help me implement the designs and all that stuff. It was a pretty big project. And then, by August of 2021, Ryan and I were talking, and I said, "Hey, listen, I want to update Epic React to use Remix because I just think that is the best way to build React applications. But I have this little problem where Remix is a paid framework. That's just going to really reduce the number of people who are interested in learning what I have to teach. And on top of that, like, it just makes it difficult for people to test things out." And so, he, around that time, was like, "Hey, just hold off a little bit. We've got some announcements." And so, I think it was September when they announced that they'd raised VC money and they were going to make Remix open source. That was when Ryan said, "Hey, listen, Kent, I think that it's awesome you want to update Epic React to use Remix. But the problem is that Remix isn't even 1.0 yet. The community is super small. It needs a lot of help. If you release a course on Remix right now, then you're not going to get any attention because, like, nobody even knows what it is." So, part of me is like, yeah, that's true. But also, the other part of me is like, how do people find out what it is [laughs] unless there's, like, material about it? But he was right. And he said, "Listen, we've got a bunch of VC money. I've always wanted to work with you. How about we just hire you? And you can be a full-time teacher about Remix. But you don't have to charge anything. You just, like, make a bunch of stuff for free about Remix." I said, "That sounds great. But, you know, to make that worth my while because I'm really happy with what I'm doing with this teaching thing, like, I'm going to need a lot of Remix." And so, Michael Jackson was like, "How about we just make you a co-founder, and we give you a lot of Remix?" And I said, "Okay, let's do this." And so I jumped on board with them as a year-delayed co-founder. I guess that's pretty common. But, like, that felt kind of weird to me [laughs] to be called a co-founder. But yeah, so I joined up with them. I worked on documentation a little bit, mostly community building. I ran Remix Conf. Shopify was interested in what we were doing. And we were interested in what Shopify was doing because, at the time, they were working on Hydrogen, which was one of the early adopters of React Server Components. And, of course, everybody was interested in whether Remix was going to be adding support for server components. And Ryan put together a couple of experiments and found out that server components were nowhere near ready. And we could do better than server components could as of, you know, the time that he wrote the blog posts, like, two years ago. So, Hydrogen was working with server components. And I put us in touch with the Hydrogen team—I think it was me—to, like, talk with the Hydrogen team about, like, "Hey, how about instead of spending all this time building your own framework, you just build on top of Remix then you can, you know, make your Shopify starter projects just, like, a really thin layer on top of Remix and people will love it? And this is very important to us because we need to get users, especially really big and high profile users, so people will take us seriously." And so, we have this meeting. They fly a bunch of their people out to Salt Lake. They're asking us questions. We're asking them questions and saying, "Hey, listen, this is why server components are just not going to work out for you." Well, apparently, they didn't listen to us. It felt like they were just like, "No, we're highly invested in this. We've already sunk all this cost into this, but we're going to keep going." And they did end up shipping Hydrogen version 1 on top of server components, which I just thought was a big mistake. And it wasn't too long after that they came back and said, "Hey, we're kind of interested in having you guys join Shopify." So, right after Remix Conf, I go up into Michael's room at the hotel with Ryan. And they say, "Hey, listen, Kent, we're talking with Shopify about selling Remix and joining Shopify," and kind of bounced back and forth on whether we wanted to do it. All of us were just not sure. Because when I joined Remix, I was thinking, okay, we're going to build something, and it's going to be huge. This is going to be bigger than Vercel, like multibillion-dollar company. So, I really kind of struggled with thinking, hey, we're selling out. Like, we're just getting started here. So, Ryan and I ended up at RenderATL in Atlanta at that conference. We were both speaking there. And Ryan didn't fill out the right form. So, he actually didn't have a hotel room [laughs], and so he ended up staying in my room. I intentionally always get a double bedroom just in case somebody needs to stay with me because somebody did that for me once, and I just...it was really nice of them. So, I've always done that since. And so, I said, "Yeah, Ryan, you can stay with me." And so, we spent just a ton of time together. And this was all while we were trying to decide what to do with Shopify. And we had a lot of conversations about, like, what do we want for Remix in the future? And it was there that I realized, oh if I want to take this to, like, multi-billion dollar valuation, I've got to do things that I am not at all interested in doing. Like, you've got to build a business that is worth that much money and do business-related things. On top of all of that, to get any money out of it...because I just had a percentage of the company, not actually any money. There was no stock. So, the only way you can get money out of a situation like that is if you have a liquidation event like an IPO, which sounds, like, awful—I [laughs] would hate to go through an IP0—or you have to be bought. And if you're worth $2 billion, or 3, or whatever, who can buy you? There's almost nobody who can buy you at that valuation. Do you really want to outprice anybody that could possibly buy you? And then, on top of that, to get there, that's, like, a decade worth of your life of working really superduper hard to get to that point, and there's no guarantee. Ryan would always say a bird in the hand is worth two in the bush. He was saying Shopify is a bird in the hand, and we do not know what the future holds. And so, we were all finally convinced that, yeah, we want to sell, and so we decided, yeah, let's sell. And as the sale date grew closer, I was getting excited because I was like, oh, I can be back on the TC39 because Shopify is, like, I don't know if they're actually sending delegates to the TC39, but I'm sure that they would be interested if I ask them to, like, "Hey, let's be involved in the evolution of JavaScript." And I know they're on the Web Working Group. Like, they're on a bunch of different committees and stuff. And I just thought it'd be really cool to get involved in the web platform again. And then, on top of that, I just thought, you know what? I'll just spend all my time teaching Shopify developers how to use Remix. That sounds like a lot of fun. As things drew closer, I got more and more uneasy about that. And I thought, you know, I could probably do just as well for myself by going full-time teacher again. I've done this thing before. I just really like being a teacher and, like, having total control over everything that I do. And if I work at Shopify, they're going to tell me, "Hey, you need to, like, do this, and that, and the other." And I don't know if I want to go back to that. And so, I decided, this is awesome. Super, super good job, folks. I think I've done everything for you that you need me to do. I'm going to bail out. And so, yeah, Shopify wasn't super jazzed about that. But the deal went through anyway. And that's how I ended my time at Shopify. WILL: I love it. It's lining up perfectly because you say you left Shopify to go back doing more teaching. And then you released another course; that's Epic Web, correct? KENT: Right. That was the reason I left Shopify or I didn't join up with Shopify is because I wanted to work on Epic Web. In this 2010s blog post, one of the last things that I mention...toward the bottom, there's a section, KCD EDU, which is basically, like, I wanted to help someone go from zero to my level as an engineer in a single place where I teach just all of the things that I can teach to get somebody there. And so I wanted to call it KCD EDU, but I guess you have to be an accredited university to get that domain or something. But that was the idea. Erin Fox, back in 2020 she said, "I'm expecting you to announce your online Kent C. Dodds engineering bootcamp." And I replied, "I'm planning on doing this, no joke." So, I've been wanting to do this for a really long time. And so, leaving Remix was like, yeah, this is what I'm going to go do. I'm going to go build KCD EDU. And I was talking with Ryan at some point about, like, what I was planning on doing in the future. And something he said or something I said in that conversation made me realize, oh, shoot, I want to build Epic Web Dev. So, I've got Epic React. I don't want Epic Remix. I want people to, like, be web developers. Remix is just, like, an implementation detail. And so, I went and I was relieved to find that the domain was still available: epicweb.dev, and so I bought that. And so, I was always planning on, like, even while I was at Remix, eventually, I would leave Remix and go build Epic Web Dev. So, that's what I did. Starting in August, I decided, okay, how about this: I will build a legit real-world web application, and then I will use that to teach people how to build legit real-world web applications from start to finish. If it's included as, like, knowledge you would need to build this web app, then that's knowledge you need to be able to build a full-stack application. That was the idea. So, I started live streaming in, like, August or September, and I would live stream almost everyday development of this web app. So, people can go and watch those on my YouTube channel. I would livestream for, like, sometimes six hours at a time with breaks every 45 minutes. So, I'd just put it on a break slide, go for a quick walk, or take a drink, whatever, and then I would come back. And I would just, like, so much development and live streaming for a long time. Once I got, like, in a pretty good place with that, the app I was building was called Rocket Rental. It's like Airbnb for rocket ships. So, you could rent, like, your own rocket ship to other people to fly. So, it had to be, like, realistic enough that, like, you could relate it to whatever you were building but not realistic enough that people would actually think it was a real product [laughs]. I worked with Egghead again. They actually have a sister company now called Skill Recordings that's responsible for these types of products. And so, I was working with Skill Recordings on, like, they would get me designs. And then I would, like, work with other people to help implement some of those designs. And then, I started working on turning this stuff into workshops. And with Epic React, we have this workshop app that you run locally so that you can work in your own editor, in your own environment, and with your own editor plugins and all that stuff. I want you to practice the way that you're going to actually exercise that practice when you're done––when you're working at work. And so we have this workshop app with Epic React. Well, that was built with Create React app, very limited on what you could do. And so, I started working on a new workshop app that I just called KCD Shop, that was built with Remix. And so, now we've got a bunch of server-side stuff we can do. And this server side is running on your machine. And so, so much stuff that I can do with this thing. One of the big challenges with Epic React was that the video you watch is on epicreact.dev, but the exercises you run are on localhost. And so, you have to keep those things in sync. You'd see, okay, I'm in exercise one on the videos. Let me go find exercise one in the app and then find the file exercise one. So, you've got, like, three different things you've got to keep in sync. And so, with the workshop app for Epic Web, I said, how about we make it so that we can embed the video into the app? And so, you just have localhost running, and you see the video right above the instructions for the exercise. And so, you watch the video that kind of introduces the problem that you're going to be doing, and then you read the instructions. And then we can also make it so that we have links you can click or buttons you can click in the app that will open your editor exactly where you're supposed to go. So you don't have to keep anything in sync. You go to the app, and you watch the video. You read the instructions. You click this button. It opens your editor. And so, that's exactly what I did. And it's an amazing experience. It is phenomenal, not just for the workshop learners but for me, as a workshop developer, like, creating the workshop––it's just been phenomenal. Because, like, we also have this diff view where you can see the difference between your work in progress and the solution. So, if you get stuck, then it's very easy to see where you went wrong. It also means that we can build even very large applications as part of our workshop and our exercise where there are dozens or hundreds of files. And you don't have to worry about finding them because it'll tell you exactly which ones you need to be working in, so all sorts of really, really cool things. So, this workshop app––actually, took a lot of time and effort to build. But now that it's done, like, people are going through it now, and they're just loving it. So, I built the workshop app, I put the first workshop of Rocket Rental into this workshop app, and I delivered it. And I found out very quickly that a full application with all the bells and whistles you'd expect, like, tons of different routes and stuff, was just too much. Even with the workshop app, it was just really pretty difficult for people to gain enough context around what they were building to be effective. So, I was concerned about that. But then, around the same time, I started realizing that I had a marketing problem. And that is that with Testing JavaScript, people know that they're customers because they're like, I'm a JavaScript developer, and I know how to test––boom. I'm a Testing JavaScript customer. With Epic React, I join this company; they're using React; I need to know React, boom. I'm a customer of Epic React. But with something like Epic Web, it's just so broad that, like, yeah, I am a web developer. I just don't know if I'm a customer to Epic Web. Like, is Epic Web for only really advanced people, or is it only for really beginner people? Or is it only for people who are using this set of tools or... Like, it's just a very difficult thing to, like, identify with. And so I wanted to de-emphasize the fact that we used Remix because the fact is that you can walk away from this material and work in a Next.js app or a SvelteKit app and still use so much of the knowledge that you gained in that environment. So, I didn't want to focus on the fact that we're using any particular set of tools because the tools themselves I select them, not only because I think that they are really great tools but also because the knowledge you gain from these tools is very transferable. And I'm going to teach it in a way that's very transferable. That was the plan. But I still had this issue, like, I need people to be able to identify themselves as customers of this thing. So, what I decided to do through some, like, hints and inspiration from other people was how about I turn Rocket Rental into a much simpler app and make that a project starter? And while I was at Remix, actually, I directed the creation of this feature called Remix Stacks. It's basically the CLI allows you to create a Remix app based on a template. I said I can make a Remix Stack out of this, and I called it the Epic Stack. And so, just took all of the concepts that came from Rocket Rental; applied it to a much simpler app. It's just a note-taking app, but it has, like, all of the features that you would need to build in a typical application. So, it's got a database. It's got deployment, GitHub integration. So, you have GitHub Actions to run tests and stuff. It has the tests. It has authentication already implemented, and even two-factor auth, and third-party auth, and file upload, and, like, just tons and tons of stuff built in. And so, people can start a new project and ship that and have a lot of success, like, skip all the basic stuff. So, I presented that at Remix Conf. I wasn't working at Remix anymore, but they asked me to run Remix Conf again, so I did. And I told them, "If I'm running it this year, I'm going to select myself to speak." And I spoke and introduced the Epic Stack there. And then that was when I started to create the workshops based on the Epic Stack. And so, now it was no longer we're going to have workshops to build Rocket Rental; it was we're going to have workshops to build the Epic Stack, with the idea being that if you build the thing, you are able to use it better, like, still following the same pattern I did with Testing JavaScript where we build a framework first. Like, before you start using Jest, we're building Jest and same with Testing Library. We do the same thing with React. Before we bring in React, I teach you how to create DOM nodes yourself and render those to the page and all of that. And so, here with Epic Web, I'm going to teach you how to build the framework that you can use to build applications. So, that is what Epic Web is, it's effectively we're building the Epic Stack. In the process, you learn all about really basic things, like, how do you get styles onto the page all the way to really complex things like, how do you validate a user's email? Or how do you implement two-factor auth? Or how do you create a test database? So, you don't have to mock out the database, but you can still run your test in isolation. Around this time was when my wife and I were trying to become pregnant. And we got the news that we were expecting, and we were super excited. And so, I'm thinking, okay, I've got to ship this thing before the baby comes. Because who knows what happens after this baby comes? So, I am talking with Skill Recordings. I'm saying, "We've got to get this done by October." I think it was May. And so, I was thinking like, okay, I've probably got, like, maybe eight days worth of workshops here. And so, kind of outlined all of the workshops. Like, I know what needs to be included. I know what the end looks like because I've got the Epic Stack. The end is the Epic Stack. The beginning is, like, a brand new create Remix app creation right there. So, I know what the start and the end looks like. I kind of can figure out how much time I need to teach all of that. And I said, "Let's do eight days." And so, we got that scheduled and started selling tickets. And we sold out 30 tickets in just a couple of days, and that's what we originally planned for. I'm like, well, gosh, I can handle 80 people in a workshop. I've done that before, but that's about as far as I go. I don't really like going that much. In fact, online, especially, I only like to go up to, like, 40. But we said, "Hey, let's knock this out of the park." So, we doubled it, and we sold another 30 seats. And so, it was sold out before even the early bird sale was over. So, that was pretty encouraging. The problem was that I hadn't actually developed this material. I'd already given one workshop about testing with Rocket Rental, and I'd given one workshop about the fundamentals with Rocket Rental. But I hadn't done anything of the authentication or, the forms, or data modeling. Also, like, Epic Notes app is different from Rocket Rental. So, I got to rebuild those workshops. Like, the first workshop was going to start in, like, two weeks, maybe three weeks. And so, I'm working on these workshops. And I'm like, I've finished the first workshop, which was going to be a two-day workshop, and so I get that done. And so, that next week, I'm getting close to finished on the forms workshop, and then I start the workshops. And that was when I started to realize, oh, shoot, I am in huge trouble because I have to not only deliver two workshops a week, so that's two days a week that I'm not able to work on the workshops, really. And then also develop the material as I go, which I don't normally do this at all because I just don't like stressing myself out so much. But, like, I'd had this timeline put together, and I'm like, I need to ship this by October. For about five weeks, I worked 80 to 100 hours a week, maybe more, in a row to get those workshops created [laughs]. And I do not recommend this, and I will never do it again. I can tell you this now. I didn't tell anybody at the time because I was worried that people would think, well, geez, is that the type of product you create, like, you're just rushing through this stuff? But I can tell you this safely now because the results speak for themselves. Like, these people loved this stuff. They ate it up. It was so good. I won't do this again. It's not something that I typically do. But it worked. And, like, I put in a crazy amount of work to make this work. People loved it. And yeah, I'm really, really happy with that. The next step, though, so it was eight days' worth of workshops in four weeks. And I realized, as I almost always realize when I'm presenting workshops, that, like, oh my gosh, I have way more material than I have time for. So, by

(Video Podcast available on Spotify and Youtube)Join us as we delve into a candid conversation with Scott Moss, a seasoned instructor and investor with a unique trajectory from the military to the forefront of tech education and startup investment. Scott shares his comprehensive insights on the transformative power of teaching, the rigorous journey through Y Combinator, and the strategic approach to tech investment. This episode is a deep dive into the practicalities of tech career progression, the long game of startup success, and the continuous learning cycle fueled by teaching. Whether you're a tech veteran or an aspiring entrepreneur, Scott's experiences and advice offer valuable perspectives on navigating the tech landscape. Check out Scott's Frontend Masters courses online here: https://frontendmasters.com/teachers/scott-moss/Find Frontend Masters Online: Twitter: ⁠https://twitter.com/FrontendMasters⁠ LinkedIn: ⁠https://www.linkedin.com/company/frontend-masters/⁠ Facebook: ⁠https://www.facebook.com/FrontendMasters⁠ Instagram: ⁠https://instagram.com/FrontendMasters⁠About Us: Advance your skills with in-depth, modern front-end engineering courses — our 150+ high-quality courses and 18 curated learning paths will guide you from mid-level to senior developer! ⁠https://frontendmasters.com/

Episode Description:(Video Podcast available on Spotify and Youtube) Join us in Episode 5 of The Frontend Masters Podcast as we explore Erik Reinert's tech journey from humble beginnings in tech support to his current aspirations as a backend developer. Erik delves into the evolution of his career, highlighting the pivotal transitions and the drive that propelled him from one role to the next. This episode offers a deep dive into the world of tech streaming, community building on Twitch, and the shift from purely educational content to a blend of education and entertainment. Erik discusses the challenges of content creation while managing a full-time tech job, the nuances of engaging a live audience, and the importance of timing and platform choice for content creators. He also shares his personal goals, including his path to becoming a principal engineer and his venture into developing stream tools. For tech enthusiasts and aspiring content creators, Erik provides a blend of practical advice and personal anecdotes, making this a must-listen for those looking to navigate their own path in the tech industry. Check out Erik's Frontend Masters courses online here: https://frontendmasters.com/teachers/erik-reinert/⁠Find Frontend Masters Online: Twitter: ⁠https://twitter.com/FrontendMasters⁠ LinkedIn: ⁠https://www.linkedin.com/company/frontend-masters/⁠ Facebook: ⁠https://www.facebook.com/FrontendMasters⁠ Instagram: ⁠https://instagram.com/FrontendMasters⁠About Us: Advance your skills with in-depth, modern front-end engineering courses — our 150+ high-quality courses and 18 curated learning paths will guide you from mid-level to senior developer! ⁠https://frontendmasters.com/

(Video Podcast available on Spotify and Youtube) In Episode 4, we dive deep with Miško Hevery, the mind behind AngularJS / Angular and Qwik, as he takes us on a journey from his early days in computer engineering to his impactful years at Google. Miško is one of the few to transition from hardware design all the way to frontend development. We go over the significance of testing in software development, the birth and philosophy of AngularJS, scalability, and code performance. Get a unique view into the evolution of frameworks and web tools from both hardware and software perspectives in this interview with Misko! Check out Miško's Frontend Masters courses online here: https://frontendmasters.com/teachers/misko-hevery/ Follow and connect with all things @frontendmasters across social media: Twitter: https://twitter.com/FrontendMasters LinkedIn: https://www.linkedin.com/company/frontend-masters/ Facebook: https://www.facebook.com/FrontendMasters Instagram: https://instagram.com/FrontendMasters Youtube: https://www.youtube.com/@FrontendMasters About Us: Advance your skills with in-depth, modern front-end engineering courses — our 150+ high-quality courses and 18 curated learning paths will guide you from mid-level to senior developer! https://frontendmasters.com/

Axels tips:Kevin Powell: https://www.youtube.com/@KevinPowellUdemy - Complete js course: https://www.udemy.com/course/the-complete-javascript-course/Udemy - Understanding TS: https://www.udemy.com/course/understanding-typescript/Saras tips:Frontend Masters: https://frontendmasters.com/You Don't Know JS Yet: https://github.com/getify/You-Dont-Know-JSOscar tips:Eloquent Javascript: https://eloquentjavascript.net/ Hosted on Acast. See acast.com/privacy for more information.

(Video Podcast available on Spotify and Youtube) Episode 3 is with Jen Kramer, our primary CSS teacher who has experience teaching at the Harvard Extension School and beyond!  This episode is a comprehensive look at Jen's career trajectory, from her initial steps in biology to her current influence in web development and academia. For modern-day developers, this episode offers invaluable insights into the evolution of web technologies. We discuss the transitions from table-based layouts to the advent of CSS and how various shifts have happened (Bootstrap, flexbox, etc.) to create best practices in today's web development landscape. Additionally, she emphasizes the importance of effective teaching methods for mastering new technologies and how interdisciplinary skills can be a unique asset in the tech industry. Check out Jen's Frontend Masters courses online here: https://frontendmasters.com/teachers/jen-kramer/ Follow and connect with all things @frontendmasters across social media: Twitter: https://twitter.com/FrontendMasters LinkedIn: https://www.linkedin.com/company/frontend-masters/ Facebook: https://www.facebook.com/FrontendMasters Instagram: https://instagram.com/FrontendMasters Youtube: https://www.youtube.com/@FrontendMasters About Us: Advance your skills with in-depth, modern front-end engineering courses — our 150+ high-quality courses and 18 curated learning paths will guide you from mid-level to senior developer! https://frontendmasters.com/

(Video Podcast available on Spotify and Youtube) In this second episode, we talk with Steve Kinney, a tech veteran who's career started in public school teaching, to eventually becoming lead of UI development at Twilio SendGrid and now Head of UI Engineering at Temporal. We delve into Steve's early coding experience and how teaching has influenced his tech career. Check out Steve's Frontend Masters courses online here: https://frontendmasters.com/teachers/steve-kinney/ Find Frontend Masters Online: Twitter: https://twitter.com/FrontendMasters LinkedIn: https://www.linkedin.com/company/frontend-masters/ Facebook: https://www.facebook.com/FrontendMasters Instagram: https://instagram.com/FrontendMasters Follow and connect with all things @frontendmasters across Twitter/X, Linkedin, Instagram and YouTube. About Us: Advance your skills with in-depth, modern front-end engineering courses — our 150+ high-quality courses and 18 curated learning paths will guide you from mid-level to senior developer! https://frontendmasters.com/

(Video Podcast available on Spotify and Youtube) In this first episode of the podcast, we dive deep into the life and career of Brian Holt, a front-end engineering veteran and educator. We discuss everything from classroom antics and tattoos inspired by Baroque art, to early experiences with computing shaped by family influences. The conversation also delves into Brian launching React code at Reddit, shedding light on the complexities of career growth, work-life balance, and the ethical dilemma of "burnout culture" in tech. Whether you're interested in JavaScript frameworks, DevOps, or the human stories behind tech professionals, this episode offers a well-rounded exploration valuable to anyone in the field. Check out Brian's Frontend Masters courses online here: https://frontendmasters.com/teachers/brian-holt/Find Frontend Masters Online: Twitter: https://twitter.com/FrontendMasters LinkedIn: https://www.linkedin.com/company/frontend-masters/ Facebook: https://www.facebook.com/FrontendMasters Instagram: https://instagram.com/FrontendMastersAbout Us: Advance your skills with in-depth, modern front-end engineering courses — our 150+ high-quality courses and 18 curated learning paths will guide you from mid-level to senior developer! https://frontendmasters.com/

Bailey and Jesse are joined by the Head of Engineering of Temporal and founder of the Turing Front End Program Steve Kinney. They discuss how Steve joined Turing during the early days, the advent of the Front End Program, his work at Sendgrid, Twilio, Temporal as well as the courses he teaches at Frontend Masters. LinkedIn: [https://www.linkedin.com/in/stevekinney/](https://www.linkedin.com/in/stevekinney/) Website: [https://www.stevekinney.net/](https://www.stevekinney.net/) Frontend Masters: [https://frontendmasters.com/teachers/steve-kinney/](https://frontendmasters.com/teachers/steve-kinney/) Temporal: [https://temporal.io](https://frontendmasters.com/teachers/steve-kinney/) Don't forget to check out https://www.milehighhack.org/ a Denver non profit and civic hackathon. And apologies for the sound quality of this episode. It's not the best and we're working to improve.

Working on legacy code is never easy, but some programming languages make it more enjoyable.  Today, we talk with Richard Feldman, the creator of the Roc programming language, the author of Elm in Action, and the creator of the Frontend Masters courses Introduction to Elm and Introduction to Rust. Richard tells us about the advantages of the Elm, Rock, and Rust languages and why they are more enjoyable to work with than other languages.  When you finish listening to the episode, connect with Richard on Twitter, check out his book and courses, and take a look at the Roc programming language.  Mentioned in this episode: Richard on Twitter at https://twitter.com/rtfeldman Roc programming language at: https://www.roc-lang.org Elm in Action at https://www.manning.com/books/elm-in-action Richard's Frontend Masters courses at: https://frontendmasters.com/teachers/richard-feldman/

Production is down!! Faulty code was released!! Users are losing your trust by the second!! Ugh, how did this happen and how could this have been prevented? By writing the right tests! Today, Jedi test master, Kent C. Dodds, joins us as we discuss all things testing, from the types of tests in your tool belt, how to write the right tests, when to run them, tools you can and should use, and ways to ensure your tests are performant. Kent is a world renowned speaker, educator, a beacon of inspiration in the tech community and has written an entire course focused solely on Testing Javascript. He graduated from BYU with a Master of Science in Information Systems, and has worked at companies like Domo, Alianza and PayPal. He is a Google Developer Expert and an instructor on egghead.io and Frontend Masters. He is actively involved in the open source community as a maintainer of projects like Glamorous, Downshift and Testing Library, and is a contributor to hundreds of popular npm packages. Prior to his current role, he co-founded Remix and worked as the Director of Developer Experience. Presently, our guest is a Software Engineer Educator working for himself and working on what he calls his magnum opus - EpicReact.Dev. When Kent is not teaching the world about software or spending time with his family he is cruising around on his onewheel or snowboarding. Prepare to become a Jedi test master!! Connect with Kent: Twitter Website Youtube Discord Show notes and helpful resources: The Testing Trophy blog post Why I never use shallow rendering blog post Avoid the test user blog post Making your UI tests resilient to change blog post Common mistakes with React Testing Library blog post Migrate from Enzyme to Testing Library documentation How to know what to test blog post Business and engineering alignment blog post Playwright - End-2-End testing library Vitest testing framework Building something cool or solving interesting problems? Want to be on this show? Send me an email at jointhepodcast@unfilteredbuild.com Podcast produced by Unfiltered Build - dream.design.develop.

Richard and Frontend Masters founder Marc Grabanski talk about a "back to basics" approach to Web development, not based on any frameworks or unnecessary dependencies.

  Episode 247 Kent C. Dodds is a world renowned speaker, teacher, and trainer and he's actively involved in the open source community as a maintainer and contributor of hundreds of popular npm packages. Kent is a Co-Founder and Director of Developer Experience at Remix. He is the creator of EpicReact.Dev and TestingJavaScript.com. He's an instructor on egghead.io and Frontend Masters. He's also a Google Developer Expert. Kent is happily married and the father of four kids. He likes his family, code, JavaScript, and Remix.   Links https://kentcdodds.com https://twitter.com/kentcdodds https://blog.kentcdodds.com/   Resources https://remix.run/ https://remix.run/docs/en/v1 https://rmx.as/discord https://github.com/remix-run https://twitter.com/remix_run https://www.youtube.com/watch?v=hsIWJpuxNj0 https://remix.run/blog/remix-vs-next https://remix.run/blog/remixing-react-router https://egghead.io/courses/up-and-running-with-remix-b82b6bb6 https://twitter.com/brandontroberts/status/1533598978658418689 https://remix.run/blog/remix-stacks https://remix.run/conf https://remix.run/docs/en/v1/tutorials/jokes   "Tempting Time" by Animals As Leaders used with permissions - All Rights Reserved × Subscribe now! Never miss a post, subscribe to The 6 Figure Developer Podcast! Are you interested in being a guest on The 6 Figure Developer Podcast? Click here to check availability!  

In this episode, Amy and James discuss all things SVGs: what is, why, and when to reach for it, and seven different ways to get an SVG on the page, and the pros and cons of each method.SponsorsVercelVercel combines the best developer experience with an obsessive focus on end-user performance. Their platform enables frontend teams to do their best work. It is the best place to deploy any frontend app. Start by deploying with zero configuration to their global edge network. Scale dynamically to millions of pages without breaking a sweat.For more information, visit Vercel.comZEAL is hiring!ZEAL is a computer software agency that delivers “the world's most zealous” and custom solutions. The company plans and develops web and mobile applications that consistently help clients draw in customers, foster engagement, scale technologies, and ensure delivery.ZEAL believes that a business is “only as strong as” its team and cares about culture, values, a transparent process, leveling up, giving back, and providing excellent equipment. The company has staffers distributed throughout the United States, and as it continues to grow, ZEAL looks for collaborative, object-oriented, and organized individuals to apply for open roles.For more information visit softwareresidency.com/careersDatoCMSDatoCMS is a complete and performant headless CMS built to offer the best developer experience and user-friendliness in the market. It features a rich, CDN-powered GraphQL API (with real-time updates!), a super-flexible way to handle dynamic layouts and structured content, and best-in-class image/video support, with progressive/LQIP image loading out-of-the-box."For more information, visit datocms.comShow Notes0:00 Introduction3:50 What is an SVG?Raster vs Vector6:21 Benefits to using an SVGChange the SizeSmall File SizeChange the color within your codeEasily Cached9:51 Seven Different Ways to get an SVG on the Page11:28 Sponsor - ZEAL12:59 Option 1 - Image Tag14:03 Option 2 - Inline SVG tag15:53 Option 3 - CSS as a  background Image16:18 Option 4 - CSS, as a Mask18:20 Sponsor - Vercel19:29 Option 5 - SVG directly within our Image tag21:20 Option 6 - Base64 or UTF8 with as a CSS Background Image21:47 Option 7 - An SVG Sprite22:34 Writing your own SVGs27:00 Going Deep on a Specific Topic, The Broken Comb28:34 ResourcesAmy's SVG Series on YouTubeSarah Drasner - Course on Frontend Masters, SVG Essentials & Animation, v2Sarah Drasner - SVG Animations: From Common UX Implementations to Complex Responsive AnimationChris Coyier - Practical SVG29:19 Sponsor - DatoCMS30:12 Grab Bag Questions30:56 Picks and Plugs31:07 Amy's Pick - Animal Cable Clips32:00 Amy's Plug - Advent of CSS32:32 James's Pick - Castle on Hulu33:34 James's Plug - Advent of JavaScript

Richard Feldman (Twitter) (GitHub)Richard's Elm book Elm in ActionRichard's Frontend Masters coursesRichard's talk Teaching Elm to BeginnersFind motivationMloc.js conference (by Prezi)Pairing as a way to teach ElmIntro to Elm Frontend Masters workshop exercises are open sourceSouth Park therefore/but storytelling technique"I like teaching things the wrong way and then showing what's wrong with it."The importance of finding good examplesTraining From the Back of the RoomDillon's Elm JSON Decoder koans repoGradual release of responsibility techniqueBrian's JSON Survival Kit bookNoRedInk jobs (looking for Elm and Haskell engineers)Richard's Frontend Masters advanced Elm course and Elm intro course

About EmmaEmma Bostian is a Software Engineer at Spotify in Stockholm. She is also a co-host of the Ladybug Podcast, author of Decoding The Technical Interview Process, and an instructor at LinkedIn Learning and Frontend Masters.Links: Ladybug Podcast: https://www.ladybug.dev LinkedIn Learning: https://www.linkedin.com/learning/instructors/emma-bostian Frontend Masters: https://frontendmasters.com/teachers/emma-bostian/ Decoding the Technical Interview Process: https://technicalinterviews.dev Twitter: https://twitter.com/emmabostian TranscriptAnnouncer: Hello, and welcome to Screaming in the Cloud with your host, Chief Cloud Economist at The Duckbill Group, Corey Quinn. This weekly show features conversations with people doing interesting work in the world of cloud, thoughtful commentary on the state of the technical world, and ridiculous titles for which Corey refuses to apologize. This is Screaming in the Cloud.Corey: This episode is sponsored in part by our friends at Jellyfish. So, you're sitting in front of your office chair, bleary eyed, parked in front of a powerpoint and—oh my sweet feathery Jesus its the night before the board meeting, because of course it is! As you slot that crappy screenshot of traffic light colored excel tables into your deck, or sift through endless spreadsheets looking for just the right data set, have you ever wondered, why is it that sales and marketing get all this shiny, awesome analytics and inside tools? Whereas, engineering basically gets left with the dregs. Well, the founders of Jellyfish certainly did. That's why they created the Jellyfish Engineering Management Platform, but don't you dare call it JEMP! Designed to make it simple to analyze your engineering organization, Jellyfish ingests signals from your tech stack. Including JIRA, Git, and collaborative tools. Yes, depressing to think of those things as your tech stack but this is 2021. They use that to create a model that accurately reflects just how the breakdown of engineering work aligns with your wider business objectives. In other words, it translates from code into spreadsheet. When you have to explain what you're doing from an engineering perspective to people whose primary IDE is Microsoft Powerpoint, consider Jellyfish. Thats Jellyfish.co and tell them Corey sent you! Watch for the wince, thats my favorite part.Corey: This episode is sponsored in part by Liquibase. If you're anything like me, you've screwed up the database part of a deployment so severely that you've been banned from touching every anything that remotely sounds like SQL, at at least three different companies. We've mostly got code deployments solved for, but when it comes to databases we basically rely on desperate hope, with a roll back plan of keeping our resumes up to date. It doesn't have to be that way. Meet Liquibase. It is both an open source project and a commercial offering. Liquibase lets you track, modify, and automate database schema changes across almost any database, with guardrails to ensure you'll still have a company left after you deploy the change. No matter where your database lives, Liquibase can help you solve your database deployment issues. Check them out today at liquibase.com. Offer does not apply to Route 53.Corey: Welcome to Screaming in the Cloud. I'm Corey Quinn. One of the weird things that I've found in the course of, well, the last five years or so is that I went from absolute obscurity to everyone thinking that I know everyone else because I have thoughts and opinions on Twitter. Today, my guest also has thoughts and opinions on Twitter. The difference is that what she has to say is actually helpful to people. My guest is Emma Bostian, software engineer at Spotify, which is probably, if we can be honest about it, one of the least interesting things about you. Thanks for joining me.Emma: Thanks for having me. That was quite the intro. I loved it.Corey: I do my best and I never prepare them, which is a blessing and a curse. When ADHD is how you go through life and you suck at preparation, you've got to be good at improv. So, you're a co-host of the Ladybug Podcast. Let's start there. What is that podcast? And what's it about?Emma: So, that podcast is just my three friends and I chatting about career and technology. We all come from different backgrounds, have different journeys into tech. I went the quote-unquote, “Traditional” computer science degree route, but Ali is self-taught and works for AWS, and Kelly she has, like, a master's in psychology and human public health and runs her own company. And then Sydney is an awesome developer looking for her next role. So, we all come from different places and we just chat about career in tech.Corey: You're also an instructor at LinkedIn Learning and Frontend Masters. I'm going to guess just based upon the name that you are something of a frontend person, which is a skill set that has constantly eluded me for 20 years, as given evidence by every time I've tried to build something that even remotely touches frontend or JavaScript in any sense.Emma: Yeah, to my dad's disdain, I have stuck with the frontend; he really wanted me to stay backend. I did an internship at IBM in Python, and you know, I learned all about assembly language and database, but frontend is what really captures my heart.Corey: There's an entire school of thought out there from a constituency of Twitter that I will generously refer to as shitheads that believe, “Oh, frontend is easy and it's somehow less than.” And I would challenge anyone who holds that perspective to wind up building an interface that doesn't look like crap first, then come and talk to me. Spoiler, you will not say that after attempting to go down that rabbit hole. If you disagree with this, you can go ahead and yell at me on Twitter so I know where you're hiding, so I can block you. Now, that's all well and good, but one of the most interesting things that you've done that aligns with topics near and dear to my heart is you wrote a book.Now, that's not what's near and dear to my heart; I have the attention span to write a tweet most days. But the book was called Decoding the Technical Interview Process. Technical interviewing is one of those weird things that comes up from time to time, here and everywhere else because it's sort of this stylized ritual where we evaluate people on a number of skills that generally don't reflect in their day-to-day; it's really only a series of skills that you get better by practicing, and you only really get to practice them when you're interviewing for other jobs. That's been my philosophy, but again, I've written a tweet on this; you've written a book. What's the book about and what drove you to write it?Emma: So, the book covers everything from an overview of the interview process, to how do you negotiate a job offer, to systems design, and talks about load balancing and cache partitioning, it talks about what skills you need from the frontend side of things to do well on your JavaScript interviews. I will say this, I don't teach HTML, CSS, and JavaScript in-depth in the book because there are plenty of other resources for that. And some guy got mad at me about that the other day and wanted a refund because I didn't teach the skills, but I don't need to. [laugh]. And then it covers data structures and algorithms.They're all written in JavaScript, they have easy to comprehend diagrams. What drove me to write this is that I had just accepted a job offer in Stockholm for a web developer position at Spotify. I had also just passed my Google technical interviews, and I finally realized, holy crap, maybe I do know what I'm doing in an interview now. And this was at the peak of when people were getting laid off due to COVID and I said, “You know what? I have a lot of knowledge. And if I have a computer science degree and I was able to get through some of the hardest technical interviews, I think I should share that with the community.”Because some people didn't go through a CS degree and don't understand what a linked list is. And that's not their fault. It's just unfortunately, there weren't a lot of great resources—especially for web developers out there—to learn these concepts. Cracking the Coding Interview is a great book, but it's written in backend language and it's a little bit hard to digest as a frontend developer. So, I decided to write my own.Corey: How much of the book is around the technical interview process as far as ask, “Here's how you wind up reversing linked lists,” or, “Inverting a binary tree,” or whatever it is where you're tracing things around without using a pointer, how do you wind up detecting a loop in a recursive whatever it is—yeah, as you can tell, I'm not a computer science person at all—versus how much of it is, effectively, interview 101 style skills for folks who are even in non-technical roles could absorb?Emma: My goal was, I wanted this to be approachable by anyone without extensive technical knowledge. So, it's very beginner-friendly. That being said, I cover the basic data structures, talking about what traditional methods you would see on them, how do you code that, what does that look like from a visual perspective with fake data? I don't necessarily talk about how do you reverse a binary tree, but I do talk about how do you balance it if you remove a node? What if it's not a leaf node? What if it has children? Things like that.It's about [sigh] I would say 60/40, where 40% is coding and technical stuff, but maybe—eh, it's a little bit closer to 50/50; it kind of depends. I do talk about the take-home assessment and tips for that. When I do a take-home assessment, I like to include a readme with things I would have done if I had more time, or these are performance trade-offs that I made; here's why. So, there's a lot of explanation as to how you can improve your chances at moving on to the next round. So yeah, I guess it's 50/50.I also include a section on tips for hiring managers, how to create an inclusive and comfortable environment for your candidates. But it's definitely geared towards candidates, and I would say it's about 50/50 coding tech and process stuff.Corey: One of the problems I've always had with this entire industry is it feels like we're one of the only industries that does this, where we bring people in, and oh, you've been an engineer for 15 years at a whole bunch of companies I've recognized, showing career progression, getting promoted at some of them transitioning from high-level role to high-level role. “Great, we are so glad that you came in to interview. Now, up to the whiteboard, please, and implement FizzBuzz because I have this working theory that you don't actually know how to code, and despite the fact that you've been able to fake your way through it at big companies for 15 years, I'm the one that's going to catch you out with some sort of weird trivia question.” It's this adversarial, almost condescending approach and I don't see it in any other discipline than tech. Is that just because I'm not well-traveled enough? Is that because I'm misunderstanding the purpose of all of these things? Or, what is this?Emma: I think partially it was a gatekeeping solution for a while, for people who are comfortable in their roles and may be threatened by people who have come through different paths to get to tech. Because software engineer used to be an accredited title that you needed a degree or certification to get. And in some countries it still is, so you'll see this debate sometimes about calling yourself a software engineer if you don't have that accreditation. But in this day and age, people go through boot camps, they can come from other industries, they can be self-taught. You don't need a computer science degree, and I think the interview process has not caught up with that.I will say [laugh] the worst interview I had was at IBM when I was already working there. I was already a web developer there, full-time. I was interviewing for a role, and I walked into the room and there were five guys sitting at a table and they were like, “Get up to the whiteboard.” It was for a web development job and they quizzed me about Java. And I was like, “Um, sir, I have not done Java since college.” And they were like, “We don't care.”Corey: Oh, yeah, coding on a whiteboard in front of five people who already know the answer—Emma: Horrifying.Corey: —during a—for them, it's any given Tuesday, and for you, it is a, this will potentially determine the course that your career takes from this point forward. There's a level of stress that goes into that never exists in our day-to-day of building things out.Emma: Well, I also think it's an artificial environment. And why, though? Like, why is this necessary? One of the best interviews I had was actually with Gatsby. It was for an open-source maintainer role, and they essentially let me try the product before I bought it.Like, they let me try out doing the job. It was a paid process, they didn't expect me to do it for free. I got to choose alternatives if I wanted to do one thing or another, answer one question or another, and this was such an exemplary process that I always bring it up because that is a modern interview process, when you are letting people try the position. Now granted, not everyone can do this, right? We've got parents, we've got people working two jobs, and not everyone can afford to take the time to try out a job.But who can also afford a five-stage interview process that still warrants taking vacation days? So, I think at least—at the very least—pay your candidates if you can.Corey: Oh, yeah. One of the best interviews I've ever had was at a company called Three Rings Design, which is now defunct, unfortunately, but it was fairly typical ops questions of, “Yeah, here's an AWS account. Spin up a couple EC2 instances, load balance between them, have another one monitored. You know, standard op stuff. And because we don't believe in asking people to work for free, we'll pay you $300 upon completion of the challenge.”Which, again, it's not huge money for doing stuff like that, but it's also, this shows a level of respect for my time. And instead of giving me a hard deadline of when it was due, they asked me, “When can we expect this by?” Which is a great question in its own right because it informs you about a candidate's ability to set realistic deadlines and then meet them, which is one of those useful work things. And they—unlike most other companies I spoke with in that era—were focused on making it as accommodating for the candidate as possible. They said, “We're welcome to interview you during the workday; we can also stay after hours and have a chat then, if that's more convenient for your work schedule.”Because they knew I was working somewhere else; an awful lot of candidates are. And they just bent over backwards to be as accommodating as possible. I see there's a lot of debate these days in various places about the proper way to interview candidates. No take-home because biases for people who don't have family obligations or other commitments outside of work hours. “Okay, great, so I'm going to come in interview during the day?” “No. That biases people who can't take time off.” And, on some level, it almost seems to distill down to no one likes any way that there is of interviewing candidates, and figuring out a way that accommodates everyone is a sort of a fool's errand. It seems like there is no way that won't get you yelled at.Emma: I think there needs to be almost like a choose your own adventure. What is going to set you up for success and also allow you to see if you want to even work that kind of a job in the first place? Because I thought on paper, open-source maintainer sounds awesome. And upon looking into the challenges, I'm like, “You know what? I think I'd hate this job.”And I pulled out and I didn't waste their time and they didn't waste mine. So, when you get down to it, honestly, I wish I didn't have to write this book. Did it bring me a lot of benefit? Yeah. Let's not sugarcoat that. It allowed me to pay off my medical debt and move across a continent, but that being said, I wish that we were at a point in time where that did not need to exist.Corey: One of the things that absolutely just still gnaws at me even years later, is I interviewed at Google twice, and I didn't get an offer either time, I didn't really pass their technical screen either time. The second one that really sticks out in my mind where it was, “Hey, write some code in a Google Doc while we watch remotely,” and don't give you any context or hints on this. And just it was—the entire process was sitting there listening to them basically, like, “Nope, not what I'm thinking about. Nope, nope, nope.” It was… by the end of that conversation, I realized that if they were going to move forward—which they didn't—I wasn't going to because I didn't want to work with people that were that condescending and rude.And I've held by it; I swore I would never apply there again and I haven't. And it's one of those areas where, did I have the ability to do the job? I can say in hindsight, mostly. Were there things I was going to learn as I went? Absolutely, but that's every job.And I'm realizing as I see more and more across the ecosystem, that they were an outlier in a potentially good way because in so many other places, there's no equivalent of the book that you have written that is given to the other side of the table: how to effectively interview candidates. People lose sight of the fact that it's a sales conversation; it's a two-way sale, they have to convince you to hire them, but you also have to convince them to work with you. And even in the event that you pass on them, you still want them to say nice things about you because it's a small industry, all things considered. And instead, it's just been awful.Emma: I had a really shitty interview, and let me tell you, they have asked me subsequently if I would re-interview with them. Which sucks; it's a product that I know and love, and I've talked about this, but I had the worst experience. Let me clarify, I had a great first interview with them, and I was like, “I'm just not ready to move to Australia.” Which is where the job was. And then they contacted me again a year later, and it was the worst experience of my life—same recruiter—it was the ego came out.And I will tell you what, if you treat your candidates like shit, they will remember and they will never recommend people interview for you. [laugh]. I also wanted to mention about accessibility because—so we talked about, oh, give candidates the choice, which I think the whole point of an interview should be setting your candidates up for success to show you what they can do. And I talked with [Stephen 00:14:09]—oh, my gosh, I can't remember his last name—but he is a quadriplegic and he types with a mouthstick. And he was saying he would go to technical interviews and they would not be prepared to set him up for success.And they would want to do these pair programming, or, like, writing on a whiteboard. And it's not that he can't pair program, it's that he was not set up for success. He needed a mouthstick to type and they were not prepared to help them with that. So, it's not just about the commitment that people need. It's also about making sure that you are giving candidates what they need to give the best interview possible in an artificial environment.Corey: One approach that people have taken is, “Ah, I'm going to shortcut this and instead of asking people to write code, I'm going to look at their work on GitHub.” Which is, in some cases, a great way to analyze what folks are capable of doing. On the other, well, there's a lot of things that play into that. What if they're working in environment where they don't have the opportunity to open-source their work? What if people consider this a job rather than an all-consuming passion?I know, perish the thought. We don't want to hire people like that. Grow up. It's not useful, and it's not helpful. It's not something that applies universally, and there's an awful lot of reasons why someone's code on GitHub might be materially better—or worse—than their work product. I think that's fine. It's just a different path toward it.Emma: I don't use GitHub for largely anything except just keeping repositories that I need. I don't actively update it. And I have, like, a few thousand followers; I'm like, “Why the hell do you guys follow me? I don't do anything.” It's honestly a terrible representation.That being said, you don't need to have a GitHub repository—an active one—to showcase your skills. There are many other ways that you can show a potential employer, “Hey, I have a lot of skills that aren't necessarily showcased on my resume, but I like to write blogs, I like to give tech talks, I like to make YouTube videos,” things of that nature.Corey: I had a manager once who refused to interview anyone who didn't have a built-out LinkedIn profile, which is also one of these bizarre things. It's, yeah, a lot of people don't feel the need to have a LinkedIn profile, and that's fine. But the idea that, “Oh, yeah, they have this profile they haven't updated in a couple years, it's clearly they're not interested in looking for work.” It's, yeah. Maybe—just a thought here—your ability to construct a resume and build it out in the way that you were expecting is completely orthogonal to how effective they might be in the role. The idea that someone not having a LinkedIn profile somehow implies that they're sketchy is the wrong lesson to take from all of this. That site is terrible.Emma: Especially when you consider the fact that LinkedIn is primarily used in the United States as a social—not social networking—professional networking tool. In Germany, they use Xing as a platform; it's very similar to LinkedIn, but my point is, if you're solely looking at someone's LinkedIn as a representation of their ability to do a job, you're missing out on many candidates from all over the world. And also those who, yeah, frankly, just don't—like, they have more important things to be doing than updating their LinkedIn profile. [laugh].Corey: On some level, it's the idea of looking at a consultant, especially independent consultant type, when their website is glorious and up-to-date and everything's perfect, it's, oh, you don't really have any customers, do you? As opposed to the consultants you know who are effectively sitting there with a waiting list, their website looks like crap. It's like, “Is this Geocities?” No. It's just that they're too busy working on the things that bring the money instead of the things that bring in business, in some respects.Let's face it, websites don't. For an awful lot of consulting work, it's word of mouth. I very rarely get people finding me off of Google, clicking a link, and, “Hey, my AWS bill is terrible. Can you help us with it?” It happens, but it's not something that happens so frequently that we want to optimize for it because that's not where the best customers have been coming from. Historically, it's referrals, it's word of mouth, it's people seeing the aggressive shitposting I engage in on Twitter and saying, “Oh, that's someone that should help me with my Amazon bill.” Which I don't pretend to understand, but I'm still going to roll with it.Emma: You had mentioned something about passion earlier, and I just want to say, if you're a hiring manager or recruiter, you shouldn't solely be looking at candidates who superficially look like they're passionate about what they do. Yes, that is—it's important, but it's not something that—like, I don't necessarily choose one candidate over the other because they push commits, and open pull requests on GitHub, and open-source, and stuff. You can be passionate about your job, but at the end of the day, it's still a job. For me, would I be working if I had to? No. I'd be opening a bookstore because that's what I would really love to be doing. But that doesn't mean I'm not passionate about my job. I just show it in different ways. So, just wanted to put that out there.Corey: Oh, yeah. The idea that you must eat, sleep, live, and breathe is—hell with that. One of the reasons that we get people to work here at The Duckbill Group is, yeah, we care about getting the job done. We don't care about how long it takes or when you work; it's oh, you're not feeling well? Take the day off.We have very few things that are ‘must be done today' style of things. Most of those tend to fall on me because it's giving a talk at a conference; they will not reschedule the conference for you. I've checked. So yeah, that's important, but that's not most days.Emma: Yeah. It's like programming is my job, it's not my identity. And it's okay if it is your primary hobby if that is how you identify, but for me, I'm a person with actual hobbies, and, you know, a personality, and programming is just a job for me. I like my job, but it's just a job.Corey: And on the side, you do interesting things like wrote a book. You mentioned earlier that it wound up paying off some debt and helping cover your move across an ocean. Let's talk a little bit about that because I'm amenable to the idea of side projects that accidentally have a way of making money. That's what this podcast started out as. If I'm being perfectly honest, and started out as something even more self-serving than that.It's, well if I reach out to people in this industry that are doing interesting things and ask them to grab a cup of coffee, they'll basically block me, whereas if I ask them to, would you like to appear on my podcast, they'll clear time on their schedule. I almost didn't care if my microphone was on or not when I was doing these just because it was a chance to talk to really interesting people and borrow their brain, people reached out asking they can sponsor it, along with the newsletter and the rest, and it's you want to give me money? Of course, you can give me money. How much money? And that sort of turned into a snowball effect over time.Five years in, it's turned into something that I would never have predicted or expected. But it's weird to me still, how effective doing something you're actually passionate about as a side project can sort of grow wings on its own. Where do you stand on that?Emma: Yeah, it's funny because with the exception of the online courses that I've worked with—I mentioned LinkedIn Learning and Frontend Masters, which I knew were paid opportunities—none of my side projects started out for financial reasonings. The podcast that we started was purely for fun, and the sponsors came to us. Now, I will say right up front, we all had pretty big social media followings, and my first piece of advice to anyone looking to get into side projects is, don't focus so much on making money at the get-go. Yes, to your point, Corey, focus on the stuff you're passionate about. Focus on engaging with people on social media, build up your social media, and at that point, okay, monetization will slowly find its way to you.But yeah, I say if you can monetize the heck out of your work, go for it. But also, free content is also great. I like to balance my paid content with my free content because I recognize that not everyone can afford to pay for some of this information. So, I generally always have free alternatives. And for this book that we published, one of the things that was really important to me was keeping it affordable.The first publish I did was $10 for the book. It was like a 250-page book. It was, like, $10 because again, I was not in it for the money. And when I redid the book with the egghead.io team, the same team that did Epic React with Kent C. Dodds, I said, “I want to keep this affordable.” So, we made sure it was still affordable, but also that we had—what's it called? Parity pricing? Pricing parity, where depending on your geographic location, the price is going to accommodate for how the currency is doing. So, yes, I would agree. Side project income for me allows me to do incredible stuff, but it wasn't why I got into it in the first place. It was genuinely just a nice-to-have.Corey: I haven't really done anything that asks people for money directly. I mean, yeah, I sell t-shirts on the website, and mugs, and drink umbrellas—don't get me started—but other than that and the charity t-shirt drive I do every year, I tend to not be good at selling things that don't have a comma in the price tag. For me, it was about absolutely building an audience. I tend to view my Twitter follower count as something of a proxy for it, but the number I actually care about, the audience that I'm focused on cultivating, is newsletter subscribers because no social media platform that we've ever seen has lasted forever. And I have to imagine that Twitter will one day wane as well.But email has been here since longer than we'd been alive, and by having a list of email addresses and ways I can reach out to people on an ongoing basis, I can monetize that audience in a more direct way, at some point should I need them to. And my approach has been, well, one, it's a valuable audience for some sponsors, so I've always taken the asking corporate people for money is easier than asking people for personal money, plus it's a valuable audience to them, so it tends to blow out a number of the metrics that you would normally expect of, oh, for this audience size, you should generally be charging Y dollars. Great. That makes sense if you're slinging mattresses or free web hosting, but when it's instead, huh, these people buy SaaS enterprise software and implement it at their companies, all of economics tend to start blowing apart. Same story with you in many respects.The audience that you're building is functionally developers. That is a lucrative market for the types of sponsors that are wise enough to understand that—in a lot of cases these days—which product a company is going to deploy is not dictated by their exec so much as it is the bottom-up adoption path of engineers who like the product.Emma: Mm-hm. Yeah, and I think once I got to maybe around 10,000 Twitter followers is when I changed my mentality and I stopped caring so much about follower count, and instead I just started caring about the people that I was following. And the number is a nice-to-have but to be honest, I don't think so much about it. And I do understand, yes, at that point, it is definitely a privilege that I have this quote-unquote, “Platform,” but I never see it as an audience, and I never think about that “Audience,” quote-unquote, as a marketing platform. But it's funny because there's no right or wrong. People will always come to you and be like, “You shouldn't monetize your stuff.” And it's like—Corey: “Cool. Who's going to pay me then? Not you, apparently.”Emma: Yeah. It's also funny because when I originally sold the book, it was $10 and I got so many people being like, “This is way too cheap. You should be charging more.” And I'm like, “But I don't care about the money.” I care about all the people who are unemployed and not able to survive, and they have families, and they need to get a job and they don't know how.That's what I care about. And I ended up giving away a lot of free books. My mantra was like, hey if you've been laid off, DM me. No questions asked, I'll give it to you for free. And it was nice because a lot of people came back, even though I never asked for it, they came back and they wanted to purchase it after the fact, after they'd gotten a job.And to me that was like… that was the most rewarding piece. Not getting their money; I don't care about that, but it was like, “Oh, okay. I was actually able to help you.” That is what's really the most rewarding. But yeah, certainly—and back really quickly to your email point, I highly agree, and one of the first things that I would recommend to anyone looking to start a side product, create free content so that you have a backlog that people can look at to… kind of build trust.Corey: Give it away for free, but also get emails from people, like a trade for that. So, it's like, “Hey, here's a free guide on how to start a podcast from scratch. It's free, but all I would like is your email.” And then when it comes time to publish a course on picking the best audio and visual equipment for that podcast, you have people who've already been interested in this topic that you can now market to.This episode is sponsored by our friends at Oracle Cloud. Counting the pennies, but still dreaming of deploying apps instead of "Hello, World" demos? Allow me to introduce you to Oracle's Always Free tier. It provides over 20 free services and infrastructure, networking databases, observability, management, and security.And - let me be clear here - it's actually free. There's no surprise billing until you intentionally and proactively upgrade your account. This means you can provision a virtual machine instance or spin up an autonomous database that manages itself all while gaining the networking load, balancing and storage resources that somehow never quite make it into most free tiers needed to support the application that you want to build.With Always Free you can do things like run small scale applications, or do proof of concept testing without spending a dime. You know that I always like to put asterisks next to the word free. This is actually free. No asterisk. Start now. Visit https://snark.cloud/oci-free that's https://snark.cloud/oci-free.Corey: I'm not sitting here trying to judge anyone for the choices that they make at all. There are a lot of different paths to it. I'm right there with you. One of the challenges I had when I was thinking about, do I charge companies or do I charge people was that if I'm viewing it through a lens of audience growth, well, what stuff do I gate behind a paywall? What stuff don't I? Well, what if I just—Emma: Mm-hm.Corey: —gave it all away? And that way I don't have to worry about the entire class of problems that you just alluded to of, well, how do I make sure this is fair? Because a cup of coffee in San Francisco is, what, $14 in some cases? Whereas that is significant in places that aren't built on an economy of foolishness. How do you solve for that problem? How do you deal with the customer service slash piracy issues slash all the other nonsense? And it's just easier.Emma: Yeah.Corey: Something I've found, too, is that when you're charging enough money to companies, you don't have to deal with an entire class of customer service problem. You just alluded to the other day that well, you had someone who bought your book and was displeased that it wasn't a how to write code from scratch tutorial, despite the fact that he were very clear on what it is and what it isn't. I don't pretend to understand that level of entitlement. If I spend 10 or 20 bucks on an ebook, and it's not very good, let's see, do I wind up demanding a refund from the author and making them feel bad about it, or do I say, “The hell with it.” And in my case, I—there is privilege baked into this; I get that, but it's I don't want to make people feel bad about what they've built. If I think there's enough value to spend money on it I view that as a one-way transaction, rather than chasing someone down for three months, trying to get a $20 refund.Emma: Yeah, and I think honestly, I don't care so much about giving refunds at all. We have a 30-day money-back guarantee and we don't ask any questions. I just asked this person for feedback, like, “Oh, what was not up to par?” And it was just, kind of like, BS response of like, “Oh, I didn't read the website and I guess it's not what I wanted.” But the end of the day, they still keep the product.The thing is, you can't police all of the people who are going to try to get your content for free if you're charging for it; it's part of it. And I knew that when I got into it, and honestly, my thing is, if you are circulating a book that helps you get a job in tech and you're sending it to all your friends, I'm not going to ask any questions because it's very much the sa—and this is just my morals here, but if I saw someone stealing food from a grocery store, I wouldn't tell on them because at the end of the day, if you're s—Corey: Same story. You ever see someone's stealing baby formula from a store? No, you didn't.Emma: Right.Corey: Keep walking. Mind your business.Emma: Exactly. Exactly. So, at the end of the day, I didn't necessarily care that—people are like, “Oh, people are going to share your book around. It's a PDF.” I'm like, “I don't care. Let them. It is what it is. And the people who wants to support and can, will.” But I'm not asking.I still have free blogs on data structures, and algorithms, and the interview stuff. I do still have content for free, but if you want more, if you want my illustrated diagrams that took me forever with my Apple Pencil, fair enough. That would be great if you could support me. If not, I'm still happy to give you the stuff for free. It is what it is.Corey: One thing that I think is underappreciated is that my resume doesn't look great. On paper, I have an eighth-grade education, and I don't have any big tech names on my resume. I have a bunch of relatively short stints; until I started this place, I've never lasted more than two years anywhere. If I apply through the front door the way most people do for a job, I will get laughed out of the room by the applicant tracking system, automatically. It'll never see a human.And by doing all these side projects, it's weird, but let's say that I shut down the company for some reason, and decide, ah, I'm going to go get a job now, my interview process—more or less, and it sounds incredibly arrogant, but roll with it for a minute—is, “Don't you know who I am? Haven't you heard of me before?” It's, “Here's my website. Here's all the stuff I've been doing. Ask anyone in your engineering group who I am and you'll see what pops up.”You're in that same boat at this point where your resume is the side projects that you've done and the audience you've built by doing it. That's something that I think is underappreciated. Even if neither one of us made a dime through direct monetization of things that we did, the reputational boost to who we are and what we do professionally seems to be one of those things that pays dividends far beyond any relatively small monetary gain from it.Emma: Absolutely, yeah. I actually landed my job interview with Spotify through Twitter. I was contacted by a design systems manager. And I was in the interview process for them, and I ended up saying, “You know, I'm not ready to move to Stockholm. I just moved to Germany.”And a year later, I circled back and I said, “Hey, are there any openings?” And I ended up re-interviewing, and guess what? Now, I have a beautiful home with my soulmate and we're having a child. And it's funny how things work out this way because I had a Twitter account. And so don't undervalue [laugh] social media as a tool in lieu of a resume because I don't think anyone at Spotify even saw my resume until it actually accepted the job offer, and it was just a formality.So yeah, absolutely. You can get a job through social media. It's one of the easiest ways. And that's why if I ever see anyone looking for a job on Twitter, I will retweet, and vouch for them if I know their work because I think that's one of the quickest ways to finding an awesome candidate.Corey: Back in, I don't know, 2010, 2011-ish. I was deep in the IRC weed. I was network staff on the old freenode network—not the new terrible one. The old, good one—and I was helping people out with various things. I was hanging out in the Postfix channel and email server software thing that most people have the good sense not to need to know anything about.And someone showed up and was asking questions about their config, and I was working with them, and teasing them, and help them out with it. And at the end of it, his comment was, “Wow, you're really good at this. Any chance you'd be interested in looking for jobs?” And the answer was, “Well, sure, but it's a global network. Where are you?”Well, he was based in Germany, but he was working remotely for Spotify in Stockholm. A series of conversations later, I flew out to Stockholm and interviewed for a role that they decided I was not a fit for—and again, they're probably right—and I often wonder how my life would have gone differently if the decision had gone the other way. I mean, no hard feelings, please don't get me wrong, but absolutely, helping people out, interacting with people over social networks, or their old school geeky analogs are absolutely the sorts of things that change lives. I would never have thought to apply to a role like that if I had been sitting here looking at job ads because who in the world would pick up someone with relatively paltry experience and move them halfway around the world? This was like a fantasy, not a reality.Emma: [laugh].Corey: It's the people you get to know—Emma: Yeah.Corey: —through these social interactions on various networks that are worth… they're worth gold. There's no way to describe it other than that.Emma: Yeah, absolutely. And if you're listening to this, and you're discouraged because you got turned down for a job, we've all been there, first of all, but I remember being disappointed because I didn't pass my first round of interviews of Google the first time I interviewed with them, and being, like, “Oh, crap, now I can't move to Munich. What am I going to do with my life?” Well, guess what, look where I am today. If I had gotten that job that I thought was it for me, I wouldn't be in the happiest phase of my life.And so if you're going through it—obviously, in normal circumstances where you're not frantically searching for a job; if you're in more of a casual life job search—and you've been let go from the process, just realize that there's probably something bigger and better out there for you, and just focus on your networking online. Yeah, it's an invaluable tool.Corey: One time when giving a conference talk, I asked, “All right, raise your hand if you have never gone through a job interview process and then not been offered the job.” And a few people did. “Great. If your hand is up, aim higher. Try harder. Take more risks.”Because fundamentally, job interviews are two-way streets and if you are only going for the sure thing jobs, great, stretch yourself, see what else is out there. There's no perfect attendance prize. Even back in school there wasn't. It's the idea of, “Well, I've only ever taken the easy path because I don't want to break my streak.” Get over it. Go out and interview more. It's a skill, unlike most others that you don't get to get better at unless you practice it.So, you've been in a job for ten years, and then it's time to move on—I've talked to candidates like this—their interview skills are extremely rusty. It takes a little bit of time to get back in the groove. I like to interview every three to six months back when I was on the job market. Now that I, you know, own the company and have employees, it looks super weird if I do it, but I miss it. I miss those conversations. I miss the aspects—Emma: Yes.Corey: —of exploring what the industry cares about.Emma: Absolutely. And don't underplay the importance of studying the foundational language concepts. I see this a lot in candidates where they're so focused on the newest and latest technologies and frameworks, that they forgot foundational JavaScript, HTML, and CSS. Many companies are focused primarily on these plain language concepts, so just make sure that when you are ready to get back into interviewing and enhance that skill, that you don't neglect the foundation languages that the web is built on if you're a web developer.Corey: I'd also take one last look around and realize that every person you admire, every person who has an audience, who is a known entity in the space only has that position because someone, somewhere did them a favor. Probably lots of someones with lots of favors. And you can't ever pay those favors back. All you can do is pay it forward. I repeatedly encourage people to reach out to me if there's something I can do to help. And the only thing that surprises me is how few people in the audience take me up on that. I'm talking to you, listener. Please, if I can help you with something, please reach out. I get a kick out of doing that sort of thing.Emma: Absolutely. I agree.Corey: Emma, thank you so much for taking the time to speak with me today. If people want to learn more, where can they find you?Emma: Well, you can find me on Twitter. It's just @EmmaBostian, I'm, you know, shitposting over there on the regular. But sometimes I do tweet out helpful things, so yeah, feel free to engage with me over there. [laugh].Corey: And we will, of course, put a link to that in the [show notes 00:35:42]. Thank you so much for taking the time to speak with me today. I appreciate it.Emma: Yeah. Thanks for having me.Corey: Emma Bostian, software engineer at Spotify and oh, so very much more. I'm Cloud Economist Corey Quinn, and this is Screaming in the Cloud. If you've enjoyed this podcast, please leave a five-star review on your podcast platform of choice, whereas if you've hated this podcast, please leave a five-star review on your podcast platform of choice, along with an incoherent ranting comment mentioning that this podcast as well failed to completely teach you JavaScript.Corey: If your AWS bill keeps rising and your blood pressure is doing the same, then you need The Duckbill Group. We help companies fix their AWS bill by making it smaller and less horrifying. The Duckbill Group works for you, not AWS. We tailor recommendations to your business and we get to the point. Visit duckbillgroup.com to get started.Announcer: This has been a HumblePod production. Stay humble.

We sat down with Kent C. Dodds to talk about his mission to improve the world with quality software. Kent has content on Egghead.io and Frontend Masters he also created Testing JavaScript and Epic React. In this episode, we talk about what it's like to teach software development, and, one of our favorite topics of discussion, creating quality content. Listen wherever you get your podcasts and be sure to check out the video recording on our YouTube channel (https://www.youtube.com/watch?v=efw1wQ9VUZU). Links https://kentcdodds.com (https://kentcdodds.com) https://twitter.com/kentcdodds (https://twitter.com/kentcdodds) https://egghead.io/q/resources-by-kent-c-dodds (https://egghead.io/q/resources-by-kent-c-dodds) https://frontendmasters.com/teachers/kentcdodds (https://frontendmasters.com/teachers/kentcdodds) https://testingjavascript.com (https://testingjavascript.com) https://epicreact.dev (https://epicreact.dev) https://github.com/testing-library/react-testing-library (https://github.com/testing-library/react-testing-library) https://www.goodreads.com/book/show/18770267-make-it-stick (https://www.goodreads.com/book/show/18770267-make-it-stick) https://kentcdodds.com/chats-with-kent-podcast (https://kentcdodds.com/chats-with-kent-podcast) https://kentcdodds.com/office-hours (https://kentcdodds.com/office-hours) https://kentcdodds.com/discord (https://kentcdodds.com/discord) Contact us https://podrocket.logrocket.com/contact-us (https://podrocket.logrocket.com/contact-us) @PodRocketpod (https://twitter.com/PodRocketpod) What does LogRocket do? LogRocket combines frontend monitoring, product analytics, and session replay to help software teams deliver the ideal product experience. Try LogRocket for free today (https://logrocket.com/signup/?pdr). Special Guest: Kent C. Dodds.

Sara Vieira (@NikkitaFTW) is here to talk TypeScript... and why you shouldn't use it everywhere. We also reminiscence about Angular 1, explain The WordPress Problem...and maybe sing some Linkin Park. Transcript: Coming soon! Show notes: Okay, I say TypeScript weird... Loved this course: https://www.executeprogram.com/courses/typescript Mike North's TS course on Frontend Masters: https://frontendmasters.com/courses/typescript-v2/ Effective TypeScript: https://effectivetypescript.com/ --- Support this podcast: https://anchor.fm/single-threaded/support

Richard Feldman - author of Elm in Action - joins the Rogues to discuss the advantages of Functional Programming and using Elm. Elm is a programming language that is a functional programming language built for the front-end that compiles to JavaScript. Due to its set of enforced assumptions, it leads to clean code and powerful programming constructs. Panel John Epperson Luke Stutters Guest Richard Feldman Sponsors  Raygun | Click here to get started on your free 14-day trial Links Vue.js GitHub- NoRedInk/elm-rails ELM Homepage Discourse ELM ELM Slack Built with Elm Picks John- GitHub: spree/spree John- GitHub: solidusio/solidus John- Merlin Series (The Lost Years by T.A.) Luke- PQINA | Designs and Builds Performant, Responsive, and Highly Polished Web Components Richard- TV series: Battlestar Galactica Richard- Frontend Masters Richard- Barbell medicine

Richard Feldman - author of Elm in Action - joins the Rogues to discuss the advantages of Functional Programming and using Elm. Elm is a programming language that is a functional programming language built for the front-end that compiles to JavaScript. Due to its set of enforced assumptions, it leads to clean code and powerful programming constructs. Panel John Epperson Luke Stutters Guest Richard Feldman Sponsors  Raygun | Click here to get started on your free 14-day trial Links Vue.js GitHub- NoRedInk/elm-rails ELM Homepage Discourse ELM ELM Slack Built with Elm Picks John- GitHub: spree/spree John- GitHub: solidusio/solidus John- Merlin Series (The Lost Years by T.A.) Luke- PQINA | Designs and Builds Performant, Responsive, and Highly Polished Web Components Richard- TV series: Battlestar Galactica Richard- Frontend Masters Richard- Barbell medicine

Richard Feldman - author of Elm in Action - joins the Rogues to discuss the advantages of Functional Programming and using Elm. Elm is a programming language that is a functional programming language built for the front-end that compiles to JavaScript. Due to its set of enforced assumptions, it leads to clean code and powerful programming constructs. Panel John Epperson Luke Stutters Guest Richard Feldman Sponsors  Raygun | Click here to get started on your free 14-day trial Links Vue.js GitHub- NoRedInk/elm-rails ELM Homepage Discourse ELM ELM Slack Built with Elm Picks John- GitHub: spree/spree John- GitHub: solidusio/solidus John- Merlin Series (The Lost Years by T.A.) Luke- PQINA | Designs and Builds Performant, Responsive, and Highly Polished Web Components Richard- TV series: Battlestar Galactica Richard- Frontend Masters Richard- Barbell medicine

Richard Feldman - author of Elm in Action - joins the Rogues to discuss the advantages of Functional Programming and using Elm. Elm is a programming language that is a functional programming language built for the front-end that compiles to JavaScript. Due to its set of enforced assumptions, it leads to clean code and powerful programming constructs. Panel John Epperson Luke Stutters Guest Richard Feldman Sponsors  Raygun | Click here to get started on your free 14-day trial Links Vue.js GitHub- NoRedInk/elm-rails ELM Homepage Discourse ELM ELM Slack Built with Elm Picks John- GitHub: spree/spree John- GitHub: solidusio/solidus John- Merlin Series (The Lost Years by T.A.) Luke- PQINA | Designs and Builds Performant, Responsive, and Highly Polished Web Components Richard- TV series: Battlestar Galactica Richard- Frontend Masters Richard- Barbell medicine

Welcome to another episode of Develomentor. Today's guest is Kent C. Dodds!Kent C. Dodds is a world renowned speaker, teacher, and trainer and he’s actively involved in the open source community as a maintainer and contributor of hundreds of popular npm packages. Kent is the creator of TestingJavaScript.com and he’s an instructor on egghead.io and Frontend Masters. He’s also a Google Developer Expert. Kent is happily married and the father of four kids. He likes his family, code, JavaScript, and React.If you are enjoying our content please leave us a rating and review or consider supporting usA note from GrantAfter considering a career as an accountant, some time spent as a missionary and a small business owner digitizing compact discs, Kent C. Dodds has steadily spent the last decade building up a career as a web developer and software engineer for the likes of USAA, Domo, The Church of Jesus Christ of Latter-Day Saints, and Paypal. These days, Kent is on his own as a world renowned speaker, teacher and trainer on software and software quality, especially in the Javascript and frontend development space. His work can be found on several leading sites like egghead.io, Frontend Masters and his very own EpicReact.dev and TestingJavaScript.com. In addition to all that great educational content, Kent also is an active contributor and maintainer of hundreds of popular open source Javascript libraries. -Grant IngersollQuotes“I ended up switching from accounting to information systems which is in the business school. II still wasn’t convinced that I wanted to program. But I thought ‘hey I really enjoy computers, I’m really good at these computer things, and business seems interesting.’”“I think that’s what got me started into UI was just that really quick feedback cycle of seeing the impact of the changes I was making.”“Right around the time I graduated from college I started making videos for egghead. My first course I created was using JWTs with AngularJS. And My first month I got my royalty check and it paid my mortgage for that month. And it did so thereafter.”—Kent C. DoddsYou can find more resources in the show notesTo learn more about our podcast go to https://develomentor.com/To listen to previous episodes go to https://develomentor.com/blog/Connect with Kent C. DoddsLinkedInTwitterFollow DevelomentorTwitter: @develomentorSupport the show (https://www.patreon.com/develomentor)

elm-spaRichard Feldman's elm-spa-example GitHub repoElm's Browser.applicationUrl.Parser - URL parsing in Elm for routing single-page appselm-shared-state pattern (formerly called elm-taco)Next.js and NuxtJSRouting and dynamic routing in elm-spaScaling Elm Apps talk - Elm Europe keynote by Richard FeldmanGetting Started ResourcesOffical elm-spa Guide#elm-spa-users channel on the official Elm slackelm-spa-realworld (Ryan's version of elm-spa-example using his elm-spa framework)Exploring elm-spa example - Richard's conference talk walking through codebaseRichard's Frontend Masters courses focus heavily on his elm-spa-example repoElm Radio Episode 7: Extending Elm

Kadi talks to me about her React Native course on Frontend Masters, and her career as an engineer. Kadi is a senior engineer and engineering manager at Formidable Labs. Find Kadi on Twitter — https://twitter.com/kadikraman How to publish an NPM package — https://dev.to/kadikraman/an-open-source-maintainer-s-guide-to-publishing-npm-packages-1218 Kadi's React Native course on Frontend Masters — https://frontendmasters.com/courses/react-native-v2/ --- Send in a voice message: https://anchor.fm/work-in-programming/message

This week we had the pleasure of speaking with the creator of Svelte, Rich Harris. The topics of the podcast can be seen below but first we have a big announcement! TypeScript support for Svelte is finally, officially here! Hallelujah! Links and other fun stuff: Frontend Masters course by Rich Harris Svite Pancake and Layercake MalinaJS Picks (amazon affiliate links): The Executioner Raspberry Pi 4 Microsoft Sculpt Volumio

Guest: Philip Poots: GitHub | ClubCollect Previous Episode: 056: Ember vs. Elm: The Showdown with Philip Poots In this episode, Philip Poots joins the show again to talk about the beauty of simplicity, the simplicity and similarities between Elm and Ruby programming languages, whether Elixir is a distant cousin of the two, the complexity of Ember and JavaScript ecosystems (Ember helps, but is fighting a losing battle), static vs. dynamic, the ease of Rails (productivity), and the promise of Ember (productivity, convention). The panel also talks about the definition of "quality", making code long-term maintainable, and determining what is good vs. what is bad for your codebase. Resources: Michel Martens mote Learn the Elm Programming Language and Build Error-Free Apps with Richard Feldman Worse is Better: Richard P. Gabriel Gary Bernhardt's Destroy All Software Screencasts Zen and the Art of Motorcycle Maintenance: An Inquiry into Values The Calm Company It Doesn't Have to Be Crazy at Work This show was produced by Mandy Moore, aka @therubyrep of DevReps, LLC. Transcript: CHARLES:: Hello, everybody and welcome to The Frontside Podcast, Episode 113. My name is Charles Lowell. I'm a developer here at the Frontside and with me today are Taras Mankovski and David Keathley. Hello? DAVID:: Hey, guys. TARAS: Hello, hello. CHARLES:: And we're going to be talking with a serial guest on our serial podcast, Mr Philip Poots, who is the VP of engineering at ClubCollect. Welcome, Philip. PHILIP: Hey, guys. Thanks for having me on. CHARLES:: Yeah. I'm actually excited to have you on. We've had you on a couple of times before. We've been trying to get you on the podcast, I think for about a year, to talk about I think what has kind of a unique story in programming these days. The prevailing narrative is that folks start off with some language that's dynamically typed and object oriented and then at some point, they discover functional programming and then at some point, they discover static programming and they march off into a promised land of Nirvana and no bugs ever, ever happening again. It seems like it's pretty much a straight line from that point to the next point and passing through those way stations. When I talk to you, I guess... Gosh, I think you were the first person that really introduced me to Elm back at Wicked Good Ember in 2016 and it seemed like you were kind of following that arc but actually, that was a bit deceptive because then the next time I talked to you, you were saying, "No, man. I'm really into Ruby and kind of diving in and trying to get into Ruby again," and I was kind of like, "Record scratch." You're kind of jumping around the points. You're not following the preordained story arc. What is going on here? I just kind of wanted to have a conversation about that and find out what the deal was and then, what's kind have guided your journey. PHILIP: There was one event and that was ElmConf Europe, which was a fantastic conference. Really, one of the best conferences I've been to, just because I guess with the nature of early language, small conference environment. There's just a lot of things happening. There's a lot of people. Evan was there, Richard Feldman was there, the leading lights of the Elm community were there and it was fantastic. But I guess, one thing that people have always said to me is the whole way track is the best track of the conference and it's not something I really appreciated before and during the breaks, I ended up talking to a guy called Michel Martens. He is the finder of a Redis sourcing company and I guess, this was just a revelation to me. He was interested in Elm. He was friends with the guys that organized the conference and we got talking and he was like, "I do this in Ruby. I do this in Ruby. I did this in Ruby," and I was like, "What?" and he was like, "Yeah, yeah, yeah." He's a really, really humble guy but as soon as I got home, I checked him out. His GitHub is 'soveran' and it turns out he's written... I don't know, how many gems in Ruby, all with really well-chosen names, very short, very clear, very detailed. The best thing about his libraries is you can print them out on paper. What I mean by that is they were tiny. They were so small and I guess, I just never seen that before. I go into Ruby on Rails -- that was my first exposure to programming, that was my first exposure to everything -- unlike with Rails, often when you hit problems, you'd start to dive a bit deeper and ultimately, you dive so deep that you sunk essentially and you just accepted, "Okay, I'm not going to bend the framework that way this time. Let's figure out how everyone else goes with the framework and do that." Then with Ember when I moved into frontend, that was a similar thing. There were so many layers of complexity that I never felt like had a real handle on it. I kind of just thought this was the way things were. I thought it's always going to be complex. That's just the nature of the problem. That's just the problem they're trying to solve. It's a complex problem and therefore, that complexity is necessary. But it was Elm that taught me, I think that choosing the right primitives and thinking very carefully about the problem can actually give you something that's quite simple but incredibly powerful. Not only something quite simple but something so simple that it can fit inside your head, like this concept of a program fitting inside your head and Rails, I don't know how many heads I need to fit Rails in or Ember for that matter and believe me, I tried it but with Elm, there was that simplicity. When I came across this Ruby, a language I was very familiar with but this Ruby that I had never seen before, a clear example was a templating library and he calls it 'mote' and it's including comments. It's under a hundred lines of code and it does everything you would need to. Sure, there were one or two edge cases that it doesn't cover but it's like, "Let's use the trade off." It almost feels like [inaudible] because he was always a big believer in "You ain't going to need it. Let's go for that 80% win with 20% effort," and this was like that taken to the extreme. CHARLES:: I'm just curious, just to kind of put a fine point on it, it sounds like there might be more in common, like a deeper camaraderie between this style of Ruby and the style encouraged by Elm, even though that on the surface, one is a dynamically typed object oriented language and the other is a statically typed functional language and yet, there's a deeper philosophical alignment that seems like it's invisible to 99% of the discussion that happens around these languages. PHILIP: Yeah, I think so. I think the categories we and this is something Richard Feldman talks. He's a member of the Elm community. He does a lot of talks and has a course also in Frontend Masters, which I highly recommend. But he often talks about the frame of the conversation is wrong because you have good statically typed languages and you have bad statically typed languages. You have good dynamic languages and you have bad dynamic languages. For all interpretations of good and bad, right? I don't want to start any wars here. I think one of the things that Elm and Ruby have in common is the creator. Matz designed Ruby because he wanted programming to be a joy, you know? And Evan created Elm because he wanted programming to be a delight. I think if you experience both of those, like developing in both of those languages, you gain a certain appreciation for what that means. It is almost undefinable, indistinguishable, although you can see the effects of it everywhere. In Ruby, everything is an object, including nil. In Elm, it's almost he's taken everything away. Evan's taken everything away that could potentially cause you to stumble. There's a lot to learn with Elm in terms of getting your head around functional mindset and also, working with types but as far as that goes, people often call it like the Haskell Light, which I think those are a disservice to Elm because it's got different goals. CHARLES:: Yeah, you can tell that. You know, my explorations with Elm, the personality of Elm is 100% different than the personality of Haskell, if that is even a programming term that you can apply. For example, the compiler has an identity. It always talks to you in the first person, "I saw that you did this, perhaps you meant this. You should look here or I couldn't understand what you were trying to tell me." Literally that's how the Elm compiler talks to you. It actually talks to you like a person and so, it's very... Sorry, go ahead. PHILIP: No, no, I think the corollary to that is the principle of the surprise in Ruby. You know, is there going to be a method that does this? You type it out and you're like, "Oh, yes it is," which is why things like inject and reduce are both methods in enumerable. You didn't choose one over the other. It was just like, "Let's make it easy for the person who's programming to use what they know best." I think as well, maybe people don't think about this as deeply but the level of thought that Evan has put into designing Elm is crazy, like he's thought this through. I'm not sure if I said this the last time but I went to a workshop in the early days in London, which is my kind of first real exposure to Elm and Evan was giving the workshop. Someone asked him, "Why didn't you do this?" and he was like, "Well, that might be okay for now but I'm not sure that would make so much sense in 10 years," and I was kind of like, "What?" Because JavaScript and that ecosystem is something which is changing like practically hourly and this is a guy that's thinking 10 years into the future. TARAS: You might have answered it already but I'm curious of what you think is the difference, maybe it just comes down to that long term thinking but we see this in JavaScript world a lot, which is this kind of almost indifference to APIs. It almost doesn't really matter what the API is for whatever reason, there seems to be a big correlation between the API that's exposed with the popularity of the tool. I think there are some patterns, like something that's really simple, like jQuery and React have become popular because of the simplicity of their APIs. What the flip side to that? What other ways can APIs be created that we see in JavaScript world. Because we're talking about this beautiful APIs and I can relate to some of the work that Charles has been doing and I've been doing microstates but I wonder like what would be just a brief alternative to that API, so it's kind of a beautiful API. PHILIP: I don't know if anyone is familiar with the series of essays 'Worse is Better' like East Coast versus West Coast, from Richard Gabriel. The problem is, I guess and maybe this is just my understanding over my paraphrase of it, I'm not too familiar with it but I think that good APIs take time and people don't have time. If someone launches a V1 at first and it kind of does the job, people will use that over nothing and then whenever they're happy with that, they'll continue to use it and develop it and ultimately, if she's market share and then that's just the thing everyone uses and the other guy's kind of left behind like, "This is so much better." I guess this is a question, I think it was after Wicked Good Ember, I happened to be on the same trend as Tom Dale on the way back to New York and we started talking about this. I think that's his big question. I think it's also a question that still has to be answered, which is, "Will Elm ever be mainstream? Will it be the most popular thing?" aside from the question of whether it has to be or not. For me, a good APIs good design comes from understanding the problem fully -- CHARLES:: And you can understand the problem fully without time. PHILIP: Exactly and often, what happens -- at least this is what happens in my experience with the production software that I've written -- is that you don't actually understand the problem until you've developed a solution for it. Then when you've developed a solution for it, often the pressures or the commercial pressures or an open source is [inaudible] the pressures of backwards compatibility, mean that you can never refactor your way to what you think the best solution is and often, you start from scratch and the reality is people are too far away with the stuff you wrote in the past about the thing you're writing now. Those are always kind of at odds. I think there are a lot of people that are annoyed with Elm because the updates are too slow, it relies on Evan and we want to have a pool request accepted. All of the things that they don't necessarily recognize like the absence of which make Elm an Elm, if you know what I mean. The very fact that Evan does set such a high standard and does want everything to go through his personal filters because otherwise, you wouldn't gain the benefits that Elm gives you. The attention is very real in terms of I want to shift my software now and it becomes easier then. I think to go to a language like JavaScript, which has all of the escape hatches that you need, to be able to chop and change, to edit, to do what you need to do to get the job done and let's be quite honest, I think, also with Elm, that's the challenge for someone who's not an expert level like me. Once you hit a roadblock, you'll say, "Where do I go from here?" I know if I was using JavaScript, I could just like hack it and then clients are happy and everything's fine and you know there's a bit of stuff in your code that you would rather wasn't but at the end of the day, you go home and the job's done. DAVID:: Have you had to teach Elm to other people? You and I did some work like I've seen you pair with someone and guide them through the work that they needs to get done. If you had a chance to do something like that with Elm and see how that actually happens, like how do developer's mind develops as they're working through in using the tool? PHILIP: Unfortunately not. I would actually love to go through that experience. I hope none of my developers are listening to this podcast but secretly, I want to push them in the direction of Elm on the frontend. But no, but I can at least make from my own perspective. I find it very challenging at first because for me, being a Ruby developer and also, I would never say that I understood JavaScript as much as I would have liked. Coming from dynamic language, no functional experience to functional language with types, it's almost like learning a couple of different things at the same time and that was challenging. I think if I were to take someone through it, I would maybe start with a functional aspects and then move on to the type aspects or vice versa, like try and clearly breakdown and it's difficult because those two are so intertwined at some level. Gary Bernhardt of Destroy All Software Screencast, I watch quite a bit of his stuff and I had sent him an email to ask him some questions about one of the episodes that he did and he told me that he done the programming languages course, I think it's on Coursera from Daniel Grossman, so [inaudible] ML which is kind of the father of all MLs like Haskell and also Elm. I find that really helpful because he broke it down on a very basic level and his goal wasn't to teach you ML. It was to teach you functional programming. It would be a very interesting exercise, I think. I think the benefit that Elm gave you is you get to experience that delight very quickly with, "Oh, it's broken. Here's a nice message. I fix the message. It compiles. Wow, it works," and then there's a very big jump whenever you start talking about the effects. Whenever you want to actually do something like HTTP calls or dealing with the time or I guess, the impure stuff you would call in the Haskell-land and that was also kind of a bit weird. CHARLES:: Also, there's been some churn around that, right? PHILIP: That's right. When I started learning, they had signals, then they kind of pushed that all behind the scenes and made it a lot more straightforward. Then I just mastered it and I was like, "Yes, I know it," and then I was like, "All right. I don't need to know it anymore." This is the interesting thing for me because at work, most of our work now is in Elixir and Phoenix. I'm kind of picking a little bit up as I work with them. I think Elm's architecture behind the scenes is kind of based, I believe on Erlang's process model, so the idea of a mailbox and sending messages and dealing with immutable state. CHARLES:: Which is kind of ironically is very object oriented in a way, right? It's functional but also the concept of mailboxes and sending messages and essentially, if you substitute object for process, you have these thousands and thousands of processes that are sending messages back and forth to each other. PHILIP: Yeah, that's right. It's like on a grand scale, on a distributed scale. Although I wouldn't say that I'm that far with Erlang, Elixir to appreciate the reality of that yet but that's what they say absolutely. CHARLES:: Now, Phoenix and Elixir is a dynamically typed functional language. does it share the simplicity? One of the criticisms you had of Rails was that you couldn't fit it in your head. It was very difficult. Is there anything different about Elixir that kind of makes it a spirit cousin of Elm and the simple Ruby? PHILIP: I think so, yes. Absolutely. I don't think it gets to the same level but I think it's in the right direction and specifically on the framework front, it was designed specifically... I mean, in a sense it's like the anti-type to Rails because it was born out of people's frustrations with Rails. José Valim was pretty much one of Rails top core committers. Basically, every Rails application I wrote at one period, at 80% of the code written by José Valim, if you included all the gems, the device and the resourceful and all the rest of it. Elixir in many ways was born out of the kind of limitations of Ruby with Rails and Phoenix was also born out of frustrations with the complexity of Rails. While it's not as simple as say, Michel Martens' Syro which is like his web framework, which is a successor to Cuba if people have heard of that, it is a step in the right direction. I don't understand it but I certainly feel like I could. They have plug which is kind of analogous but not identical to Rack but then the whole thing is built out of plugs. I remember Yehuda Katz give a presentation like 'The Next Five Years' and essentially about Rails 3.0. This is going way back and Phoenix is in some ways the manifestation of his desire to have like the Russian doll pattern, where you could nest applications inside applications and you could have them side by side and put them inside each other and things like that. Phoenix has this concept called umbrella applications which tells that, like Ecto is a really, really nice obstruction for working with the database. CHARLES:: I see. It feels like, as opposed to being functional or static versus dynamic, the question is how do you generate your complexity? How do you cope with complexity? Because I think you touched on it at the beginning of the conversation where you thought that my problems are complex so the systems that I work with to solve those problems must necessarily also be complex. I think one of the things that I've certainly realized, kind of in the later stages of my career is that first part is true. The problems that we encounter are extremely complex but you're much better served if you actually achieve that complexity by composing radically simple systems and recombining them. To the commonality of your system is going to determine how easy it's going to work with and how well it can cope with complexity. What really drives a good system is the quality of its primitives. PHILIP: Absolutely. After ElmConf, I actually invited Michel to come to my place in the Netherlands. He live in Paris but I think he grew up Buenos Aires in Argentina. To my amazement, he said, "Yes, okay," and we spent a couple of days together and there he talked to me about Christopher Alexander and the patterns book, where patterns and design patterns actually grew out of. One of his biggest things was the code is the easiest part, like you've got to spend 80% of your time thinking deeply about the problem, like literally go outside, take long looks. I'm not sure if this is what Rich Hickey means with Hammock Driven Development. I've never actually got around to watching the talk. CHARLES:: I think it's exactly what he means. PHILIP: And he said like once you get at, the code just comes. I think Michel's work, you should really check it out. I'll send you a link to put in the show notes but everything is built out of really small libraries that do one thing and do it really well. For example, he has a library like a Redis client but the Redis client also has something called Nest, which is a way to generate the keys for nested hashes. Because that's a well-designed, the Redis client is literally just a layer on top. If you understand the primitive then, you can use the library on top really well. You can embed Syro applications within Syro applications. I guess, there you also need the luxury of time and I think this is where maybe my role as VP of engineering, which is kind of my first role of that kind, comes in here which is when you're working on the commercial pressure, try to turn around to a business guy and say, "Yes, we'll solve this problem but can we take three weeks to think about it?" It's never going to happen -- CHARLES:: No. PHILIP: Absolutely, it will never going to happen. Although the small things that I tried to do day to day now is get away from the computer, write on paper, write out the problem as you understand it, attack it from different angles, think about different viewpoints, etcetera. CHARLES:: I think if you are able to quantify the cost of not thinking about it for three weeks, then the business person that you're going to talk to is their ears are going to perk up, right? But that's so hard to do. You know, I try and make like when we're saying like, "What technologies are you going to choose? What are the long term ramifications in terms of dollars or euros or whatever currency you happen to be in for making this decision?" I wish we had more support in thinking about that but it is kind of like a one-off every time. Anyway, I'm getting a little bit off track. PHILIP: No, not at all. This is a subject I love to talk about because we kind of had a few a bit of turbulence because we thought, maybe we should get product people in, maybe we should get them a product team going and what I find was -- and this is maybe unique to the size of the company -- that actually made things a lot more difficult because you got too many heads in many ways. Sometimes, it's better to give the developer all of the context so that he can think about it and come up with the best solution because ultimately, he's the only one who can understand. I wouldn't say understands the dollars and cents but he understands the cost implications of doing it in efficient ways, which often happens when you're working in larger teams. TARAS: One thing I find really interesting about this conversation is the definition of good is really complicated here. I've observed Charles work on microstates and I work with him, like I wrote a lot of the code and we got through like five or six iterations and at every point, he got better but it is so difficult to define that. Then when you start to that conversations outside of that code context and you start to introduce business into the mix, the definition of good becomes extremely complicated. What do you think about that? How do we define it in a way? Are there cultures or engineering cultures or societal cultures that have a better definition for good that is relevant to doing quality work of this? CHARLES:: That's a deep question. PHILIP: Wow. Yeah, a really, really deep question. I think often for business, like purely commercially-driven, money-oriented good is the cheapest thing that gets the job done and often that's very short term, I think. As you alluded to Charles, that people don't think about the cost of not doing the right things, so to speak in our eyes and also, there's a huge philosophical discussion whether our definition of good as programmers and people who care about our craft is even analogous to or equal to a good in a commercial context. CHARLES:: Yes, because ultimately and this is if you have read Zen in the Art of Motorcycle Maintenance, one of the things that Pirsig talks about is what is the definition of quality. How do we define something that's good or something that's bad? One of the definitions that gets put forward is how well something is fit to purpose. Unless you understand the purpose, then you can't determine quality because the purpose defines a very rich texture, a very rich surface and so, quality is going to be the object that maps very evenly and cleanly over that surface. When it comes to what people want in a program, they're going to want very different thing. A developer might need stimulation for this is something that's very new, this is something that's going to keep my interest or it's going to be keeping my CPU max and I'm going to be learning a whole lot. A solution that actually solves for that purpose is going to be a high quality solution. Also, this is going to be fast. We're going to be able to get to market very quickly. It might be one of the purposes and so, a solution that is fast and the purpose fits so it's going to be good. Also, I think developers are just self-indulgent and looking for the next best thing in something that's going to keep their interest, although we're all guilty of that. But at the same time, we're going to be the ones maintaining software, both in our current projects and collectively when we move to a new job and we're going to be responsible for someone else's code, then we're going to be paying the cost of those decisions. We both want to minimize the pain for ourselves and minimize the pain for others who are going to be coming and working in our code to make things long term maintainable. That's one axis of purpose and therefore, an axis of quality. I think in order to measure good and bad, you really have to have a good definition of what is the purpose of that surface is so rich but the more you can map it and find out where the contours lie, the more you're going to be able to determine what's good and what's bad. TARAS: It makes me think of like what is a good hammer. A sledgehammer is a really good hammer but it's not the right hammer for every job. CHARLES:: Right. TARAS: I think what you're saying is understanding what is it that you're actually doing and then matching your solution to what you're actually trying to accomplish. PHILIP: Yeah, absolutely and in my experience, we have a Ruby team building a Rails application. That's our monolith and then, we have a couple of Elixir teams with services that have been spun out of that. This isn't proven. This is just kind of gut feel right now and it is that Elixir is sometimes slower to develop the same feature or ship it but in the long term it's more maintainable. I haven't actually gotten dived into to React and all of the amazing frameworks that it has in terms of getting things up and running quickly but in terms of the full scale application, I still think 10, 11 years on, Rails has no equal in terms of proving a business case in the shortest time possible. CHARLES:: Yeah. I feel very similarly too but the question is does your development team approach the problem as proving a business case or do they approach the problem as I want to solve the set of features? PHILIP: Yes. Where I'm working at the moment, I started out just as a software developer. I guess, we would qualify for 37 signals or sorry... base camps definition of a calm company -- CHARLES:: Of a what company? PHILIP: A calm company. Sorry. They just released a new book and called 'The Calm Company' and 'It Doesn't Have to Be Crazy at Work.' I was given in my first couple of months, a problem. It was business oriented, it had to be solved but it had to be solved well from a technical perspective because we didn't want to have to return to it every time. It was standardizing the way that we exported data from the database to Excel. You know, I was amazed because it was literally, the first time that I'd been given the space to actually dive in on a technical level to do that kind of stuff. But I think even per feature, that varies and that sometimes challenging when handing the work on because you've got to say, "This fit. Literally, we're just trying to prove, whether if we have this feature, the people will use it?" versus, "This is a feature that's going to be used every day and therefore, needs to be at good, technical quality." Those are the tradeoffs that I guess, keep you in a job. Because if it was easy, then you would need anyone to figure it out but it's always a challenge. What I like is that our tools are actually getting better and I think, with Elm for example, it's kind of major selling point is maintainability and yet, with Elm, there haven't been that many companies with Elm over a period of years that exists, that can live to tell the tale. Whereas, we certainly know with Rails applications have done well like Basecamp and GitHub. For sure, they can be super maintainable but the fact that it took GitHub to just moved Elm to Rails 5.0, I belief, the fact that it took them years and years and they were running off at fork of Rails 2.3, I think it shows the scale of the problem in that way. You know, Phoenix also went through a few issues, kind of moving architectures from the classic Rails to a more demand driven design model. I think we're getting there slowly, zig-zagging towards a place where we better understand how to write software to solve business problems. I guess, I was really interested in microstates when you shared it at Wicked Good Ember because that to me was attacking the problem from the right perspective. It's like given the fact that the ecosystem is always changing. How can we extract the business logic such that these changes don't affect the logic of our application? CHARLES:: Man, we got a lot to show you. It has changed quite a bit in the last two years. Hopefully, for the better. TARAS: It's been reduced and it's almost a quarter of its size while maintaining the same feature set and it's faster, it's lazier, it's better in every respect. It's just the ideas have actually been fairly consistent. It's just the implementation that's evolved. CHARLES:: Yeah, it's been quite a journey. It parallels kind of the story that we're talking about here in the sense that it really has been a search for primitives and a search for simplification. One of the things that we've been talking about, having these Ruby gems that do one thing and do it very, very, very well or the way that Elixir being architected has some very, very good primitives or Elm, the same kind of thing being spiritually aligned, even though on the surface, it might share more in common with Haskell. There's actually a deep alignment with a thing like Ruby and that's a very surprising result. I think one of the things that appeals to me about the type of functional programming that is ironically, I guess not present in Elm, where you have the concept of these type classes but I actually think, I love them for their simplicity. I've kind of become disenchanted with things like Lodash, even though they're nominally functional. The fact that you don't have things like monoid and functors and stuff is kind of first class participants in the ecosystems, means you have to have a bunch of throwaway functions. Those API surface area is very large, whereas if you do account for those things, these kind of ways of combining data and that's how you achieve your complexity, is not by a bunch of one-off methods that are like in Lodash, they're all provided for you so you don't have or have to write them yourself. That is one level of convenience but having access to five primitives, I think that's the power of the kind of the deeper functional programming types. PHILIP: And Charles, do you think that that gives you the ability to think at a higher level, about the problems that you're solving? Would you make that link? CHARLES:: Absolutely. PHILIP: So, if we're not doing that, then we're actually doing ourselves a disservice? CHARLES:: I would say so. PHILIP: Because we're actually creating complexity, where it shouldn't exist? CHARLES:: Yeah, I think if you have a more powerful primitive, you can think of things like async functions and generator functions, there's a common thread between async functions, generator functions, promises arrays and they're all functors. For me, that's a very profound realization and there might be a deeper spiritual link between say, an async function and an array in the same way that there's a deep spiritual link between Ruby and Elm, that if you don't see that, then you're doing yourself a disservice and you're able to think at a higher level. Also, you have a smaller tool set where each tool is more powerful. PHILIP: You did a grit, I think it was a repository with a ReadMe, where you boiled down what people would term what I would term, the scary functional language down to a very simple JavaScript. Did you ever finish that? Did you get to the monads? CHARLES:: I did get to the monads, yeah. PHILIP: Okay. I need to check that out again. I find that really, really helpful because I think one of Evan's big things with Elm is he doesn't use those terms ever and he avoids them like the plague because I think he believes they come tinged with the negative experiences of people trying Haskell and essentially getting laughed at, right? CHARLES:: Yes. I think there's something to that. TARAS: But we're doing that in microstates as well, right? In microstates documentation, even though microstates are written completely with these functional primitives, on the outside, there's almost no mention of it. It's just that when you actually go to use it, if you have an idea, one of the thing that's really powerful with microstates is that this idea that you can return another microstate from a transition and what that will do is what you kind of like what a flat map would do, which is replace that particular node with the thing that you returned it with. For a lot of people, they might not know that that's like a flat map would do but a microstate will do exactly what they wanted to do when it didn't realize that's actually should just work like that. I think, a lot of the work that we've done recently is to package all things and it make it powerful and to access the concepts that it is very familiar, something you don't need to learn. You just use it and it just works for you. CHARLES:: Right but it is something that I feel like there's unharvested value for every programmer out there in these type classes: monads and monoids and functors and co-functors or covariant functors, contravariant functors, blah-blah-blah, that entire canon. I wish there was some way to reconcile the negative connotations and baggage that that has because we feel kind of the same way and I think that Evan's absolutely right. You do want to hide that or make it so that the technology is accessible without having to know those things. But in the same way, these concepts are so powerful, both in terms of just having to think less and having to write less code but also, as a tool to say, "I've got this process. Is there any way that could it be a functor? If I can find a way that this thing is a functor, I can just save myself so much time and take so many shortcuts with it." PHILIP: And in order to be able to communicate that, or at least communicate about that, you need to have terms to call these things, right? Because you can't always just refer to the code or the pattern. It's always good to have a name. I'm with you. I see value in both, like making it approachable, so the people who don't know the terms are not frightened away. But I also see value in using the terms that have always existed to refer to those things, so that things are clear and we can communicate about them. CHARLES:: Right. definitely, there's a tradeoff there. I don't know where exactly the line is but it would be nice to be able to have our cake and eat that one too. We didn't get really to talk about the type versus dynamic in the greater context of this whole conversation. We can explore that topic a little bit. PHILIP: Well, I can finish with, I think the future is typed Erlang. Maybe, that's Elm running on BEAM. CHARLES:: Whoa. What a take? Right there, folks. I love it. I love it but what makes you say that? Typed Erlang doesn't exist right now, right? PHILIP: Exactly. CHARLES:: And Elm definitely doesn't run on BEAM. PHILIP: I don't know if I'm allowed to say this. When I was at this workshop with Evan, he mentioned that and I'm not sure whether he mentioned it just as a throwaway comment or whether this is part of his 20-year plan but I think the very fact that Elm is designed around like Erlang, the signal stuff was designed around the way Erlang does communication and processes, it means I know at least he appreciates that model. From my point of view, with my experience with Elixir and Erlang in production usage, it's not huge scale but it's scale enough to need to start doing performance work on Rails and just to see how effortless things are with Elixir and with Erlang. I think Elm in the backend would be amazing but it would have to be a slightly different language, I think because the problems are different. We began this by saying that my story was a little different to the norm because I went back to the dynamic, at the dark side but for example in Elixir, I do miss types hugely. They kind of have a little bit of a hack with Erlang because they return a lot of tuples with OK and then the object. You know, it's almost like wrapping it up in a [inaudible]. There are little things and there's Dialyzer to kind of type check and I think there are a few projects which do add types to Erlang, etcetera. But I think something that works would need to be designed from the ground up to be typed and also run in the BEAM, rather than be like a squashed version of something else to fit somewhere else, if that makes sense. CHARLES:: It makes total sense. PHILIP: I think so. I recently read a book, just to finish which was 'FSharpForFunAndProfit' is his website, Scott Wlaschin, I think. It's written up with F# but it's about designing your program in a type functional language. Using the book, you could probably then just design your programs on paper and only commit to code at the end because you're thinking right down to the level of the types and the process and the pipelines, which to me sounds amazing because I could work outside. CHARLES:: Right. All right-y. I will go ahead and wrap it up. I would just like to say thank you so much, Philip for coming on and talking about your story, as unorthodox as it might be. PHILIP: Thank you. CHARLES:: Thank you, Taras. Thank you, David. TARAS: Thank you for having us. CHARLES:: That's it for Episode 113. We are the Frontside. This is The Frontside Podcast. We build applications that you can stake your future on. If that's something that you're interested in, please get in touch with us. If you have any ideas for a future podcast, things that you'd like to hear us discuss or any feedback on the things that you did here, please just let us know. Once again, thank you Mandy for putting together this wonderful podcast and now we will see you all next time.

Mike North: @michaellnorth | mike.works Show Notes: 00:51 - Transitioning from CTO to Independent Trainer 03:37 - Customizing Content and Developing Curriculum 06:37 - Bringing a Developer Into the JavaScript Ecosystem 12:47 - Training Developers with Non-Traditional Backgrounds 16:56 - Keeping Up with “Fifth Gear” 19:27 - Developing Frontend Masters Courses 22:40 - “Progressive Web Apps” 34:37 - Web Security Resources: LinkedIn's REACH Program IndexedDB Transcript: CHARLES: Hello, everybody and welcome to The Frontside Podcast, Episode 79. My name is Charles Lowell, a developer at the Frontside and your podcast host-in-training. With me today is Elrick, also at the Frontside. Hello, Elrick. ELRICK: Hey, what's going on? CHARLES: Today, we are going to be talking with Mike North, who is doing all kinds of interesting stuff as per the usual so we'll jump right in. Hey, Mike. MIKE: How is it going? I'm glad to be here. CHARLES: Last time that I saw you, I think it was about a year ago at the Wicked Good Ember Conf and we were standing on the beach, drinking scotch and talking about Fastboot but you were doing something completely and totally different then than you are now so I was wondering, we were talking the conversation before we started rolling, that your role nowadays is independent consultant and personal dev trainer. I was wondering if you talk a little bit about that move from the CTO role that you're playing at your old company to kind of moving into that independent trainer, like why and how. MIKE: Yeah, I do remember talking about Fastboot at Wicked Good Ember. It feels like things have moved quite a bit since then. I have always loved teaching developers. When I've been a team lead, it's the favorite part of my job just because I get profound satisfaction out of helping people get over these hurdles that most of the time took me a much longer time with blog posts and podcasts and incomplete examples and libraries that were out of date and Stack Overflow with half answers. I've decided to dedicate myself to trying to make it easier for people in an increasingly complex web development world to wrap their head around everything. While I was a tech lead or a CTO, I always had to split my focus between helping developers grow and something else. Oftentimes, that something else was where the deadlines were and the time pressure was. It felt a little bit like I was driving a car that only had first and fifth gear where you're like on the bleeding edge of open source and what was the latest commit to master and [inaudible]. Then like, "Oh, let's be extremely patient with this person. They've never seen promises before because they came from another programming language. Let's help them digest this at their own pace." It's this slow and patient process of building up from the fundamentals and then the bleeding edge is like, "Let's use Babel Stage 0." It was very hard for those two aspects to exist at the same time in myself so I decided I'm just going for the training side. That's really all I do these days. CHARLES: It was so, but now would you qualify that as the first gear or the fifth gear? MIKE: That's the first gear. It gets you off the ground. It takes you from stop and gets you moving and then you have to develop your own expertise beyond that. But I like to think I'm developing a really, really excellent first gear. Today for example, I'm converting a bunch of Python developers at LinkedIn who are basically the ops team. I'm teaching them Ember and JavaScript at the same time through a series of about 20 exercises over three days. That process is many weeks long without assistance so this is like, "Let's get rolling much more efficiently and quickly," than via DIY approach. CHARLES: Now, do you find you have to custom-tailor for the environment or the developers moving from like someone coming from, say C# would have a different experience than someone coming from Python? MIKE: Absolutely. When I have my material, I have sections that I can drop. If you are a C# developer, I do not have to explain conceptually what 'async' and 'await' mean. You've been working with that for a while. I probably throw up a little example in C# and then the equivalent in JavaScript to sort of create a bridge from your existing expertise into the JavaScript world. Another one -- this is very true -- is teaching Ruby developers how to use Elixir. You don't have to say, "This is a router. We have controllers. There are actions and controllers." There are so many parallels that really it's more useful to help, rather than teach things from scratch to create connections back to the expertise they already have so they're not starting from zero and they can say like, "In the Ruby world, I would think of doing XYZ." Now, I have a map in between that and this new thing. CHARLES: Obviously, there's a lot, a lot, a lot of languages and environments that you could transition to, probably more than matches your own personal experience, in doing that frontline development. What kind of research do you have to do to develop a curriculum for, say someone coming from Clojure or someone coming from Scala or something like that? Maybe that never happens. MIKE: I have a pretty, pretty broad background. My entry into programming was a subset of C and then I graduated to C++ and Java and Ruby and I used to do ASP stuff. I've written iOS apps. I feel like I have enough of a foothold into various areas like I know one JVM language. That is usually enough. If you're running a lot of Clojure, I can at least speak Java to you because odds are, you're working with that and you're seeing that and you know it. Oftentimes, I have what I need. There are situations where I can borrow something in a very cursory level. Not to rip on Scala but I have not found it valuable to make connections to that particular language for clarity and [inaudible] but I have used Haskell before and I'm not a Haskell developer but it is a pure functional language. When trying to help people understand how is this different, then the JavaScript got them running where the Ruby ends up running. It's useful to use something like that. It's a very small language, very simple and you can wrap your head around the basics. ELRICK: What are some of the particular challenges that you face when bringing in a developer outside of the JavaScript ecosystem into JavaScript since JavaScript is kind of the Wild West that you can do everything in JavaScript? What are some of the challenges you face in bringing in a new developer from Python or C or whatever that may be? MIKE: You put it very well. It is definitely the Wild West. You can do anything if you have enough [inaudible] yourself and enough power to get serious stuff done. Really, it's like the explosion in number of choices and tools, the explosion of complexity. I learned JavaScript when it was something that you sprinkle on top of your Rails app for a little interactivity, a little animation on a screen or something like that. I was lucky to learn it at that point in time when that was the norm because I've been able to gradually accumulate for more than ten years now. The tooling like using Grunt, using Golf, using Brunch and then stepping up to other more sophisticated build tools. I learned those one by one in the context of real projects. Now, it's like the mountain is so high, people don't know where to start so that's a big challenge for developers. To throw them into a meaningful project like if you asked a mean JavaScript developer, not angry but the average JavaScript developer, they're like maybe -- CHARLES: I should dare to say that the average JavaScript developer is mean. MIKE: A little bit and probably maybe [inaudible] with me as well, depending on [inaudible]. But they're going to spin up some project with webpack and Babel and all of these tools. If that's your first exposure to the language and to working with the language, you're operating in an environment that you don't understand. Research shows that is the less effective option there to slowly building things up over time. I spend a lot of time going back to the basics and making sure we're not working with promises until we've explicitly focused on them, chained a couple together, managed errors and then now, we can work with Fetch. We're not going to jump into that and throw ourselves into this deep end of the pool. We want to incrementally build up skills. It takes a little bit longer but when you have that understanding as you're learning, you get a lot more out of it because anything that you can't get a grip on to as you learn it, it sort of just evaporates into thin air and don't retain that, even if you kind of fill in those holes later. CHARLES: Yeah, it could be so hard too. Actually, this has been an experience that I've been having, I would say almost for the past two years, as the tools advance, not only you are starting from a place of not understanding but the tools themselves do not teach you. I've had two moments where I got really mad. One actually was on an Ember project and one was a project using webpack but it was the same fundamental problem where in one I was actually working with someone who was very new to JavaScript and an error happens and the stack trace was some just big bundled garbage that gave no insight at all. MIKE: In vendor.js. CHARLES: Yes, in vendor.js or in bundle JS. It was like, "How is anyone supposed to learn?" The most fundamental thing about working with Ruby or working with Node or working with anything is you get a stack trace. MIKE: Debugging is really hard. I think it just takes a little time reaching out to people who are experiencing the Stockholm Syndrome like most of the time, JavaScript developer. We all are working with Ember CLI and webpack. I'm not ripping on these tools but we're used to that complexity in our lives. When we see that stack trace, we're like, "Oh, well. I probably need a source map. I'll make sure that that's there. It's natural that I'm debugging a file that the browser is not really seeing like it mapped back to my source code debugging." This is natural to us. But if you put that in front of a developer who hasn't been living under those circumstances, the number of times they raised their hand is like, "What the hell is this?" It is just amazing and it really helps. I've reset my expectations to what a normal programming experience should be and JavaScript does not provide that today. That is really challenging to keep someone in the midst of all that. CHARLES: I feel like it's hard and do you think we'll ever achieve that? Or is it just going to be a constant hamster wheel of progress versus the tooling to educate what progress has been made or to communicate what progress has been made? MIKE: I think the tooling is fine but it's just that we have a gap in terms of learning experience. We just need really -- I'm not voluntary here because I've got a ridiculous backlog -- a couple long tail horses working with vanilla JavaScript, rendering some stuff on the screen, maybe a course of React but no JSX yet, just create component. A couple of things to fill in a gap between where maybe code school leaves off and where you are expected to be by the time you start interviewing for a spot as frontend developer on a team but there's a huge chasm right now. There's the intro guides and then there's professional life and trying to bridge the gap between those is ridiculously a challenge right now due to the huge ramp up of complexity from like, "Let's do some stuff in the console," to, "Running transpile JSX code with async [inaudible]. We've got regenerator in there to polyfill generator functions." There's so much in your average JavaScript at these days. CHARLES: Your work that you're doing at LinkedIn, part of it is trying to bring and train developers who come from more nontraditional backgrounds, including a lot of things like boot camps. What is your experience of their experience coming in? Are boot camps doing the right thing? Are they teaching the right things? Are they trying to kind of parachute them on top of that mountain? Or do you find that they're just at the base camp, so to speak? Because it sounds like your approach is like you've got to really start from fundamentals so that you can understand the layers of complexity if you're going to, someday stand on them. MIKE: I think a lot of the boot camps are doing an excellent job. These days, the employees we have at LinkedIn who come from boot camps, I would bet on them against your average MIT grad every time, just because their education is so practical. It's amazing that in the world of computer science, the stuff that you're taught in school is a little bit farther removed than one would expect, compared to the stuff that we do every day in our jobs -- building real apps. I do not need to know in my day-to-day work at LinkedIn how an operating system works or how to build a device driver. This is a little bit too fundamental. It's the wrong abstraction for practical everyday work for most people. Where in these boot camps, they focus completely on the practical. In fact, I've been fortunate enough to get involved with the REACH program here at LinkedIn, where we hire explicitly people from nontraditional backgrounds like boot camps. They're not all from boot camps but many of them are. We just hired 30 of them in March. The pilot program, I think we've hired two or three in our New York office and it just went really well. It started like, "Let's double down and double down again and double that again." This time, we're doing 30 and I expect there will be a new round next year where we poll even more. The idea is we take these REACH candidates and pair them with a mentor engineer for six months. At the end of that six months, we had to make a decision as to like this person at the level we expect of an entry level software engineering hire. From what I've seen, we're doing really well at preparing these folks and they're unbelievably valuable to the teams that they've been placed in. ELRICK: That's amazing. That's very interesting. Is there a standardized curriculum thing that each mentor will follow to get this person after they entered his REACH program and then ramp them up or is it like each person just goes and looks at what the person knows and then ramps them up accordingly. MIKE: I'd say, it's a mix of both. We have a set of technical trainings for them or we'll have a testing expert from within the company and teach a little testing seminar to them. There's that standardized curriculum there. But the nature of being taught by boot camp or teaching yourself is that you're going to have holes in your knowledge and it's not often predictable where those holes will be. That's why we make sure we do this mentorship very explicitly and over a long period of time so that if it turns out that you never learned about how to work with tree-data structures. That was not part of the go-no/go decision that brought you on but we should probably, at least get you there. At least to the point where if you're traversing a down tree and you're like parent and child, what is this, what do you mean by leaf-level node. This is stuff that is actually meaningful for web developer in some cases. CHARLES: In the context of the work that you're doing with the REACH program but also touching on something that we talked about at the beginning about the first gear and the fifth gear, part of generating a curriculum is still being in contact with what's up in the fifth gear right because ultimately, what you're trying to do is you're working with people who are in first gear or looking to get a smooth transition in the first gear but at the same time, you want to set them up and you want to be in contact for what's in fifth gear now is going to be first gear in five years. How do you feed that in? MIKE: I'm fortunate to have a great team that I work with here. This group that I roll up to in LinkedIn, they're experts and you probably know of like Chris Epstein and Tom Dale and Steph Petter. A 15-minute coffee break with one of these people is enough to keep [inaudible]. Sometimes, it's a little bit like drinking from a fire hose because it's like I spend an hour with a student trying to help them understand like, "This is why a Promise is useful. Here is the callback equivalent," and then now, "Let's dive in to Glimmer. Why this track annotation is the right way to go for automatic updating." It sends me for little bit of a loop sometimes but it is definitely keeping me up to date. The other factor, of course is when you've been doing this for a while. History sort of repeats itself so a lot of the patterns that we're seeing today, I've seen somewhere else. I was working with code splitting when I was writing Dojo JavaScript code years and years ago. I was defining my module layers in a very explicit way. I had to do that. I didn't have done a webpack that would figure out, put these splits are. But I have that experience to look back to and for that reason, it is not often that an entirely new concept comes along. Oftentimes, they're like amazing refinements on things that how to smell like stuff that we've used before in the software engineering world. CHARLES: Yeah or here's something that has never been used, is very prevalent in these other context which we're going to apply here. MIKE: Exactly. CHARLES: And like, "Oh, my goodness. It's a perfect solution." In addition to the work that you're doing with LinkedIn and developing those training curricula and stuff, you're also doing some work for Frontend Masters in an area that's very exciting, I think to me. I'm sure it's exciting to you because you decided to throw a whole lot of time into developing a course for it. That's in the development of progressive web apps, which for me has been like this thing that I'm so curious about but I'm like a kitten playing with a little yarn ball. I want to dive in but I'm just going to tap it with my paws right now. MIKE: Yeah, it's a really interesting area and I think that even if you're not using progressive web technologies today, it's one of these things that sort of reinvigorates your energy for JavaScript's future and what may be possible soon. Steve and I have put together this amazing progressive web app course, which has I think like 18 short examples of iteratively building up a grocery shopping app. If you've used InstaCard or something like that, we start out with app already built and it's like a single-page app as doing everything that you would expect. After a few of the exercises, it works offline. After a few more, you can add stuff to the card and background sync, push it to the API when you come back online. We get deep, deep, deep into service workers. That's one of the areas that my work at LinkedIn and my teaching with Frontend Masters overlaps really well because I've been heavily involved in creating our service worker for LinkedIn.com. I may be able to take some of what we've learned here and disseminate it a little bit so that, hopefully fewer people have to learn the hard way. It's best to keep things simple at first and add on functionality. I'm about to cross like the [inaudible]. This is my favorite just because the example turned out to fit so well and in particular, on Frontend Masters, I think Steve and I have had contrasting teaching styles but they complement each other so well because I'm like the 'melt people's brains' instructor. I love to throw people exercises that are like 120% of what they can do and it's going to hurt, just like when you're lifting weights at the gym, like you're going to beg for mercy but we're going to make you strong. Then Steve, just listening to him, even with I am in the classroom and he is teaching me Electron. He's so energizing and he's really funny too but not in an overtly cracking jokes kind of way. He's just so fun when he teaches. I think it is a really good combination just because things lined up just by luck and through hard work and just the right way out of a couple of important areas. CHARLES: Now, just for people who might not be familiar with the term progressive web apps, what does it encompass? Do people actually call them PWAs? MIKE: No. I'm going to start, though. I like that. That carries very well over a video chat or something. Nobody knows how to spell that: P-U-A? P-W-U-A? It is a rejection of the old idea that in order to take advantage of some web technology, it has to be supported in all of the browsers that we need to support. The idea here is to hold as a core tenet of our design practices, the idea of progressive enhancement, meaning we serve up a basic experience and where we can take on these superhero features, like the ability to work offline, the ability to receive push notifications, we go ahead and do so. If your browser doesn't support this, that's unfortunate. No big deal. You still get a good experience. But if you're using a very recent version of Chrome or Safari or you have a new Android device, these browsers can take advantage of sophisticated metadata or sped up a background process that can serve up data to your app and your app doesn't even know that there's something between it and the API. That is the idea of progressive web apps -- apps that become superheroes where possible and they still work and provide a great basic experience for antiquated browsers like IE8 and Safari. CHARLES: The idea theoretically, you could work without any JavaScript or whatsoever. What's the ground floor there? MIKE: That is ideal. I think server-side rendering, which is what you're talking about there, even if JavaScript is not working, just HTML and CSS will provide a basic experience. That's great but that's not a modern browser technology thing. If you have JavaScript turned off in today's Chrome, like Chrome 60, versus IE9, both of them working with them without JavaScript. What we're really talking about here is app-like characteristics, where we are pushing web technology to the point where you will swear that this came from an App Store. It's on your home screen. It's running in the full screen. You're getting push notifications. It works offline and you can store a large amount of structured data locally on the device. All of the stuff sounds like the list of reasons to reach for native mobile technology because the mobile web is not good enough. But in fact, it has a feature set of this family of progressive web technologies. It's really like a web app that is so good and so modern that it feels and looks just like a native mobile app. CHARLES: That sounds so hard to do right. MIKE: Well, it is now, just because what we have to work with can be thought of it like a basket of ingredients, rather than a solution that we drop in. But over time, as more people start working with these ingredients, I think we're going to see a lot of consensus around the best patterns to use and boilerplate code will fall away as we can identify that the set is in fact commonly needed and not a beautiful and unique snowflake. CHARLES: Because it seems like the thing that I always struggle with is not wanting to put the critical eggs in the basket of a superhero feature or have you being able to provide an alternative if the superhero feature doesn't exist. Some features, if you just don't have it, that's fine. You can turn it on if the capabilities available but certain features are very critical to the functioning of your application. I'm casting about for an example and I'm not finding one immediately but -- MIKE: Offline is a great one. That fits pretty neatly. If you're using an older browser or if you're using Safari, which by the way, I should stop ripping on Safari. For the listeners out there, we saw a commit lend in webkit, where service for APIs are beginning to be stubbed out. No longer do we have to look at length. Service worker, enthusiasm and Safari has got it in the five-year plan. There was motion last week. We haven't seen motion in ages so thank you Safari Team. Thank you. Keep up the good work. CHARLES: Is there a discipline of Safari-ologists who monitor the movement of Safari to bring this news? MIKE: Of course, we monitor it because right now, Chrome and Firefox, they are pretty much hopeful in terms of supporting this modern stuff. Opera supports this modern stuff. Samsung's fork of Chromes support this modern stuff. Especially when we think about the mobile web, you got to worry about Android and you got to worry about iOS Safari and right now, like we've talked about these progressive web apps, you don't get that superhero experience on an iPhone or an iPad. Once we crossed that threshold, this is going to have a breakaway level of adoption because there are no more excuses. Essentially, for a mobile web experience, you can send push notifications to the user. That is huge. That is probably at the top of the list for why some people use native apps, instead of mobile web. The more we can do that, the more we can make it so that a great LinkedIn experience can be delivered to your phone without having to install a binary. I just have to update Facebook the other day and it was over 100 megabytes. Why do we need to do that? You should be able to make it work with less. I'm sure that there's some great stuff in there. Apparently, Snapchat filters are popular but I don't need this. Can we code split that away or something because I don't want to have to download that? I can't even download it on the cell network because it's over 100 megabytes. It's really exciting to see the web start to compete with this heavy mobile experience because now I think is ready. CHARLES: Now, when you talk about push notifications, you're talking about being able to send things to my lock screen. MIKE: To your lock screen while the browser is not on the foreground, while the app is not open. Essentially, you're installing a lightweight process that runs in the background. It receives events that originate from your server and the user can tap on them and then your little lightweight worker process in the background decides what to do when that tap happens, like open up the app, take them to this URL or something like that. That is a game changer. That's huge. Or background sync like the user added some items to their cart and then they lock their phone and now, their plane has landed. That's why they were offline and they get back on the internet and without them having to touch their phone, now we can push that data to the server and everything's in sync, rather than like, "Please revisit your app. We need to run some JavaScript code to flush IndexedDB or API." It still feels like a hack at that point. This is a fluid experience. ELRICK: Wow. This is exciting for me as I don't have any more space on my cellphone, thanks to all the apps that I have to install to do various things on the web. MIKE: You're not alone. CHARLES: Yeah, it's crazy and just the amount of code sharing that you can have, I guess that doesn't happen much these days on the web where you've got these popular libraries out on CDNs so that the chances are that you've got jQuery 1.2.1 on your cache, you've got 16 versions of jQuery so most of your web applications don't have to do that. I guess we kind of do the equivalent of statically linking everything. MIKE: There is a benefit near that where we have imperative code managing our cache, instead of just relying on the HTTP cache or app cache, if you have a vendor.js file that is not changing over six months, there is no reason you should be re-downloading that every time you deploy your app or letting the browser evict that, just because memory pressure is high from Google image search results or something like that. We really don't have much control over it. But with a service worker, we can say, "Hold on to this," or maybe like prefetch the next version of the app so that we're going to show you the old version now but the next time you refresh, here's the new version available instantly. It's downloaded in the background and it's like click to update your version, like it's already here waiting for you. That's huge. That's amazing. CHARLES: That is amazing. Although the complexity skeptic in me is thinking, "Oh, my goodness. Now, we've got all this state that we're storing on the server. We have to have data migrations." We need some sort of migration mechanism for our clients-side state and perhaps some transaction and rollback in case you're not able to successfully migrate your data. It sounds like a lot of fun but I'm just imagining we really are getting started here. Has there been any work on that aspect? MIKE: If you've ever worked with IndexedDB, it does have a concept of migrations. Basically, the data you store on a device has a version and when you read in what's called a file but it's a database, when you read that in, the first thing you do is you basically bring it up to date incrementally. You'll bring it in, you're looking for version nine like your code wants version nine. What you see is version two because your user hasn't been at your site for six months and you're going to take it from two to three to four to five to six. Each of those, essentially constitutes a migration. We just have to apply the same principles of forward-compatible changes. The escape hatch here is remember it's progressive enhancement so if we had to destroy everything, fall back to a basic experience and start from scratch, like discard all of our data, it's really being held there as an optimization. Some people use this immutable caching strategy or basically, like rolling out a new service worker version constitutes for the most part. Any data that wasn't created by a user you're going to discard that and you're going to fetch it new. You don't have to worry about like, "Crap. This six month-old thing is still plaguing half our users and we can't get rid of it," like you can have [inaudible]. But you should really check out this course. It is simpler than you think and what we demonstrate is not a trivial like hello service worker. It is taking in a classic single page app, making it completely offline, having it exist on the home screen and I think the service worker ends up being no more than 100 lines of code. It's not too bad. ELRICK: I'm definitely going to check that out because my progressive web app journey is still on just service workers. MIKE: That's very [inaudible], though. ELRICK: Yeah. I'm definitely checking it out. Sounds like a really fantastic course. MIKE: I've been focusing a lot on this area and another one is security. The reason I picked these two is because developers are not really going to learn about these on the critical path to [inaudible] plus they learn about them the wrong way. As the JavaScript world is becoming radically more complex with each passing year, I've tried to target some of my efforts towards areas where they are not getting as much attention as I'd like to see, just because we have to focus somewhere. Obviously, getting the app out and figuring out how to make the build tools work for us. Without that, we can't do anything at all. One of the courses that's coming in September for Frontend Masters is a one-day web security workshop or we'll do with like cross-site scripting, how to work with certificates because if you start playing with HTTP/2 -- the next generation of HTTP -- you will need to generate some certificates for development at least today you need to. I've seen some amazingly smart developers get this dangerously wrong to the point where they compromise their own machine and anything that's on that machine, just by trying to set up dev environment. Typically, I'm an optimist but when it comes to this PWA stuff and security, I am paranoid. I feel like, we as a community need to get together and have the discipline to brush up in these areas so that as we introduce all of this new stuff, we don't end up opening a bunch of holes. Nowhere near the same rigor as put into frontend compared to backend and now, the line is blurred. Right now, we're server-side rendering so our code is running on the backend somewhere so injecting something can really mess things up in a bigger way. ELRICK: Yeah, I think that's a fundamental characteristic of someone does going to be involved in security paranoia. You have to be paranoid about everything. MIKE: Yep. I don't trust anything. CHARLES: It's important to make those things easy because I'm definitely fall more into the hippie camp like, "Everything is going to be fine. Let's trust everybody," which is I know is totally unrealistic. But then you get into these secure technologies and you learned enough of it just to get the task that you're going to do and then you forget. SSL is a great example. Over the course of my career, I've learned how SSL certs have worked probably, at least 10 times. ELRICK: Right, [inaudible] you had to set it up in production. CHARLES: Yes, exactly and then I promptly forget about it, never worry about it again and then the next time I'm like, "How did that work? What's this trust chain? What?" ELRICK: Exactly. I read a study from Carnegie Mellon a couple of years ago that showed developers observe security best practices dramatically less than the general public and the general public is not good. Do you know what I'm talking about when I say a certificate warning and a browser, there's big scary red screen saying like something is wrong here? Before the Chrome team put some effort into improving that, 70% of people would click through those and proceed anyway. After their improvements, over a third of people still clicked through and that number when you just look at Canary versions of browsers, that number is actually considerably higher close to 50% of our developers. We're trained by every broken certificate system that exists on the internet like the legitimate ones or maybe some things just expired. They're training people to just click straight through these things and as a result, it is terrifyingly easy to mess with people. We have to remember as developers, our machines, those have the private deploy keys and those have the SSH keys to commit code to GitHub, we have to treat that like it's a private data. It's really, really important that we make it easy and that we make sure that that easy path is also very safe. CHARLES: Absolutely. All right. Well, thank you so much Mike for coming by and talking with us. We touched on a lot of subjects but I feel like I certainly learned a lot. MIKE: Yeah, thanks. It's been so much fun talking with you this morning. CHARLES: Anybody who wants to go and check out those courses, they're on Frontend Masters. Now correct me if I'm wrong, you've obviously got the one on progressive web apps or PWAs. If it doesn't work offline, it's faux-PWA. MIKE: Yes, I like that. That's going to become a t-shirt sometime soon. CHARLES: The fundamentals of progressive web app development, which is now released if I understand correctly. MIKE: Members have access to everything, you can watch the raw video now. The edited course will be available later this year. CHARLES: Okay, and that's with Steve Kenny. I am very much looking forward to looking at that and learning more about it. Then you've also got ones coming up in September on TypeScript web security in Visual Studio Code. MIKE: Yep and members can watch that as a live-streamed event. Frontend Masters even ask people to watch the comment stream so you'll have a proxy question asker or hand raiser in the room. It's really a great experience to be part of a live thing. CHARLES: Oh, man. That sounds awesome. Then if you are obviously doing your independent consulting and if people want to get in contact, how would they do that? MIKE: You can find me on Twitter, @MichaelLNorth or you can visit my website, Mike.Works and I have all of the courses I teach and outlines and I can just open up a little chat bubble on the lower right, ask me any questions that you have. I am really passionate about teaching people. If you like that's useful for your team, please reach out and I'd love to talk. CHARLES: Fantastic. Thanks, Mike and thanks everybody for listening to us. If you want to get in touch with us, you can always do that. We're on Twitter at @TheFrontside and email, Contact@Frontside.io. Thanks, Mike. Thanks, Elrick and I will see you all later. MIKE: Thank you so much. ELRICK: Bye.

Kyle Simpson: @getify | Blog | GitHub | getify@gmail.com Show Notes: 04:19 - Styles for Learning as a Newcomer 08:41 - The Structure of the Journey “If you're waiting until you're already an expert on a thing to share it with somebody else, you've waited far too long because we missed out on the most important part which was the journey.” 12:52 - Understanding a Problem vs Solving One "I want to inspire people to be uncommonly curious." 29:02 - How do you know when to stop? 35:02 - Knowing Math and Learning Programming 43:40 - The Importance of Mentorship Resources: LABjs The JavaScript Austin Meetup Pedagogy Saron Yitbarek (CodeNewbie): I don't belong in tech: Trying to find my place in the place I love, and constantly failing Dr. Seuss' The Sneetches (Star-Bellies Reference) Big O Notation You Don't Know JS: A Book Series Functional Light JavaScript Kyle's Frontend Masters Training Videos Transcript: CHARLES: Hey, everybody and welcome to the Frontside Podcast episode 50. I'm your host, Charles Lowell. With me, also from the Frontside, is Stephanie Riera. And with us today is a very special guest, Kyle Simpson, a fellow Austinite. We're going to talk about education and teaching JavaScript. You hear this name everywhere you go. I remember when I first moved to Austin, back in 2009, I moved back to Austin, I went to my very first JavaScript Meetup and there was this guy sitting there doing some live coding on this crazy thing called LABjs which was just like mind-blowing stuff that was going on that was doing crazy on-the-fly modules floating. And this was like back in 2008/2009, so awhile back. And that was my first experience. And then just moving inside tech circles, he just like popped again and again and that's just like the story. It seems like Kyle is like ubiquitous. I was at Clojure Conf last weekend and one of the speakers actually gave a shout-out to Kyle Simpson. So, I don't know Kyle if you do much Clojure, but you definitely have an impact, an outsized impact in the JavaScript community and outside the JavaScript community at large, all throughout tech. It's really a pleasure to get to have you on the show. So, welcome Kyle. KYLE: Thank you so much. It's a huge honor to be here. I'm glad to be doing this in our home city of Austin. It's fun to actually get a chance to pull again with the Austin community because a lot of my work takes me on the road. I sometimes joke that I know more about JavaScript communities in other cities than in my own since when I'm home, I'm usually with the family. And when I go to meetups, it's usually in other cities. But it's fun to be here. It's interesting you bring up that JavaScript Meetup, the original Austin JavaScript Meetup. It started in January of 2009. Actually Joe McCann, most people will know that name. He's kind of a rockstar in the Node community and one of the founders of NodeSource. I think he's up in New York City now. But he started the Austin JavaScript Meetup in January. February, I started kind of came on and we ended up kind of tag teaming running that meetup for the next couple of years. In the early days of that, you're talking about LABjs, I remember that was summer of 2009. The early days of starting up a meetup when you have 5 or 6 attendees on a really good night, mostly consists of about a week before the meetup, "Oh, we don't have a speaker. One of the two of us has to figure out something to speak about." So, I would often kind of take on that task and I would say, "Okay, what's something I'm interested in," or, "What's a library I could write that I could talk about something when I was coding?" CHARLES: So that actually born out of the need to actually present something at the Austin JavaScript Meetup? KYLE: Yes, actually LABjs, it was something at work at that time that I was trying to solve but I wasn't really making a library out of it. It was just some code that I was toodling around with. I was like, "Wow, crap! It's 3 days before the meetup. I better come up with something to talk about." So I wrote the very first version of LABjs to present at that meetup and I got a bunch of good feedback from people that were looking at it and saying, "Oh, that's cool." So I kind of ran with it. That's literally my first kind of major open source project. Most people probably originally heard of me if they've been around the tech world for a while, they originally heard of me because of that one. CHARLES: Wow! I had no idea I was there. KYLE: You were there for the origination. I was the unveiling to the world of LABjs. CHARLES: It's like the Woodstock of JavaScript. KYLE: Those were some early days of meetup stuff. You're like pick up a pizza and a couple of beers from the store on the way to the meetup and there wasn't a lot of organization but we had a lot of fun. Now, the Austin JavaScript Meetup 6 or 7 years later is, it rocks! There's 50 or 60 people every single month that attend. There's been several change-overs of leadership over that couple of years but it's still fun to think about kind of helping Joe get that off the ground way back in 2009. CHARLES: Yeah, that was fantastic. You've been in it a long time and that actually kind of brings me to one of the things that I'm curious about is you've been doing this for a long time. You've been writing JavaScript for a long time and yet you're very much connected to the Day 1 learners and the people who were coming in just kind of from at the very bottom floor. And one of the things that I find in my interactions with the people who are starting out or people who are beginning is that it can be very difficult to know what's appropriate to teach a style that's effective or teaching them because you don't have that empathy of you're so far removed from the experience, that struggle and that challenge of really clawing your way into programming. And yet that doesn't seem to be an issue for you or maybe it is. I'm just curious, one, do you perceive that as something that you have to deal with and how do you do it? KYLE: I would say that part of the way that I'm able to keep a pulse or a finger on what it's like to first start learning something comes from my own learning style which is that I, to learn a thing, I can't follow tutorials. As a matter of fact, every time somebody comes up with a new major awesome tool or framework and they put out this great tutorial and everybody raves about it, I secretly have that huge flare up of impostor syndrome because I know that I will feel really dumb if I try to go through a tutorial and learn it in that fashion. That's just not how I learn stuff. The way I learn stuff is very, very slow and methodical. It generally is taking a thing apart and trying to figure out what each of the different pieces is doing, understanding at that deeper level, and then reassembling the pieces. The reason I mentioned that is because I like to describe my process of teaching and I really think this generalizes to people beyond me that it's my process. I think that my process for teaching is just to have a narrative journey and that it's all about a process. It's not about a single event because I don't think that learning is transactional or I don't think it should be. I think learning should be a process. And so, for me, that process starts with an initial thing that I'm looking at. I get an idea of what it's about, the problem domain that it's in. I probably develop an instant sense of 'ooh, I don't really like that' or 'ooh, that's kind of interesting'. But if I'm going to learn a thing, it's not going to come through a tutorial. It's not going to come through reading a Read Me and being like, "Okay, I'm good to go," and I can sort of copy and pasting. For me, it's going to take, in some cases, reinventing parts of it as I put those pieces back together so I can really understand the choices that were made. I do a lot of reading of somebody else's source code. As an example of this ongoing journey that I'm learning, I was recently at a conference and I heard a discussion of Redux. And of course, Redux is something that tens of millions of people, I mean everybody seems to be an expert on this stuff and I don't know Redux. I don't know React. I don't spend a lot of time at that layer of the stack. But I was listening to a talk and I was thinking, "Well, that sounds interestingly similar to the stuff that I was playing around with back in 2010." It's kind of event oriented and single source of truth for the model and stuff like that. "That's cool. I should go and learn that more." So, that's on my pretty near future to-do list to kind of learn stuff. And there's a really good chance that that process, that journey that I go on to learn about Redux is going to spin off at least some sort of code that I play around with, whether that's using Redux or writing something kind of like Redux to show off how I've been thinking about the idea. And then I'll probably write about it. I know for sure that I'm going to be mentioning it in one of the chapters of my current book on functional programming. So, I'll be talking about it, at least a little blurb about how it fits into the overall scheme of things. And then probably eventually once my journey has gone a little bit further, eventually there'll be some kind of class that I spin up in a module or in one of my classes that I talk about Redux and where that comes from. And that's not because I've been on the high training. As a matter of fact, it's the opposite. I'm the latest adaptor for most of these things but that is a very long slow methodical process for me to learn something and then turn around and try to teach it to other people. CHARLES: Is the idea then that you want to kind of share that journey that you've taken or try to encourage the next learner to take a similar or different journey? How do you structure that learning once you do decide to package it up? KYLE: The structure of the journey -- I think that's an interesting way of articulating the question. What is the structure of the journey? And I would say that the structure of the journey generally, from my perspective, starts from understanding a concept, the why behind the concept, what is the problem I need to solve, and what is motivating solving the problem. And then it moves into the how are we going to do it, what are the possible ways to do that, and that really is the part of that process that you spend most of your time digging into and understanding the deeper level of the thing. So, not just using the library but understanding really how it does it and the choices that it made. And then it moves to the what. And that is inverted from the way most people's learning seems to go about because people learn most typically by, "I find the cool thing because it was in some newsletter that I read about. It seems like it would help on my job project, so I dropped the thing in, put in a couple of the snippets from the Read Me and it's working great, and maybe someday later, I'm going to go back and dig into it a little bit." I'm completely reversed. So, that's my structure for learning and I recommend that people, at least from time to time, take a similar path. It doesn't have to be exactly that way, but take a similar path to breaking down the learning. I'm sure as we go along in this discussion, I'll be able to elaborate on that more. I don't want to just churn on and on forever. But I really do think it's important for people to dig in deeper. So my process is that and the way that I teach is to take people on that journey with me. The way that I teach is to say, "This is the journey that I'm going through. This is the stuff that I understand." For the listeners that aren't teachers, there's some interesting -- I don't want to get too much into the weeds about teaching -- but there's something interesting about teaching. There's this fancy word called Pedagogy which is not the thing that you're teaching but the strategy that you want to use to teach it, the narrative that you want to take a person through. And I spend an awful lot, probably more of my time thinking about that than about the topic itself. So, my practice is to use a lot of silly metaphors. Like I'm teaching promises and I talk about future cheeseburgers and stuff for those that have read or heard from me before, they'll know the future cheeseburger. I use silly stuff like that because this stuff can be really dry and difficulty and I want it to stick in your head. I want the how to stick in your head. So, I invite other people. That doesn't mean that you have to take the entire journey that I did to learn a thing, but I really want to inspire people to learn at that level to be uncommonly curious. And I hope that when they see that I've done it and that I'm transparent about how my process works, I hope it inspires other people. CHARLES: Yeah, and I think wrapped-up in that is tied back to my usual question is because you yourself are in fact you're going through this process, it's very easy then to empathize people who are going through the same process. I really like that. KYLE: And I think everybody should look at the process of getting up to speed on the thing as an opportunity to go on that journey and to document and share that journey with others. You don't have to have the word 'teacher' in your job title to be a teacher. I think all engineers should be seeking to go outside of themselves and to explain things, if for no other reason than the purely selfish reason which is you learn it better by re-explaining it to somebody else, but all boats will rise with the tide. And so, I have taken, for years now, the perspective every time I learn a thing, I'm going to turn around and share it with somebody else. It's exactly the same thing that's interesting and almost ironic that we started our discussion today about that meetup and about LABjs. I was learning a thing and figuring out a thing and I turned around and shared it with other people and it turned out to make an impact. But the impact isn't the important part. The important part was the journey, it's not the end goals. I was always tell people, "If you're waiting until you're already an expert on a thing to share it with somebody else, you've waited far too long because we missed out on the most important part which was the journey." STEPHANIE: Kyle, you touched on something that I wanted to ask you about. You talked about the first phase being understanding a problem, and then the second one being how do we fix this. And last week, I believe, CodeNewbie has her own podcast. And she released a post on Medium and it's called 'I Don't Belong in Tech'. And she talks about how her instinct is to understand the problem versus solving it. It seemed like she feels she is an outcast in the tech community because most people are really excited about solving problems and she doesn't feel like she is solution-oriented. And I kind of wanted to ask you, is that the case? Do you think the people that excel in programming are people that are just naturally excited about solving problems? And if that's not the case, then what do you recommend for people that may not think in that fashion, they don't intuitively feel like solving problems and they feel like they approach it in a different manner? It seems like people have different learning styles. KYLE: I agree completely that people have different learning styles. And that question you just asked is so rich with so many things to mind. So, I'm excited to dig into that a little bit. I 100% agree that people have different learning styles and I think that it is why it is important for there to be people in the community who are spending their time and attention thinking about teaching and about improving educational processes. I do not think that curriculum teaches itself. And I'm somewhat suspect of the movement that we have as an industry towards almost praising or taking it as a badge of honor the label of self-taught. It's almost become its own cult that you're a self-taught person versus somebody who came through it from a more traditional path where a person was carefully thinking about how to present to you and how to teach you whether that was at a university or a tech school or mentorship or any of the others. People that are self-taught often wear that as a badge of honor. It's almost a rite of passage that you got to a level of understanding and experience and expertise because you boot strapped yourself up as opposed to the more top-down approach. And I am suspect of whether or not that's healthy for us to suggest to people that there are these two factions. It's kind of like the old Dr. Seuss book of the star bellies and the non-star bellies. I have the star belly because I got my Computer Science degree. And if you know that book and if you don't know the book, you should go look it up. But what happens in the book is at some point, there's a flip and now the people with stars are the excluded ones and the people without aren't. So I don't think it's healthy for us to promote the idea that we need two entirely different approaches that there's a person who can only be a self-taught and that's a thing, and then there's a person who gets more formal education. I really think it's important for people to spend time thinking about how stuff should be presented and not just throwing information out there for people to learn themselves. This is kind of a crazy metaphor. But if you had a one or two year old kid and you wanted them to learn to swim, the developer mindset often says, "Well, just throw them in the deep end and they'll figure it out." But that isn't how we actually would teach them to swim. We would be very, very patient, very, very cautious with them. We'll start with the shallow end, there being an adult there and they would guide them through that. And I think there's virtue in having some of your learning even if you're one of those listening that does value the whole self-taught thing or that has worked for you in the past. I think there's also value in people going through a more formalized process. Like I said, there's lots of different channels for that modality. But I think the formalized modality has value to it. And of course, that's what I spend my time thinking about. I put out a lot of information - my books and my training videos. There's a lot of that material available for people to self-teach but I really hope that what that does is not encourage people to stay disconnected but rather, to attract people to create relationships around learning because I think relationship-based learning is the most effective modality for leaning. And we've proven that for thousands of years in lots of other parts of society, but we haven't really taken that to heart in the developer world, and I think we need to more. You're right, going back to the original question that there are lots of different ways that people learn. I know CodeNewbie. What's interesting about that premise, I share a similar perspective on those that want to learn to solve a problem versus those that want to learn to figure out how to solve problems. I have a statement that I make which I will preface with I understand that sometimes it can be a little bit off but I hope that listeners will take this from the spirit that I'm trying to give it in. I think that one of the things we can do is begin to think a little bit more about what we're doing even though all of the other structure and process scaffolding around us incentivizes and encourages the opposite. I think what we see is that the developer-oriented mindset typically is more interested in first solving a problem and maybe later understanding it. Whereas I think the engineering mindset -- for lack of a better label, I'll call it the engineering mindset. That's my bias because I came up through a more traditional engineering CS degree. But I think the engineering mindset, the one that most people would say is heavily focused on problem solving and that kind of thing. I think the engineering mindset seeks first to understand the problem and maybe later solve it. If you have developer mindset that wants to solve a problem without really fully understanding it, I think one of the outcroppings of that is the churn that we see in the development community. We see people constantly every two or three years trying to go recreate a whole new stack of things because we're saying, "We need to do this thing differently." And I have seen that cycle four or five times in my career. And so, I can say with pretty strong certainty right now that somewhere in the world, there is a guy or a girl that is a 16 year old that is working on what is going to eventually replace React. I don't know what it is, I don't know who the person is, but I'm pretty sure that we're at some point going to say, "Wow!" And when that shift happens, we're going to come back and think to ourselves, "How could we have ever thought that React was the most amazing thing in the world," and we very quickly forget. So, one of the outcroppings is that continuing cycle because people are seeking to fix problems as quickly as possible and not everybody takes the time to really think about it. The authors of those tools, they think really deeply about these problems. They think so deeply about them. I am amazed the kinds of thought that goes into creating one of those frameworks or libraries. And I have a lot of deep respect to the Ember community, the React community, the Angular community. Those people spend a lot of time thinking about those problems. But the people that use them, use them as tools to get their job done honestly and earnestly so. But they very rightly focus on what can I get done with React rather than 'can I understand what React is really trying to do and use it to its best ability'. And we incentivize that. We incentivize that by saying that the people that advance at work, the people that become the senior developers at work are more likely the people that shipped more code. They're more likely the people that closed more bugs. And one path to getting there is you're just a really quick coder or you're one of those mythical unicorn 10x developers. But a lot of people aren't. I'm certainly not. I am not a fast developer. I'm one of the slower developers. I am very, very careful about what I write. So, I can't survive in that environment where I have to advance because I can write code quickly. Rather for me to survive in those environments, I advance or up my stature, if you will, because I understand the thing deeper than anybody else. And I think there's places in the workplace for both, so I'm not disparaging those that write a lot of code quickly. But one of the outcroppings of writing code quickly if jumping as quickly as you can to solving a problem, is that you often times find a local maximum. A mathematic theory about -- just visualize a curve kind of like the landscape of hills. If you're climbing a hill as quickly as possible and you get to the very top of the hill, it might not have been the tallest hill that you could have climbed. But you got to the top of the hill really quickly and you got the next promotion, you went on to the next thing. So, I think those value. Sometimes in your career and some people in the community who want to take a step back and understand a thing deeper, dig into a thing deeper, and I encourage people to have that as part of their toolset, that they would be that uncommon level of curiosity. Take a moment and by a moment I mean a couple of months, maybe a cycle at most of six months, take a step back from the just everyday churn of shipping a feature and fixing a bug and making the button blue, take a step back and say, "What are some of the things that I have been touching or I have been hearing people talk about," and dig into that thing and learn it. And learn it really deeply and really understand it, and maybe reinvent it if you need to. But really deeply get it. And then kind of resurface and look around and say, "All right, let me find the next thing." And so, I think those cycles are healthy for people. And I think the engineering mindset should be something that each of us strives to adopt at least some in the workplace as opposed to being almost drunk on the idea that the best developers among us are the ones that ship code the quickest. CHARLES: I think also too there is like if you do take the time and you then make that investment upfront, it engenders a lasting speed. In the same way that if you look at a child taking its first steps which is kind of the initial solution of a problem, it takes intense concentration. And it takes all the muscles or trembling and stuff just to coordinate the balance to take those first steps. But then once the child kind of understands the process fully -- like none of us, at this point in our lives, think about walking. It's just something that we do naturally. But because the human brain is wired at that point to take whether it's walking or any other kind of motor skills to really understand the motion and rewire the brain optimized for that motion so that it becomes second nature, so that you benefit from that again and again and again. And I feel having spent a long time in the industry seeing the speedups that can actually be gained by doing it slow. In other words, you expand that understanding to fill the room and then the door is only a few millimeters away, if that makes any sense. KYLE: I think it does. And I think for those that are listening just to address what questions may be popping up in people's heads because as a teacher, you learn to anticipate questions ahead of time. So I can see, even from our discussion so far, that somebody may be asking, "Okay, you're talking about some really nice theory here, but what about the practicality of it? What are the benefits of the thing? I don't have time to go learn React but I can get my job done by applying React to my business process." So, I think there are some practical things that we can point to that that come from being that uncommon level of curious, that deeper and slower and more methodical learning. One of those, I'd like to say -- and people always kind of smirk at me when I say this -- I call them getify's laws. They're just statements that I make. They're statements of my opinion and really the only thing that I'm an expert on is my own opinions and I'm never at a lack for those. It's just an opinion but I believe that you can't hope to solve a problem if you don't first understand it. Or to put another way the getify's law - if you don't understand why a piece of code works, you have no hope of understanding why it broke and how to fix it. So we do a lot of code that works and we don't know why. I would say probably the majority of code that gets shipped were just sort of only kind of tenuously understand it. And sometimes it's really tenuous. Sometimes it's house of cards development where you build a thing and you're not really quite sure why it works but you put a comment there that says 'don't touch this' and 'don't break it' or whatever. And then we back away and hold our breath and hope that it stays in place. That is a way to ship code quickly. The agile mindset has permeated so deep down that on every line of code we're thinking [inaudible], we're thinking, "Just get the thing working and get the test passing and then we'll worry about whether it's the appropriate way to solve the problem. We'll worry about that later." Many times we don't get a chance to worry about it later until there's a fire, until something's broken. And that fire could be that bug or that brokenness could be it's not doing what it's supposed to do or more often, that fire is it's doing it but it's impossibly slow, it's impractically slow. And now, we have to go back and think, "We thought we only had five pieces of data to ever work with, but now we have 50,000 and the algorithm completely falls apart. We can't do an [inaudible] scan anymore," or whatever. So that very narrow myopic short term mentality can be effective for people to get stuff shipped and to advance in their jobs, but it falls apart when things start breaking. If you're talking about a car and you said, "I don't need to know how a car works, so I can just drive a car." And that's entirely true. But if we took that to its logical extreme, you could say, "I don't even need to know that my vehicle runs of gasoline or electricity," or whatever. "I don't even need to know anything about the liquids that go in that make my car work. I just sit down behind the driver wheel and drive and it works." And that will work until your gas tank runs empty. And then at that point, you have no idea how to fix your problem. So you're going to have do some reading and worse, you're going to be at the mercy of somebody else. Having an instinct, having a clue about something about what's going on into the hood is pretty important when we go off the happy path and start trying to fix problems, whether that is fixing bugs or improving performance. Those are, I think, some very important practical takeaways that come from some people some of the time being the uncommonly deep learner. Just for fun, for my son in his school, I've been working on building a game that he's doing as part of his school through this Mathematics competition, I've been building a computerized version of this game. And those that have been following my Twitter have seen some interesting tweets about that. But I've been building an AI, a strategy turn based AI so that you can play against the computer for this thing. Tackling that requires you to kind of really understand or at least be able to fiddle your way through some deeper "CSC" kind of topics. But I got it working and it was too slow. You have to wait for the computer for 20 or 30 seconds for it to figure out its next move and that's slow. So then I started thinking about how I'm going to optimize this. Do I need an object pulled to pull stuff in and be able to reuse arrays or something? I was at a loss as to how to do that efficiently. I was completely lost. And so, I had to learn that thing. I had to think very carefully methodically. If I had let some sort of artificial deadline and say, "No, you just got to ship the game," it would have worked but it would have been impractical. And so, taking that time to think about it -- actually, I finally did. It took me days but I finally arrived at a solution for managing, sharing references that actually works from a performance perspective. It is practical now. I think there are practical takeaways. It's not just all the theory behind being a deeper learner. CHARLES: I've been thinking like where do you know where the stopping point is? Because the world is just packed with knowledge. When I was starting out as a programmer, there were people who just code assembly for fun and assemble their own microprocessors and stuff because that's what they did when they were coming up. But all of that stuff exists like we're standing on it. We've kind of lived on the level of the city street but beneath that is the subway and beneath that is the power grid and the gas pipes and the hog water pipes and all that stuff. Who knows how much more layers of urban development lie beneath some of these cities that are certainly way more rich than Austin. None of that stuff is present here. KYLE: I was going to say I didn't know there was a subway. I wish there was. CHARLES: Once I realized what the analogy was, I was standing in the Austin streets, I kind of transitioned to New York without telling anybody. My point is that in the computer world -- let's just keep it there -- let's say you're working with JavaScript and you're running on top of the browser. Most of modern browsers are written in C that are also using C libraries that are written on native platform tool kits whether it's OSX or Linux or Windows which then are written on top of these operating systems which then are written on top of these compiled assembly language that run on these microprocessors. It's a deep, deep ocean, so to speak. And we spend most of our time skimming around on the surface in our boats. And so, I guess the question is how do you know when to stop and how do you know when enough is enough? Ultimately, there is a tension between a deadline and the amount of time that you're going to invest in learning. And I think that there are definitely -- I feel very strongly that it's skewed way towards the deadline and that we need to kind of pull that tug of war back in the other direction. So the question is then how far is far enough? Or is it just really until you feel comfortable? KYLE: I see the world of what we do in computers and in software development as layers of a cake if you want to mix in a whole bunch of different metaphors here. There's lots of layers of abstraction that we create to utilize technology more effectively in our lives. And in a sense, the technological revolution from the 1940's onward has really been a story of adding layer upon layer upon layer upon layer just like a big tall cake of different abstraction because lots of different people need to eat at different layers. They need to get their jobs done, if you will, at different layers. There are people who need to get their job done the assembly language, the deep guts of your computer talking to the 1's and 0's kind of thing. And then there are people that need to work in the C libraries. And then there are people that need to work in the operating system tool kits. And then there are people that need to work in the browser. And then there are people that need to work in JavaScript. And then there are people that need to work on frameworks. And then there are people that need to work on transpilers that build the frameworks that then get compiled down. So we just keep adding more and more layers because there's more and more people that were opening up the world to, to participate. And not everybody is going to play on the same level. If your choice is to be a JavaScript developer, if your choice is to be a React developer, if your choice is to be somebody who builds those almost meta tools like the transpilers that go from one language to another, if you're a ClojureScript developer or whatever, my recommendation is that whatever layer of cake you eat out, whatever layer you've chosen to make your primary focus, I think you should be striving to become an absolute expert at that layer. And that is not a transactional thing when you just go watch the right video or read the right book and then you check it off. That will be, in most respects, a lifelong process. But I think you should strive to be as much of an expert at that layer as you can. But to become an expert at that layer, one of the most important things is to begin to have an understanding, a level of competency at the layer below it. So if you're a React developer, having a layer of JavaScript below it means that you want to have some pretty good core competency in the JavaScript language. In a sense, that's what my job is dedicated to doing is assisting people at playing at these higher levels at the frameworks and tools levels by understanding JavaScript more deeply. But if you're a core JavaScript developer and that's all you do, you should have some competency at the layer below that which we might say would be the browser API level or maybe the C level and understanding something about how memory is going to get managed to let you have some intuition about that. And so, the further you go down in the stack, you start to see that diminish but it never gets to zero. I don't think there should be any engineer out there that aspires to have absolutely no knowledge whatsoever of what a processor is or what 1's and 0's are or any of that. But that might not be your everyday task. If that's 4 layers removed and you have a lot less understanding of that layer, to be effective in your job, you should be an expert at your layer and be seeking to have a core competency level of understanding at the layer below that. I think that's how you start to answer, Charles, your question of how do you figure out where to stop is at this point in your career -- because many people will dance around and eat at different layers of the cake as they go. But whatever point you are at in your career now, be looking to understand how to eat all that layer of cake and then understand the one below it. I would say that would be the most effective strategy that I've come up with. CHARLES: I like that. I like that a lot. STEPHANIE: I want to become an expert in JavaScript. But sometimes I have doubts in my ability to "become a programmer" or think like a programmer. I feel like the people that excel in programming, and you could tell me if I'm wrong, I don't know if you've noticed this as well or haven't. But it seems like the people that excel at programming are the people that are naturally good at math. It's like they think in terms of math. I don't know if they're seeing algorithms in their brain or what it is. And I don't know if other people relate to this as well. But I'm a natural problem solver. I like problem solving but I don't think in terms of math. And I've taken a lot of math courses for my undergrad degree. I took Calculus for Biosciences like two and a half times, and so I beat my brain enough to understand those concepts. But I don't know if you have also seen that, if that is the case. And if it is the case, is there any advice for the hopeless programmers like myself that are not naturally good at math. But I am interested and I do want to be good at this. KYLE: There's hope, Stephanie. There's definitely hope. STEPHANIE: [Laughs] KYLE: Again, lots to unpack here and I thank you for asking that question because I actually do have a particular sensitivity to the mindset that seems to come around between people - again, the haves and have-nots. There are people that naturally gravitate to or understand math and there are people for whom math has always been an opaque topic that they keep running into over and over and they haven't been able to really fully engross themselves in or wrap themselves in. They haven't been able to get it, if you will. And as an educator, I don't teach math for a living. But as an educator, it deeply troubles me. As a parent, my son, Ethan, is about to turn six. He's in Kindergarten for the first time, so it is right on the front of my radar screen to think about how we teach these things. And I want for everybody to be able to grasp important concepts like obviously reading is important, but Math is one of those core concepts that I think is important for people to not be intimidated by. And I think we do ourselves a really big disservice and have for many, many years by approaching the teaching of that topic as there's one right way to know how to do math. In a sense, I think, we're seeing a shift to know there's lots of ways to learn and we should embrace that. Just like we said there's lots of different ways that people learn. There's lots of different ways to approach. There's lots of different pedagogy, if you will, around approaching math and I embrace that idea that we should be doing that. I think we should be starting that with our Kindergarteners and working all the way up. And I'm glad that there are educators that are thinking about that because my generation was taught that either you get it this way or you're just "not a math person". And I sat and sat alongside in my Science and English classes all the way through schooling even at University, I sat along people that were math people and on the other side of me were people that were "not math people". It's sad and it sucks that we would divide people that way or that people would choose to divide themselves that way because they struggle with math. My sphere of influence right now is my two kids - my son, Ethan, and my daughter, Emily. I really want for both of them, whether they become math nerds or nor, whether they have a minor in math like I do or it's just a thing that they learn, I want them to not be intimated by that. I want them to understand it. And I hope that I will be able to, in the sense, partner with the educational system. Our kids are in Austin IST Public Schools and they will be for their whole lives, as our plan, but I hope to, in a sense, be augmenting that by saying, "I understand that this is struggling for you, but let me help to at least not be intimidating, at least be a thing that you can grab on to and understand even if it's not interesting to you, it won't be scary to you," because I have family members and I see it personally that have self-labeled and self-[inaudible] themselves as "not math people" and they struggle their entire lives as a result. And I don't want that to happen. So, I'm glad I got at least a little chance to have some advocacy there to say I hope that people aren't being that way and aren't promoting patterns that treat people as either you know math or you don't. I was one of those people that gravitated towards math. But I can tell you for a fact that I do not use most of my math background on a regular basis as a programmer, and even if I try. As you're asking the question, I was doing some self-assessment here. What are the things that I know from math? Like I understand for example that a function is putting in an X value and getting out a Y value and when we plot that, we see a parabola on the graph. I get that concept. So, there's a tie in between the visual and the actual written out math for me. And I understand in calculus when we have the integral. I understand that's the area underneath the curve. So, I get those concepts. But does any of that stuff actually play into my day-to-day work? Not really. Maybe a little bit about functions since I'm starting to be a bit more attuned to the functional programming these days, but it really doesn't play into my job. But there is a part of math that really does play in almost daily, and that's what we call discrete math. That's more of the computer science-y take on math. And discrete math is things like understanding number systems, things like understanding the difference between representing something as a binary or representing it in base 10 or hexadecimal. There are certain concepts that we talk about like Big O Notation - that's one of those computer science-y concepts. When I was writing this game AI, I had an intuition about a loop inside of a loop is going to perform worse than just a single level of loop. But I didn't spend any time whatsoever actually calculating the Big O complexity of my algorithm. I just had some intuition about it. And the reason I have this intuition about it is because I took a discrete math class. So, if I could say anything to the people listening, for those that aren't math people or for some reason or another didn't really gravitate towards it, to be better at programming, I would encourage you to at least think about discrete math as an area to study to get some better understanding around, because I do think those things help. But I don't think that most of math, the stuff that most people struggle with, like algebra and matrices -- I was terrible at matrices. I hated them for some reason. I don't think most of that ever comes in. I learned what an icon vector was but I've never once coded it. So I don't think that you have to feel intimated coming at programming if you weren't one of those "math people" but there are some parts of math that do end up playing quite a bit into the programmers' everyday life. CHARLES: I think for me certainly whenever you have a particular problem, then that's an opportunity to actually explore the math behind it. I think a lot of times we put -- there's this kind of inverse relationship -- we put the cart before the horse. It's like you got to learn math and then you learn the programming. But it's almost like the equation ought to be reversed in the sense that it's like trying to -- let me just cast about for a random analogy here -- it's like learning the theory of fishing without actually living on the coast and going out on a boat every day. You can certainly study it and it can be interesting. Yes, we tie the line to the pole and we put it in the water but unless you actually have that problem of like, "Now, I'm trying to catch fish," you actually are connected to it in a way that's going to help you understand what solutions work and which ones don't. I often feel like we frontload way too much on the theory. I feel it has to be connected to practice, I guess is what I'm saying. Because certainly my experience, I come from a CS background, but I didn't switch to CS until my junior year of college. And that after I'd basically dropped out of school for two years to work at a startup. And I remember it made a lot more sense because I had this prior programming experience. It's like, "Oh…" Whereas, I think a lot of my classmates, they were kind of dumbfounded by, "What does this even mean? I don't understand. I don't understand how this connects to anything." But if you have that kind of experience, then the learning can come in hand with it but it has to be more of an organic process as opposed to one coming before the other. That's my experience. KYLE: I love what you're saying there and I want to build off of that to unpack some of my most recent passion and focus in the area of education and with developers because I really think what you're saying is the foundation is the same belief I have. So, I'm right there with you. If you look at humans and the way humans have passed along information and skill to the next generation, if you look at that over the course of history, we have mountains of precedent around the idea that skills are passed along through the mentorship model. Some like to call it the master apprentice model. It's the more classical way to think about it. But just the more modern way is to call it mentorship. For example, chefs. You would never suggest that the best chef at the best restaurant in town and the way that that chef got there, the way that that chef got to be the best chef in town and have the best restaurant was that they sat in a classroom and learned all the theory about how to bake a chicken. First, before going and baking the chicken, there's lots of ways that they could have gotten to be better but probably the least effective way would have been for them to learn all the theory upfront and then just go work in a kitchen for year after year after year after year and almost accidentally -- we call it the School of Hard Knocks -- accidentally learn all those experiences. That's how a lot of people define experience is experience these mistakes over time getting practice making perfect. That does work and lots of people have done that. And I certainly would say a lot of my story is that way, but I wish that I'd had a mentor. I wish that I'd had somebody like what happens with chefs to sit there and say, "I'm not just going to let you figure it out on your own and screw up a bunch of chickens. What I'm going to do is give you a little bit of information about cooking a chicken. Like for example, what the temperature of the oven needs to be, how to tell what the temperature of the chicken is to know that it's fully cooked, what materials you need and what utensils. But we're going to spend 10 minutes in the classroom talking about it and then we're going to go sit in a kitchen and you're going to watch me bake a chicken. And you're going to watch very carefully. And I want you to ask a lot of questions about what I'm doing and I'm going to talk to you about it every single step and the decisions that I'm making. And then I'm going to do that again and again and again and again. And over time, you're going to start to pick up on and glean some of my experience from observation. And then eventually, once you are starting to feel more confident about it, we're going to flip the tables and now, you're going to start baking the chicken but you're going to do it step by step methodically and I'm going to watch you and be very closely paying attention. And I'm going to ask you questions and I'm going to say 'why did you squirt that there and why did you do this and why did you turn on the oven right now'. And I'm going to ask you about that stuff and challenge you to make sure that you really got all the different pieces of what it takes to master this skill. And then I'm going to do that again and again and again. And after we feel pretty good about chickens, we'll go back to the classroom and we'll talk about cooking steak and then we're going to repeat this process over and over." That is much more the picture of how that mastery of that skill is replicated in another person is that mentorship model. And we've seen that with stone masons and carpenters and plumbers and chefs and caterers. And on down the line through most of human history, we can see that that is how skills are passed along. What I think we're missing is that there's a lot of value to be gained by applying those models to software development. As a matter of fact, I think if you ask most developers, regardless of the skill level even if they were a senior developer -- although certainly the intermediate and junior developers are more willing to admit it. But I think if you really ask in their heart of hearts, almost all the developers would say, "Oh, I'd love to have a mentor to help me get better but I don't know how or I can't afford it or there aren't any available or I don't know what to do," because we haven't prioritized as our part of the industry making education more effective. And so, when you talk about 'I need to practice a thing, not just know the theory', you're absolutely right. You're absolutely right that sitting in a classroom and learning a bunch of stuff which ironically that's what I do. I teach corporate training classes, I threw out a bunch of information then I know as I'm throwing out that information, the vast majority of it isn't going to be retained because the only stuff that will be retained is the stuff that somebody gets a chance to practice pretty quickly. And by pretty quickly, I think probably that horizon level is about three days beyond when you've learned it. If you don't get a chance to really practice, and I don't mean just the artificial stuff that we teachers come up with like a silly little toy examples and the foobar kind of stuff, I mean really practice in a context of something that matters and that you're thinking about it and you need to solve it. If you don't get a chance to practice some of that theory within about three or four days, you're going to lose it. So, I present to you a set of information in a week-long training course that you really ought to actually learn. And by learn, I mean more than just hear the theory but also practice it. You really should learn that over 12 to 24 months. But I give it to you in 40 hours because that's, again, the industry incentivizes how quickly can I check off the check box then my developers learn how to become React developers or that we learned about JavaScript. Instead of focusing on how do I really get them to know it. And the only way to really get somebody to know it is to have somebody watching over them as they practice what was taught. You teach a little bit and you have a bunch of practice. And that practice can't be just the developer has to figure it out on their own and make their own mistakes and figure it out through Stack Overflow, it has to be monitored, it has to be proactively mentored. And they have to take a little bit of learning, a lot of guided practice. Pipeline that across, that's how we make this educational process for developers become much more efficient, much more effective. And so in a sense, what I'm trying to do is disrupt my own educational model and try to [inaudible] myself as a business by saying, "I teach it in the classroom but every time I walk out of that classroom, I feel empty inside," because I feel not just tired physically because it is exhausting, but I also feel empty inside because I know that what's really missing is that I just contributed to yet another transactional learning experience. But what really is important is for people to know that learning that is most effective is learning that's relational. Learning has to be paired with people because at its heart, what we do as developers is a people game. It's not an 'instruct the computer' game. The 'instruct the computer' is a side effect of what we do in connecting with people and passing along information and skill and knowledge. We've got to do that because we are throwing all kinds of money and time and effort at figuring out how to make people learn better through books and videos and conferences and tech schools and the list just goes on and on and on. And it's good that there's a wide buffet for people to pick from, there's no question. But most of that stuff isn't as effective as it ought to be, and that is why people have to keep doing it over and over and over again. They have to try all these different things because they don't get satiated by picking the one right thing that they ought to have fixed. I happen to be obviously very bias, but I happen to believe that a lot of the problems that developers face, a lot of the overhead of code maintenance and all of that stuff, it could be solved if people were trying to implement mentorship for developer education. And that's what I'm trying to do. My recent efforts are around upending or reimagining the normal corporate developer training. Of course I still offer that. And if anybody wants me to come teach, I can still do that. But what I'm moving towards and building a startup to offer mentoring at scale because I believe that's where we move it from transactional relationship. We make it about people and then we get a chance to really practice what we're learning. That's how you take a person, and get them from being junior to being intermediate or from intermediate to senior is that they have to have practice. Would you rather them figure it out on their own and make lots and lots of mistakes or would you rather them be guided and monitored as they go through that process of practice? I think the latter would be a lot more effective. CHARLES: For people who are excited about this, who want to figure out ways in which to engage in this relational learning, this can be a very expensive proposition especially for smaller companies. But even for larger companies, one of the things you're hoping to address is a way to make this when you say 'do it at scale, make it more accessible' in terms of those time and resources. KYLE: In a sense I would be failed at the start if I didn't feel like I had a model for scaling mentorship. If I was just on here and [inaudible] saying, "Hey, everybody. You should go mentor," and I had no way of doing that, then everybody will say, "Okay, that's all well and great. Thanks." And as soon as this podcast ended, they'd just go on back to their normal day jobs and fix anything. I really do believe that there are ways to scale out and to make it effective. That doesn't necessarily mean that the price tag is cheap because time is expensive. And what we're saying is you need expert time paired with your people to get them to where you need them to go. But I want to push back on the notion that expense makes things inaccessible, because I want to point out -- this is almost like I'm doing a customer pitch. But I just want to point out that there's an awful lot of things that we spend money on as managers of software development teams. For example, I've talked to managers of software development teams and they've said, "We probably spend 70% to 80% of our time maintaining our existing code and fixing bugs, and only maybe 20% of our time implementing new stuff." Some people listening would say, "Good lord, I'd love to have 20%. We probably spend 5% of our time on that and 95% on maintenance." So those numbers differ. But there's a lot of overhead associated with running a software development team. And one of my theories which I believe we will prove out as we scale this out, one of my theories is that if you want people to avoid having to come back and return on something. One of the ways to do that is to empower them with better education before they write that line of code. I think even though yes it will be more expensive to get your developers mentored, you will actually not spend more as a company, you will spend much less because you'll be investing that money much more effectively in the things that actually make them retain and get a chance to practice that. It also means that hiring will be cheaper because you'll know much more deeply what your company wants and needs and that will make it a lot easier to identify the right candidates. It means that the total cost of ownership of yourself will be vastly less. So there's lots of dollars here that I think we can pull that we are, in a sense, wasting or misappropriating to make it more effective to invest in mentorship. I think what we need is a process and a model instead of tools to do that, and that's my mission. That's my goal. CHARLES: I am very, very excited to see that, because I know that that is something that one, holds the value. Here at the Frontside, we see as one of our core beliefs and one of our core aspects or mission is to level people up and make sure that they can improve themselves as a developer and improve the quality of the products that they develop. But it's definitely something that we've struggled with. So, I'm really curious and excited to see the outcome of this. So, we'll be on the lookout for it. Is it still under the radar? KYLE: There's no company name to announce yet. There's no website or Twitter account. But I can say that it's been under active development now for four to six months. I have a team of founders with me and we are formalizing our process in trying to get funded for that. I hope within the next few months that there'll be a much bigger announcement about where we're headed with it because I'm all in on believing that it's not just good enough for me to keep churning. I get emails and tweets weekly. I get a couple to maybe five or ten sometimes in a week of people saying, "Hey, I read your book," or, "I watched your Frontend Master's training video," or whatever, "And that's awesome. I'd love it if you could help me with something. Could you spend some time? How much would I need to pay you to get a few hours of your time to sit here and talk with me?" And it pains me to get these kinds of requests. And the reason it pains me is because I would absolutely love to spend that kind of time with people, but that kind of time is so valuable right now. Time is so valuable because the process of mentoring currently is incredibly time intensive. It's very, very expensive to do this. And that's why I think it's not done very widespread is because people haven't figured out how to make it effective, from time and money perspective. And I know that pain personally. I have to turn people down and say, "I'd love to but I'm too busy because…" and then fill in the blank with a thousand things. I'd love to have that time. What I really want is I really want to be able to do this effectively and to scale it, because people are hungry. They want to learn. I believe that what we need to do is unlock that hunger, not necessarily inspire people. I think we need to unlock and empower that hunger that people naturally tend to have to want to get better at what they do. And I think this is one of the ways that we can help people get better. STEPHANIE: I also wanted to point out that for companies that are interested in doing this, not only do junior or apprentices benefit from this model but the senior developers also benefit from this. I have personally seen someone on my team, Alex, from all the times that we've been pairing and talking about JavaScript concepts, I have seen an exponential growth in just the way that he explains things. And they do say the one that does the teaching does the learning. And I have seen that in him and I think it's something that every team could benefit from. KYLE: I 100% agree. And to build on that, I would say what we're really doing with that is we're helping people find more purpose for what they do. And who doesn't want to have more purpose and more meaning? We're giving people a way to -- as I said, all boats rise with the tide. We're giving people a way to help other people around them. And it doesn't have to be like some macro scale thing where you become an international conference speaker. You don't even have to speak at your local city meetup. You can just pair with the person next to you and help them learn the thing that you're learning, and then learn from them. And you've made the world better, you've made the workplace better, you've made yourself better. It goes back to what I said before - I think we have to get better. The biggest thing that's lacking from us developers right now, in my opinion, the emotional muscle that we need to work on the most is recognizing empathy for our fellow human beings for the people around us because I really deeply in my core believe and my DNA I believe that what we're about is people and not about the code that gets written as a result of this connections. If we can focus on building the relationships around this. You don't have to go pay for the service of the startup that I'm building. You can implement this just like what Stephanie just said, by looking for opportunities whether it's coding, whether it's code review used as a way to learn, whether it's doing a brown back lunch, you can look for ways to build the culture of learning into the workplace around you and people will benefit from that. You will inspire people to get bigger and better as a result of providing that environment. CHARLES: Fantastic! If people need to get hold of you, Kyle, what is the best way to reach out to get in touch? KYLE: The best way to get in touch with me is to find getify. That's how people know me online. That's my Twitter handle, that's my GitHub handle, it's also my Gmail address. So, getify@gmail.com. Reach out to me in any one of those channels, probably through Gmail is best. If you'd like to talk more about education, if you'd like me to come and help your team, I would love to come and do a workshop and then build a relationship with you or we can begin this mentoring process as I spin that up. If you're interested in that, if you're hoping to learn from some of my resources, you can check out my book series. I have the You Don't Know JS books that I wrote that many people know about. That's up on my GitHub. I'm almost done with my next book which is Functional Light JavaScript, you can check that out on GitHub. All that stuff you can read for free. You can also buy it if you'd like to -- and I always appreciate people if they want to support me. But check out my books. I have training videos available on FrontendMasters.com. I think I have nine courses and we've already scheduled a few more that I'm going to be teaching later in the Spring. That's a fantastic platform. There's 50 or 60 really incredibly well-versed experts that are teaching on that platform. So, check out Frontend Masters. Some of those videos are also out on Pluralsight. You can check them out as well. Check out books, check out the training videos, get in contact with me if I can help you in some way with training at your company. But I would love it that even if that isn't the channel, if you take nothing else away from the podcast, go talk about learning stuff deeper within the workplace. That will be the best takeaway that we can get from this podcast. CHARLES: Yeah, definitely. I think the things that we talked about here really apply far beyond JavaScript and even really far beyond the technical trade of programming. All right, that's a wrap. Bye everybody!