Re[4]: Есть ли какие минусы работы "таксистом" ?
От: Кодт Россия  
Дата: 27.07.18 12:23
Оценка:
Здравствуйте, LuciferNovoros, Вы писали:

LN>Поверь, их есть у нас и немало... Очень много "хотелок" просто улетает в помойку. Много их висит не один месяц, пока все согласовывается, состыковывается и так далее. Потом пока еще разрабатывается ТЗ, чтоб не получилось ХЗ на выходе. В общем, вполне себе нормальный процесс. И ревью кода тоже есть, куда ж без него. И промежуточные альфы и беты, чтоб протестировать.


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

И, наверно, расширять штат, если ситуация с завалом тикетами постоянная.
Причём, как штат разрабов, так и штат менеджеров — если они по многу месяцев тормозят.

Кстати, работа в офисе сильно ускоряет рабочие процессы — в их неформальной части. Вместо того, чтобы оформлять и согласовывать электронную писанину, пошёл в соседнюю комнату, потрещал с коллегами, порисовал что-то прямо на столе, — а потом хоба, оформили и согласовали. Или хоба, и забили болт и не замусорили трекер заведомо мёртвой хотелкой.
С удалёнкой возможности личного общения несколько меньше.
(Мне щас тоже скажут, что это стокгольмский синдром, проводить треть жизни в опенспейсе и десятую часть в дороге...)
Перекуём баги на фичи!
Re[5]: Есть ли какие минусы работы "таксистом" ?
От: LuciferNovoros Россия  
Дата: 27.07.18 13:46
Оценка:
Здравствуйте, Кодт, Вы писали:

К>Тогда надо просто относиться к этому философски. Цинически по отношению к тому, что улетает в помойку, и стоически — к тому, что вошло в планы.

К>Всех хотелок не воплотишь, всех денег не заработаешь.

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

К>И, наверно, расширять штат, если ситуация с завалом тикетами постоянная.

К>Причём, как штат разрабов, так и штат менеджеров — если они по многу месяцев тормозят.

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

К>С удалёнкой возможности личного общения несколько меньше.


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

К>(Мне щас тоже скажут, что это стокгольмский синдром, проводить треть жизни в опенспейсе и десятую часть в дороге...)


Я не скажу. Но иногда в офисе все же да, удобнее.
Re[6]: Есть ли какие минусы работы "таксистом" ?
От: lintik  
Дата: 28.07.18 17:27
Оценка:
Здравствуйте, denisko, Вы писали:

D>Стокгольмский синдром имхо. У нас такого нет, хотя компания в несколько раз (десятки если судить по обороту, разы-десятки если судить по пользователям) больше яндекса. У каждого модуля и подмодуля есть программист (архитектор), он решает что войдет что нет. Архитекторы объедены в пирамиду, так что размер команды на каждом уровне максимум 10 человек.

Жесть какая. Страшно подумать, что случайно можно попасть в такую пирамиду.
Re[7]: Есть ли какие минусы работы "таксистом" ?
От: denisko http://sdeniskos.blogspot.com/
Дата: 29.07.18 18:41
Оценка:
Здравствуйте, Кодт, Вы писали:
Общая логика работы, чтобы все нижеперечисленные проблемы были твоими проблемами. Решается банально: деньгами и люлями.

К>Какой у вас автобусный фактор? На время отпуска разработка модуля прекращается?

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


К>Если на тебя затмение найдёт во время коммита, — как вы это будете разгребать?


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

К>Если тебе надо поменять интерфейс или контракт, от которого зависит вышестоящий модуль, — тоже без подтверждения коммитишь (и пусть там всё сломается)?

Нет, запрашиваешь это изменение, если все согласны, что оно разумно -- применяешь. А вот если нижестоящий, то тоже запрашиваешь изменения, но это по сути предупреждение.

К>Или у вас каждый коммит — это новая минорная версия модуля, и пусть у вышестоящего болит голова, надо ли апгрейдить зависимости?

Нет, откуда такая дикость?
К>От каждого модуля зависит только один надмодуль, поэтому можно такое пирамидальное версионирование применить?
У нас все инфраструктрные части обычно устаканены уже, раз в года или несколько лет. Но проблем пока не было.

К>Мне кажется, что это специфика вашей компании, что вы смогли разрабатывать в режиме "каждый сам себе царь". Не все проекты так удачно декомпозируются.

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

D>>Один работал у байкаровой в команде, другой не помню у кого, тоже рядом с обработкой изображений.

К>Кто такая Байкарова? Не нашёл в списке сотрудников.
Довольно известная тетка в области обработки изображений, бывший тех.дир. спирита. Она вполне вероятно ушла уже, последнее что я о ней слышал в связи с яндексом относилось к 15 или 16 году.
<Подпись удалена модератором>
Re[3]: Есть ли какие минусы работы "таксистом" ?
От: a7d3  
Дата: 29.07.18 18:46
Оценка:
Здравствуйте, __JS, Вы писали:


