A short review on “The Madness of Crowds” by Douglas Murray (2019).

I have read the “Madness of Crowds”. It is a book about several kinds of inequalities in the society, to which a lot of effort has been paid in order to compensate for them, and although up to a certain point a lot of this effort paid off, recently the effects became more controversial than working.

Douglas discusses four big (in the amount of text dedicated to them) inequalities, and many more small ones.

I think that the main point that should be taken away from the text is that much more thinking needs to be done before deciding on an important issue, even if this issue may seem perfectly obvious to the referential group. If someone is offering you a “clear solution” to an issue, doubt it even if it is a direct extrapolation of the solution to the same issue as it used to be in the past. Doubt it if is the same solution to a different issue, no matter how similar it may look. Doubt it in any circumstances.

Another thing that I take out of his book is: read the classics. Not the classical fiction, but the classical thought. The older guys, like Democritus, Protagoras, Plato, Aristotle, Socrates, Confucius, Babylonians, they have been outdated and superseded… but it is astonishing to see how slowly the process of change goes in the human nature, compared to the human tools.

There is also one thought that is not terribly new, at least I heard it several times from different people, but which, I tell myself, is worth repeating. When listening to people giving advice, try to distinguish the people who are giving you good advice because they want you to become better from people who give you bad advice because they want you to fail.

The book is not too long, a native speaker can probably get through it in a couple of evenings.

Contacts

Subscribe and donate if you find anything in this blog and/or other pages useful. Repost, share and discuss, feedback helps me become better.

I also have:

Facebook

http://facebook.com/vladimir.nikishkin

Telegram

http://t.me/unobvious

GitLab

http://gitlab.com/lockywolf

Twitter

https://twitter.com/VANikishkin

PayPal

https://paypal.me/independentresearch

Advertisement

A review on “Psychology of Intelligence Analysis by Richards J. Heuer Jr.”

Abstract

Richards J.Heuer Jr.is one of the people who revolutionised the way intelligence content is produced in the Central Intelligence Agency of the U.S.A. Speaking crudely, his main contribution was the introduction of the “Scientific Method” into the everyday routines of the CIA analysts. This book is partly his self-reflection on this transformation, and partly a list of heuristics that any intellectual worker could employ to improve his own efficiency (and self-satisfaction). I found it very good. It clarified quite a bit of concepts I had been only vaguely aware of, and helped me hone a few of my own ideas.

I actually recommend reading it to everyone, and perhaps would even suggest studying it at school, because it is hard to find a skill of more generality than a skill of thinking. And the intelligence aroma just makes the book more exciting for kids.

If you are interested in more detail, welcome under the cut.

The Futurological Congress by Stanislaw Lem

Read it if you haven’t already. Re-read otherwise.

It is a great text. The book is short, it’s just a little over 260 kilobytes. I actually read it at school, but forgot almost everything. I guess, I was not old enough at that time to appreciate the complete sense of the book. Lem is a genius, obviously. And in addition, the book is the only thing I remember about my high school history teacher Markelov, besides trying to test “digital learning materials” on our class, and trying to convince me that mentally ill people are beyond help. But the book suggestion was good.

I particularly liked the sarcastic depiction of an imaginary “scientific congress” consisting of people whose complete lives consist of travelling from a conference to a conference. I liked the reference to the prevalence of sexual themes in the “liberated” culture, all too common nowadays.

The reference to the overpopulation turned out to be completely wrong, the world population growth seems to be decelerating, but many of his other prophecies seem to be still plausible.

I believe that the reference to the domination of the chemically-induced virtual reality should be taken metaphorically. I doubt that drugs can make you feel that much of a difference with the real life. However, the reference to the sheer amount of drugs in our life in the not so distant future is probably correct.

Rioting is included.

I really liked the reinforcement of my conspiracy theory that the government is putting sedative medicine into the tap water, just to make the population less critical. The reference to the illicitness of negative emotion display is also happening already in our life. The language discussed in the “far future” part of the book is a nice try to imagine how the language is going to be changing, and how it may be affecting the dominant philosophy.

Briefly, irrespective of the anti-utopian scent (common to so many futurological works), this book reinforced my optimism and the belief in the progress and the bright future.

Contacts

I also have:

• Telegram: https://t.me/unobvious
• Facebook: http://facebook.com/vladimir.nikishkin
• GitLab : http://gitlab.com/Lockywolf

A short review on “The Culture of Chinese Communism and the Secret Sources of its Power” by Kerry Brown

Abstract

Kerry Brown is a well-known scholar of Chinese culture. The Communist Party of China could not have avoided his attention.

I have read this book at a book club, and would like to share some of my impressions.

Proposing programming language features

This blog hasn’t had enough attention for quite a while. This is not, however, because I have abandoned it, but rather because the original purpose of this blog, that is dumping essays regarding books I read, is still valid. It’s just that the most recent book has taken an order of magnitude more time than I had expected it to take.

Okay, I’m going to write a bigger and better review on the “Structure and Interpretation of Computer Programs”, but the book altogether took so much time, effort and emotions, that even writing the review is going to take a while.

Meanwhile, one of the by-products of my reading happened to be a proposal of a feature to be included into the Scheme Language, that is needed in order to support all the code examples in the book.

(Yes-yes, you’re not misreading it. The book published in 1996 is _still_ not covered by the existing language standard in full. Otoh, it means that there is a chance of achieving things.)

Now that the proposal has an official number, there is going to be a public discussion among the potential Language System providers, and maybe (if it passes the review), we will have this feature officially recognised.

Watching discussions of experts on what they may actually work themselves is a fascinating experience, and a chance to improve own skills too. In this case the discussion is not expected to be too heated, however, but anyway.

https://srfi.schemers.org/srfi-203/ — this is the link to my recent proposal.

