Эта заметка — для менеджеров, которые принимают решение о выборе технологического стека. Если вы CTO, программист или просто готовы поговорить о различиях языков программирования — посмотрите версию для программистов.

За пару дней до Нового Года я решил выбрать робот-пылесос. На рынке есть десятки брендов — iClebo моет полы, iRobot лучше всех строит карту помещения, Дайсон — мощный, а Сяоми вроде бы самый крутой, и стоит в 5 раз дешевле. Объединяет всех производителей одно — нихуя не понятно, какую из характеристик нужно выбрать, чтобы конкретно в моей квартире стало всегда чисто.

Когда руководитель не может делегировать выбор технологий для нового проекта, он оказызывается в такой же ситуации, как я на Новый Год. Проект нужно было начать еще вчера, а чем Руби отличается от Питона и Раста, и как эти отличия отразятся на сроках и целях — непонятно.

Ответ про пылесос я в итоге нашел на вечнозеленом ixbt. Но с языками программирования так не получается — вменяемых материалов нет. Даже если вы неделю будете изучать реддит, то узнаете только как правильно троллить ПХПшников или что наследование в Го лучше чем в Джаве. Какое это имеет отношение к срокам и целям — непонятно.

А ответ простой — новый проект нужно начинать на стеке, с которым работает команда, способная гарантировать результат. Вы же не обсуждаете с дантистом диаметр бура, а с дворником виды метел? С дантистом вы договариваетесь о том, чтобы не болели зубы, с дворником — чтобы во дворе не валялся мусор.

Вы же менеджер, вот и управляйте проектом: договоритесь с командой о несдвигаемом дедлайне, узнайте что они будут делать, когда поймут, что не успевают. Найдите, наконец, запасную команду — пойдете к ним, если текущие ребята вас обманут. Но выбор технологий оставьте профессионалам.

Еще раз — подойдет любой язык программирования (кроме JS, конечно). Главное, чтобы те, кто на нем пишет, гарантировали результат. И у вас было, кем их заменить.

В 2017 году я развивал технологические навыки — научился делать фронтенд, писать хорошие интеграционные тесты и строить сложные пайплайны. Время в основном ушло на профессиональную и техническую литературу, так что я прочитал всего 21 нетехническую книгу. Надо срочно исправляться — это меньше двух книг в месяц.

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

Книга года — Теория каст и ролей. Алексей Крол даже через книгу работает как коуч — помогает предельно откровенно взглянуть на себя, свои возможности и планы на жизнь.

Главная художественная книга — Конец Смерти, окончание «Воспоминаний о прошлом земли» Лю Цысиня. Если любите качественную рациональную фантастику с небольшим количеством допущений — обязательно прочтите всю трилогию, лучше на английском.

Список книг 2017

Ожидал получить книгу про поведенческую экономику, которую можно советовать подросткам, а получил понятное пособие для новичков-инвесторов.

Ставки по вкладам стремятся к трем процентам, так что если ты не собираешься хранить деньги под матрасом или покупать квартиру в лесу за МКАДом, то вот пара тезисов из книги:

• Не бояться потерь. Если акции упали в цене — это не повод их продавать. Представь, что ты прямо сейчас решаешь, купить эти акции по текущей цене или нет? Если купить — держи дальше. Если нет — продавай.
• Списывать убытки. Если уж решил продавать — продавай. Пофиг, за сколько ты их покупал — ты вложился в дерьмо и дальше будет только хуже.
• Не фиксировать прибыли, если акции растут. Через 10 лет будет еще больше.
• Не играть в профессионального инвестора — если портфель из одних и тех же голубых фишек продержать 10 лет, то заработаешь больше, чем от ежемесячного перетряхивания в попытках предсказать будущее.
• Если уж пытаешься управлять портфелем — при выборе инвестиций смотри на P\E.
• Тренды и знакомые — плохие советчики в принятии инвестиционных решений (авторы, очевидно, не знали про биткоин).

Ну и банальные советы про личные финансы (если вдруг еще не):

• Кредиты — чмо. Если у тебя есть кредит по рыночной ставке — бросай все и отдавай. Кредитку разрежь прямо сейчас.
• Записывай расходы. Тогда узнаешь, что подписка на Эпл музыку стоит 2028 рублей в год, а год ежедневного кофе стоит как поездка в Штаты.
• Записывай доходы. Если вкладываешь деньги — нужно считать их эффективность. Для записи доходов и расходов, я горячо рекомендую систему Севы.
• Не храни все деньги в одном банке, или акциях одной компании.

Больше в книге ничего полезного нет.

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

Ненавидеть фичи — работа не только продуктолога, но и всей команды — дизайнеров, программистов, менеджеров и тестировщиков. Особенно важно ненавидеть фичи в стартапах.

Между простым и сложным, влюбленный в фичу программист всегда выбирает сложное. Он будет рефакторить код, менять архитектуру и делать другие программистские штуки только ради того, чтобы новой фиче приятнее жилось в системе. Не важно, что фичу не внедрят или забудут — программист любит свою работу и сделает ее хорошо.

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

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

Трезвый менеджер, наоборот, думает про цифры — на какую метрику бизнеса эта фича влияет? А что считать показателем успеха внедрения? Если ответов нет — фича режется.

Давайте экономить деньги и не любить фичи.

Самое важное в общении распределенной команды — писать так, чтобы не переспрашивали. Когда коллега из Гонконга в следующий раз выйдет на связь — никто не знает, а значит в сообщении должно содержаться все необходимое для выполнения задачи.

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

Если работаете над задачей вдвоем — используйте тесты для документирования. Написал новый эндпоинт в АПИ — дай ссылку на тесты ключевых возможностей. Исправил ошибку — выложи тест, который это проверяет.

Не пишете тесты? Откройте лучше автомойку, или завербуйтесь к газовикам на север.