Skip to content
General

12 Web Development Podcasts That Inform and Inspire

Jessica Wilkins

Jessica Wilkins

Published May 5, 2022

Updated Feb 13, 2023

6 min read

This article was written over 18 months ago and may contain information that is out of date. Some content may be relevant but please refer to the relevant official documentation or available resources for the latest information.

Podcasts can be a great source of entertainment and education. But with the sheer volume of podcasts out there, sometimes it is hard to know what to listen to.

In this article, I will share my favorite podcasts to listen to that discuss the latest in web technologies and careers.

Modern Web

The Modern Web podcast explores the latest in web development by interviewing leading industry professionals. Past guests have included Evan You (Creator of Vue.js), Jem Young (Engineering Manager at Netflix) and Mark Thompson (Developer Relations Engineer at Google).

The hosts are all Software Architects at This Dot Labs and they do a great job coming up with thought provoking questions for the guests.

My favorite episode is when Jesse Tomchak interviewed Jem Young and discussed his role as an engineering manager and the challenges he has faced so far.

CodeNewbie

If you are new developer and looking to learn more about the industry, then CodeNewbie is the podcast for you. Saron Yitbarek (host) and the rest of the team do a great job selecting a diverse range of topics and make it accessible to all developers.

Some of the guests have included Danny Thompson, Arit Amana, Cassidy Williams, Quincy Larson and Angie Jones.

My favorite episode is titled How freeCodeCamp has evolved over time with Quincy Larson. This episode chronicles Quincy's journey with freeCodeCamp and covers future developments for the organization.

The Changelog: Software Development, Open Source

The Changelog has over 400 episodes of interviews with leading industry professionals discussing everything from AI, to open source, UI/UX, engineering management, and more.

Adam Stacoviak and Jerod Santo do a great job creating engaging conversations with their guests and keeping it educational for the audience. Some of their guests have included Feross Aboukhadijeh, Annie Sexton and legendary computer scientist Brian Kernighan.

My favorite episode would have to be the interview on Brian Kernighan as he shares his thoughts on how software has evolved over his 50+ year career.

JS Party: JavaScript, CSS, Web Development

If you are interested in learning about all things JavaScript, then JS Party is the place to start. You will learn about the latest developments in popular web technologies, performance, open source projects and more.

Each week, they have a different set of hosts that include Jerod Santo, Feross Aboukhadijeh, Kevin Ball, and Amelia Wattenberger. Some of their previous guests have included Kent Dodds, Zach Leatherman, and Jen Looper.

My favorite episode is titled Remix helps bridge the network chasm where Kent Dodds talks about this new framework and why it is a good addition to the web ecosystem.

Front End Happy Hour

If you are looking for a laid back podcast discussing all things frontend web development, then take a listen to Front End Happy Hour.

Each week, a panel of Software Engineers from Netflix, Twitch, & Atlassian will invite guests to discuss their experiences with frontend development over a casual conversation with drinks. Previous guests have included Sumana Mohan, Joe King, Nazanin Delam, and Dan DiGangi.

My favorite episode is titled Standing out in a crowded bar where the hosts bring on Taylor Desseyn and Jono Grayson to discuss ways to stand out in the job market.

Developer Tea

Developer Tea produces short impactful episodes on career advancement. Jonathan Cutrell (host) covers a variety of topics including effectively working with management, staying motivated, and building better work relationships with your team.

A good episode to listen to would be Swizec Teller's two part episode on the Senior Engineering Mindset.

React Podcast

If you learning about React and want to hear about the latest developments, then the React Podcast is for you.

Michael Chan (host) interviews leading professionals about their thoughts on the industry and all things React development. Previous guests have included Shawn Swyx Wang, Cassidy Williams and Kent C. Dodds.

My favorite episode is titled Kent C. Dodds on Epic React where they discuss his popular React course and how it will help you level up as a developer.

JavaScript Jabber

JavaScript Jabber covers all things JavaScript including frontend architecture, Web3, React, D3 and more. The panel of hosts include Aimee Knight, AJ O'Neal, Charles Max Wood, Dan Shappir, and Steve Edwards.

