The Language of “Helping”

A decade ago, finding answers to tricky programming questions was a massive headache. Searching forums for hours on end, learning entire new languages to solve one problem; it was incredibly stressful. Then along came Stack Overflow. We found and gave answers to some of the toughest problems. To this day, a week doesn’t go by where I don’t comment on an answer with something along the lines of “OMG you just saved my ass!”

I’m a relatively active Stack Overflow user. For the first two years or so of its existence I spent at least an hour or two every day searching and answering questions. Browsing my questions over time will give you a pretty accurate view into what I am working on (or learning) at any given time.

These days I’m in the top 1% of users based on my “reputation”. That may sound impressive, but this is certainly not a reflection of my prowess as a developer. Take for example this foundational question I asked when I first started learning Objective-C in 2009:

“Are there any shortcuts to (stringByAppendingString:) string concatenation in Objective-C, or shortcuts for working with NSString in general?”

The up-votes on that question are currently worth about 4,500 points of my total reputation gained for what is now—to me—a very basic question. So, lesson one: programming prowess isn’t about rep, stars, or contributions. You don’t know what anyone knows or doesn’t know until you work with them, so cut everyone slack by default. I feel confident in the certainty that the some of most accomplished developers in our industry do not use Twitter, don’t write blogs, and—shockingly—don’t have a GitHub account.

Keeping in mind that—on the web—we don’t really know each other that well, I find it important to remind myself of words we often use in programming (or any pursuit, really) that can be disconcerting and potentially even harmful to folks learning at any skill level. After over a decade solving tough problems, I am quite confident with my skills, but it’s great to remember that we are all at different points in our lives/careers, so the language you use to talk to a long-time pal should be explicitly different from the language you use when speaking to the generic programmer.

Here’s some of the words I try to be careful with when I talk to other developers, in person or online. One will never be perfect, but it doesn’t hurt to try.

“Simply”

This wording implies that the solution is “simple”, but the simplicity of implementation is relative to the questioner’s experience; the “simply” here implies that you as the answerer consider solving the problem in question pretty easy.

I struggle when I see this myself quite often. Those feelings of doubt start to creep in when you aren’t able to quickly comprehend something that someone describes as “simple”.

Recommendation: remove “simply” from your answer nomenclature unless it’s indicative of actual brevity. If we’re serious about simplicity, let’s remove extraneous words in our answers.

For example, here’s an example where “simply” doesn’t improve our answer:

Simply add a BOOL that you check in touchesMoved and reset in touchesEnded.

And here’s an example where it does:

[To get the current webpage URL], use window.location.href (or simply location.href).

The first implies that the implementation of the solution is easy, the second uses simply to contrast two snippets of code, one more concise than the other; the judgement there being about the code, not the difficulty to the generic programmer. I ask you, is this answer any less effective than the original?

Add a BOOL that you check in touchesMoved and reset in touchedEnded.

“Obviously/Clearly”

Looking back through the history of programming, it seems clear that most people can agree on single inheritance. But if there had been a clear winner among the myriad approaches to multiple inheritance I think it would have become common by now.

The Answerer here starts with the assumption that Questioner has been around for the entire history of programming and/or that they’ve the same experience to draw from as they themselves do. Take away the context of an encyclopedic knowledge of programming; with little to no prior knowledge, it isn’t clear that people have agreed on anything. Perhaps the questioner hasn’t reached that point in their learning and have yet to conclude that “single inheritance” is indeed the way to go.

Furthermore, by stating that it should be common knowledge, they’ve also implied that Questioner is “less than” because they didn’t know the facts. This inference can often feel exclusionary and even condescending. Taking into consideration the famous idiom “there’s no tone on the internet”, all we have is our words, so our word choice will be extremely impactful.

Recommendation: don’t assume prior knowledge. Attempt to discern the experience level of the person asking and their familiarity with programming or the domain itself. Don’t shut down a potential teaching experience because you assume the concern is “common”.

“Seriously”

You didn’t seriously copy & paste the function, did you?

Somewhat beyond belief, many answerers will provide a fantastic answer to the original question, but feel the need to belittle the original poster by injecting a not-so-subtle jab at their ignorance. The assumption here being that we’re all at the same phase in our learning, so a mistake like “copying and pasting a function” needs to be called out as a stupid move. Does this comment add value to the answer?

Added bonus: this answer was from a Stack Overflow moderator.

Recommendation: just don’t do this. Answer the question without the value judgement.

Why our words matter

When I wrote our technical specifications at my previous gig at Typeoneerror, I utilized NASA’s “Writing Effective Requirements Specifications” guide to ensure I was being clear and specific with my imperative usage. The guide makes distinctions between strong and weak words and recommends the following:

Avoid fuzzy words that have relative meanings such as “easy”, “normal”, “adequate”, or “effective”

For example, consider the following statement from an old proposal:

If user has connected their game to Facebook, they may be prompted to share their score on Facebook.

Here I decided to use may (instead of shall or will), because I wasn’t entirely sure (at the time) whether the Facebook’s app functionality would support this user interaction as we were proposing. Using a weak imperative here allows us some wiggle room with our budget/scope, and ensures that we are not explicitly dictating functional requirements in this case via our language choice.

These NASA docs convinced me that, when I don’t have control over the delivery via the tone of my voice, I need to be very selective about my word choice, because a single word difference can have incredible impact.

Interestingly, we also see how much importance NASA places on avoiding the use of “Weak Phrases” (of which “Simply” & “Obviously” can likely be included):

Weak Phrases is the category of clauses that are apt to cause uncertainty and leave room for multiple interpretations. Use of phrases such as “adequate” and “as appropriate” indicate that what is required is either defined elsewhere or, worse, that the requirement is open to subjective interpretation. Phrases such as “but not limited to” and “as a minimum” provide a basis for expanding a requirement or adding future requirements. The total number of weak phrases found in a document is an indication of the extent that the specification is ambiguous and incomplete.

And look who’s there in our list of weak phrases to avoid—it’s our old pal, “easy”; brethren of “obvious”, sistren of “simple”.