Hacker News new | past | comments | ask | show | jobs | submit login
Ask HN: What are good writing tips for software developers?
51 points by soneca on Mar 5, 2018 | hide | past | web | favorite | 65 comments
I am thinking about all the occasions a developer writes words related to writing code. Pull requests descriptions, email communication with colleagues (devs and non-devs), commit messages, specifications, documentation.

Eventually a technical article or blog post too. But I am mostly concerned about day-to-day needs of writing that every developer has.




A preposition is a very bad word to end a sentence with.

But only a fool would begin or end a sentence with the word but.

And only a total idiot would begin or end a sentence with the word and.

Anyway, you should never use the word 'anyway'. Even worser to use 'anyways'.

And never utilize the word 'utilize' when you could utilize the word 'use' instead.

Your doing it wrong if you're sentences confuse the words your and you're.

There are two many people doing it wrong too get to upset about confusion over to, too and two.


He he, good ones.

Here's a small Python tool I wrote to help with stuff like this - it can easily be customized to add more suggestions of your own, from this thread or elsewhere:

Cut the crap! An absolutely essential tool for writers:

https://jugad2.blogspot.in/2015/07/cut-crap-absolutely-essen...


>A preposition is a very bad word to end a sentence with.

"Ending a sentence with a preposition is something up with which I will not put."


Yes. Definitely agree about use of "utilize." It is a total tell in any piece of writing that is trying to sound "fancy" for nothing. The person who wrote the text loses one star of my respect rating immediately at the first occurrence of "utilize." It's even worse when spoken!


"At this point in time" is another one, can be replaced with just "right now" or even "now". Had to tell a team member of mine that once.


There there, never mix up their and there.

Don't write lead when you mean led. (I see this a lot in exec and other bios on company sites.)


Don't write loose when you mean lose.


Agreed. Also complete sentences.


and capitalization


Capitalisation is very important, if for no other reason then it means the difference between helping your Uncle Jack off a horse...


A comma could also be an invaluable tool in that situation. Properly used. And Walmart has them on sale in one dozen packs.


Proper: punctuation helps too


Oh? really!


+1


I recommend getting three books and to begin writing at least 500 words per day distraction free (technical, fiction, stream of conscious):

1) On Writing Well - William Zinser https://www.amazon.com/Writing-Well-30th-Anniversary-Nonfict...

2) On Writing - Stephen King- https://www.amazon.com/Writing-10th-Anniversary-Memoir-Craft...

3) The Elements of Style - Strunk & White - https://www.amazon.com/Elements-Style-Fourth-William-Strunk/...

The two most important points are concise style and active voice. Both of these habits are critical for SEs to write concise emails, specs and commit messages. You will even see improvement in more casual day to day interactions (via slack, SMS etc).


I am reading "Style: Lessons in Clarity and Grace", have you read this?

EDIT: link to the book: https://www.amazon.com/Style-Lessons-Clarity-Grace-12th/dp/0...


It's much more useful then Strunk & White in my opinion.


I have not. I'll have to check it out.


> and commit messages

I noticed a while ago a trend for commit messages to be in the active voice and present tense. Seems to make them more concise and read better / clearer. Started doing that myself on my projects.


The two pieces of writing feedback I've received that I often regret not following:

- Most adverbs are superfluous. I am as guilty of ignoring this as anyone, but most cases where you say "generally" or "usually" you're undermining your point and the use of "very", "extremely", etc. are hyperbolic and breathless and make it easier to regard what you're writing as unserious.

- Avoid pronouns unless the antecedent is unmistakable. The use of "it" should immediately be a reason to re-read that sentence and the one before it for clarity.


You could actually drop the it in the last sentence... :-)


These prescriptive writing tips do more harm than good. The crucial question is not whether you have adhered to all the tips but if what you wrote sounds good. Following writing advice without critically analyzing it often leads to writing which feels overdone.


I can write you a sentence that sounds amazing. I can also write it with an unclear pronoun antecedent and make a hash of its meaning.

