Карьера программиста

Получилось так, что я завершил свою карьеру программиста. Вот уже как полтора месяца — с 1 февраля 2021 — я не хожу в офис, не поднимаю VPN-соединение, не логинюсь из дома к удалённым компам, не запускаю Visual Studio и не делаю практически ничего из того, что делал на работе последние почти тридцать лет. И я не планирую делать это в дальнейшем. Во всяком случае, как наёмный работник.

Конечно, всё может измениться. Сейчас стало модным, особенно среди именитых боксёров и бойцов MMA, объявлять о завершении карьеры только для того, чтобы через год-два триумфально вернуться в ринг. Может, так будет и в моём случае. 🙂 Но на данный момент у меня нет планов возвращаться к работе программистом.

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

Прежде всего приведу краткую статистику по своей работе, дабы придать немного веса своим словам. Я работал в IT c 1993 по 2021 год в роли преимущественно full stack web-программиста. Округляя — двадцать семь лет. В моём активе одиннадцать компаний и десятки разнообразных проектов. Моей специализацией большую часть времени были технологии Microsoft — .NET, C#, SQL Server, Visual Studio, TFS, Azure. Но начиналось всё с Pascal и С++, а ближе к завершению карьеры мне довелось поработать с модными кросс-платформенными технологиями — nodeJS, JavaScript, TypeScript, Angular, Docker, Kubernetes и даже чуть-чуть React. Я работал в четырёх странах: Россия, США, Норвегия и Швеция. Среди моих работодателей были как небольшие, малоизвестные фирмы, так и крупнейшие корпорации, включая Microsoft, AT&T и SunTrust Bank.

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

Самым важным в карьере программиста я считаю педантичность. Неукоснительное следование правилам, протоколам, соглашениям. В этом кроется наибольшая сложность. Дело в том, что с годами я понял, что в обычной жизни слишком большая педантичность мешает. Педантичный, соблюдающий обширный набор различных правил человек — «душен», с ним трудно общаться. Да и вообще, жизнь намного сложнее любых правил и законов, её трудно уложить в формализованные рамки. Поэтому большинство людей в жизни педантичны «в меру» и, приходя в профессию, они переносят этот подход на программирование. И в этом их ошибка. Потому что мелкие нарушения правил, которые кажутся безобидными, это одна из фундаментальных причин долгоиграющих проблем в любом IT-проекте. Стремление «срезать» по короткому пути, немного нарушить, но зато сделать быстрее, чтобы понравилось начальству и заказчику, — это искушение, с которым далеко не у всех получается успешно бороться. Тем более, что отдалённые во времени последствия такого безответственного отношения к работе разгребать придётся, скорее всего, другим людям. На самом деле, примеров этого полно совершенно в любой профессии. Но в программировании эта проблема стоит особо остро, так как последствия «косяченья» могут наступить очень нескоро, но часто бывают серьёзными, а иногда и катастрофическими, а также трудноисправимыми. Короче говоря, надо стараться всегда всё делать правильно, не позволять искушению «срезать коротким путём» за счёт снижения качества кода одержать над собой верх. В большинстве случаев, эти косяки не связаны с недостатком знаний или опыта, т.к. люди идут на упрощение своей программисткой жизни сознательно, зная, что так делать — неправильно, но по каким-то причинам считая это для себя допустимым. То есть, это психологический вопрос, а совсем не вопрос профессиональных знаний.

