Как стать автором
Обновить

Комментарии 32

НЛО прилетело и опубликовало эту надпись здесь

На кредитные деньги он ее купил и теперь доедает без соли, как и его более низкоранговые коллеги, мы все в одной лодке (сарказм) :)

Очередная "распильня"

У бабки на базаре пруфов больше. Сколько средний оклад, сколько премия? О каких суммах вообще речь? Может там премия больше символическая, на конфеты к чаю, а мы тут это обсуждаем? Что в положении о премировании написано, какие показатели были в плане, какие получились? Новость ни о чем: где-то премий заплатили меньше, чем кому-то хотелось.

Как работник скажу, что все верно в статье написано. Годовая премия - в зависимости от грейда 15-20% от оклада за весь год, можешь посчитать, сколько это для разработчиков с опытом. Совсем не на конфеты. Без премии зп немного ниже рынка, с премией - вполне в рынке.
Показатели по задумке выдаются заранее, делятся на личные, командные и бизнесовые, у рядовых разрабов - 100% личные, у тимлидов личные+командные, бизнесовые - у руководителей среднего звена и выше. При этом решено было порезать на 25% всем, вне зависимости от этих показателей. Наша команда, например, свои личные и командные выполнила на 100% и повлиять на это не могла.

Без премии зп немного ниже рынка, с премией - вполне в рынке.

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

Разработка в конторе давно уже не в фаворе, на годовом обращении Мартыненко к народу, медали и похвалы сыпались тем, многих из кого мы даже фамилии не знаем. А те, кого уволили, оказывается, плохо работали, хотя там были отличные люди (избавились от большинства аутстаферов). А поните его обещания +1 оклад за ТЗР22? Ну и как, все получили +1?! Кто тянул таски до срыва сроков, тот и получил, еще и х2 на переработках за выходные взяли. С показателями по командам тоже вечно какая-то торговля идет. Вся эта полнейшая демотивация началась именно с прихода Мартыненко, зато носятся с этими дуратскими мерчами, назвывая носки с символикой "системой мотивации".

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

Согласен. Ну и со стороны бизнеса действительно бывают случаи когда резерва финансов на повышение ФОТ нет, но не факт что и через год появятся, это тоже надо понимать. Так что "думайте сами, решайте сами". Ну и лучше пусть честно скажут что сейчас хреновый период, и не обещать что "через год точно будут золотые горы", чтобы сотрудник принимал решение без иллюзий.

НЛО прилетело и опубликовало эту надпись здесь

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

В общем раскидываться кадрами - это самодурство с точки зрения бизнеса (здорового).

НЛО прилетело и опубликовало эту надпись здесь

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

НЛО прилетело и опубликовало эту надпись здесь

Да, к сожалению, пытаются искать так же часто.

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

НЛО прилетело и опубликовало эту надпись здесь

Я вас уверяю сейчас при найме уже не просто найти разраба (даже уровня мидл) который знает что такое SOLID и может это адекватно объяснить. Я уже молчу про уровни изоляции транзакций в базах данных

Сколько предлагаете? Может зарплата не соответствует, вот и непросто найти. Чем занимаетесь, если надо знать уровни изоляции транзакций? Вопрос, мягко говоря, специфический.

НЛО прилетело и опубликовало эту надпись здесь

Ну или как вариант не завалить а заодно почесать свое чсв, с гордым видом, что недавно вычитал и запомнил какой- нибудь нюанс а визави его не знает, лошара :)

Ну например в найме Backend PHP, зп согласно присвоенному грейду в среднем 200 на руки. Нужно хотя бы понимать что такое SOLID и зачем он нужен. А нужно это для того, что-бы человек, который пришёл в команду не начал делать задачи так как ему хочется/умеет, а делал так как это принято в команде, чтоб код был поддерживаемым, это единственная цель.
Знание что такое уровни изоляции - делает быстрый срез, насколько человек понимает как работает СУБД, код довольно высоконагруженный нахватать Deadlock-ов ничего не стоит при неумелом обращении.

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

Про дедлоки понятно, вот такие практические вопросы приветствую, одна из самых неприятных задач на моей практике была исключить дедлок на проде (еще под windows тогда, gdb не подключишь по простому) который раз в месяц условно происходил, а работать должна была программа 24/7.

НЛО прилетело и опубликовало эту надпись здесь

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

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

НЛО прилетело и опубликовало эту надпись здесь

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

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

Знание что такое уровни изоляции - делает быстрый срез, насколько человек понимает как работает СУБД, код довольно высоконагруженный нахватать Deadlock-ов ничего не стоит при неумелом обращении.

Все равно непонятно. Вы с дедлоками боретесь уровнями изоляции? Почему не спросить про релевантный опыт или как бы кандидат разбирался с реальным кейсом? Вообще говоря на современной (и даже не очень) СУБД нахватать дедлоков это надо еще постараться. Времена MS SQL Server 7.0 давно прошли. Да и в те времена зачастую просто добавляли во все запросы WITH NO LOCK просто на всякий случай)

НЛО прилетело и опубликовало эту надпись здесь

Вот здесь категорически не соглашусь.

Я не говорю что это правильно, но так делали. А кое-кто делает до сих пор.

Вы должны чётко отдавать себе отчёт что делает каждая команда (или хинт СУБД).

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

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

А если в команде принято нарушать SOLID? Сложилось так исторически, переделывать нецелесообразно, решили пусть будет безобразно, зато единообразно.

Для этого нужны code conventions и единая архитектура. А если уже написано 5 разными способами, то поезд ушел и никакой SOLID не поможет.

оба нуждаются друг в друге

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

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

PS

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

Вот только все рычаги у работодателя.

Да почему же, работодатель (если бизнес не фиктивный и построенный с целью приносить деньги) точно так же нуждается в квалифицированных сотрудниках. Одно дело если сотрудник сам пришёл на стуле посидеть и не приносит ощутимой пользы процессу. Другое дело попробуй просто так заменить да условного DevOps в компании с численностью персонала > 50 человек. Повторю свой тезис выше, это только сказки что "за воротами ещё 100 человек стоит" (если конечно вы не руководите бригадой дворников, тут скорее да).

Как показала более чем 100 летняя практика, страшнее чем государство, для работодателя только профсоюз работников.

Поэтому "разделяй и властвуй". И т.д. и т.п. И да, такие мысли как у вас, именно то, о чём мечтает работодатель.

Срезать этому парню 50% премии!

Обе премии традиционно выплачиваются в мае, с зарплатой за апрель.

Обычно в таких случаях в день выплаты премии в ОК появляется стопка заявлений.

Зарегистрируйтесь на Хабре, чтобы оставить комментарий

Публикации

Истории