Подобную ситуацию часто наблюдаю в знакомых IT компаниях, причем, бывает, что это преподносится как высшее благо для стажера. Мы в определенный момент увеличили стажировку до 3-4 месяцев, при этом программа отделена от боевых проектов для формирования правильного опыта и набора знаний, по окончании стажировки уже работа в качестве джуна — несколько месяцев продолжения стажировки, но уже с реальными задачами и помощью со стороны коллег.
Сказал бы я, что наша стажировка стала идеальной? Думаю, что нет, но это шаг к уходу от конвейерной подготовки кодеров на аутсорс. Могу назвать ряд примеров, где стажировка не является натаскиванием на конкретные задачи. Так что, я бы не переносил слова автора статьи на всю стажировку в целом.
Пример с docker-compose подходит для локальной разработки и всяких CI/CD из говна и палок самописного разлива, он несет с собой ряд ограничений для продакшина:
Заметное снижение производительсности в определенных случаях (например, на MacOS) по причине не очень качественной реализации volumes
Для работоспособности необходимо рядом держать код. Т.е. его надо дополниельно туда положить и обновлять. В ряде случаев доступа к файловой системе вообще нет.
Непонятно, как ставить глобально пакеты, например curl
Поэтому, для разворачивания во всяких k8s и прочих свормах необходим самодостаточный образ без всяких волюмов.
UPD. Пока писал комментарий тут уже ответов понаписали
Без ИИ или сложной предобработки мы смогли получить только карточку объекта с превьюшкой фотографии. Но это позволило загружать любые фотографии для произвольных объектов (надеюсь, что база из будет увеличиваться). В дальнейших планах ручная подготовка фотографий для накладывания их на реальные объекты, но это на будущее. В этой версии уже будут не фотографии, а вырезанные из них объекты, но тут будут проблемы с 3D.
Также при «сборке» системы возник ряд вопросов, связанных в основном с безопасностью. В базовом варианте Elasticsearch ничем не защищен — пришлось приспосабливать для этих целей стороннее ПО.
Ребята, не надо переходить в плоскость общения с заказчиком. В большинстве нормальных компаний для этого есть специально обученные люди. А вот общение с коллегами никто не отменял. Примеры: человек свою работу делает, как одолжение — ты его просишь что-то сделать, а он это преподносит, как будто ты должен будешь ему до конца жизни; не воспринимает критику в свой адрес, вместо принятия жалуется всем на того, кто критикует или спорит; перекладывает ответственность или прикрывает свою пятую точку; строит из себя всезнайку и на вопросы отвечает не как более опытный товарищ, а как бог всея с г**ом. Да много примеров можно привести, но результат, как правило, один: взаимодействия с подобными людьми стараются избегать, а важные задачи не давать.
Мне кажется, что мы с Вами начали говорить разными словами, но об одном и том же.
Я специально в заключении выделил несколько путей дальнейшего развития разработчика: программирование, обучение, руководство. А так же специально акцентировал внимание на то, что если не хочется быть управленцем, то и не стоит это делать даже не смотря на то, что тебя к этому принуждают. Если же нравится заниматься менеджментом, то привел одну из книг, которая помогает двигаться в этом направлении.
Во время подготовки статьи мне скинули ссылку на другую статейку, но я не стал еще и это приплетать. А вообще, удивлен, что никто в комментариях не заклеймил за главное изображение поста с диаграммой. В ней, конечно, есть доля юмора, но и в каждой шутке есть доля шутки ;-).
У нас в заказной разработке по городу ЗП менеджеров колеблется в довольно узком диапазоне. ЗП разработчиков же начинается с очень низкой и начинает очень быстро расти, сеньоры уже легко перегоняют менеджеров по ЗП. Сильный технический специалист практически не имеет потолка по ЗП, главное тут — продолжать учиться и совершенствоваться, ни понимать, что для получения очень больших сумм надо очень много работать (в плане движения) и рассматривать возможность смены города и даже страны. Пройдясь по своему списку друзей в соцсетях, могу найти несколько подобных вариантов.
А на последние деньги купил биткоинов по $18к
Сейчас за 5-10 лет IT технологии меняются настолько, что востребованность на рынке может упасть в сотни раз. Потреряет Коля работу? Если закрепится за продукт, который будет поддерживать ещё лет 10, то нет, но автор об этом и так писал несколько раз.
Современный IT ещё и движется в сторону упрощения технологий в плане доступности. Если лет 12 назад я пробовал реализовывать перцептроны на C++, то сейчас практически любой облачный сервис предоставляет ML подсервисы, а по Интернету гуляют курсы по AI за 21 день. Я не говорю, что любой сможет ML сейчас, но в 90% проектов д.т.н. по AI/ML/Dl становятся не нужны, а в крупных R&D отделах нужны специалисты топового уровня всегда.
Мы в конце сентября-начале октября вели переговоры с техподдержкой на тему подключения различных версий API и нам сообщили, что к новой версии пока не подключают и есть только первая версия, к ней и подключили
Либо я плохо выразился, либо вы не так поняли. Я потексту указывал именно не хочет ИЛИ не может, а тут была контраста предыдущего комментатора.
Я могу представить себе такую ситуацию (и даже знаю примеры), когда хорошо получается управлять, но это отнимает слишком много сил, времени и т.д. + если ты ПМ, а твой заказчик в другом часовом поясе, то приходится подстраиваться под него, а переработки не оплачиваются.
Не являясь ПМом могу сказать, что это самая неблагодарная работа — на него давит и команда и клиент и работодатель. И плох тот менеджер, котррый это давление просто передает дальше поцепочке.
Потому что у него hard-skill жёстко прибит гвоздями к конкретному фреймворку
Предлагаю перечитать статью еще раз и комментарий к ней, а потом уже «нерадоваться»
Автор специально ввел понятие tech-skills для того, чтобы убрать из hard-skills фреймворки, библиотеки и прочее, а оставить именно опыт и фундаментальные знания.
Что касается лида — он может быть разный — Team Lead (ведущий конкретную команду с проектом), Tech Lead (ведущий в плане стратегического выбора технологий),
Так что написано очень хорошо, но одно это заставляет в целом усомниться, в полной ли мере ли автор точно понимает, о чем пишет в статье.
Автор решил не акцентировать на этом внимание в данной статье по той причнине, что если разобраться, то Team/Teach не выбивается из общей концепции, а еще и техлидов не хотелось бы обижать.
Но если появился такой вопрос, то могу на него ответить исходя из опыта и наблюдения как за одними, так и за другими.
TeamLead — технически грамотный специалист, который управляет командой разработчиков. Для работодателя этот вариант является более выгодным по ряду причин
Он ближе к разработчикам и может их адекватно оценивать
Разработчики к нему относятся лучше, чем к проектному менеджеру
Можно убрать из проекта или снизить роль проектного менеджера (а он не приносит прямой доход)
Он может общаться с клиентом с точки зрения бизнесса, а не технологий.
Совещает в себе роли TechLead и PM
TechLead — техническй специалист без управления командой. В ряде случаев он более технически подкован, нежели TeamLead, но для работодателя менее интересен, т.к. не совмещает в себе 2 роли. почему конкретный человек именно TechLead, а не TeamLead:
Он может быть технически очень сильным и отвлекать его не стоит, например, может участвовать в большем количестве проектов
Он интроверт или мизантроп, ему очень сложно общаться с людьми, а им с ним
Он очень сильно любит программировать, а управленческие задачи ему не интересны
PM не хочет делиться с ним обязанностями
В компании нет необходимости в TeamLead и больше требуется технические специалисты
Техлид или архитектор — развитие программиста, который не хочет и не может развиваться в качестве управленца и об этом было упоминание в заключении, однако, при отсутствии очень сложных проектов он все равно менее востребован для работодателя, нежели тимлид, а если посадить рядом тимлида и техлида при равных технических скилах и наличии менеджеров проектов, то работодатель в большинстве случаев выберет именно тимлида из-за универсальности.
У меня 2003-2006 годы — Pascal, Delphi, C++.
с 2006 по 2016 годы основным ЯП был PHP (c 2008 фуллтайм)+jQuery+фреймворки Symfony, Laravel, Bitrix, YII. Но при этом писал плагины для jQuery, на Java, C++ и прочем. Были проекты с использованием Perl, были и корп. порталы и всякий e-commerce. В качестве тимлида продавал проекты, участвовал в разработке ТЗ, управлял командой разработчиков и проводил сдачу проекта заказчику.
В 2015 я и мои товарищи слышали фразу: ваш стек технологий устарел, это слышать было довольно тяжело.
В 2016 году с переходом в студию освоил React + Angular 1.5/2+ + NodeJS — скажу честно, что временами было очень тяжело. Но стал Mean фуллстеком.
Что помогало?
Глубокое знание веба (в свое время занимался разбором пакетов в wireshark)
Опыт работы с БД
Опыт работы и администрирования Linux. (сейчас приходится DevOpsить при необходимости)
Опыт разработки многопоточных приложений, межпроцессного взаимодействия, тестирования безопасности, нагрузочного тестирования, разработки высоконагруженных систем.
Опыт работы с кучей языков программирования (больше половины я не указывал в этом комментарии)
Опыт работы в качестве тимлида (уделять внимание мелочам, развивать младших товарищей, общаться с клиентом, не давать необдуманных обещаний, проактивность и клиентоориентированность)
Привычка работать в режиме постоянного стресса
Привычка разбираться в том, что ты делаешь, а не скакать по вершкам
Возможно, что-то еще.
Могу сказать, что смена стека технологий прошла тяжело, однако, относительно быстро, за 1.5+ года nodeJS знаю больше, чем среднестатистический молодой nodeJS разработчик, который пишет 3 года в резюме (переходы были без понижения ЗП)
На текущий момент именно программированием занимаюсь только при необходимости (когда надо, а людей нет), но основная проблема с кодированием — постоянные задачи, которые надо решать, делегировать, контролировать.
В ряде сфер есть привязка в выслуге лет. В IT я про такое не слышал и программировать можно хоть до победного. Я знаю и знал специалистов, которые были очень сильны именно как технари, но при этом в плане общения были очень тяжелы. Правильный руководитель создаст для такого сотрудника условия, при которых он сможет комфортно для себя и других выполнять свои обязанности (при условии, что такая возможность есть).
Я долго ждал подобного комментария и был удивлен, что он долго не появлялся.
Да, действительно, графики без подписей являются плодом моего IMHO, что, собственно, и было указано в самом начале стати, а также несколько раз по тексту.
Я бы с радостью построил математическую модель и проверил бы ее на основе каких-либо исследований, но дать объективную оценку скилам практически невозможно. Даже сам поиск способа оценки может вылиться в нехилое исследование. Даже технические скилы, например, тесты на апворке не всегда отражают объективной ситуации и могу как минимум быть набиты с N попытки.
Единственное, что радовало меня как технаря, так это то, что они строились в на основе табличных данных и формул, т.е. не совсем от руки. А вот наполнение уже было сделано на уровне симуляции (а не эмуляции) разработчика в собственной голове, но на основании как собственного опыта, так и наблюдения за сотоварищами.
gitlab-ce в Ubuntu репозитоии все ещё старый. У всех так?
Сказал бы я, что наша стажировка стала идеальной? Думаю, что нет, но это шаг к уходу от конвейерной подготовки кодеров на аутсорс. Могу назвать ряд примеров, где стажировка не является натаскиванием на конкретные задачи. Так что, я бы не переносил слова автора статьи на всю стажировку в целом.
из говна и палоксамописного разлива, он несет с собой ряд ограничений для продакшина:Поэтому, для разворачивания во всяких k8s и прочих свормах необходим самодостаточный образ без всяких волюмов.
UPD. Пока писал комментарий тут уже ответов понаписали
Для безопасности в ELK есть штатный пакет X-Pack
Я специально в заключении выделил несколько путей дальнейшего развития разработчика: программирование, обучение, руководство. А так же специально акцентировал внимание на то, что если не хочется быть управленцем, то и не стоит это делать даже не смотря на то, что тебя к этому принуждают. Если же нравится заниматься менеджментом, то привел одну из книг, которая помогает двигаться в этом направлении.
У нас в заказной разработке по городу ЗП менеджеров колеблется в довольно узком диапазоне. ЗП разработчиков же начинается с очень низкой и начинает очень быстро расти, сеньоры уже легко перегоняют менеджеров по ЗП. Сильный технический специалист практически не имеет потолка по ЗП, главное тут — продолжать учиться и совершенствоваться, ни понимать, что для получения очень больших сумм надо очень много работать (в плане движения) и рассматривать возможность смены города и даже страны. Пройдясь по своему списку друзей в соцсетях, могу найти несколько подобных вариантов.
Сейчас за 5-10 лет IT технологии меняются настолько, что востребованность на рынке может упасть в сотни раз. Потреряет Коля работу? Если закрепится за продукт, который будет поддерживать ещё лет 10, то нет, но автор об этом и так писал несколько раз.
Современный IT ещё и движется в сторону упрощения технологий в плане доступности. Если лет 12 назад я пробовал реализовывать перцептроны на C++, то сейчас практически любой облачный сервис предоставляет ML подсервисы, а по Интернету гуляют курсы по AI за 21 день. Я не говорю, что любой сможет ML сейчас, но в 90% проектов д.т.н. по AI/ML/Dl становятся не нужны, а в крупных R&D отделах нужны специалисты топового уровня всегда.
Либо я плохо выразился, либо вы не так поняли. Я потексту указывал именно не хочет ИЛИ не может, а тут была контраста предыдущего комментатора.
Я могу представить себе такую ситуацию (и даже знаю примеры), когда хорошо получается управлять, но это отнимает слишком много сил, времени и т.д. + если ты ПМ, а твой заказчик в другом часовом поясе, то приходится подстраиваться под него, а переработки не оплачиваются.
Не являясь ПМом могу сказать, что это самая неблагодарная работа — на него давит и команда и клиент и работодатель. И плох тот менеджер, котррый это давление просто передает дальше поцепочке.
Нежелание может быть не так выражено, либо они еще не решили, что ему будет лучше, но они же уходят в программисты со словами «не мое это»?
Предлагаю перечитать статью еще раз и комментарий к ней, а потом уже «нерадоваться»
Автор специально ввел понятие tech-skills для того, чтобы убрать из hard-skills фреймворки, библиотеки и прочее, а оставить именно опыт и фундаментальные знания.
Автор решил не акцентировать на этом внимание в данной статье по той причнине, что если разобраться, то Team/Teach не выбивается из общей концепции, а еще и техлидов не хотелось бы обижать.
Но если появился такой вопрос, то могу на него ответить исходя из опыта и наблюдения как за одними, так и за другими.
TeamLead — технически грамотный специалист, который управляет командой разработчиков. Для работодателя этот вариант является более выгодным по ряду причин
TechLead — техническй специалист без управления командой. В ряде случаев он более технически подкован, нежели TeamLead, но для работодателя менее интересен, т.к. не совмещает в себе 2 роли. почему конкретный человек именно TechLead, а не TeamLead:
Техлид или архитектор — развитие программиста, который не хочет и не может развиваться в качестве управленца и об этом было упоминание в заключении, однако, при отсутствии очень сложных проектов он все равно менее востребован для работодателя, нежели тимлид, а если посадить рядом тимлида и техлида при равных технических скилах и наличии менеджеров проектов, то работодатель в большинстве случаев выберет именно тимлида из-за универсальности.
с 2006 по 2016 годы основным ЯП был PHP (c 2008 фуллтайм)+jQuery+фреймворки Symfony, Laravel, Bitrix, YII. Но при этом писал плагины для jQuery, на Java, C++ и прочем. Были проекты с использованием Perl, были и корп. порталы и всякий e-commerce. В качестве тимлида продавал проекты, участвовал в разработке ТЗ, управлял командой разработчиков и проводил сдачу проекта заказчику.
В 2015 я и мои товарищи слышали фразу: ваш стек технологий устарел, это слышать было довольно тяжело.
В 2016 году с переходом в студию освоил React + Angular 1.5/2+ + NodeJS — скажу честно, что временами было очень тяжело. Но стал Mean фуллстеком.
Что помогало?
Возможно, что-то еще.
Могу сказать, что смена стека технологий прошла тяжело, однако, относительно быстро, за 1.5+ года nodeJS знаю больше, чем среднестатистический молодой nodeJS разработчик, который пишет 3 года в резюме (переходы были без понижения ЗП)
На текущий момент именно программированием занимаюсь только при необходимости (когда надо, а людей нет), но основная проблема с кодированием — постоянные задачи, которые надо решать, делегировать, контролировать.
Да, действительно, графики без подписей являются плодом моего IMHO, что, собственно, и было указано в самом начале стати, а также несколько раз по тексту.
Я бы с радостью построил математическую модель и проверил бы ее на основе каких-либо исследований, но дать объективную оценку скилам практически невозможно. Даже сам поиск способа оценки может вылиться в нехилое исследование. Даже технические скилы, например, тесты на апворке не всегда отражают объективной ситуации и могу как минимум быть набиты с N попытки.
Единственное, что радовало меня как технаря, так это то, что они строились в на основе табличных данных и формул, т.е. не совсем от руки. А вот наполнение уже было сделано на уровне симуляции (а не эмуляции) разработчика в собственной голове, но на основании как собственного опыта, так и наблюдения за сотоварищами.
Никогда не считал себя гуманитарием