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

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

И, разумеется, необходимо упомянуть случай, когда именно ваш код стал причиной такого крупного и громкого сбоя (ха-ха, смотрите, я нашел виноватого!). Если серьезно, не берите в голову. Делайте то, что вы бы сделали, найдя у себя ошибку при более спокойных обстоятельствах. Сделайте выводы, разберитесь, почему все пошло не так, извлеките пользу из этого происшествия. Черт, вы можете даже немного гордиться им. Если ваша ошибка отключила и сожгла сервер, можете называть себя Повелитель Огня.

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

Тезисы

■ Поиск виноватых – пустое и глупое занятие.

■ Если ошибка уже случилась, займитесь ее исправлением.

■ Не упрекайте себя за ошибки, набирайтесь опыта, делайте выводы.

■ Чем крупнее ошибка, тем ценнее вынесенный урок.

Задание

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

История из жизни

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

Холивары

Ничто так не занимает некоторых разработчиков, как возможность зацепиться с кем-нибудь языком на тему, почему технология A лучше технологии B и почему язык программирования X подходит для решения любых задач, а язык Y – полное дерьмо. Споры между людьми, существующие столько же, сколько существует человечество, с появлением IT-индустрии получили новую жизнь и новых последователей.

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

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

Люди эволюционно запрограммированы собираться в стаи. Они чувствуют себя спокойнее и увереннее, если разделяют принципы какой-либо группы и придерживаются их (да, огромное количество преступлений против человечества было совершено по этой причине). Старайтесь руководствоваться здравой логикой. Пусть вы терпеть не можете технологию Х, но скажите, по какой причине вы бы стали отговаривать кого-то от ее использования? Вам доплачивают за это? Кто-то угрожает вашей семье? Прелесть несостоятельных технологий в том, что время решит все за них. Равно как и в эволюции: характеристики, которые не сработали, перестанут воспроизводиться, а те, что оказались полезными, дадут начало новым.

Если у вас уже есть опыт работы с несколькими языками программирования (и вы использовали их не только в своих pet projects), то вы представляете, о чем я говорю. Такое многообразие языков существует не просто так. Каждый из них занимал какую-то нишу, каждый пытался наследовать лучшее от предшественников и избавиться от их ошибок. Старался следовать за новыми технологиями, упрощал жизнь разработчиков и пользователей. И нет, это не делает старые технологии плохими или непригодными (давайте, расскажите С, что он мертв).

Не вовлекайтесь в бесконечные споры о том, почему один язык лучше/быстрее/функциональнее другого, не участвуйте в досужих рассуждениях о том, почему какая-либо новая технология или методология разработки обречена на провал. Лучше уделяйте время тому, что действительно важно, – повышайте свои навыки, увеличивайте опыт.

Да, вам будет полезно узнать о двух языках, о которых спорят коллеги, но совсем не для того, чтобы примкнуть к какой-либо из сторон и с пеной у рта доказывать ее правоту. Ознакомившись с обеими технологиями, вы получите двойной опыт – двух разных подходов, двух парадигм, двух видений, которым следовали авторы этих технологий. Это во много раз ценнее словесного пинг-понга, из которого никто и никогда не выходит победителем.

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

Тезисы

■ Холивары – для людей, которым нечем заняться.

■ Все технологии нужны.

■ Придерживайтесь своего мнения, но не пытайтесь никого переубедить.

■ Собирайте знания, не воюйте с технологиями, абсорбируйте их.

Задание

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

История из жизни

Помню, сразу после института я был совершенно уверен, что Java – медленный язык программирования, и даже старался кому-то это доказать – только для того, чтобы несколько лет спустя в поте лица писать на Java систему, работающую в реальном времени. Рад я только одному: что достаточно быстро усвоил урок о ненужности бесполезных споров.

Оценка задач

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

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

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

Декомпозиция. Если перед вами объемная, сложная задача, разбейте ее на несколько небольших, проанализируйте каждую из них и решите, стоит ли разделить