Programmers have different sayings about difficult problems. Probably my favorite option : “There are two difficult problems in computer science: cache invalidation, naming and error per unit.”

I have been writing software long enough to face each of these problems. At the same time, I speak from the side of business and explain to customers the technical part of our product, therefore I constantly encounter non-programmers. The most important thing is to correctly convey the idea or concept in such a way that others understand it.

And this is very difficult.

As in all professional fields, programmers have developed their own jargon for quickly transferring concepts.

Technolepet

Jargon is very important. If my colleague and I choose an algorithm to solve a specific problem, we can say that "the first option O(n^2)with minimal overhead from the start, and the second is depreciated to O(n log n), but with expensive installation and configuration . "

This single sentence says a lot, for which scenarios the algorithm should be used and how they are implemented under the hood:

Option A is great for a system with a small amount of input.
Option B is great for working with a really large amount of input data, where the high costs of installing and configuring the system will be offset by better performance in the process.
If you intend to use the algorithm in a loop, you should choose the first option to avoid the expensive installation and configuration code.
Perhaps we can reduce the cost of installing option B using caching.
Probably, in option A, each element of the input data is compared with all the others (for example, for x in inputs { for y in inputs { if some_condition(x, y) { ... }}}).
Probably, option B first creates a tree, then performs a linear search, followed by a search in this tree.

As you can see, we were able to convey several paragraphs of information in one sentence, simply using the correct terms.

In this case, I meant algorithms for detecting collisions, that is, intersections between two or more objects. The first checks all possible combinations of input data, while the second uses a quadrant tree or a binary space partition to check only close elements.

But if you have a meeting with people from outside the programming world (for example, mechanical or electrical engineers, managers, marketers), this technical jargon will only insult and confuse people, without transmitting almost any valuable information.

This is what I call technoleth, the mumble of a programmer.

Frankly speaking, usually these details and terms are not needed by people from other areas, and they really do not care.

For example, you are explaining an amazing new function that finds the shortest path from A to B, generating a navigation grid and applying A * search .

In no case do you need to describe the new function as in the previous sentence. Instead, say something like this:“We compute a bunch of possible paths, and then apply the smart algorithms that are used in the gaming industry to find the best route . ”

It doesn’t matter that we are using the A * search here (unlike the Dijkstra algorithm or the width search). It doesn't matter that in games, A * search is used not only to move characters. It is enough for the interlocutor to know that you can find a good way from A to B and that we use reliable tools that have already been tested in other areas.

It does not hurt to show the illustration of what you mean ...

I happened to observe how more experienced programmers use tech-jargon to demonstrate superiority, to show their incredible intelligence and establish dominance. This is really annoying.

Do not get it wrong, sometimes there are situations when a sufficiently competent interlocutor asks: “This is very difficult, why not just make X?” - and you have to show that you are an expert here, but he does not know what he is talking about ... but you can still do it in different ways.

Do not try to use technolepet to satisfy your ego, it ostracizes people and dishonors our profession.

Respect

So we gradually move on to the next point ... do not forget about respect.

Many people with whom I work are really smart and experts in their fields, but not necessarily they have enough knowledge and experience in creating information systems.

When explaining a complex problem, it is often better to simplify concepts. But try not to be condescending.

The software engineer that I mentioned about often answered: “It's ... complicated” when a “normal” person asked how this or that function works. It’s as if the code is so sophisticated that without 20 years of programming experience you cannot understand it.

Do not do like this.

The best answer:“If you simplify things a bit, then first we do X, then we do Y, and finally we do Z, but you need to keep in mind a dozen border situations (perhaps explain one or two), but the essence is this . ” Your colleagues are smart and without techno-jargon are quite capable of understanding you.

Another really useful trick is to use a non-programmer as a deck, like a rubber duck. If you are working on a complex problem, explain to him in simple words your solution and ask if you can come up with a better option.

Our company works in the field of CNC, that is, it has something to do with the real world (for example, when you try to implement compensation for the width of the cut ). Engineers are really good at analyzing problems related to physics and geometry.

Personification, exaggeration and analogy

People are social beings. We are programmed to understand relationships and love analogies to relate new concepts to existing ones. When you are talking with someone, you can use these tricks to help you understand complex topics.

Say your company has an online procurement system. The marketer wants to understand the whole chain from the online order to the delivery of the parcel in order to better answer customer questions. I could say something like this:

, . www.example.com, «» ( -, ).

(-). , () . , , , (, ).

( ), , . , , ( — , ), .

( ) . , , .

All this sounds a bit comical, and the example is more than far-fetched, but I can guarantee that this is a more understandable explanation than a large network diagram with the terms “web server”, “event architecture” and “Apache Kafka” (see the section on technolepte )

Another example. If you try to explain to an outsider how the path search algorithm works, you don’t say “visited paths are given more weight”, you say “the algorithm really doesn’t want to go along the paths where it already went.”

This is a subtle difference, but we are doing the personification of the algorithm. We say that he “really wants to make X” or “try very hard to avoid Y”. Often this helps people just understand .

Useful analogies with examples (if appropriate). You have probably already noticed that this article is full of examples. Instead of an abstract explanation, I tell specific stories that help explain the thesis. This is not an accident.

Draw beautiful pictures

It sounds corny, but sometimes a picture is really worth a thousand words.

