The Data Science Handbook

Chapter 9Technical Communication and Documentation

I debated whether to include this chapter in the book. In the first place, it ventures into “touchy feely” areas that I generally try to avoid. This is mostly a technical, brass-tacks type of book. The second problem is that I don't feel that I myself am that great at technical communication. I'm certainly good enough to get my own work done (and given that I'm in consulting, that bar is higher for me than for most data scientists), but beyond that I don't claim to have any special expertise.

However, my own lack of natural talent is part of why I felt this chapter is necessary. I've seen that first-rate technical work can be tragically undervalued if people fail to communicate it in an effective way. I've also seen that just a few basic, easy-to-learn principles can make a world of difference between incomprehensibility and a stunning presentation. Internalizing a few guiding principles has made for career advancement for myself, follow-up engagements for my company, and early identification of mismatches between the technical work and business objectives.

Data scientists are in a uniquely communication-intensive niche. Software engineers mostly talk with other software engineers, business analysts with business analysts, and so on. It is the job of a data scientist to bridge the gaps between the worlds of business, analytics, and software. So, it's a crying shame that, frankly, most of us aren't that good at it. Ultimately, ...