19 июля 2015

Отзыв на "Release It! Design and Deploy Production-Ready Software" Michael Nygard

В очередной раз приветствую читателей моего бложика.

Сегодня я спешу поделиться с вами фидбэком на преинтереснейшую книгу, ссылку на которую я нашёл в одной из статей Мартина Фаулера,-
"Release It! Design and Deploy Production-Ready Software" Michael Nygard, 2007.

"Hope is not a design method"

В этой книге затрагиваются такие важнейшие качества программного продукта как стабильность, расширяемость, безопасность, доступность, администрирование и мониторинг.
Почему это важно? Вот несколько причин:

30 мая 2015

Краткий курс общения без эскалации от Umputun'a

Прослушивая очередной архивный выпуск подкаста от Umputun'a, в котором была затронута тема межгрупповых коммуникаций по следам недавнего конфликта его подопечных, я решил оформить у себя в блоге тот манифест, который Евгений выдал своим коллегам.
  1. Никогда не продолжай дискуссию в режиме "пинг-понга" (вопрос-ответ-вопрос-ответ) в длинных цепях рассуждений, если вы и другая сторона о чём то не согласны. Если Вы ответили А, а Вам Б, а Вы ответили еще раз А, а Вам ответили еще раз Б, не отвечайте третий раз А, а обратитесь к своему руководителю (или к другому лицу, которое выполняет функции "последней инстанции", арбитра и т.п.).
  2. Если уже запланировано совещание по данной проблеме, то необходимо прекратить всё обсуждение до этого мероприятия.
  3. Никогда не пробуйте объяснить другой стороне "правильный путь". Даже если вы думаете, что знаете "как надо", другая сторона наверняка не пришла к вам с вопросом "как надо". У неё скорее всего другие вопросы и задачи.
  4. Ты должен быть прагматичным и холоднокровным. Если тебя просят сделать (или спрашивают) что-то тупое, но с точки зрения выполнения этого запроса это занимает у вас 5-10 минут, то вместо попытки объяснения зачем это делать не надо, лучше просто это сделать. В общем случае - если выполнить просьбу быстрее, чем обсудить её необходимость, то лучше просто её сделать. Скорее всего та сторона поймёт сама, что это было лишнее. Мир лучше не станет, но прагматизм лучше.
  5. Оценивайте ту сторону как хороших ребят. Даже хорошие ребята могут ошибаться. Может и они или вы чего-то не понимаете и тогда смотрите пункты 1-2.
PS:
Добавлю от себя не менее полезный совет - "Если разговаривая с человеком вам кажется, что вы разговариваете с идиотом, то скорее всего он думает о вас аналогично".

Вообще, помимо подкастов Радио-Т и Weekly Umputun Podcast послушать другие умные мысли достаточно опытного и, не побоюсь этого слова, умудрённого жизнью автора можно в недавнем выпуске подкаста CTOCast.

30 апреля 2015

Мой последний день работы в R-Style Softlab

После четырёх лет работы в компании настало время подвести итоги начала моей профессиональной деятельности.
Работа в ДСЭБО дала мне важное понимание многих нюансов командной работы, разработки программных продуктов, которые критически важны для правильного осознания того окружения, в котором работаешь.
Я познакомился с многими замечательными людьми, смотря на которых понимаешь, что мы все вместе могли бы свернуть горы и добиться ещё более впечатляющих результатов.
Хочу всем сказать спасибо за ваш вклад в становление меня как профессионального разработчика.
Надеюсь, что моё небольшое наследие, в свою очередь, окажется для вас так же полезным :-)
Желаю всем вам: счастья, здоровья, благополучия и стремления к новым профессиональным вершинам!

В адресатах письма стояло более 20и человек из Московского, Вологодского и Череповецкого филиала.

26 января 2015

"Как мы провели ЭТО". Региональный этап всероссийской олимпиады школьников по информатике 2015.

Сказка о том, что бывает, когда организаторы олимпиады забывают о золотом правиле разработки "Работает - не трогай" или "Хочешь сделать хорошо - сделай это сам".

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

18 января 2015

Отзыв на "Идеальный программист" Роберта Мартина

Приветствую своего читателя в очередной раз за обзором ещё одной хорошей книги для настоящих программистов и для тех, кто им хочет стать - "Идеальный программист. Как стать профессионалом разработки ПО".
Это мой обзор уже второй книги известного автора книг по Agile и просто хорошей разработке - "Uncle Bob" Роберта Мартина.

05 октября 2014

Behind the scene. Выступление на WebDev Meetup Вологда 27.09.2014

Всем привет.

На данный момент в Вологде примерно раз в 2 месяца компания "Трилан" организует небольшой митапчик для ИТ-шников в Вологде. Проходит он в коворкинге "Контейнер" (который правда сейчас на грани закрытия).
На каждом таком мероприятии выступает 2-3 спикера из местных разработчиков/дизайнеров и также можно пообщаться с людьми после и между докладами за чашечкой чая и пиццей.
В общем, такая неплохая субботняя туса для тех, кому интересно.
Мне было предложено подготовить доклад на тему, которой я стал заниматься не так давно - Soft Skills. Подробнее об этом увлечении можно почитать в предыдущем посте в блоге.

В качестве темы я выбрал "Тёмная и Светлая сторона убеждения людей".
В этом докладе затрагиваются разные тактики к убеждению людей на переговорах.
Доклад получился немаленьким (около часа) и может на грани нормальной усваиваемости, но мне очень не хотелось его разносить на два выступления с интервалом в пару месяцев.
Каждая подтема так удачно сочеталась с другой, что именно от цельного выступления, как мне казалось, будет наибольшая польза.

07 июня 2014

Soft skills. Материалы.

Всем привет!
После небольшого перерыва продолжаю пополнять свою копилку интересных материалов по разным темам. Сегодня я постараюсь выделить запомнившиеся мне материалы в области Soft skills.
Как мне кажется, это одна из тех тем, изучая которую можно научиться решать тот класс своих задач, которые ты не мог бы решить будь ты хоть экспертом в своей области на работе.
Это проблема эффективного общения с людьми. Отсутствие навыков эффективного общения в команде может с той же лёгкостью погубить любой проект, как и непродуманная архитектура, план разработки, баги.