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