Much like code smells, there are conversation smells. Words that should be a red flag, words that often indicate something bad is happening. Here are some words I watch out for in dev meetings.

Obviously

The fastest way to shut someone down is to make them feel stupid. Saying “Obviously” prevents me from asking questions about what you said. If it’s not so “obvious” to me, maybe I’d like to dig a little deeper - but you’ve set up a situation where I look stupid in front of the group because I can’t immediately grasp the full meaning of what you said.

Drop this word entirely.

Just/Simply

These words hide and trivialize work. “Let’s build a private cloud” vs “Let’s just build a private cloud” - VERY different tones to those sentences. The second one, said casually, makes a private cloud sound like something you could knock out in an afternoon. It subliminally encourages my mind to gloss over the content of the sentence and focus on bigger problems. Estimating the size or duration of a project is such an important, difficult, hot-button part of a dev meeting. Making glib, offhand remarks about size/duration leads to a cavalier attitude about estimation and pre-empts the serious discussion that should happen about building that private cloud.

If I catch myself saying one of these I’ll usually stop mid-sentence, call myself out (“I shouldn’t say ‘just’") and restart the sentence.

Easy

“Easy” is a statement about time masquerading in a statement about complexity. When I say “it’s easy” what I mean is “as far as I know there are no significant barriers”. What people often hear is “fast”. There are two problems with this. First, I’ve seen too many “easy” projects rabbit-hole into three week slogs to be comfortable calling ANYTHING easy until it’s done. Second, when you start describing your work with “easy” people start asking you about it in the same manner. “Let’s build a private cloud - is that easy?” Now you’re stuck answering a yes or no question about the timing of a very complex feature.

Use “straightforward” in place of “easy” to keep the conversation focused on complexity, not time.

Assume

As the old adage goes, “when you assume you make an ASS out of U and ME.” Assumptions are an unavoidable (and perhaps even invaluable) part of programming. But that doesn’t mean you should make them lightly. Every assumption is an opportunity to make a mistake in judgement that will continue to compound throughout your codebase.

If you catch yourself using “assume,” take a minute to validate or at least think critically about the assumption.

Can’t

Really? You CAN’T? Or you don’t know how, it would take a long time, cost too much, you don’t want to, there’s no ROI, etc etc? “Can’t” is a cop out. Nothing is impossible, but there are good reasons not to do a very large number of things. Also, saying “can’t” too many times is going to ruin your credibility. No one likes a pessimist or an incompetent.

Be more specific.

Pop

Asking for a design element to “pop” has become a running joke among designers, and for good reason. Design is not about individual elements, it’s about the relationships between elements. Asking for something to “pop” more ignores those relationships. By saying only “this thing is important” you’re reducing your UI to two levels, “pop” and “unimportant”. Anything unimportant should probably be removed, so you’re left with only “pop”, and everything important cannot “pop”. “Pop” is a warning sign that belies narrow focus. You’ve lost a holistic awareness of the design and information architecture of your project.

But wait — you’re having an honest reaction to a design. That’s great! You’re halfway there! Take a step back and think how this particular element fits into the grand vision for your project.

Rephrase your feedback in a larger context. For example, instead of “Can the text pop more?” try something like “The white text is explaining our holiday offer, which is the whole point of this page, but over the light background image it’s hard to read. How can we balance the visual impact of the image with the importance of people understanding the details of the offer?”

Others?

Let me know on twitter if you have something to add to the list!