Notice: file_put_contents(): Write of 14339 bytes failed with errno=28 No space left on device in /var/www/tgoop/post.php on line 50

Warning: file_put_contents(): Only 8192 of 22531 bytes written, possibly out of free disk space in /var/www/tgoop/post.php on line 50
emacsway-log: Software Design, Clean Architecture, DDD, Microservice Architecture, Distributed Systems, XP, Agile, etc.@emacsway_log P.1252
EMACSWAY_LOG Telegram 1252
Forwarded from Ivan
Исправление - это комплекс мер. Тут надо смотреть, где идет затор, сверху или снизу.

Я обычно делаю так (но я не советую за мной повторять из-за высоких рисков, просто у меня с моим польским характером по другому не получается):

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

2. На новом месте есть три месяца, чтоб осуществить изменения. Если за три месяца не удалось, то уже вряд ли получится. Нужно менять работу. В РФ это делать болезненно, ибо остается запись в трудовой, поэтому испыталку лучше оформлять по ГПХ. В Европе многие программисты работают как предприниматели, поэтому там проще: не понравилось - ушел, и никому об этом не говоришь просто.

3. На новом месте нужно пустить корни. Провести встречи 1to1 с программистами, понять кто и что из себя представляет. Выбрать костяк, узнать их проблемы, чем-то помочь и заручиться их поддержкой.

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

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

5. Итак, поддержка есть (мы же сформировали костяк, да?). Всегда найдутся недовольные, которые постараются подорвать авторитет неуважительными выходками. Шопенгауэр в помощь. Языком нужно владеть. Деликатно, острослово и пропорционально поставить выскочку на место. Важно не перегнуть и вовремя протянуть руку, когда человек "уже все понял". Обычно после одного-двух прецедентов больше желания ни у кого не возникает - включается внешний конформизм. Но если это сделать до формирования костяка поддержки, то есть риск попасть в опалу. Поэтому всегда нужно взвешивать силы поддержки и силы сопротивления.

6. Внимательно прислушиваемся к среде. Обычно там, где не хватает знаний, возникают конфликты, особенно на Code Review. Разруливаем конфликты путем интервенции знаний, чем зарабатываем авторитет. Пару раз подсказать - потом сами спрашивать начнут.

7. Противоречия между руководителями - это ваш ресурс. Читаем "Дао Лидера" Джона Хейдера, или Дао Де Цзинь в оригинале. Изучаем диалектику во всех её проявлениях. Учимся использовать эти внутренние противоречия для синтеза. Если этого не сделать, то есть риск скатиться в донкихотство. На этом этапе вы из себя силы пока еще не представляете. Поэтому, находим заинтересованные стороны действующих сил. Тонкая политика. Но мы архитекторы, а архитектура - есть суть разрешение противоречий. Если арх умеет их разрешать, ему не важно, это противоречие требований или противоречие между двумя топами.

8. Выявляем проблемы, по принципу Парето определяем с какой проблемы начать. Смело и решительно решаем выбранную проблему. Дерзновенно, твердо, буйно и радостно.

Если решили проблему менее чем за три месяца - ура, кредит доверия оправдан. Если не решили - бывает. Я в госах тоже не смог ничего изменить. Тогда нужно уходить на резервный оффер - дальше будет хуже. Я проверял. Kent Beck изменил индустрию, но не смог ничего изменить в Facebook. А Eric Evans написал свою книгу по DDD в порыве отчаяния, как финальный аккорд.

Если удалось осуществить изменения - тогда в помощь:
https://dckms.github.io/system-architecture/emacsway/soft-skills/change-making.html

Это мой собственный алгоритм. У меня это работало. Но это рискованный алгоритм. Я бы сам был бы рад поступать по другому, но не получается.
🔥23👍6



tgoop.com/emacsway_log/1252
Create:
Last Update:

Исправление - это комплекс мер. Тут надо смотреть, где идет затор, сверху или снизу.

