How exactly does software spread?

Author | HILLEL WAYNE

Translator | Meniscus

Listing | CSDN (ID: CSDNnews)

Recently, my job is mainly to research foreign software technology and sell it to various companies, which means I am a software disseminator. So, I started thinking about what "Evangelist" (also called "Evangelist") really means.

A lot of people have a certain misconception about the work of evangelists: The culture of software engineers looks down on evangelists and considers these people untrustworthy. I believe they have their reasons. Since communicators are blamed more than encouraged online, it is a pity that the working skills of a community theory communicator are not available.

So, most of my working principles are not learned from other places, but based on my own experience. At work, I need to convince people to adopt fringe, high-risk, high-reward technologies, especially formal methods. Although I don't have the backing of the company behind me, I can rely on my personal reputation and sometimes people see my name and read material they would otherwise skip. My client base is developers, not CTOs, project managers or other positions. All of this affects how I view communicators, and people from different backgrounds may have completely different views.

Since I have not done a systematic summary, this article only describes some personal experiences.

1. The goal of the communicator

Change the way the community thinks about something, like a product, process, language, and more. You can spread the word about agile development, testing, Clojure, MongoDB, functional programming, the use of dev/urandom, and more. I call the dissemination object the subject.

All my work can be roughly divided into two categories: interpersonal and output. Relationships refer to building good relationships with various teams and individuals; outputs refer to material written to change a culture, including speeches, essays, projects, presentations, and especially “viral” tweets. In this article, I’m not going to discuss relationships because it’s hard enough to convince people that the communicator’s job is meaningful, and I don’t want to rant. So, assume for the moment that the job of the communicator is just output.

2. Groups

Imagine that every developer has a "cutoff point" that can be persuaded. The size of this threshold depends on a variety of different factors: problem domain, workplace, personality, background knowledge, past experiences, relationships, etc. While we can predict the influence of some factors, the overall thresholds vary widely. One person might be very interested in a topic, while another person on the same team, even working on the same job, might have a completely different interest.

This results in very low efficiency in personal communication. In contrast, dissemination to a certain group of developers will be very efficient. Note that people with a lower "threshold" are receptive to your output, while those with a higher "threshold" will not resent you. You don't know who will listen to you, but you know someone will listen, which means you've succeeded.

Over time, you'll get better at spreading technology to groups. First, you can spot patterns in which people listen carefully. Primarily junior developers, enterprise C# developers, academics, or someone else? These patterns can serve as a guide for future work. Second, you'll see more "threshold" effects. This "cutoff" is not a number, but the interaction of many different factors, some of which you can directly influence. For example, if people are resisting because a topic is too theoretical, you should provide practical examples and case studies; if it's because the infrastructure is bad, try to improve; if the output doesn't fit the audience environment, you need to find more practical topics.

3. Trust

The core of the communicator is to manage trust. To convince people, first they need to trust you. The best way to gain trust is to be trustworthy. There are two main types of trust:

• Your expertise can be trusted: your judgment on the best approach is correct.

• Your opinion is trustworthy: you are not deceiving others in your judgment.

Therefore, in order to be a good communicator, you must have solid professional knowledge and at the same time be honest and trustworthy. The latter introduces an important principle of communicators: objectivity.

4. Objective

The communicator must be as objective as possible.

While it is very important for communicators to remain objective, it is almost impossible. Your goal is to sell a product, how can you be objective?

We can use the most direct way to defuse this conflict. While we cannot be objective about the products we promote, we can pick and choose quality products (from an objective point of view). Our focus should be on deciding which product to market, not how to market a low-quality product, which amounts to a scam.

I teach TLA+ and Alloy courses because I believe they can revolutionize our industry. If I lose faith in them, these courses will not be taught.

Remaining objective may limit the choice of topics, but also the environment in which to work. Being objective means telling the truth: "This tool isn't right for your job, and you don't need it." Or, "While this tool is generally useful, your work environment seriously affects its performance. role." Even said, "I think another solution is more suitable for you."

Still, being objective is still well worth it. First, you can always stick to your principles. If you can't identify with a product in your heart, it's hard to sell it. Second, being objective can earn you more trust. If you're willing to tell the truth: "This tool isn't for you," people will believe you're not lying when you say, "This tool is for you."

You should understand not only the pros but also the cons of the subject. There is no free lunch in the world. If you can't tell the problem with the subject, then you are not objective enough.

5. Quality

When exporting, you often need to balance quality and quantity. Which way do you prefer: write lots of articles, or focus more on quality? While we want both, time is limited.

For someone who is just starting a blog, generally I would recommend ensuring the frequency of posting. It is easy for newbies to fall into the trap of perfectionism, where they will revise again and again and be slow to come up with an article that can be published. But quality has a bottom line. Sometimes, I also see the other extreme, someone who insists on winning by quantity. As a communicator, you are the representative of a topic, and the quality of your output affects not only how people perceive you, but also how people perceive the topic.

The easiest and most important way to improve quality is iterative revision, but it's also the most painful. Even modifying it again the next day can greatly improve the quality of the output. Better yet: revise based on feedback from the draft. Most of my blog posts are revised 4-5 times before they are published. If your output is a speech or video, it may not be possible to modify it repeatedly.

When modifying the output, don't be afraid to cut. It's perfectly fine to delete entire paragraphs for brevity. Of course, you can also just take out the three paragraphs you like and delete the rest. You can even drop a piece entirely and pick it up after a while. Or simply leave it behind. Even if the new draft does not use a single sentence or word from the old draft, it is lifted from the ashes of the old draft.

6. Diversity

It's more of a specific technique than a principle, and while I don't know if it's universal, I think this topic is worth discussing.

Every few years, there's a war between the Haskell and Clojure communities. In 2018, a battle erupted on Twitter after Rich Hickey's "Maybe Not talk" angered many Haskell fans.

Since then, whenever someone gives a Haskell talk at a Haskell Symposium, LambdaJam, or other conference, Clojure is bound to be mentioned.

If your life revolves too much around one theme, then it becomes disconnected from the rest of the software. This causes your trustworthiness to drop because you lack basic objective knowledge. Although your opinions are sincere, there is a lack of expertise.

Therefore, in order to enrich our knowledge, we need outputs in addition to the disseminated topics. This can show that you have a broad exposure to software, and it can also help you reach out to a wider group of people. As far as I know, part of my audience finds me through the articles I write about the history of software development.

Finally, variety can also increase your trustworthiness. There is a difference between having expertise and people believing you have expertise. Not everyone is good at assessing expertise in a new area, such as your subject. How can they tell that you are a real expert and not talking nonsense?

It would be helpful if you could find something they could understand and agree with. They'll tell you how hard you should try to master topic X, or ask some questions about topic Y. While not perfect feedback, it's better than nothing.

In addition, mastering a variety of knowledge will give you a sense of accomplishment and improve yourself. In addition to spreading themes, you can also develop your own hobbies. You can write about your favorite technology!

7. Some ideas

While writing this article, I noticed that many principles are actually ways of accepting oneself. In order to be a good communicator, first you need to love the profession. If you're not satisfied with your work, you won't be able to stick with it for long, whether you're good at it or not. So, in the process of spreading the software, you need to recognize your own identity and ethical standards. In my case, I want to be honest, objective, and purposeful. I can imagine that everyone's concerns are different, and in order for everyone to accept the communicator, they will also propose different principles.

Reference link: https://buttondown.email/hillelwayne/archive/principles-of-software-evangelism/