Собчак о женщинах Силиконовый долины

[mavr]

На счет необходимости много пахать. Если надо мого пахать в чем проблема нанять в 2 раза больше людей и они будут пахать больше. Это же владельцу надо вывести продукт на рынок, а мне надо больше денег заработать не перетруждаясь.

Да, над таким вопросом тоже голову ломаю. Тут же в штатах ещё как, нередко мало просто делать свою работу качественно. Надо ещё как то влиять на остальных. Например недавно менеджер команды на интервью сказал, что ему на перформанс ревью надо, чтобы о человеке отлично отзывались другие, желательно из других команд. Люди, которые просто хорошо делают свою работу, у них долго не задерживаются, этого мало.

Это-то как раз очень просто. Когда ты просто делаешь свою работу, ты приносишь 1х пользы. Когда ты вдохновишь/отучишь 10 человек, ты уже приносишь 10х+ пользы

Засчитав себе 10х+ от работы других людей вы либо уже считаете совсем другую пользу, либо присваиваете себе чужую пользу, либо считаете одну и ту же пользу много раз по кругу.

[Херовимчик]

На счет необходимости много пахать. Если надо мого пахать в чем проблема нанять в 2 раза больше людей и они будут пахать больше. Это же владельцу надо вывести продукт на рынок, а мне надо больше денег заработать не перетруждаясь.

Да, над таким вопросом тоже голову ломаю. Тут же в штатах ещё как, нередко мало просто делать свою работу качественно. Надо ещё как то влиять на остальных. Например недавно менеджер команды на интервью сказал, что ему на перформанс ревью надо, чтобы о человеке отлично отзывались другие, желательно из других команд. Люди, которые просто хорошо делают свою работу, у них долго не задерживаются, этого мало.

Это-то как раз очень просто. Когда ты просто делаешь свою работу, ты приносишь 1х пользы. Когда ты вдохновишь/отучишь 10 человек, ты уже приносишь 10х+ пользы

Засчитав себе 10х+ от работы других людей вы либо уже считаете совсем другую пользу, либо присваиваете себе чужую пользу, либо считаете одну и ту же пользу много раз по кругу.

Разверните пожалуйста мысль

[xrundel]

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

Ну да, поэтому с людьми всегда необходимо работать с 2-х сторон одновременно. Разумно доверять но и разумно не доверять.

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

Но без контроля всё мгновенно скатывается в 4 часовой рабочий день из дома. Поэтому жестокий контроль над продуктивностью, созвоны утром и вечером, локи и увольнения когда продуктивность падает.

Нельзя, нельзя делать только что-то одно - это верный способ убить компанию. Поэтому отсеваются ленивые или излишне креативные или очень уж свободолюбивые. Отсееваются те кто не тянет. Всегда отсеиваются агрессивные и токсичные. А остаётся очень даже отличный сегмент с которыми мы очень хорошо находим общий язык.

[nyekimov]

На счет необходимости много пахать. Если надо мого пахать в чем проблема нанять в 2 раза больше людей и они будут пахать больше. Это же владельцу надо вывести продукт на рынок, а мне надо больше денег заработать не перетруждаясь.

Да, над таким вопросом тоже голову ломаю. Тут же в штатах ещё как, нередко мало просто делать свою работу качественно. Надо ещё как то влиять на остальных. Например недавно менеджер команды на интервью сказал, что ему на перформанс ревью надо, чтобы о человеке отлично отзывались другие, желательно из других команд. Люди, которые просто хорошо делают свою работу, у них долго не задерживаются, этого мало.

Это-то как раз очень просто. Когда ты просто делаешь свою работу, ты приносишь 1х пользы. Когда ты вдохновишь/отучишь 10 человек, ты уже приносишь 10х+ пользы

Засчитав себе 10х+ от работы других людей вы либо уже считаете совсем другую пользу, либо присваиваете себе чужую пользу, либо считаете одну и ту же пользу много раз по кругу.

Разверните пожалуйста мысль

А я с ним согласен.

Посадили значит меня один раз парным программированием заниматься. Дали слабого инженера, чтобы он у меня учился. А я привык писать код быстро, не обращая внимания на знаки препинания и затем как закончу мысль, расставлять пропущенные знаки, может даже с помощью компилятора и тулов IDE, которые все подсветят. Как у многих авторов есть корректоры. Так этот слабый инженер стал меня сбивать и указывать на пропущенные точки с запятыми. А потом ещё долго вспоминал, как он «помог» и удивлялся. Что такой важный эксперимент резко прекратили. Ну естественно я сказал хватит руководству.

И нередко вижу проблему того, что подобные товарищи бегут «помогать» и «спасать мир», решая несуществующие проблемы. А если сюда ещё приставить «эффективный менеджмент», то получается как когда то на выборах. 146% за. Перестарались.

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

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

[Херовимчик]

