От джуна до сеньора. Как стать востребованным разработчиком

Это МОИ деньги

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

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

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

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

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

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

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

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

Тезисы

■ В начале карьеры придется набраться терпения: вам нужен опыт.

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

■ Ведите учет своих профессиональных достижений.

Задание

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

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

Достаточно много лет я не умел оценивать свою работу, не знал, как правильно выстраивать диалог об оплате труда. Отчасти из-за того, что много сомневался в своих силах и опыте, отчасти потому, что деньги никогда не были для меня основным мотиватором. Я всегда любил разработку, любил программировать, любил сам процесс. Бывали месяцы, когда я забывал отправить платежные документы, чтобы получить заработанные деньги, просто потому что был слишком увлечен проблемой, которую решал. Это не самое лучшее отношение к своему труду и времени. Наше время очень ограниченно, а деньги позволяют проживать его с комфортом. Если бы я мог вернуться в прошлое и дать совет себе начинающему, этот совет был бы таким: никогда не бояться говорить о деньгах и соглашаться только на ту сумму, которая соответствует моему опыту.

Сильные и слабые стороны

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

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

Трудно честно ответить себе на вопрос, каковы ваши сильные стороны, а каковы слабые. Ваше внутреннее «я» будет сопротивляться, выдавая желаемое за действительное. Вы станете обманывать себя: превращая сильные стороны в нейтральные или даже слабые. Не торопитесь, дайте себе время. Постарайтесь анализировать отстраненно: что бы вы сказали про себя, будь вы своим коллегой?

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

Используйте свои сильные стороны – полагайтесь на них, доверяйте им. Вы умеете писать очень качественный код? Наверняка об этом знаете не только вы, поверьте. Используйте это как козырь, развивайте этот навык. Вы отлично умеете декомпозировать задачи, видеть частности в целом? Применяйте это в своей работе, помогайте улучшить продукт, претендуйте на голос в принятии решений по проекту и его архитектуре.

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

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

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

Если же ваши слабые стороны – это просто список вопросов, которым вы уделяли мало внимания, тогда все отлично: можете совершенствоваться.

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

Тезисы

■ Для определения своих сильных и слабых сторон нужно время.

■ Постарайтесь оценивать себя как бы со стороны.

■ Будьте максимально честны по отношению к себе.

■ Соблюдайте баланс: подтягивайте слабые стороны, не запускайте сильные.

■ Используйте свои сильные и слабые стороны в собственных интересах.

Задание

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

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

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

Интервью

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

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

Внешний вид. Да, вы должны выглядеть опрятно и соответствовать принятому в компании дресс-коду. Однако если вам делают замечание по поводу внешнего вида или вы поняли, что он чем-то не устроил интервьюера, вряд ли стоит идти в такую компанию. Вас нанимают за знания и навыки, а не за внешний вид.

Соответствие требованиям. Если вы идете на интервью по вакансии, то уже знакомы с требованиями работодателя. Не пытайтесь хитрить или приукрашивать свои умения. Это может сработать, если у вас есть значительный опыт в индустрии и большой набор знаний в разных областях IT. Однако если вы только начинаете карьеру разработчика, просто постарайтесь иметь представление обо всех требованиях, перечисленных в объявлении о вакансии. Собеседования с начинающими разработчиками проходят достаточно быстро, и, чтобы сразу отсеять кандидата, не нужно даже привлекать технического специалиста: вам просто зададут стандартный набор вопросов по технологиям, перечисленным в вакансии. Если вы не знаете их на достаточном уровне, это выяснится либо сразу, либо позднее, в другой части интервью, где вас будет собеседовать технический специалист.

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

