Похоже у нас эта оценка вообще нафиг не нужна. Какие бы ты балы не получил: 1. Тебя скорее всего не уволят 2. Повышение ЗП при смене работы все равно будет больше чем при пересмотрах
Самый треш был когда оценивали по количеству написанного кода, и количеству коммитов. Не то чтобы иэ этого платили ЗП, нет, просто если ничего не закомитил за целый день, то плохо поработал, если в комите мало изменений тоже не очень хорошо. Достаточно быстро с ними перестал работать
Я думаю это все манагеры с опытом более полугода знают и большинство программистов. И все это расчитано на джунов, миддлов и синьйоров, которые в свои года сохранили детскую наивность, таких тоже полно.
Спасибо за видео, тема действительно очень актуальная! Мне кажется, что если менеджер каждую неделю будет заводить разговор с разработчиком о его производительности, то это будет скорее отвлекающим фактором, а то и вовсе станет стрессом для обоих, не говоря уже о неэффективности использования рабочего времени. Как по мне, заводить подобные разговоры нужно в том случае, когда на то есть причина - явное проседание, либо спад производительности. А если разработчик в целом справляется со своими задачами, то достаточно одной / пары фраз от менеджера +/- раз в две недели, типа "хорошая работа", "ты отлично справился", чтобы работник чувствовал что его труд ценят. Со временем, если разработчик и менеджер работают вместе продолжительное время и имеют высокий уровень доверия друг к другу, необходимость в подобных фразах может и вовсе отпасть, т.к. разработчику не нужны будут слова чтобы понимать что его ценят и уважают. Я также считаю что performance review, в адекватной его форме, это все же полезная практика, потому как она позволяет работнику получить развернутый фидбек от своего менеджера и старших коллег о результатах своей работы за прошедшие пол года / год. Под "адекватной формой" имеется ввиду четкий и содержательный отзыв, подчеркивающий сильные стороны разработчика и его успехи / достижения за прошедший период, а также пункты о том, над чем стоит работать и что нужно развивать и подтягивать. При этом менеджеру не стоит выдумывать и искать недостатки если их нет, лучше ничего не писать, чем превращать объективную оценку в фарс. Хороший отзыв вдвойне приятен когда он честный и объективный! И еще пару мыслей о критериях по которым, как мне кажется, можно примерно оценить работу и в целом уровень программиста. Чтобы иметь возможноть дать объективную оценку, менеджеру / тим лиду достаточно понаблюдать за следующими показателями: - Как разработчик подходит к изучению задачи и определению способа ее реализации. - Готовность обосновать свое решение, может ли разработчик объяснить почему решать проблему / имплементировать задачу нужно именно так, а не иначе. - Как происходит разбиение задачи на под-задачи и как затем происходит их оценка. Насколько точно разработчик вписывается в свой естимейт по итогу. - Про-активность в процессе планирования, имплементации и тестирования задачи. - Какими инструментами пользуется программист и как организует свою рабочую среду и процесс. - Как подходит к решению проблем, встречающихся в процессе имплементации технического решения. - Дает ли разработчик обратную связь. - Как происходит взаимодействие с другими членами команды.
У меня в компании перфоманс ревью раз в пол года, проходит так: Пишешь на себя самооценку, там перечисляешь чего крутого сделал за предыдущие пол года, собираешь фидбэк с коллег и далее менеджер тебя и твою самооценку защищает на так называемых «калибровках». Примерно месяц идут калибровки и после этого оценка, премия, повышение зп и тд. Мне тут нравится что чисто менеджеры в этом не очень много принимают учестие. Пока было 2 ревью, скоро третье. Первые два были очень объективными, на мой взгляд и это реально мотивирует. Фидбэк после ревью мне лично оказывался очень полезным. Из неоднозначных моментов то, что тебя сравнивают с другими коллегами твоего грейда, и можно быть норм но на фоне вундеркиндов трудоголиков смотреться бледно. К тому же, не уверен, но кажется что сильно зависит от способностей твоего Лида тебя защищать
Хоть видео и не об этом, но можно перформить и брать только сложные задачи, а в следующем квартале, при малейшем изменении на performance review, никто и не вспомнит что ты п*%здячил как *индийский слон.* Поэтому работать так: в первую очередь *в комфортном для себя режиме* upd: Как уже было написано в комментах - импакт в продукт оценивают только в стартапах (в основном)
Работать нужно только на себя, так как сразу прекрасно начинаешь оценивать и свои знания и результаты своей работы, и то, сколько ты на самом деле стоишь.
Если и на себя, то открывать бизнес, не связанный с айти. Как я писал ранее, твои знания все равно обнулятся из нового стека технологий (следовательно, карьера тоже), а старого человека уже с легкостью заменят более молодым, готовым работать 24/7.
@@paulrepaul6373 Ууу, ну верить в оценку окружающими - это вообще гиблое дело. В лучшем случае - лотерея, а обычно будут боссознательно или сознательно топить.
Не ожидала такое услышать. Всегда думала, что оценивают по результату. А для результата, маленького или большого, есть четкие критерии оценки. Переучилась с Fortran на JS и REACT, но читаю вакансии и потому, как они написаны, понимаю, что в этой компании делать нечего. Ну возможно, учить разбираться в сортах кофе и быстро колотить по клавиатуре.
Это во всей айти сфере, к сожалению. Проблема в том, что твой стек технологий будет обнуляться из-за нового стека технологий, которым придется учиться, чтобы быть в тренде. То есть базиса не будет - не будет профессионального роста из-за постоянно обновляющихся технологий. Таков путь разработки, Сорты кофе и технологии в айти - это очень разные вещи (вообще не советуют проводить аналоги с другими профессиями, поскольку мозг таким образом закрепощается и отказывается от трудностей).
В РФ очень сильна культура красного менеджмента, когда боссы не доверяют линейным менеджерам, исполнителям, и не смогли придумать никаких других средств контроля. На одной из работ у меня было 5 систем оценки/отчетности, долго конфликтовали по этому поводу, в итоге менеджер сказал что можно подделывать отчётность
Проблема коммуникаций. Недоверие всех ко всем. Раньше такой концентрации недоверий не было и чушь про русский менталитет помню нормальные времена. Как и откуда это появилось загадка для меня, почему этого не доверие стало так популярно сейчас. Мы русские доверяем другдругу! Нет?
Как же я вас понимаю. Уже начал ненавидеть работу из за этой менеджерской "бесполезности", которая призвана лишь задолбать сотрудника, а не предоставить реальные объективные данные.
Однажды Макс Крайнов писал статью о корпоративных паразитах. Там много всего было, но главная суть следующая: как только появляется "линейка для измерения", люди моментально сразу под нее подстраиваются. Помнится, у нас менялась "линейка" и было видно как поведение людей меняется. Количество багов должно быть меньше? Надо добежать до тестирования и попросить удалить баг, поклявшись его закрыть. Как можно больше количество issues? Надо попросить аналитиков заводить на тебя мелкие задачи. Количество строк кода? Вот тебе много переводов строк. Количество коммитов? Вот тебе целый ворох мелких коммитов. И так далее. Была бы линейка, а люди выстроятся чтобы по ней выглядеть лучше.
Я думаю причина ода, остальное - не желание признавать эту причину и поиски оправданий. И это отсутствие доверия. Руководство платит деньги, программисты что то делают, руководство даже не представляет что они делают. Они не понимают платят ли они деньги и кодеры их пробухивают или они недоплачивают, а сотрудники пашут безвылазно. Отсюда и выдуманные критерии оценивания: коммиты, часы на рабочем месте. Люди просто не знают как ещё можно оценить работу и понять нужно ли людям платить. Руководство нужнее контроль. Они должны видеть цифры, которые они понимают. Им плевать на сколько цифры честны (хотя они будут отрицать), им главное что бы они были. Обычные палки. И нет, комментаторы не правы, это не особенности российского рынка, это особенности людей. В it компаниях у руководства есть адекватный тех дир, который отвечает за то что программисты не проедают деньги просто так. И этому тех диру руководство доверяет.
Всё верно. Руководству всё равно кто как работает, за всё отвечает техлид, тех дир, тимлид или другой доверенный технически грамотный человек. Главное результат чтобы давали. Если нет результата, то пды получает техлид, а техлид дает пды своим подчинённым и так далее.
12:30 Про участие в собраниях. Сначала мне говорили спасибо за мои замечания и предложения. Потом молчали. Потом... По прежнему молчали, но чувствовалось, что внутренне меня шлют нахер... =)
При текущих реалиях рынка адекватным решением может быть создавать условия, где каждый разработчик может комфортно для себя расти, получать индивидуальную обратную связь, реализовывать свой потенциал. Тогда и желания уйти будет меньше, и другие хорошие разработчики захотят попасть в такую компанию. А контроль, метрики, рамки только отталкивают людей: компания требует, ничего не предлагая взамен.
Был у меня случай, когда несколько опрошенных человек из scrum комманды критически отозвались о работе коллеги за последний год. Тот, когда услышал об этом на ПР, никак в это не верил, частично не вспоминал проколы и сваливал вину на других. Закончилось ничем - мнение против мнения. Играться в суд времени особо нет. Мораль: опасно оценивать сотрудников лишь по субъективным оценкам коллег, особенно если это происходит раз или два в год. Наверное нужно комбинировать методы и намного чаще запрашивать feedback
Веленью божию, о муза, будь послушна, Обиды не страшась, не требуя венца, Хвалу и клевету приемли равнодушно, И не оспоривай глупца. Когда менеджер будет оценивать, надо бы вспомнить эти слова.
Позволю себе предположить, что оценки эффективности могут делать по настоянию специально приглашённых специалистов, которые ничего именно в вашей области не понимают, но за большую сумму денег прошли, окинули взглядом вам оффис и сделали предложение, как можно повысить прибыль. или просто главный инвестор приехал раз в год и сказал урезать расходы на Х%, и повысить прибыль на У%. Конкретные методы его не волнуют. Важна бумажка со списком того, что сделали. А если "не получилось", то инвестору не важно. Ибо у него таких фирм много. Часть уйдёт в минус, но другие окупят всё. Для инвестора результат +. А конкретные люди - не важны.
с точки зрения владельца бизнеса, если мы говорим о большом продукте, то важно понимать скорость девелопмента. т.е. оценить все задачи (в часах или в попугаях) и понять сколько этих попугаев делается в итерацию и логичным выводом потом будет посмотреть сколько попугаев делает конкретный человек. безусловно это не может быть оценкой человека , но это может быть одной из оценок
"Вы как менеджер должны моч посмотреть в код...." все менеджеры в моей компании : "Менеджер не должен заниматься микроменеджментом и разбираться в коде". Интересно было бы посмотреть видео по оценке производительности вот таких вот менеджеров которые ни за что не отвечают а только "делегируют".
Человека заметили когда ему было 6 лет. Ходил с мамой на работу, в 10 лет стал системным админом. После 11 управляющая компания взяла на себя все расходы для дальнейшего продвижения. Пока как бы себя не позиционеровали, приоритет тому, у кого папа на каком уровне.
Как ни перекручивай тему, всё равно она про деньги. Разработчику важно помнить, что всё, что ему не доплатили в зарплату, бизнес заработал. Перформанс можно оценить как достаточный, если от услуг разработчика не готовы отказаться. Перформанс можно оценить как избыточный, если разработчик при прочих равных условиях может получать больше в другой конторе.
Вообще, по мне, оценка продуктовой команды и аутсорсинговой - разные ситуации. По аутсорсингу, кому интересно, посмотрите методы Ильи Отькало - по мне, вполне работают.
Видео говорит о том , что менеджменту заняться нечем . Надо сокращать их количество , мешают людям работать и ищут себе занятие. Кстати , именно это сейчас и происходит с введением 1 скрама на пяток команд , а в команде неформальный лидер (как правило аналитик тк таски ему падают в первую очередь и ему решать к его команде это пушнуть или в футбол).
Самая главная метрика для оценки производительности, это количество итераций при выполнении задачи. Делает с первого раза - красавчик! Делает с 3-5-10го - раздолбай. ( P.S. Половина времени работы над таской уходит на УТОЧНЕНИЕ требований по таске. А код написать - самое простое..
Есть проекты на которых локально невозможно протестировать решение, приходится коммитить, деплоить в тестовую среду и там тестировать интеграционными тестами. И так в несколько итераций.
Перформанс ревью позволяет хоть как то предметно отвечать на вопросы типа "Почему Вася уже сеньер, а я еще нет". Это всетаки какой то этап, когда суммируется работа и человек знает что у него есть условные полгода на демонстрацию буста. С 1on1 такое не провернуть.
@@SeniorSoftwareVlogger зависит от процесса, у нас после performance review например есть т.н. «калибровка», когда тимлиды питчат оценки своих сотрудников другим тимлидам и там как раз идет синхронизация, что сеньоры в разных командах у нас действительно на одном уровне.
как раз сейчас готовлюсь к асесменту. у нас вообще сделали матрицы и уровни разработчиков J1 J2 J3 M1 M2 S1 S2 и на каждый уровень есть матрица на 134 строки вопросов которые на разный уровень надо знать всё глубже :D P.S. можешь скинуть ссылку на крепление, на подставку, на которой стоит ноут? Не сам кранштейн (рука) , а именно плоскость. А то сколько ни искал, все какие-то громоздкие.
а не выходит ли так, что для того что бы тебе подняли зп надо не работать, а уметь отвечать на вопросы? 134 вопроса, уверен, там и про работу есть, но все же. Мне действительно интересно. Я такого не видел...
В общем резюме видео - как только появляется перформанс ревью, значит компания обзавелась жирком и есть возможность сжечь лишние человеко-часы( читай обеспечить занятость HR, линейных менеджеров и сотрудников) за счёт прибыли владельца))
В видео упомянуто парное программирование, я про него слышал, но в реальности не встречал. Оно реально существует и как часто его применяют )? Спасибо за видео !
Так вышло, что работаем с девушкой в одной компании удаленно. Довольно часто зависаем вместе над одним ноутом. И в итоге приходят решения, которые в одиночку вряд ли бы пришли. Бонусом багов меньше, чем когда работаем по отдельности. Производительность хуже, качество выполненной работы выше. Менеджеры довольны. Чем не парное программирование?)
@@mixa9269 Работал в компании, где практиковали парное программирование. В целом впечатления такие же, единственное отметил бы, что этой штукой лучше дозированно пользоваться, ибо быстрее устаешь как-то. Хотя мб это субъективное.
На текущем месте работы, раз в год происходит беседа с начальником о твоей полезности и планах компании на тебя на следующий год, как результат документ в котором все за фиксировано. Но оценка сроков и возможность корректировки раз в год все портят. По факту вообще отсутствие премирования за качественный код. Желание, что-нибудь отрефакторить приходится обосновывать. Во главе удовлетворенность клиента и сроки. Но это особенности немецкой региональной компании.
Вывод из видео - если делать плохо, будет плохо. Перечислены просто детские ошибки перформанс ревью, которые вполне можно научиться избегать. При этом польза от перфревью рассказана с явной предвзятостью, на мой взгляд. Об этом свидетельствует хотя бы хронометраж - сколько внимания уделено пользе, сколько вреду.
Вся эта лабуда с оценками это защита компании от резкого изменения рынка зарплат, чтобы затягивать с повышением заплат, я бы даже сказал не с повышением, а выравниванием их до рыночного уровня. Короче чтобы создать у разработчика комплекс неполноценности. Если это было бы не так, то тогда новый человек заходил бы с зарплатой не выше среднего по компании, а потом бы оценивался для повышения. А так новые всегда заваливают по рынку и чаще с зп выше чем у тех, кто уже пару лет проработал и был бит оценочными палками в своем желании увеличить зп. Советую вам поподробнее узнать об этих оценках на собеседовании, и если их будет дофига, то будьте готовы что эта компания не собирается вам повышать особо.
@@SeniorSoftwareVlogger то есть английский тоже А2? Просто я учусь на программиста и везде говорят о необходимости владения B2-C1, а оказывается можно и без этого обойтись. Спасибо огромное!
Мне кажется оценивать программиста не программист просто не может, да и не каждый программист может обьективно оценить собрата… Поэтому и понапридумывали такую вот максимально примитивную аналитику…, сколько задач выполнил 🤷♂️, лол мой коллега к примеру фигачит забагованный и с низкой производительностью г*** код, но зато делает задач в два раза больше… Компания столкнется в будущем с такими проблемами что мало не покажется…
Пересмотрел и обратил внимание на один момент, который от меня ускользнул год назад. Мы в моей текущей команде недавно внедрили сбор данных через Sup-бота в Slack вместо формального daily standup'а (который остался, но в неформальной форме и не в каждый рабочий день). Так вот, этот бот, помимо данных о том что ты делал/что планируешь делать/какие есть проблемы, спрашивает про твоё настроение в данный момент. Этот анонимный дата пойнт, он, якобы, никому не показывается, только в усреднённом виде - как "настроение в команде" на этот день. И вот что я подумал в контексте performance review. Кажется, имеет смысл также спрашивать анкетируемого о его настроении в момент заполнения анкеты с обратной связью на коллегу, а также учитывать потом это настроение при выборке и сопоставлении данных из нескольких анкет. Возможно, есть корреляция с сигналом/шумом. Проверить это на практике, конечно же, весьма затруднительно. Но дата пойнт "настроения" кажется очень важным.
Не думаю что кому-то понравится так работать. Сделал вовремя, то сухо скажут ок. А вот если что-то пошло не так сразу начинают искать кого бы репресировать. В 30ых годах в ссср было подобное и от этого отказались. А сейчас менеджеры в ит компаниях промышляют такой штукой. Судя по военным фильмам у немцев это вообще было популярно и видимо они до сих пор от этого не отказались. На мой взгляд это не к чему хорошему не приводит. Возможно это специфика галлер. Но если в компаниях такое практикуется, то лучше поискать другую работу. Когда каждый день над твоей головой висит дамоклов меч, то под стрессом начинаешь лепить ужас из кода, а если что-то можно быстро скопипастить то ты сразу так и поступишь. В итоге уровень проектов очень сильно скатывается. Ещё думаю эта вся тема идет из ошибки выжевшего. Есть например биография Стива Джобса и например там был такой факт что Стив Джобс устраивал разносы разработчикам и увольнял кого угодно за мелкие косяки, в итоге выросла компания apple и Стив стал миллиардером и построил крутую компанию. И возможно менеджеры такие "а ну я новый Стив Джобс" и думают, что так нужно делать.
Я оцениваю производительность в нашей компании так: умножаю скилл программиста на его мотивацию. В двух крайностях ( нет скилла, но огромная мотивация; огромный скилл, но нет мотивации) производительность будет 0 ( 0 * 100 и 100 * 0). Остальное можете сами интерполировать, но значения считаю равнозначными и с одинаковой метрикой ( от 0 до 100) Понятно что человек будет не линейно "производить труд", от всякого рода внешних и внутренних причин, но в среднем весь результат всегда будет пропорционален мотивация * скилл. Если проводить аллегорию, то мотивация - бензин, а скилл - мощность двигателя, а на пути машины будут горки, ямы, и иногда ровная дорога.
Бро , Совершенно Согласен - Заставляют Делать Оценку Производительности ( то что реально никто не любит - но как-то нужна Держать " Team " в Тонусе ) - Вообще КАК МОЖНО ОЦЕНИВАТЬ ЧЕЛОВЕКА - И ПОТРАЧЕНЫЕ НЕРВЫ : (
Мне не хватило в первой части видео пояснения, что именно ты называл тут performance review. Как будто ты противопоставляешь performance review некоторым «другим хорошим практикам, как надо на самом деле оценивать людей», но в моем понимании все эти практики вполне могут работать в рамках формального процесса. То же общение с коллегами сотрудника - мне кажется довольно распространенный аспект performance review много где. А если просто по теме, то мне кажется, что наличие формального процесса с грейдами, оценками, матрицами компетенций и пр. это скорее всего лучше, чем когда его нет. Понятно, что можно все то же самое делать без процессов на уровне отдельного менеджера и его общении с командой, но это подразумевает более высокую квалификацию всех менеджеров в компании. Формальные процессы позволяют даже не самым талантливым менеджерам соответствовать какому-то "baseline" в плане вовлеченности в развитие сотрудника и его карьерный рост. Это как например Scrum - наверное не идеальный способ управлять проектом, можно придумать лучше, но если заставить каждого менеджера переизобретать с нуля подход к ведению команды, то много не очень крутых менеджеров в итоге получат результат хуже. А так есть какой-то фреймворк, которому можно следовать и получать good enough результат. Вот кажется, что формальный performance review это как раз такой фреймворк для менеджеров.
"... но это подразумевает более высокую квалификацию всех менеджеров в компании" И даже это, скорее всего, никак вам не поможет. Ведь управлять профессиональным развитием узкого специалиста в принципе способен только сам узкий специалист (с помощью или без помощи коллег-специалистов, внутри компании или в процессе обмена опытом с коллегами из индустрии). Потому что познания в таких сложных областях знания и практик, как IT и Software Engineering, у неспециалиста (менеджера) даже самой высокой квалификации будут всегда на уровне buzz word'ов и аналитических трендов рынка от условного Gartner, не привязанных ни к глубокому пониманию специфики проекта, ни хотя бы к личному опыту и чутью. Даже если он(а) сам(а) в прошлом когда-то был(а) квалифицированным узким специалистом средней руки, то на деле это может только усилить проявления нежелательных когнитивных искажений. Поэтому любое вовлечение в "развитие сотрудника" это дилетантизм, а если с оценками и какими-то формальными последствиями, то ещё и неприкрытая манипуляция. Управлять можно тем, что можно измерить, и как следует измерить, а не абы как. Работу Канемана на этот счёт Дмитрий в видео упоминал. В данном случае шума настолько много, что смысла в управлении нет.
Если сотрудника попросить дать структурированную обратную связь в письменной форме (причём, отметив как плюсы, так и минусы в одной анкете), по идее, это должно подснизить уровень шума. Потому что меньше места для срабатывания когнитивной лёгкости и приходится включать 2-ую систему (по Канеману). Как ты считаешь, поможет? У тебя был опыт сравнения устного/письменного и не-/структурированного фидбека? Спасибо!
А на чём работать?Не могу купить компьютер, от всего болят глаз, сижу за древним ноутом на ламповой подсветке.По компьютерным клубам хожу - везде компы плохие, глаза болят через 2 часа уже...Это начало конца эпохи компьютерной техники? Зачем оно надо, если пользоваться невозможно...
Ламповая подсветка по моим наблюдениям для работы удобнее. На работе древний монитор с ccfl подсветкой и за ним спокойно можно просидеть целый день. А дома за более современным монитором с led подсветкой через час уже начинают глаза болеть. Скорее всего изза ШИМ регулировки яркоски. Хз. Ищи монторы с flicker free функцией или с частотой ШИМ повыше. Может вобще посмотри в сторону OLED экранов хотя там цены заоблачные.
Привет, мне не очень зашла парадигма реактивных фреймворков Ангуляр, Реакт, Вью. Свелт понравился очень сильны, но с ним плохо работают либы для ванильного джс. В итоге так и делаю статичные сайты mongoose + webpack + express.js + pug + vanilla js + mongodb. Есть ли спрос на таких программистов? Ещё мне понравилась идея 2-х фреймворков hotwire turbo + stimulus.js , это концепция SSE , их идея в том, что сайты становятся как облачный игровой сервис с минимум JS в браузере, т.е. сервер реактивно присылает участки html . Мне прям идея вкатила. Я думаю это круче чем реактивные фреймворки, которые я назвал в начале.
Твой подход - это, по факту, SSR. А SSE нужны для обновления информации на странице, не делая ненужные запросы с клиента на сервер, отдавать html прям такое. SSR годится для статики, типа лендингов и обвязок в виде футера, хедера и подобного, где контент не меняется в целом. Но манипулировать с DOM прям больно, это реактивщиной, от части, и пытались исправить, а SPA и вовсе плачут. Как говорится, для каждой задачи свой инструмент. Про спрос - просто зайди на сайты с вакансиями, посмотри требования и узнай хватит ли тебе твоих знаний для желаемой позиции.
@@artemhrytsenko1353 hotwire turbo использует именно SSE подход, они через вебсокеты и потоки (стримы) res.sendStream отправляют сгенерированные участки html , а stimulus.js регулярно следит за обновлениями содержания, чтобы на участки кода навешать слушателей-контроллеры. В общем hotwire крутая тема. Они ещё скоро выпустят strada чтобы можно было мобильные приложения делать с их идеей.
@@artemhrytsenko1353 в общем рекомендую ознакомиться с этим фреймворком) он , наоборот , разгружает браузер пользователя от JS, так как бизнес-логика переносится на сервер, а заодно у разработчика выстроен грамотный порядок, т.е. можно масштабировать приложения не боясь беспорядка. По сути этот hotwire и есть реактивный фреймворк. А так Реакт все берут, так как из-за его поддержки Цукенбергом на него сделано много библиотек (готовых решений), что ускоряет разработку) Но как по мне Ангуляр, Реакт, Вью - это джаваскриптовые гранаты, закинутые в браузеры пользователя, а много джаваскрипта у юзера это не всегда хорошо)) Будущее за облачными технологиями всё-таки
@@indigosay твой подход это SSR. Он был и есть давно. Ты так говоришь будто бы только и сразу все начали пилить на этих ваших реактах, ангулярах и прочих. Всё было иначе. Почитай историю и назначение реактивщины, как это устроено и почему это хорошо, или хотя бы просто почитай сравнение SSR и реактивщины, прежде чем писать мнение, которое само по себе обусловлено небольшим опытом разработки. Все хотят сделать автономию (небезосновательно) от сервера, форсят SPA и PWA (что лично считаю хреновой затеей, но если костыли а ля react native живут, то и PWA вполне себе будут), а тут человек хочет все 10 лет прогресса насмарку пустить :) Использовать связку SSR + реактивщина - ок, чистый SSR для лендингов - тоже ок. Использовать абсолютно везде SSR - стреляешь себе в ногу и попадешь прямо в 2009. P.S. Сноска про Цукерберга вообще бредова. P.P.S. Порядок можно и в реакте навести, главное руки из правильного места иметь. P.P.P.S. «бизнес-логика переносится на сервер» - а до этого она где была? Иль ты умудрился прямо с клиента к базе стучаться?))
жесть, не думал что все так плохо: 1. контролировать необходимо потому как могут работать на 2х работах одновременно. Потому как могут заливать на котиков. 2. методы оценки? Да хотя бы "покер" из аджайла - набросали задач, оценили, расписал по исполнителям, сделал план-факт... Иначе бида - все на 99% буду шаройо...
1. Если человек работает на двух работах и при этом закрывает все задачи норм, то в чем проблема? 2. Как покер из аджайла тут поможет? Заложил побольше да и все, любой не-джун тебе в легкую пояснит за оценку
Подскажите, 2К монитор 144гц подключил через HDMI к MacBook Pro 16" и максимум 50гц можно выставить. Тут дело в HDMI и надо через Display Port или я чего-то не понимаю?
Да никогда процессы никакие не станут нормальными. Под нормальными я подразумеваю отсутствие негатива. Капитализм - это априори работодатель хочет от работника по максимуму выжать. А работник раб. Смириться нужно с тем, что все эти решения/процессы/большие теории о том, как якобы оптимизировать какие-то процессы. Принцип один - от тебя всегда будут хотеть больше вплоть до бесконечности. Кстати, зп программистов "неоправданно высокие" очень обоснованы. Мало кого так пинают во время работы как айтишников. Все эти ежедневные скрамы, митинги. Смотрел, как работает чел из автомастерской - пригнал ему что-то. И ждешь, пока не сделает. И хрен ты его как-то поторопишь. А попытаешься надавить ему на психику - вообще останешься без ремонта. Это только айтишников так приручили. Скрамы все эти по сути высасывают жизненную энергию очень дико. И неизвестно, что еще в старости у нас у всех выскочит из-за такого постоянного нервного напряга. Мы - первое поколение, которое это психологическое давление на себе такое постоянно испытывает. Но, кстати, какие-то результаты уже есть. Импотентов полно.
Капитализм - это работодатель хочет от работника по максимуму выжать. А работник хочет побольше выжать из работодателя. Все в равновесии, капитализм - благо. зп программистов "неоправданно высокие" обоснованы тем, что порог входа в эту сферу очень высокий, как и в любую другую сферу сложного интеллектуального труда. Только программистов при этом еще и нужно бесчетное кол-во, чтобы удовлетворить современный спрос. Поэтому и зарпалты, одни из самых высоких по рынку, вполне обоснованы. Справедливости ради, нервный напряг здесь, как и в любой сфере, может быть, а может не быть. Программист, на котором завязана куча процессов серьезного проекта, и которого невыгодно выгонять, может так же посылать кого-угодно куда угодно. И вряд ли на него сможет кто-то надавить. Но для этого надо чтобы в тебе нуждались больше, чем ты в нуждаешься в ком-то. Кто больше зависит, тот и уступает
Не нужно усложнять. Назначай частоту, с которой подчинённые могут просить прибавки. Например, раз в году. Соответственно раз в году любой желающий может сам решить какими метриками он может похвастать и подойти к тебе со словами "Дядь, я тут прокачался и за последний год не только решил такие-то задачи, но ещё и двух китайцев натаскал. Дай денег". А может и не подойти. Вот тогда надо задуматься, а чего это время уже подошло, а он денег не просит, Уж не потому ли, что месяц назад дали ему простую задачу на неделю, а он до сих результата не принёс
Не согласен с автором. Я начинал в компании с позиции интерн 250$. У нас в компании основной критерий это коммерческие часы и уровень английского + сбор фитбеков от членов команды по тому как ты вообще работаешь в команде, как комуницируешь, даёшь экспертизу. В целом перфоменц ревью дает возможности понять в каких точка нужно улучшить навык и систематический рост зп. В целом это занимает 1-2 ч в пол года
Есть одна очень простая метрика о которой почему-то не сказали. Это насколько человек укладывается в сроки по оценке задачи. Пример у нас на работе. вся команда оценила задачу в 3 стори поинта (что у нас соответсвует примерно 3м дням). Дали одному разрабу, он уже делает её 2 спринта, т.е. 20 дней, и это при том, что в процессе нашелся способ еще и сильно упростить требования по задаче. Там реально нечего делать, и чем он занимается - я не знаю.. И это у него не первый случай. На дейликах постоянно какие-то отмазки. Поэтому я считаю что перфоманс ревью нужны хотя бы для того, чтобы увольнять таких лентяев.
а зачем ждали 17 дней? передаёте следующему из "вся команда", кто тоже как 3 дня оценил и засекаете, тоже будет долго делать или нет. Если второй тоже задержится, то скорее всего задача херово поставлена. Даже требования к ней пришлось упрощать. Только тупой программист не лентяй
@@i17talk8 Я бы так и сделал, но менеджмент на стороне заказчика, пусть они и решают. А насчет требований, не совсем правильно выразился, требования те же, просто нашли одну фичу используемой технологии, которая сильно упрощает реализацию.
@@GoodGuyFinishFirst Т.е. про лентяев возражений нет? :) А то я тоже неточно выразился. Имел в виду, что мне, например, лень переделывать код, поэтому выбираю писать качественно сразу, насколько хватает мозгов. А если по факту медленно работает - лень ждать исполнения - ускоряю, раз мозгов не хватило. Лень в этом случае может быть не той, о которой говорите вы.
@@i17talk8 Ну в моем понимании как.. Есть задача, есть её оценка. Просто сажусь и честно делаю, если получится быстрее оценки, то ничего, значит сделаю быстрее и возьму следующее. Если не успеваю - ну значит не уложился в сроки, бывает. Понятно, что в оценку тоже изначально стараюсь заложить преемлемый уровень качества. Мне интереснее именно так работать, чтобы была динамика, сделал одно - начинай другое. А есть люди, которые даже если сделали быстрее, начинают затягивать, и возможно заниматься какими-то своими делами, в то время, когда надо работать. В случае же этого чувака, он писал 400 строчек кода (включая тесты) 21 день, не самого сложного кода... Как на меня так это или лень, или он работает где-то еще параллельно, или просто глупость.
@@GoodGuyFinishFirst может так, а может, разбирался, где что и как написать. Я иногда тоже могу дофига думать, а потом написать немного. Зато перепроверил все связи, что ничего нигде не нарушил. ХЗ, как у вашего индивида. Вариантов немного, можно спросить. Если загнобили, правду не узнаете.
![Зачем программистам нужны менеджеры? [личный опыт]](http://i.ytimg.com/vi/65zn96QkYLk/mqdefault.jpg)
![Зачем программистам нужны менеджеры? [личный опыт]](/img/tr.png)
Похоже у нас эта оценка вообще нафиг не нужна. Какие бы ты балы не получил:
1. Тебя скорее всего не уволят
2. Повышение ЗП при смене работы все равно будет больше чем при пересмотрах
@bitmap у нас в среднестатистической компании
Самый треш был когда оценивали по количеству написанного кода, и количеству коммитов. Не то чтобы иэ этого платили ЗП, нет, просто если ничего не закомитил за целый день, то плохо поработал, если в комите мало изменений тоже не очень хорошо. Достаточно быстро с ними перестал работать
Ужас, как с писателями раньше, когда платили за количество страниц.
Бугаенко что ли?
@@ll-ib5jr Егор платит за закрытые задачи, а не количество строк в них. не все таски - это написать код
@@ione88 задачи ведь тоже разными бывают
@@bmarvinb потому что самый хороший код - это ненаписанный код. Поскольку у него нет расхода на поддержку
Спасибо за видео! Очень интересно услышать мнение не только со стороны менеджера, но и со стороны разработчика.
Всё как всегда по существу и со ссылками (почти на всю) литературу. Твои бы выводы да проджектам в мозги! Спасибо, Дмитрий)
Я думаю это все манагеры с опытом более полугода знают и большинство программистов. И все это расчитано на джунов, миддлов и синьйоров, которые в свои года сохранили детскую наивность, таких тоже полно.
чё то ты от нимба не много съехал, верстка полетела
Просто другая перспектива)
Хотя возможно лучше подойдёт термин ракурс...
@SAM, у Вас тоже, что-то не то: частица "не" отделилась от слова "много"
🤗
Видео о как создать правильно документацию для проекта plz
Никак. Самодокоментируемый код.
Спасибо за видео, тема действительно очень актуальная! Мне кажется, что если менеджер каждую неделю будет заводить разговор с разработчиком о его производительности, то это будет скорее отвлекающим фактором, а то и вовсе станет стрессом для обоих, не говоря уже о неэффективности использования рабочего времени. Как по мне,
заводить подобные разговоры нужно в том случае, когда на то есть причина - явное проседание, либо спад производительности. А если разработчик в целом справляется со своими задачами, то достаточно одной / пары фраз от менеджера +/- раз в две недели, типа "хорошая работа", "ты отлично справился", чтобы работник чувствовал что его труд ценят. Со временем, если разработчик и менеджер работают вместе продолжительное время и имеют высокий уровень доверия друг к другу, необходимость в подобных фразах может и вовсе отпасть, т.к. разработчику не нужны будут слова чтобы понимать что его ценят и уважают.
Я также считаю что performance review, в адекватной его форме, это все же полезная практика, потому как она позволяет работнику получить развернутый фидбек от своего менеджера и старших коллег о результатах своей работы за прошедшие пол года / год. Под "адекватной формой" имеется ввиду
четкий и содержательный отзыв, подчеркивающий сильные стороны разработчика и его успехи / достижения за прошедший период, а также пункты о том, над чем стоит работать и что нужно развивать и подтягивать. При этом менеджеру не стоит выдумывать и искать недостатки если их нет, лучше ничего не писать, чем превращать объективную оценку в фарс. Хороший отзыв вдвойне приятен когда он честный и объективный!
И еще пару мыслей о критериях по которым, как мне кажется, можно примерно оценить работу и в целом уровень программиста. Чтобы иметь возможноть дать объективную оценку, менеджеру / тим лиду достаточно понаблюдать за следующими показателями:
- Как разработчик подходит к изучению задачи и определению способа ее реализации.
- Готовность обосновать свое решение, может ли разработчик объяснить почему решать проблему / имплементировать задачу нужно именно так, а не иначе.
- Как происходит разбиение задачи на под-задачи и как затем происходит их оценка. Насколько точно разработчик вписывается в свой естимейт по итогу.
- Про-активность в процессе планирования, имплементации и тестирования задачи.
- Какими инструментами пользуется программист и как организует свою рабочую среду и процесс.
- Как подходит к решению проблем, встречающихся в процессе имплементации технического решения.
- Дает ли разработчик обратную связь.
- Как происходит взаимодействие с другими членами команды.
Valuable thoughts; I like such video format. Thank you for sharing your experience👍
У меня в компании перфоманс ревью раз в пол года, проходит так:
Пишешь на себя самооценку, там перечисляешь чего крутого сделал за предыдущие пол года, собираешь фидбэк с коллег и далее менеджер тебя и твою самооценку защищает на так называемых «калибровках». Примерно месяц идут калибровки и после этого оценка, премия, повышение зп и тд.
Мне тут нравится что чисто менеджеры в этом не очень много принимают учестие. Пока было 2 ревью, скоро третье. Первые два были очень объективными, на мой взгляд и это реально мотивирует. Фидбэк после ревью мне лично оказывался очень полезным.
Из неоднозначных моментов то, что тебя сравнивают с другими коллегами твоего грейда, и можно быть норм но на фоне вундеркиндов трудоголиков смотреться бледно.
К тому же, не уверен, но кажется что сильно зависит от способностей твоего Лида тебя защищать
Интересный подход!
Очень грамотный ролик, спасибо! Подписываюсь под каждым словом.
Хоть видео и не об этом, но можно перформить и брать только сложные задачи, а в следующем квартале, при малейшем изменении на performance review, никто и не вспомнит что ты п*%здячил как *индийский слон.*
Поэтому работать так: в первую очередь *в комфортном для себя режиме*
upd: Как уже было написано в комментах - импакт в продукт оценивают только в стартапах (в основном)
Работать нужно только на себя, так как сразу прекрасно начинаешь оценивать и свои знания и результаты своей работы, и то, сколько ты на самом деле стоишь.
Если и на себя, то открывать бизнес, не связанный с айти. Как я писал ранее, твои знания все равно обнулятся из нового стека технологий (следовательно, карьера тоже), а старого человека уже с легкостью заменят более молодым, готовым работать 24/7.
Не согласен, очень легко себя недооценить. Многие к этому очень склонны. Особенно начинающие.
@@petrvictorovich также легко себя переоценить, а вот отзывы от коллег подскажут насколько ты "приятен" в работе.
@@paulrepaul6373 Ууу, ну верить в оценку окружающими - это вообще гиблое дело. В лучшем случае - лотерея, а обычно будут боссознательно или сознательно топить.
Не ожидала такое услышать. Всегда думала, что оценивают по результату. А для результата, маленького или большого, есть четкие критерии оценки.
Переучилась с Fortran на JS и REACT, но читаю вакансии и потому, как они написаны, понимаю, что в этой компании делать нечего. Ну возможно, учить разбираться в сортах кофе и быстро колотить по клавиатуре.
Это во всей айти сфере, к сожалению. Проблема в том, что твой стек технологий будет обнуляться из-за нового стека технологий, которым придется учиться, чтобы быть в тренде. То есть базиса не будет - не будет профессионального роста из-за постоянно обновляющихся технологий. Таков путь разработки,
Сорты кофе и технологии в айти - это очень разные вещи (вообще не советуют проводить аналоги с другими профессиями, поскольку мозг таким образом закрепощается и отказывается от трудностей).
В РФ очень сильна культура красного менеджмента, когда боссы не доверяют линейным менеджерам, исполнителям, и не смогли придумать никаких других средств контроля. На одной из работ у меня было 5 систем оценки/отчетности, долго конфликтовали по этому поводу, в итоге менеджер сказал что можно подделывать отчётность
"менеджер сказал что можно подделывать отчётность" - в РФ (да и в целом на постсовке) зачастую всё и делается "для отчетности"
Проблема коммуникаций. Недоверие всех ко всем.
Раньше такой концентрации недоверий не было и чушь про русский менталитет помню нормальные времена. Как и откуда это появилось загадка для меня, почему этого не доверие стало так популярно сейчас. Мы русские доверяем другдругу! Нет?
Как же я вас понимаю. Уже начал ненавидеть работу из за этой менеджерской "бесполезности", которая призвана лишь задолбать сотрудника, а не предоставить реальные объективные данные.
@@Cre0w доверие это социальный капитал, и его зарабатывают, долго и с большим трудом, а вот растерять его легко.
Однажды Макс Крайнов писал статью о корпоративных паразитах. Там много всего было, но главная суть следующая: как только появляется "линейка для измерения", люди моментально сразу под нее подстраиваются.
Помнится, у нас менялась "линейка" и было видно как поведение людей меняется. Количество багов должно быть меньше? Надо добежать до тестирования и попросить удалить баг, поклявшись его закрыть. Как можно больше количество issues? Надо попросить аналитиков заводить на тебя мелкие задачи. Количество строк кода? Вот тебе много переводов строк. Количество коммитов? Вот тебе целый ворох мелких коммитов. И так далее. Была бы линейка, а люди выстроятся чтобы по ней выглядеть лучше.
Да, люди накручивают любую цифру, как только эту цифру начинают наблюдать
"Для любой метрики М, есть такая стратегия S, при которой метрика М постоянно растет, а при этом проект летит в жопу" не помню автора
Я очень благодарен автору за то что он открыл глаза на сколько по конченому в реальной работе оценивают умных людей кретины…
Очень интересно, спасибо!
Спасибо за контент!
Интересно было послушать. Лайк
Девопс - это философия.
Потрясающе 💥💥💥💥🖤🖤🖤
"Не задавай вопросов, если не хочешь слышать лжи" © Револьвер
=)
Я думаю причина ода, остальное - не желание признавать эту причину и поиски оправданий. И это отсутствие доверия. Руководство платит деньги, программисты что то делают, руководство даже не представляет что они делают. Они не понимают платят ли они деньги и кодеры их пробухивают или они недоплачивают, а сотрудники пашут безвылазно. Отсюда и выдуманные критерии оценивания: коммиты, часы на рабочем месте. Люди просто не знают как ещё можно оценить работу и понять нужно ли людям платить.
Руководство нужнее контроль. Они должны видеть цифры, которые они понимают. Им плевать на сколько цифры честны (хотя они будут отрицать), им главное что бы они были. Обычные палки.
И нет, комментаторы не правы, это не особенности российского рынка, это особенности людей. В it компаниях у руководства есть адекватный тех дир, который отвечает за то что программисты не проедают деньги просто так. И этому тех диру руководство доверяет.
Всё верно. Руководству всё равно кто как работает, за всё отвечает техлид, тех дир, тимлид или другой доверенный технически грамотный человек. Главное результат чтобы давали. Если нет результата, то пды получает техлид, а техлид дает пды своим подчинённым и так далее.
12:30 Про участие в собраниях.
Сначала мне говорили спасибо за мои замечания и предложения.
Потом молчали.
Потом... По прежнему молчали, но чувствовалось, что внутренне меня шлют нахер...
=)
очень интересные темы, клево
При текущих реалиях рынка адекватным решением может быть создавать условия, где каждый разработчик может комфортно для себя расти, получать индивидуальную обратную связь, реализовывать свой потенциал. Тогда и желания уйти будет меньше, и другие хорошие разработчики захотят попасть в такую компанию.
А контроль, метрики, рамки только отталкивают людей: компания требует, ничего не предлагая взамен.
Компания предлагает взамен деньги 💰
Досмотрел до конца
Был у меня случай, когда несколько опрошенных человек из scrum комманды критически отозвались о работе коллеги за последний год. Тот, когда услышал об этом на ПР, никак в это не верил, частично не вспоминал проколы и сваливал вину на других. Закончилось ничем - мнение против мнения. Играться в суд времени особо нет. Мораль: опасно оценивать сотрудников лишь по субъективным оценкам коллег, особенно если это происходит раз или два в год. Наверное нужно комбинировать методы и намного чаще запрашивать feedback
Веленью божию, о муза, будь послушна,
Обиды не страшась, не требуя венца,
Хвалу и клевету приемли равнодушно,
И не оспоривай глупца.
Когда менеджер будет оценивать, надо бы вспомнить эти слова.
Позволю себе предположить, что оценки эффективности могут делать по настоянию специально приглашённых специалистов, которые ничего именно в вашей области не понимают, но за большую сумму денег прошли, окинули взглядом вам оффис и сделали предложение, как можно повысить прибыль. или просто главный инвестор приехал раз в год и сказал урезать расходы на Х%, и повысить прибыль на У%. Конкретные методы его не волнуют. Важна бумажка со списком того, что сделали. А если "не получилось", то инвестору не важно. Ибо у него таких фирм много. Часть уйдёт в минус, но другие окупят всё. Для инвестора результат +. А конкретные люди - не важны.
Бекграунд в видео просто огонь
с точки зрения владельца бизнеса, если мы говорим о большом продукте, то важно понимать скорость девелопмента.
т.е. оценить все задачи (в часах или в попугаях) и понять сколько этих попугаев делается в итерацию
и логичным выводом потом будет посмотреть сколько попугаев делает конкретный человек.
безусловно это не может быть оценкой человека , но это может быть одной из оценок
Отличное видео!
"Вы как менеджер должны моч посмотреть в код...." все менеджеры в моей компании : "Менеджер не должен заниматься микроменеджментом и разбираться в коде". Интересно было бы посмотреть видео по оценке производительности вот таких вот менеджеров которые ни за что не отвечают а только "делегируют".
У меня как раз performance review на следующей неделе. Интересно было послушать.
Человека заметили когда ему было 6 лет. Ходил с мамой на работу, в 10 лет стал системным админом. После 11 управляющая компания взяла на себя все расходы для дальнейшего продвижения. Пока как бы себя не позиционеровали, приоритет тому, у кого папа на каком уровне.
Привет, хотел спросить, какая у тебя модель монитора? Тебя устраивает? Стал бы менять?
ЛыЖы вроде тусклый монитор на мой взгляд, я бы их не брал никогда
Гугли "Senior Software Vlogger техника". Там есть модель монитора.
А можно пруфы на исследования влияния Perf Review? А то гугл выдает обратную информацию - ревью работает
Как ни перекручивай тему, всё равно она про деньги.
Разработчику важно помнить, что всё, что ему не доплатили в зарплату, бизнес заработал.
Перформанс можно оценить как достаточный, если от услуг разработчика не готовы отказаться.
Перформанс можно оценить как избыточный, если разработчик при прочих равных условиях может получать больше в другой конторе.
Красноярск, столько смотрю тебя и только сейчас узнал что земляк ))
Клавиатура Такмак не вызвала подозрений? :)
@@SeniorSoftwareVlogger Думал случайное совпадение))
Вообще, по мне, оценка продуктовой команды и аутсорсинговой - разные ситуации. По аутсорсингу, кому интересно, посмотрите методы Ильи Отькало - по мне, вполне работают.
Видео говорит о том , что менеджменту заняться нечем . Надо сокращать их количество , мешают людям работать и ищут себе занятие. Кстати , именно это сейчас и происходит с введением 1 скрама на пяток команд , а в команде неформальный лидер (как правило аналитик тк таски ему падают в первую очередь и ему решать к его команде это пушнуть или в футбол).
Спасибо за видио
Самая главная метрика для оценки производительности, это количество итераций при выполнении задачи.
Делает с первого раза - красавчик!
Делает с 3-5-10го - раздолбай. (
P.S. Половина времени работы над таской уходит на УТОЧНЕНИЕ требований по таске. А код написать - самое простое..
Иногда бывает быстрее и лучше делать в несколько итераций. Зачастую сразу непонятно, как лучше, а итерации могут выступать в роли рабочих прототипов.
Есть проекты на которых локально невозможно протестировать решение, приходится коммитить, деплоить в тестовую среду и там тестировать интеграционными тестами. И так в несколько итераций.
Перформанс ревью позволяет хоть как то предметно отвечать на вопросы типа "Почему Вася уже сеньер, а я еще нет". Это всетаки какой то этап, когда суммируется работа и человек знает что у него есть условные полгода на демонстрацию буста. С 1on1 такое не провернуть.
Это больше планирование карьеры. В оценке никто не скажет, как дела у Васи и какую оценку получил он.
@@SeniorSoftwareVlogger зависит от процесса, у нас после performance review например есть т.н. «калибровка», когда тимлиды питчат оценки своих сотрудников другим тимлидам и там как раз идет синхронизация, что сеньоры в разных командах у нас действительно на одном уровне.
Перфоманс ревью не отвечает на вопрос, что качать, чтобы стать синьором как Вася, так что это такой себе ответ
как раз сейчас готовлюсь к асесменту. у нас вообще сделали матрицы и уровни разработчиков J1 J2 J3 M1 M2 S1 S2 и на каждый уровень есть матрица на 134 строки вопросов которые на разный уровень надо знать всё глубже :D
P.S. можешь скинуть ссылку на крепление, на подставку, на которой стоит ноут? Не сам кранштейн (рука) , а именно плоскость. А то сколько ни искал, все какие-то громоздкие.
Гугли "Senior Software Vlogger техника". Там вроде есть эта подставка.
kit.co/seniorsoftwarevlogger
а не выходит ли так, что для того что бы тебе подняли зп надо не работать, а уметь отвечать на вопросы? 134 вопроса, уверен, там и про работу есть, но все же. Мне действительно интересно. Я такого не видел...
В общем резюме видео - как только появляется перформанс ревью, значит компания обзавелась жирком и есть возможность сжечь лишние человеко-часы( читай обеспечить занятость HR, линейных менеджеров и сотрудников) за счёт прибыли владельца))
В видео упомянуто парное программирование, я про него слышал, но в реальности не встречал. Оно реально существует и как часто его применяют )?
Спасибо за видео !
Существует, применяют
Так вышло, что работаем с девушкой в одной компании удаленно. Довольно часто зависаем вместе над одним ноутом. И в итоге приходят решения, которые в одиночку вряд ли бы пришли. Бонусом багов меньше, чем когда работаем по отдельности. Производительность хуже, качество выполненной работы выше. Менеджеры довольны. Чем не парное программирование?)
@@mixa9269 Работал в компании, где практиковали парное программирование. В целом впечатления такие же, единственное отметил бы, что этой штукой лучше дозированно пользоваться, ибо быстрее устаешь как-то. Хотя мб это субъективное.
@@mixa9269 Читер! =)
отправил свою заявку на performance review, ожидаю результата
На текущем месте работы, раз в год происходит беседа с начальником о твоей полезности и планах компании на тебя на следующий год, как результат документ в котором все за фиксировано. Но оценка сроков и возможность корректировки раз в год все портят. По факту вообще отсутствие премирования за качественный код. Желание, что-нибудь отрефакторить приходится обосновывать. Во главе удовлетворенность клиента и сроки. Но это особенности немецкой региональной компании.
На каких языках ты говорил в НЕ русских офисах? Расскажи как преодолевал языковой барьер. Интересно послушать как ты говоришь на других языках.
th-cam.com/video/dO6jxwtAThQ/w-d-xo.html
th-cam.com/video/BlnPIOs6mY0/w-d-xo.html
Ну... ещё есть галеры и там может быть ещё опция перевести гребца на другой проект.
Оценивают по футболке.
У меня такая-же, кстати, от Qwertee?
Я принят.
Купил по рекламе в инстаграме 🙈
Супер видосик. Интересно, прибегут ли ща зануды и начнут ли пояснять что какой-нибудь блум фильтер - не настоящая струмктурма данмных
Вывод из видео - если делать плохо, будет плохо.
Перечислены просто детские ошибки перформанс ревью, которые вполне можно научиться избегать.
При этом польза от перфревью рассказана с явной предвзятостью, на мой взгляд. Об этом свидетельствует хотя бы хронометраж - сколько внимания уделено пользе, сколько вреду.
Ты крутой менеджер!)
Что за книга на столе лежит? )
Вся эта лабуда с оценками это защита компании от резкого изменения рынка зарплат, чтобы затягивать с повышением заплат, я бы даже сказал не с повышением, а выравниванием их до рыночного уровня. Короче чтобы создать у разработчика комплекс неполноценности. Если это было бы не так, то тогда новый человек заходил бы с зарплатой не выше среднего по компании, а потом бы оценивался для повышения. А так новые всегда заваливают по рынку и чаще с зп выше чем у тех, кто уже пару лет проработал и был бит оценочными палками в своем желании увеличить зп. Советую вам поподробнее узнать об этих оценках на собеседовании, и если их будет дофига, то будьте готовы что эта компания не собирается вам повышать особо.
что бы оценить чьюуто работу ее нада наблюдать. если наблюдения нет то это не оценка. А наблюдать ее может в основном тим лид.
Скажи пожалуйста, с какими навыками английского и немецкого переехал?
Немецкий уровня А2, английский pre intermediate
@@SeniorSoftwareVlogger то есть английский тоже А2? Просто я учусь на программиста и везде говорят о необходимости владения B2-C1, а оказывается можно и без этого обойтись. Спасибо огромное!
Я встречал людей с таким корявым английским, что мама не горюй. Я думаю, что мой английский был больше B1. Говорить мог, грамматика страдала
@@SeniorSoftwareVlogger а на каком языке приходилось составлять резюме и проходить интервью?
Не в тему, но что за лампа (или что-то другое) за монитором которое переливается разными цветами?
Гугли ambilight
Скажи, какие книги, упомянутые в этом ролике ты читал?
Первая th-cam.com/video/88WKzOTUZrY/w-d-xo.html
Вторая th-cam.com/users/postUgweO6TvTBNYX-o3eFB4AaABCQ
Мне кажется оценивать программиста не программист просто не может, да и не каждый программист может обьективно оценить собрата…
Поэтому и понапридумывали такую вот максимально примитивную аналитику…, сколько задач выполнил 🤷♂️, лол мой коллега к примеру фигачит забагованный и с низкой производительностью г*** код, но зато делает задач в два раза больше… Компания столкнется в будущем с такими проблемами что мало не покажется…
Пересмотрел и обратил внимание на один момент, который от меня ускользнул год назад.
Мы в моей текущей команде недавно внедрили сбор данных через Sup-бота в Slack вместо формального daily standup'а (который остался, но в неформальной форме и не в каждый рабочий день). Так вот, этот бот, помимо данных о том что ты делал/что планируешь делать/какие есть проблемы, спрашивает про твоё настроение в данный момент. Этот анонимный дата пойнт, он, якобы, никому не показывается, только в усреднённом виде - как "настроение в команде" на этот день.
И вот что я подумал в контексте performance review. Кажется, имеет смысл также спрашивать анкетируемого о его настроении в момент заполнения анкеты с обратной связью на коллегу, а также учитывать потом это настроение при выборке и сопоставлении данных из нескольких анкет. Возможно, есть корреляция с сигналом/шумом. Проверить это на практике, конечно же, весьма затруднительно. Но дата пойнт "настроения" кажется очень важным.
1:30 если бы эта оценка была анонимной...
Прям палочная система в случае с 10% отстающих.
Кайфовый офис
Сколько разной ненужной хрени расплодилось...Работать некому.
Херню делать легче, чем работать.
джобсу подражать хватит ))) мыслитель...
Лол
@@SeniorSoftwareVlogger вот зачем ты мне ответил, я напуган ) Но ты действительно жестикуляцией похож ) И да, джунов бить нельзя ;)
Посоветуй плиз литературу, о которой говоришь в видео.
Первая th-cam.com/video/88WKzOTUZrY/w-d-xo.html
Вторая th-cam.com/users/postUgweO6TvTBNYX-o3eFB4AaABCQ
Не думаю что кому-то понравится так работать. Сделал вовремя, то сухо скажут ок. А вот если что-то пошло не так сразу начинают искать кого бы репресировать. В 30ых годах в ссср было подобное и от этого отказались. А сейчас менеджеры в ит компаниях промышляют такой штукой. Судя по военным фильмам у немцев это вообще было популярно и видимо они до сих пор от этого не отказались. На мой взгляд это не к чему хорошему не приводит. Возможно это специфика галлер. Но если в компаниях такое практикуется, то лучше поискать другую работу. Когда каждый день над твоей головой висит дамоклов меч, то под стрессом начинаешь лепить ужас из кода, а если что-то можно быстро скопипастить то ты сразу так и поступишь. В итоге уровень проектов очень сильно скатывается. Ещё думаю эта вся тема идет из ошибки выжевшего. Есть например биография Стива Джобса и например там был такой факт что Стив Джобс устраивал разносы разработчикам и увольнял кого угодно за мелкие косяки, в итоге выросла компания apple и Стив стал миллиардером и построил крутую компанию. И возможно менеджеры такие "а ну я новый Стив Джобс" и думают, что так нужно делать.
а как решить сколько платить?))
Я оцениваю производительность в нашей компании так: умножаю скилл программиста на его мотивацию. В двух крайностях ( нет скилла, но огромная мотивация; огромный скилл, но нет мотивации) производительность будет 0 ( 0 * 100 и 100 * 0). Остальное можете сами интерполировать, но значения считаю равнозначными и с одинаковой метрикой ( от 0 до 100)
Понятно что человек будет не линейно "производить труд", от всякого рода внешних и внутренних причин, но в среднем весь результат всегда будет пропорционален мотивация * скилл. Если проводить аллегорию, то мотивация - бензин, а скилл - мощность двигателя, а на пути машины будут горки, ямы, и иногда ровная дорога.
Бро , Совершенно Согласен - Заставляют Делать Оценку Производительности ( то что реально никто не любит - но как-то нужна Держать " Team " в Тонусе ) - Вообще КАК МОЖНО ОЦЕНИВАТЬ ЧЕЛОВЕКА - И ПОТРАЧЕНЫЕ НЕРВЫ : (
Мне не хватило в первой части видео пояснения, что именно ты называл тут performance review. Как будто ты противопоставляешь performance review некоторым «другим хорошим практикам, как надо на самом деле оценивать людей», но в моем понимании все эти практики вполне могут работать в рамках формального процесса. То же общение с коллегами сотрудника - мне кажется довольно распространенный аспект performance review много где.
А если просто по теме, то мне кажется, что наличие формального процесса с грейдами, оценками, матрицами компетенций и пр. это скорее всего лучше, чем когда его нет. Понятно, что можно все то же самое делать без процессов на уровне отдельного менеджера и его общении с командой, но это подразумевает более высокую квалификацию всех менеджеров в компании. Формальные процессы позволяют даже не самым талантливым менеджерам соответствовать какому-то "baseline" в плане вовлеченности в развитие сотрудника и его карьерный рост. Это как например Scrum - наверное не идеальный способ управлять проектом, можно придумать лучше, но если заставить каждого менеджера переизобретать с нуля подход к ведению команды, то много не очень крутых менеджеров в итоге получат результат хуже. А так есть какой-то фреймворк, которому можно следовать и получать good enough результат. Вот кажется, что формальный performance review это как раз такой фреймворк для менеджеров.
"... но это подразумевает более высокую квалификацию всех менеджеров в компании"
И даже это, скорее всего, никак вам не поможет. Ведь управлять профессиональным развитием узкого специалиста в принципе способен только сам узкий специалист (с помощью или без помощи коллег-специалистов, внутри компании или в процессе обмена опытом с коллегами из индустрии). Потому что познания в таких сложных областях знания и практик, как IT и Software Engineering, у неспециалиста (менеджера) даже самой высокой квалификации будут всегда на уровне buzz word'ов и аналитических трендов рынка от условного Gartner, не привязанных ни к глубокому пониманию специфики проекта, ни хотя бы к личному опыту и чутью. Даже если он(а) сам(а) в прошлом когда-то был(а) квалифицированным узким специалистом средней руки, то на деле это может только усилить проявления нежелательных когнитивных искажений. Поэтому любое вовлечение в "развитие сотрудника" это дилетантизм, а если с оценками и какими-то формальными последствиями, то ещё и неприкрытая манипуляция. Управлять можно тем, что можно измерить, и как следует измерить, а не абы как. Работу Канемана на этот счёт Дмитрий в видео упоминал. В данном случае шума настолько много, что смысла в управлении нет.
Про девопс как культуру хотелось бы еще видео
"Руководство по DevOps" вам в помощь. Дивная книга.
Если сотрудника попросить дать структурированную обратную связь в письменной форме (причём, отметив как плюсы, так и минусы в одной анкете), по идее, это должно подснизить уровень шума. Потому что меньше места для срабатывания когнитивной лёгкости и приходится включать 2-ую систему (по Канеману). Как ты считаешь, поможет? У тебя был опыт сравнения устного/письменного и не-/структурированного фидбека? Спасибо!
А на чём работать?Не могу купить компьютер, от всего болят глаз, сижу за древним ноутом на ламповой подсветке.По компьютерным клубам хожу - везде компы плохие, глаза болят через 2 часа уже...Это начало конца эпохи компьютерной техники? Зачем оно надо, если пользоваться невозможно...
Dasung
Ламповая подсветка по моим наблюдениям для работы удобнее. На работе древний монитор с ccfl подсветкой и за ним спокойно можно просидеть целый день. А дома за более современным монитором с led подсветкой через час уже начинают глаза болеть. Скорее всего изза ШИМ регулировки яркоски. Хз. Ищи монторы с flicker free функцией или с частотой ШИМ повыше. Может вобще посмотри в сторону OLED экранов хотя там цены заоблачные.
Как услышал про 10% - так сразу запахло амазоном.
Что за монитор?)
работа не универ == оценка не показатель
Привет, мне не очень зашла парадигма реактивных фреймворков Ангуляр, Реакт, Вью. Свелт понравился очень сильны, но с ним плохо работают либы для ванильного джс. В итоге так и делаю статичные сайты mongoose + webpack + express.js + pug + vanilla js + mongodb. Есть ли спрос на таких программистов? Ещё мне понравилась идея 2-х фреймворков hotwire turbo + stimulus.js , это концепция SSE , их идея в том, что сайты становятся как облачный игровой сервис с минимум JS в браузере, т.е. сервер реактивно присылает участки html . Мне прям идея вкатила. Я думаю это круче чем реактивные фреймворки, которые я назвал в начале.
Твой подход - это, по факту, SSR. А SSE нужны для обновления информации на странице, не делая ненужные запросы с клиента на сервер, отдавать html прям такое.
SSR годится для статики, типа лендингов и обвязок в виде футера, хедера и подобного, где контент не меняется в целом. Но манипулировать с DOM прям больно, это реактивщиной, от части, и пытались исправить, а SPA и вовсе плачут. Как говорится, для каждой задачи свой инструмент.
Про спрос - просто зайди на сайты с вакансиями, посмотри требования и узнай хватит ли тебе твоих знаний для желаемой позиции.
@@artemhrytsenko1353 hotwire turbo использует именно SSE подход, они через вебсокеты и потоки (стримы) res.sendStream отправляют сгенерированные участки html , а stimulus.js регулярно следит за обновлениями содержания, чтобы на участки кода навешать слушателей-контроллеры. В общем hotwire крутая тема. Они ещё скоро выпустят strada чтобы можно было мобильные приложения делать с их идеей.
@@indigosay ну так это костыли до времен реактивщины)
@@artemhrytsenko1353 в общем рекомендую ознакомиться с этим фреймворком) он , наоборот , разгружает браузер пользователя от JS, так как бизнес-логика переносится на сервер, а заодно у разработчика выстроен грамотный порядок, т.е. можно масштабировать приложения не боясь беспорядка. По сути этот hotwire и есть реактивный фреймворк.
А так Реакт все берут, так как из-за его поддержки Цукенбергом на него сделано много библиотек (готовых решений), что ускоряет разработку)
Но как по мне Ангуляр, Реакт, Вью - это джаваскриптовые гранаты, закинутые в браузеры пользователя, а много джаваскрипта у юзера это не всегда хорошо))
Будущее за облачными технологиями всё-таки
@@indigosay твой подход это SSR. Он был и есть давно. Ты так говоришь будто бы только и сразу все начали пилить на этих ваших реактах, ангулярах и прочих. Всё было иначе.
Почитай историю и назначение реактивщины, как это устроено и почему это хорошо, или хотя бы просто почитай сравнение SSR и реактивщины, прежде чем писать мнение, которое само по себе обусловлено небольшим опытом разработки. Все хотят сделать автономию (небезосновательно) от сервера, форсят SPA и PWA (что лично считаю хреновой затеей, но если костыли а ля react native живут, то и PWA вполне себе будут), а тут человек хочет все 10 лет прогресса насмарку пустить :)
Использовать связку SSR + реактивщина - ок, чистый SSR для лендингов - тоже ок. Использовать абсолютно везде SSR - стреляешь себе в ногу и попадешь прямо в 2009.
P.S. Сноска про Цукерберга вообще бредова.
P.P.S. Порядок можно и в реакте навести, главное руки из правильного места иметь.
P.P.P.S. «бизнес-логика переносится на сервер» - а до этого она где была? Иль ты умудрился прямо с клиента к базе стучаться?))
Не знаю, возможно, наверное, непонятно зачем - это видео все объясняет. Буэ
под монитором клавиатура...ты ее разыгрывал ведь среди подписчиков, наряду с второй от Акко
Я К1 разыгрывал. Это К3
@@SeniorSoftwareVlogger хорошо ) прошу прощения за провокационный вопрос
Что думаешь о no-code?
жесть, не думал что все так плохо:
1. контролировать необходимо потому как могут работать на 2х работах одновременно. Потому как могут заливать на котиков.
2. методы оценки? Да хотя бы "покер" из аджайла - набросали задач, оценили, расписал по исполнителям, сделал план-факт... Иначе бида - все на 99% буду шаройо...
1. Если человек работает на двух работах и при этом закрывает все задачи норм, то в чем проблема?
2. Как покер из аджайла тут поможет? Заложил побольше да и все, любой не-джун тебе в легкую пояснит за оценку
Подскажите, 2К монитор 144гц подключил через HDMI к MacBook Pro 16" и максимум 50гц можно выставить. Тут дело в HDMI и надо через Display Port или я чего-то не понимаю?
Dp 1.4+
разве мак умеет в 144гц? это ж геймерская тема, а маки не про это.
@@G00glieS а при чем тут мак или не мак? Тут же все упирается в GPU и тип подключения к монитору
@@sekiro6969 и драйвера. На маках 144гц должно работать если кабель правильный и мак не шибко старый.
Я тоже хочу стать менеджером.....
во наговорил..
Да никогда процессы никакие не станут нормальными. Под нормальными я подразумеваю отсутствие негатива. Капитализм - это априори работодатель хочет от работника по максимуму выжать. А работник раб. Смириться нужно с тем, что все эти решения/процессы/большие теории о том, как якобы оптимизировать какие-то процессы. Принцип один - от тебя всегда будут хотеть больше вплоть до бесконечности.
Кстати, зп программистов "неоправданно высокие" очень обоснованы. Мало кого так пинают во время работы как айтишников. Все эти ежедневные скрамы, митинги.
Смотрел, как работает чел из автомастерской - пригнал ему что-то. И ждешь, пока не сделает. И хрен ты его как-то поторопишь. А попытаешься надавить ему на психику - вообще останешься без ремонта. Это только айтишников так приручили. Скрамы все эти по сути высасывают жизненную энергию очень дико. И неизвестно, что еще в старости у нас у всех выскочит из-за такого постоянного нервного напряга. Мы - первое поколение, которое это психологическое давление на себе такое постоянно испытывает.
Но, кстати, какие-то результаты уже есть. Импотентов полно.
Капитализм - это работодатель хочет от работника по максимуму выжать. А работник хочет побольше выжать из работодателя. Все в равновесии, капитализм - благо.
зп программистов "неоправданно высокие" обоснованы тем, что порог входа в эту сферу очень высокий, как и в любую другую сферу сложного интеллектуального труда. Только программистов при этом еще и нужно бесчетное кол-во, чтобы удовлетворить современный спрос. Поэтому и зарпалты, одни из самых высоких по рынку, вполне обоснованы.
Справедливости ради, нервный напряг здесь, как и в любой сфере, может быть, а может не быть. Программист, на котором завязана куча процессов серьезного проекта, и которого невыгодно выгонять, может так же посылать кого-угодно куда угодно. И вряд ли на него сможет кто-то надавить. Но для этого надо чтобы в тебе нуждались больше, чем ты в нуждаешься в ком-то. Кто больше зависит, тот и уступает
Дэлойт.
Также известна как "do little" 😏
Не нужно усложнять. Назначай частоту, с которой подчинённые могут просить прибавки. Например, раз в году. Соответственно раз в году любой желающий может сам решить какими метриками он может похвастать и подойти к тебе со словами "Дядь, я тут прокачался и за последний год не только решил такие-то задачи, но ещё и двух китайцев натаскал. Дай денег". А может и не подойти. Вот тогда надо задуматься, а чего это время уже подошло, а он денег не просит, Уж не потому ли, что месяц назад дали ему простую задачу на неделю, а он до сих результата не принёс
акула из гипса или бумажная ?
бумага
Не согласен с автором.
Я начинал в компании с позиции интерн 250$.
У нас в компании основной критерий это коммерческие часы и уровень английского + сбор фитбеков от членов команды по тому как ты вообще работаешь в команде, как комуницируешь, даёшь экспертизу.
В целом перфоменц ревью дает возможности понять в каких точка нужно улучшить навык и систематический рост зп.
В целом это занимает 1-2 ч в пол года
делОйт: th-cam.com/video/-eMBmkzLO_Q/w-d-xo.html&ab_channel=JamesWhittaker-DreamCareerLAB
Есть одна очень простая метрика о которой почему-то не сказали. Это насколько человек укладывается в сроки по оценке задачи. Пример у нас на работе. вся команда оценила задачу в 3 стори поинта (что у нас соответсвует примерно 3м дням). Дали одному разрабу, он уже делает её 2 спринта, т.е. 20 дней, и это при том, что в процессе нашелся способ еще и сильно упростить требования по задаче. Там реально нечего делать, и чем он занимается - я не знаю.. И это у него не первый случай. На дейликах постоянно какие-то отмазки. Поэтому я считаю что перфоманс ревью нужны хотя бы для того, чтобы увольнять таких лентяев.
а зачем ждали 17 дней? передаёте следующему из "вся команда", кто тоже как 3 дня оценил и засекаете, тоже будет долго делать или нет. Если второй тоже задержится, то скорее всего задача херово поставлена. Даже требования к ней пришлось упрощать. Только тупой программист не лентяй
@@i17talk8 Я бы так и сделал, но менеджмент на стороне заказчика, пусть они и решают. А насчет требований, не совсем правильно выразился, требования те же, просто нашли одну фичу используемой технологии, которая сильно упрощает реализацию.
@@GoodGuyFinishFirst Т.е. про лентяев возражений нет? :) А то я тоже неточно выразился. Имел в виду, что мне, например, лень переделывать код, поэтому выбираю писать качественно сразу, насколько хватает мозгов. А если по факту медленно работает - лень ждать исполнения - ускоряю, раз мозгов не хватило. Лень в этом случае может быть не той, о которой говорите вы.
@@i17talk8 Ну в моем понимании как.. Есть задача, есть её оценка. Просто сажусь и честно делаю, если получится быстрее оценки, то ничего, значит сделаю быстрее и возьму следующее. Если не успеваю - ну значит не уложился в сроки, бывает. Понятно, что в оценку тоже изначально стараюсь заложить преемлемый уровень качества. Мне интереснее именно так работать, чтобы была динамика, сделал одно - начинай другое. А есть люди, которые даже если сделали быстрее, начинают затягивать, и возможно заниматься какими-то своими делами, в то время, когда надо работать. В случае же этого чувака, он писал 400 строчек кода (включая тесты) 21 день, не самого сложного кода... Как на меня так это или лень, или он работает где-то еще параллельно, или просто глупость.
@@GoodGuyFinishFirst может так, а может, разбирался, где что и как написать. Я иногда тоже могу дофига думать, а потом написать немного. Зато перепроверил все связи, что ничего нигде не нарушил. ХЗ, как у вашего индивида. Вариантов немного, можно спросить. Если загнобили, правду не узнаете.
Видео о том, как натянуть сову на глобус)
Тільки продуктивність команди/компанії: людина може працювати опосередковано, але надихає людей і команда працює краще.
Посылаю всех кто пытается меня оценить. Могу ещё и в бубен дать.
Так и запишем: not open to a constructive feedback. Надо поработать над этим. А пока misses expectations.
@@SeniorSoftwareVlogger 😁 спасибо за оценку.
Идея хорошая. Только вот я пытаюсь себя оценить. Может, есть ещё какие варианты?