О сроках 2

Хорошо работает только планирование рутинных задач. Типа “добавить отчет”. Если мы уже делали похожие отчеты, то примерно знаем, сколько на них нужно будет потратить времени, накидываем ±пару дней и спокойно едем. А вот всякие околоисследовательские штуки, или что-то неизвестное можно только ограничивать временем вроде “давайте попробуем потратить 5 дней на исследование а дальше посмотрим”. Ну это тоже такое себе планирование, потому что может оказаться что 5 дней мало, дальше берутся еще 5, потом еще, потом еще и вот уже два месяца ушло и только теперь стало ясно куда можно копать дальше.

О сроках 1

Самая большая проблема разработки — сроки. Бизнес любит ставить сроки (а как работать-то, без них?), разработчики не любят называть сроки, менеджеры любят занижать сроки, а в итоге они всегда продалбываются. В чем я точно уверен — так это в том, что сроки на длинном временном промежутке планирования (год, а то и меньше) 100% будут сорваны. Даже если не изменятся требования (а они изменятся), не будет смены приоритетов (а они будут), не будет меняться состав команды (а люди будут приходить и уходить), и будут заложены буферы (работа занимает столько времени, сколько на нее отводится).

Нужно на вчера, давай быстрее

Крайне распространённая манипуляция — ”нужно на вчера”. “Нам нужно срочно закрыть вакансию, не могли бы вы выйти пораньше?”, “Два дня на подумать”, “Багу срочно нужно пофиксить”, “Фичу срочно надо выкатывать”, “Никто, кроме тебя это не сможет сделать” и так далее. Так вот, ничего не случится, если человек выйдет на две недели позже. Вы и так уже ищете два месяца подходящего, не подождете еще две недели? Допустим, я ищу работу. Последнее, что стоит делать — соглашаться на первое предложение и отметать будущие возможные варианты, даже не рассмотрев их.

Менеджеры-белки (истерички)

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

Слабоумие и отвага

Главный движитель карьерного роста — готовность бесстрашно брать на себя ответственность. Когда долгое время работаешь простым разработчиком то как-то привыкаешь что все решения принимают за тебя — как делать продукт, какие технологии или стек выбирать, как развивать команду, куда расти тебе лично (менеджеру, ему же точно виднее). В этом мирке очень ценятся люди, которые не очкуют встать и сказать — ”вот это сделаем так и так, я готов взяться/возглавить”. Когда я только начинал менеджерить и беспокоился о решениях, которые нужно было принимать, то мой босс все время твердил — ”лучше предложить хоть какой-то план, даже если он не очень хорош и взять на себя ответственность, нежели вообще ничего не делать”.

Зачем ходить в офис

Вот уже два года как я работаю удаленно. В интернетах полно материалов на тему почему удаленная работа хороша, или почему хорош фриланс (это разные вещи, если что), как начать и вот это все, фокусируясь на достоинствах удаленки. Спустя пару лет могу подтвердить, да, все действительно так. Не врут. Зачем же ходить в офис? Существенным недостатком удалённой работы из дому для меня является отсутствие социализации. Человек — животное социальное, и видеть и разговаривать с другими людьми лично, а не через интернет — обязательно.

Неразглашение зарплаты

Компании часто добавляют в договора пункты о неразглашении зарплат а руководство с HRами еще и грозит анальными карами и санкциями за нарушение этого пункта. В конторе где я раньше работал один из руководителей прямо заявлял — за разглашение зп увольняем сразу. О прецедентах никто не слышал, но все боялись. Что интересно, в советские времена такого не было — все знали зарплаты друг друга. Социализм во все поля! Приходишь в бухгалтерию, расписываешься в ведомости и там видишь зарплаты всех остальных.

Удаленная работа в офисе

В больших корпорациях часто есть множество офисов, рассосредоточеных по всему миру. В конторе, где я раньше работал, было 2 офиса в Украине, 5+ офисов в РФ и бесчисленное количество команд, которые сидели у заказчика по всем странам и часовым поясам мира. Из-за большого количества проектов, практически всегда команда собиралась из разных офисов. Очень редко было такое, что все сидели в одной комнате. Но, что интересно, не так редка была ситуация, когда человек был единственным, кто работал на проекте из его окружающих.

Прогресс регресс

Уже несколько лет подряд я ретроспективно оцениваю решения и поступки которые совершал в прошлом году. И каждый раз думаю — “черт, как я мог творить такую дичь? зачем я в это вписывался? зачем соглашался? почему не приложил больше усилий для?”. Что характерно, история повторяется каждый год. То есть вроде бы и думаешь — “ну все, в этот раз такой шляпы не будет”, а нет, проходит год и опять понимаешь что делал дичь.

Тьюринг-полные круды

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

Беспомощность

Обычно у разработчиков не возникает проблем с решением задач. Поисковики, стековерфлоу, куча мануалов, в принципе все типовые задачи уже давным-давно решены, а нетиповые — так их делают опытные люди. За всю карьеру полностью прочувствовать свою беспомощность и неспособность справиться с задачей меня угораздило только один раз (ну и еще было много других мелких случаев, когда просто задача давалась тяжело, но удавалось как-то разрулить). Дело было в 2009-2010 году — работал я значит в корпорации, подпиливал свой маленький (тогда) продукт, в ус не дул.

О работе над продуктом

Почти всю свою карьеру я так или иначе занят в продуктовой разработке. Помимо продуктов я делал собственно демо-проекты и разнообразные прототипы других продуктов. На старой работе у нас был такой термин “продуктизация”. Это когда бралось решение, сделанное кастомного под определенного заказчика, творчески переосмыслялось и впихивалось в продукт. Идея была в том, что эта кастомная функциональность могла бы пригодиться кому-нибудь в будущем. Одной из моих задач, как технического руководителя одного из продуктов, было отбиваться от запросов на такие всякие разные продуктизации.

Производительность веб-сервисов

До сих пор люди иногда спорят о скорости программ, написанных на том или ином языке или платформе. Хотя тренд значительно пошел на убыль и редко где услышишь “Java тормозит” или “1 000 000 конкуррентных подключений на node.js” но время от времени все равно этот вопрос подымается. Так вот. У меня в продакшене уже несколько лет крутится куча сервисов, часть на JVM, часть на Rails, часть на Python, часть на PHP, парочка на node.

О стеклянном потолке 3. Оффлайновый бизнес

Предыдущие части: первая, вторая. Многие люди ненадолго погрузившись в сладкие обещания, которые нам вещают со страниц книг, буллитов презентаций, сцен залов всевозможные бизнес-тренеры, рано или поздно задумываются о своем деле. В качестве такого “своего” дела часто выбирается какое-то оффлайновое предприятие — магазинчик китайского барахла, фургончик с фастфудом, СТО или похожие активности. Будущие бизнесмены мечтают о том, как они вложат десяток тысяч баксов, поставят все процессы на поток, а сами укатят на #сказочноебали лежать на пляже и любоваться закатами.

Вранье на собесах

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

Почему нужно нанимать джунов

Я горячий сторонник найма джунов. Нанимал кучу джунов когда работал в большой корпорации, а потом нанимал уже к себе в компанию и платил им из своего кармана. Сейчас не нанимаю, потому что работаю практически сам, да и карманы опустели 😄 Убежден, что любая контора, которая зарабатывает хоть какое-то бабло просто обязана нанимать джунов, и вот почему. Улучшение и формализация процессов. Когда у вас на борту не самые опытные бойцы, такие вещи как CI/CD, статические анализаторы кода, тесты, код ревью и автодеплой становятся просто обязательными.