Уверенность в себе. На какую бы должность вы ни претендовали, неуверенность и сомнения в себе будут заметны с порога. Да, вы будете испытывать стресс, и некоторые компании только подстегнут его (в их воспаленных фантазиях это может лучше раскрыть кандидата, вот же странные люди). Не позволяйте эмоциям завладеть вами. Это просто работа, вы пришли не на суд, а рассказать о себе и своих знаниях. Если не знаете, что отвечать, – скажите об этом и попытайтесь предложить решение в той области, в которой разбираетесь. Большинство интервью направлено не на то, чтобы услышать от вас правильные ответы. Обычно работодатели хотят узнать, как вы подходите к проблеме, как пытаетесь решить ее, основываясь на своем опыте и умениях, – учитывайте это при подготовке к интервью. Не забывайте о своих сильных сторонах, равно как и о слабых (поверьте: когда вы говорите, что ваш самый большой минус – желание всем угодить, никто этому не верит, даже вы сами).

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

Тезисы

■ Ваш внешний вид на собеседовании должен соответствовать должности, на которую вы претендуете, и дресс-коду компании.

■ Если вас оценивают только по внешнему виду – бегите.

■ Изучите требования к кандидатам и не приукрашивайте свои знания.

■ Не пожалейте времени на подготовку к интервью.

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

Задание

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

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

Я никогда не любил интервью и собеседования. Мне не нравились вопросы, задания, я никогда не мог вспомнить нужную сортировку и особенности ее реализации в нужный момент. Я не любил конкретные вопросы о том, что я «должен» помнить наизусть, это напоминало мне скучное заучивание, без вариативности и возможности придумать что-то на ходу. Стоит ли говорить, что с таким подходом я редко оказывался желанным кандидатом для самых разных компаний. Но был и плюс: благодаря такому отношению я попадал в другие компании, которые так же не принимали формализма в найме разработчиков, отдавая предпочтение их практическим навыкам. Моя нелюбовь к формальным собеседованиям привела меня к тому, что уже находясь по другую сторону стола я с куда большим пониманием и симпатией отношусь к разработчику, который хочет получить работу, и не пытаюсь выдавить из него реализацию алгоритма, которую он должен написать ПРЯМО СЕЙЧАС на бумажке (да, увы, я побывал и на таком собеседовании).

Если начальник – идиот

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

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

Слово «начальник» можно понимать достаточно широко. Это может быть любой человек в коллективе, от которого зависит ваша работа, – директор, старший разработчик, проект-менеджер и т. д.

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

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

Тезисы

■ Если вы поняли, что ваш начальник – идиот, уходите.

■ Абсолютно серьезно – уходите.

Задание

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

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

К счастью, в жизни мне попалось только несколько руководителей, с которыми я не cмог работать. Вот, пожалуй, самая глупая из связанных с этим историй: в 3 часа ночи мне звонил начальник, находившийся в другом часовом поясе, и требовал объяснить, что делает код, который мы написали в течение дня (он не был разработчиком и о коде имел такое же представление, как я о глубоководной фауне). Нужно ли говорить, что время этого разговора не учитывалось при оплате в конце месяца? Как и в отношении денег, я довольно долго считал, что мне нужно подстраиваться под людей, чтобы иметь шанс быть частью какого-то продукта, но каждая такая ситуация в 3 часа ночи хорошо отрезвляла и напоминала, что мой запас времени и нервов весьма ограничен.

Поиск виноватых

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

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

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

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

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

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

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

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

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

Тезисы

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

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

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

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

Задание

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

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

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

Холивары

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

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

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

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

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

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

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

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

Тезисы

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

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

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

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

Задание

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

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

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

Оценка задач

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

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

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

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

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

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

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

Коэффициенты. Финальное действие – это применение коэффициентов. Строго говоря, коэффициенты могут понадобиться вам лишь в ряде случаев, но для начинающего разработчика они весьма желательны, так как дают запас времени, даже если изначальная оценка была проведена некорректно (пока вы только набираетесь опыта, так и будет, можете мне поверить). После того как вы оценили задачу, руководствуясь предыдущими пунктами, необходимо выбрать коэффициент и умножить на него полученную оценку. Это дополнительное время – ваша страховка на случай непредвиденных обстоятельств. Выбор коэффициента будет зависеть от того, насколько такая практика принята в вашей компании, готов ли заказчик платить за скрытые риски, а также от того, как вы оцениваете свой опыт в задаче. Если попытаться свести величины к числам, коэффициент будет варьироваться от 1 (вы считаете оценку точной и не предвидите никаких рисков, начальное время оценки после умножения на 1 остается тем же) до 1,5 (вы предполагаете, что задача таит в себе большое количество скрытых рисков и дополнительной работы). Допустим, вы оценили задачу на 10 часов, но догадываетесь, что даже с тестированием и заложенными рисками можете потратить дополнительное время на обсуждение и доработку от дизайнеров, и выбираете коэффициент 1,2. Таким образом, ваша конечная оценка будет 12 часов (10 × 1,2), где дополнительные 2 часа – ваша страховка.

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

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

