How to Read First Impression Posts

Rust gets a lot of first impression posts. For people in the community, reading those posts can often be frustrating, with factual errors leaving people concerned that others will get the wrong impression. For people outside the community, they may be unsure of how much said is true, or how to read these posts effectively. In this post, I outline how I think about first impression posts, and why I recommend reading them the same way.

Info 1 This isn’t Rust-specific

Most of what I’m writing here isn’t specific to Rust; it’s true for anything! Given that, this post is not written with Rust-specific language.

I’d summarize my view as follows:

First impression posts will make factual errors.
If you’re in the community, treat those errors as an indicator of what and how someone has learned, and look for opportunities to help others learn better.
If you’re outside the community, take a first impression post with a grain of salt, but watch the community for how they respond to it, to see how they’d treat you when you get something wrong.

First Impression Posts Will Make Factual Errors

The first item ought to be obvious. Someone who is brand new to something is likely to make incorrect statements about it. They may even be confident in stating their incorrect thing! Unfortunately, some may disbelieve that they’ve misunderstood or missed anything, which may cause them to write very authoritative-sounding but absolutely incorrect or at the least debatable statements.

No one is immune to this challenge. Even very experienced programmers, people you may take to be experts in the field, are highly likely to say at least one wrong thing in their first impression post unless they are very explicitly careful not to, perhaps by consulting with a friendly expert to proofread prior to publishing. The nature of learning something new is that you don’t know what you don’t know, and a big part of learning a new language is intuition building. We come to languages with the knowledge of our prior languages, and are very likely to make assumptions or determinations about how something works by bringing along knowledge of other languages. This often doesn’t quite work, because every language is different!

If You’re in the Community…

Aside 1: Limits of Language Analogies ↺

Programming languages are complex constructs involving fundamental trade-offs on a number of goals and design axes. These trade-offs are interrelated, which generally means a feature in language X is unlikely to look or work exactly the same in language Y, due to its interactions with other features in each language.

This makes requests to “just add M exactly how language X does it, because it’s perfect” often reductive or hard to discuss. A feature can feel natural, perfect, exactly right in one language while being impossible or out of place in another.

When learning a language, this also creates challenges for learning by anology. Features may have the same names in multiple languages, but work differently in subtle ways.

So be careful when comparing languages in this way, or requesting (even demanding) the introduction of a feature you like in another language. Remember it may not be as simple as “do it in this language too!”

If you’re knowledgeable about something, and you see someone without much knowledge in that thing spouting off incorrect information about it, particularly if that incorrect information makes the thing look bad, you may understandably get defensive.

“That’s wrong!” you may shout. “This feature doesn’t work like that at all!” or “The design you’re suggesting wouldn’t work in this context because of X and Y issues!” This can feel good, and right, as you fight with this interloper for the attention of the audience. Your fear, in all of this, is that they will be poisoned against your topic or tool by misinformation, and worse that this misinformation will spread and limit the reach and potential of this thing you’ve invested your time and attention into.

I know it may be hard, and the smack-down of telling someone they’re wrong may feel good, or even sometimes righteous, but please don’t do it. Please do not talk down to, harshly correct, or insult someone being factually wrong in a first impression post. Please don’t do it even if they’re rude, obnoxious, or insulting to you, the tool, its creators, or its community.

When you do that, no matter how righteous you feel, you are showing others how your community accepts criticism, and telling them that you may respond to it with vitriol. This is not a good look.

Alert 1 One Major Exception

However, there is one large caveat to this: do not accept, ever, for any reason, content in the spaces you control which excludes or harms others, and do not affirm abusive behavior brought in from spaces you do not control. I am a firm believer in the value of Codes of Conduct, and in the belief that free speech absolutism serves to exclude those without power, who will feel and often be left unprotected against the rage of those with power.

This is not to say that you should let factual errors stand. You absolutely should correct factual errors, but do so in a way which welcomes people to learn more, and withholds judgment towards individuals who have made a mistake.

You can also use these posts as an opportunity to question why someone reached their incorrect conclusion. How did they approach learning your tool? Are there changes you can make to help others select a better path to learn in the future, or to improve the outcomes of learning along this person’s selected path? Take their post as feedback, and try to identify valuable changes from it. Look at collections of these posts as a whole to identify systematic learning failures which may help guide documentation and teaching.

If You’re Outside the Community…

If you’re outside a community, and you see a tool or topic being discussed in a first-impression post, your challenge is generally to sort the true from the untrue, the opinion from the fact. Depending on how unfamiliar a topic is, this may be very difficult to do. If a topic is very far outside of your knowledge, you may be best off keeping to sources which are already expert on it, which can present you both with the best view of its proponents, and an honest assessment of its limitations from people with enough understanding to identify the important ones.

However, there is still value in any first impression post if you’re in this situation, because it tells you how that community handles errors. It shows you how you may be treated in the future if you get something wrong while learning that tool. If you observe the community mocking and belittling the poster, you may rightly think twice about learning the tool.

Tools don’t exist in isolation, they exist in a context of their documentation, their support, their community, and so much more. When you learn a tool, you become engaged with that full ecosystem, and so it is fair and reasonable to consider how that ecosystem will treat you.

Conclusion

First impression posts are a valuable part of tech communities. We have an open culture where people are generally able to and encouraged to share their thoughts, even if those thoughts are half-formed. This is a good value, but it must be accompanied with an understanding of how to treat those who go through this process, and with an eye to how to best use their feedback constructively.

Possible Rust

Possible Rust

Categories

Tags