Здравствуйте, 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. Если же нет узкой специализации, то появляется возможность всей командой сфокусированно разрабатывать одну самую высокоприоритетную фичу и быстро отправить её в продакшен.
