For about the last year and a half, my daughter and I have made a podcast. My daughter is currently a toddler. It’s not always easy to produce a podcast with a toddler, but I have found the end product to be priceless.
Disclaimer: Because every child is different, this is going to be less of a how to and more of a “my experience with podcasting with a toddler.”
Toddler’s are not always the easiest to work with. So why would I bring it upon myself to try to make a podcast with one?
Like many of my cohorts in the millennial generation, I’m really into podcasts. Like many podcasts listeners, I’ve thought “I should make a podcast.” Should might be a stretch. But I definitely could record audio and post it on the internet.
A couple buddies and I tried starting a podcast called Average of Averages. Being the tech nerd I am, I loved doing all the technical stuff of a podcast—recording, making a website, generating a feed, etc.—but I had trouble figuring out what could make out show different and engaging. Three white guys talking about nothing? How original. We never did figure out our niche. Finding time for three people to record also wasn’t easy. It fizzled out after two episodes.
I still wanted to make a podcast though.
Around this time, my daughter started putting multiple words together in cute little 18-month old sentences. I’m terrible at writing a journal. I’m also terrified that I’ll forget all the adorable things my daughter says. Then it hit me! Here’s a tiny human being, in my own house, whose schedule I have small amount of control over (more on this later), and I want some way to record her so I can remember how cute and little she was. There’s the podcast. The Lily & Sam Show was born.
After about a year and a half and a couple dozen episodes, I feel like we’re finally at a place where recording and editing is a smooth process. It’s taken a lot of trial and error to get to this point though.
We started recording with a single microphone, the Audio-Technica ATR2100-USB. I chose this microphone because it was recommended both by Jason Snell and Marco Arment (#4 on Marco’s mega review). It’s a great USB mic. My daughter would sit in my lap and I’d move the mic up and down depending on who was talking. I quickly realized this was not going to be a great long term solution. She kept wanting to turn around and look at me and moving the mic between us often missed what she or I would say. Not great.
I later purchased a second mic, the Pyle PDMIC58, a cheap XLR mic also recommended by Marco Arment (#5 on Marco’s mega review). Since this was XLR only, I needed an USB audio interface.
I was able to borrow a Zoom H6 from a coworker. I was considering buying one because it would double as a recorder and an interface. I thought we might have an easier time recording if I could follow her around and record her in a less controlled environment. My microphones weren’t suited for that at all. So we tried the Zoom H6 as an audio interface. Turns out she loved having her own chair and microphone.
So I knew that was the direction we needed to head. My wife bought surprised me with a Behringer UMC404HD audio interface after I had to return the Zoom H6 to my friend. The Behringer was the most affordable decent audio interface that had more than 2 XLR inputs I could find. (I wanted to be able to have at least 3 inputs because my wife occasionally joins us on the podcast.)
I don’t know if you know this about toddlers or not, but they don’t stop moving. The problem with my daughter sitting in her own chair and having her own microphone, is she kept moving and touching the mic! So. Much. Noise. My daughter also liked switching seats with me for a while. That made editing a pain.
I also got a couple heavy mic stands to set on my desk (these ones). This lets us sit on opposite ends of the desk and face each other. In addition to being able to put the mics in the right place for both of us, this reduces the amount of noise bleed there is.
I edit in GarageBand. I don’t love it, but it’s free! I’ve gotten faster at editing over the months, but it’s still a chore.
If you’ve listened to any of our episodes you know they are short, like 2–3 minutes. In order to get 2–3 of content, we now typically record for about 10+ minutes. At the beginning it sometimes took 20+ minutes to get 2 minutes of material. Most editing is cutting out the parts where it’s quiet, she’s running off to play with her LEGOs, or she is being too grumpy. Occasionally I move stuff around to make the conversation more coherent. It used to take me about an hour to cut 17 minutes of recordings down to 2 minutes. Now I can edit an episode in about 20 minutes. With 2 mics you get 2 tracks, which makes it easier to see who’s talking where and what can be cut out. I always listen through once or twice with my eyes closed to make sure it all sounds decently coherent.
I tried so hard at the beginning to remove all of my daughter’s mic bumps and the noise of her moving in her chair. Eventually I kinda gave up on that mission. I began to see it as the charm of recording with a podcast; hearing how lively she is while we record. I personally think it gives the podcast a bit of character.
One of the hardest parts of editing has been adjusting levels. Because my daughter moves around so much, sometimes she’s too quiet and sometimes she’s too loud. So I have to go through and a bunch of volume automation points all over to help it sound a bit better.
Screenshot of audio levels in GarageBand
As she has gotten older and her language skills have improved, the editing process as gotten easier and easier. So the future is bright.
I will write more about the technical aspects of the website in another post, but lilyandsam.show pulls in data from my custom CMS at verygood.fm and generates the RSS feed. It’s built with NuxtJS and is hosted on Netlify. Netlify made it simple to add a form for people to ask questions for the show. Those questions are emailed to me.
We’re now recording the podcast about every other week, sometimes once a month. I love having these recordings. I love when my daughter runs up to me and asks if we can record the podcast. I love seeing her grin when she listens back to it.
Sometimes it’s real tough to make. My daughter gets grumpy and hungry and doesn’t want to record. Or she’ll say she wants to record just get into my office and play. But on average, I’d say it’s worth it.
I’ll keep making it as long as she wants to.
My daughter wanted to help me type this. So the following is typed by her:
/.l l., ÷¬;l¬…÷ln,no.,,;/,jllj
,g.,/on/j
Thanks for reading!
I’ve been working full-time as a software developer for almost 2 years now. I’ve learned a lot. I’ve messed a bunch of stuff up too. The question I’ve been struggling with is how do I know I’m actually becoming a better developer? Over the last couple of years, I feel like I’m becoming a better developer. But is feeling better enough?
I haven’t worked with or known a ton of developers, but I’ve worked with some great ones. Besides the actual code a developer produces, there is lots that makes a developer great. There is lots that make a developer great, but here are a few things that I think make a developer (and people in general) great:
Unfortunately, all these things are hard to measure. I think most people can agree that the easy things to measure (number of lines written, number of tickets closed, etc.) have little bearing on whether a developer is great. So that’s where I get stuck. I want to get better, I know what I think a good developer looks like, but how do I know I am better than I was a week, a month, a year ago?
I like numbers. They are easy to compare. But how do I compare something like being approachable? I could maybe find a number to represent it, like number of questions I get a day. I could ask people to give me a rating on how approachable they think I am, but I’m guessing the people who like me would rate me highly and the people who don’t would rate me poorly, and that it wouldn’t change much over time.
Let’s assume I do find a number or a couple numbers to represent approachability. Over time, I think I would subconsciously, or maybe even consciously, find a way to game that number. I’d want to chase that good feeling that comes from seeing a number improve. My point is, numbers probably won’t work very well. Are all metrics bad? No. Are most? Maybe. It’s hard to find the useful metrics. But they do exist, I think. But I also know from personal experience that it is incredibly easy to focus too much on the number and not on the end result the number is supposed to measure.
I’m now thinking yes, just feeling like you’re a better developer is probably enough.
The hosts of one of my favorite podcasts, Cortex, talk about yearly themes. Instead of making yearly goals or resolutions, they have a theme. Whenever a decision or opportunity comes up, you can just look at your theme determine if the decision is on or off theme. I think a similar tactic can be taken with becoming a better developer. Instead of creating specific goals or measuring (pointless) metrics, just keep what you think makes a developer great in mind, and when situations arise, just ask, “How would a great developer act in this situation?”. Sounds cheesy, I know. But that’s the best I can come up with right now. It’s not just wanting to be a better developer that makes someone better. It is knowing what you want to be like and acting more and more like that until you become that.
If you have any ideas or thoughts, let me know. I’d appreciate it. This is all still forming in my mind. What do you think makes a developer great? How do you know that you’re getting better?
With Safari Technology Preview 68, there is a new media query, prefers-color-scheme. I’ve used it on this site like the following:
@media (prefers-color-scheme: dark) {
background-color: #000000;
}Digging around in the WebKit release notes, it looks like it supports dark and light at the moment. I tested both, and the do appear to work.
Anyways, kind of cool! I’m sure my dark mode looks bad, so I’ll work on it. But I hope other browsers implement this media query soon as well.
Here is a Tailwind CSS plugin to add a dark and light variants. Just add this to the plugins array in your Tailwind config file.
// You need to make sure you have postcss imported in your config file:
// const postcss = require("postcss");
({ addVariant }) => {
addVariant("dark", ({ container, separator }) => {
const mediaRule = postcss.atRule({
name: "media",
params: "(prefers-color-scheme: dark)",
});
mediaRule.nodes = container.nodes;
container.nodes = [mediaRule];
mediaRule.walkRules((rule) => {
rule.selector = `.dark${separator}${rule.selector.slice(1)}`;
});
});
addVariant("light", ({ container, separator }) => {
const mediaRule = postcss.atRule({
name: "media",
params: "(prefers-color-scheme: light)",
});
mediaRule.nodes = container.nodes;
container.nodes = [mediaRule];
mediaRule.walkRules((rule) => {
rule.selector = `.light${separator}${rule.selector.slice(1)}`;
});
});
};More information on adding Tailwind variants can be found here.
At ng-conf, John Papa gave a talk on writing readable code. You can watch the video here. I recommend it.
Writing clean, readable code seems like an obvious and simple thing to do, but this talk made me realize that I have been ignoring it. For whatever reasons (I’m guessing the thrill of increasing my throughput 🤓), I’ve been focusing more on closing tickets than writing good code. Recently, I have really been trying to focus on writing quality, readable code. I’ve come up with two general steps to help me when I’m working on an issue:
I’ve been stopping after step 1. This has produced some code that I definitely don’t want to go back to. Ever. Now, I’ve been trying to slow down and worry less about getting lots of bugs fixed. Instead I’m trying to figure out what it takes for me to not only complete a ticket, but complete it in a way that I’m proud of the code I’m producing. Luckily I work at a company that doesn’t pressure me to get more and more tickets done all the time, so I’m able to actually slow down.
Recently, a couple of my coworkers and I have been pushing for more code reviews on our team. I’ve found this a very effective way to help me write better code. When I know for sure that someone else is going to look at my code, I put more effort into making it readable as I’m working on it. So, code reviews. Do them. Even if it’s just with yourself.
For me, focusing on readable code is like switching keyboards: my “productivity” has dropped, but I’m sure it’ll pick back up as I get used to it.
I have found that it is okay to slow down, and that I need to. I have felt that focusing on writing readable code has been helping me become a better developer. Next step, make git commits more often.
Hit me up on Twitter if you have and comments or good tips on writing readable code.
A template reference (I’ll call it a template ref) is basically a tag you put on an element in your template so that you can easily reference that element later. Can you see why they named it like they did? The syntax is # and then the name. For example, if I want to add a template ref to an email input and call it email, then I would add #email to the input, like the following:
<input type="email" #email />So how is this useful. Well, elements with a template ref can be used in a template just like a public variable on a component can be.
So if I want a button to validate the email entered, I can do something like:
<input type="email" #email />
<button (click)="validateEmail(email.value)">Validate!</button>The value of the email input will be passed into the function. Cool!
In a little project I was working on, I had a widget selector and a button to add that widget to the page. The button called a function on the component and needed the selected value from the selector. I could add a variable to the component and change that every time an option was selected, but nothing else needs to know about that selected option, just the function the button calls.
<select #widget>
<option value="a">Dashboard Title</option>
<option value="b">Tickets</option>
</select>
<select #width>
<option value="span-col-1">1 Column</option>
<option value="span-col-2">2 Columns</option>
</select>
<select #height>
<option value="span-row-1">1 Row</option>
<option value="span-row-2">2 Rows</option>
</select>
<button (click)="addWidget(widget.value, width.value, height.value)">
Add
</button>If I select “Tickets” “1 Column” and “2 Rows”, then click the button, a, span-col-1, and span-col-2 will be passed into addWidget! I like that a lot. It keeps my component cleaner because I don’t need to define a bunch of variables to keep state that I don’t really need.
You might be asking yourself right about now, “Can I only put template refs on regular ol’ HTML elements?” Even if you aren’t asking, the answer is no! You can put template refs on components too and access their properties! For example, if we have a hello component that has a property that tells us how many times a hello world has been done, you can access it in your template with a template ref.
<hello #hello></hello>
<p></p>So there’s probably some cool things you can do with that. I haven’t messed with it much.
The other powerful way you can use template refs, is grabbing template elements inside of your component. Using ViewChild you can grab an ElementRef using your template ref. This lets you do some cool things.
import { Component, ViewChild, ElementRef } from "@angular/core";
@Component({
selector: "my-app",
template:
'<input type="email" #email><button (click)="clickButton()">Click</button>'
})
export class AppComponent {
@ViewChild("email") emailInput: ElementRef;
clickButton() {
console.log(this.emailInput.nativeElement.value);
}
}I’ll write about this more when I write about ng-template and ng-container. Stay tuned!
Template refs need to be unique. You can’t have two inputs with the ref #email in the same template.
ref-input is a alternate way of doing #input.
<input type="email" #email />and
<input type="email" ref-email />are equivalent.
I’ve tried doing something like
<input type="text" #input />
<p></p>In hopes of it printing out the value of the input as you type. It doesn’t seem to work. You can add change to the input and that will show the value, not as you type, but on blur.
<input type="text" (change)="true" #input />
<p></p>Won’t lie, don’t really understand what’s going on here. But adding (change)="true" triggers change detection.
This is the conclusion of this article. Hit me up on Twitter if you have any questions or comments.
Last week, I was able to attend ng-conf in Salt Lake City, UT. ng-conf is a conference dedicated to Angular, and this was their fifth year. I’ve had never been to a conference before, and the prospect of going to such a large one (around 1400 people!) was a little unnerving. But I was excited to learn stuff about things! I’m not big on “networking” or “talking to people”, so I was fortunate to be able to go with a group of about a dozen coworkers. Most of us are Angular noobs. At work, we are on AngularJS 1.6, but we are getting on the current version of Angular soon (“soon” being only a couple months away, for the last year and a half). I have limited experience with Angular. Every time I try learning about it, I feel like I get bogged down by TypeScript. For whatever reason, TypeScript just wrinkles my brain whenever I see it. But, after this conference, I think I have a much stronger grasp on Angular and TypeScript. Well, maybe slightly stronger. Still good!
There were a lot of great talks and workshops about a myriad of topics. But at times, being a noob, it felt like getting firehosed—I left with a long list of things to look up and learn about later. So for the next few weeks, I’m going to take some of those topics on my list, and research, practice, and write about them here.
A few topics I’ve got in mind to write about so far are:
ng-container and ng-templateAt the very least, this will help solidify some of the things I learned at ng-conf. If it helps someone else, even better!
As my daughter says, I'm just a tired dad, with a tired name, Sam Warnick. I'm a software developer in Beaufort, SC.