Инженер VS Программист. Или куда уходят инженеры
За последнюю неделю на Хабре появилось как минимум три поста о том, как люди разного возраста, пола и полученной специальности становились программистами. Успешными программистами. Эти истории отвечали на вопрос «как», но почти упускали вопрос «почему».
Сейчас я еще работаю инженером, причем по моей вузовской специальности «Радиофизика и электроника», и по профилю кафедры Антенн и Радиопередающих устройств. Но уже активно шагаю в сторону переквалификации.
Почему же я, инженер с 14 годами стажа, решил перейти в программисты?
Востребованость
В России сейчас инженер СВЧ не нужен. Новых разработок очень мало. Интересных проектов почти нет. Есть ВПК, где еще что-то разрабатывают, но там сидят деды, которые не дадут дергаться сильно. Секретный допуск и документация для передатчиков начинается от «совершенно секретно», что лишит вас радости путешествия за пределы России и повесит дамоклов меч службы Гостайны у вас над головой. Разработки только из элементов, доступных в перечне импортозамещения. Новые технологии? Слышали, но не можем. Ах, да, слышать и читать вы их не будете, интернет на работе запрещен.*
*данная информация является личным опытом автора поста
В частном секторе все еще хуже и печальнее. Если считать, что СВЧ в нынешнем его понимании начинается от 10ГГц и не включает сотовую связь, то мест, где вы найдете работу для разработчика, да еще по специальности, да еще за деньги — почти нет.
Оплата труда
Из причины выше можно увидеть, как работают законы рынка. Спрос на работу превышает предложения, поэтому зарплаты идут вниз. Оно и раньше инженер получал меньше рабочего.
Сейчас кажется, что всё осталось также. Средняя зарплата инженера-разработчика в Петербурге — 40 000 рублей. Данная цифра соответствует действительности. Причем разброс небольшой — от 23 до 60. Не нравится – иди работай в другом месте, на твое место есть очередь. Хотя в последнее время ситуация стала меняться еще в том, что на 30 000 руб приходят свеженькие выпускники вузов.
Поэтому я могу точно сказать – уровень образования технических вузов стремительно пикирует вниз. Потому что те, кто понимает на этапе обучения, что высоких зарплат не будет, сразу уходят в программисты.
Одна среда
Опять логический переход. Отличия инженера от программиста у нас небольшое. Системный подход, аналитическое мышление, умения решать поставленные задачи. Даже привычка делать код с костылями выросла из волшебного свойства синей изоленты. Более того, инженер-разработчик в нынешнее время — это в любом случае программист, потому что от микроконтроллеров, обработки сигналов и прочей алгоритмов никуда не деться. От инженера в программисты — всего пара шагов.
Перспективы
Опять выигрывает программист. Инженеры нужны все меньше и меньше. Все более узконаправленные и узконаправленные. В программировании все иначе, это как пучок технологий, где тренды меняются каждый год. «Нам нужно больше программистов». Этот рефрен можно услышать даже из чайника, по WiFi. Я боюсь, что станет, когда инженеров станет слишком мало, но радуюсь, что до этого не доживу. Пока что еще слишком много инженеров и слишком мало программистов.
Вывод напрашивается один. Идти в программисты. Почему я не сделал этого раньше? Одна единственная причина – я создаю устройства. Готовые, технологичные и полезные в пределах целого мира. За небольшую зарплату, с переработками и мыслями по ночам о том, как сделать лучше. Я могу подержать их в руках, я могу вспомнить, как они выглядели, каков был их нелегкий путь от идей к воплощению. Но, наверняка они будут продолжать создаваться и без меня…
Стоит ли иди в программирование, будучи инженером?
Оценить 1 комментарий
В программировании ты точно также рано или поздно уткнешься в потолок. Будь то финансовый, будь то моральный, как сейчас. Айтишников сейчас в скором времени будет как грязи. И зп в 100 тебе просто так никто не даст. Не верь сказкам.
Сайт, на котором начинающие программисты делятся впечатлениями об том, как их обидели?
Как можно при такой востребованности ИТ и таком дефиците мало-мальски квалифицированных спецов так нагибаться?
Не знаю как у вас, сэр, а у меня и моих друзей имеется очередь из клиентов.
Длиной примерно в пару месяцев.
Да, Kubernetes устанавливаю
Но знания уже должны быть, совсем нулевого человека не возьмёт никто.
Не стесняйтесь отправлять резюме на вакансии, даже если не под все из указанных требований подходите. Я пришёл на работу не зная трёх фреймворков, которые были указаны в требованиях, а уже через несколько дней нормально писал код под них, хоть и не очень быстро, переодически сверяясь с документацией и разбираясь, что откуда берётся.
В общем, устроиться вполне реально, если вы каждый день занимаетесь самообразованием и готовы, что на поиски может уйти два-три месяца или даже побольше.
Время. Инженер или программист?
Моя микробиблиотека про программирование вообще. В этот же список стоит добавить «Джоэль о программировании» Джоэля Спольски. Очень хорошая книжка)
Будь как я: инженер-программист ))))
В плане книг начать с ОБЯЗАТЕЛЬНО C ЭТОГО:
1. «Код», Чарльз Петцольд
2. «Как программировать на C++», два Дейтела
Не слушай никого. Достань эти книги как хочешь и начинай с них. Вторая очень популярна и постоянно переиздается, так что можно будет купить в бумажном виде. Гарантирую, затрешь книги до дыр. Особенно последнюю. Она стоит того, чтобы купить. Я с ней весь универ прошел и года три на работе непрерывно пользовался. Всех программеров в нее тыкал носом, как котят. Начитаются Керниги и Ритчи или Кнута, а сути не знают. Вообще не представляют как программа живет. Затем можно читать что угодно, но с этих двух книг нужно начинать по любому. И времени тебе такой подход сэкономит просто офигенное количество.
Еще вещь «Совершенный код». Но это перед тем, как пойдешь на работу. Чтобы не быдлокодить.
Когда за активностью твоей клавиатуры следит начальник.
Коллега на работе выполнил свое задание, но активность клавиатуры должна быть) в помощь кодерам пришли инженеры, ржали всем офисом.
Житие инженера
На одной из машин в настройках нашел пасхалку.
Человек-все
Не спрашивайте, почему я в свое время ушел от этого работодателя. Насчитал 5-6 профессий. Кто больше?
Про облака.
Есть старый, 15 лет назад сделанный механизм расчета. Считает медленно, с их слов, но они это воспринимают как данность.
Я говорю «Что-то тут неправильно, както медленно. Может пересмотреть уже подходы? Есть же новые инструменты, есть математика, в конце концов. «
Мне говорят «Да забей. Там знаешь какие люди делали? Это на века сделано, и лучше не бывает. «
Мне говорят «Ну давай, надо посчитать вот это. «
Они выкатывают кучу требований, описывают вычисления итд. Делаю за пару дней, тестим, 30 секунд.
Вышел в курилку. Вышел один из инженеров. Стоим курим.
И он мне выдает «Да оно у нас и на втором шаге уже часы считало, и это год говорят делали. А последний никто и не пробовал даже. А что такое облака, про которые ты говорил?»
Вот так. «Что такое облака?» 21 век на дворе. Часы считало 15 лет. Прогресс. И дождь пошел.
Полезные блоги для IT-специалистов
На окончательное осознание того, что содержимое хабра не отражает реального положения дел в IT-индустрии и всесторонне вредит профессиональному развитию, ушло около пяти лет.
Объяснять причины, приводить доказательства не буду: долго и выглядеть будет неубедительно для тех, кто пока не дошел до этой мысли самостоятельно. Однако перечислю ряд источников, которые, на мой взгляд, крайне полезны для ознакомления IT-специалистам любого профиля.
Также укажу примеры постов, чтобы сразу можно было открыть и начать читать.
6) Статьи Игоря Ашманова
Дополняйте в комментариях, у кого тоже есть интересный материал
Проект «Недовольный пылесос»
Что-то меня потянуло на пылесосную тематику.
Где-то 6 лет назад мною был приобретен робот-пылесос Румба. Сначала он не сильно прижился: на съемной квартире ему мешала пылесосить не самая удачная, но единственно возможная планировка мебели. Высланный в Калининград к родителям тоже стоял голодный и пылился, потому что мама мыла пол быстрее, чем тот пачкался. Окончательно пылесос осел со мной в Дании, освоился, резво пылесосил большую комнату и кухню и провожал меня на работу, за что был назван Бобиком.
А потом, в один из долгих зимних датских вечеров мне пришла в голову идея научить Бобика разговаривать. Идея простая: пылесос едет, натыкается на препятствие и говорит недовольным голосом «понаставили тут». Или «позасирали тут», если натыкается на грязь.
Идея простая, но реализация оказалась далеко не такой тривиальной. Дальше всякие технические детали.
Собственно, имелось следующее:
1. Сам пылесос Румба 500й серии и спецификация интерфейса, через который можно было общаться с пылесосом (через серийный порт)
2. Миникомпы (ардуино, распберри пай и свифт), с которых планировалось запускать программу для контроля сенсоров и проигрывания аудио записей
3. Куча проводов, макетная плата и прочие радости юного инженера
1. Динамик для проигрывания аудио записей. И как выяснилось позже, набор для создания аудио усилителя, потому что по умолчанию динамик слишком тихий, чтобы перекрыть 70 Дб пылесоса
2. Всевозможные трансформаторы напряжения, чтобы запитать миникомпьютер от батарейки пылесоса и чтобы настроить соединение через серийный порт.
Неделя была потрачена на поиск и закупку трансформаторов со всевозможными емкостями, проводов, резисторов, динамика и прочего барахла.
Первым делом надо было разобраться с аудио усилителем. В интернете нашелся прекрасный сайт с не менее прекрасными схемами. Простите за шакальную картинку
Заработало почти с первого раза, хоть и выглядело довольно убого. Тем не менее до 80 Дб звук дотянулся, что было уже вполне достаточно. На фотке как раз убогий вариант.
Окей, дальше надо было заставить распберри общаться с Румбой через серийный порт. Тут пришлось немножко попаять (шикарно слово, я считаю) регулятор напряжения. Ну и конечно разобраться, где вход-выход-земля. Это я осилила далеко не сразу, но в итоге что-то получилось.
Научилась двигать пылесос по прямой путем отправки специальной команды через Румба-интерфейс. И всё, казалось бы, шло хорошо, пока я не попыталась получить данные с сенсоров (грязевого и бампера, чтобы как раз отследить, когда надо начинать разговаривать). Румба начинал включать моторы, кататься вперед-назад, дергаться, двигать щеткой, затихать на 20 минут и начинать всё по новому. Заткнуть несчастного Бобика можно было только вынув батарейку, что задалбывало.
На этом потерялось довольно много времени, и в итоге было принято решение заставить распберри общаться не с пылесосом, а с ардуино (хорошо иметь больше двух миникомпьютеров). И тут это зараза и попалась. Ардуино слал распберри сообщение в стиле «Привет, лох, чо как там?», а распберри предлагал.. ВВЕСТИ ПАРОЛЬ. Всего-то надо было поменять настройки. Заработало. Счастье.
Все инженеры умеют программировать, но не все программисты могут быть инженерами: в чем отличие?
Никто не может стать инженером за два месяца, за шесть месяцев или за год. Почему не все программисты могут называться инженерами и какими навыками обладают настоящие инженеры-разработчики?
Многим людям не нравится термин “инженер по разработке программного обеспечения” из-за относительного сравнения с инженерным делом. Но эта статья посвящена не термину. Если вам не нравится название, вы можете заменить его на “автор ПО”, “мастер ПО” или даже “художник по ПО”.
Под инженером по разработке я подразумеваю человека, который считает создание качественных программ своей профессией. Человек, который применяет науку и статистику в своей профессии и не смотрит на это как на работу, которая просто приносит деньги.
Знание программирования не делает вас инженером. Любой может научиться программировать. Любой может создать простые программы, которые будут работать для него на собственном компьютере, но это не гарантирует, что те же программы будут работать для остальных.
Моя любимая аналогия — любой человек может петь для себя в душе, но на вечеринке вы не будете ставить свои записи. Вы полагаетесь на профессионалов.
Хотите еще бльше аналогий? Конечно:
Я хочу донести мысль о том, что простые программы отличаются от тех, что создали инженеры. Программирование — это создание инструкций для компьютеров, чтобы они приняли входные данные и превратили их в определенный результат.
Процесс проектирования программ — это планирование, написание, тестирование и поддержка компьютерных программ с целью решения проблемы для многих пользователей. Это создание надежных решений, которые выдержат проверку временем и будут работать не только с очевидными проблемами, но и с неизвестными.
Инженеры понимают все о проблемах, которые они решают, о своих решениях, об ограничениях этих решений, последствиях этих решений для приватности и безопасности.
Если человек не понимает проблему, он или она не может создать решение для нее.
Склонность к поиску решений
Инженеры не считают свою деятельность просто написанием программ. Они думают о потребностях и решениях проблем. Это важно, потому что не каждая проблем нуждается в новой программе. Некоторые проблемы можно решить уже существующими программами. Некоторые проблемы можно вообще предотвратить, если действовать заранее. Создание хороших программ часто включает предотвращение будущих проблем.
Сложные проблемы требуют создания нескольких программ. Некоторые проблемы требуют параллельной работы программ, а другие — последовательной. Некоторые проблемы можно решить обучением пользователей.
Перед созданием программы инженер задает вопросы:
Качество кода
Отличные программы понятны, и их можно легко расширить, они отлично работают с другими программами, а поддерживать их не так сложно. Качеством кода нельзя жертвовать, а использовать временные решения из-за дедлайна или эмоций — неприемлемо.
Один из самых важных аспектов разработки ПО — создавать с самого начала системы, которые можно будет расширять. Изменение программ неизбежно. Пользователи начнут требовать новых функций и новых способов применения программ.
Сама по себе программа не так полезна. Ценность их функций проявляется, когда разные программы коммуницируют друг с другом, обмениваются данными и совместно работают над представлением данных и интерфейсов пользователям. Об этом нужно помнить при создании программ. Какие сообщения они будут принимать? Какие события будут отслеживаться? Какие сообщения они будут отправлять? Как мы будем проводить аутентификацию и авторизацию коммуникаций?
Другой важный аспект отличных программ — это ясность кода, а не количество тестов или число в отчете по тестовому покрытию. Этот код может прочитать кто-то ещё? Смогу ли я понять этот код через несколько недель?
В программировании существует только две по-настоящему сложных вещи: инвалидация кэша и именование переменных, — Фил Карлтон
Удобство чтения кода важнее, чем вы думаете. К сожалению, для ясности кода нет хороших метрик. Знание хороших методов может помочь, но часто этого недостаточно. Хорошие инженеры просто учатся этому с опытом. Здесь подходит метафора с писательством: знание большого количества слов не поможет вам писать понятные тексты.
“У меня не было времени на короткое письмо, поэтому я написал длинное”, — Марк Твен
В программах случаются ошибки. Возможность без проблем исправить их — это ключевой атрибут хорошей программы. Ошибки должны сопровождаться понятными сообщениями и храниться в одном месте. Когда появляется отчет о новой ошибке, ответственный за исправление человек должен иметь возможность устранить в ней баги. Он или она должны иметь возможность зайти в систему и прочитать информацию об ошибке в любое время. У них должна быть возможность подтвердить ожидания о любой части системы.
Среда и тестирование
Когда инженеры пишут программы, они должны убедиться, что эти программы будут работать в разных средах, на разных устройствах, в разных часовых поясах. Программы должны работать на экранах разного размера и ориентации. Они должны справляться с ограниченностью памяти или вычислительной мощности.
Программное обеспечение для браузера должно работать во всех популярных браузерах. Программы для компьютеров должны работать для пользователей Mac и Windows. Приложения для работы с данными должны работать, когда подключение слишком медленное или его совсем нет.
Чтобы написать программу, инженеры должны продумать любой возможный сценарий и спланировать тестирование всех этих сценариев. Это начинается со “счастливого пути”, когда ничего неожиданного не происходит, но затем инженеры должны прописать каждую проблему, которая может случиться, и написать для них тесты. Некоторые инженеры начинают с написания тест-кейсов, которые симулируют эти сценарии. Затем они пишут код, который проходит все эти тесты.
Инженеры понимают расплывчатые требования программ. Уникальный навык инженера — это не просто знать, как написать решение, но понять, что должно быть в этом решении.
Стоимость и эффективность
Во многих случаях инженеры могут решить проблемы быстро. Если вы думаете, что найм опытных программистов повысит расходы, подумайте еще раз. Чем больше у программиста опыта, тем быстрее он или она сможет создать надежное решение, которое можно будет поддерживать без особых трудностей. Это означает сокращение расходов в долгосрочной перспективе.
Вам также нужно принять во внимание стоимость запуска программы. Каждая программа будет использовать компьютерные ресурсы, которые не бесплатны. Инженеры будут писать эффективные программы, которые не будут тратить компьютерные ресурсы впустую. Например, это кэширование часто используемых данных, но это только одно из тысяч решений, которые могут сделать программу быстрее и эффективнее.
Начинающий программист может сделать для вас дешевое решение, но оно в итоге потребует у вас и у вашего клиента больших затрат, чем изначально эффективное решение.
Удобство использования
Хорошие программы создаются с учетом пользовательского опыта. Взаимодействие человека и компьютера — это большая тема с многочисленными исследованиями и выводами. Чем чаще будут учитываться эти выводы, тем лучше будут программы.
Вот несколько примеров:
Читабельность и безопасность
Это наиболее важные моменты, которые отличают профессионалов от любителей. Они знают, что ответственны за создание надежных и безопасных решений.
Программа должна быть устойчивой к плохим входным данным, состояниям и взаимодействиям. Этого очень сложно достичь, и поэтому мы слышим о том, что люди погибают из-за ошибок в ПО.
Пользователи будут вводить неверные данные в программу. Некоторые будут делать это специально, чтобы взломать её. Ответственного за недавний скандал с Equifax обвинили в том, что этот человек не сделал свою работу, то есть не создал устойчивую к зловредным входным данным программу.
Безопасность касается не только зловредных данных, но и обычных. Если пользователь забывает пароль, то сколько раз он или она сможет его ввести? Заблокируете ли вы после этого аккаунт? Что если кто-то этого и добивается? Позволите ли вы вводить пароль через незащищенное соединение? Что если попытка логина состоялась из необычного места? Что если логин кажется сгенерированным автоматически?
Что вы сделаете, чтобы защитить пользователей от межсайтового скриптинга и подделки запросов, атаки посредника и простого социального фишинга? Есть ли у вас стратегия на случай DDoS-атаки? Эти вопросы — это только несколько из проблем, к которым вы должны готовиться.
Безопасные программы не хранят чувствительную информацию в форме простого текста, а в виде зашифрованных данных, которые сложно взломать. Это запасная стратегия на случай взлома. В программах будут случаться ошибки, и если вы об этом не знаете или вы не подготовлены, то вас нельзя считать профессионалом.
Дефекты программ невидимы. Наша способность предсказывать и предотвращать известные дефекты ограничена. Поэтому инженеры понимать ценность хороших инструментов, которые могут помочь им писать корректные и безопасные программы.
Инструменты
Несомненно, нам нужны хорошие инструменты. Они многое меняют и часто недооцениваются. Представьте, если бы нам все ещё нужны были FTP для файлов! Представьте проблемы с производительностью и устранением багов без Chrome DevTools! Представьте, как неэффективно бы было писать на JavaScript без ESLint и Prettier!
Любой инструмент, который сокращает цикл обратной связи, должен быть ценным дополнением. Аргумент Брета Виктора об изобретении мгновенной визуальной репрезентации того, что мы создаем, открыл мне глаза. Принятие и улучшение инструментов — это единственный способ попасть в это светлое будущее.
Когда я нахожу отличный инструмент, я жалею лишь о том, что не нашел его раньше. Хорошие инструменты помогут вам стать хорошим программистом. Ищите их, используйте их, цените их и улучшайте их.
Эволюция разработки
Никто не может стать инженером за два месяца, за шесть месяцев или за год. Вы не научитесь этому в буткемпе. Я учусь на протяжении последних двадцати лет. Я стал достаточно уверенным, чтобы назвать себя опытным программистом только после десяти лет обучения и создания и поддержки приложений, которые используют тысячи пользователей.
Разработка не для каждого, но все должны учиться решать свои проблемы с компьютерами. Если вы можете научиться писать простые программы, то стоит это сделать. Если вы можете научиться использовать сервисы, то стоит это сделать. Знание программ с открытым исходным кодом даст вам много возможностей.
Проблемы эволюционируют, и разработка должна развиваться аналогично. Будущее этой профессии — позволить обычным пользователям использовать свои компьютеры без необходимости учиться пять лет. Дайте пользователям возможность решать простые проблемы простыми инструментами. Инженеры должны создавать хорошие инструменты, решать большие проблемы и пытаться предотвращать неизвестные.
Мой путь из инженера в программисты
Краткое содержание
Автор поныл, как тяжело живется инженерам на Руси и решил уходить в программисты. У него получилось. Пост о том, как именно.
Зачем я все это пишу
Благодарность
Ради этого пост задумывался. С этого и стоит начать.
Мой пост «Инженер VS Программист. Или куда уходят инженеры» принес множество комментариев, несколько личных сообщений, пару собеседований. Самое главное — он принес мне волну поддержки, позитива и мотивации.
Большое спасибо всему сообществу Хабра! Именно поддержка сообщества дала вдохновляющий пинок, вперед, к моей цели, и привела меня в программисты.
Отдельное спасибо хочу сказать serenityfx, который специально зарегистрировался, чтобы оставить комментарий с предложением поделиться своим опытом, нашел время побеседовать со мной лично, ответить на мои вопросы. Он дал мне направление и помог составить некое понимание, как и куда идти дальше.
Спасибо, Хабр! Ты крутой!
Краткое содержание прошлого поста
Проработав 14 лет инженером, в том числе инженером-разработчиком, я решил перейти в программисты, потому что инженер-программист — востребованная специальность с более высокой оплатой труда, широкими перспективами и возможностями.
Мой путь
Благодаря фидбеку от Хабра, я смог четко сформулировать два пути развития дальше.
Первый — еще раз попытаться найти себя как инженера-разработчика, как в России, так и за ее пределами. Благо, прямо из комментариев пришло несколько личных контактов, которые позволили сделать несколько попыток.
Второй путь, который тоже прорисовался достаточно четко – качать навыки программиста микроконтроллеров и встроенных систем и искать начальные позиции (джун-мидл) в этой сфере.
Как «умная и красивая обезьяна», у которой было время, я попытался идти одновременно по двум направлениям. Активно занялся поиском работы, в том числе за рубежом, и стал качать свои навыки в контроллерах.
Через полгода стало понятно, что первый путь все же тупиковый. Надо идти в программисты. Стечение обстоятельств подтолкнуло меня к увольнению. Я сосредоточился на контроллерах и поиске работы, но уже в качестве программиста.
Неожиданно для себя я получил предложение поработать в качестве фрилансера на проекте, который одновременно использовал меня и как программиста контроллеров, и как инженера-разработчика. Моя жизнь фрилансера продлилась 8 месяцев и закончилась вместе с платежами по заказам. Но мои навыки программирования за это время сильно подросли, поэтому я вернулся к рынку труда и поиску вакансии инженера-программиста.
По результатам одного из собеседований меня пригласили сначала на стажировку, потом на испытательный срок, который плавно перетек в постоянный контракт. Так я стал инженером-программистом встроенных систем.
Но давайте чуть подробнее о каждом из этапов.
Стартовая позиция
Начинается с инженера-разработчика. На самом деле, моя работа на половину состояла из разработки и тестирования алгоритмов, железа, на четверть из организационных вопросов — управлением командой, закупками и документацией, и на четверть из программирования разработанных устройств.
Как у инженера старой школы, у меня была склонность к теоретическим знаниям, поэтому к моменту увольнения за спиной у меня уже было несколько пройденных курсов разной степени полезности:
Кроме того были интересные, но бесполезные курсы от HTML Академии ИТМО (HTML/CSS/JS),
«Управления проектами» от ВШЭ и «Теория графов» от ИТМО. А также половина пройденного курса на JavaRush, который был заброшен после решения идти в embedded.
На практике у меня был опыт моделирования и обработки сигналов, связанных с моими устройствами. Опыт написания прошивок для контроллеров серии C8051 от SiliconLabs, младших контроллеров Atmel и немного опыта разработки для FPGA от Altera.
Также за спиной был опыт управления командой и мелкосерийным производством, но я считал его нерелевантным.
В поисках вакансии
Тема собеседований достойна отдельного поста. Их было много, они проходили волнами.
На собеседованиях был много странностей. Когда я приходил собеседоваться на позицию программиста, меня спрашивали, почему с таким опытом я не хочу работать инженером. На собеседованиях на позицию инженера меня пытали на предмет опыта программирования.
Были короткие встречи, на которых я говорил «Стоп, вам нужен не я». В противовес этому на одну из позиций был марафон собеседований из пяти двухчасовых собеседований на английском по скайпу. Были замаскированные военные, идти к которым я не хотел принципиально. Была фирма, которая по сути представляла собой кооператив фрилансеров во главе с менеджером.
Главным же итогом большинства моих собеседований было отсутствие предложений о работе там, где я хотел, и наличие предложений там, где мне не хотелось бы работать.
Жизнь во фрилансе
Здесь я с головой окунулся во все плюсы и минусы фриланса, которые многократно обсуждались на Хабре. Для меня огромным плюсом стало время. Я жил в своем таунхаусе на природе и не тратил время на дорогу. Зато я легко отдавал проекту по 12 часов в день, имея возможности учиться и закрывать те пробелы в знаниях, которые у меня были в программировании. Я окунулся в мир STM32 и, в том числе, FreeRTOS. Сначала смакетировал на Дискавери нужный мне проект, потом сделал плату и повторил его на 10х серии. Параллельно разобрался в Git и проектировании на UML в рамках нужных задач. К сожалению, уезжать далеко от дома я не мог, потому что осциллограф, паяльник, блок питания пришлось бы таскать с собой.
Одновременно пробегали проекты, связанные с антеннами и радарами. Но основной доход приносил один заказчик. К слову, этот доход был в полтора раза выше мой зарплаты инженера-разработчика.
Однако сначала заказчик стал задерживать оплату этапов, но я терпел. Когда же совсем перестал платить и исчез с горизонта, то пришлось затянуть пояс и идти искать работу снова.
Да, банальность известная всем — заключайте договор. Я обменял деньги на опыт работы во фрилансе и программировании.
Испытание боем
В эту фирму я попал со второго раза. Первая попытка решить тестовое задание (небольшая задачка для микроконтроллера) не привела к собеседованию. Отзвонился, узнал чем именно не понравилось мое решение (мало комментариев, предложен всего один вариант решения). Вторая попытка спустя полгода была более удачной.
Собеседование с представителем HR, с небольшими тестами. Разговор с будущим коллегой, долгий и обстоятельный. Суммарно более 2 часов. Предложение об оплачиваемой «стажировке» на несколько дней.
За время «стажировки» закрыл пару-тройку багов. Деньги получил на руки вместе с предложением испытательного срока на три месяца.
Можно сказать, что с этого времени началось настоящее погружение, длиной в полгода. Вкратце за это время:
Первые полгода были очень активным временем. Работаешь положенные 8 часов. Потом приезжаешь домой и все оставшееся время пытаешься быстро подтянуть свои знания и навыки, чтобы решить задачи, поставленные днем. На следующий день приходишь на работу и с новыми знаниями пытаешься решить задачу.
Очень сильно помогали коллеги. Где практическими советами, где просто идеями.
Когда работаешь в режиме: есть задача — нужно срочно решать, то обучение движется существенно быстрее. Главное не забывать смотреть чуть шире, и успевать понимать, что именно ты делаешь.
Сейчас я чуть снизил обороты, тем более что зимой я впадаю в состояние, близкое к спячке, но я уже не только работаю программистом, но и ощущаю себя им. Легаси код, спринты, проектирование, тесты, CI/CD в полный рост. И мне это чертовски нравится!
Зарплата по сравнению с инженером-разработчиком выросла более чем в два раза. Никаких переработок и непонятных требований. Это даже больше, чем я ожидал, когда собирался уходить в программисты.
Что дальше.
Не останавливаться. Это не сложно, потому что программирование имеет свойство затягивать в процесс. Начав, очень сложно остановиться.
Учиться. Потому что белых пятен в моих знаниях еще очень много, в том числе теоретических. А уж как не хватает практических.
Очень хочу заниматься своим проектом, тем более что у меня в голове есть парочка идей, а на руках две интересные платки.
Записался на пару курсов. Алгоритмы и базы данных.
Хочу дойти в той же сфере до сеньора, а там посмотрим.
Заключение
Самый главный посыл этого текста – я смог стать из инженера-разработчика программистом встроенных систем за два года. Если бы не терял время в тщетных надеждах и топтании на месте – в полтора года точно бы уложился.
Что было важно и нужно – знание теории. Базовые понятия, железо, Линукс, контроллеры.
Чего явно не хватило – практики. Любой свой проект, с обязательным красивым кодом и комментариями – очень не хватало при поиске работы.
Уверенность в том, что все получится. У меня были вдохновляющие комментарии на Хабре и «крепкий тыл», который в меня верил.