A short review of the “Art of War for Women” by Chin-Ning Choo.

001_book_cover_1587895815.jpg

The Art of War.

NOTE: this review is not about a similarly-titled book by Sheetz-Runkle, and not about a similarly-titled book by Huang and Rosenberg.

The “Art of War”, not such a long time ago used to be fairly unknown to the western audience. Maybe because there had already been a well-established western military tradition, represented by von Clausewitz. The Soviets, however, perhaps due to being actively involved with Asia since the very establishment, were much more open to the Eastern tradition, and the Art of War was a part of the Soviet intelligence curriculum for a long time. Eventually the West has also fallen victim to this millennia-old book on strategy and tactics, and the Art of War began its triumphant parade over the business culture. This was also partly fuelled by the very visible progress that the Asian cultures, from Mongolia to Japan, had by the end of the 20th century. One of the most prominent marks of the era was a recent British independence slogan “Will the Brexit Referendum make London the Singapore-on-Thames?”. Such an astonishing claim to be made in the former capital of the world.

The book by Ms Choo introduces the concept of the 21st century being the “Century of Asia” at the very beginning of the book. Indeed, although the book is full of citations from the Art of War, my feeling was that they were cherry-picked with the main purpose of adding Ms Choo’s book an Asian flavour, rather being the core knowledge carrier.

Maybe it’s actually for the best. To each his own, I am still planning to lay my hands on the old book itself, and thankfully, the “for Women” version was not much of a spoiler.

The second claim that is firmly made in the book is that the 21st century is going to be the century of women. That’s probably a thing that nobody is going to argue against, since the technology is making the world a much more comfortable place for women, so even though I would be more careful about attributing the whole century to just a since human trait (sex), we are definitely going (in fact we already are) seeing more female influence on the everyday life.

The core ideas.

The book is roughly structured around five aspects of success.

They bear fancy Chinese names, but for simplicity I am just writing them out in layman terms:

  • Personal qualities
  • Temporal properties
  • Fixed properties
  • Skill
  • Implementation

Each chapter is dedicated to one of the components of success, and in each of those the author tries, beyond presenting the basic concept of a component and the actions that are needed to nurture this component, some additional traits that are supposed to be more related to women than men.

Quite unsurprisingly, as the book progresses, each subsequent chapter bears less “femaleness” and more “practical guidelines”.

In general, I cannot say that I highly assess the parts that are more dedicated to the sexual dimorphism. The management chapters were quite good. I have made a lot of records, and rearranged some of my working practices, following her advice. The “female” parts, to be honest, did not help illuminating how exactly sexual dimorphism affects the differences of performance between the employees of different sexes too much. The book contains quite a lot of female encouragement and debunking of old misconceptions about women, which is a great thing, but seems to be of less use to those who have already given up those misconceptions. However, developing “conceptions” (pun intended), that is the understanding when and how exactly sexual differences can be used as a leverage, and where they should be kept in mind as a thing of concern, is sub-optimal, in my opinion.

Conclusion

The book is short, and can be done in a couple of evenings. It is probably worth reading as an encouraging material, although women who have already decided to be the best of themselves, are unlikely to need any more encouragement. Some anecdotal evidence is nice, it feels very nice to be able to relate yourself to some real-life examples. Some paragons of female success are also given, from various areas of life, from politicians to doctors and managers. The management-related, gender-agnostic chapters are just good and worth looking even more than once. Is it the book to be read to find out about gender differences and how to use them – perhaps not, and it is also not a good book about the “Art of War”.

The main military thought that you can derive from it is that avoiding defeat may be often a much more efficient strategy than winning a battle. After all, Suvorov is believed to be emphasising this a lot.

The Russian translation is horrible, however.

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

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

2020-09-14_10-44-42_book-madness-of-crowds-cover-with-douglas-murray-author.png

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

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

Abstract

001_book-cover_9781594546792-e1543265376887.jpg

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.

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

The Futurological Congress by Stanislaw Lem

Futurological_congress_cover.jpg

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.

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.

001-book-cover-9781509524563_FC.jpg

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

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

001-book-front-s32310042.jpg

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.

Continue reading “A Review on The Light That Failed by Ivan Krastev and Stephen Holmes”

A Review of LiShan Chan’s Philosopher’s Madness

001_a-philosophers-madness-book-cover

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.

Continue reading “A Review of LiShan Chan’s Philosopher’s Madness”

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

01-introduction.jpg

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.

02-acceptance.jpg

Принятие

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.

03-teach_colleagues.jpg

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

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.

04-cooperative.gif

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

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.

05-emotions.jpeg

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

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.

06-bad_boss.png

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

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

05-slap_meme.jpg

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

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

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.

08-conflict.jpg

Конфликты

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

09-bureaucrat.png

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

Я внедрял на работе 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
 10-subscribe.jpg

