Как я увеличил свою зарплату в 40 раз, освоив программирование

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

Собственно, в этой статье я хочу рассказать о своем пути в области IT. На момент написания этого текста он длится уже 10 лет и еще отнюдь не завершен. Я начинал как QA инженер (читай – тестировщик) и мечтал освоить программирование еще будучи студентом. Сейчас я работаю разработчиком на довольно крупную американскую компанию, при этом не выходя из дома.

Все цифры для интересующихся – в конце статьи.

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

Этап 1: QA Engineer

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

Я твердо решил освоить программирование, когда мне было лет 12. Тогда у меня еще не было компьютера, но была замечательная приставка СЮБОР, позволяющая писать простейшие программы. Но спустя 8 лет я стал тестировщиком… то есть, простите, QA инженером. Дело в том, что мне поначалу довольно тяжело давалось программирование, и я не мог как следует ухватить идею ООП. Да и с функциональным программированием у меня было тоже довольно посредственно.

Итак, я стал тестировщиком. Было жаль, что не разработчиком, но профиль был довольно близок, и это меня утешало. К тому же, мануальным тестированием я занимался крайне мало, потому что мой лид практически сразу решил меня бросить на авто-тестирование. Спасибо ему большое за это! Я писал авто-тесты на Selenium WebDriver, используя Java. В процессе написания скриптов я познакомился с такими штуками, как JUnit и Eclipse. А параллельно почитывал книжку по Java. Она была довольно хреновая, но определенные знания я все же почерпнул.

Но что же дальше?

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

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

На самом деле, взяться можно было за любой язык, но в компании активно использовалась именно Java.

Еще полгода я занимался саморазвитием. Я вышел на разговор еще раз, а параллельно сходил на собеседование в другую компанию. И – мои труды были вознаграждены! Ребята с проекта сказали, что я сильно вырос, и что, вероятно, стану разработчиком через месяц. А еще через неделю мне позвонили из другой компании и поздравили – ведь они готовы взять меня на позицию Junior iOS Developer! До сих пор не понимаю, почему именно iOS, ведь я собеседовался на Java.

Я наконец мог профессионально заняться программированием! Но знаете, что я сделал? Я отказался, ведь меня должны были перевести в разработчики уже через 3 недели!

Конечно, никуда меня не перевели. Примерно в это время я пошел на курсы Java-разработчиков в третью компанию, а через 3 месяца уволился. Курсы должны были закончиться спустя 2 месяца после моего увольнения, но я верил в то, что меня, как одного из лучших студентов, возьмут в штат. И не зря.

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

Этап 2: Java Developer

Да, меня взяли разработчиком летом 2012, и я наконец занялся программированием за деньги. Поначалу это была практически эйфория – ведь я теперь буду писать код, и совсем-совсем не буду заниматься неинтересным мне тестированием! Мне нравилось это время.

Сразу по приходу в компанию я попал на бенч (это внутренние учебные проекты для временно свободных сотрудников), потому что компания не смогла сразу же определить меня на проект. На бенче я сидел около двух недель – в это время я занимался простеньким учебным заданием, где мельком познакомился со Struts2 и Mercurial. Затем мне написал мой Resource Manager с радостной новостью, что меня готовы рассмотреть на настоящий, боевой проект! Там уже работал ведущий разработчик, и ему требовался смышленый товарищ, но желательно уровнем повыше, чем junior. И еще здесь была ужасная деталь – мне необходимо было пройти собеседование по скайпу с человеком из Москвы!

Первый выход в свет

Наверное, как и большинство неопытных новичков, я паниковал от одной только мысли о собеседовании (это сейчас мы рассматриваем их как приятное времяпровождение, где можно выявить пробелы в знаниях, верно?). Буду краток – собеседование я прошел неплохо, и даже написал Ping Pong на двух потоках в качестве тестового задания. Параллельно со мной собеседовали еще одного разработчика с бенча, но в итоге предпочтение отдали мне. Скрывать не стану – мне было очень приятно, особенно на фоне новости, что хотели брать хоть сколько-нибудь опытного человека, а у меня в программировании опыта не было. Зато были хоть какие-то знания, которые я почерпнул из книг и статей!