Двигаемся далее. В начале пути у меня была иллюзия относительно карьерной лестницы программиста. Кстати, очень распространённая, имхо. Мне казалось, что программист, пройдя по ступенькам junior, middle и senior, в какой-то момент непременно должен стать тимлидом, потом менеджером проектов, ну и двигаться дальше в направлении занятия всё более и более высоких должностей, вплоть до технического директора компании, а то и создания собственной фирмы. Ну в крайнем случае необходимо стать архитектором сложных распределённых систем, чтобы под твою дудку плясали «обычные» программисты. Долгое время — наверное, примерно половину всей своей карьеры — я именно так и думал и пытался по этой лестнице продвигаться. Я то рвался в тимлиды, то в архитекторы, иногда мне даже удавалось прорваться в эти «высшие», как мне казалось тогда, сферы. Но сейчас я знаю, что всё проще. Сермяжная правда жизни заключается в том, что у каждого человека есть то, что получается делать лучше всего. И не надо стремиться куда-то ещё. Если у тебя получается программировать, но не получается вести за собой людей, то и надо программировать, а не пытаться стать начальником. Более того, если у тебя есть внутри эта способность — руководить, тогда и больших усилий прикладывать не придётся — всё получится легко и само собой. Я бы даже сказал, что если ты не стал хотя бы мелким руководителем в первые два года своей карьеры, при этом не вылезая из кожи вон ради этого, то дальше можно не напрягаться — это не твоё. Последние примерно лет семь своей карьеры я отбросил какие-либо амбиции касательно карьерной лестницы и довольствовался ролью senior-программиста. Хотя, несмотря на это, мне всё-таки приходилось выполнять роль тимлида много лет, несмотря на отсутствие горячего желания к этому с моей стороны. Просто начальство, как правило, считает, что человек с большим опытом должен руководить другими программистами. Это не так, но отказываться от этой роли, когда начальство её предлагает, может быть политически неверным. Поэтому приходилось терпеть и руководить, руководить и терпеть. 😀

Следующий пункт, в отличие от предыдущих, обусловлен современной конъюнктурой на рынке. С начала до конца моей карьеры на рынке можно было заработать больше, исключительно работая на заграничных, а не российских заказчиков. За эти годы я посетил, наверное, около пятидесяти собеседований, и финансовые условия, предлагаемые чисто российскими компаниями, неизменно уступали предложениям аутсорсеров, то есть компаний, соединяющих западных заказчиков с российскими программистами. В этих условиях может быть только две причины работать на российскую компанию: патриотизм и/или проблемы с английским (который, безусловно, язык международного общения, в IT-то уж точно). Тут каждый решает для себя. В моём случае мне сильно думать не пришлось: английский мне всегда нравился (и нравится поныне), а тут он ещё и даёт возможность зарабатывать больше. С патриотизмом больших проблем тоже не испытывал: работая в России я всегда платил налоги в российский бюджет, то есть делал тот необходимый минимум, который требуется от каждого гражданина РФ по закону.

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

Остановлюсь на этой теме немного поподробнее. Что именно мне порой мешало проходить собеседование успешно. Во-первых, стрессовая ситуация. На собеседовании ты думаешь над заданием когда рядом с тобой сидят один или несколько человек и пристально на тебя смотрят, ожидая ответ в течение довольно нещадно лимитированного времени. Это, конечно, замечательно, только это ни разу не похоже на реальную работу. В реальности никто у тебя над душой не стоит. Ты сидишь у себя в офисе за столом (а сейчас, в условиях удалёнки, даже у себя дома) и спокойно думаешь над текущей задачей. Во всяком случае, именно таким является мой личный modus operandi — я люблю в спокойной обстановке, при отсутствии каких-либо отвлекающих факторов, полностью погрузиться в задачу. При этом я могу не замечать как пролетает время, и могу с удивлением обнаружить, что наступил вечер, хотя вот только что было девять утра, но именно так у меня получается работать наиболее эффективно. И зачем на интервью заставлять меня работать по-другому и делать из этого какие-то далеко идущие выводы — для меня загадка.

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

Ну, в общем, интервью — это сложно. Но обойти эту тему не удастся. Тут надо осознать и смириться с недостатками существующего общепринятого процесса проведения собеседования, и действовать методом проб и ошибок, ища свой путь.