My favorite episode is about Sam Sycamore's story on transitioning from landscape construction worker to full time developer.

Syntax

The Syntax podcast explores all this web related including the latest in Gatsby, AWS, Web3, Remix and more. Wes Bos and Scott Tolinski (hosts) do a great job creating fun and educational content for their listeners.

My favorite episode to listen to would be the JavaScript × STUMP’D episode where the two hosts try to answer JavaScript interview questions.

HTML All The Things

HTML All The Things cover all things web development, web design and small business. Matt Lawrence and Mike Karan (hosts) discuss a variety of topics including entrepreneurship, how to handle stress, Web3, web performance, and more.

My favorite episode to listen to is the one titled The Dark Side of Web Development which provides a look into the not so pleasant side of this industry.

Virtual Coffee Podcast

Virtual Coffee is a community of developers at all stages of their software journey who collaborate and support each other along the way. Each week, Dan Ott and Bekah Hawrot Weigel interview one of the community members to discuss their journey into tech.

My favorite episode is titled Yolanda Haynes - Breaking into Tech: It Takes Time which follows her journey into web development and the lessons she learned along the way.

There are plenty of inspiring stories to listen to on The Virtual Coffee Podcast that are both entertaining and educational.

freeCodeCamp

freeCodeCamp is an educational non-profit company with a mission to provide free programming education to everyone regardless of age, race or socioeconomic background. Their podcast features a lot of stories on how career changers made the transition into web development.

My favorite episode is titled How a former music teacher taught herself to code and landed a job at GitHub.

Conclusion

I hope you enjoyed my list of 12 podcasts that will inform and inspire your coding journey! I enjoy listening to these podcasts during work and I hope you do too.

Here are some more podcasts I am looking forward to exploring in the future and have been well received by the developer community.

This Dot is a consultancy dedicated to guiding companies through their modernization and digital transformation journeys. Specializing in replatforming, modernizing, and launching new initiatives, we stand out by taking true ownership of your engineering projects.

We love helping teams with projects that have missed their deadlines or helping keep your strategic digital initiatives on course. Check out our case studies and our clients that trust us with their engineering.

About the author(s)
  • Author Jessica Wilkins

    Jessica Wilkins

    Jessica Wilkins is a classical musician turned Software Engineer. Prior to joining the tech industry, she spent her time running her own sheet music company (JDW Sheet Music) as well as performing and teaching in Los Angeles, CA. She enjoys working with React and TypeScript. She is also a prolific technical writer for freeCodeCamp.

    @codergirl1991@jdwilkin4

You might also like

I Broke My Hand So You Don't Have To (First-Hand Accessibility Insights) cover image

I Broke My Hand So You Don't Have To (First-Hand Accessibility Insights)