Поначалу для меня было все в новинку – ant, SVN, JDBC, ну и конечно же Java Core. Всего было так много, что я решил даже не заниматься дополнительно, ведь итак много всего изучал каждый ~~божий~~ рабочий день. В итоге я более-менее научился пользоваться некоторыми инструментами, но не имел четкого понимания, как именно они работают. Вследствие этого довольно часто я изобретал велосипед и усложнял вещи.

Кстати, не обращайте особого внимания на название инструментов того времени. В 2020 мало что из того используется.

Совет – всегда досконально изучайте то, с чем имеете дело. Знание деталей поможет вам писать более эффективный и лаконичный код. Многие скажут, что для того, чтобы водить машину, необязательно знать устройство двигателя. Скажу лишь то, что это довольно бредовая аналогия, и что для меня разработчик – это не водитель, а механик. А вот ему уже все-таки надо знать хоть чуть-чуть, верно? Задача плохого разработчика – сделать, чтобы работало. Задача хорошего разработчика – чтобы работало эффективно. (А задача совсем хорошего разработчика – чтобы еще и код было приятно читать и сопровождать).

Дальнейшее развитие

Около года я проработал на этом проекте. Я помню, что офис находился далеко от дома, и я решил ездить на работу к 7:30 утра по следующим причинам:

Не попасть в пробки
Успеть занять место на парковке
Мой лид приходил часам к 11. Следовательно, до 11 я мог читать книги по программированию

Таков был мой замысел.

В это время я прочитал книгу Брюса Эккеля «Философия Java» и первый том книги по Java Кея Хорстмана и Гари Корнелла. Честно говоря, чтение давалось с трудом. Думаю, это из-за того, что я не до конца представлял, что произойдет после того, как я их дочитаю. Я не особо представлял себе свое будущее, были лишь размытые цели типа «лучше освоить программирование и стать хорошим разработчиком».

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

Худший проект в жизни

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

Мы туда попали вдвоем с другом, с которым вместе ходили на курсы. Это плюс. Единственный.
Мы занимались правками JSP страничек и Struts классов. А на стороне ABAP сидел лодырь, правки от которого мы могли ждать часами. Простейшие правки.
JSP странички содержали практически всю логику приложения. Говоря современным языком – логика лежала в контоллерах (вьюхах, презентерах)
Отвратительное подобие менеджера проекта, который раз в неделю появлялся в скайпе и спрашивал: «Ну как, все хорошо?». Следовательно, все проблемы с заказчиком мы решали сами.
Невозможно было сразу увидеть результаты своих правок. А деплой мог тоже длиться часами, к тому же деплои нужно было согласовывать с командой заказчика.

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

Настоящая разработка

И вот, опять-таки в 2013 году, я попал на уже настоящий Enterprise. Там я познакомился с Maven и рядом продуктов IBM: WebSphere, RAD, DB2. Что мне особенно понравилось, так это то, что я плотнее познакомился с JavaScript и jQuery (тогда его еще вроде как использовали). А еще там был очень суровый самописный аналог Hibernate. Это объяснялось тем, что сам Hibernate «тормоз», а нам нужен был реактивный (в смысле быстрый) механизм ORM, который мгновенно положит записи в базу и заберет их оттуда. Не сказать бы, что я с этим согласен, но на тот момент это вполне могло иметь смысл – система имела миллионы запросов ежедневно, поэтому дело осталось за JDBC. В общем, мы не делали маппинг сущностей БД на Java классы и работали с простыми запросами.

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

Этап 3: Смена работы

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

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