Тезисы

■ Перед оценкой выясните все требования к задаче.

■ Дробите большие задачи на более мелкие.

■ Учитывайте потенциальные риски; запоминайте, когда вы ошибались в оценке.

■ Добавляйте время на тестирование.

■ ОБЯЗАТЕЛЬНО добавляйте время на тестирование!

■ Учитывайте время на «потрындеть», оно такое же реальное.

■ Добавляйте коэффициенты оценки, не пренебрегайте своей безопасностью.

■ Низкие оценки никого не впечатлят, а вам придется ночевать на работе.

Задание

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

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

Всех историй о том, как я недооценил задачу, не перечислить и в трех книгах, но одна запомнилась особенно хорошо – правда, по иным причинам. Я уже не вспомню, что конкретно надо было сделать, но задача выглядела солидно, предполагала время на анализ, на дополнительные тесты. Суммарно выходило порядка 20 часов. Задача была оценена, я отложил ее на поздний срок и вернулся к ней через несколько недель. Работа моя продлилась 2 часа, после чего еще полчаса ушло на то, чтобы понять, как я ухитрился нафантазировать себе оценку в 20 часов.

Общий код

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

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

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

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

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

Тезисы

■ Код проекта – это совместный труд его разработчиков.

■ Вам не обязан нравиться чужой код, равно как и ваш код не обязан нравиться вашим коллегам.

■ Умейте читать и воспринимать любой код.

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

Задание

Возьмите любой проект и проанализируйте его код. Попробуйте угадать непосредственно по коду, какие части были написаны разными людьми. Используйте git blame, чтобы узнать, правы ли вы. Найдите код, который вам визуально не нравится: он может быть написан с использованием необычных нотаций из прошлого (да, Венгерская нотация, я никогда тебя не забуду), иметь нетипичный подход к размещению блоков и т. д. Попробуйте хотя бы немного привыкнуть к нему.

Представьте, что разработчик, написавший этот код, – ваш подчиненный. Достаточно ли у вас оснований сказать, что код не работает, и отправить его на доработку?

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

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

Одно кольцо, чтоб править всеми

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

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

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

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

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

Если в какой-то момент карьеры именно вы окажетесь тем, кто принимает ключевые решения, я заранее поздравляю вас. Поздравляю с тем, что отныне каждый ваш выбор будет делить людей на две или больше групп. Часть из них будет согласна с вашим решением, а часть – сопротивляться ему так, будто вы пытаетесь поджечь их дома. Это нормально, опирайтесь только на объективные критерии выбора. Да, когда вы объясняете, что необходимо сделать, старайтесь находить правильную аргументацию и слова. И не нужно угождать всем, ваша задача – сделать проект сильнее и лучше.

Тезисы

■ Каждый проект – это совокупность больших и маленьких решений.

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

■ Если решения принимаете вы, будьте готовы столкнуться с сопротивлением.

Задание

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

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

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

Обсуждения

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

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

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

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

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

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

Тезисы

■ Мало обсуждений – плохо.

■ Много обсуждений – тоже плохо.

Задание

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

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

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

Бюрократия

Как бы печально это ни звучало, но бюрократия на сегодняшний день – неотъемлемая часть мира IT. Она проникает в нашу индустрию потому, что руководству компаний нужна четкая структура и понимание продукта (с какой скоростью и с какими перспективами идет его разработка). Это благое желание, которое часто выливается в замедление или усложнение разработки.

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

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

Вы, как разработчик, вряд ли будете напрямую влиять на рабочие процессы в компании (и скажите за это спасибо, вы НЕ хотите лезть в эту банку со змеями).

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