When you know how to write, you can break the rules. Until you do, guard rails keep you from looking like an idiot.


Easiest wins:

- "Start with why." (I use 3 layers of why, some more, some fewer.)

- Get it out, then go back and reverse the order of the sentences in each paragraph, so each one begins with the point you were getting to.

- Kill your babies. Any turn of phrase you are working around to keep it in, or make it work is not as good as you think.

- Read a lot of quality, edited writing. The Economist, Financial Times, Telegraph, and sometimes even the Guardian. Avoid cloying, sing-song, editorial prose that is full of jargon and cliches.

Source: am a writer who codes.


1. Try to have an identified audience. It makes the piece easier to write because the language selection will be straightforward and you'll be able to avoid explaining concepts that the audience is already familiar with so it will be shorter.

2. Keep paragraphs short.

3. Unless you're part of the story, don't use "I" or "we".

4. Avoid gendering an abstract person. "Flight attendant" over "stewardess" / "they" over "he".

5. For long reports put the three to five points in a numbered list on the first page and bold one sentence or fragment per point. This makes the report easier to forward to upper management. Upper management is where the bonuses come from.

6. Learn the precise definition of words. A software virus is not the same thing as a software worm. Being at a higher risk does not mean that the potential outcome has gotten worse (see risk vs hazard).

7. Re-read / edit your piece (log(estimated number of people reading it) + 5) number of times before publishing. This only applies to actual writing. Don't waste your time doing this for Hacker News comments.


I treat writing like I do programming. My goal is to get the interpreter (i.e. the reader) to properly parse and understand the idea I'm trying to convey. As such, I try and keep everything simple and on point, freely go back and refactor sentences which don't make sense, and read the content back in my head to see if the words I wrote even make sense to me.

The only other rule I really use is to write for as low level of an audience as I can. This helps to reduce confusion for the readers, not all of whom may have the same vocabulary or "state" as you. You don't want to write about concepts from CS 401 when your readers are in CS 101, especially if the CS 401 concepts are not required for understanding.

Oh, and avoid un-delimited sarcasm. It travels really poorly through the internet; someone will always take it at face value.


One of my favorite classes in grad school was learning to write about complex topics in a clear and concise way.

Hopefully these reading materials are still useful!

- "Science of Scientific Writing" https://cseweb.ucsd.edu/~swanson/papers/science-of-writing.p...

- "Style: Lessons in Clarity and Grace" https://www.amazon.com/Style-Lessons-Clarity-Grace-10th/dp/0...


As a developer myself, I have wanted to improve my writing skill. I have found an older copy of the The Pyramid Principle that I am working through. The whole premise of the book is to better structure your ideas using the pyramid pattern.


As a developer who received regular positive feedback on the quality of my writing, I am starting a side-project to help developers like you. :)

This post is to try to get a more diverse opinion on what constitutes good writing outside of my bubble.

Please check the kick-off post, maybe you find it useful: https://writingfordevelopers.substack.com/


Thanks, how often would you send out an email for this newsletter?


My plan is to send it weekly, but with shorter texts than this first one.

The idea is to be more specific, like: "Tips for a good Pull Request description", "Tips for a good feature deploy announcement email", "Tips for a good user story".

What do you think? Any topic you are particularly interested?


I'm very interested in this - will be signing up. I've been told my specification writing style is good if just a little repetitive. I appreciate it's a technical document and somewhat dry, however keen to see ways I could improve sentence structure.

Edit to say : Tips on effective email communication would be good. I seem to either be too brief and appear curt or waffle on where I shouldn't.


Thanks, it will the topic next Monday! :)


It is a bit longer, but how about a series where you outline writing a good README.md for a github project. This would include the descriptions, examples etc. Many times I will come across a project on github that seems interesting, but there is only a single sentence in the README.md


Great book. As well as improving your writing it will also make you a much more effective reviewer, even if your own work.