Меня собеседовали не в переговорке, а в обычном кабинете, где сидели и работали люди. Думаю, это напрягало не только меня.
Я пришел как раз в период аврала, и спустя 3 недели мне пришлось целый месяц выходить по выходным. За это я получил компенсацию за полтора рабочих дня по ставке один к одному с формулировкой: «Ну ты же ничего полезного особо не сделал, проект не знаешь еще»
Отсутствие процессов. У нас была Jira, но ей никто не пользовался. Активности отмечались в гуглодоке, а задачи ставились либо по скайпу, либо менеджером по телефону. Само собой, все забывалось, и что-то не делалось или делалось не так.
Отвратительный офис с маленькой кухней, сделанной из комнаты, и общим на этаж туалетом.
Требование появляться в офисе в 10 утра. Жутко неудобно, так как по утрам я люблю делать свои дела. Конечно, можно вставать пораньше, но это уже я не люблю.
Все мои предложения по улучшению процессов не возымели эффекта.
Учиться было особо не у кого – не было действительно сильных программистов. Точнее, они были, но вели себя довольно расслабленно и просто «лутали баблишко».

Из плюсов – хороший коллектив!

Чем дольше я работал, тем отчетливее понимал, что этот этап будет недолгим. На проекте я познакомился с GWT, Spring и более плотно поработал с Hibernate. Собственно, GWT мне не понравился, я посчитал его абсолютно недееспособным на фоне современных инструментов. Дополнительно изучать GWT я не стал. Оговорю сразу, что это лишь мое впечатление от столкновения с ним.

Свои проекты и переосмысление

Зато в это время у меня появился общий с друзьями небольшой проект. Проект был довольно простенький, но все же было интересно его продумывать и реализовывать. Я ближе познакомился с JavaScript, Spring, Hibernate и JUnit.

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

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

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

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

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

Этап 4: Возвращение на родину

Итак, я вернулся в ту компанию, которая дала мне старт как разработчику. Мне попался довольно крупный проект с Big Data, и мы использовали вполне современный стек: Spring, Hadoop (и его экосистема: HBase, Oozie, etc), Maven, TestNG. Вероятно, многие посчитают Hadoop уже не таким современным, но это не умаляет современности самого направления. А еще именно тогда я познакомился со Slack и очень оценил этот инструмент.

Наш проект состоял из менеджера и двух Java-разработчиков в нашем офисе, а также менеджера и Java-разработчика в США. Вернувшись, я сразу почувствовал всю разницу между хорошими процессами и их отсутствием:

Мы использовали Jira и работали по Agile. Я не боготворю Agile, но работать проще, когда у тебя есть зафиксированный объем работы.
У нас были действительно короткие встречи по утрам и не было затянутых нудных созвонов.
Было чему поучиться у второго программиста в нашем офисе.
Адекватные код-ревью.
3 раза в неделю у нас были короткие созвоны, где менеджер предоставлял нам краткую выжимку того, что происходит в компании и на соседних проектах, а также планы по нашему проекту.

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

А может, что-то совсем новое?

Я внезапно почувствовал острое желание работать ближе к клиенту, возможно даже заняться front-end. Мне начало жутко надоедать работать с Big Data. Мне надоело ходить через несколько удаленных рабочих столов на сервер. А еще мне надоело запускать свой Job и затем подолгу копаться в логах и анализировать их. Ни в коем случае не назову это скучной и нудной работой, но что-то изменилось. Мне просто хотелось программировать. То, что поначалу показалось весьма новым и интересным, спустя время начало надоедать и становиться рутиной. Я пошел к начальству и честно все сказал: я хотел попробовать front-end. А параллельно с этим отправил «шальное» резюме на случайно увиденную, но очень интересную вакансию.

Сложное решение

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

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

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

Не так давно я встретился на улице с тем самым ресурс менеджером. Мы хорошо поговорили, и никаких негативных эмоций он ко мне не испытывал. Он все понимал.

Этап 5: RoR Developer

Да. Я занялся программированием на Ruby on Rails. Не буду подробно писать о процессе изучения нового языка, лишь самое главное:

Меня практически сразу бросили на боевой проект
Коллега по проекту, также бывший Java-разработчик, активно помогал и рассказывал об особенностях языка
Руководитель направления тоже весьма активно участвовал в моем развитии и обучении
Я прочел документацию и несколько книг по теме

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

Итак, поздняя осень 2015. Я уже полгода работал в новой компании, зарплаты хватало на все, проект хоть и не самый интересный, но для меня было много нового, следовательно я не скучал. На проекте я познакомился со множеством интересных инструментов: некоторые сервисы Amazon, Heroku, rspec и множество гемов для rails. Но самое главное – я пощупал динамический язык программирования. И если поначалу было абсолютно ничего не понятно, то спустя полгода началась эйфория от этой магии. А потом снова стало непонятно.

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

Upwork?

В общем, прошло полгода, как я занимаюсь программированием на Ruby on Rails. Примерно в это время я заинтересовался Upwork. Но заказ я нашел на JavaFX и занимался им около месяца по 10-20 часов в неделю. Понравилось, но график 40 + 10(20) начал утомлять, поэтому после окончания проекта я решил отдохнуть от Upwork пару месяцев.

А вот и сайт Upwork

https://www.upwork.com/

Затем я нашел другой проект, уже на Ruby on Rails. Ставка была очень хорошая, но также было условие: работа fulltime. Длительность – от месяца до трех. Если кратко – я работал месяц, дальше проект свернулся по причине стартапа. Это было очень тяжело – первую неделю я отработал все 40 часов вдобавок к тем 40 на основной работе. Далее я работал 35, 30 и 25 часов во вторую, третью и четвертую недели соответственно. Это настолько меня утомило, что я решил еще несколько месяцев отдохнуть от дополнительных проектов. Хотя, стоит отметить, заработал я вполне неплохо за это время.

Да не, уж лучше не заморачиваться

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

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

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

Я решил вплотную заняться Upwork.

Этап 6: Fulltime удаленка через Upwork

Я немного поискал и нашел подходящую мне работу. Это long-term сотрудничество с довольно крупной американской компанией. Первые 3 недели я работал параллельно на двух работах, а уволился со старой работы лишь после того, как получил email с указанием того, что новый работодатель очень доволен качеством моей работы, и классным задачам и морю веселья для меня не будет конца.

На данный момент я работаю здесь чуть более 4 лет, и пока что меня все устраивает: стек, процессы и коллектив. Западный стиль управления мне нравится больше. Мне нравится слышать слова “amazing”, “fantastic”, “awesome” при оценке моей работы. Само собой, со своей стороны я тоже прикладываю максимум усилий, чтобы услышать эти слова.

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

Как найти работу на Upwork?

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

Заполнение вашего профиля очень важно. Это то, что работодатель увидит во вторую очередь.
Конечно, хорошо пройденные тесты на знание языков и фреймворков вам на руку.
Cover letter при отклике на вакансию крайне важно. Это то, что работодатель увидит в первую очередь. Укажите, кто вы и откуда, какой у вас часовой пояс, и готовы ли вы работать по бизнес-часам работодателя, хотя бы частично. Укажите свой опыт и стек, а также дайте понять, что вы хорошо знакомы со стеком работодателя. Не врите. Скиньте свой профиль на linkedin/github/stackoverflow. Если вы только начинаете и у вас пока нет репутации на Upwork – можете указать о готовности выполнить тестовое задание на несколько часов.
Портфолио также будет отнюдь не лишним.
Работайте только с работодателями, у которых рейтинг стремится к 5 звездам. Читайте отзывы. Помните, что неадекватный клиент может подпортить вашу репутацию, и затем найти нормальную работу будет проблематично.
Кто-то рекомендует хвататься поначалу за любые заказы, будь то даже пятидолларовый фикс-прайс за пару часов. Я не думаю, что выполнение дешевых заказов красит вас как опытного разработчика, поэтому я изначально брался только за почасовые долговременные заказы с не самыми низкими расценками
Избегайте заказчиков, которые не уважают вас как программиста, а хотят лишь, чтобы кто-то выполнил их задачи.
Сами уважайте ~~своего господина~~ работодателя.