A couple of months ago I was reading a course on the radio, and the girl nearby couldn’t remember which buttons to press on the menu of this small 16 × 2 LCD.

I asked if she could draw a diagram.

She thought that I was a smart guy and scoffed at her.

But I was not joking.

Instead, I found a piece of paper, and together we made something like this:

The programmer immediately recognizes the state diagram from the theory of automata. Unbeknownst to a girl, I introduced the fundamental computer science technique into her brain and how the interface of this radio is programmed under the hood.

But she (and everyone else at this stage) doesn't give a damn about science. They got a map that they can use to navigate the user interface.

There is some strange pleasure in adapting a complex concept for someone from another area. Especially when they can determine that the map is really a bug: you need to press and hold the Cancel button to return to the Idle state, because pressing this button normally returns you to the "Main Menu".

I always have a large notebook with blank sheets on my desk. Usually I write down a to-do list or some drawings during reflection, but often it helps in explaining. The ability to draw something during a conversation helps to verify the course and make sure that you are on the same wavelength (pun intended) that you have the same idea.

I accelerated $ FEATURE tenfold

Suppose you made some performance adjustments, and now a certain piece of code works much faster. How to explain this to a non-programmer or someone who does not see the source code?

On the one hand, to the question of what you did last week, you can tell the person the truth: “I added caching to lookup_something ()to speed up the general search and translate the algorithm from detect_collisions()c O(n^2)to O(n log n)” , but with a high probability they won’t understand anything (see technolept ) .

You can also say that you “optimized productivity” , but it sounds like an excuse, and the manager will think about why he hired you.

Often, developers say, "I accelerated $ FEATURE tenfold."(or some other arbitrary number) and this is limited. Such a phrase allows you to enjoy a bunch of congratulations from the townsfolk, but often it is a little ... misleading.

In most cases, you actually improved the performance of several functions, but if these functions were not a performance bottleneck, then with a high probability no one will see any difference.

Note. If you are familiar with Amdahl’s law, then increasing the performance of a function that is not a bottleneck is like using more CPU cores for a task that is essentially consistent.

The question also begs: what have you done to increase productivity tenfold? Is this a surprisingly specific number, has your source code repeated one work several times? Or did he request data (say, from hardware or some third-party site) ten times slower than it should? Even this makes me doubt your abilities, because you either guessed (poorly) the initial polling speed, or you still sacrifice performance by using polling instead of a more efficient event architecture.

It seems to me that it is better to try to find a middle ground between accuracy and comprehensibility. If you made a change that improves the algorithmic complexity of a code fragment (for example, a function detect_collisions()switched from O(n^2)to O(n log n)), then you can say:“Function X can now scale to a large amount of input in a reasonable amount of time, but could not before . ”

It’s normal to say “I don’t know” ...

... and continue like this: "... but if you give me five minutes, I can tell you" .

I often see this. People are afraid to show their ignorance, therefore they are silent, tormented or invent something.

For example, if a manager comes to you and asks: “The client asked for function X, is this possible? And how long will it take? ”

In nine cases out of ten, the honest answer is “I don’t know,” but it doesn’t really help the manager decide the timing. He turned to you because you are an expert in the relevant field and are best prepared to give an answer.

Some try to guess or cheat (for example, “Yes, we’ll do it in two to three weeks”), but this approach usually does not work in the long run. In the best case, you will be delayed for a couple of weeks, and in the worst case, spend months working just to find out that this function cannot work with the current application architecture.

This is a great way to lose the respect of colleagues and superiors.

On the other hand, the words “Not sure, but give 5-10 minutes, and I will have an answer” shows several things at once:

You are ready to admit that you do not know everything (that is, not a narcissistic egoist).
You are responsible for your words and do not want to give an inaccurate answer.
You respect the person enough to spend part of your time helping to answer his question.
You're a good guy :).

(And you get enough time to figure it out).

It resembles an old parable :

Other people (usually) do not expect you to know everything in their field. Instead, they expect you to have tools to research the question and translate the answer into terms that they can understand.

The old engineer retired, and after a few weeks the Big Machine broke down, which is very important for the company's income. The manager was unable to get the machine to work again, so the company invited the old engineer as an independent consultant.

He agreed. Arriving at the factory, he looked at the Big Machine, took a sledgehammer and hit it once. After that, the car started working. The old engineer left, and the company began to make money again.

The next day, the manager receives an invoice from the old engineer for $ 5,000. The manager is furious and refuses to pay. The old engineer assures that this is a fair price. The manager retorts that if this is a fair price, then you can ask for details of the account.

A new, detailed account looks like this ...

Hammer: $ 5

Know where the car hit with a hammer: $ 4995

Anyone can google any question. But only a software engineer knows which keywords to use and how to interpret the results.

findings

Usually on my blog I publish purely technical articles with tons of code, but sometimes it’s useful to remember that there is something else in this world besides code.

Programmers (not without reason) are perceived as people with weak social and communication skills. But a significant part of our work requires effective communication. I hope my experience will help you with something.

Some may consider this to be “office politics” and the manipulation of other people's opinions. Here is what I will answer:

Well yes. But does this not apply to most interpersonal interactions?

Psychology simply helps programmers speak the same language with non-programmers and work together to achieve a common goal.

Talking is hard. Essays on Communicating with Non-Programmers