0. Give a damn. You're already doing this step, which is great!

1. Every first draft is crap. Edit. Edit again. I do this for everything — design docs, doc comments, HN comments, email, tweets. Writing is editing.

2. Have a clear audience in mind that you are writing for, ideally a single person, sympathetic to your topic, but choose whatever audience makes sense.

3. Treat your audience with respect and try to give them as much value as you can in return for the effort, time, and attention you are asking of them. When you edit to distill and clarify your concepts, you are transferring effort from them onto yourself, and they'll thank you for it.

4. Unless you're writing for a venue that explicitly requires it, formality is overrated. People will remember your writing better if they have some emotional connection to it, and that requires an informal human element.


Always proofread what you write. Always. Even if it’s a short text message or a giant email.


Never write a giant email. Nobody's going to read it.


I think there is a distinction between formal writing (article, blog post, docs, specs) and informal writing (commit messages, emails, pull request descriptions).

I wouldn't apply formal writing strategies to commit messages, they would be way too verbose. And I have different requirements for pull requests descriptions than I do for specifications.

I'm not sure where to start with helping you, it's a big question! If there's one thing that has always helped me it's re-reading what I've written; Write something, read it top to bottom (out loud, even), revise it, and repeat.


Lots of good advice here. Here are a few more basic tips:

1. Read it out loud when you're done. If it doesn't sound right, change it so that it does.

2. For the love of everything grammatical, please learn how to use apostrophes properly. Especially its/it's, your/you're, and yours. "It's" always means "it is." "You're" always means "you are." "Your's" is not a word.

3. There is no shame in using a spellchecker. (There is often shame in not.)

4. Know your audience. Don't use technical terms if you're writing for non-technical users and don't dumb it down for a technical audience.

5. Be concise. There's no need to prove you can use a dictionary or thesaurus to stretch out a sentence or to try to sound more intelligent than you need to be (it doesn't work anyway).

If you want a friendlier guide to grammar than some of the other books listed in this thread (which you should also consider adding to your reference library), check out Grammar Girl's Quick and Dirty Tips for Better Writing by Mignon Fogarty https://www.amazon.com/Grammar-Girls-Quick-Better-Writing/dp...


Some general pieces of advice that I think apply to all writing:

- Write like you would speak. Think of your writing as an extended conversation with other developers.

- Use the active voice wherever possible.

- Strive for clarity and simplicity over overly-complicated industry babble. The smarter you try to sound, the harder you will fail. Of course, there will be some amount of jargon you will rely on, which is fine considering your audience, but even with technical writing the Mark Twain axiom holds: don't use a $5 word where a $0.50 word will do.

- The best writing doesn't feel like writing. Take what you've written and read it out loud (to yourself or a friend). Rewrite until there's a natural rhythm and flow to your words.

- Don't be afraid of shitty first drafts. Dump out all your ideas without fear of judgment (no one's going to look!). Then go back and re-shape, re-word, cut, etc. I think of it like a sculptor and clay - your first draft is just a gathering of all the clay. The following revisions are about molding and shaping it for your intended audience.

- Finally, read good writing. Whether it be well-communicated emails or your favorite SF novel, pay attention to what other good writers are doing and try to emulate that.


> read good writing

That's sort of a Catch-22 right there. Can you tell if "your favorite SF novel" represents good writing without having a grasp on what constitutes good writing to begin with?

