A few nights ago, in the wee hours of the morning, I came to be staring red-eyed at a list of programming languages. I'm a generally optimistic person, I enjoy learning these sorts of things, and I appreciate the things that the tools on this list had to offer. Despite all that, I couldn't contemplate investing in any of them with anything but dread.

This had nothing to do with the merits of the tools on that list. I was in the waning moments of an irrationally anxious episode, questioning my ability as a programmer, the sustainability of this industry, my choice of career. I certainly wasn't sleeping, which is what I ought to have been doing. I haven't been a programmer for as long as some folks, but even a relative whippersnapper like me can feel buried by the avalanche of new tech, stymied by the exacting nature of working with these infernal silicon devices and the software we write for them.

The incident that precipitated this moment of angst was a SQL view that I encountered at work. Some changes had been made to this view and I was tasked with validating that they were correct. Now, I consider a ten line SQL view to be a substantial piece of code, and a hundred line view is approaching the limit of I'm comfortable with. The view in question was an order of magnitude bigger than that. It was also part of a system which has probably saved lives. This needed to be done, and we needed to be confident that it was done right.

Eventually, what let me close that list and get some rest was the realization that this is the job. As a programmer, sometimes you need to be smart and creative and put together a clean solution with no wasted parts using exactly the right tools. But other times, when folks are depending on you to fix something important, your job is to open the thousand line SQL view, take a deep breath, and figure out how you can do the task in front of you with the tools you have.

Remember that. Expect it. And be proud when you do it well.

There is a great diversity of material for improving programming skills and knowledge. It's no great task to give examples of books, blogs, videos, live-streams, interactive tutorials etc. This diversity makes our profession better.

A surprising inclusion in this list is the podcast, which one might expect to be a bit useless: we work with a lot of plain text, complex data structures, design and layout. At first blush, this seems like poor material for a purely aural medium.

Nevertheless, I derive great enjoyment and value from listening to other programmers talk about their craft and I recently had an object lesson in why.

Giant Robots Made My Day

While working my way through the back-catalogue of the Giant Robots Smashing into Other Giant Robots podcast, I listened to a conversation between Ben Orenstein and Matt Knox about deliberate practice for programmers. A few days later, I have a Github repo for my kata and whole bunch of energy for them that I didn't have last week.

That's not a bad return when all I started with was a half-hour of dishes and a free MP3. Where did I find this enthusiasm, and why is the podcast the perfect medium to go looking for it?

They Don't Cure Cancer But . . .

An obvious benefit of listening to other professionals is that it keeps good ideas front-of-mind. Kata for programmers is hardly a new idea (heck, Jeff Atwood wrote about them on CodingHorror, so pretty much everyone has heard of them) but it's easy to lose focus and drive in that amorphous category of “professional development” without the occasional injection of perspective. Regularly exposing oneself to the ecosystem of good ideas is a good way to stay on track.

Podcasts also have more emotional weight than blogs or Hacker News. Much as one might like to be a perfectly rational logic machine, a little tug on the right heart-strings can be wonderfully effective. There's a palpable excitement, an infectious enthusiasm that emanates from professionals keen on their craft, and it comes through headphones loud and clear.

And in case this all seems like perfect fellowship and sunshine, there's a slightly pointed aspect to consider as well: competition. Besides being sources of inspiration and content, the characters coming down over WiFi can be the masters we seek to surpass or the antagonists against whom we prepare our opinions. As much as we need idols and peers, rivals and tyrants also have their uses.

I'll Be Listening

So for code snippets and clever hacks, blogs are still king. Videos and prose will win out in the domain of architecture and lofty ideas. But as long as I aspire to a better technical culture than I inhabit, I'll listen to podcasts to make up the difference.

Finding good programming podcasts can be a bit challenging. There are a ton of options to choose from and Sturgeon's Law definitely applies. Try lots of things, be selective, and use an RSS reader or podcatcher to automate your subscriptions. Here are a few solid offerings to get you started.

• Giant Robots Smashing into Other Giant Robots. I wasn't really excitied about the business possibilities of being a developer until I heard some of these stories. Particularly good episodes include the aforementioned interview with Matt Knox and an older interview with Brennan Dunn about the business side of being a small independent developer.

• The StackExchange Podcast. Worth listening to if only for Joel Spolsky. Lots of good content about scaling up a massive website, online reputation systems, and huskies. The episode about keeping a datacenter running through hurricane Katrina was particularly memorable.

• The Cognicast. This one used to be ThinkRelevance (the consulting firm that produces it merged with another one—names and URIs were changed). Often features Clojure and other functional programming topics. This interview on testing is a good one.