Некоторое время назад я наконец‑то осуществил свою маленькую мечту — перешел с bare‑metal разработки для микроконтроллеров на работу с Embedded Linux. Причина заключалась в том, что работа с МК, как мне казалось уже продолжительное время, становилась однообразной: берешь очередной чип и документацию, поднимаешь на нём очередной UART / SPI / I2C, пишешь драйвера общения с устройствами и более‑менее несложный основной алгоритм. Хотя временами возникали интересные задачи, когда ты работаешь с незнакомым доселе интерфейсом, пишешь какой‑нибудь протокол или алгоритм верхнего уровня. Но такое случалось редко, а хотелось уже чего‑то более масштабного...
Итого имеем:
5+ лет работы с МК и причем только в нескольких IDE, без знаний CI/CD, контейнеров, утилит тестирования, фреймворков и т.д.;
профильное образование, которое вообще ни к селу, ни к городу, хоть и техническое и изредка помогающее;
устойчивое мнение, что реальные знания приобретаются в работе;
желание наконец-то вынырнуть из болота... в другое.
И вот наконец я оказался в новой компании с новыми задачами и с оговоркой, что без опыта в Embedded Linux, что в самом линуксе я далеко не продвинутый пользователь (ну там в терминале по директориям побегать, что-то удалить/создать, не более), но есть огромное желание развиваться, упорство и нескончаемые запасы вазелина стрессоустойчивость. Тут стоит добавить, что эта оговорка была сказана еще на собеседовании и вполне устроила соискателей. Кошмар начался с малого - с загрузчика.
Волею судьбы первый проект был связан с U-Boot чисто для того, чтобы было не слишком больно. Первые 1,5 месяца я работал только с ним, из которых 1 месяц - это внесение правок в загрузчик одновременно с привыканием к линуксу, командной строке, докеру, тоннам спагетти-кода, экзистенциальному кризису.
До сих пор помню мою первую попытку сборки загрузчика из исходников: проект не собирается, компилятор ругается на синтаксис, начинаешь рыскать в гугле в поиске ответов... Оказывается нужен тулчейн, гуглишь, что это такое и не понимаешь. Пишешь в поиске быстрого совета более опытным коллегам - ответ: "так а какой тулчейн ты используешь для сборки?"... Блин блинский, да кто такой етот ваш тулчейн?
Ладно, с этим разобрался, научился работать с докером (ну как я тогда думал) и задачу выполнил в поставленные сроки. Как выяснилось, это были цветочки...
После меня временно перекинули в другой отдел (на поддержание проекта после ухода сотрудника), в котором собиралась уже полноценная прошивка через Buildroot со всякими подмодулями, патчами и нефритовым стержнем. Да-да, взаимодействие с китайскими вендорами и их творчеством в виде процессоров, кода из костылей и неполной документации. Здесь я уже привыкал именно к работе в билдруте, а затем вернулся обратно в свой отдел работать с этим же процессором, но над другим проектом, к работе с драйверами, модулями, особенностями отладки. И вот это были уже ягодки...
Нет смысла пересказывать все события дней минувших, но, думаю, стоит сказать одну мысль: несмотря на то, что учиться нужно всегда, перед погружением в новую сферу следует всё-таки пару-тройку месяцев эту сферу хоть немного изучить. И не просто почитать, а именно потыкать - почитать литературу или глянуть видео-гайды на ютубе, затем попробовать сделать маленький домашний проект или на худой конец пройти онлайн курсы. Я это говорю для людей, которые начинают изучать новую специальность только после прихода в неё без предварительной подготовки. Таковым являлся я, так как считал, что лучшее обучение происходит в бою - если перед тобой ставится задача да еще и в сжатые сроки, то ты в лепёшку расшибёшься, но задачу сделаешь. Увы, это работает не всегда. Это работало только поначалу, потому что дальше происходят следующие процессы:
начинаешь систематически задерживаться на работе, так как тратишь больше, а иногда много больше времени на задачу, так как больше половины времени уходит на изучение инструментария, методов и т.д.
как следствие, накапливается усталость и свободное время (если таковое имеется) тратится не на то, чтобы с удовольствием изучить что-то новое, а на то, чтобы повтыкать в развлекательный контент
если продолжать с переработками в том же духе, накапливается апатия, мозг будто блокирует процессы обучения, любая новая задача превращается в стресс, что отражается и на личной жизни тоже
процесс обучение новому теряет какой-либо систематизированный вид - информация поступает урывками и только та, которая нужна конкретно для задачи. Целостного знания предмета, как такового нет
В результате возникает очень странная ситуация, когда ты вот казалось бы влетел в ту сферу, которая тебя так манила и звала, но... У тебя нет ощущения, что ты в теме хоть сколько-нибудь разобрался. Любой вопрос по теме ставит в ступор, так как ты попал в замкнутый круг: все силы тратишь на выполнение локальной задачи, и больше нет сил, чтобы сформировать глобальное знание.
Очень простая аналогия со спортом: прежде чем приступить к марафону, начни хотя бы с одного километра каждый день. И начни заранее, сильно заранее, чтобы не страдать на тренировках и не мучить свой неприученный к дистанции организм. Иначе просто будешь бежать от лавочки к лавочке (если они вообще по пути попадутся) и достигнешь цели очень и очень не скоро. Если вообще добежишь.
Подводя итог под выше упомянутым, очень хотелось бы сказать, что все невзгоды пройдены, атлант расправил плечи и гордо терпит все тяготы и лишения Embedded Linux разработки, но... оказалось, что у запаса прочности есть предел и выгорание меня добило. Впервые в моей карьере. Как позже выяснилось, причина была не столько в нехватке опыта, сколько в управленческой особенности "мало разрабов - много проектов". Описание причин по объёму тянет на ещё одну статью, но как говорил Леонид Каневский: "Это уже совсем другая история".
Спустя некоторое время после написания первой версии этой статьи я начал работу в другой компании с бОльшим количеством сотрудников, развитой корпоративной культурой и более спокойным темпом работы. Это всё та же работа с Linux, но уже далеко не Embedded
Если будет интересно, то можно выпустить продолжение в виде оценки управления командой со стороны разработчика
