хорошее замечание но не все инженеры хотят становится менеджерами

вообще в этом есть некоторая родовая травма нашей индустрии. Часто чтобы получить повышение надо прийти к боссу с оффером от конкурента. А раз уж ты пошел по собесам, то уже полдела считай сделано.

Можно получить временное повышение зп, а потом месть... Плохой паттерн, обычно без увольнения зп не повышается.

За что месть?

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

вообще в этом есть некоторая родовая травма нашей индустрии. Часто чтобы получить повышение надо прийти к боссу с оффером от конкурента. А раз уж ты пошел по собесам, то уже полдела считай сделано.

сменил несколько индустрий, такое было везде

сменил несколько индустрий, такое было везде

сменил несколько индустрий, такое было везде

хотя я не знаю, помнишь (знаешь) ли ты меня или нет

Какое отношение Kubernetes имеет к программисту?

Есть команды, где mocroservice per developer и там может входить в задачи написание манифеста для микро под ответственностью разработчика. Чтобы не потерялся. Ну и в целом, не вижу ничего зазорного иметь такой навык разработчику в целом или экспертизу. Уметь доставать данные из конфиг мапы, манифесты править и тому подобное. Видимо у них есть такие задачи, где требуется экспертиза. Поэтому, в частных случаях - прямое.

Есть команды, где mocroservice per developer и там может входить в задачи написание манифеста для микро под ответственностью разработчика. Чтобы не потерялся. Ну и в целом, не вижу ничего зазорного иметь такой навык разработчику в целом или экспертизу. Уметь доставать данные из конфиг мапы, манифесты править и тому подобное. Видимо у них есть такие задачи, где требуется экспертиза. Поэтому, в частных случаях - прямое.

А еще не помешает уметь управлять поездами метро, тролейбусами, автобусами, трамваями и т. д. Ведь программист ездит же на работу на общественном транспорте.

Я в принципе на собесе слышал фразу «зачем мне sql, я хочу писать на go?» Меня ничем уже не удивить

Я вот представляю уже, как человек приходит на собес и начинает пальцы гнуть: «а зачем мне знать куб? А вы умеете троллейбус водить? А у вас программисты офис убирают?» ну и в таком духе. Отличный способ отсеяться по софтскиллам:)

Есть уровень компетенции, который требуется разработчику для того, что бы работать с кубом. Можно понимать его на уровне Джуна девопса и этого будет хватать за глаза. Про троллейбус, хороший пример, конечно, но не в вашу пользу) если на собесе будут душить с какими-то тонкостями куба, то это скорее говорит о том, что в кампании не выстроены процессы и разрабы убирают офис вместо своей работы. Тут скорее интервьюер и компания не подходит и дело не в софт скилах. Не представляю ситуации, когда знание куба на уровне «выше среднего» дает преимущество разработчику при трудоустройстве. Если вам нужен универсальный солдат и вы готовы искать человека, который и Швец и жнец и на дуде игрец, то процесс может затянуться. Гораздо адекватнее (имхо) инвестировать средства и научить хорошего разработчика той компетенции, которая от него будет требоваться, чем мучать соискателей почем зря и требовать бесполезные для него скилы в 99% компаний.

Я в принципе на собесе слышал фразу «зачем мне sql, я хочу писать на go?» Меня ничем уже не удивить

Так, а какой уровень знания куба нужен в обсуждаемой вакансии?

Теоретически человек может использовать всегда ОРМ.

Нет ни одной ормки на go, которая закрывает все бизнес потребности на дистанции

А еще не помешает уметь управлять поездами метро, тролейбусами, автобусами, трамваями и т. д. Ведь программист ездит же на работу на общественном транспорте.

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

Теоретически человек может использовать всегда ОРМ.

Во-первых, процитирую ещё раз себя "в частных случаях - прямое(отношение)". Во-вторых, специалист, который умеет не только пузырёк написать и протобаф править, а ещё изучает системный дизайн и может отличить ноды от подов - это намного лучше, чем без. В-третьих, если говорить о специалисте, который растёт в сторону t-shaped уровня экспертности, то такой специалист не обязан быть сеньор девопсом, но с такой базой знаний принесёт больше вэлью для компании. Ну и в-четвёртых, если ориентироваться на модель описания архитектуры C4(context-containers-components-code), то лучше выходить из уровня code и components, изучить как Х инструмент, который улучшает работу сервисов, узнать, что он для этого делает. Тогда как и в третьем пункте, человек принесёт больше пользы для команды