Коснувшись темы интервью не могу не затронуть тему, которую очень любят поднимать на собеседованиях — шаблоны проектирования (design patterns). По моему глубокому убеждению, паттерны — это очень похоже на правила русского (или любого другого) языка. Правил в языке существуют сотни — часть из них мы изучаем в школе. Но носителю языка, чтобы говорить и писать грамотно не надо знать практически ни одного! Чтобы быть грамотным человеком достаточно просто в течение некоторого времени активно читать и писать. После этого грамотная речь и письмо появляются сами собой! И придётся даже приложить усилия, чтобы писать неграмотно. Та же история, я считаю, с шаблонами проектирования. Они являются лишь формализованным отражением того, как логично организовать код для достижения оптимального результата. После приобретения небольшого опыта в программировании это становится понятно на интуитивном уровне, и помнить названия и специфику всех этих паттернов нет никакого смысла! Их имеет смысл преподавать в ВУЗе, да. Но использовать их знание как критерий отбора сотрудников — большая ошибка со стороны компаний. Гораздо больше смысла имело бы, например, дать человеку задачу с определёнными условиями и предложить ему в общих чертах описать, как бы он организовал взаимодействие элементов программы для достижения указанных целей, возможно набросать какой-то псевдокод. И совершенно неважно, как называются паттерны, которые он применит. Главное, чтобы он написал эффективный код, который удовлетворяет предъявленным требованиям — это всё, что нужно! Тем не менее, повторю: на интервью паттерны — любимая тема, поэтому, хочешь не хочешь, учить их придётся. Но после интервью можно спокойно забыть. Во всяком случае, я делал именно так. И по моим наблюдениям, далеко не только я. Так как в реальной работе названия паттернов упоминались в моей карьере крайне редко — что мной, что моими коллегами.

Заканчивая тему собеседований упомяну чуть-чуть о собственном опыте их проведения в качестве интервьюера. Собственно, я могу сказать только одно — это абсолютно не моя тема. У меня это не получалось и мне это не нравилось настолько, что сейчас мне даже не особо хочется об этом вспоминать. В этом я отличаюсь от многих коллег, которые не раз говорили как это прикольно: сидишь, задаёшь вопросы, беседуешь с человеком. Не знаю, я не нашёл в этом виде деятельности ровным счётом ничего интересного или привлекательного для себя. Меня эти «беседы» всегда напрягали. Подозреваю, что эта моя проблема имеет психологические корни. Задавая вопросы, я как бы вступаю в интеллектуальное соревнование с незнакомым мне человеком, и вот это мне совсем не нравится. Начиная примерно с середины карьеры начальство в разных компаниях периодически пыталось привлечь меня к проведению собеседований, отчего я активно отбрыкивался всеми руками и ногами. Практически всегда успешно. 🙂

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

— Нельзя «глотать» исключения (exception swallowing). Из этого правила бывают исключения, когда возможность возникновения exception’а ожидаема и его можно обоснованно проигнорировать. Но они редки.
— Логировать надо полную информацию об исключении: тип, message, stack trace, дата/время возникновения.
— Логировать надо не только само исключение, но и все вложенные исключения (inner exceptions). Это самая большая проблема. Из опыта моего анализа чужого кода в 90% случаев логируется только главный exception. В 10% случаев у программиста, видимо, начинает брезжить какое-то прозрение и он логирует главный exception и его inner exception. Мысль о том, что inner exception может иметь свой inner exception, ему в голову при этом не приходит. Один раз я видел очень необычное решение: код рекурсивно проходил по inner exceptions, но ничего с ними не делал. И только последний, самый глубоко вложенный inner exception, он таки логировал. Таким образом, логировалась непосредственная ошибка, но не более общая информация о контексте, в котором она произошла. И ни разу за всю свою карьеру, повторюсь — ни разу, я не видел, чтобы код логировал все исключения — и главное, и все вложенные в него. Конечно, ведь для этого надо написать рекурсивную функцию, а это так сложно. (нет)
— Часто исключение имеет смысл не просто бросить где-то в глубине кода и поймать и залогировать наверху в центральном обработчике, а поймать несколько раз при раскрутке стека, создавая каждый раз новый exception, записывая в него информацию о контексте, в котором произошла ошибка, доступную на данном уровне стека, и бросая его дальше, добавляя исходное исключение в качестве inner exception. В случае возникновения исключения это поможет собрать о нём полноценную информацию, включающую данные, доступные на разных уровнях программы.
— Убедиться, что собранная для логирования информация об исключении вся целиком попадает в лог, а не обрезается в процессе логирования. Упоминаю об этом, т.к. подобный случай имел место в моей практике — криво настроенное логирование обрезало stack trace до 1024 символов. В то время, как stack trace в сложных программах вполне может занимать больше. Ух, сколько часов этот косяк стоил заказчику!