__J>И также дело в том что команда это одни люди,

__J>а топ менеджмент компании и его политика это совершенно другие люди

Самый правильный выход — сдвинуть дату выхода на работу к яндексойдам на то количество времени, которое необходимо чтобы закрыть дела с текущей командой.
Во-первых, выписанный тебе оффер не требует сиюминутного ответа, а предполагает его в течении пары недель.
Во-вторых, после акцептинга оффера согласуется дата выхода на работу и «через два месяца» — это вполне нормальная тема.
Re[8]: Есть ли какие минусы работы "таксистом" ?
От: Кодт Россия  
Дата: 29.07.18 20:12
Оценка:
Здравствуйте, denisko, Вы писали:

D>Здравствуйте, Кодт, Вы писали:

D>Общая логика работы, чтобы все нижеперечисленные проблемы были твоими проблемами. Решается банально: деньгами и люлями.

К>>Какой у вас автобусный фактор? На время отпуска разработка модуля прекращается?

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

Автобусный фактор, равный 1 — не твоя проблема. Ты уволишься "спокойно, во сне, как твой дед, а не с криками ужаса, как его пассажиры".

К>>Если на тебя затмение найдёт во время коммита, — как вы это будете разгребать?


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


Смоделируем ситуацию: у тебя и твоего заместителя оказалось разное чувство прекрасного.
Ты ушёл в отпуск, а он взял и отрефачил кучу твоего кода, просто потому, что может. Честно отрефачил, изоморфно.
Может быть, даже не со зла, а тупое преобразование "заменить пробелы на табы", в соответствии с настройками его редактора.
Тесты, естественно, все прошли.
Возвращаешься из отпуска, и что ему скажешь?

А вот это "не возьмут твою версию в поставку" — это не является ревью?

К>>Если тебе надо поменять интерфейс или контракт, от которого зависит вышестоящий модуль, — тоже без подтверждения коммитишь (и пусть там всё сломается)?

D>Нет, запрашиваешь это изменение, если все согласны, что оно разумно -- применяешь. А вот если нижестоящий, то тоже запрашиваешь изменения, но это по сути предупреждение.

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

Это — не ревью?

К>>Или у вас каждый коммит — это новая минорная версия модуля, и пусть у вышестоящего болит голова, надо ли апгрейдить зависимости?

D>Нет, откуда такая дикость?
К>>От каждого модуля зависит только один надмодуль, поэтому можно такое пирамидальное версионирование применить?
D>У нас все инфраструктрные части обычно устаканены уже, раз в года или несколько лет. Но проблем пока не было.

К>>Мне кажется, что это специфика вашей компании, что вы смогли разрабатывать в режиме "каждый сам себе царь". Не все проекты так удачно декомпозируются.

D>Эта специфика почти любой компании, где хоть какая то декомпозиция возможна. Главное, вовлечь разрабов в проблемы и позволить самоорганизоваться.

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

D>>>Один работал у байкаровой в команде, другой не помню у кого, тоже рядом с обработкой изображений.

К>>Кто такая Байкарова? Не нашёл в списке сотрудников.
D>Довольно известная тетка в области обработки изображений, бывший тех.дир. спирита. Она вполне вероятно ушла уже, последнее что я о ней слышал в связи с яндексом относилось к 15 или 16 году.

Вообще ничего не находится. (По бывшим сотрудникам тоже).
Она точно в Яндексе работала, или только в Спирите?
Перекуём баги на фичи!
Re[9]: Есть ли какие минусы работы "таксистом" ?
От: denisko http://sdeniskos.blogspot.com/
Дата: 30.07.18 07:01
Оценка:
Здравствуйте, Кодт, Вы писали:

К>Здравствуйте, denisko, Вы писали:


D>>Здравствуйте, Кодт, Вы писали:

D>>Общая логика работы, чтобы все нижеперечисленные проблемы были твоими проблемами. Решается банально: деньгами и люлями.

К>>>Какой у вас автобусный фактор? На время отпуска разработка модуля прекращается?

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

К>Автобусный фактор, равный 1 — не твоя проблема. Ты уволишься "спокойно, во сне, как твой дед, а не с криками ужаса, как его пассажиры".

Ну так кормить надо лучше, они и не улетят.

К>>>Если на тебя затмение найдёт во время коммита, — как вы это будете разгребать?


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


К>Смоделируем ситуацию: у тебя и твоего заместителя оказалось разное чувство прекрасного.

К>Ты ушёл в отпуск, а он взял и отрефачил кучу твоего кода, просто потому, что может. Честно отрефачил, изоморфно.
К>Может быть, даже не со зла, а тупое преобразование "заменить пробелы на табы", в соответствии с настройками его редактора.
К>Тесты, естественно, все прошли.
К>Возвращаешься из отпуска, и что ему скажешь?

Ничего. Продолжу писать в его стиле, если он соответсвует гайдлайнам. Мне пофиг на это, если ему это важно то и ок.


