Текст книги "Карьера в IT. Как найти работу, прокачать навыки и стать крутым разработчиком"

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

Например, предположим, что вы – медсестра с 20-летним опытом работы и хотели бы заниматься программированием.

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

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

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

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

Компании-разработчику намного проще найти и нанять разработчика с 10-летним опытом разработки, но того, кто разбирается в разработке программного обеспечения и имеет 10 или более лет опыта в определенной области, найти гораздо труднее.

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

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

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

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

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

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

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

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

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

Будьте терпеливы.

Глава 18. Переход с технической должности

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

Я испытал это на себе – мне пришлось делать это дважды.

Первый раз я менял сферу деятельности, когда только начинал карьеру.

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

Поначалу работа была простой.

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

Это было довольно скучно.

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

Я попросил предоставить мне доступ к инструкциям печати, которые отправлялись на принтер при проведении каждого теста. Инструкции печати были написаны либо на PCL, либо на PostScript – двух популярных языках для вывода информации на печать.

Я изучал PCL и PostScript, тратя как свое личное время, так и свободное рабочее, которое появлялось из-за простоев.

Я стал экспертом в обоих языках.

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

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

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

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

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

На этот раз я сидел рядом с довольно неопытным разработчиком программного обеспечения, который слабо разбирался в C++.

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

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

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

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

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

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

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

В частности, в мире разработки обычно существует четкое различие между разработчиками и тестировщиками (или обеспечением качества).

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

Это довольно неприятно – особенно если вы уже переросли свою текущую должность.

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

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

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

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

Прежде всего – старайтесь говорить о своем желании перейти на должность программиста как можно большему количеству людей.

Сообщите коллегам, что вы хотите перейти в разработку.

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

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

Расскажите боссу о преимуществах, которые компании сулит ваш перевод.

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

Однако слова – это всего лишь слова.

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

Подкрепляйте слова действиями.

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

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

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

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

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

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

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

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

И продолжайте спрашивать.

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

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

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

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

Вероятно, вам придется самостоятельно создавать для себя возможности.

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

Часто эти возможности являются «грязной работой». Это то, чем никто не хочет заниматься.

Это будет что-то вроде мытья туалетов, но в контексте программного обеспечения.

Например, поиск и устранение одного приставучего бага, который никто не может найти.

Или написание документации для API. Или создание инструмента, который упростит жизнь всем остальным.

Скорее всего, это будет скучная и трудная работа, но если вы хотите найти проект, за который ни с кем не надо бороться, то это наверняка будет та самая «грязная работа».

Будьте готовы закатать рукава и с головой погрузиться в задачу.

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

Другие начальники будут очень довольны тем, что вы потратили часть своего времени на выполнение «грязной работы».

Однако так бывает не всегда.

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

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

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

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

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

Это вам точно никто не запретит.

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

Для многих тестировщиков таким своеобразным мостом может служить автоматизация.

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

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

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

Кроме того, многие организации испытывают затруднения в поисках таких узкопрофильных специалистов. Не так-то просто найти эксперта по автоматизации тестирования.

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

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

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

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

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

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

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

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

Как же тогда перейти с должности тестировщика в одной компании на должность программиста в другой?

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

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

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

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

Не унывайте.

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

Но если вы готовы трудиться сверх нормы и стать «настолько хорошим, что они не смогут вас игнорировать», как говорит Кэл Ньюпорт в своей одноименной книге, успех неминуем.

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

Терпение и настойчивость – ключ к успеху.

Глава 19. Договор подряда или работа в штате

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

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

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

Когда я работал в HP, сначала по договору подряда, а затем в качестве штатного сотрудника, в компании бытовали такие понятия, как «синие барсуки» и «оранжевые барсуки».

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

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

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

Бывают места, где иерархия выглядит ровно наоборот.

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

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

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

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

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

Начнем наш разговор с темы работы по договору подряда.

Я определяю работу по договору подряда как любую работу, которая не является работой за оклад, хотя существует несколько видов консалтинговых или контрактных работ, при которых работнику платят зарплату, а клиенту выставляется счет на почасовой основе. (Не советую браться за такую работу, она для лохов.)

Вопрос Джону!

Почему это работа для «лохов»?

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

Многие консалтинговые компании создают должности архитекторов предприятия (enterprise architect) или архитекторов решений (solution architect), очень похожие на обычные штатные должности, но на самом деле это консультационные должности, где зарплату платит компания на основе почасовой ставки, которую они выставляют клиенту за ваше время.

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

Звучит неплохо, правда? В чем же здесь подвох?

Подвох в том, что на самом деле это не штатная должность.

Нет никаких гарантий этой занятости.

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

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

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

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

Когда я говорю «подрядчик», я имею в виду работника с почасовой оплатой труда.

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