В итоге, вместо того, чтобы сразу же после того, как об ошибке на prod-сервере стало известно, заглянуть в лог и увидеть там исчерпывающую информацию о ситуации и оперативно всё исправить, программисты сначала полдня смотрят на ту информацию, которую недоделанный логинг всё-таки смог предоставить, пытаясь сопоставить её с исходным кодом и понять, что же произошло. Потом, так и не поняв, ещё полдня, а то и несколько дней, пытаются воспроизвести ошибку в QA-среде. Причём иногда это бывает крайне сложно сделать, так как ошибка может возникать только при уникальной комбинации большого объёма реальных prod-данных и последовательности действий пользователя (или ещё хуже — пользователей). Если повезло и ошибку удалось воспроизвести в QA, остаётся совсем немного — поймать её в среде разработки (в моём случае — в Visual Studio) в режиме отладки (debug mode) и, воспользовавшись нормально написанным отладчиком этой самой среды, который способен показать все исключения, наконец таки увидеть непосредственную причину ошибки и начать её исправлять.

Я бы не писал об этом так подробно, если бы не считал обработку исключений краеугольной проблемой программирования, неправильная реализация которой способна поглощать миллионы долларов в виде человеко-часов работы программистов. Я клянусь — я видел, как на поиск причины ошибки подобным образом тратились человеко-дни (!), в то время как при правильно написанной обработке исключений понадобилось бы пять минут!

Вернёмся к менее техническим вопросам. Поговорим о деньгах. Не будем ханжами и признаем, что всем нам хочется получать много $$$. В принципе, профессия «программист» и так предполагает высокую зарплату (когда достигнут уровень «senior»), но я хочу отметить пару моментов, которые я осознал не сразу и которые могут помочь в вопросе максимизирования ваших заработков в IT-сфере.

Во-первых, надо не бояться просить много и надо не бояться подаваться на вакансии компаний, которые в состоянии много платить. Это некоторая «детская болезнь левизны» — проработав в сфере уже несколько лет и приобретя опыт, продолжать думать, что ты по-прежнему чайник и просить много тебе ещё рано. Надо понять, что всего ты не будешь знать никогда. Потому что это невозможно. Как я говорил, современная индустрия программирования — это крайне обширная область знаний и её вполне можно делить на более мелкие индустрии, каждая из которых также очень объёмна. Поэтому всё, что нужно, — это поработать некоторое время на младших позициях, понабивать шишки, поучиться на своих и чужих ошибках, расширить профессиональный кругозор, получить опыт в нескольких реальных проектах. Желательно поработать в нескольких компаниях — это даст, во-первых, разнообразие знаний, во-вторых, опыт прохождения интервью. Обычно на этот этап уходит — если начинать совсем с нуля — ну, наверное, года три-четыре. Хотя, безусловно, это зависит от способностей и мотивации. И после этого можно начинать считать себя крутым программером, ходить на интервью в крутые конторы и не стесняться просить большие деньги. Конечно, будут случаться обломы, на вас будут смотреть с удивлением, услышав сумму, — у меня были такие эпизоды в карьере. Но чаще на ваши условия будут соглашаться. Индустрия IT — это вообще довольно удивительная в плане разброса зарплат вещь. У меня за все эти годы сложилось впечатление, что в одно и то же время в мире существуют люди, которые, обладая примерно одинаковым набором знаний и навыков и делая очень похожие вещи, получают за свою деятельность деньги, отличающиеся на порядок! Это так потому, что труд программиста — довольно сложная с точки зрения оценки сложности процесса деятельность. Оценить время, требующееся на реализацию проекта, так, чтобы оценка была близка к реальности, — это нетривиальная задача. Для этого есть даже целые методики. Но даже с методиками всё сильно зависит от способностей и знаний непосредственного исполнителя, от того, как выстроен рабочий процесс в компании, от того, насколько качественный хочется получить код, и от других факторов. Поэтому никто точно не знает, сколько стоит труд программиста. Это и приводит к тому, что зарплаты в отрасли бывают самые разные. И больше чаще, чем реже, люди получают столько, сколько не стесняются попросить. Конечно, это несколько упрощённый взгляд на вещи — всё же, прося много надо суметь обосновать, почему ты считаешь, что тебе можно столько платить. Но упускать из виду этот психологический фактор нельзя — это может дорого стоить на длинной дистанции.