It speaks about quite an interesting approach to generating computer images, that builds on top of the classical features present in most drawing languages, such as PostScript, TikZ, MetaPost or SVG. While the expressive power is largely the same, the degree of abstractness is greater, which leaves gives greater code reusability and flexibility.

Scheme is by not means the only language that has a community feature review process.

• Python has Python Enhancement Proposals (PEP)
• Java has Java Community Process (JCP)
• Scheme has Scheme Requests For Implementation

The image in the header is a digital copy of a work of M. Escher, whose works have inspired the original author of the “Picture Language” Peter Henderson. http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.137.1503

A Review on The Light That Failed by Ivan Krastev and Stephen Holmes

I have read “A Light That Failed”. This review is not a part of the series of reviews on technological books. Nevertheless, in order for a brain to keep moving, some humanitarian reading is advised.

This book was a part of a book club in discussion in Shanghai. Speaking briefly, it discusses the new (2019) tendency in politics in which the western politicians start using the rhetoric that they have not been using so far; the rhetoric that is not unlike the one used by the authoritarian politicians. Surprisingly, the book is known among readers in China, it has a rating on DouBan. The book is not related (at least, directly) to the eponymous novel by Rudyard Kipling. The book is not related (at least, directly) to the eponymous film of 1939, based on the work by Rudyard Kipling.

A Review of LiShan Chan’s Philosopher’s Madness

I have read the “Philosopher’s Madness” by LiShan Chan. It is a book about mental illness, British Education, academic careers, their successes and failures, Overseas Chinese, Singapore and Dubai, writing and reading.

This review is not a member of the technological book reviews series.

If you are still interested, welcome under the cut.

A Review for GNU Autotools by John Calcote (1st. ed.)

/ I saw a book titled ≪Die GNU Autotools≫ and I thought “My feelings exactly”. Turns out the book was in German. – Tim Martin./

I have read the GNU Autotools: A Practitioner’s Guide by John Calcote.

This is a small review of mine. This time the review is really small, mainly because there already is a good review, written by Flameeyes  https://flameeyes.blog/2010/08/20/book-review-autotools-by-john-calcote/, and even though ther review was arranged by the original publisher, No Starch Press , it is technically accurate and psychologically unbiased.

What I do have to add are just a few of my own experiences.

Russian kids are not taught a proper lesson in computer information exchange.

While this statement is a bit radical, most often there is not a single consice introductory lecture which would teach people how to make descent programs, and saying broader, software pakages out of scattered and disperse algorithms, which people are taught to create in high school and in universities.

Most people learn this by either struggling with Microsoft’s documentation, or (even worse) by copying existing Free Software projects, and tweaking the scripts.

This is a very bad approach.

I know, this is a very emotional statement. But my experience says the following: the less structured is the field you are studying, the more structure needs to be present withing the courses given.

As an example: C, C++, HTML, are reasonably well-structured topics. No matter how you approach the studying, there is only one definitive standard of those, and you have almost no chance of completing your tasks successfully unless you comply with the rules.

As an opposite example, creative writing is not that structured. Your literature teacher may give you good grades, or bad grades, but that would quite often be affected by his personal properties rather than his experiences with the audience you are targeting. In case of the high school class essays this doesn’t matter so much, because your target audience IS your teacher, but it gives you little expertise on how to write for other people.

Therefore, creative writing teaching should require much more elaborate courses than computer programming, exactly to overcome this uncertainty.

Making software packages is an ill-defined task.

You cannot ever solve it precisely. You can reach some level of closeness to the original goal, but as life evolves, your projects have no choice but to adapt to the changing world. Therefore creating software packages is a badly structured task

This makes it necessary to have a structured course. Calcote’s book provides such a course.

Indeed, despite being called “A practitioner’s guide.”, it is more of a good theory treatise than a cookbook. And this is good, not bad. Nowadays canned recipies are in abundace, at StackOverflow, for example. But well-narrated explanations are as rare as they have ever been.

Shall this book be studied at school.

No. Of course not. But it would be a very good idea to let university freshmen read this book as a part of their ‘practice of programming’ introductory classes.

Statistics

This book is 315 pages long, and required 29 hours 54 minutes of my time, including doing exersises and writing this review. This makes it roughly 10 pages per hour, 6 minutes per page. Those were produced in 11 study sessions, each session 2 to 4 hours, and was accomplished in one week, with more than one session per day on the weekend. The book was printed out on paper, and I was making annotations with a pencil. For practical text writing I was using GNU Emacs 26.2. In the

Bibliography

• Autotools Mythbuster
• Die GNU Autotools by Florian Stöhr
• No Starch Press’ webpage for the preview of the second edition
• GNU Website for Autoconf

Review for SSH Mastery by Michael W Lucas

Cover

Motivation

Why did I decide to read the SSH Mastery?

I have been using SSH for a long time, learning it bit by bit, intuitively. At some point I decided to arrange my knowledge in a more structured shape. So at that time I had a choice, whether to read official SSH documentation, or to look out for some external information, preferably from people who have experience of not just creating the product, but also of using it.

The problem with more prosaic books though is that they often risk just retelling the original documentation verbatim, which is always the safest choice, as all the errors may then be attributed to the software authors. On the other hand, they have a risk of falling into a terribly newbie- oriented, very verbose narration style, which would make them too voluminous for being digested in observable time.

Michael W Lucas’ book skilfully manages to avoid both of those pitfalls. It’s both concise and easily readable. Therefore, it didn’t take me too long time to print it out and dive into.

Why a book on SSH is even needed?

Indeed, why? What SSH even is? SSH stands for Secure SHell, but it actually has nothing to do with shells or cores. A ‘shell’ is just a name, traditionally used in computing to denote a way to ask a computer to perform exact tasks. That is, 90% of exact tasks are asking a computer to compute something. You know, that mode of your computer, when this huge 1000$ machine actually works as something it was designed to be 70 years ago: a huge calculator. (By inexact tasks I usually denote tasks which require automated, but not exactly computational tasks, such as calling your friends by a voice chat. )

