Привет! В этой статье я хочу рассказать о своем пути в области IT. На данный момент он занял у меня уже 6 лет, и еще отнюдь не завершен. Я начинал как QA инженер еще будучи студентом, а сейчас я работаю удаленно через Upwork на довольно крупную американскую компанию. Нет смысла указывать конкретные компании, в которых я работал, поэтому все названия будут в стиле “вот эта вот” и “другая”.
Итак, 6 лет. Не так уж и много, и, честно говоря, я уверен, что не знаю практически ничего полезного и не являюсь выдающимся разработчиком. Но этого срока было достаточно, чтобы получить определенный опыт, поэтому я позволю себе делать некоторые выводы и даже давать маленькие советы тем, кто еще в самом-самом начале своего пути.
Этап 1: QA Engineer
Я начал работать QA инженером (пишу именно это умное слово, а не “тестировщик”, поскольку в трудовой стоит именно эта запись) летом 2010 года, тогда я перешел на 4й курс университета. Университет весьма уважаемый, впрочем, это не имеет значения.
Я твердо решил стать разработчиком, когда мне было лет 12. Тогда у меня еще не было компьютера, но была замечательная приставка СЮБОР, позволяющая писать простейшие программы. Но спустя 8 лет я стал тестировщиком… то есть, простите, QA инженером. Дело в том, что мне поначалу довольно тяжело давалось программирование, и я не мог схватить как следует идею ООП, да и с функциональным программированием у меня было тоже довольно посредственно.
Итак, я устроился по профилю, довольно близкому к разработке, и это меня утешало. К тому же, мануальным тестированием я занимался крайне мало, потому что мой лид практически сразу решил меня бросить на авто-тестирование. Спасибо ему большое за это! Я писал авто-тесты на Selenium WebDriver, используя Java. В процессе написания скриптов я познакомился с такими штуками, как JUnit и Eclipse. А параллельно почитывал книжку по 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. Всего было так много, что я решил даже не заниматься дополнительно, ведь итак много всего изучал каждый божий рабочий день. В итоге я более-менее научился пользоваться некоторыми инструментами, но не имел четкого понимания, как именно они работают. Вследствие этого довольно часто я изобретал велосипед и усложнял вещи.
Совет: всегда досконально изучайте то, с чем имеете дело. Знание деталей поможет вам писать более эффективный и лаконичный код. Многие скажут, что для того, чтобы водить машину, необязательно знать устройство двигателя. Скажу лишь то, что это довольно бредовая аналогия, и что для меня разработчик – это не водитель, а механик. А вот ему уже все-таки надо знать хоть чуть-чуть, верно? Задача плохого разработчика – сделать, чтобы работало. Задача хорошего разработчика – чтобы работало эффективно. (Задача совсем хорошего разработчика – чтобы еще и код было приятно читать).
Около года я проработал на этом проекте. Я помню, что офис находился далеко от дома, и я решил ездить на работу к 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, то JDBC – это Java DataBase Connectivity, просто механизм взаимодействия с базой без каких-либо преобразований записей БД в объекты).
Где-то спустя полгода я начал понимать, что застаиваюсь, поэтому попросил перевести меня на другой проект. Я так и мотивировал эту просьбу: мне проект надоел, он довольно древний, а мне хочется чего-то нового. Руководство отнеслось нормально, и спустя месяц я попал на еще более древний проект. Тогда я решил что пора принимать более решительные меры. В целом цель была достигнута – я стал разработчиком, но надо ставить новую цель – стать хорошим разработчиком и работать с современным стеком, двигаться дальше. А еще я тогда решил, что нужно заниматься своими проектами, потому что на одной теории далеко не уедешь. В это время я и перешел в новый этап.
Этап 3: Смена работы и свои проекты
Я понял, что текущее место работы не дает мне развития. Я работал на довольно старом и неповоротливом проекте, и это мне начало надоедать. Я не готов был оседать на одном месте, не научившись практически ничему.
Пропуская мелочи – я устроился в ужасную компанию, но на более высокий оклад и другие технологии. Хочу выписать основные минусы:
- Собеседование. Меня собеседовали не в переговорке, а в обычном кабинете, где сидели и работали люди. Думаю, это напрягало не только меня.
- Переработки. Я пришел как раз в период аврала, и спустя 3 рабочих недели мне пришлось целый месяц выходить по выходным. За это я получил компенсацию за полтора рабочих дня по ставке один к одному с формулировкой: “Ну ты же ничего полезного особо не сделал, проект не знаешь еще”
- Процессы. Точнее их отсутствие. У нас была Jira, но ей никто не пользовался. Активности отмечались в гуглодоке, а задачи ставились либо по скайпу, либо менеджером по телефону. Само собой, все всегда забывалось, и что-то не делалось или делалось не так.
- Отвратительный офис с маленькой кухней, сделанной из комнаты, и общим на этаж туалетом.
- Требование появляться в офисе в 10 утра. Жутко неудобно, так как по утрам я люблю заниматься спортом. Конечно, можно вставать пораньше, но это уже я не люблю.
- Все мои предложения по улучшению процессов не возымели эффекта.
- Учиться было особо не у кого – не было действительно сильных разработчиков.
Чем дольше я работал, тем отчетливее понимал, что этот этап будет недолгим. На этом проекте я познакомился с GWT, Spring и более плотно поработал с Hibernate. Собственно, GWT мне очень не понравился, я посчитал его абсолютно недееспособным на фоне современных инструментов. Ну, и дополнительно изучать GWT я тоже не стал. Оговорю сразу, что это лишь мое впечатление от столкновения с ним.
Зато в это время у меня появился общий с друзьями небольшой проект. Проект был довольно простенький, но все же было интересно его проектировать и реализовывать. Я ближе познакомился с JavaScript, Spring, Hibernate и JUnit.
В этот период я начал читать книги не столько технические, сколько по написанию кода в целом. Во многом я проникся книгой “Чистый Код” дядюшки Боба.
Констатация факта: на определенном этапе приходит осознание того, что нужно знать не только используемые технологии, но и правила написания хорошего кода в целом – структура, архитекрура, рефакторинг и конечно же тесты.
Спустя 9 месяцев после смены работы я уже отчетливо понимал, что текущее место сильно тянет меня вниз, поэтому решил вернуться на предыдущее место работы. Естественно, на еще чуть больший оклад и интересный проект.
Совет: если имеется довольно сильный дискомфорт в работе, то не нужно бояться положить этому конец. Пусть даже ценой смены рабочего места. В конце концов, в этом нет ничего страшного. Соглашение изначально полагается как взаимовыгодное, и если вам оно невыгодно – исправляйте ситуацию.
P.S.: без фанатизма. Я не пропагандирую идею прыгать с места на место в попытках поднять свою позицию и оклад. Прежде всего, нужно постоянно чему-то учиться и применять знания во благо компании. Но если вы ощущаете, что застаиваетесь, что ваши знания не востребованы или что на вас ездят – тогда перечитайте совет выше.
Этап 4: Возвращение на родину
Итак, я вернулся в ту компанию, которая дала мне старт как разработчику. Мне попался довольно крупный проект с Big Data, и мы использовали вполне современный стек: Spring, Hadoop (и его экосистема: HBase, Oozie etc), Maven, TestNG. Вероятно, многие посчитают Hadoop уже не таким современным, но это не умаляет современности самого направления. А еще именно тогда я познакомился со Slack и очень оценил этот инструмент.
Наш проект состоял из менеджера и двух Java-разработчиков в нашем офисе, а также менеджера и Java-разработчика в США. Вернувшись, я сразу почувствовал всю разницу между хорошими процессами и их отсутствием:
- Мы использовали Jira и работали по 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.
Итак, прошло полгода, как я пишу на Ruby on Rails. Примерно в это время я заинтересовался Upwork. Но заказ я нашел на JavaFX и занимался им около месяца по 10-20 часов в неделю. Понравилось, но график 40 + 10(20) начал утомлять, поэтому после окончания проекта я решил отдохнуть от Upwork пару месяцев.
Затем я нашел другой проект, уже на Ruby on Rails. Ставка была $25/h, а также было условие: работа fulltime. Длительность – от месяца до трех. Если кратко – я работал месяц, дальше проект свернулся по причине стартапа. Это было очень тяжело – первую неделю я отработал все 40 часов вдобавок к тем 40 на основной работе. Далее я работал 35, 30 и 25 часов во вторую, третью и четвертую недели соответственно. Это настолько меня утомило, что я решил еще несколько месяцев отдохнуть от дополнительных проектов. Хотя, стоит отметить, заработал я вполне неплохо за это время.
Итак, я решил сосредоточиться на основной работе, а по вечерам отдыхать либо заниматься самообразованием, а не работать на другой. Некоторое время продолжался такой режим – я не перенапрягался, изучал новое и жил спокойно. А затем проект отдали индусам, а меня кинули на… наидревнейший проект на старых Ruby и со старой легаси-системой, которую мы поддерживали. Видимо, это мой рок – работать на старых проектах. Вдобавок к этому я начал все отчетливее видеть косяки в процессах компании, на которые не обращал внимания поначалу. Основные из них: скудный набор проектов и полнейшее отсутствие аналитики, а также отсутствие тестировщика на проекте.
Совет: если в вакансии в разделе “ожидаем от соискателя” фигурирует пункт “умение работать, не имея законченных требований”, то лучше знайте перевод: “У нас в компании нет аналитики, поэтому ее следует провести вам. И реализовать задачу потом тоже по своим же требованиям”.
Помните, я говорил, что только покидая зону комфорта, можно достичь новых высот? Работая на данной работе, я получал хорошую зарплату, меня устраивал коллектив и офис. В целом было комфортно, и я мог бы остаться на том проекте, особенно если учесть, что загрузка по нему не была полной. Я мог читать статьи и даже заниматься личными проектами в свободное время. Но какое развитие я получал, кроме своих личных начинаний? Как текущее рабочее место способствовало моему развитию? На одном изучении далеко не уедешь, нужна практика. И практика нужна не только в свободное время, но и в каждодневной работе.
Я решил вплотную заняться Upwork.
Этап 6: Fulltime на Upwork
Я немного поискал и нашел подходящую мне работу. Это long-term сотрудничество с довольно крупной американской компанией. Первые 3 недели я работал параллельно на двух работах, а уволился лишь после того, как получил email с указанием того, что работодатель очень доволен качеством моей работы, и классным задачам и морю веселья для меня не будет конца.
На данный момент я работаю здесь чуть более 2 месяцев, и пока что меня все устраивает: стек, процессы и коллектив. Западный стиль управления мне нравится больше. Мне нравится слышать слова “amazing”, “fantastic”, “awesome” при оценке моей работы. Само собой, со своей стороны я тоже прикладываю максимум усилий, чтобы услышать эти слова.
Я не буду описывать, как найти работу на Upwork – на хабре полно статей на эту тему. Опишу основные, наиболее важные моменты на мой взгляд:
- Заполнение вашего профиля очень важно. Это то, что работодатель увидит во вторую очередь.
- Конечно, хорошо пройденные тесты вам на руку.
- Cover letter крайне важно. Это то, что работодатель увидит в первую очередь. Укажите, кто вы и откуда, какой у вас часовой пояс, и готовы ли вы работать по бизнес-часам работодателя, хотя бы частично. Укажите свой опыт и стек, а также дайте понять, что вы хорошо знакомы со стеком работодателя. Не врите. Скиньте свой профиль на linkedin/github/stackoverflow. Если вы только начинаете и у вас пока нет репутации на Upwork – можете указать о готовности выполнить тестовое задание на пару часов.
- Портфолио также будет отнюдь не лишним.
- Работайте только с работодателями, у которых рейтинг стремится к 5 звездам. Читайте отзывы. Помните, что неадекватный клиент может подпортить вашу репутацию.
- Кто-то рекомендует хвататься поначалу за любые заказы, будь то даже пятидолларовый фикс-прайс. Я не думаю, что выполнение дешевых заказов красит вас как опытного разработчика, поэтому я изначально брался только за почасовые заказы с прайсом не менее $20/h.
- Избегайте евреев.
По поводу последнего пункта приведу пример. Я как-то нашел неплохой почасовой заказ, а у клиента был хороший рейтинг. Закончилось это тем, что клиент сразу же попросил оценивать задачи в часах и сказал, что платить будет только за то время, которое проставлено как estimate. В итоге у нас случился диалог примерно следующего содержания:
– Эта задача может быть выполнена быстрее, чем за 12 часов. Я заплачу только за 10.
– Если вы меня наняли, то извольте руководствоваться моими оценками. Я очень подробно описал, почему это займет именно 12 часов.
– Я работал в прошлом разработчиком и кое-что понимаю. К тому же, я не согласен с тем часом, который вы выделили на риски. Его можно исключить.
– Эти часы нельзя исключать из эстимейта, так как мне необходимо поддерживать старый код – в процессе внедрения фичи что-то может пойти не так.
– Артем, вы же профессионал и должны понимать, что это бизнес – я плачу только за фактически выполненную работу, а не за ваши часы.
– Во-первых, ваш бизнес меня не касается. Вы тоже профессионал и должны понимать, что вы вкладываете деньги не только в фактически выполненную работу, но и в знание проекта разработчиком, который будет его поддерживать. Если я потрачу 12 часов на выполнение задачи, я буду ожидать оплату за 12 часов. Если потрачу 8 – оплатите мне 8 часов. Иными словами, я ожидаю оплату за все время, что я потрачу на ваши проекты. Во-вторых, у нас была договоренность о почасовой работе, а текущее развитие событий меня не устраивает.
– Хорошо, пожалуйста сделайте коммит всего, что у вас есть. Я найду другого разработчика.
Так что снова повторю – не бросайтесь на первый же проект, показавшийся интересным. Изучите сначала историю этого работодателя.
Позволю себе отойти от лирики и опишу основные плюсы, которые я вижу на текущем рабочем месте:
- Укомплектованная команда: аналитика, разработка, QA, devops.
- Работа по спринтам с четкой постановкой задач.
- Заработная плата в 3,5 раза выше, чем на прошлом рабочем месте.
- Работа из дома – для меня это плюс, так как не испытываю проблем с самомотивацией и дисциплиной.
Если честно, я не знаю, как долго небо над головой будет безоблачным. С одной стороны, работа в России в соответствии с ТК РФ выглядит надежнее. С другой стороны, пары месяцев работы удаленно хватит для создания очень комфортной подушки безопасности. На данный момент ничего не предвещает беды, работодатель имеет большой скоуп задач на много месяцев вперед, а моя работа его вполне устраивает. А еще с каждой неделей растет моя репутация на Upwork, так что я смею надеяться, что в случае необходимости я найду новую работу довольно быстро. Также добавлю, что я работаю строго по ТК РФ – я зарегистрировал ИП и плачу налоги.
Совет: не торопитесь. Суммарно за 4 проекта на Upwork я видел немало ужасного кода. Люди часто уходят на вольные поля, не получив достаточного количества опыта. Их банально никто не тыкает носом в их косяки и не говорит, как надо это делать правильно. Мой путь пока что занял у меня 6 лет, из которых 4 я посвятил разработке и постоянному самообразованию. 80% времени мной повелевали опытные и мудрые тимлиды, которые передавали мне частичку своего опыта. Не торопитесь уходить во фриланс/удаленную работу.
Заключение
Да, 6 лет – это немного. Но все же довольно длинный путь уже пройден. Я не жалею ни об одном своем шаге на протяжении этого пути. По большей части, эта статья – просто мои воспоминания и выписка основных моментов. А все советы, которые я позволил себе озвучить – это те советы, которые я дал бы самому себе, если бы мог. Но, тем не менее, я буду очень рад, если это подобие мемуаров кому-то поможет или вдохновит на что-то. Успехов!
Автор: tmn4jq
