You can’t really code until you can explain it

My development career has brought many interactions with authors and thought leaders. A few years ago as founder of the Agile Online Summit, I met Andrew Stellman .

He is an accomplished programmer and author. He has written numerous books for O’Reilly . I asked him how writing helped his software development skills.

Connect the Dots

Writing books on C# definitely helped me become a better developer, and writing books on Agile did the same for helping with projects. A lot of people say that you don’t really understand something until you have to explain it, and I think there’s a lot of truth in that. I think writing about topics really helps me connect a lot of dots.

I agree with Andrew. As I do development each day the writing helps me process the lessons. At the moment, we may want to get our work done. When we create content we need to make it coherent. Reflect and connect.

Engage the Reader

Andrew had some additional advice to engage the reader. It helps to have empathy for your reader. Or as AJ Harper says in her book Write a Must-Read . We need to identify our ideal reader. When we do that we can capture their attention.

I think really trying to write in a way that’s easy to understand and engaging helps me a lot. The two books I always recommend to people who want to write technical books are non-technical. The first is the one I already mentioned, “On Writing: A Memoir of the Craft” by Stephen King. The other is “Save the Cat” by Blake Snyder. It’s a book on screenwriting, but there are a lot of lessons that we can actually learn about keeping people engaged and giving them a story.

Even hardcore developers know the importance of a story. Pick your favorite movie and it's the story that draws us in. In Dan and Chip Heath's book Made to Stick , they remind us that stories are remembered. Where facts are forgotten.

Marathon not a Sprint

I grew up watching Chia pet commercials. Everything happened quickly. Andrew outlined some similarities between starting a team with good habits.

Sometimes I have to remind myself that writing is a marathon, not a sprint. There are actually a lot of parallels to getting an agile team up and running. A lot of teams will start doing great practices like daily standups or retrospectives or refactoring, but after a little while those new practices trail off. But if you can get the team to develop real, lasting habits, that’s how you get things to stick.

Our daily practices determine the team's health. If we don’t have a stand-up and align we get off track. Andrew has a beautiful combination of technical chops and an understanding of group development.

Technical practices of refactoring code help teams deliver quality code. Too many people don’t see that connection. Andrew knows it because he has lived it.

Good Narrative

Greg Jensen and I presented together at Iowa Code Camp a few years ago. His advice to developers is to craft a career narrative. I took this presentation and created Tech Survival 101 . Andrew shares similar advice with us as we code a solution.

Coming up with a really good narrative that explains why — not just how — technology or tools or techniques really forces me to understand whatever I’m writing about on an even deeper level.

One thing I have been trying to create a good narrative is technical debt. As developers, we see the rotting code. Although we don’t communicate the severity well to the business.

So what narrative are you going to try to change? Try out a few options and see what resonates. That is the way to truly understand. Find your people and engage with them.

Let’s review all of the great advice from Andrew Stellman. He shared how developers should write to connect the dots. We can see the big picture and understand the moving parts.

We need to engage the reader. Consider who you are talking to. Are you talking to your manager? Another developer? Or some stakeholders. Focus on good practices for the long term.

Lastly, Andrew wants us to craft a good narrative. This can be more persuasive than just relating facts. Take us on a journey and draw us in. Then we can support you and your work.

Like this and follow me on LinkedIn!