When you use your calculator, you don’t really need any specific introduction into typing numbers, do you? Well, as I said, a personal computer is a very huge, and a very advanced calculator, so it needs a special advanced program to ask you for your formulae.

The word Secure here implies that using SSH, you can actually ask other computers to be the calculators you ask to compute something for you, and those only need to have the SSH on them, and be connected to a computer network.

So the main task of SSH is establishing connections to other calculators.

Is it so hard? Why would anyone have an extensive manual for a program which performs such a simple task?

There are many answers, but the main one is: not being obvious. The hardest thing to get used to when working with computers is that they are actually one of the least obvious things you find in this world, even less obvious than people.

It doesn’t mean that they are hard. Quite on the opposite, since computers are very dumb, and quite fast, if a good manual is available, few things are actually easier than computers.

But computers are painfully unobvious. Which image among the ones you see on your screen is a real one, and which one is a compressed one? No way to tell. Is the password you are typing on a website stored somewhere or is it not? Are you being attacked by hackers right at this moment, when you are reading this?

The answer to the last question is ‘yes’, even if you are not even remotely aware of the existence of those hackers. And they are also not even remotely aware about your existence, but they don’t even need to. They have robots do all the dirty work for them.

And this is also the place where official manuals fail to increase the obviousness of what is going on, as they are bound to only describing what a program should do, but not what the program should NOT do.

What is the book about?

SSH is usually used for connecting to a remote computer and giving it some orders using the command line.

One of the reasons for reading the book is learning that SSH can to much more than that. As I already said, it is very good at making any soft of connections between two machines.

A typical example: an SSH can work as a universal (so-called SOCKS5) proxy server between you browser and some computer in a country with a less outrageous censorship law. (Yes, to go around those nasty screens telling you that the government decided to block your access to some website.)

Or, SSH is able to forward just one connection from your computer to another computer. This may be very useful if your company is restricting websites which you are able to visit.

Yes, although this post is NOT about circumventing censorship, for non system administration people it’s not obvious (another picture on “not obvious”) that going around barriers is the very nature of computers.

Or, SSH is able to forward everything leaving your computer through a computer far away. Can be very useful if you company’s system administrator is collecting your bank card numbers for his own pleasure.

SSH can simplify a lot of cryptography for you, and the book is very practical about how to make your life as painless as possible while working with cryptography, and (if you never tried), cryptography is still a very very meticulous task, where every little bit helps.

Writing style

The SSH Mastery book is good at simply and in a concise manner explaining the (quite complicated) things. To be honest, I was astonished to see how many practical details Michael W Lucas managed to include in his book, and still keep it under 200 pages.

The book is enriched with practical examples from his own working experience, and he, besides being a writer, is one of the world’s best experts on secure operating systems. (He also wrote the Absolute BSD book.)

The book is also written in a swift, light, vocabulary-rich language. (Which is less surprising than it may seem, as Michael W Lucas is also writing fiction books(!).)

One of the best properties of the book is that it gives you the right tools to reach that sweet feeling of almightiness, which is one of the main reasons why people are choosing computers as a career. And this book makes this feeling not limited to just computing (or systems administration) professionals.

The book collection

Michael W Lucas is writing a series of books actually, under the shared name of ‘IT Mastery’. In this series he elaborates on those tools that systems administrators are learning by trial and error, and users often completely ignore, even though these are those tools which are actually controlling their lives and are used every day. All those have practical examples and accompanying life experience stories.

Should everyone read this book? Shall it be taught at school?

Well, I am sad to say no. Indeed, most people, most developers, and even most systems administrators can get by without ever consulting any reference material on SSH, and especially a prosaic book.

But saying that, most people can get by without so many things… Maybe it’s sometimes better to think in terms of enriching life, rather than surviving?

P.S.

Michael W. Lucas has no relation whatsoever to the film director Michael Lucas.

2019-07-04T10:25:13, Shanghai

How to talk to your child. Общаться с ребёнком. Как? (ENG/РУС)

This blog post contains a short summary and a few independent musings about Yuliya Gippenreyter book’s “How to communicate with your child.”.

Введение

Introduction

Книжку Гиппенрейтер я выбирал, потому что вообще проблема общения
родитель-ребёнок (хотя, конечно, чаще выросший ребёнок) в китайском обществе стоит очень актуально, или, говоря простым языком, потому что беда в этом деле даже большая, чем у русских, и мне хотелось иметь инструмент общения с китайцами.

Кроме того, все мы не далеко ушли от детей, а настоящих детей у меня нет, поэтому я ожидал лучшего применения подчёрпнутым принципам в общении со взрослыми, чем в общении с детьми, и тут мои ожидания не были обмануты. Методы оказались достаточн полезными в работе с коллегами, настолько полезными, что я решил переписать их тут в форме, адаптированной для выросших людей, чтобы и самому понять лучше, и фидбек получить, и убрать комментарии из изложения.

Ну, и кроме прочего, мне хотелось рекоммендаций по выстраиванию отношений с собственными родителями, а, как бы, понятно, что нет лучше способа понять продавца, чем почитать книжку по продажам, и нет лучше способа понять родителя, чем прочитать книгу “как говорить с детьми”.

В итоге, некоторые принципы, которые она рассказывает, оказались
полезны для выстраивания отношений с коллегами.

Прочтение сего краткого обзора не может ни коим образом заменить прочения оригинала, потому что в оригинале есть вещи более важные, чем утверждения — там есть задания и примеры.

Гиппенрейтер — МГУшница, 1930 года рождения, заслуженный человек, работает в том же МГУ, делала карьеру в психофизиологии, однако более известна как автор книг по популярной психологии.

