I hereby claim:
- I am kirushik on github.
- I am kirushik (https://keybase.io/kirushik) on keybase.
- I have a public key whose fingerprint is 655D F5CB FECD 6718 CFC8 2949 FBF0 C4CB 6A37 5D79
To claim this, I am signing this object:
#!/usr/bin/env ruby | |
require 'rubygems' | |
require 'mechanize' | |
require 'uri' | |
a = Mechanize.new | |
root = URI.parse('https://en.wikipedia.org/wiki/List_of_Star_Trek:_The_Next_Generation_episodes') |
I hereby claim:
To claim this, I am signing this object:
#!/bin/bash | |
gnote --search="`xsel`" |
New GPG key for security@parity.io email | |
At Parity we’re always looking for ways to improve our security. As phishing exploits continue increasing in sophistication, we have been thinking about how to ensure the trustability of our critical security messages. | |
We receive critical security messages through security@parity.io. In order to ensure that the recipient can trust that we are the only receiver of these emails, they encrypt their message with GPG keys, which enable signing and encrypting emails. | |
GPG keys have a two-year lifespan. While it’s possible to extend the lifetime of the keys, when facing the end of our security@parity.io key lifespan, out of an abundance of caution, we decided to issue a new key instead of extending the existing key. | |
Up until Sunday July 21, 2019, our security@parity.io GPG key has this fingerprint: | |
DAE5 1560 28CF 37A0 7C69 3883 5D0F 0301 8D07 DE73 |
(Большое спасибо одногруппнику Петру за разговор, который заставил меня полностью переосмыслить прочитанное и выбросить прошлый вариант этого текста.)
Довольно несложно понять, почему книга даётся в качестве “входной” литературы к курсу системного мышления (на самом деле — даже нижележащего по стеку курса онтологики и коммуникации):
Самое полезное для меня в курсе пока — пятнадцатиминутное упражнение по выделению моих основных рабочих ролей и распределению времени по ним. Тут как с тренировками с тренером в спортзале — нет ничего такого, что нельзя бы было делать самому, но “в серии из десяти отжиманий самое последнее — одиннадцатое”, и (по крайней мере мне) нужен кто-то внешний, чтобы "дожать".
За эту неделю я успел начать сразу несколько процессов, чтобы сместить баланс времени в пользу ролей, в которых меня трудно/невозможно заменить. Для этого, как вполне очевидно, я работаю над уменьшением времени, приходящегося на роли, в которых меня з
Уже какое-то время я применяю подходы системного мышления ко всему прочитанному “менеджерскому” нон-фикшену, и не могу остановиться.
Эффект забавный: ментальная реинтерпретация в категориях системного подхода делает многие статьи не только компаче, но и гораздо тривиальнее, нежели оригинальное авторское изложение.
Я несколько беспокоюсь что эта тривиализация на самом деле сжатие с сильными потерями (и я рискую недобрать опыта, читая статьи таким образом — там же мог быть какой-то слой мудрости/опыта, который потерялся при интерпретации).
Отсюда и афоризм в заголовке; но я успокаиваю себя тем, что (по крайней мере пока) мне полезнее получить пусть несколько обеднённую, но консистентную картинку менеджмента в голове — это заметно лучше, чем никакой.
А то обычно менеджмент размножается по мозгам абсолютно бессистемно, в формате афоризмов ("Учить → Лечить → Мочить" для разрешения проблем с Командой) и анекдотов из жизни (все эти “кейсы из практики”), и далеко не любая книга (что уж говорить про более мелкую
Где-то уже недели 4 (с тех пор как у меня самого "щёлкнуло") я уделяю 3-5 часов в неделю тренировке подчинённых (и, при случае, более "отдалённых" коллег) пониманию связи ролей, интересов и практик — и удержанию во внимании связанных с этим изменений. Естественно, это подводит их к пересмотру собственных практик и планированию постепенного (и согласованного между разными людьми/командами!) обновления их стека.
Важная практика, которую приходится ставить практически "с нуля" (с очень примитивной, нигде не описанной, ad-hoc системы, наросшей эволюционно без какого-то дизайна для затыкания дырок "в моменте") — управление знаниями (knowledge management). Команда растёт, проекты и задачи всё более разнообразны — и полагаться на дедовские методы ("я просто подсмотрю в коде" и "я найду, у кого спросить" в основном) больше не выходит.
При этом большая часть "традиционных" knowledge management практик очевидно противоречат остальным инженерным Agile-практикам, который мы применяем: "по классике" Agile предполагает