A Mathematical Theory of Systems Engineering: The Elements by A. Wayne Wymore

The review on the book by Albert Wayne Wymore
‘A Mathematical Theory of Systems Engineering — The Elements’

wymore1967book_cover

This review must be prefaced with a quotation from the last chapter of the book, which is sort of really indicative of what you should expect from it if start reading.

“(Alan) Turing’s work is very important; there is no question about that. He illuminated many fundamental questions. In a sense, however, it is unfortunate that he chose to write in terms of ‘computability’ especially in view of development, subsequent to Turing’s work, of modern computers. As a theory of ‘computability’, Turing’s work is quite important, as a theory of ‘computations’, it is worthless.

“Wow!”, you would think. “This man has the audacity to defy Turing himself! He must be offering something really outstanding instead!”
Well, not really. What is then that he is offering instead?

To start reviewing a book about systems engineering, one would have to first, at least try to specify what systems engineering is. But even such a simple, supposedly, term would have to be met with caution. Well, obviously, it’s connected with the engineering of systems.

But if you open the definition of a system in the book, you’ll see the following:

A system is a set Z = {S, P, F, M, T, \sigma}, where 
    S is a set not empty,
    P is a set not empty,
    F is an admissible (ignore this word at the moment) set of input functions with values in P,
    M is a set of functions each defined on S with values in S,
    T is a subset of R containing 0,
    \sigma is a function defined on FxT with values in M such that \sigma is onto and 
        (1) the identity mapping \omega \in M and for every f \in F, \sigma(f,0) = \omega;
        (2) if f \in F, s, t, and s+t \in T, then \sigma(f -> s, t)\sigma(f,s) = \sigma(f, s+t);
        (3) if f and g \in F, s \in T, and f(t) = g(t) for all t \in R(s), then \sigma(f,s) = \sigma(g,s)

Wow. Looks really cryptic, doesn’t it?

Factually, if you open almost any other book on the subject, you’ll most probably see a completely different definition, likely dealing with loosely defined terms, such as ‘components’, ‘interfaces’, ‘actors’ and similar things from project management jargon.

For example, this is the definition of a system from the INCOSE’s Systems Engineer’s Handbook.

“… an integrated set of elements, subsystems, or assemblies that accomplish a defined objective. These elements include products (hardware, software, firmware), processes, people, information, techniques, facilities, services, and other support elements. (INCOSE)”

“Well”, you may tell me, “perhaps this Dr. Wymore is meaning something completely different?” Are they even speaking about the same field of knowledge?

Let’s check:

‘A. Wayne Wymore founded the first academic department of Systems Engineering in the world at the University of Arizona in 1960. He pioneered Mathematical-based Systems Engineering and later led Model-based Systems Engineering. He was an early and ardent supporter of the fomenting of INCOSE. He has led self-evaluation of Systems Engineering education, and continues to be one of the most prominent theoreticians of the Systems Engineering community. In addition to his teaching, writing, and consulting, he has participated in pro bono projects to bring a Systems Engineering approach to social service organisations.

INCOSE (2003) “INCOSE’s Pioneer Award” text; cited in: Wayne Wymore biography at incose.org, last updated: 19 Nov 2007.’

Wow, that’s impressive. So Dr. Wymore actually founded the whole Systems Engineering way of thinking. How come the definitions are so different?