I remember, I promised to write a review on GNU Coding Standards, but I’m not made out of steel, and sometimes I do need some less mind-crushing literature for reading.

I selected the book by Gippenreyter, because generally the problem of child-parent communication (although more often a grown-up child) is noticeably painful in Chinese society. Speaking frankly, the it’s ever worse than in Russia. Moreover, I wanted a tool to communicate with my colleagues.

Apart from that, we’re all not that far from being kids ourselves, and I don’t have my own children, therefore I had to apply the skills to communication with adults, and my expectations were exceeded. The methods turned out to be useful in working with colleagues, so useful that I decided to rewrite them in an “adult” way, to better understand myself and to get some feedback.

They say that there is no better way to learn how not to get fooled by advertisement than to read a book on how to do advertisement yourself. I assumed the same logic with respect to talking to those me as to a child.

Especially colleagues, who sometimes do get this feeling that if they start to talk in a patronizing tone, it may help them reach their goals.

Reading this brief summary will not compensate for reading the original book, book, especially because the book has examples and homework (with solutions), but may serve as a cheat sheet.

Gippenreyter is a venerable person, a professor from the Moscow State University, made a career in psychophysiology, but is better known as an author of popular psychology books.

Принятие

Acceptance

Надо меньше требовать от коллег. Если у них не получается — значит
это твоя недоработка, а не их ущербность. Надо сказать, что иногда
имеет смысл бросить им вызов словами “да ты просто лентяй”, но чаще
всего даже если дело и в этом, то чаще всего лентяй только потому, что
я не смог его правильно замотивировать. Например, показать, как клёво заниматься программированием. Или как классно можно применять навыки дизассемблирования для написания демок.
Они учились не на Физтехе, и даже не в прогерской системе. Их не
научили учиться, а значит, сейчас надо это делать тебе, потому что не жить же рядом с людьми, которые не умеют этого.

Надо больше заниматься бессодержательными построениями отношений. Люди эти дома, скорее всего, ещё более неустроенные, чем ты, живут далеко от семьи, и страдают от этого больше тебя. Обеспечь им хотя бы ту мелкую социализацию, которой у тебя море, и бесплатно. Расскажи баечку из своего бурного прошлого, расскажи какой-нибудь трюк, сильно упрощающий жизнь, и который давно вошёл у тебя в привычку, и о котором они не задумывались. Ещё очень классно показать им шоткат или какую-нибудь фишку софта, которым вы пользуетесь, просто для того, чтобы качество документов, которые они тебе пришлют, было лучше. Заодно китайский подтянешь.

We need to demand less from our colleagues. If they fail at doing something — it is not their fault, it’s my under-performance. Though sometimes it may make sense to challenge them by saying “you’re just lazy”, but but even if so, he’s usually lazy because it was your obligation to motivate him in one way or another, and you failed. For example by showing how cool it is to do software development. Or how nicely he can use his disassembly skills to write demos.Yeah, remember, your colleagues didn’t study in MIPT/MIT, and they aren’t even professional software developers. They weren’t taught how to learn, therefore now you have to teach them how to do it, because it’s not worth living neat the people who can’t.

It’s also worth to do more and more small-talk. Building weak relationships. At home these people are probably even more unkempt than you are, and suffer from it more than you. Provide them with some tiny socialisation which you have lots of and for free. Tell them a story from your tumultuous past, tell some life-simplifying trick, which your practice every day automatically, and which they are unaware of. It’s really nice to teach people how to use hotkeys/shortcuts, just to make the quality of the email they send to you better. You can also improve your Chinese this way.

Коллег надо учить

It really pays off to teach your colleagues

Для людей, активно практикующих extreme programming, или хотя бы
code-review, в этом нет ничего странного, но вообще говоря, большинство людей крайне удивляется, когда им предлагают поработать
вместе надо документом. Чаще всего последний раз они это делали в
старшей школе, и с тех пор фидбэк по работе к ним приходил
исключительно в виде “сдал-не сдал”. К сожалению, сдал-не сдал
работает только для человека, который уже настолько увлечён работой, что его уже бессмысленно оценивать. Поэтому лучшее, что можно сделать при оценке работы подчинённого или коллеги — это выдать ему оценку тех сил, что он, по твоему мнению, вложил в работу. (Оценивать работу как таковую бессмысленно в высшей степени.) А лучше всё-таки просто пытаться работать вместе, пока коллега не начнёт делать так, как ты считаешь правильным. Это будет лучше и быстрее, чем тебе кажется, потому что с вероятностью 99% с ним больше никто возиться не будет, так что волей-неволей начнёт тебя копировать.Соответственно, хвали — за старание. Ругай — за неверие в
собственные силы. Остальные оценки бесполезны, хотя можно иногда
попытаться постимулировать премией.

Зачем учить, ещё раз.

• Свалить на него свою работу.
• Научить учиться без учителя и избавиться от обязанности учить в дальнейшем.
• Заработать авторитет (особенно если научить “магическим” трюкам, вроде хоткеев, которые дёшево и сердито делают работу с компами и не только удобнее) и заручиться поддержкой в будущем.

Нужно ли учить коллегу-мудака? Да, нужно, и ещё больше, чем коллегу
хорошего, но желательно какой-нибудь технологии которая нужнее
где-нибудь там, чем здесь. Тогда неровен час, что уволится, да ещё и тебя хорошей памятью вспоминать будет.

В обучении коллег ест одна загвоздка. Часто надоедает смотреть “что
так медленно”, и думаешь “лучше сам сделаю”. Не надо так делать, так ничего не выучит. Но и бросать на него работу вида “бери и делай”, не стоит. Он-то сделает, но результат потом можно будет в лучше случае применить один раз.

