Hacker News new | past | comments | ask | show | jobs | submit login
Please learn to write (randsinrepose.com)
516 points by filament on May 16, 2012 | hide | past | web | favorite | 117 comments

Source of my problems:

  design issues               5%
  architecture constraints    5%
  language shortcomings       1%
  mental blocks               5%
  personal time management    4%
  personal energy             5%
  communication with others  75%
I waste more time just trying to figure out what others are trying to say, sometimes in person and by voice, but mostly in writing. For most emails, I have to click "reply" or call back simply because what you're trying to tell me is so unclear. I think the last time I received a written specification I could actually work from was in 2002.

This isn't a problem of education, country of origin, or any other demographic: almost everyone sucks at writing. It's a real problem.

I suppose the best antidote to poor writing is more writing, especially on-line. Don't be bashful because as OP says, your readers won't be.

Thanks OP for the one "please" post this week that everyone can benefit from. (Did I just end that sentence with a preposition? Need more practice.)

Did I just end that sentence with a preposition?

A preposition is a perfectly acceptable thing to end a sentence with. Seriously. If you find yourself re-writing it as "with which to end a sentence" you're going to come across as stilted and awkward.

Eschewing trailing prepositions is a rule improperly inherited from Latin. It does not apply to Germanic tongues where prepositions are necessary to disambiguate verbs. For example, to ask about, to ask of, to ask to, and to ask in are very quite distinct. In Latin, the default position of the verb is the end of the sentence. Latin word order isn't fixed like English, so the ordering of words is a form of emphasis, and placing something in the final position, after the verb, is one of the strongest emphases possible. Putting a preposition in that position would be like someone screaming "WITH! WITH!" on a soapbox on the street corner.

It's a useful rule though: an English grammar book that proscribes trailing prepositions is one you needn't spend any more time with. Just put it down and forget that it exists.

Like so many other rules, it results from Latin-steeped scholars of the 19th century who were uncomfortable with the flexibility of their native tongue, and attempted to hem it round. It's understandable. These men knew they could use the full scope of expression of Latin. About the only person who's ever pushed English hard enough to make it creak was James Joyce.

Amusing aside: you can transform transitive verbs into nouns in English directly (to request, a request). You can't similarly transform intransitive verbs because they require a preposition. In German, you would say a for-ask or an of-ask, but we don't accept that in English. Verbs with both forms are an interesting grey area, such as to dig vs to dig for.

< Latin word order isn't fixed like English

It isn't fixed like English, but parts of it are indeed fixed, prepositions being one of them. The issue isn't that putting a preposition at the end of a sentence in Latin gives the preposition undue emphasis, but rather that you simply can't put a preposition at the end of a sentence in Latin[1]. Ending an English sentence with an article would be roughly similar in terms of nonsensicality. As for Joyce, well, you know he's binomeans to be comprendered!

