11 podcasts that will make you a better software engineer

These podcasts are sure to make you a better software engineer. They are in no particular order but I’ve found each one useful in their own way. I usually listen to these as I’m driving to and from work. It’s a great time to grow when you aren’t really doing anything else productive or mentally intensive at the same time.

Hansel Minutes

Site: http://hanselminutes.com/

Feed: http://feeds.feedburner.com/HanselminutesCompleteMP3

One of my favorite things about Hansel Minutes is the host is a great interviewer. He has this interesting technique where he approaches the topics from ignorance and as a result seems to ask all the right questions. Of course you can tell he has put in a lot of research before hand, he just seems to know what you would want to ask if you were giving the interview.

Another nice thing about the podcast is the guests are varied and come from a lot of different backgrounds. For example, he will often interview designers and game developers, but there’s also a lot of guests like Uncle Bob or Joel Spolsky.

There are over 500 episodes to catch up on if you aren’t already listening to it.

SE Radio

Site: http://www.se-radio.net/

Feed: http://feeds.feedburner.com/se-radio

SE Radio talks about a lot of software engineering topics I don’t see discussed anywhere else. For example, there’s an episode on Developer Anarchy, a topic I never heard of until I listened to the podcast. Each episode goes into a lot of depth with the topic at hand and the topic is usually very specific.

I do have a few complaints about the podcast, though. A lot of the guests tend to be very dry and that can make the podcast difficult to pay attention to. I find myself listening to a few of them because I feel like I should instead of because I enjoy the speakers.

Another issue is that the interviewers seem to be very hands off. They’ll ask a question and let the guest talk for minutes before the next interaction. I feel like I can be really confused by something that the host really should have asked for clarification about but never does.

The Agile Revolution

Site: https://theagilerevolution.com/

Feed: http://feeds.feedburner.com/theagilerevolution/fxnY

This is an interesting podcast that often has really good guests but I don’t see on a lot of other peoples’ podcast lists. They’ve had a lot of agile thought leaders on their podcast like Mary and Tom Poppendieck.

The problem is the audio quality is not very good and they’re often taking place inside a noisy cafe or a conference hallway. That said, the content is usually very good.

The Cognicast

Site: http://thinkrelevance.com/blog/tags/podcast

Feed: http://feeds.feedburner.com/thinkrelevance/podcast

This is a podcast that mainly talks to Clojure developers about Clojure topics. Even though I’m not actively developing in that language, I find it very interesting to listen to on occassion. They have a lot of very intelligent guests on the show that are doing all sorts of interesting things you may not have ever heard about if you aren’t working in a functional programming language. Another thing I like is that they often have the creator of Clojure, Rich Hickey, as a guest.

One complaint is that the titles of the podcast only say the guest name, they do not mention the topic of the discussion.

Programming Throwdown

Site: http://www.programmingthrowdown.com/

Feed: http://feeds.feedburner.com/programmingthrowdown

This is a podcast where each episode, the hosts discuss some details about a different programming language. This podcast is extremely casual. Sometimes the first 50-75% of each episode chit chat and then the last part is left over for the programming language itself. They don’t usually take a deep dive in the language but talk about enough to get you interested in learning more on your own.

I have a weird complaint about this podcast: The two hosts sound kind of similar and it can be difficult to tell who is talking. Also, I’m more interested in learning about the language so I almost always skip the first 50-75% to find the content I’m looking for. I find the idle chit chat to be a waste of my time because I’m not interested, but that’s my personal preference.

The Changelog

Site: https://changelog.com/

Feed: http://feeds.5by5.tv/changelog

This podcast discusses an open source project, framework, library or language each episode. They go into a lot of depth on each topic and at the end they ask a series of questions to the author about how they want the community to help the project succeed and who their programming hero is. I like to listen to this podcast because it helps me be aware of other software out there that I can leverage when I’m working on my work projects. For example, I may not have heard of Zero DB, Kong, or Redux without listening to this podcast because they are in different worlds from what I’m doing on a day to day basis.

Giant Robots Smashing into Other Giant Robots

Site: http://giantrobots.fm/

Feed: http://simplecast.fm/podcasts/271/rss

This is a good podcast with some usability experience issues: The problem is the podcast titles are a weird phrase used at some point in the podcast. As a result, you have to dig into the description to figure out who the guest is and if you’re interested in the topic. Call me lazy, but this is usually enough to put me off.

That said, the host and the guests are often good. The interview style is very casual and the guests usually feel like they’re very comfortable and talking to a friend. They have had famous guests like Uncle Bob Martin and Chad Fowler.

Ruby Rogues

Site: http://devchat.tv/