For people who practice “Extreme Programming” or at least regular code-review, there is nothing new about that, but generally many people become incredibly surprised when offered to work together at a paper. Most probably, the last time they did it in high school, and since then the only feedback they ever had was in the form of ‘pass-fail’. Unfortunately, pass-fail only has any meaning for people who already like their work enough to not need to be evaluated. Therefore, the only thing you can really do when assessing your colleague’s work is to assess the amount of effort he has put into the job. (Assessing the work itself if meaningless to the utmost degree.) And generally it’s just better to just try to work on the same task together until the colleague starts doing what you see ad being correct. It will be better and cleaner, and even much faster than you may thing, because with high probability no-one but you will ever care about him, so he will be copying you inevitably.Therefore — praise him for his effort. Disapprove — for not believing in himself. The rest of the marks are pointless, although sometimes a bonus may also help.

So why would you teach your colleagures once again:

• Dump your job on him.
• Teach him to learn without a teacher and get rid of the necessity to teach him more.
• Earn credibility. Especially if you can teach him some magical tricks, such as hotkeys, which cheaply make working with computes and such faster, and earn some guarantees of his support in the future.

Do you really need to teach a jerk colleague? Yes, and even more than a good one. And it better be the technology useful somewhere far from your immediate sphere of interest. This increases the chances of him resigning and leaving for a better position.

Teaching colleagues has one caveat. It’s often so annoying to see him working so slowly that you start thinking “I’d better be doing this myself”. Don’t do it. He won’t learn anything like this. But dumping all your job on him and saying “just do it” is also not very productive. He may ever successfully do it, but the result will be disposable at best, and most probably ever unusable.

Что делать если коллега не хочет сотрудничать?

What to do if the colleague is not cooperative?

Достаточно часто можно просто забить. Если и так хватает работы, то
невозможно объять необъятное. (Отдельная ссылка на самого себя — не больше 7 трудовых связей может поддерживать человек в один момент времени. Уж всех людей свыше этих семи можно с чистой совестью не пытаться научить.)Что делать, если забить нет возможности?

Во-первых, для начала попытаться понять, не пытаешься ли ты учить его не ради благих целей, а ради распространения собственной любимой доктрины (даже если она какой-нибудь интересный трюк из компьютерной грамотности). Если второе — посиди, подумай, обожди. Может, и не надо.

Если надо.

Во-первых, можно попробовать воздействовать на него через
более близких ему коллег. Есть шанс, что если его друг научится делять Х, то из-за близости характера и сам упрямый коллега или захочет, или умудрится решить задачу как-нибудь ещё эффективнее. (Вообще идеальный вариант.)

Во-вторых, можно пытаться действовать через ваших
заказчиков, даже если они внутренние. Кто больше ништяков может
сделать, без кого дело не движется — тот ценный человек. Упрямый
коллега почувствет, что заказчики от него уходят — вполне может
всё-таки в итоге освоить дело.

Давить через босса — не рекомендую, за исключением ситуаций, когда
это делается через презентацию “для всей команды”. Если босс даёт не личное поручение “выучить Х”, а командное — это всегда воспринимается легче.

Ну, и иногда можно бросить человеку вызов вида “что же ты Х, а не
можешь У”. На достаточно гордых людях это прокатывает иногда. Но трюк тоже опасный, потому что гордые люди не любят ощущение, что они проиграли.

Лекции и тренинги полезны для запоминания общего словаря, и для
запоминания общих картинок-диаграмм. В качестве передатчика информации они на взрослой работе уже, в общем-то, не работают. Хотя общий словарь — это тоже полезно, и мелькать у людей перед глазами — полезно.

Инструмент 1: внешние инструменты, вроде того, что в межличностной
психологии называется “пассивная агрессия”, в рабочей практике
незаменимы. Напоминалки, чеклисты, маленькие жёлтые стикеры, диаграммы на стенах, катающиеся доски, и просто повторения упрощённых бизнес-процессов вслух — создают чувство общего контекста и разгружают память. Найди все, что существуют в твоей компании, и используй их все. Лучше всего — напиши батч, который по одному средству, удобному тебе, активирует их все.

Инструмент 2: не всегда обязательно приходится вдалбывать человеку навык Х силой. Часто, когда вы делите работу, можно дать ему выбор. То, что человек выбрал сам, будет и осваивать, и делать с большим удовольствием. Ну и, соответственно, иногда можно давать фейковый выбор. Скажем, сделали вы часть работы, выпустили бета-версию продукта. Попробуйте оставшиеся части дать на выбор. С вероятностью 90% человек выберет то, что уже делал. Но уже будет иметь ощущение “это моё”.

Often you can just ignore him.

Especially if there is enough work, and you cannot cover The Unbounded.
(One more shameless reference to myself: a standard person cannot maintain more than 7 relevant personal connections at a moment. You shouldn’t criticise yourself for not being able to teach more of them.)

What can you do if you can’t just ignore them?

First, try to reflect once again if you’re really trying to teach him for the sake of something good, or just because you want to disseminate some favourite doctrine of yours (even if it IS some interesting computer literacy trick). If the second is the case, hang on for a bit, make a deep breath and reflect on it a little bit. Maybe it’s not worth it.

If you decide that it IS worth it.

Firstly you can try to do it through the colleagues who are closer to him than you are. There is a good chance that if his friends learns to do X, then the more resistant colleague may want it too… or he will solve the problem in some more efficient way. (This would be even better, because it’s a chance for you to learn something from them.)

Secondly, you can try to influence him through customers, even if they are internal customers. Who can do more nice things, without whom the business is not running, that person is a worthy, respected guy. If the more resistant colleague starts feeling that the customers are leaving him — there is a good chance he would be able to learn too.

Putting the pressure on him through his boss… I don’t recommend it. Except when it is done on team meetings. If a boss gives a team order ‘learn X’, rather than a personal one — it is always easier.

