At the
devLink Technical Conference, one
of the Open Spaces focused on Computer Science curriculum at universities, and what
things that the developer community would CRUD on the CompSci tradition. Though I
did not have opportunity to participate in the discussion—I was facilitating an Open
Space on Continuous Integration, next door—I do have one proposal: "Writing." For
Computer Scientists—a traditionally introverted and communication-challenged group—programming
in English (substitute with your native language) should be paramount. Communicating
to humans is part of our job description, and we must be able to do so effectively
and using their language, whether it be for status updates, business justifications,
SOWs, proposals, or just another email. Developers need to communicate effectively;
write well rather than write good. We must be right like a writer.
We programmers should write like we code. The written word should be concise, to the
point, just like code. Coders do not frivolously use fancy namespaces and complicated
classes so that their code looks smart, as it has the opposite effect by resulting
in bloated, inefficient, unmaintainable systems. Big words implemented frivolously
for the sake of sounding smart perform the opposite function, and likewise result
in bloated, inefficient, unmaintanable text. We avoid power robbers in our code, such
as using string builders rather than underperforming string concatenations, and should
avoid similar performance kills in our writing. Additionally, using the wrong keyword
in code, or misusing grammatical marks in our code, results in compiler errors or
runtime errors. The written word—a language void of any compiler benefits—throws runtime
exceptions on execution when it is improperly authored, much like JavaScript or XSL.
“Vigorous writing is concise. A sentence should contain no unnecessary
words, a paragraph no unnecessary sentences, for the same reason that a drawing should
have no unnecessary lines and a machine no unnecessary parts. This requires not that
the writer make all sentences short or avoid all detail and treat subjects only in
outline, but that every word tell.” — William Strunk
But like a programming language, English is simply a matter of keywords and laws.
We must learn the rules of the system; we must learn its syntax; we must learn how
to test and validate our code before shipping it off to a client or to production.
Approaching the English language like we approach a programming language would also
provide an effective learning mechanism for us developer-types. This would make an
effective course at university: "Writing : For Programmers." Learn English like we
learn any other language—approach it using our virtues—as what works for us may not
be the same path that works for an English major.
Throughout my career, I have noticed a few areas that are typically mis-coded. I have
included a few items below that every developer should be aware of to help learn English's
keywords, its laws, and to provide opportunities to improve end-user experience.
Knowing the Language at an Elementary Level
-
Homonyms : words that sound the same but can mean different things. This is
often a challenge for people new to English, but even veterans get confused. Everyone
should learn the difference, and make proper use a habit. And proof read, as spell
check will not catch misuse of homonyms. This applies to:
-
Their / There / They're
-
To / Too / Two
-
Your / You're
-
Its / It's
-
Hear / Here
-
Threw / Through
-
Write / Right
Irregardless
is not a word.
Who vs. Whom : Who, the subject, is doing the acting,
and whom, the object, is being acted upon. The shortcut is to use who and whom as
you would he and him. (Remember that him and whom both
end in "m".) <Who did what to whom for how many jellybeans? He did that to him
for five jellybeans.>
Me vs. I : Follow the same rules as for who vs. whom,
above. The subject is doing the acting, and the object is being acted
upon. Subject pronouns are I, he, she, we, they,
and who. Object pronouns are me, him, her, us, them,
and whom. <Sally gave me five dollars. I used to money to buy lunch.>
Than vs. Then : A comparison (than) vs. a measure of time
(then). In code, than is used when describing a comparison operator;
the '>' operator is a greater-than operator. In code, time sequences are
an if...then statement. <Apples are better than oranges. I will eat my apple
first, then I will eat my orange.>
Knowing the Language at a High School Level
-
Power Robbers : Never use due to the fact that. It weakens your sentence.
Use because.
-
Contractions : In formal writing (e.g. Proposals, SOWs), avoid contractions.
Contractions are for casual writing. Think along the lines of a Debug Build versus
a Release Build.
-
Simply & Obviously : Avoid using simply and obviously as
it may be both to you, but neither to your audience. If it was simple or obvious,
then you didn't need to write it.
-
Use one space after a sentence, not two. A PC is not a typewriter. On a typewriter,
with fixed-width fonts, two spaces are preferred, but on a PC, True Type fonts will
properly space "<dot><space>" for you. Don't believe me? Open up any book
and look at the spaces between sentences. Microsoft Word has an option to indicate
this for you under grammar preferences.
-
Effect vs. Affect : Effect is the result, affect is
the action. Noun and verb. <Poor engine performance is the effect of ignored maintenance.
Ignoring maintenance affects engine performance.>
Knowing the Language at a Collegiate Level
-
Lists : Just like when defining an array, use a comma after every item in a
list except the last. This includes before "and." <I like red, white, and blue.>
-
i.e. vs. e.g. : The first is in other words and the second
is for example, though this does not do much for clarity. Essentially, i.e. is
a complete, clarifying list, while e.g. is an incomplete list of examples.
<I watch the three stooges (i.e., Larry, Curly, and Moe). I like all four-player
card games (e.g., Euchre, Spades, and Hearts).>
-
Semicolons : Semicolons are used to separate two independent yet related clauses
that could be broken into separate sentences. <The water is very hot; I hope I
don't burn myself.> Also, use semicolons to separate items in a list where the
items contain commas. <When the cards were dealt, Jack had a straight; Sally had
two nines, two fives, and a queen; and George had a full house.>
Be mindful of your native language. It is the one you use the most, even more
than C#, or Ruby, or Java. If you don't already own a copy, pick up
The
Elements of Style by Strunk & White; if you do own a copy, either have
it at your desk so you can use it, or give it to someone who will. Effectively communicating
with humans, using their rules, will help you have better testing, better design,
better requirements, and have a better job. Become an effective English developer,
and it will help you be a more effective developer, overall.
