Когда учиться

Вечная тема, у которой следующая вводная:

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

Ну и как и когда?

Сразу скажу, что у каждого своя жизнь, своя загруженность (полагаю, сложно выделять время, если три работы и семеро по лавкам родителя хотят хотя бы разок за руку потрогать), свои, несомненно, объективные причины как-либо критиковать предлагаемый мною далее подход, объясняя, почему вот именно этот Василий Пупкин не может и страничку в день читать. Не трудитесь. Знаю живых людей, что даже при трёх работах, лавке и прочем таки умудрялись. Т.ч. физически это возможно.
Ну и ещё важное. Вы должны хотеть учиться. Причина не так уж важна. Любовь к процессу. Понимание важности результата. От безделья и скуки. Вам в конце обещали шоколадку. На начальном этапе разницы особой нет. Главное, надо хотеть, а не тошнить над главой простенького учебника для школоты, ожидая, пока не появится даже самая мелкая и нелепая причина заняться другим. Если этого нет… ну, после 18 лет человек вроде как взрослый и убеждать его учиться невероятно скучно. Жизнь научит чередой увольнений и упущенных возможностей. Возможно, это к лучшему. Программист, которому не нравится освоение программирования, хорошим специалистом не станет.

Приоритеты: семья, работа, обязательное обеспечение жизнедеятельности. У всего остального можно подрезать время. Вы совершенно точно вынуждены чем-то пожертвовать. Не получится вести прежнюю развесёлую или бестолковую жизнь, при этом накачиваясь информацией.
Во-первых, сон. Шести часов в будний день достаточно. На выходных отоспитесь. Если накапливается усталость, спать можно 5-6-8-6-5 часов с понедельника по пятницу. В среднем те же шесть, но более мягко. Привыкайте к лёгкому недосыпанию, это нормально.
Во-вторых, развлечения. Отказаться от компьютерных игр, от постоянных гостей (если есть), отложить хобби, не ходить в кинотеатры и т.д. Кинотеатр занимает три часа в среднем. Час на дорогу и два часа фильм. Это время, за которое вы можете проработать с кодом 30..50 страниц обычного разработческого учебника из знакомой области. Достаточно 6..8 фильмов, чтобы лишить себя возможности освоить книгу по какой-нибудь технологии. Отсутствие в резюме строчки даже базового уровня может пронести вас мимо фильтров HR’ов на интересную вакансию. Стоят того «Звёздные войны против человека-паука III» или недокрашенный Pz.II?
В-третьих, совмещайте. Читать полезное можно на обеде, в метро, в очереди, на унитазе, наконец. В любой момент, когда вы тупили бы, глазея на мир или листая соцсеточки, вы можете продолжить чтение учебника. Поживите так неделю. Удивитесь количеству прочтённого. Точно так же можно поступать с развлечениями. Слушайте подкасты во время готовки (если можете отвернуться от плиты, лучше читайте). Смотрите проходные фильмы при написании кода (фильм небольшим окном в углу экрана). Листайте соцсети в коротких очередях (у кассы, например), в которых нет смысла начинать читать.
В-четвёртых, дауншифтинг. Если подумать, немало занятий, отнимающих у вас время, ещё лет 30..40 назад отсутствовали. Что не помешало человечеству создавать компьютеры и летать в космос. Читайте соцсети не чаще раза в сутки, выделите на это не более 10 минут. Заходите в Instagram раз в два-три дня, не чаще. Откажитесь от телевизора, если он есть. YouTube только для лекций и докладов. Не надо постоянно проверять почту, лучше настроить внятные уведомления. Не листайте Ali, трекеры, новости и прочее. Действительно важное и нужное мимо вас не пройдёт.
В-пятых, группируйте. Оптимальнее прочитать десять страниц подряд без перерыва, а не размазывать на день. Потому важно собранные отовсюду маленькие промежутки свободного времени компоновать в более длительные.
В-шестых, организуйте. Вы должны организовать «учебное место». Нужные книги (учебники, справочники, мануалы, гайды и прочее) должны быть в известных и доступных местах. Окружающие должны привыкнуть к тому, что в выделенное для учёбы время вас нельзя отвлекать. Для каждой темы составляйте хоть какой, но план обучения. Вам должно быть привычно комфортно читать текст и комфортно писать код.
В-седьмых, не занимайтесь фигнёй. Не распыляйтесь. Сначала выучите хорошо выбранную специализацию, потом занимайтесь смежными или потенциально полезными. Сконцентрируйтесь на том, пользу чего можете явно и честно сформулировать. Нет, junior Java developer’у не надо браться за C++, сначала полезнее превратиться в Java middle. Бесполезно всерьёз идти в machine learning, не подняв из глубин математику. Теория баз данных интересна и годнота, но практичнее сначала освоить базовый SQL.