Sometimes you can challenge your colleague. “You are an X, and still don’t know how to do Y. Shame on you!”. Sometimes it works on haughty people. Although the trick is a bit dangerous, as proud people don’t like the feeling of losing.

Lectures and trainings are useful for establishing a common vocabulary, and for memorising shared diagrams. As an information transfer media at an adult job, the don’t work. Although having a common vocabulary is also valuable, and getting noticed by co-workers is also valuable.

Tool 1: external instruments of a passive-aggressive kind are indispensable in daily work. Reminders, check-lists, tiny little stickers, diagrams on walls, rolling boards, and just repeating established business processes aloud — the together create a feeling of a shared context and relieve your memory. Find all that are used in your company (yes, make a list!) and use them all. Or, if you can, write a batch script that is triggered by your favourite tool and activates them all. Works for software tools, obviously.

Tool 2: not every time you have to force someone to learn X. Often you are deciding how to split the work to be done. The thing that the person has chosen himself he would enjoy learning more. Therefore sometimes your can give him a fake choice. Say, you’ve done a part of work, released a beta version of a product. Now try to make a vote on how the rest of the work should be split. With probability 90% a person will choose something he has already familiar with. But will get this feeling of ownership.

Работа с эмоциями

Working with emotions

Не то чтобы я сам был большой специалист по работе с эмоциями, однако, есть несколько простых правил, упрощающих жизнь.Меня тут могут обвинить в манипулятивности, и трудно будет это
отрицать. Однако, в своё оправдание могу сказать, что тот, кто не
манипулирует сам, будет манипулируем другими. Ну и, что манипуляция, кроме как быть направленной на человека, может быть ещё направленной на себя самого.

Или, выражаясь иначе, манипулировать можно как с целью запутать, и
вследствие этого половить рыбку в мутной воде (не рекомендую), так и с целью прояснить ситуацию. И именно на этом я бы немного подробнее остановился.

В эмоциях, самая опасная вещь — это не негативность, а их
нераспознанность.

Не так плохо, когда человек искренне недоволен чем-то, чем когда он
чувствует, что его эмоции никем не поняты и игнорируются.

Взрослого человека в этот момент тянет сказать: “Ага! Значит сейчас мы будем угадывать эмоции коллеги и пытаться их скомпенсировать хитрым трюком!”. В целом, если у тебя скилл манипуляции уровня бог, то это может и прокатить, однако есть приличный шанс обмануть самого себя и получить не только коллег, которые не верят ни единому твоему слову, но и проблемы с психикой. Поэтому предлагается более простой метод. Если тебе кажется, что ты угадал эмоцию коллеги — дождись, пока он произнесёт ещё два предложения (вдруг ты всё понял неправильно), и выскажи свою догадку. Если ты ошибся, коллега тебя поправит. Достаточно трудно угадывать эмоции людей, которые их скрывают. Но ещё труднее пытаться подделывать эмоцию вслух.

Рекомендация подождать два предложения не на пустом месте написана. Не надо превращать рабочую коммуникацию в игру “угадай эмоцию”. Но накал дискуссии таким образом можно снизить.

Проще всего высказать эмоцию человека его же словами, правда,
осторожно, чтобы не превратиться в психотерапевта Emacs.

Ну, и так же следует информировать коллегу о своих эмоциях. Часто
так и тянет либо накричать, либо смолчать, сделать вид, что всё
хорошо, чтобы не гнать волну. Но обычно это плохая практика. Всё время сдерживаться невозможно, и прорвёт в самый неподходящий
момент. Поэтому лучше всё время, часно, не не очень интенсивно,
объявлять свои эмоции вслух. Не бывает людей с нулевой
эмпатией. Коллеги тоже будут более кооперативны в итоге.

It’s not that I am a great expert on working with emotions, but there are a few rules that simplify life.And I may be accused of manipulation here, and will find it hard to refute the accusations. As an excuse, I can meekly say that whose who don’t manipulate get manipulated. And that a manipulation is still just a tool. And that apart from being targeted at someone, it can be targeted at oneself.

In other words, you can use manipulation to mislead someone and confuse, in order to make some personal benefit out of it, but you can also use the same tool to clarify the communication and improve the working process. And I don’t endorse the first application as honest collaborators are always more efficient than misled. So I’d try to broaden the picture a bit.

In emotions, the most dangerous property is being unencrypted.

It’s not as bad if a person is genuinely unhappy with something than when he feels that his emotions are not even spotted, and therefore — ignored.

An experienced adult reader may immediately feel the urge to say “I get what you mean. Now we will be guessing colleagues’ emotions and try to compensate them with our clever tricks”. In general, if you manipulation skill is Godlike, this may actually work, although a much higher chance is that you may actually fool yourself instead, and not just find out that your colleagues don’t believe a single word of yours any more, but that you are in need af a psychological help yourself. That’s why a more trivial method is proposed. When you feel that you have guessed your colleague’s emotion, wait until he pronouncec two more sentences (in case you are wrong), and voice your guess. If you are wrong, he will correct you. It’s a bit hard to guess people’s emotions when they are hiding them. But it’s even harder to hide your emotions aloud.

The recommendation to wait for two more sentences is not here for nothing. It’s not worth turning your work communication into a “Guess Emotion” game. But it IS possible to lower the tone of the debate his way.

The best way it usually to express the emotion using his own words, but be careful not to turn into an Emacs psychotherapist.

And you also should inform your colleagues about your emotions. As we become adult, it becomes increasingly tempting to keep silent and to pretend everything is good in order to maintain peace. But usually that’s a bad practice. You can’t restrain yourself all the time, and when the emotion erupts the consequences may be gross. Therefore a better approach is to often but not too strongly express your own emotions aloud. There are not people with zero empathy. Your colleagues will eventually become more cooperative.

Стандартные (чаще всего, нерабочие) методы взаимодействия