И второй момент, связанный с деньгами: конкуренция между работодателями. Да, конкуренция существует не только между соискателями на место в компании, но и между компаниями она существует тоже — конкуренция за соискателей. И этим можно и нужно пользоваться, потому что конкуренция означает наличие выбора, а это краеугольный камень, позволяющий оптимизировать результат. Пользоваться этим очень просто. Если вы на рынке и ищете работу — не ограничивайтесь одной компанией. Посетите несколько. И выбирайте лучшую из них. В своей карьере я порой устраивал очень масштабные мероприятия по поиску работы, в ходе которых в течении двух-трёх недель посещал больше десяти компаний (в некоторых из которых было больше одного интервью). В результате выбирал ту, которая больше всех меня устраивала (ну и которая сделала оффер, разумеется; это тоже не всегда происходит, к сожалению). А получив позицию в компании возьмите за правило «закрепляться» на достигнутом уровне и в дальнейшем переходить только на ещё большую или, как минимум, не меньшую, зарплату. Это не всегда возможно, так как помимо денег есть ещё немало факторов, влияющих на выбор, но нужно к этому стремиться. Такой подход позволит вам постоянно повышать свой зарплатный уровень: как фактически — добавляя к своей зарплатной истории ещё одну строчку с большим количеством нулей, так и психологически — привыкая к высокому уровню зарплат и переставая считать себя чайником, недостойным высокой денежной компенсации.

Обратимся вновь к техническим моментам. Тестирование. А именно, автоматические тесты (unit-тесты). Признаюсь, меня всегда ломало их писать. Но я осознаю, что их наличие — по крайней мере, в некоторой степени — необходимо. Правда тут нужно не перегнуть палку. Дело в том, что в ряде случаев написание автоматического теста может быть очень трудоёмкой задачей. Более того, чтобы обеспечить возможность работы теста порой приходится модифицировать сам код, который тестируется. Надо соотносить трудозатраты на написание теста и его воздействие на исходный код с теми выгодами, который он даёт. Если у вас написание теста занимает столько же времени, сколько написание самого тестируемого кода, или даже больше, это повод задуматься, а стоит ли заморачиваться. Или достаточно просто тщательно протестировать вручную. В любом случае, код теста должен быть простым. Естественно, никакие фишки объектно-ориентированного программирования, никакие паттерны, даже никакие helper-функции применяться не должны. Иначе в итоге вам придётся писать тест для вашего теста. Что имеет совсем уже мало смысла.

К сожалению, убедить в этом всём тимлида, руководителя проекта бывает непросто. Я сталкивался с такими руководителями, которые фанатично желали иметь покрытие кода тестами, близкое к 100%. Но, справедливости ради, существует и другая крайность — отсутствие каких-либо требований по автоматическим тестам. То есть, хочешь — пишешь, не хочешь — не пишешь. Это тоже не совсем правильно. Автоматические тесты там, где их написание не отнимает слишком много ресурсов, нужны. В общем, если вам начальством дана в этом вопросе свобода действий, руководствуйтесь здравым смыслом и не впадайте в крайности. Хотя скажу по секрету: когда в компании не было обязательным написание автоматических тестов, я их не писал. Это правило мной не нарушалось ни разу. 😉

Следующая тема касается широты ваших знаний. Тут есть две крайности и весь диапазон между ними: можно копать вглубь, а можно в ширь. И нужно решить, что именно из этого делать. При этом надо понимать, что ресурс времени у вас ограниченный, и вы можете усилить что-то одно только за счёт другого. Что же делать лучше — изучать как можно больше разных технологий, но знать их поверхностно, или изучать что-то одно, но знать это глубоко? Я знавал людей-многостаночников, которые имели знания и опыт чуть ли не во всех технологиях (хотя это и невозможно). Там в голове одного человека умещались .Net, Java, Python, React, Angular, JavaScript, Azure, AWS, Google Cloud, SQL Server, MongoDB и многое-многое другое. Но я сам всегда придерживался другой парадигмы. Почти с самого начала своей трудовой деятельности я сосредоточился на технологиях Microsoft и много лет копал в этом направлении, пока обстоятельства не заставили прикоснутся и к другим темам, в частности к SPA-фреймворкам (Single-Page Applications; кстати, я думаю, что за SPA будущее веб-приложений: SPA — это гораздо более логичный подход к вопросу), а именно Angular, и контейнерам (Docker, Kubernetes). Мне кажется, копать вглубь — это более правильно. Это вообще соответствует моим взглядам на жизнь — если уж мне что-то понравилось и я на это «запал», то это, как правило, надолго. Опять же — тут важно не впадать в крайности. С одной стороны, узконаправленность знаний и навыков повышает ценность человека как специалиста в данной конкретной области, но с другой — снижает вероятность найти подходящую позицию (чем уже луч, тем меньше вероятность высветить им нужную часть пространства, даже если интенсивность луча высока).

