Burn out нечаянно нагрянет, когда его совсем не ждёшь. Когда человек впервые сталкивается с профессиональным выгоранием, у него возникают вопросы:

— Что со мной: осенняя хандра, депрессия или профессиональное выгорание?
— Что с этим делать?
— К кому идти за помощью?

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

Поэтому так важно разобраться в проблеме заранее, понять, что проблема решаема — и решаема разными способами.

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

Я обратился за разъяснениями к психиатру Максиму Малявину. Хобби Максима не раз спасало меня от плохого настроения, а быть может и от начала профессионального выгорания. Его «Психиатрические байки» способны спасти от серости и печали будней не хуже, чем волшебная пилюлька бромдигидрохлорфенилбензодиазепина. А книги Максима «Записки психиатра, или Всем галоперидолу за счёт заведения!» и «Новые записки психиатра, или Барбухайка, на выезд!» давно прописались на моей книжкой полке.

Я в тестировании 12 лет, работал в Naumen и Яндексе. Сейчас руковожу отделом тестирования из 150 человек в Контуре и продолжаю работать тестировщиком в одной из команд.

После полугодовых performance review менеджеры из разных команд рассказали, какие цели поставили своим тестировщикам. У каждого пятого была такая: «Научиться оценивать сроки на тестирование задач». Часто такой «оценки сроков» хотят не только от тестировщиков, но и от разработчиков.

Оценка сроков в 95 % случаев. Спасибо, xkcd.

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

Сейчас объясню, как это работает.

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

Мы выбрали пути развития руководителей разработки темой следующего Team Leader Meetup, который пройдёт вечером 28 ноября в московском офисе Яндекса. Обсудить эту тему можно будет с экспертами из крупных IT-компаний. Регистрация ещё открыта.

В этот раз нашими экспертами стали:

• Николай Крапивный, руководитель бекенд-разработки, Badoo
• Роман romas1982 Ивлиев, CTO, mos.ru
• Александр Поломодов, руководитель отдела исследований и разработки, Tinkoff.ru
• Борис Тоботрас, директор центра программных решений, Инфосистемы Джет
• Виктор Ламбурт, руководитель направления рекомендательных продуктов, Яндекс
• Игорь Кураленок, генеральный директор, Лига Экспертов

Сегодня на Хабре мы задаём им ряд вопросов, чтобы задать тон будущей дискуссии:

1. Какие советы вы бы дали вашему коллеге – сильному разработчику, который недавно, буквально вчера, стал тимлидом? С каких конкретных, понятных действий ему стоило бы начать свою работу в новой должности?
2. Какие книги или статьи вы бы порекомендовали прочитать руководителю разработки? А какие ресурсы имеет смысл изучать на регулярной основе?
3. Сколько времени стоит уделять работе над техническими задачами, а сколько – над задачами, связанными с управлением коллективом? На что ещё может или должен тратить своё время тимлид?

Предисловие

Данный текст предполагает, что читатель ознакомлен с т.н. agile-манифестом разработки программного обеспечения и его т.н. основополагающими принципами.

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

Содержание

1. Манифест жёсткого программиста
2. Основополагающие принципы манифеста жёсткого программиста
3. Комментарии

Манифест жёсткого программиста

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

Концепция важнее новых требований
Качество важнее скорости
Делать как надо важнее, чем делать как просят

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

• модели регрессии Пуассона;
• методы random forests (случайных лесов);
• методы ранжирования (по силе команд исходя из спаррингов за 2010-2018 года и по коэффициентам в букмекерских конторах).

Моя личная история трейдинга, все совпадения случайны.

Я начал свою карьеру в HFT в австралийском филиале одной из крупнейших американских трейдерских компаний в качестве программиста на C++. В первый день меня встретил офис с огромными окнами с видом на сиднейскую гавань, на одном из которых было написано фломастером “< 2ms”. Это было главной задачей для дюжины разработчиков, но, пока что, не для меня. Итак…

a = 1
a = a + 1
print(a)

Большая четвёрка

Пожалуй, непопулярное мнение (и тут немного иронии от меня).

Чтобы быть способным и отличным инженером, вам не нужно писать статьи в блоге, участвовать в проектах open source, выступать с техническими лекциями или делать что-нибудь ещё.

Можете оставить свой код в офисе — и это вполне нормально.