Всем привет.

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

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

О профессиональном выгорании

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

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

Для себя я сформулировал два тезиса, которым придерживаюсь:

  • «Я люблю челленджи только в рабочее время».
  • «Пусть лучше оно сломается у меня сейчас, чем когда-то потом у клиента, когда я буду отдыхать».

Все дальнейшие мои действия следуют из этих двух принципов.

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

  • Не бери на себя больше, чем можешь вытянуть, но и не переставай самосовершенствоваться. Культ суперзвезд и переработок разрушает креативную деятельность. За примерами можно сходить в книгу «Кровь, пот и пиксели».
  • За редким исключением переработка только вредит и тебе и тому, на кого ты работаешь. Важно научиться аргументированно говорить «Нет» на задачи и предлагать альтернативы.
    • Участвуя в этой гонке ты «перестаёшь видеть лес за деревьями»: вместо того, чтобы вложиться в анализ проблем, ты занимаешься только тушением пожаров, от чего проблемы не заканчиваются, чего не сказать про твои нервные клетки.
    • Когда ты необоснованно рискуешь – часто подводишь не только себя, но и тех, кто положился на тебя и посчитал, что никаких рисков нет. А потом «эффект домино» накрывает кучу людей. В итоге это ещё и подорвёт доверие к тебе, оно тебе надо?
  • По моему опыту больше всего выгорают именно руководители. Сейчас к тимлидам в ИТ столько требований, что пора распрощаться с иллюзией, что став босом ты будешь чилить в большом кресле и раздавать команды миньонам. С тебя будут спрашивать за результат начальство, а подчиненные будут требовать от тебя внимания к своим проблемам. Сейчас в ИТ битва за кадры, а не за компании. Тебе придётся к ней присоединиться.
  • Старайся оставлять работу на работе. Отдохнувший мозг сам потянется к саморазвитию, что приведёт к лучшим результатам и на работе.

О мыслетопливе

Многие думают, что при интеллектуалном труде мы что-то не успеваем потому, что у нас не хватает времени. На самом деле проблема нехватке мозга (mind power или «мыслетопливо»). Чтобы быть более эффективным старайтесь его всячески разгружать и не напрягать лишний раз:

  • Заведите блокнот для записей, научитесь ставить напоминалки. Тут я в очередной раз рекомендую посмотреть доклады Максима Дорофеева.
  • Отключите интернет на телефоне или хотя бы лишние нотификации, которые постоянно отвлекают нас от работы, делая её ещё более тяжелой.
  • Очень полезны медитативные прогулки, когда есть время спокойно подумать о смене подходов к работе, вместо того, чтобы продолжать делать так, как делали. Заодно можете послушать подкасты и тем самым развиваться.
  • Старайтесь выделять время для работы в «состоянии потока» – он реально способен вынимать из мозга такие идеи, которые при рваном ритме работы вряд ли придут вам в голову.

О здоровье

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

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

О личном бренде

Личный бренд – это важно. Несмотря на то, что вакансий больше, чем людей, за реально хорошие места придётся бороться. Он помогает не только предрасположить к себе интересные компании и коллег, но и:

  • Позволяет добиваться лучших результатов в работе: навыки публичных выступлений, написание текстов позволяют лучше находить контакт с людьми, от которых может зависеть успех вашей работы.
  • Становится драйвером к изучению новых областей: как раз по этой причине я поставил себе цель переехать с BlogSpot-a на отдельный домен и познакомиться на практике с движком статических сайтов Hugo. Я «допилил напильником» несколько понравившихся мне шаблонов, и вот теперь у меня есть красивый сайт, блог и наконец-то привёл в порядок свой cv 😄

О саморазвитии

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

Но чтобы не подвергнуться прокрастинации я редко когда записываю что-то «посмотреть потом». Я либо читаю/смотрю это прямо сейчас, либо дроблю на простые задачи и систематически выполняю их небольшими порциями. Именно так я осилил переписывание более 30 постов старого блога под новый сайт 😄

О спортивном программировании

Если вам не посчастливилось получить хорошее профильное образование по Computer Science в вузе, то решение задач по программированию – это то, в чём явно стоит себя попробовать. Речь не идёт о том, что вам непременно надо стать профи в этой области: изучить большое количество классических тем и зазубрить кучу «именных алгоритмов». Речь о том, чтобы, порешав даже достаточно простые олимпиадные задачи (они тоже есть на соответствующих сайтах!), развить в себе достаточно базовые навыки, без которых сложно представить хорошего программиста:

  • Написание кода без ошибок в достаточно добром темпе.
  • Придумывание тест-кейсов.
  • Культура построения доказательств корректности алгоритмов до их реализации.

Вы не поверите, насколько продуктивней станет ваша работа и спокойней сон, когда вы почувствуете большую уверенность в своих программах 😄

Даже поверхностно изучая эту область вы оцените различные красивые идеи и неочевидные подходы, результатом применения которых сможете приятно удивить себя и коллег, что скажется на вашем продвижении по работе 😄

Об эмпатии к пользователям

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

Лечим синдром «Это всё сложнааа»

Читаем книги и статьи от экспертов в этой области UI/UX, для которых удобство пользователей намного важнее простоты реализации.

Лечим синдром «Этим будут пользоваться другие»

  • Используем свой программный продукт в своей же повседневной деятельности. Были слухи, что при разработке Android OS у разработчиков отбирали все другие телефоны, чтобы они писали код так, чтобы смогли в случае экстренной ситуации позвонить домой.
  • Практикуем gemba: выходите на реальное место работы человека, который пользуется вашим продуктом, и смотрите насколько удобно вам работать с вашим же софтом выполняя бизнес процессы.