Standard (and often misused) interaction methods

По-моему, эта глава плохо работает на работе, в отличие от
остальных. Она слишком эмоциональна, коллеги всё-таки уже не
настолько дети, а часть приёмов всё-таки не приходит в голову
применять в работе со взрослыми.

1. Команда (делай Х)Пошёл ты в жопу, начальник.
2. Угроза (если не сделаешь, оштрафуем)Не оштрафуете, я и так за МРОТ (ЖРАТ) работаю.
3. Пропаганда (Мы самые трудолюбивые и талантливые)Не знаю, как вы, а я нет.
4. Советы (Тебе стоит)Если не стоит, то и не стоит.
5. Призывы к логике. (Если делать Х, можно такое)А можно такое не делать!
6. Ругань (ты дурак)Сам ты дурак.
7. Лесть. (Ты молодец)Я молодец, и что?Здесь лучше сказать “ты хорошо сделал Х”, а ещё лучше “я считаю, что ты хорошо сделал Х”.
8. Высмеивание. (Ты инженер, а не умеешь Х)Ты сам много чего не умеешь.
9. Интересоваться личной жизнь человека.Если не хобби или отпуск. Ну, тут комментарии не нужны.
10. Допросы. (Тебе сказали, ты не сделал. Почему?)Не сделал и не сделал, пошёл ты в жопу, начальник.
11. Фейковое сочувствие. (Да, плохо быть тобой.)Лучше бы делал чего.
12. Уход от разговора. (У меня нет времени.)Нету — найди. Запланируй на через неделю.

In my opinion, this chapter (from the original book) is not so efficient at work, in contrast to the other ones. It’s too emotional, and the colleagues are not that childish, and we are generally more considerate to other adults than to children.

