O
Оно вроде как и не много, но это перерастает в тяжелые жирные регулярные затраты.
Size: a a a
2021 March 13
DT
+ у тебя большая часть этой работы размазана по организации и так, просто ты её посчитать не можешь
DT
Я несколько в этом понимаю и "все просто работает и сборка запускается одной командой" это не то, чтобы совсем правда. Точнее это правда в идеальных условиях суперстандартного сервиса полностью написанного внутри без особых зависимостей.
Да нет, для 95% случаев всё так и есть. Для еще 3-4% проблемя решаются достаточно легко. И вот в 1-2% это превращается в реальный геморрой
O
Ты меня не слышишь. На команду поменьше и без такого легаси не надо столько людей
Давай я еще некоторые риски озвучу:
1. Тебе постоянно нужно будет поддерживать свое решение и с точки зрения разработки, и с точки зрения операционной поддержки
2. Тебе будет сложно и дорого нанимать людей на него
3. Твои разработчики будут ныть и плеваться от этого, потому что они этого не знают и им оно не надо будет ровно за порогом твоей компании
Это по верхам только)
1. Тебе постоянно нужно будет поддерживать свое решение и с точки зрения разработки, и с точки зрения операционной поддержки
2. Тебе будет сложно и дорого нанимать людей на него
3. Твои разработчики будут ныть и плеваться от этого, потому что они этого не знают и им оно не надо будет ровно за порогом твоей компании
Это по верхам только)
SG
А вот и нет. Я на какойто англоязычной конференции рассказал про идеальное интервью и меня там запинали. Сказали, "too personal". Лезем в личную жизнь. Задаем странные вопросы. Вместо того чтобы оценить навыки.
(а я рассказывал, как мы на интернвью вообще не спрашивает про тех-навыки, а в основном базарим про всякие сноуборды, велосипеды, играешь ли на муз. инструментах, может выжигаешь лобзиком или любишь в Контру погонять?)
это был провал, все кричали как это неполиткорректно и обидно и это не дело компании влезать. Типа делим людей на своих и чухих. В этом есть доля правды, кстати. Но хз
(а я рассказывал, как мы на интернвью вообще не спрашивает про тех-навыки, а в основном базарим про всякие сноуборды, велосипеды, играешь ли на муз. инструментах, может выжигаешь лобзиком или любишь в Контру погонять?)
это был провал, все кричали как это неполиткорректно и обидно и это не дело компании влезать. Типа делим людей на своих и чухих. В этом есть доля правды, кстати. Но хз
классная история
АА
Я могу тебе рассказать достаточно подробно, тк имплементировал это все в Яндексе на 2к+ разработчиков (сейчас там больше) Но тут надо либо список вопросов, либо уже в формате краткой презентации. Я так-то могу рассказать, можно даже сделать тематический зум-звонок на интересующихся
С удовольствием послушаю!
DT
Это валидно в большей или меньшей степени для разных занятий, но я занимался эксплуатацией и вот там все грустно.
Но есть и обратная сторона медали - когда приходят люди, умеющие только определенный набор инструментов, и там всё превращается в «давайте переедем с Х на У потому что хз почему» :)
O
Это разные подходы. Применять подход Faanga в не-faang компании - это прямой путь на поле с граблями. Концептуально я не спорю с тем, что они вполне могут успешно жить с этим решением и даже нуждаться в нем. Молодцы:)
O
Но есть и обратная сторона медали - когда приходят люди, умеющие только определенный набор инструментов, и там всё превращается в «давайте переедем с Х на У потому что хз почему» :)
Ну это отдельная крайность.
O
Но если бы ко мне пришли и сказали "давайте закапаем несколько миллионов долларов в монорепу, а потом всю жизнь будем ее поддерживать" с обоснованием "зато мерж-реквесты в одном месте" - я бы пожалуй засомневался в адекватности человека.
Выглядит как болезнь резиновых бюджетов:)
Выглядит как болезнь резиновых бюджетов:)
O
Я совершенно понимаю почему тот же Яндекс пошел по этому пути. Но точно так же понимаю, что этот путь применим дай бог к 5% компаний.
A
и про работу в команде? как быть, если у вас там футболист, сноубордист и теннисист? это хорошая бэкенд команда или мобайл?
а работа в команде это тоже cultural fit, выясняется по наводящим вопросам
O
То есть большинство (подавляющее) компаний пойдут и возьмут то, на что легко хайрить, с чем можно жить с минимальным велосипедированием и будут заниматься зарабатыванием денег на основном продукте. Да, будут вероятно некоторые страдания, но пусть велосипедиорвания "все свое" принесет не меньше страданий, если ты конечно не понимаешь, что через 5 лет, когда оно все утрясется, ты отобьешь это за счет косвенных штук.
DT
Давай я еще некоторые риски озвучу:
1. Тебе постоянно нужно будет поддерживать свое решение и с точки зрения разработки, и с точки зрения операционной поддержки
2. Тебе будет сложно и дорого нанимать людей на него
3. Твои разработчики будут ныть и плеваться от этого, потому что они этого не знают и им оно не надо будет ровно за порогом твоей компании
Это по верхам только)
1. Тебе постоянно нужно будет поддерживать свое решение и с точки зрения разработки, и с точки зрения операционной поддержки
2. Тебе будет сложно и дорого нанимать людей на него
3. Твои разработчики будут ныть и плеваться от этого, потому что они этого не знают и им оно не надо будет ровно за порогом твоей компании
Это по верхам только)
Есть такие потенциальные риски, да. Но ц других решений есть обратные риски, которые тоже полезно перечислить:
1. Никто не оунит инфраструктуры разработки и когда что-то сложное нужно сделать или починить - это проблема
2. Сильно тяжелее поддерживать консистентность подходов, а без этого раздробленность и общее удорожание разработки + усложнение ротации внутри компании
3. Сложнее сделать «golden path” для типовых операций тк нужно поддержать гораздо большее количество комбинаций.
Finally, я если что не топлю за монорепу как за единственное возможное решение и наоборот многим говорю, что им оно не надо (например, нет выделенных ресурсов на поддержку).
Но если вдруг есть понимание, что этим пора заняться - сейчас это сильно проще сделать, чем 10 лет назад.
1. Никто не оунит инфраструктуры разработки и когда что-то сложное нужно сделать или починить - это проблема
2. Сильно тяжелее поддерживать консистентность подходов, а без этого раздробленность и общее удорожание разработки + усложнение ротации внутри компании
3. Сложнее сделать «golden path” для типовых операций тк нужно поддержать гораздо большее количество комбинаций.
Finally, я если что не топлю за монорепу как за единственное возможное решение и наоборот многим говорю, что им оно не надо (например, нет выделенных ресурсов на поддержку).
Но если вдруг есть понимание, что этим пора заняться - сейчас это сильно проще сделать, чем 10 лет назад.
A
а где отсев по скиллам?
это все тоже есть, расскажи про самй интересный проект, про самые сложные челленджи и тп. Я имел вииде без whiteboard-буллшита. бабл-сорт, "чем отличается референс-тайп от валью-тайп" вот это все
GL
это все тоже есть, расскажи про самй интересный проект, про самые сложные челленджи и тп. Я имел вииде без whiteboard-буллшита. бабл-сорт, "чем отличается референс-тайп от валью-тайп" вот это все
а, ну у нас так же. у нас самый любимый вопрос - расскажи про свои факапы
SS
это все тоже есть, расскажи про самй интересный проект, про самые сложные челленджи и тп. Я имел вииде без whiteboard-буллшита. бабл-сорт, "чем отличается референс-тайп от валью-тайп" вот это все
мне кажется, у вас values интервью с техническим в кучу свалено, с перевесом в values. баблсорт это буллшит, но есть же средний вариант между остутствием этого совсем и чернокрасными деревьями. как вот ты поймешь, что человек не умеет читать техзадание и делает абы что? ну и много других деталей, для которых социальные навыки совсем не показатель
O
Есть такие потенциальные риски, да. Но ц других решений есть обратные риски, которые тоже полезно перечислить:
1. Никто не оунит инфраструктуры разработки и когда что-то сложное нужно сделать или починить - это проблема
2. Сильно тяжелее поддерживать консистентность подходов, а без этого раздробленность и общее удорожание разработки + усложнение ротации внутри компании
3. Сложнее сделать «golden path” для типовых операций тк нужно поддержать гораздо большее количество комбинаций.
Finally, я если что не топлю за монорепу как за единственное возможное решение и наоборот многим говорю, что им оно не надо (например, нет выделенных ресурсов на поддержку).
Но если вдруг есть понимание, что этим пора заняться - сейчас это сильно проще сделать, чем 10 лет назад.
1. Никто не оунит инфраструктуры разработки и когда что-то сложное нужно сделать или починить - это проблема
2. Сильно тяжелее поддерживать консистентность подходов, а без этого раздробленность и общее удорожание разработки + усложнение ротации внутри компании
3. Сложнее сделать «golden path” для типовых операций тк нужно поддержать гораздо большее количество комбинаций.
Finally, я если что не топлю за монорепу как за единственное возможное решение и наоборот многим говорю, что им оно не надо (например, нет выделенных ресурсов на поддержку).
Но если вдруг есть понимание, что этим пора заняться - сейчас это сильно проще сделать, чем 10 лет назад.
Риски не потенциальные совершенно. Они прям реальные, реальней некуда.
1. Для этого есть devops практики, для этого есть выделенные команды инженерные и т.д. Совсем не обязательно решать это монорепой или своим тулингом. А, ну и ответ на множествол вопросов гуглится разрабом за 3 минуты на SoF.
2. В целом да. Но зато можно легко нанимать со стороны без дополнительного месяца-двух оверхеда по поводу "а вот тут у нас тоже свои грабли, только они не гуглятся"
3. Golden path имеет свойство обрастать if-ами, рамки лучше четких рекомендаций. Больше гибкости. Особенно если продукты и сервисы несколько разнообразны.
На счет "выделенных ресурсов" - тут большой вопрос в том, на что их тратить. Можно вот пойти в Open Source развивать на базе чего нибудь свое решение, заодно будет косвенный профит. В общем да, тема конечно неоднозначная. Любопытно поговорили.
1. Для этого есть devops практики, для этого есть выделенные команды инженерные и т.д. Совсем не обязательно решать это монорепой или своим тулингом. А, ну и ответ на множествол вопросов гуглится разрабом за 3 минуты на SoF.
2. В целом да. Но зато можно легко нанимать со стороны без дополнительного месяца-двух оверхеда по поводу "а вот тут у нас тоже свои грабли, только они не гуглятся"
3. Golden path имеет свойство обрастать if-ами, рамки лучше четких рекомендаций. Больше гибкости. Особенно если продукты и сервисы несколько разнообразны.
На счет "выделенных ресурсов" - тут большой вопрос в том, на что их тратить. Можно вот пойти в Open Source развивать на базе чего нибудь свое решение, заодно будет косвенный профит. В общем да, тема конечно неоднозначная. Любопытно поговорили.
DT
Уже реже, фб переписали его более чем
А вы с Фабрикатора на что-то другое слезли? На что, если не секрет?
RK
А вы с Фабрикатора на что-то другое слезли? На что, если не секрет?
Я же decline to answer такие вопросы