How to be a Good Duck

When you’re creating software, it’s easy to second guess yourself.

Sometimes you need a good duck.

In the book The Pragmatic Programmer, Andrew Hunt and David Thomas wrote that software developers would carry around a rubber duck in their pocket.

When needed they would take it out and explain their code to it.

Developers found that by explaining the problem out loud they would come to a solution faster.

As a manager of software projects I like to tell my teammates to reach out to me if they ever need a good duck.

Because of this, I have some tips I’ve learned on how to be a good duck.

Tip 1 : Don't problem solve

The purpose of being a good duck isn't to solve the problem.

It's to be an aid to help your teammate solve their problem.

This is challenging because as developers we solve problems.

It's easy to want to give a solution to any problem we face, but this isn't being a good duck.

Tip 2 : Listen, actively.

Listen, with the only goal to help someone think better, is the purpose of your presence.

I've had conversations where I only listen.

I don't say a word, and the person figures out their own problems by having me there.

Tip 3 : Seek clarity of your own understanding of the problem.

Become your five-year old self.

Why?

Five-year olds are the most curious creatures walking this planet.

They will quickly lead you down an existential crisis with their incessant ability to ask “why?”.  This is because they ask questions without assumptions.

So should you.

Through seeking your own clarity, you're helping your teammate find their own.  

They may have made assumptions that are incorrect or they may have realized gaps in their own understanding of the problem.

Software development is a team sport.

Through active listening and understanding you can help your teammate figure out the solution to their problem.

If these tips are too hard then maybe the best thing you can do for them is to just quack.

If you found this post helpful to your software journey, please subscribe to my newsletter where I talk about my experiences building software for myself, others, and helping aspiring product managers do the same.