1. A command. (Do X)Cos fuck ya, “boss”.
2. A threat. (If you don’t do X, we’ll fine you.)No you won’t, because I’m already working for food.
3. Propaganda (We in this company are the most hard-working and talented.Maybe you are, I am not.
4. Advices (You should)Don’t tell me what to do, and I won’t tell you where to go.
5. Logic. (If you do X, you can Y)You don’t even image how good is my life without Y.
6. Swearing (you’re an idiot)You’re the idiot yourself.
7. Flattery. (You’re great)Yeah, I know. Now what.It’s better to say “you did X well” or even better “I think that you did X well”
8. Making jokes. (You’re an engineer and not know how X)You can’t do a lot of stuff yourself.
9. Being curious about someone’s personal life.Unless it’s a hobby or a holiday. Well, no comments.
10. Interrogation. (You were told, you didn’t do. Why?)I didn’t because I didn’t. Fuck you, “boss”.
11. Fake empathy. (Your state is really bad.)You’d better do something.
12. Avoiding a conversation. (I don’t have time.)If you don’t, find it. Plan for next week.

Собственные эмоции

Own emotions

Как уже писал, собственные эмоции надо декларировать. Это помогает их потихоньку выпускать, не проявляя совсем уж демонстративно.Как ни странно, люди намного больше любят личные конструкции, чем
безличные, поэтому “эта работа отлично сделана” — хуже, чем “я
считаю, что эта работа отлично сделана”. Рептильный мозг человека
довольно прямолинеен, если слышит “ты хороший”” — думает “я хороший всегда”, слышит “хорошая работа” — думает “хороша для всех вариантов использования”.

С другой стороны, можно и нужно обезличивать конструкции, когда они
склоняют к мысли, что коллега плох. “Работа не очень” — лучше “ты
плохо сделал работу”, потому что есть шанс воспитать в человеке
неверие в собственные силы, а этого делать не надо.

As I said, own emotions must be declared. It helps slowly emitting them bit by bit, without falling into an outright hysteria.”Peculiarly, people much prefer personal constructions to impersonal. That is “this work is well done” is worse than “I think that this work is well done”. Reptilian brain of a homo sapiens is quite straightforward, and if it hears “you’re good” it thinks “I’m always good”, and if it hears “the work is good”, it thinks that the work is done.

On the other hand, making impersonal statements is the right thing to do if a personal one would imply that the colleague is bad by himself, not that just the work is bad. “The work is not really good” is better than “you did the work badly”, because it decreases the chance of instilling a disbelief in himself in that employee.

Конфликты

Conflicts

Про решение конфликтов написано много материалов, но метод, который
даётся в книге Гиппенрейтер довольно прост.Очевидно, что ни ты, ни коллега не не можете быть правы
всегда. Скажем, сегодня мне рассказали один интересный, хотя и
тривиальный трюк с Фурье-интерполяцией, которого я не знал, хотя он
фольклорен. И рассказал коллега, от которого я этого совсем не ждал.

Даже если тебе кажется, что твой опыт в некотором деле бесконечно
велик, всё равно у тебя всего одна жизнь. А жизнь всё-таки длинна и
разнообразна, волей-неволей узнаешь много разного.

В общем, самый простой совет — всегда и во всём сомневайся, в себе
самом в первую очередь. В решениях и предложениях коллег тоже, но для
того, чтобы в них усомниться, нужно их для начала внимательно
выслушать, потому что даже если они выскажут ерунду, ты покажешься
внимательным слушателем. И что более интересно — они могут, и почти
наверняка расскажут какой-нибудь трюк, полезный в других ситуациях.

В целом, если возникла спорная ситуация, метод разрешения простой:

1. Проанализировать
2. Собрать предложения
3. Выбрать
4. Воплотить
5. Проверить

Более сложные протоколы наверняка существуют, и если компания богатая, то могут даже иногда применяться. Например, иногда можно выбора не делать, реализовать оба решения и выбрать лучшее. (На самом деле, это классный вариант, он очень мягко учит, и тебя, и коллегу. Но дорогой.)

Отсюда следует не самое очевидное утверждение, что иногда стоит быть заинтересованным в победе не твоего решения, а решения намного
хуже. Дело в том, что если решение хуже чуть-чуть, то его недостатки можно обнаружить потом лет через десять, когда уже поздно будет.

А вот когда решение совсем плохое, провалится оно довольно быстро, а научиться на нём всё равно можно многом.

Способ временами трудоёмкий, даже когда применяется один раз, однако в частности способствуте ещё и развитию риторики и навыков убеждения.

There is a lot of literature written on the subject of conflict resolution, but the method give in the book is relatively simple.Obviously neither you nor your colleague are always right. Say, today I was taught a useful, although trivial trick with Fourier interpolation that I had been unaware of, although it is well-known. And it was explained to me by a colleague who I expected the least to do so.

So even if you feel that your experience in some area is infinitely high, you still only live once. And life is long and variable, so inevitably different people learn many different things.

So the most general advice is to always doubt everything, first and foremost yourself. Doubt the suggestions of your colleagues too, but first listen to them carefully, because even if they say stupid things, you will be considered an attentive listener, and it’s a respected trait. What’s more interesting — they can and probably will tell you some trick which may be found useful in other situations.

In general, if a debatable situation arises, the easiest ever solution protocol is the following:

1. Analyse
2. Gather solution candidates
3. Choose
4. Implement
5. Verify

More complicated protocols surely exist and if the company is rich may be even applied somewhere. For example sometimes you can avoid making the choice at once, implement both proposed solutions and choose the better one. (Frankly, this option is the best one, it teaches both you and your colleague, and in a very soft way. But it’s expensive.)

So from this follows that sometimes it’s worth being interested in a choice of a decision much worse than yours. Because if the decision is just a little worse, it’s easier for it to win the selection, but the drawbacks may only be discovered yeas later,when it’s already too late to change.

On the other hand, when the decision is really bad, it will fail quite fast, and should provide a lot of learning opportunity.

Sometimes this method is laborious, even if applied once, but it also helps developing debating skills.

Регламент

Regulation

Что такое регламент? Бессмысленная бюрократия, или что-то полезное?Я ненавидел регламенты, пока не поиграл в политику. В обществе людей, каждый из которых хочет мнить себя наполеоном, регламент сразу проявляет свою жизненную необходимость.

Я внедрял на работе Jira. Внедрял с болью и негодованием. Внедрил. Теперь без Джиры народ работы не мыслит. Одно из самых замечательных свойств Джиры — практическая честность. Всё на виду. Недостаток — если ты не админ — трудно делать свои воркфлоу, и не получается делать воркфлоу для единственной задачи. Однако, стоит привыкнуть писать воркфлоу, как в какой-то момент понимаешь, что можно обходиться и без Джиры.

Полезность регламента вообще можно сопоставить полезности
графиков. Есть правило, что тем лучше график, чем больше в нём
отношение энтропии к площади чернил. С регламентом всё почти так
же. Чем больше рекомендаций на единицу чернил — тем полезнее
регламент.

Плюс, хорошо написанный регламент позволяет кастовать заклинания
босса, не имея ответственности босса. Напиши грамотную бумажку,
подпиши у начальства, и у тебя в руках свиток неожиданно большой
мощности.

Вообще, чем больше доверяешь коллеге, тем проще будет регламент. А в какой-то момент можно позволить ему и самому писать его для
себя. Главное, чтобы он это делал.

What is regulation? Is it just worthless bureaucracy or something worthier?I had hated regulation until I took part in a bit of political activities. In a society of people, each of whom deems himself Napoleon, regulation immediately reveals its usefulness.

I implemented business processes with Jira at work. It was painful and induced hatred. Finished. Now people don’t even imaging working without Jira. One of the best properties of Jira is a practical honesty. Everything is visible. The drawback is that if you are not an admin, it’s harder to create new flows and you can’t make individual flows for different tasks. But when you get used to writing work-flows, you will suddenly have in your head how to get by without Jira.

The usefulness of regulation can be compared to the usefulness of graphs. The greater is the information divided by ink ratio, the better the graph. The regulation is almost similar. The more recommendation per unit of ink, the more useful the regulation.

Moreover, a well written regulation allows casting boss’ spells without having his level of responsibility. Make a well designed paper, get it authorised by your boss, and suddenly you have a spell of an unexpected might.

In general, the more you trust your colleagues, the simpler the regulation will be. At some point you can even find him writing his own regulation. He’d better do.

Заключение

Conclusion

Не везде в этом тексте можно заменить “коллега” на “ребёнок”, чтобы
получился содержательный текст. Однако, это получилось сделать в
намного большей степени, чем даже я сначала ожидал.Если бы я хотел сформулировать главную мысль этой книги в одном
абзаце, нескольких предложениях, то написал бы примерно следующее.

Протокол общения на работе должен быть хорошо определённым, простым и понятным. При этом эмоции надо не избегать, а включать в протокол, пуст и в виде объекта измерения. Лучше измерять, чем разгребать последствия. Слушать всех, но толкать свою повестку. И пусть победит достойнейший, помощь ему — честь.

А вы что думаете на тему проекции методов общения с детьми на коллег?
Хочу услышать ваше мнение.

2019-05-08T01:05:29, Шанхай

Not everywhere in this text you can substitute colleague for a child to get a consistent text. But I managed to do it to a far greater degree than I had expected.If I had to formulate the essence of this book in just a few sentence, I would write roughly the following:

The communication protocol at work must be well defined, easy and clear. Emotions should not be avoided, but rather incorporated in the protocol, as a method of assessment. It’s better to measure than to mitigate. Listen to everyone, but push your agenda. And let the most worthy win, helping him is an honour if you lose.

What do you think about the work-child communication?
I’d like to hear your opinions.

2019-05-26T09:47:55, Shanghai

My telegram: http://t.me/unobvious