We take accessibility quite seriously here at This Dot because we know it's important. Still, throughout my career, I've seen many projects where accessibility was brushed aside for reasons like "our users don't really use keyboard shortcuts" or "we need to ship fast; we can add accessibility later." The truth is, that "later" often means "never." And it turns out, anyone could break their hand, like I did. I broke my dominant hand and spent four weeks in a cast, effectively rendering it useless and forcing me to work left-handed. I must thus apologize for the misleading title; this post should more accurately be dubbed "second-hand" accessibility insights. The Perspective of a Developer Firstly, it's not the end of the world. I adapted quickly to my temporary disability, which was, for the most part, a minor inconvenience. I had to type with one hand, obviously slower than my usual pace, but isn't a significant part of a software engineer's work focused on thinking? Here's what I did and learned: - I moved my mouse to the left and started using it with my left hand. I adapted quickly, but the experience wasn't as smooth as using my right hand. I could perform most tasks, but I needed to be more careful and precise. - Many actions require holding a key while pressing a mouse button (e.g., visiting links from the IDE), which is hard to do with one hand. - This led me to explore trackpad options. Apart from the Apple Magic Trackpad, choices were limited. As a Windows user (I know, sorry), that wasn't an option for me. I settled for a cheap trackpad from Amazon. A lot of tasks became easier; however, the trackpad eventually malfunctioned, sending me back to the mouse. - I don't know a lot of IDE shortcuts. I realized how much I've been relying on a mouse for my work, subconsciously refusing to learn new keyboard shortcuts (I'll be returning my senior engineer license shortly). So I learned a few new ones, which is good, I guess. - Some keyboard shortcuts are hard to press with one hand. If you find yourself in a similar situation, you may need to remap some of them. - Copilot became my best friend, saving me from a lot of slow typing, although I did have to correct and rewrite many of its suggestions. The Perspective of a User As a developer, I was able to get by and figure things out to be able to work effectively. As a user, however, I got to experience the other side of the coin and really feel the accessibility (or lack thereof) on the web. Here are a few insights I gained: - A lot of websites apparently _tried_ to implement keyboard navigation, but failed miserably. For example, a big e-commerce website I tried to use to shop for the aforementioned trackpad seemed to work fine with keyboard navigation at first, but once I focused on the search field, I found myself unable to tab out from it. When you make the effort to implement keyboard navigation, please make sure it works properly and it doesn't get broken with new changes. I wholeheartedly recommend having e2e tests (e.g. with Playwright) that verify the keyboard navigation works as expected. - A few websites and web apps I tried to use were completely unusable with the keyboard and were designed to be used with a mouse only. - Some sites had elaborate keyboard navigation, with custom keyboard shortcuts for different functionality. That took some time to figure out, and I reckon it's not as intuitive as the designers thought it would be. Once a user learns the shortcuts, however, it could make their life easier, I suppose. - A lot of interactive elements are much smaller than they should be, making it hard to accurately click on them with your weaker hand. Designers, I beg you, please make your buttons bigger. I once worked on an application that had a "gloves mode" for environments where the operators would be using gloves, and I feel like maybe the size we went with for the "gloves mode" should be the standard everywhere, especially as screens get bigger and bigger. - Misclicking is easy, especially using your weaker hand. Be it a mouse click or just hitting an Enter key on accident. Kudos to all the developers who thought about this and implemented a confirmation dialog or other safety measures to prevent users from accidentally deleting or posting something. I've however encountered a few apps that didn't have any of these, and those made me a bit anxious, to be honest. If this is something you haven't thought about when developing an app, please start doing so, you might save someone a lot of trouble. Some Second-Hand Insights I was only a little bit impaired by being temporarily one-handed and it was honestly a big pain. In this post, I've focused on my anecdotal experience as a developer and a user, covering mostly keyboard navigation and mouse usage. I can only imagine how frustrating it must be for visually impaired users, or users with other disabilities, to use the web. I must confess I haven't always been treating accessibility as a priority, but I've certainly learned my lesson. I will try to make sure all the apps I work on are accessible and inclusive, and I will try to test not only the keyboard navigation, ARIA attributes, and other accessibility features, but also the overall experience of using the app with a screen reader. I hope this post will at least plant a little seed in your head that makes you think about what it feels like to be disabled and what would the experience of a disabled person be like using the app you're working on. Conclusion: The Humbling Realities of Accessibility The past few weeks have been an eye-opening journey for me into the world of accessibility, exposing its importance not just in theory but in palpable, daily experiences. My short-term impairment allowed me to peek into a life where simple tasks aren't so simple, and convenient shortcuts are a maze of complications. It has been a humbling experience, but also an illuminating one. As developers and designers, we often get caught in the rush to innovate and to ship, leaving behind essential elements that make technology inclusive and humane. While my temporary disability was an inconvenience, it's permanent for many others. A broken hand made me realize how broken our approach towards accessibility often is. The key takeaway here isn't just a list of accessibility tips; it's an earnest appeal to empathize with your end-users. "Designing for all" is not a checkbox to tick off before a product launch; it's an ongoing commitment to the understanding that everyone interacts with technology differently. When being empathetic and sincerely thinking about accessibility, you never know whose life you could be making easier. After all, disability isn't a special condition; it's a part of the human condition. And if you still think "Our users don't really use keyboard shortcuts" or "We can add accessibility later," remember that you're not just failing a compliance checklist, you're failing real people....

Dec 6, 2023

5 mins

AccessibilityA11yWeb DevelopmentHTML
What is Accessibility and Why It Matters cover image

What is Accessibility and Why It Matters

Billions of people around the world use various web applications in their everyday lives. As web developers, we strive to build strong websites that can be used and enjoyed by everyone. But what is accessibility and why should we care about it? Web accessibility is the practice of building websites that can be used by everyone. This includes those with disabilities, those with slow network connections or users on mobile phones. Everyone should have the ability to easily navigate and interact with all of the web content on the site. Why is it Important to Design for Accessibility? A large portion of websites online are not accessible for all users, and it creates a barrier to access information for some groups of individuals. The goal of accessibility is to not exclude anyone from information, products or services online. A focus on accessibility promotes inclusion of all groups including the following: - Individuals with visual disabilities - Individuals with auditory disabilities - Individuals with motor disabilities - elderly individuals - those in developing countries affected by varying connection speeds - those in rural areas affected by varying connection speeds A focus on accessibility is also really important for businesses. When a business creates strong accessible designs and web products, the user experience is much stronger and customers are left more satisfied with the end product. What are the four principles of accessibility? The Web Content Accessibility Guidelines(WCAG) are a set of guidelines and standards for accessibility. The WCAG has come up with the acronym POUR which stands for Perceivable, Operable, Understandable, and Robust. Perceivable - Users should be able to perceive content through one of their senses (visual, sound or touch). Operable - Users should be able to use all interactive elements on the page, and it should work with assistive technologies like screen readers. Understandable - Users should be able to clearly understand the content on the website. Robust - Users should be able to choose the technology they want to help them interact with on the website. To learn more about these principles, please visit the W3C documentation. What are examples of web accessibility? There are many things you can do to ensure that your website is accessible to all. I will show you a few examples of what you can implement in your sites. Semantic HTML Semantic HTML describes the meaning of the content to the browser and developer. Examples of semantic HTML elements include main, article, and nav elements. When creating your markup, you should always strive to use semantic HTML when possible. Other elements like div and span tags hold no special meaning and act as generic containers. Semantic HTML helps users relying on assistive technologies understand the meaning behind the content. Avoid using markups like this: ` Instead, you should write markup like this: ` Alt text Alt text is short descriptive text associated with an image or media element. It is used to help assistive technologies like screen readers understand the content. Inside your code, you would add an alt attribute inside the img element like this: ` That short descriptive text will help those with visual disabilities understand what the image is supposed to be about. Creating meaningful Links When you are adding links on your website, it is really important that your link text is descriptive. You want to avoid creating link text like this: ` "Click here" is not that descriptive, and doesn't tell you anything about where the link is going. This would be an example of using descriptive anchor text. ` Where can I learn more about web accessibility? There are many great resources where you can learn more about accessibility. Here are a few options to choose from. - W3C Web Accessibility Initiative - JavaScript Marathon: Developing Accessible Websites & Web-Based Apps with JavaScript - The Meaning of Web Accessibility: Accessible HTML & Assistive Technologies w/ Nic Steenhout Conclusion When you are building out your websites, please make sure that your content is accessible to everyone. A large portion of websites online are not accessible for all users and it creates a barrier to access information for some groups of individuals. Remember that accessibility is not a feature, but a requirement when building strong web applications....

Jul 21, 2022

3 mins

Web Development
Introducing the Next.js 12 and Chakra UI Starter Kit cover image

Introducing the Next.js 12 and Chakra UI Starter Kit

Next.js is a very popularly used React framework, and to help support developers using Next, This Dot Labs has just created a new starter kit that they can use to bootstrap their next projects. This Next.js 12 starter kit comes with formatting, linting, example components, unit testing and styling with Chakra UI. In this article, we will take a deeper look into what this kit has to offer. Table of Contents - How to initialize a new project - Technologies and tools included with the kit - Next.js v.12 - Chakra UI - Jest - Storybook - ESLint and Prettier - A note about state management - Deployment options - Reasons for using this kit - Conclusion How to initialize a new project 1. Run npm create @this-dot/starter -- --kit next12-chakra-ui or yarn create @this-dot/starter --kit next12-chakra-ui 2. Follow the prompts to select the next12-chakra-ui starter kit, and name your new project. 3. cd into your project directory and run npm install or yarn install . 4. Run npm run dev or yarn run dev to start the development server. 5. Open your browser to http://localhost:3000 to see the included example code running. Technologies and tools included with the kit Next.js v.12 This starter kit uses version 12 of Next.js with the TypeScript configuration. We have also included an example inside the src/pages/api/hello.ts file on how to work with the built-in types for API routes. ` Chakra UI This starter kit uses Chakra UI for all of the styling. We have already setup the ChakraProvider inside the src/pages/_app.tsx file, which includes extended theme objects for colors, font weights, and breakpoints that you can customize to your liking. ` You can take a look at any of the example components inside of the src/components folder on how to best use Chakra's components. Jest This starter kit uses the Jest testing framework for its unit tests. The unit tests for the home page can be found in the tests directory. ` Storybook This starter kit comes with Storybook so you can test out your UI components in isolation. We have also included the @storybook/addon-a11y addon, which is used to check for common accessibility errors in your components. When you run Storybook, each story will show detailed explanations with suggested fixes if errors are found. Examples of stories can be found in the components directory. ESLint and Prettier This start kit uses ESLint for linting and Prettier for formatting. All of the configurations have been setup for you so you can get to building out your project faster. A note about state management This starter kit does not use a global state management library. Instead we are managing state within the routing system. For examples, please look at the /src/pages/counter-example.tsx and src/pages/fetch-example.tsx files. Deployment options You can use services like Netlify or Vercel to deploy your application. Both of these services will come with a built-in CI/CD pipeline and live previews. Reasons for using this kit Next.js is a versatile framework, and can be used for a variety of situations. Here are some examples of what you can use our starter kit for. - personal blog - e commerce application - user dashboard application - MVP (Minimum Viable Product) Conclusion Next.js has a lot to offer, and this new starter kit will help you bootstrap your next project. Study the example components to learn about best practices with Next.js and Chakra UI. Get started building out new features for your project with our new starter kit!...

Apr 3, 2023

3 mins

NextJS
Understanding Sourcemaps: From Development to Production cover image

Understanding Sourcemaps: From Development to Production

What Are Sourcemaps? Modern web development involves transforming your source code before deploying it. We minify JavaScript to reduce file sizes, bundle multiple files together, transpile TypeScript to JavaScript, and convert modern syntax into browser-compatible code. These optimizations are essential for performance, but they create a significant problem: the code running in production does not look like the original code you wrote. Here's a simple example. Your original code might look like this: ` After minification, it becomes something like this: ` Now imagine trying to debug an error in that minified code. Which line threw the exception? What was the value of variable d? This is where sourcemaps come in. A sourcemap is a JSON file that contains a mapping between your transformed code and your original source files. When you open browser DevTools, the browser reads these mappings and reconstructs your original code, allowing you to debug with variable names, comments, and proper formatting intact. How Sourcemaps Work When you build your application with tools like Webpack, Vite, or Rollup, they can generate sourcemap files alongside your production bundles. A minified file references its sourcemap using a special comment at the end: ` The sourcemap file itself contains a JSON structure with several key fields: ` The mappings field uses an encoding format called VLQ (Variable Length Quantity) to map each position in the minified code back to its original location. The browser's DevTools use this information to show you the original code while you're debugging. Types of Sourcemaps Build tools support several variations of sourcemaps, each with different trade-offs: Inline sourcemaps: The entire mapping is embedded directly in your JavaScript file as a base64 encoded data URL. This increases file size significantly but simplifies deployment during development. ` External sourcemaps: A separate .map file that's referenced by the JavaScript bundle. This is the most common approach, as it keeps your production bundles lean since sourcemaps are only downloaded when DevTools is open. Hidden sourcemaps: External sourcemap files without any reference in the JavaScript bundle. These are useful when you want sourcemaps available for error tracking services like Sentry, but don't want to expose them to end users. Why Sourcemaps During development, sourcemaps are absolutely critical. They will help avoid having to guess where errors occur, making debugging much easier. Most modern build tools enable sourcemaps by default in development mode. Sourcemaps in Production Should you ship sourcemaps to production? It depends. While security by making your code more difficult to read is not real security, there's a legitimate argument that exposing your source code makes it easier for attackers to understand your application's internals. Sourcemaps can reveal internal API endpoints and routing logic, business logic, and algorithmic implementations, code comments that might contain developer notes or TODO items. Anyone with basic developer tools can reconstruct your entire codebase when sourcemaps are publicly accessible. While the Apple leak contained no credentials or secrets, it did expose their component architecture and implementation patterns. Additionally, code comments can inadvertently contain internal URLs, developer names, or company-specific information that could potentially be exploited by attackers. But that’s not all of it. On the other hand, services like Sentry can provide much more actionable error reports when they have access to sourcemaps. So you can understand exactly where errors happened. If a customer reports an issue, being able to see the actual error with proper context makes diagnosis significantly faster. If your security depends on keeping your frontend code secret, you have bigger problems. Any determined attacker can reverse engineer minified JavaScript. It just takes more time. Sourcemaps are only downloaded when DevTools is open, so shipping them to production doesn't affect load times or performance for end users. How to manage sourcemaps in production You don't have to choose between no sourcemaps and publicly accessible ones. For example, you can restrict access to sourcemaps with server configuration. You can make .map accessible from specific IP addresses. Additionally, tools like Sentry allow you to upload sourcemaps during your build process without making them publicly accessible. Then configure your build to generate sourcemaps without the reference comment, or use hidden sourcemaps. Sentry gets the mapping information it needs, but end users can't access the files. Learning from Apple's Incident Apple's sourcemap incident is a valuable reminder that even the largest tech companies can make deployment oversights. But it also highlights something important: the presence of sourcemaps wasn't actually a security vulnerability. This can be achieved by following good security practices. Never include sensitive data in client code. Developers got an interesting look at how Apple structures its Svelte codebase. The lesson is that you must be intentional about your deployment configuration. If you're going to include sourcemaps in production, make that decision deliberately after considering the trade-offs. And if you decide against using public sourcemaps, verify that your build process actually removes them. In this case, the public repo was quickly removed after Apple filed a DMCA takedown. (https://github.com/github/dmca/blob/master/2025/11/2025-11-05-apple.md) Making the Right Choice So what should you do with sourcemaps in your projects? For development: Always enable them. Use fast options, such as eval-source-map in Webpack or the default configuration in Vite. The debugging benefits far outweigh any downsides. For production: Consider your specific situation. But most importantly, make sure your sourcemaps don't accidentally expose secrets. Review your build output, check for hardcoded credentials, and ensure sensitive configurations stay on the backend where they belong. Conclusion Sourcemaps are powerful development tools that bridge the gap between the optimized code your users download and the readable code you write. They're essential for debugging and make error tracking more effective. The question of whether to include them in production doesn't have a unique answer. Whatever you decide, make it a deliberate choice. Review your build configuration. Verify that sourcemaps are handled the way you expect. And remember that proper frontend security doesn't come from hiding your code. Useful Resources * Source map specification - https://tc39.es/ecma426/ * What are sourcemaps - https://web.dev/articles/source-maps * VLQ implementation - https://github.com/Rich-Harris/vlq * Sentry sourcemaps - https://docs.sentry.io/platforms/javascript/sourcemaps/ * Apple DMCA takedown - https://github.com/github/dmca/blob/master/2025/11/2025-11-05-apple.md...

Nov 21, 2025

5 mins

JavaScript

Let's innovate together!

We're ready to be your trusted technical partners in your digital innovation journey.

Whether it's modernization or custom software solutions, our team of experts can guide you through best practices and how to build scalable, performant software that lasts.

Prefer email? hi@thisdot.co