Title: WRITEME

Author: Bob Schmidt

Date: 09 July 2019 01:15:56 +01:00 or Tue, 09 July 2019 01:15:56 +01:00

Summary: 

Body: 

As I sit down to write an editorial for CVu as guest editor – helping out while Steve Love is moving house – I find myself thinking about communication. I don’t mean electronic communication between computers but written and spoken communication between us, the programmers: it’s how we share our thoughts and ideas, it’s how we collaborate, it’s how we learn our trade – and it’s how we improve our practice of that trade by picking up tricks and wrinkles from other practitioners who are more experienced than we.

We communicate in lots of different ways: we write books and articles in journals such as this; we write documentation for the projects we work on; we write web pages, wikis, and blogs, that are available through an intranet or through the internet; we use social media, we speak at conferences, and make podcasts and videos; and we have earnest technical conversations around the coffee-machine or the office water cooler – or sometimes in the pub over a few drinks.

Not everyone does all of these things, of course, and some do more than others, but most of us do some of them at some stage in our careers, even if it’s only internal project documentation for our employers, or a README file or a github page for an Open Source project. It’s a part of what we do, and it is as important that we do it well as it is that we write good code and good unit tests.

Spoken communication – face-to-face – is the most immediately effective, because it allows for instant feedback. A kind of mental handshaking goes on, that lets the speaker know that the listener has understood, and gives a chance for repetition or rephrasing when the listener seems lost. Unfortunately it’s also the least effective in the long term because – unless the listener was taking notes – much of the detail will soon be forgotten.

Written communication is more permanent, but the writer – lacking the benefit of instant feedback that one gets in a spoken conversation – has to work harder to try to ensure that the reader will understand the message: that the writing is clear and unambiguous. Once something is written, though, it can be read and reread by many people and the investment in effort may be repaid many times over.

Of course, if you write nothing you won’t succeed in imparting any knowledge to posterity – and if nobody reads your book or your article, nobody reads your blog or watches your video, nobody visits your website or listens to your podcast, then – again – you have communicated nothing.

At one place I worked there was an internal blogging platform on which developers could share tips and write about useful tools and libraries we’d written. The platform was provided but nobody insisted that it be used, there was no code on our timesheets for time spent keeping up to date with work being done, or for writing up one’s own work. This meant that hardly anyone read it, and even fewer contributed. It was a great tool, but all it amounted to was a missed opportunity.

Looking around our industry, though, I don’t think this is unusual. Our managers want us to keep abreast of technologies and to know what our coworkers are working on but they don’t encourage us to share the information and don’t provide time for us to do it. As professionals, though, I think it’s our duty to do it anyway – it helps keep all our skills honed, and makes us more employable – and it’d be boring not to!

DANIEL JAMES
GUEST EDITOR

Notes: 

More fields may be available via dynamicdata ..