А я еще раз процитирую любимого Хайнлайна Каждый человек должен уметь менять пеленки, планировать вторжения, резать свиней, конструировать здания, управлять кораблями, писать сонеты, вести бухгалтерию, возводить стены, вправлять кости, облегчать смерть, исполнять приказы, отдавать приказы, сотрудничать, действовать самостоятельно, решать уравнения, анализировать новые проблемы, вносить удобрения, программировать компьютеры, вкусно готовить, хорошо сражаться, достойно умирать. Специализация - удел насекомых.

Не знать sql даже джуну должно быть стыдно.

Обожаю этого писателя

Не совсем согласен. Основная база паттернов изучается ещё джуном, а остальные отдельные случаи не занимают много времени и подготовки. Имхо

Тяжелое наследие 2000х и 2010х. Концепция поменялась, теперь бывают проекты вообще без реляционных баз (хотя конечно признаю что большинству прикручивают языки запросов похожие на sql). Некоторые данные удобнее и быстрее хранить без схемы, колонками, и т.п.

А я еще раз процитирую любимого Хайнлайна Каждый человек должен уметь менять пеленки, планировать вторжения, резать свиней, конструировать здания, управлять кораблями, писать сонеты, вести бухгалтерию, возводить стены, вправлять кости, облегчать смерть, исполнять приказы, отдавать приказы, сотрудничать, действовать самостоятельно, решать уравнения, анализировать новые проблемы, вносить удобрения, программировать компьютеры, вкусно готовить, хорошо сражаться, достойно умирать. Специализация - удел насекомых.

И будет такой специалист нужен 5% работадателей.

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

Речь не о количестве времени, а о том что оно не бесконечно. А значит придется выбирать, а не знать все.

О том и речь, что в большинстве компаний sql нужен.

Часть задач решается ORM.

Давайте посмотрим правде в глаза, если бы каждый их нас потратил время, которое он тратит на общение тут, на изучение кубернетеса, мы все бы знали оный просто отлично

Это уровень джун-

Речь не о количестве времени, а о том что оно не бесконечно. А значит придется выбирать, а не знать все.

Опытному специалисту хватит 2-3 часа, чтоб понять как куб работает.

А кто-то готов платить разработчику за эти знания, или так чтоб было?

Разработчику платят не за знания, а за решаемые задачи. Если человек может покрыть больший спектр задач, если ему на каждый чих не нужен смежник, обычно он получает больше

Абстрактно. Возможно он умеет писать простой понятный код, умеет ООП и т.п.

Если разраб во время инцидента начинает верещать, что читать из кубера лог - это не его профиль, то ему конечно никто потом платить не будет

Это врятли. В нестандартных ситуациях требуется знания Linux, сетей, и т.п.

Он его видит в кибане, ему не надо лог тащить с кубера.

Кибана сдохла в том же инциденте, привет

Тогда проблемой займутся opsы.

Давайте посмотрим правде в глаза, если бы каждый их нас потратил время, которое он тратит на общение тут, на изучение кубернетеса, мы все бы знали оный просто отлично

Или нет

Тогда проблемой займутся opsы.

Короче человек, который не может решить проблему и перекидывает ее на других, закономерно будет получать меньше, чем человек, который просто закрывает весь свой участок

"как знать меньше остальных и получать зарплату сеньора" хотел бы я увидеть такую книгу)

Гениально. Привезли холодильник, разраб который откажется его затащить в офис без лифта будет получать меньше. :) Как в анекдоте про армию: "те кто музыканты тащите рояль на 5 этаж". :)

Вы используете софистический прием «доведение до абсурда». Конечно прочитать логи из пода или отрестартить под - это не починка холодильника

Так учить разработчику администрирование это и есть абсурд, так как каждое направление очень наукоемко, и сильно разнится.

Так учить разработчику администрирование это и есть абсурд, так как каждое направление очень наукоемко, и сильно разнится.

Нет же границы между раработкой и администрированием. Ее не возможно прочертить.

Так учить разработчику администрирование это и есть абсурд, так как каждое направление очень наукоемко, и сильно разнится.

Наукоемко:) 10 лет нужно, чтобы выучить полторы сраных команды в кубере:) Кандидатскую защитить, чтобы под отрестартить

Есть. Администрирование это знание всего что окружает код разработчика.

Наукоемко:) 10 лет нужно, чтобы выучить полторы сраных команды в кубере:) Кандидатскую защитить, чтобы под отрестартить

Где она есть. Права доступа к каталогу - это программирование или администрирование? Понимание что такое SSH, и умение настроит законектиться по SSH это тоже администрирование или программирование?

Это администрирование.

Поднять свой репозиторий в Git - это тоже и администрирование и программирование. Нет как таковой границы она очень размыта.