1. It's the same with split infinitives, which you just can't do in Latin short of tmesis (http://en.wikipedia.org/wiki/Tmesis#Latin).

nicely written.

> You can't similarly transform intransitive verbs because they require a preposition. In German, you would say a for-ask or an of-ask, but we don't accept that in English.

i think i'll have a bit of a lie-down now....

> I think I'll have a bit of a lie-down now...

Maybe in your lean-to? (Only other example I can think of quickly.)

More seriously, thanks to the grand-parent for squelching the preposition nonsense so soundly.

Unless writing for a scientific journal, or some other such formal setting, your goal of clear communication will be best served by using a casual, conversational style that resonates as closely as possible with how you would talk to your reader in person.

That means prepositions are very much something you can end a sentence with. And you can start one with a conjunctive too, if it feels right. The rules of grammar are more like the pirate code than an ISO standard - they're more what you might call guidelines, really.

I think we'd be better served using such styles in scientific journals more often.

As an example, here's a wonderfully written article by the late statistician, Jacob Cohen: http://www.ics.uci.edu/~sternh/courses/210/cohen94_pval.pdf

Just to note, although he wrote far more on statistics, he was a psychologist born and bred.

Agreed. Grammar's just norms of communication, and norms depend on context. So treat the violation of them as such - sometimes it matters, sometimes it don't.

Apropos, http://www.youtube.com/watch?v=J7E-aoXLZGY it would seem this whole topic is rather inflammable.

All is dependent on audience.

"This is the kind of arrant pedantry up with which I will not put."

-- Winston Churchill, on not ending sentences with prepositions

Alas, there's no evidence Churchill ever said it.


Didn't he patent Facebook too?

I'm not against ending a sentence with a preposition, but I find myself often unconsciously avoiding doing it in speech as well as in writing. I don't really find it stilted (but I don't care about the issue one way or another). I say "what are you talking about?" about as naturally as I do "On which machine does this process run?".

Similarly, I tell people that I can count on one hand the number of times I've had a project fail (or nearly fail) because I or someone on the team couldn't open a database connection, or write to a file, or shrink an image, or what have you (it's happened, but very rarely, and usually because of some arcane weirdness or a truly incompetent person).

Overwhelmingly, projects I've been involved in that failed or nearly failed did so because of basic communication problems - misunderstanding someone, not clarifying, not getting enough detail, making assumptions, etc. Yet these skills are hardly ever taught anywhere. Hard tech skills in schools, certification progams, etc. all cover less than half of what makes a truly useful developer.

I work for a large corporation that paid for my Masters in Software Engineering.

Despite that, the most important training I have received is from taking the in-house courses on subjects like Interviewing, making decisions, being effective, basic management skills, etc. The one thing they have all had in common was that they taught (and stressed) better communication skills.

Seemingly simple, "soft" stuff like learning how to listen better has been more useful in my day to day work as a programmer than a technical graduate degree. Go figure!

+1 on making assumptions.

It's a nasty habit that I've been trying to curb this year, with some effectiveness. Whenever I catch myself making an assumption, I either come up with other assumptions and weight them, or wait until I can get some clarity on the issue.

I find that I have a nasty habit of giving a "voice" to a textual conversation. I'll start reading it as if the other person is happy, or angry. Then I'll continue down that path.

Recently it got to a point where I was seriously convinced that every text a friend was sending me was an angry quip. Every fiber of my being was slowly filling up with anger and resentment. When in fact they weren't angry at all, they were just short on time and words. I was getting upset over an imagined (assumed) problem.

I felt incredibly silly, and that is what made me decide to stop making assumptions in my communications.

I think you hit it on the head. I'd break down the 75% a little further in my case:

- 25% Poisonous people in key architectural/infrastructure positions who actively make it as difficult as possible to communicate.

- 15% "Mea culpa". I fail to clarify or make an assumption due to busyness, lazyness or missing something.

- 25% Folks who do not take initiative to engage in conversations at the appropriate time. These folks typically pop up with 11th hour critical path problems.

- 35% General nonsense: People incapable of writing english, etc.

Making the online communications situation worse is the proliferation of "short" communication methods (ex: IM, Twitter, FB Status messages, etc.).

Written communication is naturally more challenging than face to face verbal communication. These "short" communication modes make things worse, opening up all sorts of possibilities for misinterpretation and miscommunication.

I felt so shackled by IM conversations, that I disabled GChat earlier this year. I've rediscovered the telephone and how superior it is when I really want to understand the other person. The only modes of only written communication I employ now are blog posts, forum posts, and emails. They all give me the opportunity to thoroughly review my words before setting them free.

I've tried both, and for coding-related stuff, I really dislike phone (or Skype), ranking it just about the worst possible option. I'd much rather IRC or IM, where at least we can exchange code and links and there's a bit of a scrollback buffer.

Twitter and FB status messages I put in a different category, because it's difficult to have a proper conversation with them. It's pretty easy to have a proper conversation on IRC, though, at least if all parties are text-chat-fluent.

There are a bunch of collaborative text editing web sites where two or more people can work on the same document.

I've used them for technical phone interviews and they work well. Combine that with phone and skype and you can make things happen (of course it's hard to run code in this).

Perhaps a screen sharing / webex approach would work in the case where you really need to run code together.

TBH I find myself enjoying TeamSpeak quite a bit.

I've set up a private server and it's really nice. First of all you can record voice conversations. Secondly it offers chat between users and between channels.

I find that voice communication is really effective, but having the ability to say "Hold on, let me send you this link!" is also crucial.

I hadn't considered the coding situation, but you're right: coding is something where you need a visual reference to make sure that you're both on the right page.

But what about this compromise: Skype voice conversation + skype text-chat for showing each other code snippets.

That can work better than just Skype, but I guess I don't generally see the benefit. As long as all parties are chat-fluent (I've worked with some people who aren't, and then it can be painful, like IMing with my parents), I find IRC discussions better than Skype. Especially true if three or four people are participating; conference calls are much harder to demultiplex, at least for me, with all this time wasted on people accidentally speaking over other people, asking for something to be repeated, etc., etc. And with text, you can grep the logs, too!

> But what about this compromise: Skype voice conversation + skype text-chat for showing each other code snippets.

I've been using this combination for a few weeks now, working on a development project with a partner who is ~1000 miles away. Besides voice and text, Skype also has screen sharing. All three parts have become essential to how we work.

At my last firm we could share our screen just by giving someone a hyperlink over IM. Sometimes this was really valuable... for coding issues or support issues. Skype has this too, people should use it more.

The way you learn to write well is by reading.

And of course it makes a difference what you read.

Learning how to do anything well takes practice.

But you will not become a good writer unless you read.

As for what you should read,

"Garbage in, garbage out."

What do you think are the effects on your writing from reading blogs like "codinghorror"?

If your aim is to be a better written communicator in business, then you should read business correspondence from good sources.

While reading helps to improve your understanding of what makes good writing, I feel writing regularly is more important. You need to learn to foster your own ideas through writing, being careful not to just think what others write.

"For ever reading, never to be read." - The Dunciad III

Right. But if you only ever write and rarely ever read your writing will not be as good. Reading is essential to good writing. The quote you use is encouraging the reader to write, but it also presupposes that the reader is well read ("A lumberhouse of books in every head"). Maybe that's not a coincindence.

Is there a difference in encouraging a "scholiast wit" to write versus encouraging a "dimwitted blogger"?

Yes, I agree. Like all things it's a balance. In looking to refine skills everyone will require tuning in different areas. A programmer may be great at writing code but often fails to identify re-use of libraries/patterns. Reading others' code and technical articles may assist him/her in developing in that area. Likewise you may be able to tell when a writer lacks a 'lumberhouse of books'.

Being aware of why you are not developing a skill is probably key -- review from others helps to provide insight into potential underdeveloped areas.

A great engineer is superior to an average engineer mostly due to their communication skills.

> Did I just end that sentence with a preposition? Need more practice.

For me, grammar is the farthest thing from the real issue. What I find makes it difficult to communicate are situations when the writer/speaker is producing without the understanding that the reader has no fucking clue (or limited understanding of) what they are discussing.

Inevitably what I read or hear in terms of "specs" or "user stories" has an entirely different meaning to the writer/speaker than to the reader. The writer/speaker generally has at least some domain knowledge and often assumes such knowledge that should not be expected of the reader/listener.

Sort of ironic but pretending your someone else "really well" could qualify you as both perhaps insane (under some definitions) and as a really good writer/speaker. The critical point for me is the age old adage "know your audience".

I learned to improve my writing quite a bit by using outlines that let me shift through levels of abstraction at will. I write long e-mails and blog posts using mind-mapping software. Being able to re-order my paragraphs & sentences, include or change examples, and step up and down different levels of detail has made it much easier for me to communicate the points I want to make. I've found that this helps even when I'm writing short e-mails or HN comments.

Admittedly my writing doesn't sound pretty. I'm okay with this. My e-mail chains end up much shorter than any other programmer/analyst I know and result in significantly fewer misunderstandings. That's what I call success.

What mind-mapping software do you use?

A quick Google search reveals quite a few apps. I had never heard of this "genre" until now!

I used to use bubbl.us because it has nice keyboard shortcuts. Now I use www.checkvist.com because you can create stuff in a list format, which is easier to paste into documents and share with others.

MindNode (http://mindnode.com/) is not bad for Mac. I've also found FreeMind (http://freemind.sourceforge.net/wiki/index.php/Main_Page) pretty good in the past.

I love freemind, mostly for how quick it is to use from just the keyboard, and also for the the platform independence which makes it very easy to use it collaboratively.

It bothers me when other engineers I work with use common terms in ways that don't mesh with their definitions in standards documents.

Please, fellow engineers, read the standards documents, and use terms correctly. Even the ones that you think you know already.

This is exactly why Jeff Atwood was wrong. If you can solve your own problem instead of having to communicate it to someone else, you've taken away 75% of the impediment to a solution.

All dependent on context. In the context of a team, one can rarely solve all problems by herself. More importantly, it can cause greater disfunction when work isn't coordinated/communicated appropriately. The whole point of working in a team is to get more work done more efficiently because the work load is shared and each member focuses on her specific skill, and doesn't do everything.

Yes, context is key. My implied context was small problems that can be solved with just a little bit of programming. If the problem is big enough to require a team then a different approach is required.

If you're working on a problem that you can solve alone, you need a bigger problem.

People deal with small problems or questions all the time. If you can answer your own question using less effort than it would require you to communicate the question to someone else, you're ahead.

no, what atwood was saying is that if you're dealing with a problem todo with FOO, learning about BAR won't help you.

"This is a rule up with which I cannot put." Winston Churchill

I'm (primarily) a coder and I've started writing a short weekly newsletter for the users of the application I'm supporting and extending. The basic format is "what happened this week" and "what may happen next week" as well as a "please communicate with us if you have concerns or ideas". I'm now 14 weeks into this experiment, and I've found a things worth sharing.

1. Explaining to your entire user base what you're up to helps you focus your efforts on meaningful demonstrable progress instead of gold-plating.

2. It has been said a hundred times before, but the way to get better at writing is to write.

3. People prefer incremental changes over disruptive redesigns, especially if they are given a heads-up before the incremental changes happen.

4. People care about the quality of writing. I've gotten a bunch of comments about how they actually enjoy reading the newsletter. That was totally unexpected.

5. Tone matters. I've found a good conversational tone that incorporates just a touch of humor and self-deprecation without being too casual. My userbase is non-technical, so I can't leak jargon on them. Metaphors help.

6. Cadence matters. Writing a weekly update is much easier than writing an update "just whenever".

7. Having an editor helps. I generally write the entire message, but pass it along to comrade to send it out to see if anything is confusing, I've made any typos, or forgot to finish one of my sentenc

This advice sounds fantastic, and I've bookmarked it for reference. Thank you for sharing!

I'm glad you like it. I just remembered another thing I've learned from the experience and added it (#7 - have an editor)

One of the best pieces of advice I received for my career was from my university's computer science counselor.

I asked him what I needed to do/study to be better than other programmers. I started asking, "should I study C, Java (it had just come out), etc. He said study something to improve your communication. He said in the real world business just look at you as a computer person. They don't know the difference between a programmer, network engineer, PC support person, etc.

He said anyone can code and the ones that are way better will not be recognized enough by management to make a difference in their careers. Since computer people are sort of known as introverts, just being able to speak well and communicate with everyone will go further than being the expert at language X.

Communication skill is a proxy for critical thinking skill - if you can't communicate effectively, your critical thinking skill is either going to be undervalued or underutilized.

For the lack of understanding, communication inputs are misinterpreted, ignored or incorrectly responded to. For the lack of clarity, precision and understandability, communication outputs suffer the same fate. And, as we've learned in networking, inefficiencies in a system (such as the engineer whose emails make no sense, when he/she bothers to reply at all) get routed around.

Everyone should learn to code. Everyone should learn to write. But we shouldn't necessarily aspire to become professionals in either.

English and Code are tools that are used by others to form the world around us. To understand these tools is to understand this world. To not understand these tools is to be at the mercy of the world's creators.

Knowledge is power; it is both the power to attack and the power to defend. Learn to write and learn to code, not to attack, but to defend yourself in this world.

knowledge is energy, being able to apply knowledge to a situation is power.

Being able to write well appears to be a shockingly lacking skill in my industry (pentesting and forensics). It's a really rare talent when you find someone that is capable of writing a good report in appropriate plain business English.

Having that skill is intensely valuable, as I'm sure it is in other areas of IT. How big a role does being able to write well play in your part of the world?

Good writers move up the organizational and/or salary ladder.

Good technicians or engineers who cannot communicate end up making the guy who translates whatever they are doing to the customer or management look good.

True. Effective communication is just as important as writing good and maintainable code in my opinion.

I suppose I could get a blog post out of this, but I can't be bothered, so:

Please learn to use a phone to make a voice call.

I value effective written communication, but part of effective communication is understanding your audience, and in many situations, you audience is only a handful of people. In that case it is a much more efficient use of your time, and theirs, to just have a conversation.

IRC or IM is a reasonable substitute, and a face-to-face conversation, if practical, is even better.

(Writing this in a spare moment before talking to someone face-to-face. Last night I spent the better part of an hour trying to figure out how to address the issue over email before concluding that a short conversation would be more effective)


"Is there any skill besides coding that allows you to use your ability to make using your ability easier?"

Code is probably far and away the best example, as you point out. But this is true to a lesser degree in areas like metalworking. It is also true to an extent in biology where one biological system can be constructed specifically to help study or mass produce another.

And of course it is true in mathematics, where by moving up a level of abstraction you can develop techniques and knowledge that help in a huge array of problems.

In short, it will be true in any field where the material being worked with is also the material being worked on.

It seems like the skill of building machines would be analogous. There are all sorts of machine out there that help you build more machines, and if you know how to build machines you can improve these machines to help you build better machines.

Absolutely other fields use their "abilities to make their abilities easier". As a coders we live in abstractions and you should be seeing them everywhere.

Writers work with words, but some smart writers invented sentences as tools to help structure them. Some other writers invented paragraphs to structure those sentences. Some even smarter writers invented novels, short stories, screenplays, etc. These are all tools built with writers tools to make writing easier.

The processors you use to run your code are tools made by electrical engineers built with logic gates, which are tools they built on top of electrical components, which are tools themselves. etc etc etc.

Short stories, screenplays and novels are definitely not tools, since you don't build stuff with them, they are finished works, and if you want to make another one, you have to start from scratch. I'd argue there are more similar to frameworks, but less powerful, since the structure of a novel only gives you a basic idea of how the end product should look, instead of doing any actual work for you.

The novel, short story and so on are absolutely tools used to build things[1]. So are genres (sci-fi, fantasy), narrative modes (free indirect discourse, stream of consciousness), and even rhythms or styles (see the Oxen of the Sun episode of Ulysses for an extreme example). Concepts are generative: if you decide to write a Künstlerroman, a lot of the heavy lifting is done for you.

That said, a single writer can't, as a general rule[2], "use [their] ability to make using [their] ability easier" in this way, since genres, modes and the like don't "just work." Even when they descend from the work of one or a few innovators, there's a long process of consensus-building that has to take place before new concepts become conventional and, as a result, productive.

1. The screenplay (for both film and television) in particular is structurally very rigid, although slug lines and such admit more variation than most people think. And the actual writing is capable of great variety. Check out the original Alien script (http://sfy.ru/?script=alien) or the Alien-inspired style of WALL•E.

2. Though of course it happens: T. S. Eliot, Ezra Pound, James Joyce, et al.

It's been almost 15 years since my linguistics courses, but I'm pretty sure the spoken word (along with the grammars that bounded it) existed long before writing.

I also believe you drawing correlations between human languages and computer languages that don't exist. Computer language designers define syntax and grammar initially. Human language develops far more organically (to put it another way, where's the spec for American English?). Certainly, human language gets bounded by rules, but not in the same way as code does.

programming languages are often less "designed" than you might think. consider the history of C: the path leading up to the first formal spec, ANSI C 89, was twenty years long and involved endless mutations and competing versions--commonly called "dialects"! many languages (perl, python, etc.) have only a reference implementation, not a spec per se, and things like HTML (not precisely a programming language, but definitely a computer language) are so flexible and underspecified in practice as to resemble human language quite closely.

To be fair, if I want to apply computer technology to solve certain complicated, real-world problems, I need to know both code and calculus.

There is very little automation required in writing, though.

Writing is for people, not compilers, and people don't like reading the same thing over and over yourself. Good writers don't repeat themselves simply because it's boring (except, of course, in situations where it makes sense to repeat yourself for some specific purpose, but I digress)...

Also, it's not fair to say that there is no leverage effect from writing. As a simple, obvious example, I leverage earlier blog posts that I've written in later ones. This saves me from having to re-explain older concepts, and allows me to reach into more complex concepts, since I have already explained the simpler concepts that the later elaborations rely on.

Finally, it's worth pointing out that the purposes of writing, piano-playing, or coding, are different. Coding is generally a utilitarian activity, aimed at achieving a practical purpose, that can be sped up profitably. Writing and piano-playing are more like entertainment. It's as pointless to speed up piano-playing as it is to speed up a dance.

> There is very little automation required in writing, though. > > Writing is for people, not compilers, and people don't like reading the same thing over and over yourself.

isn't romance half the US fiction market or something? romance authors are basically human automatons all executing (not implementing) the same function over and over again.

> [...] as long as they do something about math's terrible symbol notation...

Which area of math are you talking about? In general you can make up your notation as you go along solving your problems, and only need to use a common notation for sharing your work with other people, and even then a short introduction will usually suffice and you can use your notation.

The standard notation is convenient, and that's why people use it. Historically, it developed writing on black boards and paper and works best there, it doesn't map all that well to ASCII.

Carpenters and other craftspeople often build their own tools.

Many people are commenting that writing improves with practice, and that's true, but it probably isn't enough. The 10,000 hours count only if they're done well. I'm not a writer but here are some basics I've found helpful.

1. Revise constantly. If you haven't revised it three times you almost surely haven't done enough. You don't need an outline, but as you write new thoughts will occur to you, previously open questions will be answered, opinions of priorities will shift. Writing in the Rubber Duck school of programming to the nth degree. All that you discover you already knew should be completely reflected in the final document. This is a very painful thing, you can spend hours on something and be "almost done" when you realize the key question on which all depends, the answer to which requires a complete rewrite of the document.

Note that "revision" often means changing the purpose of the document. You can go from reporting status to asking about key variables driving that status. Text may not be the right medium for the new message.

2. Edit ruthlessly. Everything can be shorter. The time you take clarifying and shortening saves your readers that much and more -- since you, not they, are best positioned to solve the puzzles posed by an obscure sentence, and to summarize an overly long one. If your readers number more than one, the time savings are multiplied.

3. Be very clear in your terms, meanings and references. If they aren't clear, explain them. Did that explanation just blow up your document's organization? Time to revise. Be precise. Your audience does not have your perspective -- your local environment variables are not theirs -- you need to orient them to the topic before you can expect casual references to be meaningful.

4. Much business writing requires an imperative style. At the top, tell your reader the action or decision expected / hoped for of them at the end of the document, and tell them what you will talk about. As you provide information, keep it in relation to the action expected of them. If there is no relation, what is it doing here? If it must be in here, why? and what are the implications for the stated purpose of the document? Is it time to revise again?

At the end of the document, give them detailed instructions about what they should do next -- call at this number, email that address, provide these thoughts, whatever.

Good training in writing is available and worthwhile. If you really want to get better, seek it out.

I once asked a well known science writer how many times he will revise passages. He sighed and replied "sometimes, for the difficult spots, maybe fifty to a hundred."

This made me feel much better about my own writing, which often goes through many, many drafts.

It also helped me appreciate Thomas Mann's maxim that a writer is someone who finds writing harder than other people.

2. Edit ruthlessly

I would add one more piece to your excellent suggestions: find a skilled editor if at all possible. An editor will find things you won't and offer suggestions based on an entirely different reading history and pool of knowledge. You'll learn much vaster and write much better material with another person to help you than without.

I've found some of the best training available is in discussing controversial subjects (like religion) with a mixed, but curious and respectful, group. The biggest drawback is that it's hard to find such an audience.

One of the best forms of training this circumstance provides is immediate feedback any time you fall short. If you're not clear in your terms, meanings, and references people will respond with misunderstandings. If you're too verbose, they may not respond at all. If your writing is poorly structured, they will be confused as to what point you were trying to make. And if you do a good job, you'll get meaningful and interesting comments and criticism, which will help you refine your ideas and be better able to write about them in the future.

" Good training in writing is available and worthwhile. If you really want to get better, seek it out. "

Do you have any pointers for resources ?

This is the most valuable thing I've learnt during my PhD. PhD teaches you:

  research skills                                     50%
  ability to communicate your research to others      50%
In my experience, I've noticed a lot of very smart hackers to be woefully bad in communication, and PhDs to be much better than the median at it. On the other hand, I think there is no correlation between research skills and having a PhD.

An interesting take on the topic. I would tend to agree with it. I've always maintained that it takes a certain something to be a programmer. The specific language is less important if you have a "programmer's mind". I've worked with a bunch of different languages. Once you get over the varied learning curve of the exact syntax and structure, it really just leaves you with the general logic and planning and all the stuff that any app is going to require regardless of the language. These aspects are not as easily learned as things like "always (or never) terminate with a semi-colon" or "white space matters".

But I also struggle a fair amount with remembering all the rules... and exceptions to those rules... and exceptions to those exceptions... when it come to American English. Sometimes I actually have to pause and mentally recite the rules for "its vs. it's" and things like that. I think that comes from there not being a strict compiler for the that. The reader is going to be more forgiving in the sense that even if you misuse its when you should use it's, the reader is going to to understand your overall meaning. Most won't correct you because it doesn't really matter to them. Think about the butchered language that gets used on Twitter to get things into 140 chars. It would be nearly impossible to write an interpreter that would take most tweets and rewrite them in proper English. You have too many variations to make that work. But the reader will probably have less trouble with it.

The most crucial part is expressing your idea clearly. Being concise. Not wasting the reader's time.

If you have great content in your writing, the reader will treat "syntax errors" as "warnings."

Communication isn't one-way.

There are billions of people and plenty of languages out there (nearly 200 are spoken by at least a few million people per language, if you go by the list on Wikipedia).

We live in a world where most co-workers have probably had to claw their way up to their current language proficiency.

People who only know one language can't really complain about poor communication. Both people in a conversation have a responsibility to work at closing any gaps, and frankly a native speaker has more than 50% of that responsibility.

Even if you have learned another language, do you really know how tough it could possibly be? For example, have you learned to read, write, speak, swear and slang in the 2nd language to the point where no one will misunderstand you? And here's the real test: is the alphabet the same as your native language or is it something totally new?

I grew up with English. I spent years learning to read, write and speak French, and while this gave me some appreciation for the difficulty in learning a language it was still the same letters, similar words and a few new rules. I've since invested a lot of time in learning basic Japanese and that is something I'd recommend to anyone who thinks they're an expert at a language.

You have to try something completely unlike anything you've ever seen before you understand what a chore it must be for others to try to communicate with you.

The funny thing is we live in an era where more people write more than ever - between Facebook, forums, online dating profiles etc. Twenty years ago the average high school graduate stopped writing anything longer than a shopping list, or maybe a letter, after age 18,

but they were probably more diligent in the writing they did do. now writing is trash.

writing is another form of informal speech.

What others haven't said is that, writing is both the formulation of logical thoughts and the communication of those thoughts so they can be understood by another person. Writing and logic go hand and wrench.

Organizations which design systems are constrained to produce designs which are copies of the communication structures of these organizations.

-- Conway's Law ( http://design.caltech.edu/erik/Misc/Conway.html )

First reading this adage was a relevation. I realised I've never worked on a technical project that wasn't constrained by it. This post/discussion reminded me of it again.

"On Writing Well" from W. Zinsser is one of the few books I've read multiple times over the years and probably the book I've recommended and loaned out the most.


Anyone who runs a business, has a blog, has to communicate with other, or sends email should read it. Twice.

Have this book, and couldn't agree more.

Writing strikes me as providing different fundamental skills. Here's the rub: computer languages are entirely prescriptive-- behavior is defined by the compiler. Natural languages are defined entirely by usage and here the descriptivists rule. Even in hyper-defined jargons like legalese, interpretation matters and there is no single, objective reference point.

I believe everyone should learn to code trivial programs. I also think there is great value in truly mastering one's own language (and I say this as one who can fluently read Middle English and who can parse my way through Old English given some time). But they are different skills. You can't get them all from one or the other.

If you want to compare writing to programming, then you should consider comparing it to writing portable software in a language where every reader has coded his/her own compilers based on their own unique understandings of the standards! But writing isn't the same as coding.....

I often find it annoying in writing and in speech when people don't know the correct technical terminology for an idea they are trying to express, when they ought to.

Believe it or not, there are people out there that write Objective-C, for example, and don't know what an "instance variable" or a "class method" are by name.

Or go blathering along about ctors or visitors. If you want to use slang from some random book or website, define it.

A while a go I saw this article that told that strongest correlation with economic success now is with reading skills within that nation in 1900. (sorry I lost the article)

What is the reading of today? I think it's coding and here's why: A young person is good at school in two things, math and biology. She thinks that a career of mathematician would be little boring, so she chooses to become a biologist. She doesn't ever think about becoming an engineer because she never had to do anything that would have indicated that shes good at it.

Now how about a school where people have to learn to code just a little. Suddenly the people who are naturally talented at it start to do it. Not just the people who think it's cool because their elder brother codes. People have a strong tendency to do things they are good at. But only if they know they are good at it.

The next great thing will be a post titled: "Please: stop with 'please' titles"

And then the next day, we'll be surrounded by posts about the first time a person used the word 'please', and why another person continues to use please, and another post encouraging the use of please more often...

And HackerNews will have been successfully trolled again.

"Please" considered harmful?

In a series of posts that uses it to self-promotion? IMHO yes.

It was a reference to this: http://en.wikipedia.org/wiki/Considered_harmful

Namely -- Frank Rubin published a criticism of Dijkstra's letter in the March 1987 CACM where it appeared under the title 'GOTO Considered Harmful' Considered Harmful. The May 1987 CACM printed further replies, both for and against, under the title '"GOTO Considered Harmful" Considered Harmful' Considered Harmful?. Dijkstra's own response to this controversy was titled On a Somewhat Disappointing Correspondence.


My (really) bad! Shame on me.

What's the difference between coders and the population at large? My thought is that it's the difference of problem granularity/scale/scope. In general, computer programmers are interested in solving bit-based problems, the rest of the population not so much.

That said, my opinion is that 'programming' in the broadest sense is a native capacity of humans and therefore is not special. If you haven't realized by now that algorithms == recipes == best practice methodolgies == etc. you're missing the forest for the trees: programming is systematic problem solving period. C# mavens aren't the only ones who program; we all do.

The liberal arts need to be valued more highly. 'Nough said.

If you're willing to spend a few dollars to improve your writing, buy "Style: Toward Clarity and Grace" by Joseph Williams (http://www.amazon.com/Style-Clarity-Chicago-Writing-Publishi...). It's far better than a list of rules; it breaks down sentence and paragraph construction and shows you exactly how to write more clearly (and less academically). And it accomplishes this very quickly, with a marked improvement in your writing after only a couple chapters.

Exactly what I thought when I saw all the responses to Atwood's original post.

I think he meant to play the realist card. Of course the world would be better if more people learned how to code, but that comes at a substantial time cost. Lets say I argued on how everyone should learn to play an instrument. There are many intangible benefits to this, but lets get real. The world would only be a better place, truly, if everyone learned how to play an instrument well, and there just isn't enough time for that.

"Neither can his Mind be thought to be in Tune, whose words do jarre; nor his reason in frame, whose sentence is preposterous; nor his Elocution clear and perfect, whose utterance breaks itself into fragments and uncertainties." - Ben Jonson via Richard Mitchell


Maybe the thought of people who do know how to communicate, such as Mayor Bloomberg, learning to code is bothersome to Jeff Atwood. If so, consider why.

My concern is that Bloomberg is just looking for money. He may have no interest in how a computer works.

If he could code, what sort of programs would he write?

For example, with respect to the desktop and the web, many "coders" write programs that are a constant game of manipulation of naive end users. The moral issues raised in programming are seemingly endless. It's relatively rare to find a programmer with a social conscience. Mainly because few people with a social conscience know how to program.

Would people like Bloomberg bring a greater sense of social conscience to programming? Or would they worsen the situation?

On the flipside, having more people be more familiar with programming might reduce the amount of manipulation that is possible. More people might start demanding and reading source code. That could be a positive force.

you know, now that i think about it, the first question really ought to be, why the hell does the man who brought us the https://en.wikipedia.org/wiki/Bloomberg_Terminal bloomberg terminal need to "learn to code"? is he just talking about updating his skills, or has he actually been running one of the world's biggest data companies for more than thirty years without knowing how to program?

It just goes to show that you do not need great knowledge of programming to launch a business that relies on it. The founders of Bloomberg LP all had very good knowledge of the financial sector and the technology used in it. They knew the shortcomings in the solutions provided to trading desks. But whether any of them could themselves construct a Bloomberg Terminal is, in retrospect, irrelevant.

They had industry-specific knowledge of the problem they were attempting to solve. Unless you have worked in an industry, as a programmer you are unlikely to understand the true nature of the problems in that industry. And thus, you will not know what opportunities there might be for innovation. Is this the so-called "non-technical founder"?

Bloomberg wants to know how to build things in software. He wants to stimulate New York's economy with more software development industry reducing reliance on the finacial industry alone. It's interesting if nothing else.

Mike graduated with an EE degree in 1964. He worked his way up from an entry level job on Wall St to overseeing equity trading / running information systems at Salomon. There was never any reason for him to code given the programmers working for him. It was a way less accessible skill in the 80s.

One of my all time favorite pieces on writing is Orwell's "Politics and the English Language."


there are two sources of problems for Unix geek: 1. permission problems 2. communication problems

The latter is the source of problems for most people, so learning to write and speak clearly will give you a huge leg up on becoming successful.

All this back and forth makes me want to write a blog post called "Please learn"

Had the same thought. After your post I will write a blog post called "Please!"

Please learn to learn

They mayor of NYC wants to learn to code? Awesome!

And yet detractors think he should spend more time off, "doing mayor things." Leave it to the professionals. We don't need to teach everyone to be a master carpenter, right?

"Learning to code," isn't just about teaching people another vocation. We don't teach kids to be carpenters because we know that with a little math, some reading, and advice from a carpenter that kid could figure it out. If you give them a rule in the imperial system and blueprints in metric they should be able to figure it out. Mathematics and literacy give them tools to solve other problems. We consider them fundamental tools.

The reason why teaching people to compute or "code" as some are putting it is to teach them a kind of literacy. You can't take the fundamental math and reading skills you're taught in school and write a computer program to classify your email for you or scrape the sports scores off your favorite site to track your bets. Without understanding the fundamental concepts of computation there are a whole categories of problems and inefficiencies that persist unaddressed.

So what's wrong with teaching people the basics? Most people can figure out how to unclog a drain or bang together a decent shed without investing their lives into becoming master plumbers and architects. It may be easy to think that today there just aren't the prevalence of problems in peoples' lives where a rudimentary understanding of what a program is and what a process is can solve, but I dare you to keep hold of that notion for the next ten years. Programming to those who are experienced practitioners is a skill that is easily taken for granted. You may think that programming involves sitting in front of a computer noodling with compilers while life passes you by but you'd be wrong. With enough of a basic understanding, the fundamentals, that we can give someone an intuition about what a program is and how it can be used to spin off processes that can do work for you and apply the things you learned in your maths classes or automate tedious work in your research... we can really make the world a much better place.

How would software patent reform still be an issue today if we had been educating people on the fundamentals of computer science for the past few decades instead of hiding it in the upper eschalons of academia? Would phishing scams still be profitable with fewer rubes? How much inefficiency could be saved in research, finance, design, journalism, and so forth if everyone had at least a basic understanding of what a program is? Sadly most people don't it seems. They use computers all day long but if you get talking with them about it they don't understand what the machine is doing... they're just merrily typing in and clicking on the things they're told to and wouldn't have the faintest idea if there was a better way to do things. Such is the way the world is when people are ignorant of the tools they use.

It's simple to dismiss now and maybe in ten years time your friends and family will still throw their hands up at computers and marvel at how the hell they work. Perhaps as many people do now with math. But that's a poor reason to suggest people shouldn't be taught these things and should remain ignorant.

It's a bit funny that the title of this article is broken English.

Within which he kicks it off with with a passive sentence...

1. Read "Politics and the English Language", Orwell

2. Goto http://andromeda.rutgers.edu/~jlynch/Writing/

3. Read http://www.amazon.com/English-Language-Users-Guide/dp/158510... by Jack Lynch (as well)

4. Understand Paul Grice's Conversational Maxim's: http://www.sas.upenn.edu/~haroldfs/dravling/grice.html (Understand that they are, as proffered by Grice, descriptive, partly anthropological heuristics for analysis of certain ways of talking, or façon de parler; but they _may_ also be developed as normative principles which may be used to constructively guide all talk exchanges.)

Fig. 1, Grice's Maxims:

❝ The maxim of quantity, where one tries to be as informative as one possibly can, and gives as much information as is needed, and no more.

The maxim of quality, where one tries to be truthful, and does not give information that is false or that is not supported by evidence.

The maxim of relation, where one tries to be relevant, and says things that are pertinent to the discussion.

The maxim of manner, when one tries to be as clear, as brief, and as orderly as one can in what one says, and where one avoids obscurity and ambiguity.

Fig. 2, an excerpt from J. Lynch:

❝ ##Prepositions.

Prepositions are usually little words that indicate direction, position, location, and so forth. Some examples: to, with, from, at, in, near, by, beside, and above.

A quick-and-dirty rule of thumb: you can usually recognize a preposition by putting it before the word he. If your ear tells you he should be him, the word might be a preposition. Thus to plus he becomes to him, so to is a preposition. (This doesn't help with verbs of action; show + he becomes show him. Still, it might help in some doubtful cases.)

##Prepositions at the End.

Along with split infinitives, a favorite bugbear of the traditionalists. Whatever the merit of the rule — and both historically and logically, there's not much — there's a substantial body of opinion against end-of-sentence prepositions; if you want to keep the crusty old-timers happy, try to avoid ending written sentences (and clauses) with prepositions, such as to, with, from, at, and in. Instead of writing “The topics we want to write on,” where the preposition on ends the clause, consider “The topics on which we want to write.” Prepositions should usually go before (pre-position) the words they modify.

On the other hand — and it's a big other hand — old-timers shouldn't always dictate your writing, and you don't deserve your writing license if you elevate this rough guideline into a superstition. Don't let it make your writing clumsy or obscure; if a sentence is more graceful with a final preposition, let it stand. For instance, “He gave the public what it longed for” is clear and idiomatic, even though it ends with a preposition; “He gave the public that for which it longed” avoids the problem but doesn't look like English. A sentence becomes unnecessarily obscure when it's filled with from whoms and with whiches. According to a widely circulated (and often mutated) story, Winston Churchill, reprimanded for ending a sentence with a preposition, put it best: “This is the sort of thing up with which I will not put.” [Revised 12 Jan. 2007.] ❞

Write and talk appropriate to your audience. Your audience in some cases might be your self. Determine what criteria you demand for a successful "talk exchange" such that shared knowledge may be produced, rather than actionable results (we should ignore implementation details).


The font on that website hurts my eyes.

Seems fine to me

"I tweeted Jeff Atwood’s piece because, well, I agree that it’s pretty silly to think that the world is going to be a better place if the Mayor of New York City learns how to code. I agree with Atwood that his valuable time would be better spent elsewhere."

Oh yeah? And who the fuck are YOU, sir?? Or Mr. Atwood?

For all you know, the world would be infinitely better if the Mayor of New York City learns how to code.

But I suppose we'll never know, because no one should ever do anything other than what they are to be doing right then.



In that case, stop writing and go back to whatever it is you were doing before, because the world is not a better place when you blog -- your valuable time would be better spent elsewhere.

Is not history itself defined by breaking patterns? They don't call it a "turning point" because it sounds nice.

How many events that altered the path of mankind were part of "The Plan"? How many were arrived at by strictly adhering to a well-defined path?

Applications are open for YC Summer 2019

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