LINUX.ORG.RU
ФорумTalks

Зарплаты devops

 ,


0

2

На какие зарплаты стоит рассчитывать junior\middle devops в Мск? В вакансиях можно написать что угодно, интересно услышать мнение знающих\сталкивающихся. Вопрос вызван мыслями о том, стоит ли менять шило на мыло или у соседа трава зеленее.

Перенесите в tlks, пазязя.

Перемещено alpha из general

Ответ на: комментарий от filosofia

Ещё не забывай, что «средняя зарплата сеньора» != «зарплата сеньора с головой и руками».

В контексте этого треда вопрос как раз про людей с руками. И я думаю что проблема не в средних значениях а в верхних границах.

Разработчик или devops может вырасти гораздо выше этой средней температуры по больнице. А вот для толкового QA в среднем потолок ниже.

alpha ★★★★★
()
Последнее исправление: alpha (всего исправлений: 1)
Ответ на: комментарий от TDrive

Увы, вы остались не поняты. По крайней мере мной. Впрочем, я это переживу, да и вы вряд ли топиться пойдёте.

ugoday ★★★★★
()
Ответ на: комментарий от alpha

Если в конторе сейчас нет 30-летних, то где она найдет следующих шестидесятилетних с опытом длиною в жизнь, когда теперешние кончатся?

Очевидно, 30-летние постареют и донаберут опыта.

mv ★★★★★
()

На какие зарплаты стоит рассчитывать junior\middle devops в Мск?

Не знаю, как у вас в Мск, но у нас в/на Украине даже вот так бывает.

Gonzo ★★★★★
()
Ответ на: комментарий от Devastator

Нет, не просели. Покупательная способность ржубля действительно просела, но зарплаты выросли.

WitcherGeralt ★★
()
Ответ на: комментарий от alpha

Мне хотелось уточнить как у mv получился стартап из шестидесятилетних людей с «опытом длиною в жизнь», и одновременно без «попробовал здесь, попробовал там».

То ли стартап не стартап, то ли опыт у этих людей всё-таки достаточно разнообразный, и они пробуют себя в новых вещах, а не застревают в одной.

Вот поэтому-то в тебя раз в месяц и кидают комменты людей, нюхавших порох. Ну вообще никакого понимания специфики области! Оторванность от реальности просто возмутительная!

Пробовать в плане основной работы ортогонально новые вещи - это хипстерское, для неглубоких. Нормальный специалист быстро находит свой конёк и затачивает его всю жизнь, доводя до абсолюта. Чтобы потом взяли в интересный стартап за много денег. Ибо в стартапе полтора года никто не будет ждать решения проблемы. Нужно вчера ещё починить и ехать к клиенту демо делать. А для этого надо тот самый опыт, в ходе которого на все грабли в этой отрасли наступаешь и находишь решение. И, такой, оп! «У меня такая редкая фигня 10 лет назад была, ударить в бубен, да прочисть чакры надобно!».

Если тот 60-летний уйдёт в другую область, то вместо миллионов сразу, на момент IPO, у него будет 80 тыщ в месяц, как у джуниора-старпёра, с риском вылететь в первую очередь. Это помимо того, что микросхему делать и тесты на кубернетес натягивать, даже в одной конторе - это как инженер в отделе проектирования реактивного двигателя на новом топливе и, максимум, чертёжник. Исключения бывают, конечно. Например: получил миллионы/выплатил дом/выучил детей/скучно на кресле-качалке сидеть - пойду в девопсы, в корпоративное болотце. Чисто, на кухне с коллегами, чтоб, болтать.

Мой опыт начался и, так сказать, предназначение определилось где-то в 9 лет, когда начал предметно в районной библиотеке читать книжки по электронике и прочим ЭВМ. В 11 спаял 8-битный компьютер и выучил ассемблер. Работало всё медленно - экран между прерывания перерисоваться не успевал, памяти мало, поэтому оттачивал искусство оптимизации быстродействия и размера на околожелезячном уровне. Последующие 30 лет этим и занимался. Ну, минус полтора года на старте карьеры, потраченные на пхп и sql, т.к. работы нифига не было, и ещё два года в шапке, в офисе, куда Вестфорд неинтересную работу сбрасывал. Остальной опыт - весь в смежных областях, затягиваемый движением по основному курсу. Т.е. низкоуровневое программирование и оптимизация быстродействия.

