Ну и отдельно про снижение "планки квалификации".
P>Итого — ключевая посылка это "больше доля собственного кода ... задирает планку квалификации" и вы предлагаете альтернативу "либо наоборот, снижает" P>Вот это крайне странная альтернатива: "снижает планку квалификации"
Альтернатива вовсе не странная, а обычная.
Когда в компании растет объем кодовой базы и компания вынуждена нанимать все новых и новых людей, то это неизбежно приводит к тому, что "плотность сеньоров на квадратный метр" падает. И это естественно, т.к. количество доступных на рынке сеньоров растет медленнее, чем количество работы и объем кода. С этим сталкиваются все крупные компании, хоть Google с Microsoft-ом, хоть Яндекс с ВКонтактом.
ЕМНИП, в одном из своих рассказов об истории возникновения Go Роб Пайк говорил, что одна из причин начала работы над Go была в том, что типичный разработчик в Google -- это обычный программист, чьей квалификации недостаточно для нормального освоения C++ или Java. К сожалению, сейчас эта статья Роба Пайка не гуглится, подтвердить точной цитатой не могу.
P>>>Вы вбрасываете альтернативу из которой я логически вывожу, что "бывает так, что чем больше самописного кода, тем ниже риски найма"
P>Мне кажется, это очевидно.
Вам кажется.
P>Потому вам стоит озвучить как ваш подход какие именно риски минимизирует.
Не вижу смысла это делать в виду вашего тотального додумывания и домысливания за меня, подмены темы и виляния в собственных же словах.
P>Разумеется мои
Именно что ваши, которые вы преподносите как мои.
P>вы то прояснили так, что стало еще меньше понятно.
Вы не умеете или не желаете читать. Не говоря уже о том, что не можете вести корректный разговор не смотря на неоднократные просьбы.
P>А почему бы вам не привести пример который демонстрирует ошибку в моем логическом выводе?
Еще раз: проблема в том, что вы постоянно приписываете мне то, что я не говорил. А затем просите, чтобы я как-то объяснил то, что вы мне приписали, но что я не говорил от слова совсем. До тех пор, пока эта проблема не будет устранена, мои попытки донести до вас что-нибудь превращаются в попытки ответа на вопрос "а вы уже перестали пить коньяк по утрам".
P>Пример у вас есть, который покажет ошибку в этом логическом выводе?
Разумнее поговорить не об ошибке в этом логическом выводе, а о том, почему вообще речь зашла о такой штуке, как "риск найма", если изначально мы с вами разговаривали о, сюрпрайз, "сложности поиска кандидата"
В любом случае, чем больше доля собственного кода, тем сложнее найти кандидата, т.к. это автоматически задирает планку требуемой квалификации.
Т.е. сперва разговор о сложности, а потом бах! и ваш вывод о "риске найма". При этом вы не соизволили не определить понятие "риск найма", ни озвучить способы определения этого самого риска.
Может, конечно, вы придумаете что-то, что позволит уровнять "сложность найма" и "риск найма". Но здравый смысл и минимальная банальная эрудиция подсказывает, что "сложность" != "риску". Более того, "сложность поиска" может включать себя несколько рисков.
Так вот, мы беседовали (точнее я пытался прекратить ваши домысливания) о сложности поиска сотрудников. И в этой беседе тема рисков не рассматривалась пока вы не сделали собственную логическую цепочку, вывод из которой приписали мне.
А теперь вопрос: если вы ведете стабильно врете и передергиваете, то зачем вам доносить что-то, что вы заведомо извратите?
P>А если есть логическая цепочка, её корректность легко можно проверить.
Знаменитый английский натуралист лет 70 тому назад сказал: «Математика подобно жернову перемалывает лишь то, что под него засыплют». Вы видели, что в строгой эвклидовой математике эта засыпка состоит из таких аксиом и постулатов, в справедливости которых инженер усомниться не может, а так как лишь эти аксиомы и постулаты «перемалываются» без добавления новых (а если что добавляется, то должно быть точно и ясно указано), то инженер и придает такую веру математическому доказательству. Но здесь необходимо постоянно иметь в виду следующее обстоятельство: когда конкретный вопрос приводится к вопросу математическому, то всегда приходится делать ряд допущений, ибо математика вместе с механикой оперируют над объектами идеальными, лишь более или менее близкими к объектам реальным, к которым инженер будет прилагать полученные математические выводы. Ясно, что сколько бы ни было точно математическое решение, оно не может быть точнее тех приближенных предпосылок, на коих оно основано. Об этом часто забывают, делают вначале какое-нибудь грубое приближенное предположение или допущение, часто даже не оговорив таковое, а затем придают полученной формуле гораздо большее доверие, нежели она заслуживает, и это потому, что ее вывод сложный.
Так же и с вашими логическими построениями -- вы берете что-то свое (непонятно с какими допущениями и непонятно откуда взявшееся), делаете собственные выводы (настаивая на их корректности в силу "логичности"), а результаты выдаете за мои слова. Что не так от слова совсем.
Вот это вот:
P>Теперь проверяем мое утверждение, тот логический вывод который я за вас сделал P>1 проект, где простые задачи несмотря на обилие самописного кода, например, утилита командной строки, ни бд, ни ui, ни сетки, ни тяжелых алгоритмов P>2 доля самописного кода 100% и внешних зависимостей ровно 0 P>3 риски найма низкие т.к. можно брать джунов
В туже самую тему. Вы выдумали что-то свое и сделали какие-то свои выводы.
P>Но вот с примерами шота беда какая то Почему?
Кстати говоря, вы выдали откровенный парадокс, эдакую серебряную пулю, как понизить планку на входе и решить проблемы найма большинства проектов — всего лишь бери да изобретай своё, следуй паттерну non-invented-here, а потом "можно брать junior-ов или middle-ов и погружать их в X."
Утверждаете, что опыт не измеряется количественно, но сами выдаете колличественную оценку своему опыту:
Я проработал в конторе с 2001го по 2013й, проводил примерно 30 собеседований в год.
Утверждаете, что стаж != опыту, но при этом употребляете слово "опыт" вместо "стаж".
Приписываете мне ассоциации "опыт — длина — член — линейка", которых в моих словах не было от слова совсем.
И т.д., и т.п.
Игнорируя мои просьбы перестать домысливать.
Так что по совокупности, вы показали себя как звездун, которому пофигу на собеседника. С чем вас в очередной раз и поздравляю.
Здравствуйте, so5team, Вы писали:
S>Не говоря уже о том, что не можете вести корректный разговор не смотря на неоднократные просьбы.
Правильно понимаю, ваше хамство это образец корректности? Ну то есть, мне вас тоже оскорбить, обозвать, обругать и это должно помочь делу? Так у вас заведено?
S>Разумнее поговорить не об ошибке в этом логическом выводе, а о том, почему вообще речь зашла о такой штуке, как "риск найма", если изначально мы с вами разговаривали о, сюрпрайз, "сложности поиска кандидата"
Потому, что это синонимы, риски найма и сложность поиска кандидата
S>Т.е. сперва разговор о сложности, а потом бах! и ваш вывод о "риске найма". При этом вы не соизволили не определить понятие "риск найма", ни озвучить способы определения этого самого риска.
Там где в нулевых писали сложность поиска кандидата, сейчас пишут риски найма. Сложность даёт нам риски.
S>Может, конечно, вы придумаете что-то, что позволит уровнять "сложность найма" и "риск найма". Но здравый смысл и минимальная банальная эрудиция подсказывает, что "сложность" != "риску". Более того, "сложность поиска" может включать себя несколько рисков.
А я и говорю "риски найма". Покажете пример, где, по вашему, сложность найма не равна рискам найма ?
S>А теперь вопрос: если вы ведете стабильно врете и передергиваете, то зачем вам доносить что-то, что вы заведомо извратите?
Пока что очевидно, что вы стабильно хамите и пользуетесь несколько странной терминологией. Вот это точно.
Решил набраться храбрости и спросить, а вы долго занимаетесь этими вашими проектами, sobjectizer и подобными? У одного работодателя? Размер компании достаточно большой?
P>>Теперь проверяем мое утверждение, тот логический вывод который я за вас сделал P>>1 проект, где простые задачи несмотря на обилие самописного кода, например, утилита командной строки, ни бд, ни ui, ни сетки, ни тяжелых алгоритмов P>>2 доля самописного кода 100% и внешних зависимостей ровно 0 P>>3 риски найма низкие т.к. можно брать джунов
S>В туже самую тему. Вы выдумали что-то свое и сделали какие-то свои выводы.
Я привел пример, который, вообще говоря, иллюстрирует ваше понижение планки квалификации. Вы то примеры не приводите. И как мне понять?
P>>Но вот с примерами шота беда какая то Почему? S>Потому что вы видите
Слегка утрировал, что бы вы точно не прошли мимо. Перестарался, у вас выбило пробки. Не ожидал, что там всё так тонко — извините, отсутствие телепатии не позволяет через форум понять устройство вашей психики.
S>Утверждаете, что опыт не измеряется количественно, но сами выдаете колличественную оценку своему опыту:
Вы видите в этом оценку, а я вижу, что сообщил вам некоторые сведения. Косточка от арбуза(срок) не равна арбузу(опыт)
Почему важно сообщать такие сведение — в технических беседах так принято. И чем выше уровень беседы, тем больше стоит приводить таких требований.
S>Приписываете мне ассоциации "опыт — длина — член — линейка", которых в моих словах не было от слова совсем.
Вы там что, снова поменяли дежурного по рсдн?
Разберитесь, уже, кто с вашего аккаунта писал "Я не просил вас доставать ваш опыт и демонстрировать его длину"
Здесь у вас опыт связался с длиной, а только что вы написали будто этого не было.
Вот здесь у вас выплыла "мужики меряются членами" — вот это вообще непонятно, что к чему и откуда. Полагаю, это вы так видите эту беседу, раз вы приводите такие фразы.
Вот линейка — это уже моя ассоциация в ответ на ваши аргументы про длину и члены. По сути, двух примеров уже достаточно.
S>Игнорируя мои просьбы перестать домысливать.
Сегодня у нас большой прорыв — где у меня "риски найма", у вас "сложности найма кандидатов". И вы это считаете ужос-ужос каким преступлением — какой то pauel на интернете не пользуется Вашей Устоявшиейся Терминологией!!!!!!1111
S>Так что по совокупности, вы показали себя как звездун, которому пофигу на собеседника.
Как минимум, я продолжаю с вами беседовать и воздерживаюсь от оскорблений. Из этого просится логический вывод, что мне точно не пофигу. С теми, с кем пофигу, я точно не разговариваю.
Вы это в состоянии заметить, или скажете что и здесь я всё переиначил и наврал?
> С чем вас в очередной раз и поздравляю.
Пока что мы видим, что вы отрицаете много чего и не приводите пояснений своих слов. При этом продолжаете хамить.
Шота вы быстро. Вчера до вечеру держались, а сегодня уже в обед спеклись.
Но если вам это помогает — пожалуйста. Я ж вам рот не затыкаю. Что там есть, то и льётся. Жизнь так устроена.
Здравствуйте, Pauel, Вы писали:
S>>Не говоря уже о том, что не можете вести корректный разговор не смотря на неоднократные просьбы.
P>Правильно понимаю, ваше хамство это образец корректности? Ну то есть, мне вас тоже оскорбить, обозвать, обругать и это должно помочь делу? Так у вас заведено?
Если вы отмотаете разговор назад вы увидите, что употребление жестких выражений в ваш адрес началось далеко не сразу. Заслужили. И да, это вообще не хамство, каким бы обиженным вы себя не чувствовали.
S>>Разумнее поговорить не об ошибке в этом логическом выводе, а о том, почему вообще речь зашла о такой штуке, как "риск найма", если изначально мы с вами разговаривали о, сюрпрайз, "сложности поиска кандидата"
:
P>Потому, что это синонимы, риски найма и сложность поиска кандидата
Афигеть, дайте два!
Да в самом "найме кандидата", как минимум, сразу три риска сходу вырисовывается:
1. Не смогли вовремя никому сделать оффер так, чтобы оффер был принят.
2. Принявший оффер не подошел самой компании (ошибка с выбором со стороны компании), что выяснилось по ходу испытательного срока.
3. Принявший оффер покинул компанию до намеченного срока выхода на "полную проектную мощность" (либо сама компания провалила испытательный срок, либо случился какой-то форс-мажор в виде переезда/мобилизации/ареста/болезни/смерти принятого на работу).
Это только если говорить про риски, а не вообще про сложности.
P>Покажете пример, где, по вашему, сложность найма не равна рискам найма ?
Чуть больше, чем везде.
P>Я привел пример, который, вообще говоря, иллюстрирует ваше понижение планки квалификации. Вы то примеры не приводите. И как мне понять?
Здравствуйте, Pauel, Вы писали:
P>Разберитесь, уже, кто с вашего аккаунта писал "Я не просил вас доставать ваш опыт и демонстрировать его длину" P>Здесь у вас опыт связался с длиной, а только что вы написали будто этого не было. P>Вот здесь у вас выплыла "мужики меряются членами" — вот это вообще непонятно, что к чему и откуда. Полагаю, это вы так видите эту беседу, раз вы приводите такие фразы. P>Вот линейка — это уже моя ассоциация в ответ на ваши аргументы про длину и члены. По сути, двух примеров уже достаточно.
Пишу на случай, если кто-то еще ассоциировал "Я не просил вас доставать ваш опыт и демонстрировать его длину" непосредственно с длиной детородного органа.
Я воспринял упоминание Pauel своего опыты (с количественными характеристиками) в качестве дополнительного аргумента в пользу защищаемой им точки зрения. Типа если уж логических доводов не хватает, то вот могу дополнительно аргументировать и своим опытом который вот такой вот.
Аргументация опытом здесь оказывается совсем не в тему потому что:
a) меня не интересовало на основании какого опыта Pauel выстраивает свои аргументы, так как многое из того, что Pauel говорил, в подобных подтверждения не нуждалось априори;
b) этот опыт нерелевантен в том же смысле, как и опыт наблюдения за 10000 белых лебедей (и только белых лебедей) нерелевантен для утверждения о том, что черных лебедей не бывает.
А раз апелляция к опыту была в принципе не нужна, то это выглядело как бессмысленная попытка задавить авторитетом или же как попытка посоревноваться в крутизне. Отсюда и первая часть фразы "Я не просил вас доставать ваш опыт и демонстрировать его длину".
Вторая часть фразы, а именно "Но если он у вас такой, что в моих словах вы выискали вышеуказанный парадокс (удивительно где и как), то можете закатать его обратно, тут нечем хвастаться." вызвана тем, что если у человека есть немаленький опыт собеседования соискателей и введения новых людей в проекты, но при этом человек сам не осознает что его опыт отражать далеко не все, что есть в ИТ (в том числе и опыт найма мидлов/джуниоров "на вырост" вместо сеньоров), да еще и позволяет себе откровенно додумывать за собеседника, то такой опыт не впечатляет совершенно и принимать его в расчет нет смысла. Отсюда, в частности "тут нечем хвастаться" как синоним "не впечатляет" или "не производит должного впечатления", а вовсе не потому, что я подумал, что Pauel своим опытом хвастается.
Напомню, что для меня "мужики меряются членами" -- это не про линейки, это именно что про "бессмысленное соревнование в крутизне". Что и как измеряется в подобном соревновании совершенно неважно.
Здравствуйте, so5team, Вы писали:
S>Я воспринял упоминание Pauel своего опыты (с количественными характеристиками) в качестве дополнительного аргумента в пользу защищаемой им точки зрения. Типа если уж логических доводов не хватает, то вот могу дополнительно аргументировать и своим опытом который вот такой вот.
Вначале я воспринял, что вы меряете качественное количественно, и решил отыскать причину. А потом мы выяснили, что это у вас подход такой, вариант нормы в вашей реальности — смотреть на опыт количественно.
S>a) меня не интересовало на основании какого опыта Pauel выстраивает свои аргументы, так как многое из того, что Pauel говорил, в подобных подтверждения не нуждалось априори;
А я вот иначе считаю. Синдром болельщика нынче слишком сильно распространен, особенно в КСВ. Потому стоит продемонстрировать, что речь идет о вполне реальном опыте а не рассуждения вида "мне только что пришло в голову..."
S>b) этот опыт нерелевантен в том же смысле, как и опыт наблюдения за 10000 белых лебедей (и только белых лебедей) нерелевантен для утверждения о том, что черных лебедей не бывает.
Как раз таки у вас были утверждения вида "вы не сможете..."
Собственно, вы и сейчас продолжаете настаивать на том же, только сменили тактику трижды
1 — вы добавили, что я еще и вру
2 — вам надо представить мой опыт якобы нерелевантным
3 — начали обращаться к тем посетителям, которые придут сюда разгребать простыни, эдака подмога виртуальная
Подозреваю, если я где то и приукрасил, то точно не с целью ввести в заблуждение. Мне никогда не было жалко поделиться с кем то опытом. А вот что найдут люди, при разборе, так это ваши истеричные заявления и хамство, да её удивятся, как это я так долго с вам беседую.
S>Напомню, что для меня "мужики меряются членами" -- это не про линейки, это именно что про "бессмысленное соревнование в крутизне". Что и как измеряется в подобном соревновании совершенно неважно.
Ну ок. Вы может и не знаете чем вы пытались меряться, но я вот для себя нашел, в чем же у нас с вам возникла загвоздка — те самые "риски — сложности". На мой взгляд, если это решить, то можно и прийти к консенсусу.
Здравствуйте, so5team, Вы писали:
S>Если вы отмотаете разговор назад вы увидите, что употребление жестких выражений в ваш адрес началось далеко не сразу.
Если вы снова заглянете статистику моего профиля, вы увидите, что я терпением и церемониями не обладаю. Ваши "жосткие выражения" как вы их видите, я такими не рассматриваю. Это не иммунитет никакой — просто я не вижу, что бы из вашего потока из всего подряд могло бы ко мне прилипнуть.
Если вы хотели меня чем то зацепить, то это должно быть чем то близким к истине а не просто "вы всё врёти!!!!!11111".
> Заслужили. И да, это вообще не хамство, каким бы обиженным вы себя не чувствовали.
Классика — "это не я нахамил, это он первый/виноват/заслужил"
P>>Потому, что это синонимы, риски найма и сложность поиска кандидата
S>Афигеть, дайте два!
Именно.
S>Да в самом "найме кандидата", как минимум, сразу три риска сходу вырисовывается: S>1. Не смогли вовремя никому сделать оффер так, чтобы оффер был принят. S>2. Принявший оффер не подошел самой компании (ошибка с выбором со стороны компании), что выяснилось по ходу испытательного срока. S>3. Принявший оффер покинул компанию до намеченного срока выхода на "полную проектную мощность" (либо сама компания провалила испытательный срок, либо случился какой-то форс-мажор в виде переезда/мобилизации/ареста/болезни/смерти принятого на работу).
Видите, есть вещи в которых мы сходимся.
S>Это только если говорить про риски, а не вообще про сложности.
Мы про найм а не "вообще".
P>>Покажете пример, где, по вашему, сложность найма не равна рискам найма ? S>Чуть больше, чем везде.
Снова у вас общие слова. И вы снова избегаете прояснять именно там, где наше с вами видение расходится.
P>>Я привел пример, который, вообще говоря, иллюстрирует ваше понижение планки квалификации. Вы то примеры не приводите. И как мне понять? S>Пример был приведен давным-давно: http://rsdn.org/forum/flame.comp/8444732.1
Извините, я не слежу за вашим творчеством, могли бы и сбросить ссылку. Собственно, вся ситуация вполне вписывается в то, что я вам сам же и говорил. У нас в Беларуси таких компасплюсов в своё время было вагон и маленькая тележка, при этом не могу сказать, что бы это был такой типичный случай — эдак мы и оператора чата назовем инженером-программистом.
На таких проектах как я вижу, сеньоры-разработчики вообще не нужны — это как отдельная профессия, у них будут "сеньор-оператор-визуальной-системы-программирования". Никакой интриги, почти что механические движения.
И кстати говоря, я вам привел похожий пример, даже два. Трудно достучаться, пока вы там в отрицание играете. Но я крепок, мне вот интересно до вас достучаться
S>До других примеров дело не дошло ввиду вашей недоговороспособности.
Здравствуйте, Pauel, Вы писали:
P>Если вы хотели меня чем то зацепить, то это должно быть чем то близким к истине а не просто "вы всё врёти!!!!!11111".
Вы врали и сами это признали: "Слегка утрировал, что бы вы точно не прошли мимо."
>> Заслужили. И да, это вообще не хамство, каким бы обиженным вы себя не чувствовали.
P>Классика — "это не я нахамил, это он первый/виноват/заслужил"
Т.е. в мой адрес можно "у вас выбило пробки. Не ожидал, что там всё так тонко — извините, отсутствие телепатии не позволяет через форум понять устройство вашей психики", а в ваш адрес нет? Ну так об этом уже также говорилось:
Но, я смотрю, народ на RSDN какой-то изнеженный, завуалированно по чужой личности простись готов, а вот выслушать откровенные слова в ответ уже не может.
P>>>Потому, что это синонимы, риски найма и сложность поиска кандидата
S>>Афигеть, дайте два!
P>Именно.
Тогда еще раз афигеть. Боюсь, вы сильно недооцениваете глубину кроличьей норы, которая именуются "сложность найма".
P>Видите, есть вещи в которых мы сходимся.
Вы бы сами удивились насколько их много, если бы были готовы слушать вторую сторону, а не стремиться доказать, что ваша точка зрения единственно правильная (не говоря уже про все недобросовесные приемы, о которых уже говорилось).
S>>Это только если говорить про риски, а не вообще про сложности.
P>Мы про найм а не "вообще".
Найм -- это целый процесс от первого обозначения необходимости нанять нового человека и до получения полноценной отдачи от нового сотрудника (т.е. до момента, когда сотрудник начинает отрабатывать вложенное в него).
P>Снова у вас общие слова. И вы снова избегаете прояснять именно там, где наше с вами видение расходится.
Потому что здесь нужно начинать писать трактат. И этот трактат будет сильно отличаться для компаний разного размера и разного типа деятельности (т.е. для продуктовой компании до 20 человек -- одно, для продуктовой компании до 100 человек -- другое, до 1000 -- третье, аналогично и для аутсорсеров разных размеров). Кроме того, свою специфику будет накладывать то, в какой ситуации мы находимся (например, если ищем всего одного человека):
— разработчик в команде потерян внезапно и безвозвратно (скажем, COVID-19 сделал свое черное дело). У нас дыра, которую нужно затыкать как можно быстрее, стоимость практически не имеет значения. Одна из проблем, которая здесь стоит -- это как заткнуть временную дыру. Другая проблема -- как погрузить замену в проект как можно быстрее;
— разработчик обозначил сроки ухода (скажем, работаю до конца месяца/квартала, затем ухожу и не просите, и не уговаривайте). У нас дыра, но не сейчас, а на горизонте. Затыкать нужно как можно быстрее, стоимость практически не имеет значения. Пока ничего затыкать не нужно. Если новый человек найдется быстро, то уходящий может передавать свои знания из рук в руки;
— никто не ушел, но объем работы вырост настолько, что разработчики зарываются, а пользователи недовольны (что оказывается особенно больно, если компания работает на заказ, а заказчик знаковый (типа как небольшая компания из РФ стала работать с Газпромом или каким-нибудь ВТБ) и терять его нельзя хотя бы из-за имиджевых соображений). Взять нового хотелось бы быстрее, но стоимость имеет значение (например, если взять нового человека на ЗП заметно выше рынка, то нужно что-то делать с ЗП уже имеющихся разработчиков). Нет особых проблем с погружением нового человека (коллектив остается, есть кому передавать знания), но нужно что-то делать с тем, что новый человек начнет работать на полную мощность не сразу, а на это время производительность остальных разработчиков снизится;
— никто не ушел, пока объем работы стабильный, команда справляется, но на горизонте маячит что-то большое или серьезное. Например, продуктовая компания выпустила версию X.0 своего продукта, какое-то время поработала над его стабилизацией и начала строить планы по выпуску (X+1.0). Для чего нужно расширить штат, т.к. часть команды останется на саппорте версии X.0. Либо же поставщик полукоробочного решения подцепил нового клиента, основной объем работ с которым начнется с определенной даты (скажем, в начале осень договорились, что работы стартуют в начале следующего года, когда клиент начнет осваивать бюджет на следующий год). Тут может не быть спешки с поиском, стоимость имеет значения (нет смысла выходить за рамки имеющихся зарплат в компании). Нет проблем с погружением в тему нового человека.
В каждом из этих сценариев будет свой набор задач, свои приоритеты, свои ресурсы, свои планы "а", "b", "c", и т.д., и т.п.
P>>>Я привел пример, который, вообще говоря, иллюстрирует ваше понижение планки квалификации. Вы то примеры не приводите. И как мне понять? S>>Пример был приведен давным-давно: http://rsdn.org/forum/flame.comp/8444732.1
P>Извините, я не слежу за вашим творчеством, могли бы и сбросить ссылку.
Это не мое творчество. Это компания "Компас Плюс", которая в свое время была одним из заметных игроков на российском рынке банковского процессинга и ПО для банкоматов, а так же собиралась выходить на рынок со своими решениями для электронных платежей.
Я года с 2014-го к этой всей теме уже не имею отношения, но вроде они тогда чувствовали себя более чем хорошо.
P>На таких проектах как я вижу, сеньоры-разработчики вообще не нужны — это как отдельная профессия, у них будут "сеньор-оператор-визуальной-системы-программирования". Никакой интриги, почти что механические движения.
Они сделали свою систему визуального программирования и разрабатывали свои продукты на этой системе. Написать ряд банковских продуктов, внедренных в десятки банков, -- это не механические движения, тут как раз разработчики и нужны, просто они не строчки кода в редакторе будут писать, а квадратики стрелками в визуальной среде соединять.
(оказывается, я общался с ним не 15, а чуть ли не 18 лет назад).
Upd. Ссылки в старом RSDN-овском посте протухли. Вот одна актуальная из тех: http://www.softcraft.ru/paradigm/oop/flora/
P>Трудно достучаться, пока вы там в отрицание играете. Но я крепок, мне вот интересно до вас достучаться
Повторю еще раз: примеры того, как в проекты погружают серьезного уровня разработчиков, ничего не могут ни доказать ни опровергнуть. Это точно так же, как человек, который видел только белых лебедей, никак не может ни доказать, ни опровергнуть существование черных.
Даже если взять ваш пример с человеком, которого вы погрузили в проект через задачу изучения записи логов и небольшого попутного фиксинга этой самой записи.
Если мы начинаем рассматривать сценарии типа "взяли сеньора, дали ему мелкие задачки уровня джуна на время, пока он входит в тему, и считаем, что он приносит пользу сразу", то OK, я был не прав. При таком подходе вы можете взять нового человека и сразу бросить "в бой".
Однако, вот пара примеров, с которыми довелось столкнуться относительно недавно:
1. Компания использует MariaDB и хочет модифицировать под себя один из движков хранения данных. Им нужен человек, который это сделает. Если брать готового специалиста по MariaDB, то он сразу приступит к работе. Причем не только к проектированию, экспериментированию и написанию кода. Но даже к самой постановке задачи, т.к. понимая что к чему он может приводить клиента "в чувство", если клиент хочет того, что либо нельзя сделать, либо это будет стоить больше, чем клиент готов потратить. Если же взяли просто опытного разработчика со знанием C++, но который про MariaDB знает только то, что это реляционная СУБД, то такому разработчику потребуется некоторое время прежде чем он будет готов к этой задаче подступиться.
2. Компания использует ClickHouse и столкнулась с багом в обработке каких-то запросов. Хотела найти человека, который сможет им этот баг починить (видимо, на помощь самих разработчиков ClickHouse они не надеялись). Здесь ситуация аналогичная предыдущей.
И вот эти примеры гораздо ближе к тому, что я вкладываю в понятие "сразу в бой". Т.е. когда мы берем человека определенного уровня квалификации и сразу же начинаем его грузить задачами соответствующими уровню его квалификации, практически не давая времени на раскачку (с поправкой на то, что человека нужно погрузить в процессы компании).
Так вот все это становится гораздо сложнее, когда внутри "Рога и Ко" используются какие-то свои технологии (будь то собственный язык программирования, собственная среда разработки (как FloraWare от КомпасПлюс), свой фремворк (вроде userver от Яндекс)). Отсюда и мое утверждение про то, что "вы не сможете бросить нового человека сразу в бой".
Здравствуйте, so5team, Вы писали:
P>>Если вы хотели меня чем то зацепить, то это должно быть чем то близким к истине а не просто "вы всё врёти!!!!!11111".
S>Вы врали и сами это признали: "Слегка утрировал, что бы вы точно не прошли мимо."
Утрировать и врать это разные вещи:
— утрировать — преувеличивать с целью привлечь внимание, подчеркнуть какую то мысль.
— врать — искажать с целью ввести в заблуждение.
>>> Заслужили. И да, это вообще не хамство, каким бы обиженным вы себя не чувствовали.
P>>Классика — "это не я нахамил, это он первый/виноват/заслужил"
S>Т.е. в мой адрес можно "у вас выбило пробки. Не ожидал, что там всё так тонко — извините, отсутствие телепатии не позволяет через форум понять устройство вашей психики", а в ваш адрес нет?
Выбило пробки — это про ваше хамство, случаи задокументированы. Я здесь не пытаюсь давать оценку лично вам, а оцениваю ваши действия. С психикой это я конечно перестарался, двусмысленно вышла. Но куда "мягче" ваших "жостких фраз" как вы выразились.
Вы же ругулярно оцениваете именно меня, мою квалификацию, навешивая оскорбительные ярлыки, неоднократно.
Разница вам понятна — "вы плохой" и "ваш аргмент плохой"?
Если я для себя решу, что конкретно вы такой сякой, то сильно вряд ли я стану с вами после этого разговаривать. Смысла в этом никакого.
А если мне всего лишь аргументы ваши кажутся слабыми, то это совсем не повод прекращать разговор.
При этом ваши оскорбления прямо так и называю, что вы сами видели, в какую нору вы сами же себя засовываете. Это эдакий back pressure.
S>
S>Но, я смотрю, народ на RSDN какой-то изнеженный, завуалированно по чужой личности простись готов, а вот выслушать откровенные слова в ответ уже не может.
А что вы хотели — гнев можно выражать
— цивилизованно, корректно, без оскорбления, и без перехода на личности
— нецивилизованно — с оскорблениями и переходом на личности
Я уже спрашивал, вы какого отношения к себе хотите, оскорбительного, с руганью и без, когда оценивают конкретно вас, или корректного, когда оценивают ваши слова и действия?
Дайте сначала прямой ответ на этот вопрос, а дальше всё станет ясно.
P>>Именно.
S>Тогда еще раз афигеть. Боюсь, вы сильно недооцениваете глубину кроличьей норы, которая именуются "сложность найма".
Вы сейчас делаете необоснованное предположение. Мой опыт в найме вам неизвестен, т.е. именно вы здесь делаете вывод по аргументами в стиле "я такого не видел, значит не бывает"
P>>Видите, есть вещи в которых мы сходимся.
S>Вы бы сами удивились насколько их много, если бы были готовы слушать вторую сторону, а не стремиться доказать, что ваша точка зрения единственно правильная (не говоря уже про все недобросовесные приемы, о которых уже говорилось).
На секундочку — в этом треде вы минимум дважды обнулили беседу, т.е. отказались воспринимать аргументы. А я как раз вопросы вам задаю по пять раз и не могу получить ответа.
S>- разработчик в команде потерян внезапно и безвозвратно (скажем, COVID-19 сделал свое черное дело). У нас дыра, которую нужно затыкать как можно быстрее, стоимость практически не имеет значения. Одна из проблем, которая здесь стоит -- это как заткнуть временную дыру. Другая проблема -- как погрузить замену в проект как можно быстрее;
Затыкаете временную дыру — риски
не нашли вовремя
нашли не того
не смогли вписать в проект
не смогли вовремя погрузить в проект
S> Одна из проблем, которая здесь стоит -- это как заткнуть временную дыру. Другая проблема -- как погрузить замену в проект как можно быстрее
А где здесь именно сложность найма? Вы здесь говорите о проблеме, которую можно решить при помощи найма сотрудника. При этом к найму здесь применимы ровно те же риски, что вы перечислили — не нашли, упустили, взяли не того. Сложность найма в горячке. Это задирает риски. Т.е. в даном кейсе сложность найма и риски найма неразличимы.
S> У нас дыра, но не сейчас, а на горизонте. Затыкать нужно как можно быстрее, стоимость практически не имеет значения. Пока ничего затыкать не нужно. Если новый человек найдется быстро, то уходящий может передавать свои знания из рук в руки;
И здесь вы говорите о проблеме в проекте, котрую можно решить при помощи найма. И никак не раскрываетеся где тут особая сложность найма. Риски то все равно те же — только добавляется еще один "не успели сделать knowledge transfer". И снова у нас сложность найма и риски найма неразличимы.
S> нужно что-то делать с тем, что новый человек начнет работать на полную мощность не сразу, а на это время производительность остальных разработчиков снизится;
И здесь у вас ровно то же — проблема в проекте. Риск найма — новичек замедлит команду слишком сильно. Очень похож на "взяли не того". И здесь опять же неразличимы сложность найма и риски найма.
S> горизонте маячит что-то большое или серьезное.
И здесь вы фокусируетесь не на найме, а проблеме, которая решается посредством найма.
S>В каждом из этих сценариев будет свой набор задач, свои приоритеты, свои ресурсы, свои планы "а", "b", "c", и т.д., и т.п.
Как я вижу, вы в "сложности найма" записали все проблемы, которые могут решаться этим наймом. Т.е. вы попутали проблему с инструментом.
на секундочку — у нас тут разговор про "сложность найма" и "риски найма"
P>>На таких проектах как я вижу, сеньоры-разработчики вообще не нужны — это как отдельная профессия, у них будут "сеньор-оператор-визуальной-системы-программирования". Никакой интриги, почти что механические движения.
S>Они сделали свою систему визуального программирования и разрабатывали свои продукты на этой системе. Написать ряд банковских продуктов, внедренных в десятки банков, -- это не механические движения, тут как раз разработчики и нужны, просто они не строчки кода в редакторе будут писать, а квадратики стрелками в визуальной среде соединять.
Мы изначально говорили про проект, где всё самописное. В вашем примере разработчики банковских продуктов на этой визуальной системе сильно вряд ли пишут её же двигая квадраты.
Т.е. с т.з. этих разработчиков нет разницы, внешние зависимости, или зависимости от команды, которая кору струячит.
Я вот не знаю, приходилось ли этим разрабам и кору кодить. Из похожих проектов я точно знаю что обычно было жосткое разделение — разрабы коры, разрабы приложений.
И вот картина была такой
1. разрабы коры — туда абы кого не возьмешь, риски большие
2. разрабы приложение — риски регулярно сбываются, например, дикая текучка. Предложили кодить не визуально, а на питоне, и зп вдвое — и человек уходит.
S>Повторю еще раз: примеры того, как в проекты погружают серьезного уровня разработчиков, ничего не могут ни доказать ни опровергнуть.
А я думаю, что наоборот — если есть успешные применения, то это возможно. А если нет ничего — то не ясно.
S>Если мы начинаем рассматривать сценарии типа "взяли сеньора, дали ему мелкие задачки уровня джуна на время, пока он входит в тему, и считаем, что он приносит пользу сразу", то OK, я был не прав.
Если у нас джунов на проекте нет, то можно и так. Но это крайне неэффективно — простых, рутинных задач на любом проекте будет ~80%. И тогда получится так, что 80-90% работы у сеньора будет не соответствовать его уровню.
Я вам процитирую свой текст из скайпа, на всякий
"A team of senior engineers without any junior is the team of engineers."
Идея понятна?
> При таком подходе вы можете взять нового человека и сразу бросить "в бой".
Зачем нам сеньора тренировать на задачах для джуна? Ну вот я занимаюсь онбордингом сеньора. Я отдаю ему часть своих задач, где от меня не требуется много внимания. Надо ли пояснять, что у меня не будет задач уровня джуна? Просто потому, что есть и джуны — они такие задачи давно поразбирали.
S>1. Компания использует MariaDB и хочет модифицировать под себя один из движков хранения данных. Им нужен человек, который это сделает. Если брать готового специалиста по MariaDB, то он сразу приступит к работе. Причем не только к проектированию, экспериментированию и написанию кода. Но даже к самой постановке задачи, т.к. понимая что к чему он может приводить клиента "в чувство", если клиент хочет того, что либо нельзя сделать, либо это будет стоить больше, чем клиент готов потратить. Если же взяли просто опытного разработчика со знанием C++, но который про MariaDB знает только то, что это реляционная СУБД, то такому разработчику потребуется некоторое время прежде чем он будет готов к этой задаче подступиться.
Вот-вот, ровно то, о чем я вам говорил — степень пересечения. Её никто не отменял. И сеньора MariaDB мы вводим не накидывая ему задач "напиши select *", а подкидываем ему задачи его уровня
S>И вот эти примеры гораздо ближе к тому, что я вкладываю в понятие "сразу в бой".
А почему вы решили, что я вам какой то другой пример привел?
S>Так вот все это становится гораздо сложнее, когда внутри "Рога и Ко" используются какие-то свои технологии (будь то собственный язык программирования, собственная среда разработки (как FloraWare от КомпасПлюс), свой фремворк (вроде userver от Яндекс)). Отсюда и мое утверждение про то, что "вы не сможете бросить нового человека сразу в бой".
Это я понял, что вы так считаете, уже давно. Именно с этим я и не согласен. Свои технологии это не какое нибудь чудо. Обычно это упрощенные варианты имеющихся, только с дополнительными бенефитам.
С одной стороны, эта планка выше, чем в обычном рядовом проекте
С другой стороны, эта планка ниже, чем у разработчиков крутого популярного фремворка
Поэтому брать джунов-мидлов на такое мы не можем, зато нам и светила индустрии не нужны
На самом деле джуны-мидлы нужны, но не как основные работяги, а как крайний случай или на вырост. Врочем, я про это уже говорил.
Здравствуйте, Pauel, Вы писали:
S>>Вы врали и сами это признали: "Слегка утрировал, что бы вы точно не прошли мимо."
P>Утрировать и врать это разные вещи: P> — утрировать — преувеличивать с целью привлечь внимание, подчеркнуть какую то мысль. P> — врать — искажать с целью ввести в заблуждение.
А еще можно юлить и пытаться доказать, что "сложность найма" == "риски найма", а "стаж" != "опыт", опыт не измеряется, и т.д., и т.п.
P>А что вы хотели — гнев можно выражать
Если бы вы с самого начала вели себя нормально или хотя бы вовремя реагировали на замечания, то не пришлось бы "выражать гнев". Хотя гнева-то и нет.
P>Я уже спрашивал, вы какого отношения к себе хотите, оскорбительного, с руганью и без, когда оценивают конкретно вас, или корректного, когда оценивают ваши слова и действия? P>Дайте сначала прямой ответ на этот вопрос, а дальше всё станет ясно.
Мне привычнее прямота. Если я говорю что-то не то, что мне на это указывают. Форма не важна.
Проблема в том, что когда мне приписывают то, что я не говорил и не делал, то это отношения к прямоте не имеет. И касается это не только уже разобранных примеров, но и того, что выговорите про содержимое моей головы или о якобы имевших место истериках. Вы не сидели рядом со мной в момент написания текста, в принципе не можете видеть мое состояние, так что подобные измышления, мягко говоря, некорректны.
Так что прежде чем выяснять как общаться со мной, вернитесь к нормальной форме общения и мне не придется употреблять грубые выражения в ваш адрес.
S>>Тогда еще раз афигеть. Боюсь, вы сильно недооцениваете глубину кроличьей норы, которая именуются "сложность найма".
P>Вы сейчас делаете необоснованное предположение. Мой опыт в найме вам неизвестен
Опыт здесь не при чем. Достаточно того, что вы отождествили "сложность найма" с "рисками найма".
Это еще хуже, чем называть Qt как QT.
P>На секундочку — в этом треде вы минимум дважды обнулили беседу, т.е. отказались воспринимать аргументы.
Домысливание аргументом не является.
P>Затыкаете временную дыру — риски
Риск -- это вероятность наступления или ненаступления некого события с оценкой тяжести последствий наступления или ненаступления этого события.
Найм -- это процесс.
Вы умудряетесь отождествить вероятность с процессом.
Вы умудряетесь отождествлять одну из характеристик процесса с набором вероятности событий внутри процесса. О чем еще разговаривать?
S>> Одна из проблем, которая здесь стоит -- это как заткнуть временную дыру. Другая проблема -- как погрузить замену в проект как можно быстрее
P>А где здесь именно сложность найма?
Везде. Дословно расписывать не буду уж простите, написано и так слишком много.
P>И здесь вы говорите о проблеме в проекте, котрую можно решить при помощи найма.
Если вы не заметили, все приведенные примеры касаются проблем, которые не просто можно, с приходится решать с помощью найма.
P>И никак не раскрываетеся где тут особая сложность найма.
Потому что это примеры ситуаций, где "свой набор задач, свои приоритеты, свои ресурсы, свои планы "а", "b", "c", и т.д., и т.п." Сложность же в том, чтобы все это привело к должному результату.
P>И здесь опять же неразличимы сложность найма и риски найма.
Если вы чего-то не видите, то это не значит, что этого нет.
Хотя больше похоже, что вы либо тупите, либо троллите. Второе вероятнее.
S>>Они сделали свою систему визуального программирования и разрабатывали свои продукты на этой системе. Написать ряд банковских продуктов, внедренных в десятки банков, -- это не механические движения, тут как раз разработчики и нужны, просто они не строчки кода в редакторе будут писать, а квадратики стрелками в визуальной среде соединять.
P>Мы изначально говорили про проект, где всё самописное. В вашем примере разработчики банковских продуктов на этой визуальной системе сильно вряд ли пишут её же двигая квадраты.
Именно так они пишут (писали по меньшей мере).
S>>Повторю еще раз: примеры того, как в проекты погружают серьезного уровня разработчиков, ничего не могут ни доказать ни опровергнуть.
P>А я думаю, что наоборот — если есть успешные применения, то это возможно.
Успешные применения есть и у подхода с поиском сеньоров, и у подходов с поиском мидлов/джунов. Поскольку про подход с сеньорами лично мне известно изначально, то ваши примеры ничего нового не привносят.
S>>Если мы начинаем рассматривать сценарии типа "взяли сеньора, дали ему мелкие задачки уровня джуна на время, пока он входит в тему, и считаем, что он приносит пользу сразу", то OK, я был не прав.
P>Если у нас джунов на проекте нет, то можно и так.
При чем здесь "если у нас джунов нет". Речь идет про определение конкретного критерия: сеньору на время входа в проект дали джуниорвскую задачу, он с ней справился, значит уже успех. ОК, такой критерий возможен (может даже кому-то и полезен). Наличие других джуниоров на формулировку критерия не влияет.
P>Я вам процитирую свой текст из скайпа, на всякий P>"A team of senior engineers without any junior is the team of engineers."
P>Идея понятна?
Нет. Более того, непонятно зачем это в контексте разговора.
P>Зачем нам сеньора тренировать на задачах для джуна?
Мне это почем знать. Вы привели пример, который выглядит именно так.
P>Вот-вот, ровно то, о чем я вам говорил — степень пересечения...а подкидываем ему задачи его уровня
Да научитесь же вы читать то, что вам пишут! Я вам привел пример задачи где нет никакой степени пересечения. Вот вообще.
У людей есть задача, готовых специалистов нет, готовых специалистов с пересечениями по предметной области нет.
Задачу нужно решить.
И если они наймут просто специалиста по C++, то никакого "сразу в бой" не будет. Вот о чем речь.
P>А почему вы решили, что я вам какой то другой пример привел?
На основании того, что вы же про свой пример и написали.
Сперва это выглядело как мелкий фиксинг.
Затем получилось, что главное -- это анализ системы, полезным дополнением к которому будет еще и мелкий фиксинг.
P>Свои технологии это не какое нибудь чудо. Обычно это упрощенные варианты имеющихся, только с дополнительными бенефитам.
Значит вы их видели недостаточно. И очень сомневаюсь, что вы видели именно доморощенные фреймворки. Тем более не фреймворки общего назначения, а заточенные под прикладную область, для которых публичных аналогов может не быть вообще.
P>Поэтому брать джунов-мидлов на такое мы не можем
Ну OK, не можете, не берите. Ктож вас заставляет-то?
P>джуны-мидлы нужны, но не как основные работяги, а как крайний случай или на вырост. Врочем, я про это уже говорил.
Во-первых, я с этим и не спорил. Если вы перечитаете наш разговор, то увидите.
Во-вторых, я и сам это говорил:
Из сказанного мной следует лишь то, что нет "сеньоров со знанием X" поэтому и бесполезно искать именно "сеньоров со знанием X". Не более того.
Можно искать и сеньоров со знанием других технологий. Это будет один путь. О котором, собственно, вы и говорили.
А можно и не искать сеньоров, а сосредоточится на поиске мидлов и джуниоров с их последующим выращиванием. Это будет другой путь, со своими издержками. Но он таки возможен. И он таки означает снижение требований по квалификации.
Здравствуйте, Nuzhny, Вы писали:
N>Если не смотреть в замочную скважину автора приложений под Windows, то масштабы ии логика развития Qt раскроются шире и таких вопросов уже не возникнет.
Эта "замочная скважина" — практически весь десктопный софт, который на несколько порядков больше, чем ваш убогий Qt. Понимаешь, от твоего глупого употребления "замочная скважина" мысли умнее не становятся. Есть статистика, есть инженерное мышление и очевидно, Культя за 10 лет не предоставила практически НИЧЕГО, ради чего стоило бы слезть с какого-нть C#/.NET; У меня возникает только один вопрос — что за клоуны бегают со своей "кроссплатформой" и много ли они заработали, скажем, на продажах под Линукс и MacOS. Где эти миллионеры?
Здравствуйте, vaa, Вы писали:
vaa>>>Кто-то пишет GUI (настольные приложения) на системных ЯП?
B>>А с какой целью интересуешься?
vaa>Присматриваюсь в плане поглубже изучить системный ЯП. текущий кандидат зиг(раст что-то не зашел).
На сегодня нет практически ничего более "системного", чем классический Си. А прыгать по маргинальным наколенным поделиям я б не стал — не те времена. Сейчас наоборот, происходит сжатие области и на эксперименты нет ни времени, ни денег. Если есть стабильный язык с приличным количеством погромиздов — берётся он.
Но если ты собрался скальпелем рыть котлован, то ты явно фэйлишь. Будешь писать Линупс-2 — бери Си. Но если ты обычный прикладник — не майся дурью и пиши на C#/WinForms.
vaa>GUI на java/dotnet слегка раздражают размером/скоростью конечного продукта.
Жаба — может быть. На дотнете я не встречал именно "раздражающих" тормозов. Точнее, проблема есть у WPF — он написан и даже спроектирован весьма похабно, но WinForms — это практически "обёртки" над Win32 и там нечему тормозить. Кроме того, "тормоза" — палка о двух концах. Ты уверен, что это не ты — тормоз, а дотнет?? Покажи задачи, где у тебя дотнет тормозил (и какие либы ты использовал) — наверняка найдётся ответ, "почему медленно".
Другими словами, не торопись хаять то, в чём ты особо не углублялся.
vaa>Ну а как цель для системного ЯП выглядит хорошо, хотя может ошибаюсь и гуй на СЯП vaa>это только диалог настройки сервиса/тулзы.
Ты думаешь, проблема была в том, что у тебя был не системный язык? Я сильно сомневаюсь. Сколько я понаписал приблуд (начиная ещё с .NET 1.1), я не видел каких-то проблем со скоростью ГУЯ — для ЧЕЛОВЕКА дотнетины работают на высокой скорости. Плюс, не забывай: чем "системнее" язык, тем больше в нём кладут на инструменты. Так вот Visual Studio на сегодня — лучшее из того, что ты можешь себе позволить. Так что не распаляй время, возьми C#/FW4.8/WinForms и вперёд! Есть куча библиотек ГУЁвых (если тебе покажется, что контролы не очень весёленькие). Си тебе не даст практически НИЧЕГО, только умрёшь усталым
Здравствуйте, Baiker, Вы писали:
B>Жаба — может быть. На дотнете я не встречал именно "раздражающих" тормозов. Точнее, проблема есть у WPF — он написан и даже спроектирован весьма похабно, но WinForms — это
в стартовом указал на кроссплатформу. да классический дотнет имел оптимизированный рантайм.
сейчас ГУЕВЫЙ ХВ(замеры приводил) кроссплат-й это в 10 медленнее чем на том же фрипаскале.
я может и тормоз, но не дурак.
Здравствуйте, vaa, Вы писали:
vaa>Здравствуйте, Baiker, Вы писали:
B>>Жаба — может быть. На дотнете я не встречал именно "раздражающих" тормозов. Точнее, проблема есть у WPF — он написан и даже спроектирован весьма похабно, но WinForms — это
vaa>в стартовом указал на кроссплатформу
Ты пьяный штоле?? Мысли нормально формулируй.
vaa>сейчас ГУЕВЫЙ ХВ
Что это? Христос Воскрес? Хреновый Вид?
vaa>я может и тормоз, но не дурак.
Ты чудик Учись полно формулировать мысли, для кого литераторша распиналась?
B>Эта "замочная скважина" — практически весь десктопный софт, который на несколько порядков больше, чем ваш убогий Qt.
Смешно. Ты и правда узкий, как в песне Гудкова.
B> У меня возникает только один вопрос — что за клоуны бегают со своей "кроссплатформой" и много ли они заработали, скажем, на продажах под Линукс и MacOS. Где эти миллионеры?
Здравствуйте, so5team, Вы писали:
P>>Утрировать и врать это разные вещи: P>> — утрировать — преувеличивать с целью привлечь внимание, подчеркнуть какую то мысль. P>> — врать — искажать с целью ввести в заблуждение.
S>А еще можно юлить и пытаться доказать, что "сложность найма" == "риски найма", а "стаж" != "опыт", опыт не измеряется, и т.д., и т.п.
А кто вам в толковый словарь запрещает смотреть? Если вы моего разрешения ждали, то — вот оно.
Стаж — это период в единицах времени.
Опыт — результат за этот период, знания и умения.
Странно, что приходится это объяснять.
S>Если бы вы с самого начала вели себя нормально или хотя бы вовремя реагировали на замечания, то не пришлось бы "выражать гнев". Хотя гнева-то и нет.
Если гнева нет, а хамство есть, это это крайне дурной признак.
P>>Дайте сначала прямой ответ на этот вопрос, а дальше всё станет ясно.
S>Мне привычнее прямота. Если я говорю что-то не то, что мне на это указывают. Форма не важна.
Не поверю — в этой подтеме мы выяснили, что реакция на "пардокс", "выбило пробки", "строение психики" несколько неадекватная. Судите сами — на пустом месте вы дважды обнулили беседу.
Заявили, что впредь не будете со мной разговаривать, перешли от хамства к обвинениям. Вобщем, почти что фулхаус.
S>Проблема в том, что когда мне приписывают то, что я не говорил и не делал, то это отношения к прямоте не имеет. И касается это не только уже разобранных примеров, но и того, что выговорите про содержимое моей головы или о якобы имевших место истериках.
Ваше поведение в данной теме я считаю истеричным. Смотрите выше, про фуллхаус.
S>Так что прежде чем выяснять как общаться со мной, вернитесь к нормальной форме общения и мне не придется употреблять грубые выражения в ваш адрес.
Это вы мне сейчас решили поугрожать. Если вам хамство комфортнее — не надо себя сдерживать, я ж вам уже говорил.
P>>Вы сейчас делаете необоснованное предположение. Мой опыт в найме вам неизвестен
S>Опыт здесь не при чем. Достаточно того, что вы отождествили "сложность найма" с "рисками найма".
Вы пока что не предоставили никаких адекватных аргументов по этому поводу. Типа "вот сложность есть, рисков нет, а тут сложности нет, а риски есть".
S>Домысливание аргументом не является.
Тем не менее, вы обнулили беседу, в первый раз — когда бросили трубку на слове парадокс. Второй раз — в похожей ситуации.
S>Риск -- это вероятность наступления или ненаступления некого события с оценкой тяжести последствий наступления или ненаступления этого события. S>Найм -- это процесс.
Похоже, вы уже забыли, или у вас снова дежурный по рсдн поменялся.
S>Вы умудряетесь отождествить вероятность с процессом.
Вы очевидно попутали — речь была про свойства найма. Не "риски vs найм", а "сложность/риски" найма — характеристики одного процесса.
Теперь про синонимы. У слова история есть синонимы со смыслом "выдуманная история", а есть "реальная". Фактически — противоположности.
S>Вы умудряетесь отождествлять одну из характеристик процесса с набором вероятности событий внутри процесса. О чем еще разговаривать?
Похоже, вы уже забыли контекст. Простите, вам что, принципиально вести беседу про вещи, которые упомнить не можете?
P>>А где здесь именно сложность найма?
S>Везде. Дословно расписывать не буду уж простите, написано и так слишком много.
То есть, аргументов нет.
S>Если вы не заметили, все приведенные примеры касаются проблем, которые не просто можно, с приходится решать с помощью найма.
Именно что проблемы проекта решаются при помощи найма. А мы с вами — про свойства найма.
P>>И никак не раскрываетеся где тут особая сложность найма.
S>Потому что это примеры ситуаций, где "свой набор задач, свои приоритеты, свои ресурсы, свои планы "а", "b", "c", и т.д., и т.п." Сложность же в том, чтобы все это привело к должному результату.
Вы подробнее расскажите, что же за сложность именно найма.
P>>И здесь опять же неразличимы сложность найма и риски найма.
S>Если вы чего-то не видите, то это не значит, что этого нет.
S>Хотя больше похоже, что вы либо тупите, либо троллите. Второе вероятнее.
Вы мне снова хамите. Это я специально даю вам фидбек, что бы вы понимали, куда вас несёт.
P>>Мы изначально говорили про проект, где всё самописное. В вашем примере разработчики банковских продуктов на этой визуальной системе сильно вряд ли пишут её же двигая квадраты. S>Именно так они пишут (писали по меньшей мере).
А отрисовку этих квардартов они тоже квадратами пишут? А юзеринпут и стейтменеджмент они тоже квадратами обеспечивают? У вас рекурсия вышла.
P>>Если у нас джунов на проекте нет, то можно и так.
S>При чем здесь "если у нас джунов нет". Речь идет про определение конкретного критерия: сеньору на время входа в проект дали джуниорвскую задачу, он с ней справился, значит уже успех. ОК, такой критерий возможен (может даже кому-то и полезен). Наличие других джуниоров на формулировку критерия не влияет.
На мой взгляд это неэффективно, разгонять сеньора джуниорскими задачами. Неэффективно — потому, что есть более интересные варианты — внятный knowledge transfer, парнопрограммирование, хорошая документация, предсказуемые билды, простой локальный деплоймент, рабочая версия в песочнице, итд
P>>Я вам процитирую свой текст из скайпа, на всякий P>>"A team of senior engineers without any junior is the team of engineers." P>>Идея понятна?
S>Нет. Более того, непонятно зачем это в контексте разговора.
Непонятно, и ладно.
S>Мне это почем знать. Вы привели пример, который выглядит именно так.
Я вам объяснил, подробно. Давайте еще раз попробуем:
Сеньор бакенд в курсе про логирование, что это много больше чем запись ctx.trace,
и он точно умеет решать open-ended задачи
а еще он может сам разбираться в коде большой системы
и точно худо-бедно умеет коммуницировать с qa
Джун ничего этого не умеет — и вполне может считать что это логгирование это и есть ctx.trace, а QA он скорее всего будет доказывать "а у меня работает!!!".
Между тем логи не только пишутся, их где то читают, накапливают, аггрегируют, анализируют, и нас интересует весь цикл — от ctx.trace и до фрамента лога в тикете, или выдаче в кибане.
Если я дам это джуну, то мне придется с ним каждую часть сидеть рядом и объяснять, что и зачем, итд итд.
Сеньору я могу это оформить как open-ended задачу — "qa поназаводили багов, говорят им в логах приходит не то, что происходит реально, нужно выяснить и решить все связанные проблемы"
P>>Вот-вот, ровно то, о чем я вам говорил — степень пересечения...а подкидываем ему задачи его уровня
S>И если они наймут просто специалиста по C++, то никакого "сразу в бой" не будет. Вот о чем речь.
Если пересечения нет, то не будет и "сразу в бой". Я ж вам это в начале недели сказал. Нет способа получить мгновенно результат, если нет пересечения. Его надо сначала создать.
S>Сперва это выглядело как мелкий фиксинг. S>Затем получилось, что главное -- это анализ системы, полезным дополнением к которому будет еще и мелкий фиксинг.
Именно. Вы вот экономите на аргументах, вам лень объяснять, а от меня вы ждете найподробнейших описаний. Вы здесь противоречия не видите?
P>>Свои технологии это не какое нибудь чудо. Обычно это упрощенные варианты имеющихся, только с дополнительными бенефитам. S>Значит вы их видели недостаточно. И очень сомневаюсь, что вы видели именно доморощенные фреймворки.
S>А можно и не искать сеньоров, а сосредоточится на поиске мидлов и джуниоров с их последующим выращиванием
Ваша эта фраза выглядит так, будто вы собираетесь сеньорские задачи раздавать джунам-мидлам. Или вы подразумеваете, что запасец сеньоров точно есть ? Если так, то телепатии у меня нет.
Здравствуйте, Pauel, Вы писали:
S>>А еще можно юлить и пытаться доказать, что "сложность найма" == "риски найма", а "стаж" != "опыт", опыт не измеряется, и т.д., и т.п.
P>А кто вам в толковый словарь запрещает смотреть? Если вы моего разрешения ждали, то — вот оно. P>Стаж — это период в единицах времени. P>Опыт — результат за этот период, знания и умения.
В какой именно из словарей? Вот, например, относящееся к нашему разговору определение из словаря Ожегова для "опыт": "Совокупность знаний и практически усвоенных навыков, умений. Жизненный о. О. исследовательской работы. О.строительства. Поделиться своим опытом с кем-н."
Стаж -- это не просто абстрактный период времени, а период времени непосредственно относящийся к деятельности (т.е. приобретению опыта): "1. Продолжительность деятельности в какой-н. области.Трудовой с. С. работы на заводе. 2. Срок, в течение к-рого вновь поступившие работают для приобретения опыта в своей специальности, а также для общей оценки стажирующегося. Кандидатский с."
Так что стаж является одной из характеристик опыта. Что и делает "стаж" и "опыт" в определенных контекстах взаимозаменяемыми. Именно поэтому в резюме и в вакансиях указывают опыт в годах, а вы использовали слово "опыт" там, где по вашим же словам следовало бы указать "стаж".
P>Не поверю
Сколько угодно. Точно так же я не верю в наличие у вас опыта работы с доморощенными фреймворками.
P>Судите сами — на пустом месте вы дважды обнулили беседу.
Вы дважды завели ее своими домыслами и додумываними до состояния, когда продолжение не имело смысла.
P>Ваше поведение в данной теме я считаю истеричным.
Вы считаете. Специально выделю: вы.
Не знаете точно (и не имеете возможности узнать), но считаете.
Про себя вы можете считать что угодно, но когда вы это высказываете публично в форме утверждения, то это уже совсем другой коленкор, подразумевающий определенные последствия.
Что в очередной раз заставляет меня указать вам на одну из главных проблем вашего поведения: вы интерпретируете (домысливаете) мои слова по своему, а затем начинаете общаться со мной исходя из своих домысливаний, а не из того, что я вам сказал.
Просить перестать так делать бессмысленно, вы не сможете, как показала история разговора.
P>Это вы мне сейчас решили поугрожать.
Нет. Всего лишь повторю правила поведения: "Если в беседе со мной кто-то изображает дурака, я называю его дураком. Если кто-то изображает чудака на букву "М", я называю его чудаком на букву "М". Если кто-то звиздит, то я говорю, что кто-то звиздит."
Посему если вы продолжите звиздеть, то за мной не заржавеет об этом прямо сказать.
P>Вы пока что не предоставили никаких адекватных аргументов по этому поводу.
Мне приходится повторять банальности. Хотелось бы верить, что хотя бы в этот раз вы прочитаете и постараетесь вникнуть, а не скипните:
Риск -- это вероятность наступления или ненаступления некого события с оценкой тяжести последствий наступления или ненаступления этого события.
Найм -- это процесс. Процесс означает последовательность шагов, у каждого из которых есть своя сложность/трудоемкость/длительность/стоимость. У каких-то из этих шагов есть риски, которые подлежат учету и требуют неких мер по предотвращению и преодолению (у чего также есть сложность/трудоемкость/стоимость).
Откуда следует, что сложность найма -- это совокупная сложность шагов в процессе найма. Сложность шагов. А не вероятность отдельных событий в этом процессе.
Если вы и это не сможете принять за аргумент, то сорри, других у меня для вас нет.
S>>Домысливание аргументом не является.
P>Тем не менее, вы обнулили беседу
Из-за ваших домысливаний. Причем вы сами признали, что домысливания с вашей стороны имели место быть.
P>Вы очевидно попутали — речь была про свойства найма. Не "риски vs найм", а "сложность/риски" найма — характеристики одного процесса.
Сложность -- характеристика. Риски -- нет, риски -- это вероятности.
P>Похоже, вы уже забыли контекст.
Опять домысливание. Сейчас я безуспешно (из-за вашего поведения очень сильно мне напоминающего элементарную глупость) пытаюсь вам объяснить, что вы неправомерно заменили "сложность найма" на "риски найма".
S>>Везде. Дословно расписывать не буду уж простите, написано и так слишком много.
P>То есть, аргументов нет.
Повторю еще раз: тут придется писать целый трактат. Эту работу мне никто не компенсирует.
В качестве маленького примера: если вы работаете в организации с формализованными процессами, то у вас в компании должен быть отдельный документ/регламент, описывающий процесс найма. В этом документе будет изложен алгоритм выполнения этого процесса с перечнем шагов, задействованных лиц, документов, согласований и т.д.
У каждой из операций в этом процессе есть своя сложность. Мера этой сложности будет зависеть от опыта и умений того, что за операцию отвечает. Для кого-то это элементарно, для кого-то (особенно в первый раз) -- нет. Тем не менее, сложность есть у каждого из шагов в процессе найма.
Начинаться процесс может с написания служебной записки о необходимости открытия вакансии. И первая сложность -- это собственно написание такой записки. Дальше эта служебная записка должна быть одобрена. И здесь еще одна сложность: принимающего решение ваша записка может не убедить. И т.д., и т.п.
Подозреваю, что вы сможете (как вы уже неоднократно демонстрировали) найти здесь кучу рисков (типа риск того, что служебная записка не будет написана, риск того, что служебная записка не будет одобрена). Но сложность написания служебной записки и риск того, что она написана не будет -- это разные вещи.
Или еще пример. Вам нужно посадить нового человека куда-то. Желательно туда, где уже сидит команда, с которой человеку нужно работать. Но места в этом помещении уже нет. Кого-то куда-то нужно пересаживать. Так вот то, что вам не удасться собрать всю команду вместе в одном рабочем помещении -- это риск, тогда как организация рабочих мест -- это задача (может быть даже мини-процесс) со своей сложностью.
P>Вы подробнее расскажите, что же за сложность именно найма.
Не могу, ибо придется писать много текста, а потерянное на это время никто не компенсирует.
S>>Именно так они пишут (писали по меньшей мере).
P>А отрисовку этих квардартов они тоже квадратами пишут? А юзеринпут и стейтменеджмент они тоже квадратами обеспечивают? У вас рекурсия вышла.
Не вижу здесь никаких проблем.
AFAIK, до сих пор виртуальная машина для Java написана на C++, а компилятор Java был переписан на Java относительно недавно. Так что в Java присутствует C++, но это не значит, что Java разрабатывают на C++.
Я не могу говорить за Floraware, но если бы я делал такого рода проект, то применял бы подход с bootstrapping-ом. Т.е. сперва бы на C++ сделал самую простейшую версию визульного дизайнера. В этой простейшей версии сделал бы более продвинутую версию дизайнера. В более продвинутой -- еще более продвинутую.
Насколько помню, авторы Floraware говорили, что на C++ у них изначально была сделана виртуальная машина и какие-то базовые средства интеграции с ОС. Все остальное уже на самой Floraware. Возможно, сейчас они заменили C++ на .NET или Java.
Собственно, что-то подобное на протяжении уже десятков лет используется в Smalltalk-средах. Так что ничего необычного здесь нет.
В качестве еще более вырожденного примера -- GUI приложения на Python и PyQt. Нижний слой там на C++ и Qt, но ведь приложение пишется на Python.
P>На мой взгляд это неэффективно, разгонять сеньора джуниорскими задачами.
Повторюсь: речь не об этом.
Речь о формулировании критерия, который позволяет сказать, что новый человек начал приносить пользу в соответствии со своей квалификацией. Т.е. что именно считать "сразу в бой".
S>>Мне это почем знать. Вы привели пример, который выглядит именно так.
P>Я вам объяснил, подробно. Давайте еще раз попробуем:
Вы не добавили ничего нового. И я увидел все то же самое.
Мой тезис: вы не получите полноценной отдачи от человека, пока вы этого человека не погрузите в свою специфику (поскольку мы про доморощенные фреймворки, то пока он не изучит ваш фреймворк).
Вы: это не так и вот мой пример.
Я смотрю на пример и вижу, что вы именно что погружаете человека в вашу специфику. Т.е. он изучает ваш фреймворк.
P>Если пересечения нет, то не будет и "сразу в бой".
Поскольку я сразу говорил именно о ситуациях, когда "пересечения нет", то мне остается лишь в третий раз задать вопрос: так с чем вы спорите?
S>>Значит вы их видели недостаточно. И очень сомневаюсь, что вы видели именно доморощенные фреймворки.
P>Можете развеять свои сомнения www.linkedin.com/in/pavel-husakouski
И что я там должен увидеть? Особенно с учетом того, что это именно мне приходилось здесь объяснять вам что подразумевается под доморощенным фреймворком.
S>>
S>>А можно и не искать сеньоров, а сосредоточится на поиске мидлов и джуниоров с их последующим выращиванием
P>Ваша эта фраза выглядит так, будто вы собираетесь сеньорские задачи раздавать джунам-мидлам.
Вы ошибаетесь.
P>Или вы подразумеваете, что запасец сеньоров точно есть ? Если так, то телепатии у меня нет.
Слово "выращиванием" означает, что нанятых будут растить, а из этого следует, что есть кому растить. Тут не нужна телепатия. Ну или можно было просто спросить что именно имеется в виду. Спросить можно было бы сразу, если бы вы не додумывали за меня.
Здравствуйте, pagid_, Вы писали:
N>>Например, в автомобильной отрасли. _>А причем тут кросcплатформенность?
Потому что Qt есть на многих платформах? Как-то раньше Windows CE предлагалась для навигаторов, наладдонников, автомобилей. Потом QNX с Линуксом забрали себе эти области.
Пишут на Qt, потому что: а) он есть под эти платформы; б) потому что разрабатывать можно на любом компе — написал под Windows или Линукс, отладил всю логику, потом собрал на QEMU или конечном железе.
Если бы Qt не был кроссплатформенным, то хрен там его выбирали автопроизводители.
Здравствуйте, so5team, Вы писали:
P>>Опыт — результат за этот период, знания и умения.
S>В какой именно из словарей?
Это что, так принципиально? Ваши же примеры показывают ровно то, о чем я и сказал — стаж это период времени, а опыт есть результат за этот период времени, естесвенно, результат не сало на боках и количество просиженых джинс, а знания-умения-навыки.
S>Так что стаж является одной из характеристик опыта. Что и делает "стаж" и "топыт" в определенных контекстах взаимозаменяемыми.
Именно что характеристика, а не сам опыт. В некоторых контекстах слова могут быть взаимозаменяемыми — в некоторых, а не везде, где вздумается. Ровно как и со словами синонимами — далеко не везде вас поймут, если лепить абы что на основании того, что слова есть синонимы.
S>Сколько угодно. Точно так же я не верю в наличие у вас опыта работы с доморощенными фреймворками.
Ну не верьте. Разве я вас заставляю во чтото верить? Я могу показать, расскать, но вот верить или не верить это оставьте себе.
S>Вы дважды завели ее своими домыслами и додумываними до состояния, когда продолжение не имело смысла.
Это для вас не имело смысла. Для меня смысл вполне конкретный, и я уже привел примеры.
P>>Ваше поведение в данной теме я считаю истеричным.
S>Вы считаете.
Именно
> Специально выделю: вы.
Что нового вы только что сказали?
S>Не знаете точно (и не имеете возможности узнать), но считаете.
И что с того?
S>Про себя вы можете считать что угодно, но когда вы это высказываете публично в форме утверждения, то это уже совсем другой коленкор, подразумевающий определенные последствия.
Ужос. Точно ли вы понимаете разницу:
1. истеричное поведение в данном треде
2. истеричный человек
У меня есть ощущение, что для вас это одно и то же.
S>Что в очередной раз заставляет меня указать вам на одну из главных проблем вашего поведения: вы интерпретируете (домысливаете) мои слова по своему, а затем начинаете общаться со мной исходя из своих домысливаний, а не из того, что я вам сказал.
К сожалению, у меня нет телепатии, что бы влезть вам в голову и начать понимать, что же вы имели ввиду. Потому интерпретирую ваши слова с учетом уточнений и собственного опыта. Где можно, я задаю вопросы, но в целом у вас тенденция к игнорированию моих вопросов.
S>Просить перестать так делать бессмысленно
Разумеется, бессмысленно — телепатии у меня нет, и в обозримом будущем не появится.
P>>Это вы мне сейчас решили поугрожать.
S>Нет. Всего лишь повторю правила поведения: "Если в беседе со мной кто-то изображает дурака, я называю его дураком. Если кто-то изображает чудака на букву "М", я называю его чудаком на букву "М". Если кто-то звиздит, то я говорю, что кто-то звиздит."
Ну да, вы нашли хорошее оправдание своему хамству — якобы у вас есть эдакий эталон, благодаря которому можно оценить личность вашего собеседника. Вы тут случаем не в бога играете?
S>Посему если вы продолжите звиздеть, то за мной не заржавеет об этом прямо сказать.
И снова угроза. Ощущение, будто всё вне вашего опыта есть враньё. Как то так
S>Сложность -- характеристика. Риски -- нет, риски -- это вероятности.
По вашему, вероятность не может быть характеристикой?
P>>Похоже, вы уже забыли контекст.
S>Опять домысливание. Сейчас я безуспешно (из-за вашего поведения очень сильно мне напоминающего элементарную глупость) пытаюсь вам объяснить, что вы неправомерно заменили "сложность найма" на "риски найма".
Сложность найма это совсем необязательно внутренняя сложность. Когда менеджеры говорят "сложность найма" обычно имеют ровно то же, что и риски. Вот если рекрутёры говорят про сложность найма, то они имеют ввиду структуру своей работы. Нас это не сильно интересует. Снаружи всё это выглядит как те или иные риски.
S>Повторю еще раз: тут придется писать целый трактат. Эту работу мне никто не компенсирует.
Вы тут отнекивались раз в десять дольше, чем того требует хотя бы минимальный ответ по существу. Впрочем, вы его привели — спасибо!
S>Подозреваю, что вы сможете (как вы уже неоднократно демонстрировали) найти здесь кучу рисков (типа риск того, что служебная записка не будет написана, риск того, что служебная записка не будет одобрена). Но сложность написания служебной записки и риск того, что она написана не будет -- это разные вещи.
Сложность написания записки по большому счету и есть риск, что она написана не будет. Этого риска нет только в том случае, если такие записки писать не надо — например, никого не нанимаем.
А вот если есть сложность написания записки, найм открыт, а рисков, что записка будет написана некорректно, нет, то вот хотелось бы посмотреть, что это за чудо.
S>Или еще пример. Вам нужно посадить нового человека куда-то. Желательно туда, где уже сидит команда, с которой человеку нужно работать. Но места в этом помещении уже нет. Кого-то куда-то нужно пересаживать. Так вот то, что вам не удасться собрать всю команду вместе в одном рабочем помещении -- это риск, тогда как организация рабочих мест -- это задача (может быть даже мини-процесс) со своей сложностью.
Если сложность в том, что нанимаете не там, то и риск что наймёте не там Если сложность в том, что кого то некуда посадить, то и риск в том, что кому то не найдется места.
S>Не могу, ибо придется писать много текста, а потерянное на это время никто не компенсирует.
Т.е. вы сначала привели кучку примеров, а потом жалуетесь, что это время вам никто не компенсирует? Чтото я вас не могу понять. Жалко времени — не пишите сюда. Собственно, вы такое намерение уже озвучивали.
P>>А отрисовку этих квардартов они тоже квадратами пишут? А юзеринпут и стейтменеджмент они тоже квадратами обеспечивают? У вас рекурсия вышла. S>Не вижу здесь никаких проблем.
читайте себя ниже
S>AFAIK, до сих пор виртуальная машина для Java написана на C++, а компилятор Java был переписан на Java относительно недавно. Так что в Java присутствует C++, но это не значит, что Java разрабатывают на C++.
Именно это и значит, что платформу Java разрабатывают в т.ч. на C/С++ и чем то там еще. Т.е. критический код будет написан на системном ЯП.
S>Насколько помню, авторы Floraware говорили, что на C++ у них изначально была сделана виртуальная машина и какие-то базовые средства интеграции с ОС. Все остальное уже на самой Floraware. Возможно, сейчас они заменили C++ на .NET или Java.
Ну вот видите — есть ажно целая виртуальная машина, и не на квадратах, а на обычном ЯП. И у меня есть большие сомнения, что виртуалку и продукты с её использованием пишут те же самые студенты, что и пилят конкретные продукты.
S>В качестве еще более вырожденного примера -- GUI приложения на Python и PyQt. Нижний слой там на C++ и Qt, но ведь приложение пишется на Python.
Продуктовым командам не надо лезть ни во внутренности PyQT, ни QT. За счет этого и понижение требований. Зато когда у нас такого рода фремворк есть часть продукта, туда придется лазить членам команды. И это накладывает ограничения на квалификацию и как следствие влечет те или иные риски.
S>Повторюсь: речь не об этом. S>Речь о формулировании критерия, который позволяет сказать, что новый человек начал приносить пользу в соответствии со своей квалификацией. Т.е. что именно считать "сразу в бой".
Я ж сказал — пересечение имеющегося опыта и требуемого, что бы были задачи в этой области. В противном случае ничего не выйдет. А как иначе?
S>Мой тезис: вы не получите полноценной отдачи от человека, пока вы этого человека не погрузите в свою специфику (поскольку мы про доморощенные фреймворки, то пока он не изучит ваш фреймворк).
А разве речь была про 100% его мощности прям на старте? Это вы чтото своё углядели. Я всего то о том, что мы сеньора и джуна вводим в проект разными путями. Т.е. разница качественная, а не количественная.
И снаружи это будет выглядеть не как "время до момента начала выдавания результата", а как "разгрузили имеющихся сеньоров"
S>Я смотрю на пример и вижу, что вы именно что погружаете человека в вашу специфику. Т.е. он изучает ваш фреймворк.
Специфика это functional и non-functional фичи приложения, например бизнеслогика, секьюрити, перформанс. А фремворк это второстепенная вещь. Если нет понимания самой проблемы, то лезть во фремворк смысла никакого нет.
То есть, погрузить сеньора надо сначала в приложение! Фремворка свой, или не свой, разницы не имеет. Это минорная часть. Фремворк это всего 1-2% от всего кода.
Вы головой подумайте — что важнее, освоить 98..99% приложения, или только 1..2?
Ну научили вы новичка вашему фремворку. Ну и что? Всё остальное то много важнее! А если он раскурит одну единственную фичу, functional или non-functional, то он он сразу поймент, как делаются похожие фичи, заглянет по ходу в пол-приложения, получит представление о устройстве, БЛ, билдах, деплойменте, и о чем угодно.
Ну да, фремворк он так не узнает. Ну и хрен с ним, с фремвоком. И это никакая не проблема — фремворк нужно писать так, что бы люди могли влезть в него без особых усилий. Тогда он развязывает руки.
А если фремворк надо изучать, то лучше бы ему вообще не появляться.
S>И что я там должен увидеть? Особенно с учетом того, чбто это именно мне приходилось здесь объяснять вам что подразумевается под доморощенным фреймворком.
Я уже понял, если ктото считает фремвок не настолько важным, как это считаете вы, то этот ктото ничего не понимает во фремвоках
P>>Или вы подразумеваете, что запасец сеньоров точно есть ? Если так, то телепатии у меня нет.
S>Слово "выращиванием" означает, что нанятых будут растить, а из этого следует, что есть кому растить. Тут не нужна телепатия. Ну или можно было просто спросить что именно имеется в виду. Спросить можно было бы сразу, если бы вы не додумывали за меня.
А можно было бы и пояснить. Это ж ваша ответственность — быть понятым.
Почему?