Давайте все же разделять идею/подход от частных (неудачных) способов исполнения.
Это вполне известный факт, что производительность хорошей команды в разы превышает сумме производительности каждого члена команды. Взять Хрюнделя - у него нет слаженной команды, каждый сам за себя и производительность меняется на индивидуальном уровне. Прибытие или убытия бойца он влияет на производительность остальных членов команды.
Отдельные случаи неудачного парного программирования тоже сложно натягивать на подход в целом. Первый блин может быть комом, не все люди «кликают» друг с другом и т.д. Это тоже нужно делать с умом, а не брать первого попавшегося джуна и айда его учить (это кстати к менторству мало имеет отношение, менторы это вообще о другом).
Всем известный multiplier или 10х инженер, условно, не закрывает в 10 раз больше тикетов чем его коллега. Сеньор инжинер грамотно менторит джуниоров (так чтобы они росли и учились думать, а не просто как мартышки поворяли), задает тон для других Сеньоров (хорошее сопровождение кода, юнит тесты, да хоть комментарии в коде!), вкладывается в тулы для всей команды. Да даже банальный рефакторинг освободит кучу ресурсов у всей команды. По отдельности это все мелочи, но из каждой мелочи складываемся та самая engineering culture в команде. И когда в неё вкладываются толковые люди, производительность вырастает у всех

[Lisa]

Посадили значит меня один раз парным программированием заниматься. Дали слабого инженера, чтобы он у меня учился. А я привык писать код быстро, не обращая внимания на знаки препинания и затем как закончу мысль, расставлять пропущенные знаки, может даже с помощью компилятора и тулов IDE, которые все подсветят. Как у многих авторов есть корректоры. Так этот слабый инженер стал меня сбивать и указывать на пропущенные точки с запятыми. А потом ещё долго вспоминал, как он «помог» и удивлялся. Что такой важный эксперимент резко прекратили. Ну естественно я сказал хватит руководству.

А почему вы ему просто не объяснили про свой стиль работы? Это же несложно.

[kyk]

По отдельности это все мелочи, но из каждой мелочи складываемся та самая engineering culture в команде. И когда в неё вкладываются толковые люди, производительность вырастает у всех

и как такая идиллия возможно при капитализЬме, где человек-человеку волк, а сам капиталист мать родную продаст за 300% прибыли?

Где в этой картине мира хитрожопые индусы и Бубновые Валеты, работающие на 3х работах параллельно?

[idle0]

Тем более ты часть откровенной ерунды приписал, типа оплаты тестовых. Почти никто их не платит

Мы предлагаем заплатить тем кто хочет в России - где-то треть берёт деньги. В США обязательно все проходят продуктовый тест, платим $500.

А 2/3 в России на предложение денег говорят "спасибо, не надо"?

[Херовимчик]

По отдельности это все мелочи, но из каждой мелочи складываемся та самая engineering culture в команде. И когда в неё вкладываются толковые люди, производительность вырастает у всех

и как такая идиллия возможно при капитализЬме, где человек-человеку волк, а сам капиталист мать родную продаст за 300% прибыли?

Где в этой картине мира хитрожопые индусы и Бубновые Валеты, работающие на 3х работах параллельно?

Согласна, явление не частое, особенно в областях с низким порогом входа

[OtherSide]

Где в этой картине мира хитрожопые индусы и Бубновые Валеты, работающие на 3х работах параллельно?

Катаются на яхтах?

[nyekimov]

Посадили значит меня один раз парным программированием заниматься. Дали слабого инженера, чтобы он у меня учился. А я привык писать код быстро, не обращая внимания на знаки препинания и затем как закончу мысль, расставлять пропущенные знаки, может даже с помощью компилятора и тулов IDE, которые все подсветят. Как у многих авторов есть корректоры. Так этот слабый инженер стал меня сбивать и указывать на пропущенные точки с запятыми. А потом ещё долго вспоминал, как он «помог» и удивлялся. Что такой важный эксперимент резко прекратили. Ну естественно я сказал хватит руководству.

А почему вы ему просто не объяснили про свой стиль работы? Это же несложно.

Не все люди сразу понимают чужой подход. Он искренне считал, что учит меня чему то новому. Открывает мне новые горизонты.
Как в принципе большинство тех, кто раздаёт советы или лезет со своим уставом на чужую территорию.

Вообще я согласен с тем, что надо создавать такую культуру, которая будет сеять добро, взаимовыручку и взаимоуважение. Но также надо каким то образом находить грани, когда помощь имеет смысл, когда помощи ждут или человеку надо просто дать чуть больше времени подумать.

[nyekimov]

Давайте все же разделять идею/подход от частных (неудачных) способов исполнения.
Это вполне известный факт, что производительность хорошей команды в разы превышает сумме производительности каждого члена команды. Взять Хрюнделя - у него нет слаженной команды, каждый сам за себя и производительность меняется на индивидуальном уровне. Прибытие или убытия бойца он влияет на производительность остальных членов команды.
Отдельные случаи неудачного парного программирования тоже сложно натягивать на подход в целом. Первый блин может быть комом, не все люди «кликают» друг с другом и т.д. Это тоже нужно делать с умом, а не брать первого попавшегося джуна и айда его учить (это кстати к менторству мало имеет отношение, менторы это вообще о другом).
Всем известный multiplier или 10х инженер, условно, не закрывает в 10 раз больше тикетов чем его коллега. Сеньор инжинер грамотно менторит джуниоров (так чтобы они росли и учились думать, а не просто как мартышки поворяли), задает тон для других Сеньоров (хорошее сопровождение кода, юнит тесты, да хоть комментарии в коде!), вкладывается в тулы для всей команды. Да даже банальный рефакторинг освободит кучу ресурсов у всей команды. По отдельности это все мелочи, но из каждой мелочи складываемся та самая engineering culture в команде. И когда в неё вкладываются толковые люди, производительность вырастает у всех