The answer can be found, interestingly, in the auto-biography of Dr. Wymore, written by himself (http://sysengr.engr.arizona.edu/wymore/WWAutobiography.htm):

“Now (1987) I had a chance to finish the book on which I had been working for 11 years, since the publication of Systems Engineering Methodology for Interdisciplinary Teams in 1976. This was to be the book that I write for myself, for pleasure, with little regard for the existence of a market. It would be mathematically as rigorous as I was able to make it and it was intended to include every aspect of system science that would be necessary for successful systems engineering.  The rigor doubtless would be tedious for the present day systems engineer.  It might take a generation or two, perhaps more, before the profession would see fit to train systems engineers at a sufficiently high level of mathematical sophistication to qualify themselves to take on the design of a really vast and complex system such as the national health care system.”

Please, note the *the rigor doubtless would be tedious for the present day systems engineer*.

Has those two generations passed already? Or perhaps just one? 1987-2017 = 30 yeas.

So, basically, Wymore had seen the power of mathematics in describing all possibly thinkable systems, back then, in 1967. But even today, in 2019, we still don’t have sufficient enough computing systems to implement all the prerequisites for a self-supporting, computable Systems Engineering ecosystem.

Well, I have said ‘Systems Engineering’ so many times, and still hasn’t properly explained what it is.

The problem, it IS a bit hard to explain what it is. The informal definition of ‘assembling systems from pieces’ leaves more questions than answers anything.

Actually, Dr. Wymore actually had the same feeling, so he decided to give the same subject a more fundamental, mathematical base.

So, from a mathematical point of view, systems engineering is sort of a mathematics, and a skill of solving equations in a special functional space, which Wymore calls an ‘admissible input functions’ space. Without getting into too much detail, it is a somehow queer space of functions, which can have quite a lot of discontinuities, and are not obliged to be in any sense smooth, but are required to be sort of scale and shift independent, representing time and space isotropy.

Wymore claims that almost all imaginable systems (hardware or software, or even human organisations) can be represented as formulae on top of the ‘admissible functions’. And he builds a relatively comprehensive theory, describing how to relate various mathematical descriptions of systems requirements (input, output, state) with his definition of what is a system.

systems_image

Interestingly, the most ‘meaty’ thing, that is how to actually describe a system mathematically, is given very little attention in the book. Because that is, supposedly, heavily dependent on the nature of the system built. But if the system IS already described, Wymore’s theory is ready to give some insight on how to predict the system’s behaviour, and how to use the power of mathematics to partition the system into parts. (Which IS, in some sense, the main thing expected from a systems engineer in practice.)

Remember, this book comes from 1967. There is, however, the second book in the series, written in 1993 (*model-based* systems engineering), which puts more emphasis exactly on those two missing aspects of the theory. On modelling and on simulating. (I haven’t yet read it, but it’s on my plans.)

You would ask me: how does it actually work in practice? Is Wymore’s mathematics actually used somewhere?

The answer is a bit disappointing. I haven’t seen any applications of the theory, and more modern books on systems engineering seem to be full of marketing bullshit, not of consistent mathematics.

Why? Well, so far, the world is still ruled by people more focused on intuitive thinking, rather than mathematical thinking. And I don’t see much of it changing in the foreseeable future. And Wymore’s theory seems to be in the worst possible location for a mathematical theory. It requires the users to be BOTH mathematics-savvy, AND having good intuition in those places where no good mathematical theory exists.

But how is Systems Engineering working nowadays then? Well ,the actual answer is ‘difficultly’. In the situation when you can’t force people to not just know mathematics, but even learn programming, you’re left with an only option of ‘programming people’ by writing documents. And to some extent, the systems engineering of now, is a science of writing instructions for people, and drawing diagrams (rather than writing code), because generally, unprepared people are easier at understanding graphics, not text.

I guess, you’re starting to feel where I’m going to. I am going to SysML.

sysml-diagram-taxonomy

SysML (and UML) is an attempt to make programming ‘imprecise’. That is, actually, a software program is always a model of behaviour of some system. But too often we cannot formulate the system precisely enough to actually write a robot to satisfy the system specification.

Nevertheless, we often can at least sketch the system’s definition in UML/SysML. (And frankly, it was a very bad idea to make the canonical representation of the language graphical, not text-based, but thanks to PlantUML, the situation is now much-much less cumbersome for people like me, who like precision.) Who knows, maybe at some point we will actually have better tools for the interaction between graphics and logic (code). Maybe the second tome (1993) will give me more insight into how this works. Especially since Wymore seems to be providing a more computer-friendly language called T3SD, a domain-specific textual language for describing systems. Maybe it will serve as a good bridge between the mathematical and the visual parts of systems design.

So, getting back to the Mathematical Theory of Systems Engineering: The Elements.

This book is definitely a must-read for a systems engineer. If you don’t understand the mathematics behind what you are doing, you’re not doing it right in any respect.

Is it well written? Well, in almost every aspect — yes. I feel some influence of the social nature of the systems engineering job — the book has a rich vocabulary, and with an exception of several rather confounding theorems, is clearly and consistently written.

Is this book of immediate practical applicability? I wouldn’t be so sure about this, but maybe the second book will change my mind.

Is this book enough as a first introduction into the subject? Still, no. Systems engineering in practice is much more than just mathematics behind the system specifications. Some practical information on how to do *informal* descriptions of systems is seriusly needed.

And, I guess, for every subject I’m reading about, I should be asking myself a little bit weird question: “should such thing be taught in middle school?”.
And in some sense, I would rather answer “yes” than “no” to such a question.
I still remember studying physics at school, and I do remember than one of the biggest complaints I had about it was that physics was presented to us as just a set of disconnected, scattered facts, each of them having a different structure.
Having then not interconnected was already bad enough, but it was the inconsistency of internal structures than was really driving me crazy. (I still don’t know physics, even though I am working (!) as physicist now.)

And in some sense, the MTOSE book is making a small step towards providing a unified base under various physical models and phenomena, and also can be seen as providing links to the other modellable subjects, such as biological phenomena, for example.

Should you read the book? I don’t know. I guess, we need a simpler book on systems engineering for ordinary people, which would still keep at least a trace of mathematical rigour. But this one… perhaps not, unless you are a working engineer or a mathematician. Then — yes. And of course, if you are a systems engineer, it is must.