CodeBork | Tales from the Codeface

The coding blog of Alastair Smith, a software developer based in Cambridge, UK. Interested in DevOps, Azure, Kubernetes, .NET Core, and VueJS.


Project maintained by Hosted on GitHub Pages — Theme by mattgraham

I learned my second lesson from this blog today. What was the first, you might ask? The importance of peer code reviews, and I learnt this pretty much as soon as I’d started.

The second lesson was to improve my writing style! After a comment or two on my last post (in conversation rather than via the blog itself), it appears that I didn’t explain the situation particularly clearly. I will try not not be so arrogant as to assume that my readers know what I’m talking about all the time! This is actually an interesting discussion topic. I’ve found at work, and in team projects at University, that technical communication is easily hampered by not clearing the path and providing sufficient context to the discussion. Particularly with intra-team communications, it’s very easy to assume that everyone is familiar with the topic about which you are conversing. In The Pragmatic Programmer: From Journeyman to Master, Andy Hunt and David Thomas define the following “acrostic” as a useful framework for pitching your conversations:

                    What do you want them to learn?
               What Is their interest in what you have to say?
                How Sophisticated are they?
           How much Detail do they want?
Whom do you want to Own the information?
        How can you Motivate them to listen to you?

There are — count them — only six questions here to ask yourself, and they take only a couple of moments to run through mentally whilst preparing for some form of communication. With a bit of practice, it can even be done in conversation (and should certainly be done before starting a conversation). The steps, like much of the advice Hunt and Thomas impart, are simple, logical and sensible: identify your objective, identify your audience and their level of knowledge, and identify the key stakeholders.

I’ll post a full review of The Pragmatic Programmer when I’ve finished reading it, hopefully in the next couple of weeks or so, but I can say now that this is one book that every fresh graduate programmer should read. I’ll also form a recommended reading list, but for now it looks suspiciously like Jeff Atwood’s.