Feed: https://devchat.tv/ruby-rogues/feed

This is a podcast where a bunch of returning hosts talk to one or two guests about a topic. The title of the podcast is Ruby Rogues, but the topic isn’t always (or usually) specific to the ruby programming language. For example, they’ll talk about “Programmer Education and Skill Development”. They often have famous guests like Martin Fowler, etc. The big group of people discussing brings a lot of different viewpoints into the conversation.

I really like the content of this podcast but the problem is there’s often too many cooks in the kitchen. One of the hosts tends to go off on a rant for a few minutes that has little to do with the topic at hand or someone will interrupt the guest while they’re talking about a topic that I’m more interested in. These are not frequent complaints but they occur often enough to be noticeable.

.NET Rocks

Site: https://www.dotnetrocks.com/

Feed: http://feeds.feedburner.com/netRocksFullMp3Downloads

This podcast has over 1000 podcasts that are often of interest to me. For example, they have a podcast on “Continuous Delivery” and another on “Learning Haskell”. Although the two hosts are .NET developers, as you can see, the podcasts are general enough for any developer to learn from. If there is something too specific for my tastes, the titles are named well enough that I can identify that without having to listen to it first. Also, the hosts are very charismatic so the podcasts are rarely boring.

Full Stack Radio

Site: http://www.fullstackradio.com/

Feed: https://simplecast.com/podcasts/279/rss

This is a great podcast where the host and guest talk about a single topic in detail. Example topics are, “Unit Testability and the Universal Architecture” and, “Fixing Common API Design Mistakes”. The host comes off as being egoless and is not afraid to ask for clarification if he’s confused.There have been a lot of really good and famous guests on this podcast like Kent Beck and Michael Feathers. My only complaint is I wish the podcasts would come out more frequently.

The InfoQ Podcast

Site: https://www.infoq.com/

Feed: http://feeds.soundcloud.com/users/soundcloud:users:215740450/sounds.rss

This is a brand new but promising podcast. Some of the episodes are titled, “Adrian Cockcroft on Microservices, Terraservices and Serverless Computing” and “Lisa Crispin and Justin Searls on Testing and Innovation in Front End Technology”. As you can see, the host has interviewed some thought leaders in our field. I don’t have any complaints for this one as it’s so new. I look forward to listening to more episodes.

10 great ways to impress a software engineer on their first day

If you hire a new software engineer you should do whatever you can to make a good impression on their first day. This will have all sorts of benefits you may not have ever have considered. It will lead to increased retention rates so you will spend less money looking for a replacement in the future.

That person is likely to tell his peers which will market your company as a great place to work and let you spend less time on searching for candidates in the future. It will raise morale and make them excited to work hard for you. The benefits go on and on.

Before I start, I want to let you know this is mostly intended for employees. But, as a consultant, I would be even more impressed than them if these things occurred to me. Also, if your company doesn’t have a technical team, many of the things on this list may not apply to you.

Here’s what you can do:

Have their computer ready to go before they get there

When you show up to your desk and your computer is already set up, it gives the impression that the company is organized and caring. When your computer is missing, you feel forgotten. You’re an after thought. “Oh yeah, I forgot that guy is starting today.” It’s an awkward experience to ask a stranger what to do next. Your company seems unprepared.

Go the extra mile and plug in their speakers, mouse, keyboard, etc. for them. Yes, everyone is busy and it takes a little time to do this, but going the extra mile will make them feel at home.

Provide useful documentation

There should be some useful documentation about the software you expect the new hire to work on. This should give them at least a high level overview of why the product exists and its architecture. This documentation benefits everyone because the new developer will be up to speed faster, an old developer will take responsibility for documenting the software s/he works on daily, and you can increase the bus factor.

On the other hand, do not provide a 400 page document to read. This just screams “bureaucracy”. Besides, it would be expensive to keep it up to date and pointless because nobody’s going to read it anyway.

The software they will develop should already be installed and working on their computer

To be honest, I have never started a job and had this happen to me but it would be amazing. I would definitely brag about it to my peers. Normally I spend at least half the day following 30+ step directions to set up what I’ll be working on.

That’s assuming there is documentation on how to install it in the first place. If there isn’t, nothing makes you feel stupid faster than having to pester a stranger about what to do next every 5 minutes.

This is a waste of time for your new employee and a waste of money for you. When you think about it, every one of your programmers has already done this at least once. Automate the process and let your new employee work on what you hired them for.

Alternatively, setting up the project should be as simple as this:

  1. get the source
  2. build the source
  3. deploy the result

If the installation process isn’t dead simple, then at least do this next rule:

Make an old employee responsible for bringing the new employee up to speed

A manager should tell an old employee that they are responsible for on-boarding the new employee. It should come directly from the manager and be prioritized appropriately. Better yet, tell them both at the same time so the new employee can be aware if the old employee is working on something higher priority.

Don’t tell the new employee that the old employee is responsible and expect them to pass the message along. Doing this puts the new employee in an uncomfortable position. S/He has to bug a stranger with seniority and let them know that they need to do them a favor because the boss said so. The new employee feels like s/he will look bad if s/he isn’t on-boarded soon. But at the same time, s/he doesn’t want to make an enemy by pestering the old employee. You can avoid that whole awkward situation by making it clear and explicit to both of them.

Give them a clear idea of what they’ll be working on

I don’t think I’m alone in this: I absorb information better when I know why it’s relevant to me. Tell me what feature I’ll be working on before you give me a deep dive into all of your products. Otherwise, I will become overwhelmed with information and be unable to discern the “important” from the “nice to know”s.

Don’t just give them a staging/QA environment of a product to fool around with without any further direction. That’s not a very efficient use of their time. It’s like handing someone a complex board game without any instructions and then walking away. They’ll get bored quickly, they won’t know what they’re doing, they won’t get a sense of how to really use it, and it’s not fun. Give them a concrete goal to think about and it will orient their entire thought process towards a worthwhile direction. Better yet, have someone pair with them.

Have them fix something on their first day

When your developer goes home at the end of his first day, someone will invariably ask them how it went. Don’t let them say that s/he just sat through orientation meetings all day. Let them be proud that they actually accomplished something. This doesn’t have to be much. It could just be fixing a typo in a label somewhere. But, if your company can get to the point where someone can do something on their first day, that really says something about it. You need a certain level of efficiency for this to be possible.

Having the developer poking around in the code will get his wheels turning. S/He may have a better idea of what he’ll work on when s/he comes in the next day.

Tell them about your culture before the first day

What’s the dress code? Are you flexible with start times? When they walk through the door, who should they talk to? Where can they find that person?

A lot of programmers won’t think to ask of these questions in advance. There are many more important things to think about during the interview process like the programming language they’ll be using or the processes they’ll be using.

Ask if you can pay for an important tool / IDE for them

If a developer wants a $500 tool to make themselves more productive, pay for it. It’s a drop in the bucket compared to how much time they’ll waste learning a new tool they’re unfamiliar with. To put it in perspective, if you add up the hourly rate of the people involved in the interview and hiring process, it probably cost you the same amount as this tool.

Your new hire doesn’t want to seem ungrateful or whiny for asking for you to pay for something on their first day. At the same time they don’t want to seem unproductive if they’re missing the right tools for the job. From their perspective, it’s a catch-22. Taking the initiative to ask the software engineer first will avoid an awkward conversation for her/him later.

Personally introduce them to their coworkers

Take the new hire and walk them over to every single person’s desk to introduce them to their new colleagues.

A lot of people are shy and don’t know how to break the ice on their own. This may be useful to them in the future. For example, if their mouse runs out of batteries, they won’t have to interrupt a programmer to ask who to ask, they can go directly to the office manager who they’ve already met.

Invite them to lunch

Even if you normally brown bag it, you should make an exception and invite the new hire to lunch on their first day. They probably haven’t made any friends yet and may be too shy to ask strangers to lunch. This will let them get to know you and their peers better and make them feel at home.

You might want to consider inviting people from different departments. This shows that your company isn’t cliquey and there’s inter-office communication.

If you don’t do this, the worst case scenario is they have to eat alone and their takeaway is that nobody at the company is friendly. This is bad for their morale, and it could end up giving your company a poor reputation.

I’ve never seen or heard of this, but it’s an interesting idea: Invite as many people as you can to lunch in advance and pay for everyone. Make it something of a party. If you make this an expected thing, watch how quickly your employees warm up to your new hire. They’ll associate them with a free lunch.


What’s implied here is that you should treat a new hire as a guest in your home, not a roommate you already live with. Be a good host. You want them to feel welcomed. If you give them a great first impression, they are going to brag about it to their friends and peers and they will want to work for you for a very long time.

Coder vs Programmer vs Software Engineer vs Architect vs…

This is a blog post for people who are not technical but have to work with technical people and want to have a better understanding of their job titles.

Coder vs Developer vs Programmer vs Software Engineer

9 times out of 10, you can consider these job titles to be synonymous.  The main specialty of all three is that they will write code to build custom software.  If you meet one person that refers to themselves as a Coder and another that refers to themselves as a Programmer, you can think of them as doing the same thing.

But, Continue reading