Tips from a software engineer for a balanced life

Kent Dodds is a busy, busy guy. He's a full stack JavaScript engineer at PayPal, hosts JavaScript Air, co-hosts React30, is an instructor on Egghead.io, is a Google Developer Expert, and spends a lot of time on Twitter and GitHub.

He's speaking at All Things Open this year on automating the open source contributions and maintenance management process in two sessions: Managing an Open Source Project and How to Open Source Your Stuff.

I had a quick Q&A with him about how he balances his life, some thoughts on his teaching, and a quick preview of his talk.

How do you divide your time between your role at PayPal, the podcasts and instructional screencasts you create, contributing to other open source projects, and a family?

I definitely keep myself busy! If you're curious about my general schedule, someone asked a similar question on my AMA and I gave them an outline of my schedule. How I get so much done comes down to a few key facts:

• I am incredibly privileged to have a wife who's so supportive and helps free up a lot of my time by managing many of the logistics of our household, so I can focus on these things.
• I don't really have many hobbies outside of family, church, and all the things you mentioned.
• I try to automate as much as I can.
• I try to follow the "1 minute rule".
• I take advantage of every spare minute that I get. So when my kids are in bed and my wife is out grocery shopping, you can bet that I clean the kitchen as fast as I can so I can get to these things.
• I work from home, so I don't have any commute time.

Sometimes, if I need to focus on an Egghead.io course, Frontend Masters workshop, or a talk, my wife understands and we'll spend a little less time together in the evenings so I can get it done (or we'll just work side-by-side while Star Trek is going on in the background).

What do other instructors do that make you cringe? And what have you learned from other programmers that helped improve how you teach programming skills?

Hmm... Well, there are a few things that I've noticed in myself and others when teaching that could definitely be improved. From a giving talks perspective, I always recommend people watch and follow the advice in Ben Orenstein's talk, How to Talk to Developers.

Some specific things that I try to avoid:

• Using inappropriate exclusionary terms and phrases like "Guys," "Lame," "Gay," "Obviously," "It's so easy," etc.
• Speaking disrespectfully of others and their work. I'm fine hearing a comparison of tools, but not at the expense of disrespectful language.
• Trying to fit too much content into the available time. If you find you're behind, don't try to rush through the material.
• Teaching things incorrectly because of limited understanding of the material. You've got to know that what you're teaching is not only correct, but a good way to do whatever you're demonstrating.
• Giving a multi-hour "workshop" in lecture format. Workshops need to be hands-on for people to be engaged and learn.

In addition to screencasts and conferences, what do you think are the best ways to learn programming?

I talk about this quite a bit in Zero to 60 in Software Development: How to Jumpstart Your Career. I actually answer a similar question in my AMA for this one too. Basically, I see the learning process looking like this:

1. Consume: newsletters, podcasts, Twitter, etc.
2. Learn however you learn best: books, blog posts, screencasts, etc.
3. Build the things you want to dive deep on.
4. Teach the things you learned while building; this solidifies your understanding.

I also talk about how valuable it is to:

• Give freely.
• Don't be afraid to try new things and be willing to get rejected and fail.
• Be nice.

Can you give us an example of one high-value tool that a project team can deploy to automate their project processes—something that, if they do nothing else, will show value to the project?

The tool that has done more for me than any other with regards to automating open source is definitely semantic-release. I was skeptical at first, but after I started using it, I realized that it's an invaluable tool for increasing my productivity (even on projects that I'm no longer actively maintaining). If you do nothing else, set up this tool on your projects and enjoy the brain-freedom of automating your releases.