mv ★★★★★
()
Последнее исправление: mv (всего исправлений: 1)
Ответ на: комментарий от mv

Вот поэтому-то в тебя раз в месяц и кидают комменты людей, нюхавших порох. Ну вообще никакого понимания специфики области! Оторванность от реальности просто возмутительная!

Ужасно, не то слово :)

Как я могла пропустить такую основополагающую и прямо таки определяющую вещь как реальность стартапа 60-летних схемотехников. Новейшие тренды индустрии прошли мимо меня. Но я обязательно исправлюсь. Вот уже начала.

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

Только я не говорила об ортогонально новых вещах. Я говорила о том что этот самый конёк может проявляться по-разному и в разных формах.

Собственно у нас тут проблема в определениях. Я думаю что область - это когда конкретная предметная область, например биоинженерия, или automotive, или даже бухгалтерия. А Dev, или QE, или технический писатель - это не область сама по себе, это класс задач в этой области.

Поэтому прыгнуть из системного программирования в разработку веб-приложений на электроне - это сложно. А вот прыгнуть из написания кода в области системного программирования в разработку тестов того что написали системные программисты - это полезно в том числе для «затачивания» этого своего конька. Чтобы он заточился качественно и со всех сторон. Точно также может быть полезно и интересно вместо писания кода провести некоторое время в обсуждениях нужности этого кода с заказчиком (то есть примерить роли менеджера продукта или аналитика).

alpha ★★★★★
()
Ответ на: комментарий от alpha

Поэтому прыгнуть из системного программирования в разработку веб-приложений на электроне - это сложно. А вот прыгнуть из написания кода в области системного программирования в разработку тестов того что написали системные программисты - это полезно в том числе для «затачивания» этого своего конька.

Бесполезно. Тебе достопочтенный дон выше по треду уже указывал на то, что мозг у разработчика и тестировщика работает по-разному. У первого - как программа должна работать, у второго - как она не должна работать. Заставлять первого писать сплошное покрытие тестами собственного или чужого кода, да ещё в рамках какого-нибудь долбанутого фреймворка - это делать ему больно.

То же самое и наоборот. Профессиональный, успешный тестировщик не хочет днями ваять код и думать про детали архитектуры. Ему это скучно, неинтересно. Интересно вскрыть хитрый баг, наваять ещё более хитрый репродьюсер и встроить его в тестсьют.

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

Опять же, про меня, красивого: на прошлую работу взялся по-ошибке, мне там было плохо (величали кернель разработчиком, а, по-сути, был девопс), и я ушёл. Ничего нового там не узнал. Как знал, что девопс - болото, тестовые фреймворки реальные баги не ловят, только сами глючат и процесс тормозят, а весь бизнес держится на опыте, аккуратности и интуиции разработчика, так именно всё так и оказалось.

На той же работе программист решил стать менеджером. В первый же год из команды ушло три топ-инженера =) Не смог понять, что им не хватает, не пробил бюджет, не защитил проекты и интересы, людям стало скучно, они ушли. Человек обиделся и переквалифицировался в архитекторы. Не выдержал и ушёл четвёрый. Ибо заставлять узкого и редкого специалиста делать неинтересную работу - это неправильно. Резюме у того человека красивое получается, но, по-сути, развалил команду в рекордные сроки. Потому что неспециалист сунулся хоть и в смежную область, но абсолютно не понимая её специфики.

Чтобы он заточился качественно и со всех сторон. Точно также может быть полезно и интересно вместо писания кода провести некоторое время в обсуждениях нужности этого кода с заказчиком (то есть примерить роли менеджера продукта или аналитика).

