The Return of 'Write Less, Do More' by Rich Harris

which was very much a part of internet culture at the time and used to make things like this but something terrible had happened flash had been murdered by the tyrant steve jobs rest in peace and so to cut a long story short i started researching alternatives and that's how i found myself writing a language called javascript into a text box and a content management system that only really worked in internet explorer i don't think we even had monospace fonts much less syntax highlighting or linting or anything like that

and the results were entirely predictable i broke things badly and often what the dev team should have done was sanitize my markup stripped out my script tags but instead and i'll forever be grateful to this for this my friend pete lewis came to me and said rich i'm probably going to regret telling you this but there's this thing that we use to write better javascript it's called jquery and in that moment my life changed i went to jquery.com and my mind exploded into a thousand pieces all of a sudden all of the things the pie in the

sky ideas that we'd wanted to do were not just possible they were within reach i fell in love with jquery and the reason that i fell in love with it were these four words write less do more my name's rich harris i'm a graphics editor at the new york times and this talk is called the return of write less do more part one write less so there aren't many rules when it comes to writing prose but this is one of the ones that pretty much everyone agrees on

wherever possible you should strive to omit all the various repetitive redundant or needless parts of a piece of writing and only keep words that convey useful information or in other words emit needless words this is one of the rules from a very famous book called the elements of style otherwise known as shrunk and white after its authors and it continues thusly vigorous writing is concise a sentence should contain no unnecessary words a paragraph no unnecessary sentences for the same reason the drawing should not have no unnecessary lines and a machine no unnecessary parts

this requires not that the right to make all his sentences short or they'd avoid all detail and treat his subjects only in la outline but that every word tell and this isn't just about respecting your reader's time it's about writing things that are more correct flabby prose creates space for the more words that you have the more you're able to paper over all of the logical cracks that would otherwise leap out at you and having produced some short concise writing it's much easier for your reader to understand you now i've been working for most of my career

the intersection between journalism and software development and i have come to believe that writing software has more in common with writing prose than it does with engineering engineering is important that's where we tell what the computer to do but less important than the what is the why and that's what code is about as martin fowler says any fool can write code that a computer can understand good programmers write code that humans can understand i would even go so far as to say that if you want to become a better programmer a good way to do it is to practice writing prose it'll exercise a lot of

the same parts of your brain but it'll get you into the habit of evaluating the result from the perspective of a hypothetical reader nowhere are the parallels between code and prose more salient than when we're talking about size if you assume a linear relationship between the size of a code base and the number of bugs in it then that alone is a good reason to try and minimize the amount of code that you write but it turns out that the relationship is not linear it's quadratic according to steve mcconnell who compiled some data from real world

studies a 10 000 line code base will have more than 10 times the number of bugs of a 1 000 line code base it's really important to try and stay below that inflection point two studies cited in the mythical man month determined that the effort of maintaining a code base increases quadratically with a number of instructions now one way i think to interpret that