Надо отметить, что если бы у меня было больше народа в команде, самую сложную часть можно было бы и разбить, тогда она стала бы проще.
(ответственый за ядро симуляции VHDL уволился после того, как прочитал и понял главу про локально и глобально статические значения; стандарты уровня VHDL это страшная сила)
Я еще успел их частично реализовать. Но это было прямо ударом по голове, посколько меняло напрочь архитектуру (разделение синтаксического анализа и вычислений полетело в трубу).
Если бы не java для frontend-а, то можно было использовать часть имеющегося кода, а в итоге получился какой-то крокодил.
Описанный здесь стиль менеджмента идеально подходит для задумчивых интровертов. С экстравертами дело сложнее. У них мысль приходит тогда и только тогда, когда они что-то обсуждают с коллегами. Начальник здесь, в принципе, может помочь, но только если он компетентен.
Дело не в общении. Производительность экстраверта как программиста не зависит от частоты посещения ночных клубов (по крайней мере, прямой зависимости я не наблюдала). У них просто мысль по-другому работает. Не расскажешь (не обсудишь во время сеанса групповой психотерапии) - не напишешь. Странные люди, как и зачем они живут, я себе не представляю. Но от них спасает выделенное звукоизолированное пространство для их сеансов групповой психотерапии. Или наличие места с высокой степенью звукоизоляции, куда самому можно от них укрыться.
Производительность программиста-экстраверта вообще сомнительна. Не видел ни одного нормального и опытного, который не заглушал бы в себе экстраверта для программирования и придумывания идей.
> Третье, и самое важное, я настаивал на нахождении решений моими коллегами самостоятельно. В процессе обсуждения проблем я старался не указывать на решение, а спрашивать, куда надо смотреть, чтобы самому отыскать решение.
Вот это было очень круто. Я сам грешил микроменеджментом, когда был начальником и ожидал, что в мои дела будут залезать хотя бы даже из любопытства. И был очень удивлен, что ты не говоришь, что тут надо бы так, а тут сяк. Было даже немного обидно: "вот как надо, а, дурак, столько времени на ерунду потратил" )
Правда с этой перенавороченной стековой машиной меня стоило бы остановить.
Хочется спросить, как вы относитесь к код-ревью в целом и в частности к контролю за наименованием сущностей в коде? Ну, в том смысле чтоб всё называлось логично и про то, про что оно на самом деле написано.
С одной стороны лезть к человеку "переименуй тут, переназови там" - это как бы уже "микроменеджмент" которого стоило бы избегать, с другой - ситуация, когда в коде бардак с наименованием всякого сильно замедляет работу, по моим наблюдениям. При этом названия-то вроде бы все осмысленные (не i, j, z, x), но в силу того, что код много менялся разными людьми и за наименованиями не следили - много где названия не соответствуют логике. В итоге имеем ситуацию, когда казалось бы "все слова знакомые", но когда эти слова складываешь в голове в картинку - получается Пикассо. А если разобраться во всех нюансах, выходит что на самом деле-то всё написано плюс-минус терпимо, просто называется неправильно - но на этом "разобраться" теряется драгоценное время.
Comments 23
И пост отнюдь не дурацкий.
Reply
Как это отразилось на мифическом bus factor?
Reply
В самом сложном компоненте системы было чрезвычайно трудно разобраться.
Reply
(ответственый за ядро симуляции VHDL уволился после того, как прочитал и понял главу про локально и глобально статические значения; стандарты уровня VHDL это страшная сила)
Reply
Если бы не java для frontend-а, то можно было использовать часть имеющегося кода, а в итоге получился какой-то крокодил.
Reply
С экстравертами дело сложнее. У них мысль приходит тогда и только тогда, когда они что-то обсуждают с коллегами. Начальник здесь, в принципе, может помочь, но только если он компетентен.
Reply
Или включает музыку или что ещё делает.
Но не мешает находиться "в потоке" остальным членам коллектива.
Reply
У них просто мысль по-другому работает. Не расскажешь (не обсудишь во время сеанса групповой психотерапии) - не напишешь. Странные люди, как и зачем они живут, я себе не представляю. Но от них спасает выделенное звукоизолированное пространство для их сеансов групповой психотерапии.
Или наличие места с высокой степенью звукоизоляции, куда самому можно от них укрыться.
Reply
Поэтому я смело вычеркну их из рассмотрения.
Reply
Вот это было очень круто. Я сам грешил микроменеджментом, когда был начальником и ожидал, что в мои дела будут залезать хотя бы даже из любопытства. И был очень удивлен, что ты не говоришь, что тут надо бы так, а тут сяк. Было даже немного обидно: "вот как надо, а, дурак, столько времени на ерунду потратил" )
Правда с этой перенавороченной стековой машиной меня стоило бы остановить.
Reply
Поэтому у меня сейчас типизированные комбинаторы (умные конструкторы) и простые данные внутри.
Reply
Хочется спросить, как вы относитесь к код-ревью в целом и в частности к контролю за наименованием сущностей в коде?
Ну, в том смысле чтоб всё называлось логично и про то, про что оно на самом деле написано.
С одной стороны лезть к человеку "переименуй тут, переназови там" - это как бы уже "микроменеджмент" которого стоило бы избегать, с другой - ситуация, когда в коде бардак с наименованием всякого сильно замедляет работу, по моим наблюдениям. При этом названия-то вроде бы все осмысленные (не i, j, z, x), но в силу того, что код много менялся разными людьми и за наименованиями не следили - много где названия не соответствуют логике. В итоге имеем ситуацию, когда казалось бы "все слова знакомые", но когда эти слова складываешь в голове в картинку - получается Пикассо. А если разобраться во всех нюансах, выходит что на самом деле-то всё написано плюс-минус терпимо, просто называется неправильно - но на этом "разобраться" теряется драгоценное время.
Reply
Reply
Reply
Reply
Leave a comment