Is writing like cooking (where you don't really need to cook well yourself to be able to tell)?


"Can you tell if "your favorite SF novel" represents good writing without having a grasp on what constitutes good writing to begin with?"

I think for the purposes at hand, you don't need any expertise in writing to tell whether you want to write short emails with some stuff lifted from a given author.

The larger structural aspects of writing a good novel are overlooked by a lot of people, and a lot of people will declare someone a "good author" when every character in their stories are an author stand-in, things appear and disappear for no reason, there is no symbolic or mythic resonance in the story, and every other major structural error that can be made, simply because they like the sentence-by-sentence style of the author or the author has snappy wordplay that they like. That taste is more rare, but also only slightly relevant to the question of whether you can write a 500-word email to the executive team about how important it is to not cut your project.


By virtue of it being your favorite, I would think it's doing something right. But glibness aside, you could think about as you read: Is it fully engaging you? Is it communicating a complex idea in a simple and/or novel way? Is it making you feel something? Does it make you want to do something? These are all good markers, because writing is really just about communicating ideas well.

And if you don't trust your own judgment, you could look up some of the time-tested classics. Some of my favorites: The Great Gatsby, To Kill A Mockingbird, 1984 (fiction); Warren Buffett/Berkshire Hathaway shareholder letters (business/sales writing).


> By virtue of it being your favorite, I would think it's doing something right

That something doesn't have to be the quality of writing as such - eg. I can enjoy a somewhat sloppily written book if the idea behind the plot is captivating and compelling


There are plenty of writers who almost everyone agrees are great. For simultaneous clarity and beauty of prose, I like Graham Greene.


Hemingway App helps a lot: https://www.hemingwayapp.com/


I was going to submit this as well. There's room for improvement with it, but it really is great and a good launching point for reconsidering the structure of your writing. Especially business writing or comms.


Writing is like backups. If you haven't done a backup restore, then it's not a real backup.

Similarly, if someone can't read what you wrote and then explain it back to you in their own language and concepts, your writing hasn't passed muster.

There's a reason there are always acknowledgments to draft-readers in books and YC essays.

Good writing is a result of good editing.


If you're writing a long text (over 2 pages), you should invest the time to proofread it properly, and maybe get it read by a friend or colleague. When the ideas in a text are not clear and logically structured, it can be perceived as disrespect to the readers.

One thing that really helps me to catch typos in my own writing, is the text-to-speech utility built into Mac OS X. It makes it really easy to "hear" typos. Here is a doc with screenshots that explain how to set up a keyboard shortcut for this: https://docs.google.com/document/d/1mApa60zJA8rgEm6T6GF0yIem...


Keep your audience firmly in mind. Your dev colleague will probably warrant more technical detail than your non-dev colleague (but the non-dev colleague might need a different kind of detail). If the audience is future-you, you'll remember a lot less of the context of the message than you assume you will. You'll want to include sufficient detail to bring someone up to speed, link it to an issue in a bug tracker, etc.

But the kind of detail, appropriate level of detail, and presentation will change, depending on who is supposed to read it. An IM message to another dev will look very different from customer-facing documentation.


Writing improves from improved comprehension resulting from increased reading, writing, conversation.

So, make sure you are getting better at understanding the needs of the user and communicating them.

Have conversations with users - Solve problems that you have and make it available to others.

Solve others problems by learning about them and helping them.


Pretend like you're explaining things to a smart 10 year old. Keep your sentences well structured, only use jargon and abbreviations when necessary, and don't be afraid to repeat yourself for clarity. It helps to give as much background knowledge as possible.


If you're an emacs user, try https://github.com/bnbeckwith/writegood-mode


> writegood

This made me wince. I know it's perfectly acceptable American but that one's definitely a low blow for an aging Englishman.


I'm fairly certain that the name of the project is tongue-in-cheek; it's not uncommon to use "${X} good" as a comedic expression of poor English. For example, "I done code good."


Have a very specific audience in mind while writing. Even go so far as to write your content in an email editor with a friend or two similar to your intended audience in the To: field.


Get a good style guide, read it, and stick to it. I like the Dictionary of Modern American Usage because its recommendations are presented with justifications.


Commit messages should start with a verb, and complete the sentence "If you apply this commit, it will..."


Parsimony. Cut out the fat. Read Elements of Style for tips.

Also, read more and write more. You can only get better by doing more.


The key to good communication is brevity


"Omit needless words."


I suggest plugging all of your writing into Grammarly and HemingwayApp!


Tools: Grammarly


Don't be afraid of being terse.




Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: