Remember that time you had that bug that too took you an all-nighter to solve? And that time when you first saw hot-reloading work and it saved you tons of time when making sure your website looked right?
We all have real life development stories we tell each other about the good and bad struggles we faced, and how we ultimately came to overcome them. Often these experiences define why we choose to use the technologies that we use today. We think it would be great to share these stories with everyone.
Here is the key theme you will hear on the podcast:
real developers talking to other real developers about real applications they’ve built and why they chose the technologies.
There are plenty of great shows about ideas and architectures and new products. We love those shows. We’re doing something different. We’re digging into the techniques and technologies we use, solving challenges many of us have. We think it's good to ask "why". Why did we choose a technology to solve this problem we face? Did it go well? Did it go poorly? What did you learn? What was the journey like and what advice would you share with someone following your footsteps?
We’re focusing on concrete experiences. While we will absolutely center around great technologies like Angular, Vue, React, Node.js and more, we’ll invite our guests to talk about specific problems they've encountered and how they addressed those problems with the tools and techniques.
We think that many of you want to hear these stories and can likely recognize yourselves being in similar situations!
The Topics and Flow
Want a sneak peek into how the show till flow? Here’s an example Ward wrote.
Imagine you were on the show to talk about Dependency Injection (that’s native to Angular but you could be talking about DI in react or vue … or why react or vue doesn’t need it in your opinion).
You might begin like this:
“I and many others want to handle Http calls the same way no matter where they are in the component hierarchy. Just the other day I was looking at our app and each component was calling
http directly. Each component handled its own errors (or not) and did so in its own way. Each added headers it's own way. Each handled results its own way.
Every component did it differently. This was a big project, expected to last years. We were building a team for the long haul. People would come and go. Consistency would matter, both in training new people and crushing bugs. Yet, even today, with the code fresh in our minds, no one could predict how a component would get its data. We also found that testing the components was hard because we spent so much time mocking http calls. And our components were full of stuff that didn’t have anything to do with presentation. That made them bigger and harder to understand then they needed to be.
Dependency Injection helped us out of our hole. We pulled all that Http code out into separate service classes that we inject into the component class constructors.
It took us about a week to sweep the code base. And here’s what happened.”
From such a beginning, together we can explore probing questions:
- Didn’t that double the number of classes you had to manage? Did that bother you?
- How did you make sure that the services themselves were consistent … or did that just move the consistency problem somewhere else?
- What if you hadn’t used DI? Could you have achieved the same result some other way? Maybe with redux/ngrx/vuex/mobx/suspense?
- Would you do it again? Slightly differently?
- How did the team respond? How did you convince them to do it? Was there resistance? How did you overcome that (if you did)?
This type of flow focuses on "why" and the experience, while also allowing us to share what technologies can help us all with everyday Web development. This means our topics can be about great platforms and frameworks like Node.js, Angular, React and Vue, but also about tools like VS Code or WebPack, or docker, cloud solutions, AI and ML, mobile, testing, or pretty much anything that touches Web development.
The Web community has amazingly generous and kind people who share. Many of us receive help along the way. We believe paying it forward is the right thing to do. This is why we also share, at the end of our show, “someone to follow”. This can be anyone our guests feel should be shared more widely in a nod to the community that helps us all.
We'll kick things off with a mailbag question from some of you. We'll use social media to gather questions for our guests and read and answer some of them on air.
We love the Web and we know so many other people do too. We hope you enjoy hearing these stories of Web developers, their struggles, their successes, and the tools that they use.
John, Ward, and Dan