Ещё #подумалось. Жил в прошлом веке один крутой дядька, физик и философ, звали его Дэвид Бом (1). Этот дядька внёс нехилый вклад как в науку, так и в философию; в последнюю - в том числе и введением концепции "Бомовского Диалога" (2): формы общения, направленной не на решение заранее известной проблемы, но на исследование процесса "коллективного думания" как такового. Штука во многом похожая на "мозговой штурм" (3) Осборна (4) и методы ТРИЗ (5) Альтшуллера (6), но не имеющая заранее заданной практической цели, которую надо решить; а скорее преследующая цель "улучшить понимание группой общающихся самой себя". Впрочем, наблюдаемые эффекты с появлением у общения конкретной цели никуда не исчезают.
Помимо предложения метода ненаправленного коллективного творческого процесса, бомовский диалог наглядно показал, что люди куда более склонны иррационально отстаивать свою точку зрения, чем слушать других. На мой взгляд, это - следствие общего свойства жизни, именуемого "поддержание гомеостаза (7)", в приложении к психике. С практической точки зрения это - причина и суть холиваров; да и сами холивары - типичные бомовские диалоги в режиме "как не надо". Если копнуть чуть глубже, то заметной становится работа принципа "у кого что болит", и чем болезненнее отстаивается мнение, тем более уязвимое психологическое противоречие за ним обычно стоит.
С практической точки зрения важно то, что для сваливания в холивар при общении нет необходимости в реальных конструктивных разногласиях - достаточно просто сочетания в одном времени и месте ряда людей, не придающих внимания собственной предвзятости (а по умолчанию мы все этим грешим).
Вступление затянулось, но давайте вернёмся к нашим баранам - к программированию. Поскольку программы чаще читают, чем пишут, на мой взгляд уместно рассматривать программирование не только как инструктирование компьютера, но и как форму общения между людьми - весьма своеобразную реализацию бомовского диалога, например.
Если не контроллировать собственную предвзятость - то тут же получается что лично ты - в белом фраке с блёстками, а все остальные пишут код как мудаки; всю legacy codebase писали индусы, и её нужно выкинуть и переписать; менеджеры - ничего не понимают и вообще лишние люди; camelCase - круто и правильно, а snake_underscored_case - от лукавого. Ну и конечно, моё любимое: "php это плохо, а python - хорошо" и ответное "да ну его этот ваш синтаксический сахар, пхп должно быть достаточно для каждого!" =).
Следом за Бомом и Осборном можно повторить: suspend the judgement, не критикуй раньше времени; be as honest and transparent as possible, будь настолько открыт и честен, насколько это возможно. В целом - не стоит заострять внимание на том что в контексте задачи малозначительно, сколь бы сильно не раздражало оно твою любимую предвзятость.
Ещё, с практической колокольни - везде где это возможно, выгодно заранее снимать противоречия и выносить их из сферы межличностных конфликтов в сферу следованиям формальным процедурам и отраслевым стандартам. Например, холивары относящиеся к формату кодирования в python снимаются соблюдением PEP8 и использованием автоформаттеров. К сожалению, таких формализованных примеров - меньшинство. К счастью, такое состояние дел - это свойство живой системы.
Самое же важное, как в обычном общении, так и в программировании - позволять другим участникам процесса быть такими, какие они есть, и любить их такими. Ибо переделать их всё равно не получится, но если не пытаться - то можно вынести много полезного для себя и обогатить свой опыт взглядом с чужой колокольни. И вот над этим нам всем (привет ленивому психическому гомеостазу!) всю жизнь - работать и работать ;)
1. http://en.wikipedia.org/wiki/David_Bohm
2. http://en.wikipedia.org/wiki/Bohm_Dialogue
3. http://en.wikipedia.org/wiki/Brainstorming
4. http://en.wikipedia.org/wiki/Alex_Faickney_Osborn
5. http://en.wikipedia.org/wiki/TRIZ
6. http://en.wikipedia.org/wiki/Genrich_Altshuller
7. http://en.wikipedia.org/wiki/Homeostasis
Помимо предложения метода ненаправленного коллективного творческого процесса, бомовский диалог наглядно показал, что люди куда более склонны иррационально отстаивать свою точку зрения, чем слушать других. На мой взгляд, это - следствие общего свойства жизни, именуемого "поддержание гомеостаза (7)", в приложении к психике. С практической точки зрения это - причина и суть холиваров; да и сами холивары - типичные бомовские диалоги в режиме "как не надо". Если копнуть чуть глубже, то заметной становится работа принципа "у кого что болит", и чем болезненнее отстаивается мнение, тем более уязвимое психологическое противоречие за ним обычно стоит.
С практической точки зрения важно то, что для сваливания в холивар при общении нет необходимости в реальных конструктивных разногласиях - достаточно просто сочетания в одном времени и месте ряда людей, не придающих внимания собственной предвзятости (а по умолчанию мы все этим грешим).
Вступление затянулось, но давайте вернёмся к нашим баранам - к программированию. Поскольку программы чаще читают, чем пишут, на мой взгляд уместно рассматривать программирование не только как инструктирование компьютера, но и как форму общения между людьми - весьма своеобразную реализацию бомовского диалога, например.
Если не контроллировать собственную предвзятость - то тут же получается что лично ты - в белом фраке с блёстками, а все остальные пишут код как мудаки; всю legacy codebase писали индусы, и её нужно выкинуть и переписать; менеджеры - ничего не понимают и вообще лишние люди; camelCase - круто и правильно, а snake_underscored_case - от лукавого. Ну и конечно, моё любимое: "php это плохо, а python - хорошо" и ответное "да ну его этот ваш синтаксический сахар, пхп должно быть достаточно для каждого!" =).
Следом за Бомом и Осборном можно повторить: suspend the judgement, не критикуй раньше времени; be as honest and transparent as possible, будь настолько открыт и честен, насколько это возможно. В целом - не стоит заострять внимание на том что в контексте задачи малозначительно, сколь бы сильно не раздражало оно твою любимую предвзятость.
Ещё, с практической колокольни - везде где это возможно, выгодно заранее снимать противоречия и выносить их из сферы межличностных конфликтов в сферу следованиям формальным процедурам и отраслевым стандартам. Например, холивары относящиеся к формату кодирования в python снимаются соблюдением PEP8 и использованием автоформаттеров. К сожалению, таких формализованных примеров - меньшинство. К счастью, такое состояние дел - это свойство живой системы.
Самое же важное, как в обычном общении, так и в программировании - позволять другим участникам процесса быть такими, какие они есть, и любить их такими. Ибо переделать их всё равно не получится, но если не пытаться - то можно вынести много полезного для себя и обогатить свой опыт взглядом с чужой колокольни. И вот над этим нам всем (привет ленивому психическому гомеостазу!) всю жизнь - работать и работать ;)
1. http://en.wikipedia.org/wiki/David_Bohm
2. http://en.wikipedia.org/wiki/Bohm_Dialogue
3. http://en.wikipedia.org/wiki/Brainstorming
4. http://en.wikipedia.org/wiki/Alex_Faickney_Osborn
5. http://en.wikipedia.org/wiki/TRIZ
6. http://en.wikipedia.org/wiki/Genrich_Altshuller
7. http://en.wikipedia.org/wiki/Homeostasis
Another # thought. There lived in the last century a tough guy, a physicist and a philosopher, his name was David Bom (1). This uncle made a sickly contribution to both science and philosophy; the latter - including the introduction of the concept of the Bomovsky Dialogue (2): a form of communication aimed not at solving a previously known problem, but at exploring the process of “collective thinking” as such. The thing is in many ways similar to the “brainstorming” (3) of Osborne (4) and the TRIZ methods (5) of Altshuller (6), but not having a predetermined practical goal that needs to be solved; but rather the goal of "improving a group’s understanding of oneself." However, the observed effects with the appearance of a specific goal in communication do not disappear anywhere.
In addition to proposing a method of an undirected collective creative process, the Bohm dialogue clearly showed that people are much more likely to irrationally defend their point of view than to listen to others. In my opinion, this is a consequence of the general property of life, called "maintaining homeostasis (7)," as applied to the psyche. From a practical point of view, this is the cause and essence of holivars; and the holivars themselves are typical Bomov’s dialogs in the “how not to” mode. If you dig a little deeper, then the work of the principle “who has something hurts” becomes noticeable, and the more painfully an opinion is upheld, the more vulnerable psychological contradiction usually stands behind it.
From a practical point of view, it is important that for a blame in the holivar during communication there is no need for real constructive disagreements - just a combination at the same time and place of a number of people who do not pay attention to their own bias (and by default we all sin this).
The entry was delayed, but let's get back to our sheep - to programming. Since programs more often read than write, in my opinion it is appropriate to consider programming not only as instructing a computer, but also as a form of communication between people - a very peculiar implementation of the Bohm dialogue, for example.
If you do not control your own bias, then it turns out that you personally are in a white tailcoat with sparkles, and everyone else writes the code like assholes; Indians wrote all legacy codebase, and it needs to be thrown out and rewritten; managers - do not understand anything and generally extra people; camelCase is cool and right, and snake_underscored_case is from the evil one. And of course, my favorite: "php is bad, and python is good" and the answer is "well, this is your syntactic sugar, php should be enough for everyone!" =).
Following Bohm and Osborne, one can repeat: suspend the judgement, do not criticize ahead of time; be as honest and transparent as possible, be as open and honest as possible. In general - you should not focus on the fact that in the context of the task it is insignificant, no matter how much it irritates your favorite bias.
Still, from the practical bell tower - wherever possible, it is advantageous to remove contradictions in advance and remove them from the sphere of interpersonal conflicts to the sphere of following formal procedures and industry standards. For example, holvars related to the encoding format in python are removed by observing PEP8 and using autoformatters. Unfortunately, such formalized examples are a minority. Fortunately, this state of affairs is a property of a living system.
The most important thing, both in ordinary communication and in programming, is to allow other participants in the process to be as they are and to love them as such. For it’s still impossible to remake them, but if you don’t try, you can take out a lot of useful things for yourself and enrich your experience with a look from someone else’s belfry. And over all of this (hello to the lazy mental homeostasis!) All our lives - to work and work;)
1. http://en.wikipedia.org/wiki/David_Bohm
2. http://en.wikipedia.org/wiki/Bohm_Dialogue
3. http://en.wikipedia.org/wiki/Brainstorming
4.http: //en.wikipedia.org/wiki/Alex_Faickney_Osborn
5. http://en.wikipedia.org/wiki/TRIZ
6.http: //en.wikipedia.org/wiki/Genrich_Altshuller
7. http://en.wikipedia.org/wiki/Homeostasis
In addition to proposing a method of an undirected collective creative process, the Bohm dialogue clearly showed that people are much more likely to irrationally defend their point of view than to listen to others. In my opinion, this is a consequence of the general property of life, called "maintaining homeostasis (7)," as applied to the psyche. From a practical point of view, this is the cause and essence of holivars; and the holivars themselves are typical Bomov’s dialogs in the “how not to” mode. If you dig a little deeper, then the work of the principle “who has something hurts” becomes noticeable, and the more painfully an opinion is upheld, the more vulnerable psychological contradiction usually stands behind it.
From a practical point of view, it is important that for a blame in the holivar during communication there is no need for real constructive disagreements - just a combination at the same time and place of a number of people who do not pay attention to their own bias (and by default we all sin this).
The entry was delayed, but let's get back to our sheep - to programming. Since programs more often read than write, in my opinion it is appropriate to consider programming not only as instructing a computer, but also as a form of communication between people - a very peculiar implementation of the Bohm dialogue, for example.
If you do not control your own bias, then it turns out that you personally are in a white tailcoat with sparkles, and everyone else writes the code like assholes; Indians wrote all legacy codebase, and it needs to be thrown out and rewritten; managers - do not understand anything and generally extra people; camelCase is cool and right, and snake_underscored_case is from the evil one. And of course, my favorite: "php is bad, and python is good" and the answer is "well, this is your syntactic sugar, php should be enough for everyone!" =).
Following Bohm and Osborne, one can repeat: suspend the judgement, do not criticize ahead of time; be as honest and transparent as possible, be as open and honest as possible. In general - you should not focus on the fact that in the context of the task it is insignificant, no matter how much it irritates your favorite bias.
Still, from the practical bell tower - wherever possible, it is advantageous to remove contradictions in advance and remove them from the sphere of interpersonal conflicts to the sphere of following formal procedures and industry standards. For example, holvars related to the encoding format in python are removed by observing PEP8 and using autoformatters. Unfortunately, such formalized examples are a minority. Fortunately, this state of affairs is a property of a living system.
The most important thing, both in ordinary communication and in programming, is to allow other participants in the process to be as they are and to love them as such. For it’s still impossible to remake them, but if you don’t try, you can take out a lot of useful things for yourself and enrich your experience with a look from someone else’s belfry. And over all of this (hello to the lazy mental homeostasis!) All our lives - to work and work;)
1. http://en.wikipedia.org/wiki/David_Bohm
2. http://en.wikipedia.org/wiki/Bohm_Dialogue
3. http://en.wikipedia.org/wiki/Brainstorming
4.http: //en.wikipedia.org/wiki/Alex_Faickney_Osborn
5. http://en.wikipedia.org/wiki/TRIZ
6.http: //en.wikipedia.org/wiki/Genrich_Altshuller
7. http://en.wikipedia.org/wiki/Homeostasis
У записи 5 лайков,
0 репостов.
0 репостов.
Эту запись оставил(а) на своей стене Key-G B-Tee
