Where developer is succinct
- 📅
- 📝 411 words
- 🕙 2 minutes
- 📦 .NET
- 🏷️ refactoring
- 💬 7 responses
Radio 4 covered the The Six Word Memoir competition, inspired by Earnest Hemingway’s wager he could tell a complete story in just six words. He deliciously delivered “For sale: Baby shoes, never worn” earning him $10.
Expressing a life story in six words is just as tricky. Some of my favorite submissions include:
Found true love, married someone else. B. Stromberg
Work smart. Love what you do. Michael Scala
A limit on words means getting straight to the point — Twitter’s 140 character limit results in short useful extracts.
Short succinct messages require more thought, careful editing and of course time. Getting the balance right between losing important information and the laws of diminishing returns takes practice and is very dependent upon the mix and size of your audience.
As a developer I find these skills applicable to the following areas:
Blog posts
I’m not the world’s most prolific blogger but my posts tend to be short and to the point. If you didn’t find it interesting you should have realized quite quickly.
Being well-written and interesting gives a better chance of being added to StumbleUpon, Digg or other blogs.
Presentations
My latest presentation on LINQ consisted of around 20 logically-grouped slides with a few bullet points and tiny code samples.
I saved time by not writing a script and let the talk flow more naturally with interaction from the audience. This meant the audience chose the programming language and I broke into demos once they looked anxious to see it.
Code
My own projects change design dramatically during prototyping thanks to refactoring and the great tools available. It is for this reason I do not practice test-driven development.
I need my code and design to be as succinct as possible at this phase. Unused code, interfaces or stubs are wasted words. Verbosity. Declarations that are read and compiled but not used. Verbosity.
Once the overall design is settled the unit tests and fleshing out of functionality comes.
Where extensibility is needed I work with those who will consume it to ensure the interface does what is required and nothing more. Three consumers is quoted as the magic number.
This is also why I am so keen on extension methods and other simple expressions of intent.
Going forward
If anyone has any tips, informative articles or recommended books on succinct writing please leave them here.
Now if only I could get this post down to six words…
[)amien
7 responses to Where developer is succinct
“tips, informative articles or recommended books on succinct writing”
I have two: Write Right, mentioned at the link, and Reading like a Writer. Both are about writing more generally, but good writing is always succinct writing in the sense that no words are wasted and concepts are conveyed with as much brevity as possible -- and no more.
Yes writing frameworks for general consumption requires second-guessing customers which helps if yow know your domain inside and out.
It wasn’t supposed to be general advice for programming, simply how I apply the principles to my work and projects.
The irony of such ambiguity isn’t lost on me.
I should refactor the article ;-)
“Where extensibility is needed I work with those who will consume it to ensure the interface does what is required and nothing more.”
We’ve talked about before, I think this only works with development that is mostly consumed internally, or you have a very close relationship with your consumers. Any library with a large number of external users is inherently going to need more flexibility built in, because there is a minimum cycle for ‘major’ (ie feature / structure altering) releases. You can’t work individually with all of them to determine the minimum set, and you can’t refactor every other week (for external consumption anyway); you have to predict / extrapolate their requirements to some degree in order to make sure they don’t hit a brick wall that can’t be solved without a refactoring. So I think a reactive approach doesn’t work in all cases.
I guess this comes down to the definition of ‘what is required’ though. Libraries with more diverse users need more stability, which means more up-front design.
Succinct is good in code, provided the meaning is clear. Code should be verbose enough that reading it is easy and unambiguous.
In writing in general though I think the most important thing is to be enjoyable to read. Tech books which concentrate just on delivering the subject matter as succinctly as possible are most often very dry — fine as a reference, but when it comes to an enjoyable read, some padding with anecdotes and asides can make all the difference. My favourite is Scott Meyers — he’s able to tackle incredibly geeky C idiosyncracies and make it feel like entertainment. So I wouldn’t say brevity is king. But then I’m not often brief outside of a source code editor ;)
Yes, it should. Now corrected, thanks :)
The post title should have also been six words in length.
Great post.
Sorry to nitpick but should it be losing important information instead of loosing important information?
Of course the only real measurement of code quality is WTF’s per minute.
Thanks lazycoder via Twitter.