Так вы сможете ежедневно узнавать новое. И при этом не превратитесь в скучного унылого зомби. Если научиться контролировать время в интересах дела, его точно так же можно контролировать и для безделья. Когда выходите на уверенный ритм учёбы, всегда можно вклинить что-нибудь другое. Скажем, планировали проработать 30 страниц за три часа, но попалась лёгкая глава? Проработайте за час, а оставшиеся два плановых часа можно занять худлитом, фильмом, теми же танчиками.
Нет цели ухайдокать себя невыносимым режимом бытия. Есть цель постоянно учиться, оптимизировав 24 часа в сутки.
Да и вышеперечисленные пункты… Понимаете, что занятно. Едва человек осознаёт обязательность учёбы, время находится само. Шелуха отлетает. Больным, что на терапии месяц за месяцев упорно восстанавливают подвижность конечностей, объяснять систему приоритетов не надо, она очевидна. О, Петя, не разминай мышцы, нафиг тебе нога, айда бухнём! Нет, какой-нибудь терминальный идиот пойдёт бухать, конечно, но про идиотов не будем. Так и тут. В какой-то важный момент развития разработчика приоритет учёбы заметно повышается и становится ровно так же очевиден. Если этого не происходит, в итоге не происходит и разработчик. Либо бесконечно сидит на бесконечных складах Почты России эникейщиком на треть ставки, либо уходит заниматься чем-нибудь менее напряжным для головы. Остальные корпят по ночам над талмудами.
Чего и вам желаю.

Легаси

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

Знаю, конечно. Интранет и до тебя был отличным, и как ты ушёл остался замечательным, даже лучше стал. Ты же там видел только костыли и легаси – потому что мыслишь узко. Бойцы типа тебя – не те кто инфраструктуру пилит, которую якобы не очень видно на фоне кораблей, бороздящих просторы созвездия Лебедя, а те, у которых предел мечтаний отрефакторить код, чтобы можно было прикрутить любимый (модный, надежный, whatever) фреймворк.

Так что не надо, пожалуйста, прислоняться к действительно талантливым и толковым ребятам, тиражируя мемуары. У меня всё.

Не сомневаюсь, что без меня везде становится только лучше, но любимая мозоль (легаси) была задета. Отсюда и тема.


Начну с формальностей. «Официальное» толкование термина в Википедии само по себе кажется вариантом legacy, потому озвучу свой вариант, которым в голове постоянно оперирую и который подспудно везде подразумеваю.
Легаси — код, для которого через AND (со|на)блюдается следующее:

  1. Находится в production’е, т.е. каким-либо образом используется на текущий момент.
  2. Вносить в него изменения либо невозможно, либо неадекватно дорого.
  3. Не в полной мере удовлетворяет актуальным требованиям, при этом количество таких требований со временем возрастает.

По номерам пунктов и разверну.


Во-1-х, тут вроде всё понятно. Если код не используется, его выпиливают, после чего он не проблема. Не может быть легаси то, что не крутится сейчас хоть через цепочку зависимостей.

Во-2-х. Кейс с потолка. Программа библиотечного учёта. Вроде работает, библиотекари даже прижизненный томик Льва Толстого подарили на радостях. Спустя год потребовалось добавить новое поле к карточке. Да фигня, там же тех полей и так много, скопипасть соседнее, переименуй, вот и всё, десять минут работы. Разработчик смотрит в код. Документации, к слову, нет, потому в код смотрит прям сразу. Делает чай. Смотрит ещё раз. Закуривает. Смотрит. Чертит схемы на бумажках. Добавляет сто строк кода и спустя сутки без сна рапортует об успехе. Одно поле. Сто строк. Сутки работы. Знакомо, нет? Если нет, не завидую, у вас впереди свежесть эмоций от осмысления пропасти между простотой задачи и сложностью реализации. Одна из самых характерных черт легаси. Таких задач всё больше. Каждое впиливание в легаси нового продуктового заказа делает код сложнее для впиливания следующего заказа. Лапша из костылей. Если потом упороться и собрать годовую статистику «потратили столько часов, а, казалось бы, должны были столько», волосы дыбом мурашками шевелятся. Дешевле было заново сервис написать. Год, другой, третий жуют кактус. На четвёртый героически переписывают. Ура.