Эх, ещё все бы менеджеры умели считать и понимать эти самые комменты в пул риквестах и прочие вещи.

Идея понятна. А исполнение всегда интересно посмотреть. Помнится и вы здесь спрашивали, как проходит pull request reviews у остальных.

Так что любой подход имеют и плюсы и минусы и сторонников и противников.

Прекрасно помню, как человек ушедший из гугла в нетфликс рассказывал, что для него это небо и земля. Мол в гугле на пул риквесте так мозг выносили и убивали любую инициативу, если не понимали ее. Ну и в коде мол муха не пролетит да. Но зато, говорил, в Нетфликсе его наняли как эксперта, дали продукт, и он там царь и бог. Сделал все по уму? Может потчевать на лаврах. Падает сервис? Будут фиксить с овертаймами, но чисто свои косяки.
Тут уже кому что, во втором случае например нетфликс может выбросить человека на улицу, как Хрюндель. Кстати на этот момент Хрюндель собственно и рефлексанул. Пока нетфликс существует. Как и компании с другим подходом.

Пс. Ну и я не понял, что вы хотели сказать таки. «Прибытием или убытием бойца, он влияет на остальных членов команды». А как ещё? Если убытие бойца ни на что не влияет, то он был лишним. Явно лишним. В корпорациях такое нередкость. Как по мне, в нормальной ситуации команда должна быть способна перераспределить нагрузку, но либо до найма, либо боец был лишним. Не особо понимаю, как красивый код может решить проблему нехватки людей. Причём опять же если вернуться к примеру с нетфликсом, то для одного чела красивым код будет тот, который он написал
Точно также встречал немало воин разных schools of thoughts. Например в swift можно писать интерфейсы и реализацию как в одном файле, так и в разных. Если у вас в коде один интерфейс реализует несколько классов, то логично, что сам интерфейс лучше положить в отдельный файл. И каждый класс в личный фаил. Если этого нет и наврятли планируется. То держите интерфейс и реализацию в одном файле, чтобы не прыгать по файлам, когда читаете код. Но были другие товарищи, которые считали, что интерфейс всегда должен лежать в отдельном файле. И вот очень забавно наблюдать как люди, занимаясь красотой, туда сюда это дело меняли, ведь архитекторов не один человек в корпе. И в то же время менеджеры, давшие более сложный вопрос архитектору занятому восстановлением справедливости, рефлексовали и просили сениоров тоже посмотреть, почему такой то вопрос не решён, создавалась ситуация, когда приходилось лезть сениору в огород архитектора, который этому был не совсем рад. Скорее демотивирован. Тут можно петь о том, что архитектор должен быть рад взаимовыручке. По стилю должны составить правила и придерживаться им. Но с правилами, во первых однозначного ответа нет, во вторых, так постепенно создаются рамки, убивающие инициативу.

Но собственно поэтому в Америке так развита культура стартапов. Которыми Хрюндель с его слов и занимается. Очень удобно отдавать стартапам эксперименты на откуп без всей этой корп бюрократии, ограничительных рамок спущенных сверху и раздутых команд. А вот если эксперимент заканчивается успехом, то они быстро превращают это в корп с другой командой

[xrundel]

А вот если эксперимент заканчивается успехом, то они быстро превращают это в корп с другой командой

Это какие-то страшилки. Ну как можно поменять команду всю с любом сложном продукте, и главное зачем. А вот что реально происходит в успешных компаниях так это рост. Было 10 пограмистов, стало 20. Потом 40. Потом 120. Приходят более опытные менеджеры потому что не хватает своих лидеров, меняется подход к разработке, меняется культура компании. Далеко не все могут проходить через эти итерации. Вчера все сидели в офисе и кодили до 12 ночи а сегодня нужно учить новичков и писать доки. Вчера все делали всё а сегодня уже команды которые отвечают за часть продукта и нужно синхронизироватся.

[xrundel]

А 2/3 в России на предложение денег говорят "спасибо, не надо"?

У нас написано что если вы хотите денег за тестовое то скажите нам об этом. 2/3 не говорят.

[BitterSean]

Давайте все же разделять идею/подход от частных (неудачных) способов исполнения.
Это вполне известный факт, что производительность хорошей команды в разы превышает сумме производительности каждого члена команды.
Сеньор инжинер грамотно менторит джуниоров (так чтобы они росли и учились думать, а не просто как мартышки поворяли), задает тон для других Сеньоров (хорошее сопровождение кода, юнит тесты, да хоть комментарии в коде!)

Всё гениальное просто.