С ума сошла! Кто пустит обычного разработчика к разговору с заказчиком? Он же что-нибудь ляпнет! Обсуждай нужность и аналитику на форумах своих домашних проектов, а к коммерческому продукту никто не пустит. Прежде чем бывшего технического работника допустят до тела клиента, его замучают миллионом тренингов и прочими «приходи, но сиди и молчи, пока старший товарищ показывает, как надо общаться с клиентом».

mv ★★★★★
()

В свое время пытался понять, что означает данный термин, но пришел к ничему. На мой взгляд - это совершенное пустое понятие, созданным искусственным образом, для зарабатывания денег и смешение различных смыслов превращения их в бессмыслецу.

nager
()
Ответ на: комментарий от alpha

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

блаблабла. опять об определениях и 0.0 о своем опыте. и никто не понимает, что все твои умные слова на самом деле - это хорошо вызубренные методички.

crypt ★★★★★
()
Последнее исправление: crypt (всего исправлений: 1)
Ответ на: комментарий от mv

На той же работе программист решил стать менеджером. В первый же год из команды ушло три топ-инженера =) Не смог понять, что им не хватает, не пробил бюджет, не защитил проекты и интересы, людям стало скучно, они ушли. Человек обиделся и переквалифицировался в архитекторы. Не выдержал и ушёл четвёрый. Ибо заставлять узкого и редкого специалиста делать неинтересную работу - это неправильно. Резюме у того человека красивое получается, но, по-сути, развалил команду в рекордные сроки. Потому что неспециалист сунулся хоть и в смежную область, но абсолютно не понимая её специфики.

«Каждый специалист стремится достигнуть своего уровня некомпетентности»

vaddd ★☆
()
Ответ на: комментарий от ugoday

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

И Кону Коливасу тоже?

vrutkovs ★★
()
Ответ на: комментарий от mv

Кто пустит обычного разработчика к разговору с заказчиком? Он же что-нибудь ляпнет!

«врёшь, натовская морда, не может солдат сожрать два мешка брюквы!»

Проклятый редхат кстати придумал Voice Of Customer, где заказчики и инженеры собираются в баре, жрут пиво, а на завтра в офисе обсуждают детали использования продуктов без игры в испорченный телефон

vrutkovs ★★
()
Ответ на: комментарий от vrutkovs

Коллега @crypt взял глубоко верный тон. Вместо того чтобы распинаться и пересказывать агитки своими словами, лучше бы рассказали о своём личном опыте общения с заказчиками (если вы инженер, конечно).

ugoday ★★★★★
()
Ответ на: комментарий от alpha

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

Hertz ★★★★★
()
Ответ на: комментарий от ugoday

Не понимаю чего ты от меня хочешь - стенограммы посиделок? Из опыта вижу что полезно устраивать горизонтальные связи с инженерами заказчика. Тогда и проблемы решать быстрее и можно проверить какую-нибудь безумную теорию.

Интересно, что alpha прямо пишет - современное программирование это не игра с нулевой суммой, если немного написал кубовый ямл то не потерял в программировании на Rust. Наоборот, лучше АПИ станешь писать. Собственно, зачем фокусироваться на какой-то детальной проблеме постоянно, если можно передать коллеге у корого сейчас период «хочется писать тесты» - и vice versa. Косвенно, отсюда такое внимание к Outreachy, GSOC и прочему найму студентов из смежных областей.

Но эти все идеи как об стену горох - народ стойко тянется к знакомым терминам вида «просто добавили QA» и «нет междисциплинарности, просто другое имя отдела обслуживания».

vrutkovs ★★
()
Ответ на: комментарий от vrutkovs

Из опыта вижу что полезно устраивать горизонтальные связи с инженерами заказчика

Ну так и поделились бы личным опытом как вы установили горизонтальную связь и какую пользу это принесло в дальнейшем.

Интересно, что alpha прямо пишет …

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

ugoday ★★★★★
()
Ответ на: комментарий от vrutkovs

полезно устраивать горизонтальные связи с инженерами заказчика

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

crypt ★★★★★
()
Последнее исправление: crypt (всего исправлений: 1)
Ответ на: комментарий от vrutkovs

если можно передать коллеге у корого сейчас период «хочется писать тесты» - и vice versa

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

crypt ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.