В-3-х, актуальные требования. Тут четыре вектора.
Продуктовые требования. Есть простое эмпирическое правило: если хочешь получить легаси со старта, напиши сервис ровно по ТЗ. Тютя в тютю. Мир меняется, люди меняются, да чего там, гречка дорожает. Сегодня одно ТЗ, а уже через год жизни в production хотелок накидывают столько и таких, что повторно написанное ТЗ породило бы другой сервис. Хороший код обладает запасом гибкости, позволяющим менять сервис точечно, и прочности, позволяющей сохранить при всех изменениях исходную архитектуру. Легаси же этим не обладает. Потому часть задач не делается сейчас. Часть не сделается никогда. Часть делается в муках. Новых требований всё больше, нового [полезного] кода всё меньше.
Требования стабильности. Новые версии софта выпускаются не только потому, что дяденькам for fun чиселкам плюс-плюс делать, но ещё и потому, что есть security fixes, например. Или вдруг обнаруживается memory leak (который вы счастливо прохлопываете в продакшене, старательно убивая worker’ы uWSGI после малого N запросов). Или «о, блин, народ, мы тут sleep десятисекундный забыли, простите, вот новая версия». В который раз настоятельно советую читать changelog’и MongoDB и Java. Возможно, на сотом багфиксе что-то станет более понятным в контексте «надо обновляться».
Ресурсные требования. Если у вас сто машин на десять сервисов, а вам нужно ещё два сервиса добавить, но некуда, начинаете думать и смотреть с лупой на код. Мне с этой позиции интересен недавний микрокейс. Стоял nginx 1.10, в который впилили скрипт на Lua, который генерировал uuid для request’ов. Стоял давно, впилили тоже давно. Работает и ладно. Нормальный талантливый человек пройдёт мимо. Ненормальный мыслит узко и вспоминает, что в nginx 1.11 добавили штатный request_id через SSL RAND_bytes, потому что? Потому этот скрипт можно выпилить, апнув nginx. Профит. Если масштабировать этот подход к тем десяти сервисам… вот кажется, что всё-таки после массовых обновлений всего можно там выпилить, сям подпилить, вон там «само» ускорится. И потому пару машинок уже можно отобрать.
Наконец, требования современности. Код на Java 1.2 (релиз 1998 года), на дворе Java 1.9 (2017 год), на рынке джависты с опытом Java 1.6, 1.7, 1.8. Проблема ясна? Или другой вариант: в коде Django 1.6 (релиз 2013 года), на дворе Django 1.11 (релиз 2017 года, к слову, последний релиз с поддержкой Python 2.7, вдруг кому интересно ещё раз подумать о том, что такое легаси на практике). С каждой новой выходящей версией чего-нибудь теряется поддержка старого чего-нибудь. Поддержка людьми, поддержка рынком, поддержка информацией, банальная техническая поддержка («мы эту фичу сделали только с версии N.M»).

Таким макаром в самом кошмарном варианте вы получаете чудище из страшных снов разработчиков, пользователей и заказчиков: фичи не добавляются, поддерживать тошно, ресурсы жрёт как не в себя, болтается на стремительно устаревающем техностеке, дырявое аки решето. Самое время, чтобы подумать «ой, чёт хочу вкрутить свой любимый фреймворк, надо бы порефакторить!» ^_^
Самое, пожалуй, фиговое, что заполучить легаси очень просто. Достаточно поступать вот так:

  • Генерируйте велосипеды, подключайте велосипеды. Наверняка они не будут заброшены авторами. Всегда интереснее тащить в будущее сервис с десятью полузаброшенными велосипедами, чем скучно апать версию популярной библиотеки.
  • Техдолг откладывать. Нет, сегодня мы не обновимся, есть дела важнее. Завтра тоже. И через месяц. Вот планы на год, обновления тут нет. Всё и так работает.
  • Думать некогда. Делать правильно некогда. Надо делать быстро прямо сейчас, решая именно текущие задачи. Когда появятся другие задачи, тогда и подумаете, как их в код впилить. Или не вы, но другой Вася, его ни капли не жалко.

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


Так вот. Привычку не видеть легаси, создавать легаси, оставлять легаси и не уничтожать его следует выжигать калёным железом по маковку. Если вы этого не делаете, вы не разработчик и не программист, вы вредитель. Быть вредителем плохо.