С точки зрения улучшения широты знаний и навыков полезно периодически менять работу. Ну или хотя бы проекты в рамках одной компании. Но тут, опять же, важно не переусердствовать. Прыжки из одной компании в другую, среднее время работы в одной компании год или меньше — это всё красные флаги для рекрутеров. Оптимально, на мой взгляд, работать в одной компании 2-3 года, после чего менять работу (заодно повышая себе зарплату). Моя личная статистика: среднее время работы в одной компании — 2 года 5 месяцев, при минимальной продолжительности работы в одной компании — полгода, и максимальной — пять лет.

Кстати, по поводу повышения зарплаты. Есть известное правило, которое надо знать. Не меняя работу невозможно увеличить себе зарплату больше, чем на 10% в год. Даже если ты супер-пупер-мегапрограммист и тебя очень ценит начальство. Просто потому, что такова общепринятая среди работодателей парадигма. Даже на 10% процентов увеличить крайне сложно. Как правило, в компаниях при ежегодном ревью, зарплаты сотрудникам поднимают на 2-5%. Поэтому если считаешь, что вырос, и хочешь радикально повысить свой доход — процентов на 20-50, то решение только одно — менять компанию. При смене компании такое увеличение вполне реально. Из моей собственной практики: при переходе из AT&T в SunTrust моя зарплата увеличилась на треть (то есть, на 33%). Это, правда, было в США, но в России это работает похожим образом.

Сертификаты. За всю карьеру я получил совсем немного сертификатов: несколько популярных в начале нулевых сертификатов от Brainbench (C++, .Net) и несколько Майкрософтовских. Первый сертификат я получил в 2001 году, последний — в 2013-ом. Работодатели и рекрутеры любят когда у кандидата в резюме есть сертификаты. И на мой взгляд, они делают это зря. Потому что ценность сертификатов сильно сомнительна. Дело в том, что уже давно существует такое явление как braindump. Это когда человек сходил на экзамен на получение сертификата, как-то что-то там ответил, а по возвращении домой сел и записал все вопросы, которые смог вспомнить. Когда так проделают хотя бы несколько человек, объединив свои списки в один, у них получится уже довольно обширная и точная база вопросов. К которой они могут присовокупить правильные (на их взгляд) ответы. В дальнейшем этот список вопросов и ответов распространяется в сети, свободно для всех желающих. Более того, я даже встречал компании, которые совершенно открыто продают что-то похожее на braindumps, утверждая, что хотя это не точно те же самые вопросы, которые будут в экзамене, но очень похожие. Есть даже подозрение, что к таким braindump’ам имеют отношение сами компании, выдающие сертификаты. По факту всё это приводит к тому, что «подготовка» к экзамену сводится к тому, чтобы тем или иным способом раздобыть braindump, зазубрить вопросы и ответы и затем применить полученные «знания» на экзамене. Эта практика, насколько я могу судить по ажиотажу вокруг braindump’ов в интернете, очень распространена. Что делает ценность всего этого процесса с точки зрения оценки знаний человека, по моему мнению, весьма сомнительной. Более того, если вы попытаетесь быть честным человеком и не будете пользоваться никакими braindump’ами, а будете готовиться исключительно по специальным пособиям от компании-эмитента сертификата (если у вас есть деньги, т.к. эти пособия недёшевы) или по общей литературе по выбранной тематике, то ваши шансы сдать успешно с первого раза драматически снижаются, а усилия, которые придётся приложить, чтобы иметь этот шанс, возрастают экспоненциально. Из своей практики скажу, что один сложный Майкрософтовский экзамен я пытался сдавать честно (не используя braindump) два раза (оба раза заплатив за него заметные для меня деньги), на что угробил кучу времени, но завалил оба раза. После чего забил.

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

