Re[7]: Так, господа, а вот это уже серьезно (Haskell нужен 2)
От: Ziaw Россия  
Дата: 22.06.22 01:45
Оценка:
Здравствуйте, IT, Вы писали:

IT>Почему только? В любом продукте есть масса работы для инженеров любого уровня. А маленькая команда сильных инженеров — это, во-первых, дорого, во-вторых, рискованно. Так считают современные манагеры.


Современные манагеры, которые так считают, преследуют в первую очередь свои интересы — большая команда это престижнее, ей проще управлять как людьми, меньше скилов управленца нужно. А то, что при этом в коде творится и насколько все могло бы быть дешевле и проще — не их зона ответственности. Если все дорого, валится и надо переписать — виновата команда, архитектор, тимлиды (менеджер же не мог это проконтролировать). Если продукт таки задышал и начал приносить прибыль — менеджер молодец, для бизнеса он управлял его созданием.
Re[17]: Так, господа, а вот это уже серьезно (Haskell нужен 2)
От: SkyDance Земля  
Дата: 22.06.22 02:51
Оценка: +1
P>Т.е. сравнивниваем устоявшиеся команды, которые имеют успешный опыт реализации схожих по профилю и сложности проектов, с разницей только в технологиях.

Еще раз повторю, ни разу подобного не видел. Более того, сравнивать зачастую стоит не столько команды, сколько конкретных людей, которые команду образуют. Достаточно одного сильного инженера с талантом преподавателя, чтобы команда оценила и полюбила незнакомый стек. Достаточно одного брюзги с нежеланием учиться ничему новому, поставленного в позицию сеньора, чтобы та же команда стала сборищем тормозов.
Re[17]: Так, господа, а вот это уже серьезно (Haskell нужен 2)
От: SkyDance Земля  
Дата: 22.06.22 03:43
Оценка:
·>Эээ.. пхп же остался. А вот лисп переписали и лиспа не осталось вообще.

Где остался-то? Уж точно не в Facebook'е. Гуглить по словам "Hack" (форк PHP).

SD>>Более того, PHP как язык не поддерживается вообще.


...но это не в Фейсбуке. Лисп вне Yahoo тоже жив.

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

·>Stable release Haskell 2010[2] / July 2010; 11 years ago

Внимательнее смотри.

27 May 2022
GHC 9.2.3 Released! [download]
Re[8]: Так, господа, а вот это уже серьезно (Haskell нужен 2)
От: so5team https://stiffstream.com
Дата: 22.06.22 05:09
Оценка:
Здравствуйте, Ziaw, Вы писали:

Z>Современные манагеры, которые так считают, преследуют в первую очередь свои интересы — большая команда это престижнее, ей проще управлять как людьми, меньше скилов управленца нужно.


Дико извиняюсь, но позвольте уточнить, правильно ли вас понял: вы утверждаете, что для управления коллективом из 100 человек управленческих навыков нужно меньше, чем для управления коллективом из 10 человек?
Re[9]: Так, господа, а вот это уже серьезно (Haskell нужен 2)
От: Ziaw Россия  
Дата: 22.06.22 05:46
Оценка: -2
Здравствуйте, so5team, Вы писали:

S>Дико извиняюсь, но позвольте уточнить, правильно ли вас понял: вы утверждаете, что для управления коллективом из 100 человек управленческих навыков нужно меньше, чем для управления коллективом из 10 человек?


Эффективно управлять командой профи из 5 человек (то есть согласовывать цели продукта, команды, компании) в разы сложнее, чем набрать 50 человек и размазать ответственность по всем. То, что это будет в 5 раз дороже тоже гораздо проще обосновать — есть конкретные метрики. Вобщем жопа менеджера прикрыта со всех сторон, в отличии от первого варианта. Опять же тупняки менеджмента, типа продавленного неверного решения, в команде из 50 человек вообще не видны.

Ниже цена, выше риски. Чудес не бывает. У менеджера конфликт интересов с компанией, его задача снизить личные риски, у компании — быть эффективной.
Re[10]: Так, господа, а вот это уже серьезно (Haskell нужен 2)
От: so5team https://stiffstream.com
Дата: 22.06.22 05:50
Оценка: +1
Здравствуйте, Ziaw, Вы писали:

Спасибо за то, что развернуто ответили. Еще вопрос, если можно: это вы на основании собственного опыта или из книг/разговоров с коллегами к такому выводу пришли?
Re[18]: Так, господа, а вот это уже серьезно (Haskell нужен 2)
От: Pauel Беларусь http://blogs.rsdn.org/ikemefula
Дата: 22.06.22 07:26
Оценка:
Здравствуйте, SkyDance, Вы писали:

P>>Т.е. сравнивниваем устоявшиеся команды, которые имеют успешный опыт реализации схожих по профилю и сложности проектов, с разницей только в технологиях.


SD>Еще раз повторю, ни разу подобного не видел.


Значит, мало видел.

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


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

Все достаточно просто — перформанс команды == перформанс ботлнека. И вот такая штука, что код бывает ботлнеком не так уж и часто. Гораздо чаще таким ботлнеком будет обеспечение качества, менеджмент и тд. Например, мега-менеджер решил, что им тестировщики не нужны. Ну ок. Значит вся команда начинает потиху отрываться от реальности, независимо от квалификации. Рано или поздно все это приводит к тому, что продукт заполняется вечноживыми багами.
Re[8]: Так, господа, а вот это уже серьезно (Haskell нужен 2)
От: Pauel Беларусь http://blogs.rsdn.org/ikemefula
Дата: 22.06.22 07:30
Оценка:
Здравствуйте, Ziaw, Вы писали:

Z>Современные манагеры, которые так считают, преследуют в первую очередь свои интересы — большая команда это престижнее, ей проще управлять как людьми, меньше скилов управленца нужно. А то, что при этом в коде творится и насколько все могло бы быть дешевле и проще — не их зона ответственности. Если все дорого, валится и надо переписать — виновата команда, архитектор, тимлиды (менеджер же не мог это проконтролировать). Если продукт таки задышал и начал приносить прибыль — менеджер молодец, для бизнеса он управлял его созданием.


У тебя неадекватное обобщение, разновидность шериданства, т.н. "технологического расизма". Разница в том, что у шеридана виноваты девелоперы, у тебя — менеджеры.
Re[10]: Так, господа, а вот это уже серьезно (Haskell нужен 2)
От: Pauel Беларусь http://blogs.rsdn.org/ikemefula
Дата: 22.06.22 07:32
Оценка:
Здравствуйте, Ziaw, Вы писали:

Z>Эффективно управлять командой профи из 5 человек (то есть согласовывать цели продукта, команды, компании) в разы сложнее, чем набрать 50 человек и размазать ответственность по всем. То, что это будет в 5 раз дороже тоже гораздо проще обосновать — есть конкретные метрики. Вобщем жопа менеджера прикрыта со всех сторон, в отличии от первого варианта. Опять же тупняки менеджмента, типа продавленного неверного решения, в команде из 50 человек вообще не видны.

Z>Ниже цена, выше риски. Чудес не бывает. У менеджера конфликт интересов с компанией, его задача снизить личные риски, у компании — быть эффективной.

Вот-вот. Шериданство в чистом виде.
Re[9]: Так, господа, а вот это уже серьезно (Haskell нужен 2)
От: Ziaw Россия  
Дата: 22.06.22 08:04
Оценка:
Здравствуйте, Pauel, Вы писали:

P>У тебя неадекватное обобщение, разновидность шериданства, т.н. "технологического расизма". Разница в том, что у шеридана виноваты девелоперы, у тебя — менеджеры.


Это какие-то твои проекции. Здесь нет ничего про вину. Здесь про то, что умеют и чем руководствуются менеджеры. Я сам менеджер, если что и мне нафиг не нужны трудовые подвиги ни мои ни командные. Работа по выжиманию всего из требований, стека и архитектуры результативная, но очень слабо предсказуемая, а это мало кому интересно. Более того, это может удлинить какие-то промежуточные этапы, плохо попадает в оценку и сложно ложится в проектную деятельность.

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