Проблемы больших компаний

6 месяцев назад положил свой значок и пистолет бейджик на стол и ушёл из Яндекса. Проработал там достаточно долго линейным бульдозеристом в разных подразделениях, чтобы в итоге по ряду тем заполучить твёрдое понимание «как [не] надо». Как во время работы, так и после не раз общался с коллегами из других больших компаний. Также много читал инсайдов о том, как работается в мировых гигантах. Мнение имею. Далее совокупность этих компаний буду называть Гуяндбуком.
Мнение хочу озвучить по двум причинам. А — оно само вот лезет, деваться некуда. B — иногда спрашивают, стоит ли идти работать в Гуяндбук. Совмещу оба пункта в одном тексте.

Первое обязательное предисловие. Я знаю, что читатели не умеют читать. Знаю, что часто читается текст в собственной голове, а не с листа. Потому подчеркну: благодарен за годы полученного опыта. Видел много хорошего, встретился с многими хорошими людьми, хорошо делающими своё дело. Ни в коем случае это эссе не надо принимать плевком в спину «бывшей». Это глупо. Не менее глупо игнорировать характерные для топовых компаний черты. О чём и напишу.
Второе обязательное предисловие. Нет единого Гуяндбука. Всегда это набор сотен подразделений, многие из которых друг от друга сильно отличаются. Вася, сидящий в группе разработки оконных решёток, будет с большими глазами смотреть на порядки в группе доработки пластикового паркета, пусть даже находятся на одном этаже. Потому текст далее наверняка будет читаться одними с полным пониманием, другими с полным непониманием. Отсюда, кстати, ещё один хинт: вы нанимаетесь не в Гуяндбук, вы нанимаетесь в конкретное подразделение к конкретному руководителю на конкретные задачи. Иногда это знание теряется при поступлении, потом наступает закономерное разочарование.
Третье обязательное предисловие. С некоторых пор мне стало важно понимать, на что трачу жизнь. Не абстрактное время. Именно жизнь. Дана один раз, разумной сознательной части в ней не так уж много (до 20 лет идиот, после 60 лет боюсь загадывать, итого всего 40 лет). Как работа влияет на меня? Какое развитие она мне даёт? Становлюсь ли более годным специалистом или деградирую? Потому и оценка компаний с этой позиции. С вашей, конечно, будет оценка своя. И с моей может ни разу не совпасть. Точно знал двух бойцов, которым описанное ниже было норм, т.к. позволяло сидеть на месте, что-то делать от звонка до звонка и не париться. Солдат спит, служба идёт. Мне же теперь интересно равновесие наносимой и получаемой пользы без перекосов.
Начну с душеспасительного. Если вы junior и хотите получить опыт, вам обязательно пойти в Гуяндбук. Уже за год освоите столько, сколько в гараже за пять лет не впитать. Даже если целыми днями сидеть на стуле посреди опенспейса, из окружающих разговоров узнаете много полезного. А всякие соц.пакеты, печеньки на кофепоинтах, офисы какого-нибудь А-класса… в общем, старт годный, если голова на плечах есть. Любая задача кажется интересной, потому год пролетит как свист между молочных зубов.
Дальше менее душеспасительное.

Если совместить все пункты ниже, получится пункт, который можно было сделать нулевым в списке. Каждый рабочий день вы будете сталкиваться с ним. Каждый рабочий день вы будете тихонько (иногда громко) фейспалмить. Едва ли не каждая задача в Гуяндбуке будет делаться дольше нормального по объективному (в контексте компании) набору причин. Но всегда дольше. Это уныло. Итак…

Во-первых, адовое обилие встреч. При этом большинство либо бестолковы по самой своей сути, либо бестолково проходят. Мало того, что вы встречаетесь о том, следует ли провести встречу, которая резюмирует резюме встреч о встречах. Вы будете ждать опаздывающих. Потом будете пережидать обязательные шутки. Потом окажется, что кто-то не в теме и ему надо на пальцах объяснить. Потом окажется, что есть тема важнее, потому вот именно текущую тему мы обсудим на следующей встрече, а эту встречу посвятим другой теме, но вот уже и время закончилось, потому давайте встретимся отдельно про другую тему. Достаточно четверым в неделю провести по две часовых встречи в таком режиме, как за месяц потеряются четыре рабочих человекодня (за год, соответственно, в пустоту два полных человекомесяца). А встречающихся сотни. А часов тысячи.
Плюсом то, что получаете полезный опыт ненависти к встречам (раз) и понимание, как всё-таки провести встречу результативно (два).
В нормальной небольшой конторе вы минут 20..30 точечно обсуждаете ровно то, что надо, ровно тогда, когда надо. Или по пути на обед. Или в Slack’е в чате на N человек.

