ПОЧЕМУ РОССИЯ НИЩАЯ? ЧАСТЬ 12.

       Как выжить в РФ программисту?

       - Год за годом ежедневно изучать American English до продвинутого уровня. Это нужно делать параллельно вашей основной работе, а не вместо нее. Кстати, если вы будете изучать American English по часу в сутки, то эта песня может длиться вечно. Чтобы действительно выучить American English, его нужно изучать по три часа ежесуточно. Не забывайте и о том, что курсы при галерах - это шарлатанство: английскому там учат специально так, чтобы человек никогда не смог начать работать напрямую на американских клиентов, минуя галеры.

       - Никогда не колымить, не шабашить, не заниматься фрилансом. Соглашаться только на постоянную удаленную работу на конкретного иностранного заказчика фулл-тайм по контракту и без посредников. Заниматься только IT-проектами и никогда не соглашаться заниматься IT-задачками, даже если клиент гордо называет свою задачку словом «проект». Запомните: нормальный IT-проект - это когда есть полноценный менеджмент и конкретная методология разработки, когда есть распределенная по планете команда фулл-тайм-разработчиков, каждый из которых занимается строго своим делом, несет ответственность только за свой небольшой фрагмент проекта и митингует с командой раз в сутки в одно время, когда есть QA и DevOps, когда практикуется code review, когда используются баг-трекеры, JIRA, git или подобные вещи. Все остальное - это «задачки для программистов», а не проекты.

       - Не переезжать жить за границу, не переезжать жить в Москву или Петербург. Наиболее выгодный вариант для разработчика софта, удаленно работающего на иностранные компании фулл-тайм по контрактам на long-term-проектах, - это жить в одном из провинциальных городов РФ с населением от 500 000 до 1 миллиона человек, потому что там жизнь крайне дешевая во всех ее аспектах, а курс доллара США сейчас внушает радость и оптимизм.

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

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

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

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

       Как гнобить разработчиков.

       Здравствуйте, долбаные читатели. Циничный галерный менеджер репортинг ин. Меня часто спрашивают:

       - Как мне достичь таких высоких профессиональных высот (sic!) в управлении жирными командами разработчиков;

       - Что нужно, чтобы шагнуть на следующую эволюционную ступень в области high-менеджмента айти-фирмой;

       - Как грамотно и аргументировано отказать человеку, просящему о повышении?

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

       - Как заставить работников работать за еду?

       Ответы на все эти вопросы подразумевают, что вам придется овладеть искусством гнобления разработчиков. Об этом мы сегодня и поговорим, поделюсь с вами некоторыми секретами в качестве дополнения к статье «Как платить программистам меньше». Зачем, почему? Но я не хочу никого гнобить! - может возразить кто-то. Все верно, друг! Я тоже человек бесконфликтный, которому бери да проставляй пиво без какого-либо повода, просто так. Но что-то я сижу здесь сейчас, размышляю, и не вижу пива. Если взглянуть на типичного программиста, то сразу становится ясно, что перед тобой простой лох. Он сам не против, чтобы его обманули. И это хорошо для фирмы, так как на разработчиках мы будем нехило экономить - хватит не только на пиво, я это гарантирую. Алсо: обманывать разработчика нужно не только потому, что он лох, но и просто, потому что можешь. Ты ведь крут, не так ли? Когда? Когда лучше всего гнобить разработчика? Ответ очевиден: когда они наиболее уязвимы. То есть на собеседовании, или при аттестации, или на тренинге. При желании можно это также делать во время code review или когда консультируешь проектную команду. Не стоит гнобить разработчика, когда он занимается своими прямыми обязанностями, то есть разрабатывает что-нибудь. Почему? Да потому, что он в это время и так огорчен и пребывает в подавленном настроении. Вероятнее всего, ему опять подсунули отвратительно написанное и нетестируемое приложение на тормозящем энвайронменте, а тесты постоянно валятся по непонятным причинам или же никто не хочет их запускать. Гнобление в такой момент не принесет вам никакого морального удовлетворения: от вас просто отмахнутся. Как? Существует масса способов как гнобить разработчика. Остановимся на них подробнее:

       1. Ad hoc чмырение. Первый и самый очевидный способ - так называемое ad hoc или спонтанно-бытовое чмырение. Рассматривать его в деталях мы здесь не будем, так как оно неспецифично для сферы айти. Перечислим лишь несколько базовых примеров:

       - Э-э, епта, иссуа-на! Деньги есть?

       - Что ты тошнишь? Водить научись, мудила!

       - Вон, Лидке муж норковое манто купил, а ты чего добился, неудачник?

       - У Вас не хватает двух справок и одной печати. Зайдите в следующий четверг между 11 и 11:30.

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

       «Ну и что?».

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

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

       «Расти тебе еще надо, парень, расти».

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

       - Спросите собеседника, какие паттерны проектирования он знает. Ответ «Синглтон» не засчитывайте.

       - Попросите описать отличия между двумя малоизвестными паттернами, названия которых вы незадолго до этого подсмотрели в книжке. Независимо от ответа снисходительно хмыкните и скажите:

       «Хорошо».

       - Даже если собеседник перечислил все 23 канонических и еще пару десятков паттернов, нарисовал диаграммы и написал на бумажке примеры кода, спросите:

       «А еще, какие знаете?».

       Независимо от ответа снисходительно хмыкните и скажите:

       «Хорошо».

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

       2.2 Прием «инверсия». Суть данного приема заключается в том, чтобы узнать с каким инструментом человек работал, а затем раскритиковать за отсутствие опыта работы с другим инструментом той же группы. Например, если человек работает с Django, то нужно неодобрительно покачать головой, если он не работал с Flask. Обязательно спросите у бэкендщика, знает ли он фронтенд, умеет ли верстать? Помните, что fullstack - это золотое дно для таких манипуляций. Именно поэтому fullstack так популярен. Как применять? Совершенно неважно, о какого рода инструментах или технологиях идет речь. Самое главное - подробно расспросив, объяснить оппоненту, какой он лошара:

       - Если работал на проектах с SVN и Perforce - мало опыта с более современными системами типа Git.

       - Если с Git на «ты» - подтянуть коммерческие системы контроля версий.

       - Если специализируется на UI-автоматизации - слабые знания в области тестирования веб-сервисов.

       -  Если знает WebDriver - побольше поработать с QTP, SoapUI, тулами для нативных мобильных приложений и распознаванием образов.

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

       - Если в основном работал в одиночку - не командный игрок.

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

       Источник: https://ebanoe.it/2017/02/09/how-to-oppress-developers/

       ПРОДОЛЖЕНИЕ СЛЕДУЕТ…

Материал предоставил Андрей из Германии.