Не все клиенты одинаково хороши

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

– Эта задача может быть выполнена быстрее, чем за 12 часов. Я заплачу только за 10.
– В смысле? Зачем тогда вы меня просили сделать оценку задачи? Я очень подробно описал, почему это займет именно 12 часов.
– Я занимался программированием в прошлом и кое-что понимаю. К тому же, я не согласен с тем часом, который вы выделили на риски. Его можно исключить.
– Эти часы нельзя исключать из эстимейта, так как мне необходимо поддерживать старый (и очень плохой) код предыдущего разработчика – в процессе внедрения фичи что-то может пойти не так.
– Артём, вы же профессионал и должны понимать, что это бизнес – я плачу только за фактически выполненную работу, а не за ваши часы.
– Во-первых, ваш бизнес меня не касается. Если я потрачу 12 часов на выполнение задачи, я буду ожидать оплату за 12 часов. Если потрачу 6 – оплатите мне 6 часов. Иными словами, я ожидаю оплату за все время, что я потрачу на ваши проекты. Во-вторых, у нас была договоренность о почасовой работе, а текущее развитие событий меня не устраивает.
– Хорошо, пожалуйста сделайте коммит всего, что у вас есть. Я найду другого разработчика

А что не так?

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

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

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

Удаленка мне понравилась

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

Укомплектованная команда: аналитика, разработка, QA, devops.
Работа по спринтам с четкой постановкой задач.
Заработная плата в ощутимо выше, чем на прошлом рабочем месте.
Работа из дома – для меня это плюс, так как не испытываю проблем с самомотивацией и дисциплиной.

Совет: не торопитесь. Суммарно за 4 проекта на Upwork я видел немало ужасного кода. Люди часто уходят на вольные поля, не получив достаточного количества опыта и не научившись программировать. Их банально никто не тыкает носом в их косяки и не говорит, как надо это делать правильно. К тому моменту, когда я устроился на удаленку, мой путь длился 6 лет, из которых 4 я посвятил разработке и постоянному самообразованию. 80% времени мной повелевали опытные и мудрые тимлиды, которые передавали мне частичку своего опыта. Не торопитесь уходить во фриланс/удаленную работу.

Заключение

Да, 10 лет – это немного. И достиг я далеко не многого. Но все же довольно длинный путь уже пройден. Я не жалею ни об одном своем шаге на протяжении этого пути. По большей части, эта статья – просто мои воспоминания и выписка основных моментов. А все советы, которые я позволил себе озвучить – это те советы, которые я дал бы самому себе, если бы мог. Но, тем не менее, я буду очень рад, если это подобие мемуаров вдохновит кого-то заняться программированием или чем-либо еще 🙂 Успехов!

Как и обещал, про цифры

На первом рабочем месте, еще в студенческие годы, моя зарплата составляла 12000 рублей. С учетом того, что работал я на 3/4 ставки, получалось 9000. Это немного даже для 2010 года.

За 2 года, что я провел в той компании, моя зарплата постоянно, хоть и понемногу, росла. К моменту увольнения она составляла 15000 рублей за те же 3/4 ставки.

Когда я устроился программистом, я сразу стал получать 20000 рублей и вышел на полную ставку. Это был 2012 год. Каждые полгода зарплата росла на 5000 рублей, и в 2013 году я начал получать 30000. Однако, вместо следующего повышения я услышал: «Не повысим». И я ответил: «Э! Ухожу». И начал получать 35000.

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

Вернулся в старую компанию на 50000.

Уволился и устроился RoR разработчиком на 80000 на испытательный срок и 100_000 после него.

На первых двух контрактах на удаленке я получал $20 и $25 в час. Сейчас я получаю больше, но это уже другая история 🙂

В общем, самая лучшая инвестиция – это инвестиция в себя! Ставьте важные для себя цели, верьте в свои силы и прикладывайте усилия, и все у вас получится!

Подписывайтесь на меня в соцсетях!