Хорошо если менежмент энергичный и реально что-то делает, создает и улучшает условия для работы, но бывает и так, что они устают и забывают, что у них есть роль в проекте подразумевающая выполнение определённой работы, как у регулировщика на дороге, от которой другие зависят. Работать в стиле миллиардера, валяясь на шезлонге с гарнитурой за ухом и что-то там надиктовывая на созвонах долго не проканает. Некоторым настолько все равно, что они даже не пользуются продуктом, который делают, хотя могли бы. Или ещё какие-нибудь универсалы, которым все равно чем управлять производством кошачьего корма или разработкой ПО.
Это не работает. Предположим первый сотрудник code owner. Второй решал, релал какую-то задачу и наконец выдал решение, которое не устраивает первого. Первый блокирует pull request. Вот что происходит дальше. Менеджер спрашивает у второго статус по задаче, он говорит, что вот я сделал, а первый заблокировал. Менеджер идёт к первому и убеждает его принять решение как есть потому что работы много и нужно идти дальше вперёд. Время - деньги. Если же побеждает первый и pull request отправляется на доработку, то второй начинает очень лениво и очень долго править замечания. С управленческой точки зрения это все равно, что простой. Я уже не говорю об эмоциональной стороне, когда так называемые сеньоры очень болезненно воспринимают любые замечания к результатам своего труда.
Тоже пытался как-то все упорядочить. Потом с грустью осознал, что пока наводишь порядок в одной стороне, с другой стороны начинается хаос потому что коллегам то ли пофиг на системность и лишь бы закрыть задачу, то ли нет глубокого понимания и делают как могут. В итоге приходится признать поражение и поставить крест на мечтах о стройном будущем проекта.
В последнее время, рефлексируя о прошлом опыте, появилась мысль, что если бы вместо одного манагера, который нормально так по деньгам получал и руками ничего не делал, нанять 5 простых работяг, то все проблемы можно было бы решить.
Как-то раз давно я сказал начальнику, что люди не выполняют задачи не потому что не хотят, а потому что не могут. Он посмотрел на меня непонимающим взглядом. Начальство не хочет слышать о проблемах потому что это будет означать, что они наняли недостаточно квалифицированного сотрудника, а в этом они себе никак признаться не могут, их психика защищает их обходя такие острые углы.
Да, кто везет на том и едут. Можно конечно во всем винить бестолковых управленцев, но мне кажется, что это двусторонняя дорога. Исполнитель тоже должен уметь говорить STOP.
Все 4 пункта в одном человеке не встречал, но по первому частично наблюдал такое. Сотрудники с большим авторитетом игнорировали правила, которые были обсуждены на общем совещании и они четко не возражали. Ну например, договорились делать ревью кода, а человек чужие пул-реквесты апрувит не глядя, замечания к своим игнорирует и находит тех кто поставит ему апрув также не глядя потому что не считает нужным кому-то что-то объяснять. Этот вовсе не означает, что его действия лишены смысла, возможно он по своему прав отказываясь выполнять бессмысленную работу. Но в то же время это такое тихое сопротивление - я не против ваших правил, если они вам нужны, но и подчиняться им не буду. Других людей к себе в работу брать не хотят, держатся особняком.
Ну это нормально, что хочется порезвиться. Каждый программист сам по себе источник хаоса и задача менеджера как раз таки контролировать этот хаос, а не потворствовать ему, ограничить его рамками модуля чтобы этот хаос не распространился на весь проект. Да вот в рамках своего участка делай что хочешь лишь бы работало, но на другие не лезь. Например, один программист пилит бэкенд и что-то ему как-то скучно стало и он начинает доставать менеджера чтобы тот дал ему другую задачу развеяться, а тот и возьми и дай ему фронтенд задачу. Кросс-скиллинг и все такое. Бэкендщик приходит в модуль фроненда и начинает там резвиться, а потом наломав там дров возвращается обратно к себе в бэкенд. В итоге код проекта уродуется нашествием таких гастролеров. Ревью кода от этого не защищает потому что, когда время уже потрачено на задачу и она уже хоть как-то реализована, то никто ничего переделывать не будет.
Люди хотели бы один раз на старте пожертвовать время чтобы разобраться с проектом, а потом каждый день небольшими усилиями вносить улучшения, потому что у людей может быть ещё и личная жизнь, которая требует внимания. А что делает с людьми предлагаемый в статье подход? Каждый день как в самом начале трать много времени чтобы разбираться с тем что наделали другие до тебя и ещё объясняй другим, что ты сам наделал, потому что менеджер боится потери бойца, а продуктивность у тебя должна быть такая как если бы ты не тратил на все это время, короче будь ноулайфером, живи и дыши работой пока тебя не выдоят досуха и не выбросят как отработанный материал.
Да, про людей не думают. Вся статья по сути про то, что бы такое придумать чтобы защититься от потери разработчика и все предлагаемые решения лишают разработчика возможности комфортно работать. Если менеджмент выстраивает систему с защитой от ухода людей, то в такой системе люди будут уходить потому что это заложено в работу системы. А надо наоборот выстраивать систему в которой людям захочется остаться. Что сделать чтобы разработчику было комфортно? Может все таки стоит ему дать возможность работать над чем-то одним, а не гонять по системе как вшивого по бане. В IT много управленцев, которые ими стали за то, что хорошо делали техническую работу, но они не понимают базовых принципов организации труда: разделение труда, рабочая нагрузка и пр.
Вот да, но если я предложу, что давайте применим практику ротации к управленцам, например, CEO, Team Lead, директор по маркетингу, product manager будут меняться между собой, то они мне скажут, что это бред, но почему-то учинять такое издевательство над разработчиками считается в порядке вещей.
Передавать большие пачки float-параметров это моветон. И это проблема легко решается через Parameter Object. Конструктор не даст оставить поля без инициализации. Можно еще std::optional заюзать. Вызов сеттеров можно красиво сделать через fluent interface. Короче вариантов куча.
Если IDE будет тырить исходники, то такая IDE нафиг никому не будет нужна. Может быть собирают какую-то статистику по коду, измеряют код какими-то хитрыми метриками и уже этот массив чисел отправляют.
Не скажу, что все написаное вызывает у меня отклик, но что-то есть в этом слове - "безопасник".
Для меня это прежде всего люди чрезмерно сфокусированные на том чтобы как минимум удержать свои позиции. Образно говоря держатся за стол, портфель. Чаще всего это люди из руководства. Они склоны играть во власть и заниматься интриганством вместо того чтобы делать реальную работу. С ними сложно работать потому что они все время видят в тебе угрозу для себя, даже если у тебя и в мыслях нет занять их место. Они вообще видят угрозу в тех кто по-настоящему работает потому что понимают, что эти люди могут их бездельников легко заменить.
Например, начальство, которое обесценивает и преуменьшает твою работу, не придает значимости достигнутым результатам и внесенному вкладу.
Или ещё бывают руководящие группировки, которые своим прощают все, а из чужих делают козлов отпущения.
Или если, например, какое-то мероприятие прошло без их людей, то они обязательно скажут, что прошло скучно, уныло.
Один из способов как их контрить - успакаивать их публично признавая их авторитет над собой и былые заслуги, чтобы они чувствовали себя хорошо. Тогда можно даже рассчитывать на какую-то благосклонность с их стороны, но выше их прыгнуть не дадут, кого-то это устраивает, кого-то нет.
Естественно, ведь им срочно нужно обучать ИИ. Данные стали дороже продукта. Как говорится, если ты не платишь за продукт, то продукт это ты. Забавно, что юзеры буквально своими руками будут растить то, что их потом заменит.
Одна из проблем многих сервисов знакомств в том что там и раньше была куча фейков и ботов. А человеку нужен реальный человек. И не просто какой-то человек, а подходящий. Вот эту проблему поиска и совместимости надо решать. Поэтому идея добавить бота в сервис знакомств, которые и так заполонены фейками выглядит как выстрел себе в ногу.
Хорошо если менежмент энергичный и реально что-то делает, создает и улучшает условия для работы, но бывает и так, что они устают и забывают, что у них есть роль в проекте подразумевающая выполнение определённой работы, как у регулировщика на дороге, от которой другие зависят. Работать в стиле миллиардера, валяясь на шезлонге с гарнитурой за ухом и что-то там надиктовывая на созвонах долго не проканает. Некоторым настолько все равно, что они даже не пользуются продуктом, который делают, хотя могли бы. Или ещё какие-нибудь универсалы, которым все равно чем управлять производством кошачьего корма или разработкой ПО.
Это не работает. Предположим первый сотрудник code owner. Второй решал, релал какую-то задачу и наконец выдал решение, которое не устраивает первого. Первый блокирует pull request. Вот что происходит дальше. Менеджер спрашивает у второго статус по задаче, он говорит, что вот я сделал, а первый заблокировал. Менеджер идёт к первому и убеждает его принять решение как есть потому что работы много и нужно идти дальше вперёд. Время - деньги. Если же побеждает первый и pull request отправляется на доработку, то второй начинает очень лениво и очень долго править замечания. С управленческой точки зрения это все равно, что простой. Я уже не говорю об эмоциональной стороне, когда так называемые сеньоры очень болезненно воспринимают любые замечания к результатам своего труда.
Тоже пытался как-то все упорядочить. Потом с грустью осознал, что пока наводишь порядок в одной стороне, с другой стороны начинается хаос потому что коллегам то ли пофиг на системность и лишь бы закрыть задачу, то ли нет глубокого понимания и делают как могут. В итоге приходится признать поражение и поставить крест на мечтах о стройном будущем проекта.
В последнее время, рефлексируя о прошлом опыте, появилась мысль, что если бы вместо одного манагера, который нормально так по деньгам получал и руками ничего не делал, нанять 5 простых работяг, то все проблемы можно было бы решить.
Как-то раз давно я сказал начальнику, что люди не выполняют задачи не потому что не хотят, а потому что не могут. Он посмотрел на меня непонимающим взглядом. Начальство не хочет слышать о проблемах потому что это будет означать, что они наняли недостаточно квалифицированного сотрудника, а в этом они себе никак признаться не могут, их психика защищает их обходя такие острые углы.
Да, кто везет на том и едут. Можно конечно во всем винить бестолковых управленцев, но мне кажется, что это двусторонняя дорога. Исполнитель тоже должен уметь говорить STOP.
Все 4 пункта в одном человеке не встречал, но по первому частично наблюдал такое. Сотрудники с большим авторитетом игнорировали правила, которые были обсуждены на общем совещании и они четко не возражали. Ну например, договорились делать ревью кода, а человек чужие пул-реквесты апрувит не глядя, замечания к своим игнорирует и находит тех кто поставит ему апрув также не глядя потому что не считает нужным кому-то что-то объяснять. Этот вовсе не означает, что его действия лишены смысла, возможно он по своему прав отказываясь выполнять бессмысленную работу. Но в то же время это такое тихое сопротивление - я не против ваших правил, если они вам нужны, но и подчиняться им не буду. Других людей к себе в работу брать не хотят, держатся особняком.
Ну это нормально, что хочется порезвиться. Каждый программист сам по себе источник хаоса и задача менеджера как раз таки контролировать этот хаос, а не потворствовать ему, ограничить его рамками модуля чтобы этот хаос не распространился на весь проект. Да вот в рамках своего участка делай что хочешь лишь бы работало, но на другие не лезь. Например, один программист пилит бэкенд и что-то ему как-то скучно стало и он начинает доставать менеджера чтобы тот дал ему другую задачу развеяться, а тот и возьми и дай ему фронтенд задачу. Кросс-скиллинг и все такое. Бэкендщик приходит в модуль фроненда и начинает там резвиться, а потом наломав там дров возвращается обратно к себе в бэкенд. В итоге код проекта уродуется нашествием таких гастролеров. Ревью кода от этого не защищает потому что, когда время уже потрачено на задачу и она уже хоть как-то реализована, то никто ничего переделывать не будет.
Люди хотели бы один раз на старте пожертвовать время чтобы разобраться с проектом, а потом каждый день небольшими усилиями вносить улучшения, потому что у людей может быть ещё и личная жизнь, которая требует внимания. А что делает с людьми предлагаемый в статье подход? Каждый день как в самом начале трать много времени чтобы разбираться с тем что наделали другие до тебя и ещё объясняй другим, что ты сам наделал, потому что менеджер боится потери бойца, а продуктивность у тебя должна быть такая как если бы ты не тратил на все это время, короче будь ноулайфером, живи и дыши работой пока тебя не выдоят досуха и не выбросят как отработанный материал.
Да, про людей не думают. Вся статья по сути про то, что бы такое придумать чтобы защититься от потери разработчика и все предлагаемые решения лишают разработчика возможности комфортно работать. Если менеджмент выстраивает систему с защитой от ухода людей, то в такой системе люди будут уходить потому что это заложено в работу системы. А надо наоборот выстраивать систему в которой людям захочется остаться. Что сделать чтобы разработчику было комфортно? Может все таки стоит ему дать возможность работать над чем-то одним, а не гонять по системе как вшивого по бане. В IT много управленцев, которые ими стали за то, что хорошо делали техническую работу, но они не понимают базовых принципов организации труда: разделение труда, рабочая нагрузка и пр.
Вот да, но если я предложу, что давайте применим практику ротации к управленцам, например, CEO, Team Lead, директор по маркетингу, product manager будут меняться между собой, то они мне скажут, что это бред, но почему-то учинять такое издевательство над разработчиками считается в порядке вещей.
Проблема как раз таки в неявном преобразовании.
Передавать большие пачки float-параметров это моветон. И это проблема легко решается через Parameter Object. Конструктор не даст оставить поля без инициализации. Можно еще
std::optionalзаюзать. Вызов сеттеров можно красиво сделать через fluent interface. Короче вариантов куча.Ничего удивительного, C++ всегда держал разработчика на поводке достаточной длины чтобы выстрелить себе в ногу.
Пруфы? Самолично установленные вредоносные расширения не в счёт.
Если IDE будет тырить исходники, то такая IDE нафиг никому не будет нужна. Может быть собирают какую-то статистику по коду, измеряют код какими-то хитрыми метриками и уже этот массив чисел отправляют.
Не скажу, что все написаное вызывает у меня отклик, но что-то есть в этом слове - "безопасник".
Для меня это прежде всего люди чрезмерно сфокусированные на том чтобы как минимум удержать свои позиции. Образно говоря держатся за стол, портфель. Чаще всего это люди из руководства. Они склоны играть во власть и заниматься интриганством вместо того чтобы делать реальную работу. С ними сложно работать потому что они все время видят в тебе угрозу для себя, даже если у тебя и в мыслях нет занять их место. Они вообще видят угрозу в тех кто по-настоящему работает потому что понимают, что эти люди могут их бездельников легко заменить.
Например, начальство, которое обесценивает и преуменьшает твою работу, не придает значимости достигнутым результатам и внесенному вкладу.
Или ещё бывают руководящие группировки, которые своим прощают все, а из чужих делают козлов отпущения.
Или если, например, какое-то мероприятие прошло без их людей, то они обязательно скажут, что прошло скучно, уныло.
Один из способов как их контрить - успакаивать их публично признавая их авторитет над собой и былые заслуги, чтобы они чувствовали себя хорошо. Тогда можно даже рассчитывать на какую-то благосклонность с их стороны, но выше их прыгнуть не дадут, кого-то это устраивает, кого-то нет.
Естественно, ведь им срочно нужно обучать ИИ. Данные стали дороже продукта. Как говорится, если ты не платишь за продукт, то продукт это ты. Забавно, что юзеры буквально своими руками будут растить то, что их потом заменит.
Не думаю, что это было искренне. Скорее такая ирония.
Интересно, но дорого.
Одна из проблем многих сервисов знакомств в том что там и раньше была куча фейков и ботов. А человеку нужен реальный человек. И не просто какой-то человек, а подходящий. Вот эту проблему поиска и совместимости надо решать. Поэтому идея добавить бота в сервис знакомств, которые и так заполонены фейками выглядит как выстрел себе в ногу.