День выборов

На этих выборах есть три возможных стратегии:

1. Проголосовать за Путина.
2. Проголосовать не за Путина.
3. Не пойти на выборы.

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

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

Понятно, что в ходе голосования будут фальсификации. Понятно, что выборы нечестные. Что выборов нет вообще. Но это слабая причина, или даже отговорка, чтобы не ходить на голосование. Как говорит Белковский, «классический принцип традиционной этики состоит в том, что делай, что должен и будь что будет». Отказываясь от голосования мы точно ни на что не можем повлиять.

Кстати, перечитал свой старый пост об итогах выборов в парламент в декабре 2011 года. Многие вещи выглядят наивно, особенно подсчеты рейтингов. Такая уж была атмосфера медведевской модернизации. Но уже через полгода, после разгона марша миллионов на Болотной, я написал о том, что Путин прошел точку невозврата и сам от власти не откажется. После маленькой победоносной войны на Украине говорить о рейтингах вообще стало бессмысленно.

Тем не менее, за шесть лет основная идея — «надо согласиться с тем, что любой человек (в том числе Зюганов или Жириновский), выигравший выборы у Путина, будет президентом не хуже, чем сам Путин» — всё еще актуальна. Поэтому я воспользуюсь классическим принципом традиционной этики и прогуляюсь в этот солнечный день до избирательного участка.

Промышленное программирование и область ответственности разработчика

Промышленное прогаммирование

Хочу поделиться опытом промышленной разработки программного обеспечения. Под словом «промышленная» я понимаю разработку приносящего деньги продукта в коллективе от нескольких десятков человек.

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

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

Аджайл-манифест разработки программного обеспечения

Начнем систематизировать знания о разработке с аджайл-манифеста:

Люди и взаимодействие важнее процессов и инструментов.
Работающий продукт важнее исчерпывающей документации.
Сотрудничество с заказчиком важнее согласования условий контракта.
Готовность к изменениям важнее следования первоначальному плану.

То есть, не отрицая важности того, что справа, мы всё-таки больше ценим то, что слева.

Это емкие, многогранные принципы. Мы к ним еще не раз вернемся. А пока посмотрим на одну составляющую первого принципа, а именно на то, как организуют взаимодействие с разработчиком.

Область ответственности разработчика

Недавно на хабре вышла статья про то, как Слак и мессенджеры вообще снижают продуктивность. В комментариях завязалась интересная побочная дискуссия. Первая точка зрения:

Никто никого не должен отвлекать по пустякам, вообще обычный разработчик должен в рабочее время заниматься только выполнением текущих запланированных задач и реагировать только на два типа сообщений:
1. Авария — что-то серьезное на продакшене или ошибка на уровне архитектуры, в первом случае срочно чиним, во втором останавливаемся и обсуждаем т.к. дальнейшая работа может просто оказаться бессмысленной. Если часто проблемы с продом — это чаще всего косяк тестировщиков, если хреново спланирована архитектура или выбраны не те инстументы — косяк архитекторов.
2. Блокировка — т.е. отсутствие реакции на это сообщение реально блокирует работу другого человека. Если есть большой поток блокирующих сообщений, то это либо отсутствие компетенции у других исполнителей — косяк того кто их нанял, либо хреновое планирование и распределение задач между исполнителями — косяк ПМа.

Если же разработчик вынужден по работе напрямую общаться с кем либо кроме ПМа и других разработчиков (например с заказчиками), то ему лучше сменить место работы!

Вторая:

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

Это два противоположных подхода к вопросу об области ответственности разработчика. Давайте выделим особенности каждого подхода:

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

Руководитель программистов должен учитывать при подборе и огранизации рабочего процесса особенности каждого способа. Первый свойственен водопадной модели, воторй — аджайлу. Если вы нанимаете инициативных разработчиков — готовьте бюджет. Если нанимаете операторов ЭВМ, нанимайте еще менеджеров и тестировщиков.

Политика на улице

Надпись на стенке «За Россию без Путина»

← сюда туда →