Это мой опыт и если все что тебе остается — переходить на личности, то избавь меня от такого чтения. Себя же дураком выставляешь, у которого бомбит от того, что кто-то может по другому и срочно надо опровергнуть.
Re[6]: Так, господа, а вот это уже серьезно (Haskell нужен 2
От: Ночной Смотрящий Россия  
Дата: 22.06.22 08:06
Оценка:
Здравствуйте, vsb, Вы писали:

vsb>В схеме есть необычные концепции. Это continuations и гигиенические макросы. Аналога этому в других языках обычно нет


Это continuations то в других языках нет? Или другие языки у тебя строго равны java?
... << RSDN@Home 1.3.17 alpha 5 rev. 62>>
Re[10]: Так, господа, а вот это уже серьезно (Haskell нужен 2)
От: Ночной Смотрящий Россия  
Дата: 22.06.22 08:06
Оценка: +3
Здравствуйте, Ziaw, Вы писали:

Z>Эффективно управлять командой профи из 5 человек (то есть согласовывать цели продукта, команды, компании) в разы сложнее, чем набрать 50 человек и размазать ответственность по всем.


Звучит как слова теоретика. На практике с точностью до наоборот — управлять 5 профи практически не нужно, они сами прекрасно справятся, а вот заставить 50 раззвиздяев что то выдать полезное — крайне нетривиальная задача.
Плюс больших команд со средней квалификацией не в том что ими проще/комфортнее/престижнее управлять, а в том что они обеспечивают business continuity. Т.е. такую команду намного проще создать и прогнозируемо поддерживать примерно в одинаковом состоянии длительный промежуток времени. Т.е., к примеру, уволилось у тебя из такой команды пара-тройка человек — да и фик бы с ними, новых наймем. А вот если такое произойдет с командой из 5 профи — продукт окажется на коленях.
Поэтому большие конторы стараются профи-команды применять там, где риск подобного минимален либо бенефиты перевешивают риски — стартап-проекты, аварийные команды, определяющие главные свойства продукта его части.
... << RSDN@Home 1.3.17 alpha 5 rev. 62>>
Re[19]: Так, господа, а вот это уже серьезно (Haskell нужен 2)
От: Ziaw Россия  
Дата: 22.06.22 08:07
Оценка:
Здравствуйте, Pauel, Вы писали:

P>Вот-вот. И нужно теперь гарантировать, что этих людей ты сможешь вовремя заменить.


Гарантировать можно только свою смерть. Если бы можно было гарантировать успех проекта, то все бы давно уже это делали.

P>Как то так выходит, что команда крутых спецов на старте означает переписывание всего подряд с версии 2.0. Вот пример с Лиспом он как раз это и продемонстрировал.


Не выходит. Но заменять людей и расставаться с ними в любом случае надо уметь.
Re[20]: Так, господа, а вот это уже серьезно (Haskell нужен 2)
От: Ночной Смотрящий Россия  
Дата: 22.06.22 08:10
Оценка: +1
Здравствуйте, Ziaw, Вы писали:

Z>Гарантировать можно только свою смерть. Если бы можно было гарантировать успех проекта, то все бы давно уже это делали.


Так и делают. Если у тебя есть хороший vision, проработанный рынок и ресурсы на разработку — вероятность успеха очень высока. Я крайне редко вижу сейчас проваленные только из-за проблем в реализации проекты. Проваливаются почти всегда из-за кривого vision или неправильной оценки рынка.
... << RSDN@Home 1.3.17 alpha 5 rev. 62>>
Re[11]: Так, господа, а вот это уже серьезно (Haskell нужен 2)
От: Ziaw Россия  
Дата: 22.06.22 08:20
Оценка:
Здравствуйте, Ночной Смотрящий, Вы писали:

НС>Звучит как слова теоретика. На практике с точностью до наоборот — управлять 5 профи практически не нужно, они сами прекрасно справятся, а вот заставить 50 раззвиздяев что то выдать полезное — крайне нетривиальная задача.


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

НС>Плюс больших команд со средней квалификацией не в том что ими проще/комфортнее/престижнее управлять, а в том что они обеспечивают business continuity. Т.е. такую команду намного проще создать и прогнозируемо поддерживать примерно в одинаковом состоянии длительный промежуток времени. Т.е., к примеру, уволилось у тебя из такой команды пара-тройка человек — да и фик бы с ними, новых наймем. А вот если такое произойдет с командой из 5 профи — продукт окажется на коленях.

НС>Поэтому большие конторы стараются профи-команды применять там, где риск подобного минимален либо бенефиты перевешивают риски — стартап-проекты, аварийные команды, определяющие главные свойства продукта его части.

Именно это я и говорю. Большим конторам редко нужны такие кейсы по вполне понятным и обоснованным причинам. Но там где они применяются, хорошую экономию дает и стек и умелое использование его особенностей. А именно это пытаются здесь оспорить некоторые как "не бывает, а если бывает, то все равно говно получается".
Re[11]: Так, господа, а вот это уже серьезно (Haskell нужен 2)
От: Ziaw Россия  
Дата: 22.06.22 08:23
Оценка:
Здравствуйте, so5team, Вы писали:

S>Спасибо за то, что развернуто ответили. Еще вопрос, если можно: это вы на основании собственного опыта или из книг/разговоров с коллегами к такому выводу пришли?


Из собственного.
Re[12]: Так, господа, а вот это уже серьезно (Haskell нужен 2)
От: Ночной Смотрящий Россия  
Дата: 22.06.22 08:27
Оценка: +1
Здравствуйте, Ziaw, Вы писали:

Z>Управлять 5 профи все равно нужно


Только стратегически, чтобы они выдерживали курс. Иначе это не профи.

НС>>Поэтому большие конторы стараются профи-команды применять там, где риск подобного минимален либо бенефиты перевешивают риски — стартап-проекты, аварийные команды, определяющие главные свойства продукта его части.

Z>Именно это я и говорю.

Но причины этого ты приводишь какие то фантастические.
... << RSDN@Home 1.3.17 alpha 5 rev. 62>>
Re[12]: Так, господа, а вот это уже серьезно (Haskell нужен 2)
От: so5team https://stiffstream.com
Дата: 22.06.22 08:41
Оценка:
Здравствуйте, Ziaw, Вы писали:

S>>Спасибо за то, что развернуто ответили. Еще вопрос, если можно: это вы на основании собственного опыта или из книг/разговоров с коллегами к такому выводу пришли?


Z>Из собственного.


Очень и очень странно. Возможно, вам повезло. Возможно, вы просто не отрефлексировали свое собственное развитие в менеджменте и судите о сложности управления коллективом из 100 человек не учитывая опыта, которого у вас не было когда вы управляли коллективом из 10 человек.
Re[21]: Так, господа, а вот это уже серьезно (Haskell нужен 2)
От: Ziaw Россия  
Дата: 22.06.22 08:44
Оценка:
Здравствуйте, Ночной Смотрящий, Вы писали:

НС>Так и делают. Если у тебя есть хороший vision, проработанный рынок и ресурсы на разработку — вероятность успеха очень высока. Я крайне редко вижу сейчас проваленные только из-за проблем в реализации проекты. Проваливаются почти всегда из-за кривого vision или неправильной оценки рынка.


Если ресурсов на разработку с запасом, да, высока. Сейчас достаточно практик наработано. Можем конечно пободаться за термины гарантии/вероятности, но не вижу смысла.
Re[12]: Так, господа, а вот это уже серьезно (Haskell нужен 2)
От: Pauel Беларусь http://blogs.rsdn.org/ikemefula
Дата: 22.06.22 08:51
Оценка:
Здравствуйте, Ziaw, Вы писали:

НС>>Звучит как слова теоретика. На практике с точностью до наоборот — управлять 5 профи практически не нужно, они сами прекрасно справятся, а вот заставить 50 раззвиздяев что то выдать полезное — крайне нетривиальная задача.


Z>Управлять 5 профи все равно нужно и все управленческие проблемы с ними уникальны.


Обычно такие команды максимально автономны. Им сообщают приоритеты, новые фичи и всё. Т.е. участие менеджера сводится к минимуму.

Проблемой может быть говно- и микроменеджмент — тогда команда профи может как разбежаться, так и "сожрать" менеджера. Мне, скажем, известен случай, когда когда проектная команда из таких профи сожрала не одного, а целый страйк менеджеров.

Например,
1 прибегает менеджер и вопит "..я, чего ты тут занимаешься этим, это уже не надо..." ? А откуда разработчику знать, что не надо, если тикет ему только вчера выдан?
2 Или так "..я, почему бакенды коммитают раз в день, а фронтенды по 10-15 раз в день" и начинает "ускорять", потому что по его мнению бакенды тупые и ленивые, а фронтенды — хорошие и годные.
3 Или вот кейс "на текущий спринт приоритет — десктоп!!!!1111" и всем тикеты по андроиду. Следующий спринт — "приоритет андроид!!!!1" и тут же менеджер требует "мне срочно нужен релиз десктопа"
4 А вот еще "напиши вот такой код, должно работать", "если сеть ненадежна, то пусть админы сделают её надежной" — это менеджер объясняет разработчику с 15ю лет опыта, что можно писать код так, как будто сеть 100% надежна.

Итого 1 — сожран, 2 — сожран, 3 — сожран, 4 — сожран. А продукт взлетел, несмотря на "менеджеров"
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.