Часто слышу на митингах код писал ВАся, в нем ничего не понятно, будет лучше если ВАся сам посмотрит.
От 25% программистов такое слышу. Причем ребята неплохие, кто жалуется
И может действительно код ВАси плох, но хочется решения проблем а не перекладывания
Что посоветуете?
Здравствуйте, merge, Вы писали:
M>Часто слышу на митингах код писал ВАся, в нем ничего не понятно, будет лучше если ВАся сам посмотрит.
Я тоже всегда так говорю, потому что догадываюсь, что скорее всего наставлю костылей вместо нормального решения, т.к. не знаю особенностей кода. Вероятность что автор кода реализует ту же самую функциональность более грамотно и быстрее, намного выше. Но а если Вася уже далеко, да, тут уже не отвертишься, изучаешь код и архитектуру, и добавляешь свои костыли
Здравствуйте, merge, Вы писали:
M>Часто слышу на митингах код писал ВАся, в нем ничего не понятно, будет лучше если ВАся сам посмотрит. M>От 25% программистов такое слышу. Причем ребята неплохие, кто жалуется M>И может действительно код ВАси плох, но хочется решения проблем а не перекладывания M>Что посоветуете?
Ну да, промышленный код должен не просто решать задачу, но быть понятным и поддерживаемым. Код нужно писать так, чтобы он соответствовал принципу наименьшего удивления. Другими словами, код должен быть отчуждаемым. Не должен содержать черной магии и тайных знаний (если без тайных знаний не обойтись, то нужно писать пояснения в комментариях, т.е. код должен писаться так, чтобы мидл смог его поддерживать с адекватным уровнем усилий). Третьими словами, код должен соответствовать практикам типа Clean code Стива Макконнела, Роберта Мартина, принципам рефакторинга Мартина Фаулера — по всем трем есть соотв.книги, где все эти принципы описаны. Вдобавок, нужно соблюдать общеизвестные DRY, KISS, SOLID, использовать паттерны вместо велосипедов. Все эти книги должны быть в наличии у каждого члена команды в быстром доступе, чтобы в процессе работы быстро их открывать, иначе никто читать их не будет, ведь в запарке при работе над текущей задачей у разраба нет ни сил ни желания искать эти книги. Поэтому тут спасет например программа быстрого поиска и открытия и файлов, типа Farr. На корпоративной вики должен быть манифест с явным и четким описанием этих принципов, каждый член команды должен быть согласен с ними (чтобы не пришлось уже в процессе работы постоянно кому-то из них доказывать, чем SOLID, Clean code или паттерны лучше велосипедов). Есть определенная категория программистов, которая либо не признает эти принципы, либо считает что соблюдать их необязательно, приводят свои доводы, они в некоторых случаях могут быть верны — например при разработке жестких highload-систем, или встраиваемых систем, и т.д, т.е. там где ограничения по перформансу, по размеру или по другим факторам приводят к тому, что код нужно писать в угоду этим факторам, а не в угоду clean code. Но даже там можно применять многие практики из Clean code. Если берете такого программиста в команду (ну а понять отношение программиста к этим практикам призвано собеседование), будьте готовы к такого рода рискам и трате времени на постоянные дискуссии по любому комменту в код ревью. Не говорю что это плохо, скорее полезно, но это издержки на ваши силы и на затраченное время. Далее, нужно явно внедрять культуру разработки, т.е. в процессе код ревью постоянно проверять весь код на соответствие этим принципам, заниматься евангелизмом, т.е. проводить обучение и всем повсюду тыкать в лицо этими книгами и принципами, включая менеджеров, показывать и доказывать зачем они нужны, к каким эффектам приводят и как на дистанции упрощают разработку и сопровождение кода. Если не следить на код ревью за их соблюдением, то даже разрабы, которые эти книги читали, скорее всего не будут их соблюдать. Не потому, что они такие плохие, а потому что у разраба свои сроки сдачи задачи и он поглощен решением проблемы, а не соблюдением этих принципов; и первая версия сдаваемого кода по задаче — это часто наслоение в коде результатов инженерного поиска (читай "слеплено из говна и палок"), и чтобы привести решение к промышленному виду, нужно еще потратить доп. усилия, ведь с нуля clean code никто не пишет, код растет "из сора", как и стихи, и задача код ревью и этих практик — убрать весь этот сор. Поэтому для код ревью нужен именно взгляд со стороны, от человека, который эти приницпы и сам применял, умеет видеть в коде их нарушения и предлагать конкретные улучшения, как именно нужно исправить код чтобы он стал соответствовать этим принципам, т.е. любое замечание по коде ревью должно указывать на конкретные нарушения конкретных принципов (замечания типа "тут код плохой. переделай как-нибудь по-другому" не годятся, нужны конкретные замечания типа "функция нарушает стандартные унарные формы, что приводит к плохо понимаемому и плохо поддерживаемому коду, см.книгу мартина clean code стр.XX, исправь — приведи к любой стандартной унарной форме"), и если автор кода не знаком с ними, то также указывать на источник принципа (книга и страница, название принципа) и на то, как именно нужно сделать исправление; по мере накопления опыта разрабы сами начнут эти принципы применять, и в коде ревью будет достаточно просто указывать на факт нарушения принципа, без детальных пояснений.
Подытоживая: тебе нужно либо самому вводить культуру разработки (если ты знаком с этими практиками), либо искать евангелиста их знающего и умеющего, который займется внедрением культуры разработки в команде, а также убедить менеджеров в необходимости этой культуры (а это отдельный вопрос, если вкраце, нужно по каждой практике уметь показать на цифрах, как это улучшает показатели, например как принцип O из SOLID уменьшает вероятность регрессионных багов, а это уже механизм, который менеджеры поймут и могут контролировать, это реально хороший и конкретный ответ на вопрос "как снизить вероятность регрессионных багов"; или если видишь какую-то издержку из-за плохого кода, просто высчитай потери на неё, затем укажи что если бы применялась определенная практика, этой издержки бы не было — как пример, из-за непонятного наименования каких-то переменных другой программист неправильно написал код, и пока все разобрались и всё исправили, потратили столько-то часов (или даже дней — бывает и такое), а если бы были конвенции по понятному нэймингу согласно clean code, то эту проблему отловили бы ешё на этапе код ревью — и с такими примерами нужно идти к менеджерам, это ответы на вопрос "какие ваши доказательства" для внедрения этих практик).
Здравствуйте, merge, Вы писали:
M>Часто слышу на митингах код писал ВАся, в нем ничего не понятно, будет лучше если ВАся сам посмотрит. M>От 25% программистов такое слышу. Причем ребята неплохие, кто жалуется M>И может действительно код ВАси плох, но хочется решения проблем а не перекладывания M>Что посоветуете?
Вообще ребята может даже и правы.
Обычно автор кода может его поменять быстрее и лучше, в этом нет ничего удивительного.
Вообще у вас ревью кода есть? Если нет, можно ввести.
В смысле, чтобы рядовые программисты (не тимлид) апрувили пул реквесты своих коллег.
Чтобы хотя бы были в курсе, что другие там вообще пишут.
Чтобы не относились к этому спустя рукава (ревью в духе "Вася, кликни там апрув, плиз"),
можно периодически смотреть самому например и делать большие глаза в духе "боже, кто мог заапрувить этот ужас?"
Здравствуйте, bnk, Вы писали:
bnk>Вообще у вас ревью кода есть? Если нет, можно ввести. bnk>В смысле, чтобы рядовые программисты (не тимлид) апрувили пул реквесты своих коллег. bnk>Чтобы хотя бы были в курсе, что другие там вообще пишут.
Хе, это работает, пока все занимаются одинаковыми задачами. А если один солверы пишет, другой с геометрией работает, третий — шейдеры, четвертый — веб морду...
Как тут провести осмысленное ревью? Максимум — докопаться до оформления кода.
_____________________
С уважением,
Stanislav V. Zudin
Здравствуйте, Stanislav V. Zudin, Вы писали:
SVZ>Хе, это работает, пока все занимаются одинаковыми задачами. А если один солверы пишет, другой с геометрией работает, третий — шейдеры, четвертый — веб морду... SVZ>Как тут провести осмысленное ревью? Максимум — докопаться до оформления кода.
Ну изначальная постановка задачи в данном конкретном случае как бы подразумевает, что Вася сможет написать то же, что и Петя, просто стесняется.
Если Вася не сможет, то постановка вопроса вроде как вообще бессмысленная, мышка ежиком никак не станет.
Умение читать и понимать чужой код стоит в два раза больше, чем умение писать свой. И вообще встречается настолько редко, что крупные корпорации даже не пытаются тестировать наличие такого навыка (см. вопросы на собеседовании).
А если код еще и написан плохо, да к тому же без тестов, да еще и opinionated, — вносить в такой код изменения сродни высшему пилотажу.
Здравствуйте, merge, Вы писали:
M>Часто слышу на митингах код писал ВАся, в нем ничего не понятно, будет лучше если ВАся сам посмотрит. M>От 25% программистов такое слышу. Причем ребята неплохие, кто жалуется M>И может действительно код ВАси плох, но хочется решения проблем а не перекладывания M>Что посоветуете?
1. Парное программирование повышает число людей, знакомых с определённым кодом. Как минимум их уже двое.
2. Сделать постоянную ротацию, не должно быть "владельцев" кода, люди должны постоянно "трогать" разные части проекта.
Но надо понимать, что первый пункт подходит не всем программистам, очень многим комфортней работать в одиночку. Также есть вероятность, что снизится производительность команды (хотя не факт). А второй пункт однозначно снизит производительность команды, причём ощутимо.
Здравствуйте, vsb, Вы писали:
vsb>Но надо понимать, что первый пункт подходит не всем программистам, очень многим комфортней работать в одиночку. Также есть вероятность, что снизится производительность команды (хотя не факт). А второй пункт однозначно снизит производительность команды, причём ощутимо.
И поставит верхнюю планку достижимой сложности по уровню компетентности самого слабого участника.
Что может быть и хорошо, впрочем, в зависимости от решаемых задач.
Здравствуйте, Stanislav V. Zudin, Вы писали:
SVZ>Хе, это работает, пока все занимаются одинаковыми задачами. А если один солверы пишет, другой с геометрией работает, третий — шейдеры, четвертый — веб морду... SVZ>Как тут провести осмысленное ревью? Максимум — докопаться до оформления кода.
Поддерживаемость кода не особо зависит от того солверы ли это или веб-морда.
Ну и безотносительно ревью — если у вас задачи разработчиков настолько сильно изолированы, то у вас большая проблема. Уход любого из разработчиков остановит проект.
Здравствуйте, vsb, Вы писали:
vsb>2. Сделать постоянную ротацию, не должно быть "владельцев" кода, люди должны постоянно "трогать" разные части проекта. vsb>А второй пункт однозначно снизит производительность команды, причём ощутимо.
Практика показывает, что на длинных дистанциях он наоборот повышает производительность. Потому что улучшает понимание проекта в целом и снижает риск выгорания.
НС>Ну и безотносительно ревью — если у вас задачи разработчиков настолько сильно изолированы, то у вас большая проблема. Уход любого из разработчиков остановит проект.
Разделение труда-с.
С одной стороны удобно. А с другой, как ты верно заметил, каждый сотрудник на вес золота.
Но это, похоже, свойство любой компании, занятой в наукоёмких разработках. Я с этим сталкивался даже в очень крупных и богатых компаниях.
_____________________
С уважением,
Stanislav V. Zudin
Здравствуйте, Stanislav V. Zudin, Вы писали:
SVZ>Здравствуйте, Ночной Смотрящий, Вы писали:
НС>>Ну и безотносительно ревью — если у вас задачи разработчиков настолько сильно изолированы, то у вас большая проблема. Уход любого из разработчиков остановит проект.
SVZ>Разделение труда-с.
А если посмотреть дальше этого? Как ваши люди ходят в отпуск — со звонками "ах, у нас тут сломалось, включи ноут"? Как растут сотрудники, если каждый специалист в узкой ниши и дальше своей ниши ничего не знает? Как может развиваться процесс в целом, если никто не челенджит не только качество, но и вероятно архитектуру, безопасность кода и т.д., потому что никто не знает, что делает другой? SVZ>С одной стороны удобно. А с другой, как ты верно заметил, каждый сотрудник на вес золота.
Но и уход сотрудника стоит дорого, т.к. если искать надо срочно, потому что внутренней замены очевидно нет, это часто влечет за собой дополнительные расходы (реклама вакансии, рекрутинговые агентства, оплата ваше рынка, чтобы ваш оффер точно приняли). Оно вам надо? SVZ>Но это, похоже, свойство любой компании, занятой в наукоёмких разработках. Я с этим сталкивался даже в очень крупных и богатых компаниях.
Дело не в богатстве компании, а в том умеет ли конкретный менеджер (+PM) оценивать риски и перспективу. Есть такие, которые начинают решать проблему только в момент ее наступления.
Здравствуйте, Milena, Вы писали:
SVZ>>Разделение труда-с. M>А если посмотреть дальше этого? Как ваши люди ходят в отпуск — со звонками "ах, у нас тут сломалось, включи ноут"? Как растут сотрудники, если каждый специалист в узкой ниши и дальше своей ниши ничего не знает? Как может развиваться процесс в целом, если никто не челенджит не только качество, но и вероятно архитектуру, безопасность кода и т.д., потому что никто не знает, что делает другой?
Люди уходят в отпуск как обычно.
Две недели любая проблема может обождать.
Насчёт роста... в своей нише расти можно бесконечно. У нас в компании только один разработчик без ученой степени. мне вот некогда писать статьи, а шеф регулярно публикует. Иногда совместно с пользователями. Такой вот косвенный маркетинг.
Что такое "челенджить качество и архитектуру" я не очень понимаю. Либо все хорошо — код работает и позволяет расширять функционал, либо нет. Если нет, значит с архитектурой что-то не то.
Вот так вот просто и незатейливо.
В целом продукт состоит из нескольких подсистем и уж на стыках всегда можно всё обточить. А уж внутреннее устройство системы — ответственность ответственного за эту систему и незачем туда лезть с лохматыми лапами.
SVZ>>С одной стороны удобно. А с другой, как ты верно заметил, каждый сотрудник на вес золота. M>Но и уход сотрудника стоит дорого, т.к. если искать надо срочно, потому что внутренней замены очевидно нет, это часто влечет за собой дополнительные расходы (реклама вакансии, рекрутинговые агентства, оплата ваше рынка, чтобы ваш оффер точно приняли). Оно вам надо? SVZ>>Но это, похоже, свойство любой компании, занятой в наукоёмких разработках. Я с этим сталкивался даже в очень крупных и богатых компаниях. M>Дело не в богатстве компании, а в том умеет ли конкретный менеджер (+PM) оценивать риски и перспективу. Есть такие, которые начинают решать проблему только в момент ее наступления.
В отрасли, в которой я работаю, всех спецов знают поименно. Причем, со всей предысторией — в какой компании работал и что он там разрабатывал.
Периодически спецы мигрируют из компании в компанию, запускают свои стартапы. Иногда можно поймать и сманить к себе. Либо надо брать студента и выращивать под себя.
Другими словами, это штучный товар. Поэтому набрать пучок про запас, даже за любые деньги, не получится.
_____________________
С уважением,
Stanislav V. Zudin
НС>Практика показывает, что на длинных дистанциях он наоборот повышает производительность. Потому что улучшает понимание проекта в целом и снижает риск выгорания.
Вот только заранее неизвестно, будут ли эти "длинные дистанции" вообще существовать.
"Парадокс стартапов": на начальных этапах надо пилить как угодно, лишь бы быстрее (тут уж не до "понимания проекта", успеть бы до конкурентов). При таком варианте накопление техдолга идет так быстро, что стартап может и не успеть получать финансирование с той же скоростью, с какой требуется брать больше и больше неэффективных (в силу техдолга) инженеров.
Вот и получается гадание на кофейной гуще, что лучше: быстрее сейчас (а то "потом" может и не настать), или менее рисково потом. Обычно выбирают первое, ибо риск краткосрочный, в отличие от.
SVZ>Другими словами, это штучный товар. Поэтому набрать пучок про запас, даже за любые деньги, не получится.
Вот поэтому Milena (видимо, работающая в одном из т.н. "гигантов") вас и не понимает. В больших корпорациях "штучный товар" === риск === плохо. Да, один штучный инженер может сделать решение, скажем, за $10m, которому требуется на поддержку 1-2 человека и $2m в год. В больших компаниях на такой же проект будет нанято 10-15, стоить это будет $100m, и поддержка обойдется в $20m.
Но в реальности же получится так: "штучный инженер" возьмет на себя риски создания стартапа, доказательства жизнеспособности идеи, а потом "технологический гигант" просто купит стартап за $50m (вместо разработки своего за $100m).
Вот так risk management и работает, и вот потому-то крупные компании и пылесосят стартапы (исключая недружественные поглощения).
Здравствуйте, merge, Вы писали:
M>И может действительно код ВАси плох, но хочется решения проблем а не перекладывания M>Что посоветуете?
Помнить, что человек это в первую очередь биологическое существо.
Считается, что человек думает мозгом. Мозг взрослого человека потребляет
более 25% всей энергии.
Когда человеку требуется интенсивно думать,
у него даже может заболеть голова от напряжения.
В противоположность этому, когда человек не думает у него вырабатываются гормоны удовольствия.
Таким образом нежелание разбираться с чужим(да и своим кодом) естественно.
Единицы занимаются извращениями пытаясь понять код.
Остальные предпочитают задать вопрос на форуме и расслабиться получая очередную порцию удовольствия.
Здравствуйте, SkyDance, Вы писали:
SD>Вот только заранее неизвестно, будут ли эти "длинные дистанции" вообще существовать.
Иногда нет, иногда да. Не все компании/проекты это стартапы.
SD>"Парадокс стартапов": на начальных этапах надо пилить как угодно, лишь бы быстрее (тут уж не до "понимания проекта", успеть бы до конкурентов).
Ну вот у меня сейчас как раз такой проект. Месяца за три выкатили MVP, только вот потом настало время делать полноценный продукт, и до беты ушло больше года. Вполне достаточное время, чтобы назвать это длинной дистанцией — двоих у меня нагло переманили внутри компании, один сам ушел, не выдержав анархии стартапного проекта. И даже трех месяцев работы того что ушел хватило, чтобы мне до сих пор икалось когда дело касалось его участков кода. И это при том что у нас владение кодом по возможности совместное. А если я каждому позволю делянку свою окучивать — мы только и будем заниматься расхлебыванием чьего либо ухода.
НС>Иногда нет, иногда да. Не все компании/проекты это стартапы.
Сейчас большинство компаний старается эксплуатировать этот подход. Даже внутри большой компании очень жестко выделяют внутренние проекты. Изначально "спонсируют" только одного-двух работников для исследований, потом, если уже есть готовый годный прототип, могут еще дать времени или ресурсов. Но если не выходит, то довольно быстро сворачивают. Я бы сказал так, год — это максимальный срок в течение которого может не быть production grade кода, и внедрения.
НС>Ну вот у меня сейчас как раз такой проект. Месяца за три выкатили MVP, только вот потом настало время делать полноценный продукт, и до беты ушло больше года. Вполне достаточное время, чтобы назвать это длинной дистанцией — двоих у меня нагло переманили внутри компании, один сам ушел, не выдержав анархии стартапного проекта. И даже трех месяцев работы того что ушел хватило, чтобы мне до сих пор икалось когда дело касалось его участков кода. И это при том что у нас владение кодом по возможности совместное. А если я каждому позволю делянку свою окучивать — мы только и будем заниматься расхлебыванием чьего либо ухода.
По-моему, ты сейчас как раз подтвердил все то, что я писал выше. Сначала — "лишь бы взлетело" (MVP). Потом у вас удалось получить сразу большую инвестицию (больше года). Это риск, на который многие компании не готовы идти даже с наличием прототипа. Разве что вы каждые 3-6 месяцев будете демонстрировать очередную улучшеную версию MVP ("incremental value", будь он неладен).
В общем, в больших софтостроительных компаниях настоящий research — редкость, и зачастую тоже не то чтоб высокооплачиваемая работа. И в плане известности исследователи тоже мало что получат.
Здравствуйте, SkyDance, Вы писали:
НС>>Иногда нет, иногда да. Не все компании/проекты это стартапы. SD>Сейчас большинство компаний старается эксплуатировать этот подход.
Есть статистика?
SD>По-моему, ты сейчас как раз подтвердил все то, что я писал выше.
Разве?
SD> Сначала — "лишь бы взлетело" (MVP). Потом у вас удалось получить сразу большую инвестицию (больше года).
И? Проект по прежнему остался чем то вроде стартапа.
SD> Это риск, на который многие компании не готовы идти даже с наличием прототипа.
Кто то не готов, кто то готов. Чего всех под одну шконку загонять?
Здравствуйте, SkyDance, Вы писали:
SD>В общем, в больших софтостроительных компаниях настоящий research — редкость, и зачастую тоже не то чтоб высокооплачиваемая работа. И в плане известности исследователи тоже мало что получат.
А мс, гугл, фб -- это большие софтостроительные компании? Если нет, тогда ок, если да -- то там существует
свои research подразделения. У мс оно особенно мощное, вроде еще при Билли закладывалось.
У фб большой ai&ml research точно есть, иначе кто пишет pythorch?
У jetbrains что-то такое есть, Касперский свою ОС лабает. Вообще напрямую отдела может и не быть,
но вот запросто могут сотрудничать с вузами.
M>Часто слышу на митингах код писал ВАся, в нем ничего не понятно, будет лучше если ВАся сам посмотрит. M>От 25% программистов такое слышу. Причем ребята неплохие, кто жалуется M>И может действительно код ВАси плох, но хочется решения проблем а не перекладывания M>Что посоветуете?
Хочется решений проблем от кого?
Есть ли какой-то человек, ответственный за функциональность, в которой возникли проблемы? Если это не Вася (и не прямой начальник Васи, у которого Вася полностью в подчинении) — тогда поставить этому человеку задачу: вместе с Васей разберись в коде, чтобы ты был в курсе, как код устроен.
Или проблема возникла внезапно, и ее в авральном порядке приходится решать в отсутствие Васи? Тогда сказать "ну, да, согласен, было бы лучше, если бы Вася посмотрел, но Вася сейчас недоступен. В обшем, надо, Федя, надо."
Если же надо просто обеспечить резервирование Васиных компетенций — тогда поставить Васе задачу ввести в курс дела того, кто будет готов его подменить.
S>А мс, гугл, фб -- это большие софтостроительные компании? Если нет, тогда ок, если да -- то там существует S>свои research подразделения. У мс оно особенно мощное, вроде еще при Билли закладывалось. S>У фб большой ai&ml research точно есть, иначе кто пишет pythorch?
1. Настоящий research — когда не просто "допиливают pytorch", а работают над чем-то реально новым. Да, это редкость, очень небольшая часть компании (единицы, реально).
2. Обычно это не самая высокооплачиваемая работа, потому что считается высокорисковыми инвестициями.
Здравствуйте, SkyDance, Вы писали:
SD>2. Обычно это не самая высокооплачиваемая работа, потому что считается высокорисковыми инвестициями.
А вот это странно -- Ле Кунн или Лэмпорт (мс) будут работать за меньшие деньги чем какой-нибудь principal engineer?
Я думаю у них зарплаты сильно больше всех инженерных грейдов и, нравное, сопоставими с менеджерами.
У исследователей, скорее всего, точно такая же градация как и у инженеров, и, возможно, в среднем
они получают меньше, но вот именитые ученые по идее должны получать существенно больше. Это инвестиции
в будущее.
Здравствуйте, SkyDance, Вы писали:
SD>1. Настоящий research — когда не просто "допиливают pytorch", а работают над чем-то реально новым. Да, это редкость, очень небольшая часть компании (единицы, реально).
Но статистики при этом у тебя нет. Я вот подобные обобщенные утверждения не рискну выдавать, не обладая цифрами. А по опыту — в моей текущей компании такие люди есть и их много.
SD>2. Обычно это не самая высокооплачиваемая работа, потому что считается высокорисковыми инвестициями.
Опять же, в случае моей компании это не так. В случае МС — тоже. По зарплатам ресечеров в другимх компаниях у меня точных данных нет.
S>А вот это странно -- Ле Кунн или Лэмпорт (мс) будут работать за меньшие деньги чем какой-нибудь principal engineer? S>Я думаю у них зарплаты сильно больше всех инженерных грейдов и, нравное, сопоставими с менеджерами.
Отличное сравнение.
Во-первых, это уже "именитые" ученые.
Во-вторых, как много таких имен можно найти? Двое на компанию из 50,000 человек (что предполагает ~200 высокопоставленных менеджеров, у которых доходы будут еще выше). Соотношение явно не в пользу ученых.
В-третьих, когда говорят про research "с именем", зачастую там уже не так много от research, и куда больше про convince — убедить, что вот этот конкретный подход принесет компании доход. Такой вот leadership principle, — "неважно, прав ты или нет, важно лишь то, смог ли ты убедить других".
Поэтому я и не продолжаю тред "дай мне статистику и доказательства в цифрах". Потому что официальной, разумеется, нет, и быть не может. А неофициальную не докажешь. Поэтому спор может быть лишь на уровне "мое слово против твоего".
НС>Опять же, в случае моей компании это не так. В случае МС — тоже. По зарплатам ресечеров в другимх компаниях у меня точных данных нет.
Опять же, статистика есть только неофициальная. Менеджеров с высокими доходами значительно больше, чем ученых. И чем выше уровень, тем больше разрыв. В крупных компаниях ученых с мировыми именами — единицы, менеджеров с аналогичными доходами — сотни.
Здравствуйте, SkyDance, Вы писали:
S>>А вот это странно -- Ле Кунн или Лэмпорт (мс) будут работать за меньшие деньги чем какой-нибудь principal engineer? S>>Я думаю у них зарплаты сильно больше всех инженерных грейдов и, нравное, сопоставими с менеджерами.
SD>Отличное сравнение. SD>Во-первых, это уже "именитые" ученые. SD>Во-вторых, как много таких имен можно найти? Двое на компанию из 50,000 человек (что предполагает ~200 высокопоставленных менеджеров, у которых доходы будут еще выше). Соотношение явно не в пользу ученых.
Я думаю, что минимум с десяток, а может и под 100. Во всяком случае у мс. Лэмпорт просто попал в струю с Paxos и TLA.
Полно людей которые занимаются также нетривиальными вещами, но пока не очень в мейнстриме прижились. Так что не двое.
Сравнивать с со всеми менеджерами действительно не очень корректно. Некоторые руководители направлений сами по себе
миллиардеры.
SD>В-третьих, когда говорят про research "с именем", зачастую там уже не так много от research, и куда больше про convince — убедить, что вот этот конкретный подход принесет компании доход. Такой вот leadership principle, — "неважно, прав ты или нет, важно лишь то, смог ли ты убедить других".
Без понятия какие тут метрики. Но кажется, что про доход не очень задумываются, скорее про PoC, что это реализуемо.
А про TTM и доход должны думать соотв. менеджеры. Т.е. то, чем сейчас занимаются ученые, будет востребовано в индустрии через >5-10 лет.
S>Я думаю, что минимум с десяток, а может и под 100 <...> Сравнивать с со всеми менеджерами действительно не очень корректно
Теперь можно вернуться с первоначальному утверждению: SD>В общем, в больших софтостроительных компаниях настоящий research — редкость, и зачастую тоже не то чтоб высокооплачиваемая работа. И в плане известности исследователи тоже мало что получат.
Надеюсь, теперь понятнее, что я имел в виду. Да, конечно, в некоторых компаниях могут быть research отделы. Но это редкость, и оплачивается, как правило, ниже, чем исполнительные должности.
S>А про TTM и доход должны думать соотв. менеджеры. Т.е. то, чем сейчас занимаются ученые, будет востребовано в индустрии через >5-10 лет.
В этом-то и состоит риск. Долгосрочное планирование исследований, которые могут быть (а могут и не быть) будут востребованы через 5 лет. К тому времени ишак уже, да и падишах тоже. Это риск, который очень сложно "продать". Современнные тенденции направлены на снижение таких рисков. Вплоть до их минимизации путем форсирования краткосрочных целей — см. agile, scrum и аналогичные методологии с короткими итерациями.
Развивая мысль дальше, это характерный тренд для человечества. Все менее длинный attention span. Быстрая потеря интереса, требование постоянной стимуляции — даже мелочами. Выпуском "инкрементальных апдейтов", созданием коротких видеороликов и т.п.. Конечно, можно приводить контр-примеры вроде миссии на Марсе. Но и такая проекты тоже обречены на "ускорение" (зачастую мнимое, путем разделения на крошечные фрагменты выдачи очередных "апдейтов").
Не знаю, как вам, но мне это видится просто новой реальностью. Постоянная стимуляция мозга "новым", exciting, amazing, и т.п.. Интересно было бы найти реальную (или даже официальную) статистику по диагностике СДВГ (ADHD). Который, как мне кажется, есть не что иное как адаптация мозга к постоянной гипер-стимуляции.
Здравствуйте, merge, Вы писали:
M>Что посоветуете?
Посоветую командное владение кодом через:
1) Совместную декомпозицию, когда все участвуют в декомпозиции задачи
2) Мелкую декомпозицию, когда задача распиливается на маленькие подзадачки длительностью максимум день. А не так, что Вася уходит в себя на месяц, ваяет за это время супер-систему с тоннной кода, в котором потом никто не может разобраться.
3) Нужно учиться декомпозировать так, чтобы задачки можно было выполнять параллельно
4) Peer code review, когда все проводят ревью всех
5) Как результат предыдущих пунктов — сфокусированная разработка, когда вся команда целиком в один момент времени разрабатывает только одну фичу
Схема имеет массу плюсов, один из которых — это командное владение кодом
Здравствуйте, Stanislav V. Zudin, Вы писали:
SVZ>С одной стороны удобно. А с другой, как ты верно заметил, каждый сотрудник на вес золота. SVZ>Но это, похоже, свойство любой компании, занятой в наукоёмких разработках. Я с этим сталкивался даже в очень крупных и богатых компаниях.
Басфактор — это только одна из проблем, причем имхо не самая серьезная. Гораздо хуже, что при такой узкой специализации у вас всегда кто-то перегружен и делает абы-как, и одновременно с ним кто-то недогружен и делает абы-что. "Абы-как" и "абы-что" убивают любой проект.
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>Практика показывает, что на длинных дистанциях он наоборот повышает производительность. Потому что улучшает понимание проекта в целом и снижает риск выгорания.
Он не только на длинных дистанциях повышает производительность, но и на коротких. Потому что производительность важна не сама по себе, а только тогда, когда она прикладывается к наиболее высокоприоритетной задаче. Банальная теория ограничений — имеет значение только производительность бутылочного горлышка. Производительность остальных частей, которые не являются бутылочным горлышком никакой роли не играет. При этом если у тебя более-менее сбалансированная по компетенциям команда, то бутылочное горлышко каждый раз будет в новом месте, в зависимости от задачи. То есть, например, одна задача требует больше UI кода, другая больше backend кода и т.д. При этом если у теюя узкая специализация команды, то остается только два варианта: либо загружать бутылочное горлышко на 100%, а остальные в это время будут "плевать в потолок", либо брать в параллель дополнительные более низкоприоритетные задачи, чтобы недозагруженные разработчики не маялись от безделия. Оба варианта по своему плохи и оба увеличивают TTM и Lead Time. Если же нет узкой специализации, то появляется возможность всей командой сфокусированно разрабатывать одну самую высокоприоритетную фичу и быстро отправить её в продакшен.
