A neat guide for good technical writing goes as follows:<p>1. Tell the 'WHAT' (i.e what you have built/observed/intend to do/etc.)<p>2. Explain the 'SO WHAT' without which the WHAT is almost meaningless (i.e. that it reduces operating costs by X/.../etc.)<p>I often find myself focusing too much on the WHAT, neglecting the SO WHAT. However, the succinct phrasing helps me to also keep the SO WHAT in mind.<p>(I first stumbled upon this way of phrasing things in the neat little book 'Trees, Maps and Theorems' by Doumont)
Brilliant advise ! Well done, I like the almost algorithmic recipe here.<p>Speaking of writing, (sorry for slight high-jack) when writing your "ad copy"(yes I know it's the devils work, especially on HN). But since we sharing writing tips :) Here is my ad-copy tip and litmus test<p>Can I <i>exchange company/ad-subject</i> with one of my competitors and does the copy still make sense ? If yes then the ad/sales-argument is NOT unique enough and usually bad.<p>Super Stupid example:<p>You own an "Estate agency called Joe`s Family Homes and your ad-copy is:<p>"At Joe's We, Sell the best houses and get you in the right home for the lowest price"<p>Meh... Very generic and you can exchange "Joe" for any of your competitors and the ad will still be true and make sense (and be crap).<p>A 'better version' might be:<p>"Joe Smith (From Joe's Homes), who grew-up in your neighbourhood will not only get you in your next home, he probably went to high school with you and knows the in's and out of this town"
In a similar vein, my boss taught me to apply a similar strategy for writing effective emails:<p>1) Here’s what’s happening<p>2) This is what I need from you to address what is happening<p>3) This when I need it by.<p>4) Happy to answer any questions about the above.
> Here’s a story from the early days of Amazon Web Services: Before writing any code, engineers spent 18 months contemplating and writing documents on how best to serve the customer. Amazon believes this is the fastest way to work—thinking deeply about what the customer needs before executing on that rigorously refined vision.<p>Good luck explaining this to the new age Scrum certified gurus who wants to complete all design work in 2 weeks of sprint 0.
> Why - Expected ROI<p>Any guidance for quantifying this if you're an engineer and don't have access to financial numbers?<p>It's hard for me to estimate the value of a feature I'm designing if the Product team just says it's important without giving financial reasons. Presumably the feature will benefit the customer, but it's hard to translate that into e.g. "5% revenue increase"
a friend recently gave me this same advice, and it does seem like a good idea.<p>i’ve been trying to rework my github readme’s to all start with why/what/how, and it's hard! they should be concise, and yet sufficiently explanatory.<p>i’m not sure there is a why/what/how for all audiences. to get it right, you have to pick a subset of your potential readers and write for them. otherwise you trade concision for generality, and then lose some of your true target audience to boredom.
These are great sections to have - along with "Who" to delineate responsibilities between teams for say future maintenance in case several teams are involved.