К>А вот это "не возьмут твою версию в поставку" — это не является ревью?

К>>>Если тебе надо поменять интерфейс или контракт, от которого зависит вышестоящий модуль, — тоже без подтверждения коммитишь (и пусть там всё сломается)?

К>Ну вот все согласны, что оно разумно, ты выкатываешь новую версию и... коммитишь в общую репку, в общую ветку.

К>А без согласия — не коммитишь. (В своей локальной репке ты можешь что угодно делать, это-то понятно).
К>Это — не ревью?

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

К>Значит, Гугл — пример такой компании, где "хоть какая" декомпозиция — недостаточна.

К>Потому что проект Хромиум, хоть и разбили на множество мелких частей, они так и не удосужились довести до режима "каждый сам себе царь".
К>При том, что разрабов — тьма. Но цари, всё-таки, — мейнтейнеры проекта.
У гугла может быть политика замешана во все это и столкновение чувств прекрасного у царей.



К>Вообще ничего не находится. (По бывшим сотрудникам тоже).

К>Она точно в Яндексе работала, или только в Спирите?

https://ru-ru.facebook.com/people/Наталия-Байгарова/100015117611107 Блин что у вас там с поиском в яндексе. Я на одну букву ошибся, а он так тупит
<Подпись удалена модератором>
Re[10]: Есть ли какие минусы работы "таксистом" ?
От: Кодт Россия  
Дата: 30.07.18 12:24
Оценка:
Здравствуйте, denisko, Вы писали:

К>>Автобусный фактор, равный 1 — не твоя проблема. Ты уволишься "спокойно, во сне, как твой дед, а не с криками ужаса, как его пассажиры".

D>Ну так кормить надо лучше, они и не улетят.

Автобусный фактор назван в честь автобуса, а не в честь заведённого трактора.
Человек смертен, а иногда — внезапно смертен.


К>>Смоделируем ситуацию: у тебя и твоего заместителя оказалось разное чувство прекрасного.

К>>Ты ушёл в отпуск, а он взял и отрефачил кучу твоего кода, просто потому, что может. Честно отрефачил, изоморфно.
К>>Может быть, даже не со зла, а тупое преобразование "заменить пробелы на табы", в соответствии с настройками его редактора.
К>>Тесты, естественно, все прошли.
К>>Возвращаешься из отпуска, и что ему скажешь?

D>Ничего. Продолжу писать в его стиле, если он соответсвует гайдлайнам. Мне пофиг на это, если ему это важно то и ок.


А если он не соответствует? Устроите войну правок или оставите винегрет?
А если он очевидно наговнокодил, но удачно обошёл все тесты? Ты же не можешь добиться 100% покрытия кода тестами.
А если у вас редакторы по-разному настроены на табуляцию, и в истории коммитов — в каждой строчке, по мнению системы контроля версий, идёт война правок, так что поиск "кто что изменил" превращается в пытку?

К>>А вот это "не возьмут твою версию в поставку" — это не является ревью?

К>>>>Если тебе надо поменять интерфейс или контракт, от которого зависит вышестоящий модуль, — тоже без подтверждения коммитишь (и пусть там всё сломается)?

К>>Ну вот все согласны, что оно разумно, ты выкатываешь новую версию и... коммитишь в общую репку, в общую ветку.

К>>А без согласия — не коммитишь. (В своей локальной репке ты можешь что угодно делать, это-то понятно).
К>>Это — не ревью?

D>Это ревью на уровне логики. Как оно написано, если удовлетворяет требованиям, то всем пофиг. Код ревью есть 1-2 раза в год, когда особо удачные куски идут в модульную библиотеку,но там твой код просто переписывается прогером из другого департамента в соответствии со стандартом библиотеки и его (прогера) чувством прекрасного, тут уже ты ревьюишь чтобы прогер своих ошибок не внес.


Что мешает с самого начала договориться об общем чувстве прекрасного, и писать код в соответствии с общими гайдлайнами?
Это и автобусный фактор увеличит до размеров всего департамента, и портирование кусков сделает почти тривиальным.

Вот у нас есть две практически работающие политики:
— "как пасти котов? просто кормите их" — ваша фирма и, предположительно, "почти все другие"
— "если вы такие умные, почему строем не ходите" — Гугл, Яндекс, и все те, кто гугловским гайдлайнам следуют и в битбакете процедуру ревью включают.

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

Вопрос: кто переплачивает, и как померять величину переплаты.

К>>Вообще ничего не находится. (По бывшим сотрудникам тоже).

К>>Она точно в Яндексе работала, или только в Спирите?

D>Наталия-Байгарова/100015117611107 Блин что у вас там с поиском в яндексе. Я на одну букву ошибся, а он так тупит


Удельный вес очепяток в разных буквах разный и зависит от... от чего-то, например, от того, действующие сотрудники или бывшие.
Перекуём баги на фичи!
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.