Во-вторых, адовое обилие легаси. Можно с закрытыми глазами за спину бросить мячик и попасть в код, который писал Вася (админ), который уволился до Пети (фронтендер), который недопереписал код, который теперь формально поддерживает Коля (бекендер), который ни фига не поддерживает, ибо Колю уже тошнит от этой навязшей на зубах фигни, которая, тем не менее, в зависимостях у пяти сервисов, которые тоже то ещё легаси, ведь ни у кого нет времени перетащить цивилизацию из прошлого века в нынешний век, хотя бы в его начало. Об легаси вы совершенно точно будете спотыкаться. То невозможно обновить какой-нибудь пакет, т.к. ломается. То невозможно проинтегрироваться с другим сервисом, т.е. там из рабочих рук одна десятая землекопа, а надо переписать часть кода. То вам просто надо сделать что-то с кодом полезное, а он представлен в виде вот этой всей ботвы, к которой тонна вопросов, но ни одного ответа, кроме «по историческим причинам». Тоже не самая продуктивная трата времени. Особенно интересно читать новости о новых версиях языков, технологий, софта. Только читать, ибо к ржавому сейнеру модерновый комплекс ПВО не прикрутить.
Плюсов немало. Лучше понимаете [многолетний] жизненный цикл продуктов (раз), получаете в голову ворох обкатанных [не]работающих решений (два), набиваете глаза и пальцы на возне с сотнями тысяч строк самого разного чужого кода (три), снова зарабатываете полезную ненависть к легаси (четыре), учитесь учитывать множество факторов при любом изменении системы (пять).
В нормальной небольшой конторе вы обновляетесь достаточно быстро. Бывают острова легаси, безусловно. Но их вполне по силам либо переписать с нуля, либо пинками загнать в светлое будущее в разумные сроки. Риски обновления обозримы, усилия на переходы тоже.

В-третьих, адовое обилие руководителей. В какой-то момент времени в одну из забав перестановок мест и сумм в вертикалях власти от меня до Самого Главного было восемь (девять? забыл уже) хопов. Учитывая обилие всякой руководящей волокиты (от «окнуть уход Иванова в декрет» до «появиться на двадцати встречах в неделю»)… Нет, правда, у меня сердце кровью обливается, когда прикидываю, сколько человекомесяцев тратят Гуяндбуки на то, чтобы решения, бумажки, утверждения, синхронизации и прочая клюква гуляли по этому развесистому руководящему графу. Неприятный нюанс ещё и в том, что такая толпа людей с разного рода властью неизбежно порождает политоту, дипломатоту и прочую интриготу, с которой нормальный инженер дела иметь не хочет.
Плюсы есть. Если долго наблюдать за руководителями, учитесь разбираться в том, что такое хороший руководитель, а что плохой (раз). Также наблюдения помогают понять, какие дыры в процессах, кем и зачем закрываются (два).
В нормальной небольшой конторе множество руководителей просто некуда девать, потому их мало и они по делу.

В-четвёртых, болото инерции. Гуяндбуки протеряли гибкость своей молодости. Точечно она выделяется на передовые и экспериментальные подразделения, а вот массовое… там, где небольшой бизнес утром обсудил проблему, днём принял решение, а вечером реализовал, Гуяндбук потратит месяцы. С одними согласуй. До других донеси. Третьих убеди. Четвёртых предупреди. Пятые мимо проходили, но хотят поспорить. Шестые и седьмые зависимы от перемен, потому обеспечить миграцию, а у них лапки свои планы. Восьмые хотят поучаствовать, но со своим самоваром. В итоге затяжной цирк, тонущий в бесчисленных встречах и согласованиях.
Плюсом всё та же ненависть, но к болотам (раз), ну и умение упорно продавливать свои решения через это желе (два).
В нормальной небольшой конторе вы не тратите десятилетия на десятки людей с их тараканами просто потому, что контора небольшая и см. пункт «в-шестых».

