Let us discuss SRFI-216: SICP Prerequisites



This post is a not-so-technical introduction to the Scheme Request for Implementation 216: SICP Prerequisites, that I have written and made available for discussion. (Please, contribute!)

SICP stands for the “Structure and Interpretation of Computer Programs”, a world-famous introductory programming textbook.

It’s aim is to make the exercises and examples from the book be available for any Scheme system bothering to provide it, and not just MIT/GNU Scheme and Racket (which doesn’t even consider itself a Scheme any more). Before this SRFI an issue tracker request asking for SICP support would have been looking vaguely. Now you can just write “Could you consider providing SRFI-216 (and 203)” in your implementation.

In order to write this SRFI, I went through the whole book and solved all the exercises. However, my experience is just mine, and to make a truly good common vocabulary, community feedback is required.

For technical detail and more background, I am inviting you to read the whole article.

Read the whole story


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.”.



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

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

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

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

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

Гиппенрейтер — МГУшница, 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.




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

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

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.




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

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

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

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

  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.




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

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



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

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

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

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

GNU Emacs Manual 26.1


I have read the GNU Emacs manual. Before you turn away and switch to a
less propaganda-oriented topic, let me pledge that I’ll try to stick to only
speaking about the book itself, and its influence on me, rather than the
software it describes. This may sound a bit counter-intuitive, but I am
aiming at the audience slightly broader than purely operating systems
enthusiasts or even professional programmers. And as such, the book as a representation of a way of thinking would be more valuable than the actual
software itself.

Continue reading “GNU Emacs Manual 26.1”