Несколько разрозненных заметок о софте.

FAR Manager — наше всё! 🙂 Несмотря на то, как эволюционировал пользовательский интерфейс в современных операционных системах, какие красивые сейчас в них окошки и остальная графика, FAR — эти «синие таблицы», вызывающие у неискушённых ассоциации с хакерами — по-прежнему остаётся очень удобным инструментом для работы программиста. Я уже не помню, когда начал его использовать (подозреваю, что больше двадцати лет назад), но использую до сих пор.

Конечно, платный софт для работы в нормальных конторах всегда предоставляет работодатель, решая все вопросы с лицензиями и оплатой. За всё время я за свои деньги купил лишь одну утилиту для работы. Это был тул для сравнения файлов Beyond Compare. Очень удобная вещь для совместной работы с git и выполнения three-way merge.

А вот ещё один, крайне широко используемый инструмент у меня не пошёл. Это Resharper, разработка питерской фирмы JetBrains. Несколько раз я ставил его и пытался привыкнуть к его использованию, но каждый раз непременно сносил. Ну совершенно не нужна мне оказалась его функциональность. Любой рефакторинг я привык делать самостоятельно, понимая, что я делаю и с какой целью. А Resharper делает это за меня, и это мне не нравится. Базовые рефакторные функции типа переименования переменной с обновлением всех мест, где она употребляется, сейчас можно делать средствами Visual Studio. Resharper используют очень многие — по моим наблюдениям, больше половины всех пользователей Visual Studio. Я даже знаю людей, которые покупали его за свои деньги (т.к. работодатель не предоставлял лицензию) — так он им нравится. В этом я отличаюсь от большинства моих коллег. Не использовал и не чувствую никакого неудобства в связи с этим. Впрочем, некоторые другие продукты JetBrains меня вполне себе торкали — например TeamCity или dotTrace.

Регулярные выражения (они же regex) — это невероятно мощная тема для работы с текстом. Но я поймал себя на том, что эту функциональность, которая нужна не так уж часто (простую работу с текстом можно реализовать и традиционными способами), я изучал каждый раз заново, когда мне приходилось её использовать. Запомнить весь этот синтаксис со скобками, точками, запятыми и прочими символами из нижней части таблицы ASCII для меня не представлялось никакой возможности. Если бы ещё мне это было нужно постоянно, шанс запомнить бы был. Но при эпизодическом использовании… Некоторый гемор. 🙂

Ну и в заключение скажу общие слова о своём отношении к профессии программиста. Программирование однозначно было правильным выбором в моей жизни. Мне нравится этот вид деятельности, у меня получалось этим заниматься и я получал от этого удовольствие. Не раз и не два бывали ситуации, когда я настолько глубоко погружался в задачу, что буквально вываливался из реальности, переставая замечать, что происходит вокруг и как течёт время, порой проводя за работой всё время своего бодрствования (прости меня, моё зрение! 🙁 ). Конечно, не всё, что я делал было мне настолько интересно, но то, что такие моменты были, — большая удача. Считаю, что в этом мне в жизни очень повезло. Я всегда сравнивал программирование с решением головоломок. Люди ведь решают головоломки — кубик-рубика собирают или кроссворды разгадывают — просто так, потому что им это нравится. А программист решает головоломки, и ему ещё и деньги за это платят! 🙂 По-моему, лучшего варианта для профессии просто не найти. Поэтому я доволен. В то же время, я считаю, что эта профессия — не для всех. Тут важна усидчивость. Не помешает также в некоторой степени интровертность. Безусловно, аналитический склад ума. Гуманитарию с синтетическим складом ума, «творцу», из которого прёт энергия, который не может долго сидеть на одном месте, которому любое количество общения — мало, делать в этой профессии, имхо, нечего. У него ничего не получится. Точно также, как у технаря-интроверта, привыкшего анализировать, всё раскладывать по полочкам, вряд ли получится, например, сочинять музыку или играть в кино. Так устроена жизнь. Важно найти свой путь, то есть, то, что получается и приносит удовольствие, и двигаться в этом направлении.