В-пятых, большой, но замкнутый мир велосипедов. Гуяндбук настолько заполняет собою голову, что теряется связь с реальностью. У нас самые крутые разработчики (далеко не все), самые интересные задачи (далеко не всегда), самые передовые решения (далеко не везде). Такая элитарность здорово мешает объективно оценивать людей, процессы, результаты. Внутри городится огромная стоянка велосипедов (больше всех радует Alibaba, пропатчили собою всё от Linux до Java), умением кататься на которых вы и будете щеголять в дальнейшем.
Плюсом лишь нелюбовь к велосипедизму. Достаточно N раз пытаться пристроить к делу бестолковое внутреннее наколеночное, чтобы больше не хотеть никогда.
В нормальной небольшой конторе нет никакого желания тратить ресурсы на велосипедизм. Это слишком дорого как тактически, так и стратегически.

В-шестых, далеко от причастности. Попробую яснее сформулировать. Вы продавец в магазине фруктов. И одновременно владелец. Чем больше поработаете и чем больше продадите, тем больше ваш вклад в дело и тем больше причастность. В этом примере 100%. Другой пример. Вы продавец в отделе фруктов в сетевом агросупермаркете. Ваш вклад всё ещё виден и ясен, но он небольшой и от дела вы далековато. Третий пример. Вы продавец в отделе цитрусовых фруктового направления сетевого универсального супермаркета с миллионом сотрудников. Сеть являет собою конгломерат бизнесов от добычи речного песка до выдачи кредитов. С причастностью всё плохо. Стремится к нулю. Вот в Гуяндбуках та же фигня бывает, если вы не попали в те гениальные 5% ключевых для бизнеса сотрудников (как Себастьян Трун в Google, например). Вроде постоянно работаете. Сотни, тысячи тикетов переработаны. Сотни тысяч строк кода. Но с какого-то момента у такой вот линейной рабочей лошади возникают неприятные мысли. Кто я? Что я здесь делаю? Зачем всё это? На самом дне таких размышлений можно удариться об «я никто, которого можно заменить в любой момент таким же никем».
Повторюсь другими словами: речь о бойцах типа меня. Не ключевой творец компьютерного зрения, не прорывной дядька в машинном обучении, не двигаю отрасль беспилотников. Просто клепальщик и строгальщик. Так вот таким бойцам в больших компаниях никак. А выбраться из этой ямы под грузом повседневной текучки очень трудно, особенно если вне работы жизнь есть. Фигня ещё и в том, что вокруг много таких же. Результатом плохое: нет единого осознанного движняка в сторону финишной ленточки. Люди закапываются в процессы, перекатывают из пустого в порожнее, вообще теряют цель работы. Просто что-то делают, чтобы в трекерах были тикеты.
Плюсом более чёткое понимание расстояния от бизнеса / целей / ценностей работодателя, на которой вам комфортно.
В нормальной небольшой конторе любой чих влияет на всё, каждый сотрудник представляет собою ценность.

При всё вышеописанном не следует рассматривать Гуяндбуки строго негативно. Там есть отличные специалисты, у которых стоит учиться. Есть интересные решения. Есть ресурсы, которые позволяют решить задачи, принципиально недоступные небольшим конторам. Если вам повезло попасть в годное подразделение, получите отличную школу разработки со всем приятным и нужным фашизмом в виде code review, CI, планирования, нормальной ролевой системы (при которой школота не спрашивает, а нафига вообще менеджеры или тестировщики). Вообще до фига всего полезного. Но такое бывает не так часто, как хотелось бы.
Работал в Гуяндбуке достаточно долго, чтобы пообщаться (или просто пронаблюдать) с десятками (а то и сотнями) уволившимися людьми (вполне толковыми специалистами, а не выпиленными после испытательного срока раздолбаями). Выгорание и потеря смысла в такой работе. Это основная причина наравне с деньгами. Рано или поздно, но приходит к каждому, кто фигачит не на расслабончике. Я от такого успел устать и больше не хотеть никогда. Тем более, слишком резкая и явная разница с теми же пунктами на текущей работе.
Возможно, не то делал. Возможно, не с теми общался. Возможно, просто не мой формат работы, при которой перед глазами проходят сотни лиц ногами и говорящими ртами. Знаю людей, которые счастливы в Гуяндбуках. Им хорошо и даже прекрасно. Глаза горят. Потому… воспринимайте это эссе через призму своего собственного опыта, ну и в целом критически. В вашем мире всё может оказаться совсем не так.
Аминь.