О разных режимах работы

Эту мысль я узнал от Григория Бакунова: «Разработчик должен уметь работать в двух режимах – быстро и хорошо». Если перед нами задача написать прототип, небольшую утилиту или проект, который вряд ли будет меняться – качество кода в нём не так важно, как скорость получения результата. Если же перед нами стоит задача разработать систему, которая будет развиваться, отражать сложные, а, порой, и нелогичные с точки зрения разработчика, бизнес-процессы и станет критически важной основой для успеха бизнеса – качество принятых высокоуровневых решений (процессных и инженерных) и низкоуровневых деталей реализации должно быть максимально высоким.

Если «говнокодить» мы все умеем, то где черпать мудрость для разработки, когда надо «хорошо»? Я начитался уже много чего, но больше всего меня зацепила тема Domain Driven Design. Она отлично сочетает в себе практики «чистого кода» и «чистой архитектуры» и происходит от стремления уменьшить когнитивную нагрузку на людей при реализации сложных бизнес-доменов. Кажется, это тот ответ, который мы давно ищем в области реализации проектов по автоматизации бизнес-процессов. Если вас эта тема заинтересовала – рекомендую прочитать книгу «Implementing Domain-driven Design», которая описывает как фундаментальные основы подхода, так и практические паттерны решения непростых технических проблем с достаточной детализацией.

Смирись, что иногда придётся «садиться за парту», когда уже закоммитился сдавать задачу. Это будет уроком на будущее. Никому не нужен «говнокод, но сейчас» в критичных местах проекта:

  • Работаешь с бд – должен уметь хорошо проектировать схему данных; понимать, что умеет и не умеет делать твоя БД.
  • Вводишь разделение данных в микросервисах – должен знать про распределённые системы.
  • Пишешь высокопроизводительный компонент – должен знать как работает runtime языка, память, процессор «под капотом».
  • Используешь ненадёжный язык или компоненты – запасайся дополнительными тестами.

О контроле ожиданий заказчиков

“The most important single aspect of software development is to be clear about what you are trying to build.” - Bjarne Stroustrup

По моему опыту наилучший эффект достигается тогда, когда люди максимально честны друг с другом. Практика «заметания сложности под ковёр», когда мы не хотим потерять авторитет как профессионала и хотим выглядеть героем, как раз и ведёт нас к провалу. Во-первых, люди не умеют читать мысли друг друга. Во-вторых, адекватный заказчик редко когда «просто пушит, чтобы пушить». Нужно понять конечные цели друг друга, а не поддаваться поиску локально-оптимальных решений. Исход «Win-Win» – это то, к чему надо стремиться.

Поэтому полезно:

  • Заниматься декомпозицией задач до оценки сроков. Часто бывает, что оценка целой задачи зачастую меньше суммы оценок её подзадач.
  • Не обещать делать задачу, в которой ничего не понимаешь! Самообразование и pet projects вам в помощь.
  • Договориться с заказчиком обо всём «на берегу»:
    • Доводите до заказчика проблемы, которые собираетесь решать.
    • В сложных ситуациях придётся поделить риски.
    • Проговорите что вы делаете, а что не делаете.

О корректности кода

“Good code is its own best documentation. As you’re about to add a comment, ask yourself, ‘How can I improve the code so that this comment isn’t needed?’ Improve the code and then document it to make it even clearer.” - Steve McConnell

Только Сode Review и Design Review способны находить баги в логике и дизайне систем. Именно они должны использоваться для проверки сложных алгоритмов. Тесты способны найти проблемы, но не доказать, что их нет.

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

О рефакторинге

Ответственное отношение к структуре кода очень важно. Заставить компьютер достичь нужного результата можно разными способами, разделить компоненты системы – тоже. Но не за все из них тебя потом похвалят твои коллеги. Надо смириться с тем, что редко когда в самом начале можно предусмотреть направление развития проекта. Постоянная адаптация структуры программы под изменяющиеся условия – критически важный процесс, чтобы кодовая база не скатилась в состояние, когда её проще сжечь, чем отмыть.

Поэтому:

  • Используйте хорошие IDE, которые в состоянии помочь сделать безопасный рефакторинг для вашего языка программирования в более чем одном файле.
  • Если автоматика вам не помогает – тесты ваше единственное спасение.
  • Если что-то настолько поменялось, что его название теперь некорректно отражает суть – это надо переименовать. Если нельзя атомарно обновить всех клиентов – принципы поддержания обратной совместимости вам в помощь.
  • Правильный нэйминг – это непросто. Развивайте свой словарный запас.
  • Не бойтесь длинных и выразительных имён, используйте естественные контексты (объекты, функции), чтобы имена оставались понятными и не слишком длинными.

О рабочем окружении

  • Заведите себе нормальную IDE, которая помогает быстро выполнять частые операции и не раздражает своей тупостью.
  • Заведите себе нормальное рабочее окружение в проекте. Если какая-то операция сложна (первоначальная настройка, запуск тестов) – её не будут выполнять так часто, насколько это необходимо.
  • Заведите себе нормальную механическую клавиатуру, которая вкупе с автокомплитом приличной IDE поможет не жертвовать понятностью кода ради скорости печатания. Ну и это просто постоянный источник тактильного кайфа, попробуйте!

На этом пока всё 😄 Надеюсь, что мой опыт будет вам полезен.