Я обычно делаю так (но я не советую за мной повторять из-за высоких рисков, просто у меня с моим польским характером по другому не получается):

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

2. На новом месте есть три месяца, чтоб осуществить изменения. Если за три месяца не удалось, то уже вряд ли получится. Нужно менять работу. В РФ это делать болезненно, ибо остается запись в трудовой, поэтому испыталку лучше оформлять по ГПХ. В Европе многие программисты работают как предприниматели, поэтому там проще: не понравилось - ушел, и никому об этом не говоришь просто.

3. На новом месте нужно пустить корни. Провести встречи 1to1 с программистами, понять кто и что из себя представляет. Выбрать костяк, узнать их проблемы, чем-то помочь и заручиться их поддержкой.

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

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

5. Итак, поддержка есть (мы же сформировали костяк, да?). Всегда найдутся недовольные, которые постараются подорвать авторитет неуважительными выходками. Шопенгауэр в помощь. Языком нужно владеть. Деликатно, острослово и пропорционально поставить выскочку на место. Важно не перегнуть и вовремя протянуть руку, когда человек "уже все понял". Обычно после одного-двух прецедентов больше желания ни у кого не возникает - включается внешний конформизм. Но если это сделать до формирования костяка поддержки, то есть риск попасть в опалу. Поэтому всегда нужно взвешивать силы поддержки и силы сопротивления.

6. Внимательно прислушиваемся к среде. Обычно там, где не хватает знаний, возникают конфликты, особенно на Code Review. Разруливаем конфликты путем интервенции знаний, чем зарабатываем авторитет. Пару раз подсказать - потом сами спрашивать начнут.

7. Противоречия между руководителями - это ваш ресурс. Читаем "Дао Лидера" Джона Хейдера, или Дао Де Цзинь в оригинале. Изучаем диалектику во всех её проявлениях. Учимся использовать эти внутренние противоречия для синтеза. Если этого не сделать, то есть риск скатиться в донкихотство. На этом этапе вы из себя силы пока еще не представляете. Поэтому, находим заинтересованные стороны действующих сил. Тонкая политика. Но мы архитекторы, а архитектура - есть суть разрешение противоречий. Если арх умеет их разрешать, ему не важно, это противоречие требований или противоречие между двумя топами.

8. Выявляем проблемы, по принципу Парето определяем с какой проблемы начать. Смело и решительно решаем выбранную проблему. Дерзновенно, твердо, буйно и радостно.

Если решили проблему менее чем за три месяца - ура, кредит доверия оправдан. Если не решили - бывает. Я в госах тоже не смог ничего изменить. Тогда нужно уходить на резервный оффер - дальше будет хуже. Я проверял. Kent Beck изменил индустрию, но не смог ничего изменить в Facebook. А Eric Evans написал свою книгу по DDD в порыве отчаяния, как финальный аккорд.

Если удалось осуществить изменения - тогда в помощь:
https://dckms.github.io/system-architecture/emacsway/soft-skills/change-making.html

Это мой собственный алгоритм. У меня это работало. Но это рискованный алгоритм. Я бы сам был бы рад поступать по другому, но не получается.

BY emacsway-log: Software Design, Clean Architecture, DDD, Microservice Architecture, Distributed Systems, XP, Agile, etc.


Share with your friend now:
tgoop.com/emacsway_log/1252

View MORE
Open in Telegram


Telegram News

Date: |

2How to set up a Telegram channel? (A step-by-step tutorial) The visual aspect of channels is very critical. In fact, design is the first thing that a potential subscriber pays attention to, even though unconsciously. A vandalised bank during the 2019 protest. File photo: May James/HKFP. The public channel had more than 109,000 subscribers, Judge Hui said. Ng had the power to remove or amend the messages in the channel, but he “allowed them to exist.” More>>
from us


Telegram emacsway-log: Software Design, Clean Architecture, DDD, Microservice Architecture, Distributed Systems, XP, Agile, etc.
FROM American