Это карта в первую очередь для Python-программиста, для которого, на мой взгляд, любые познания в ML - не junior уровень. Разумеется, что если перекладывать её для узкого специалиста в какой-то из затронутых областей (DBE, DevOps, ML), то вся кривая распределения навыков сместится вниз (но еще больше навыков просто отвалится, кстати), и, скажем, основы статистики будут соответствовать junior уровню.
На сегодняшний день есть: автоматизированный цикл оценки перформанса, хард-скиллов и соответствия грейда; автоматизированный цикл пересмотра зарплат
Вы либо сделали гениально-уникальную штуку, либо шляпу для пускания руководству пыли в глаза.
Расскажите, на основе какой информации и какими алгоритмами вы автоматизированно "оцениваете перформанс" и автоматизированно же "пересматриваете зарплаты". На мой взгляд, без скобочек это делает только руководитель, а из реквизита ему нужен только карандаш и клочок бумаги, а вовсе не HR-отдел.
Участь HR-отдела в эпоху автоматизации - взаимодействие с госорганами по вопросам кадрового делопроизводства, онбординг и подготовка подарков детишкам на Новый Год. Но вы упорно пытаетесь создать дымовую завесу из eNPS, HRD, HRBP, ATS, performance review, "360 градусов" и прочей белиберды (HRBP же наверняка лучше, чем PhD?), при этом "мы даже не могли точно сказать, сколько человек работает в управляющей компании", то есть, другими словами, не можете пройти джуновское собеседование на 1С или SQL.
Мне кажется, что это относительно несложно. Главное - перевести описание проекта на английский + разместить на reddit небольшую статью. Делайте свою работу доступной англоязычной аудитории, и, если она содержит какое-то мало-малькси интересное зерно, внимание к проекту будет. Как пример - мой крошечный пет flywheel c 75 звездочками или роадмап по Python (в тему статьи, кстати) pyroad c 340 звёздочками. Но я не уверен, что звёзды конвертируются в офферы, так что это скорее хоббийная история.
Pyroad, я, кстати, потихоньку превращаю в отдельный сайт pyroadmap.com, где, в отличие от очень уважаемого мной roadmap.sh, пытаюсь пометить цветом (зелёный, жёлтый, красный) учебные треки для junior, middle и senior соответственно. Так что, если вы только начинаете изучение Python и немножко офигеваете от обилия информации, попробуйте последовательно пройтись по зелёным пунктам путеводителя или хотя бы используйте эту информацию для разработки своего собственного учебного трека.
Через пять лет соберётся целая библиотека объектов, где они будут лежать подобно книжкам на полках, и бизнес сможет решать любую программную задачу по щелчку пальцев, просто комбинируя нужные библиотеки как детали LEGO.
Если я правильно помню (пусть старшее поколение меня поправит), такой подход имеет корни как минимум в шестидесятых. Тогда тоже была надежда, что вот сейчас составим библиотеку всех потребных численных методов, вроде определения арктангенса, расчёта ФОТ и движения тела в атмосфере, а потом нагрузка на программиста существенно снизится.
Всё верно, именно пирог размером одного порядка с мировым ВВП сейчас и предлагают на рассмотрение инвесторам. В расчёте, разумеется, что нынешние модели удастся допилить до состояния, когда они будут способны конкурировать за рабочие места с человеком.
Насчёт полок вы, по-моему, сгущаете краски. Ручной пробойник в виде толстостенной металлической трубки с коронковой рабочей частью достаточно легко проходил сквозь бетон, на внешнюю, не несущую стену бетонной девятиэтажки (там марка цемента пожиже) даже я, будучи ребёнком, повесил часы.
Но, конечно же, с перфоратором это не сравнить и для нормальной каждодневной работы совершенно не подходит.
По-моему, в "Оппенгеймере" дискутируется не вопрос подогрева воздуха, а возможность реакции атмосферы, для которой первоначальный атомный взрыв будет лишь "активатором". Физики на этом этапе опасались уничтожить вообще всю Землю.
Возможно, @Anarchist хотел сказать, что текст прихрамывает, периодически противореча самому себе; и я с ним полностью согласен.
Например, общему посылу статьи "Мы тут все такие демократичные, молодёжные, современные, быстро собесим сразу с лидом" противоречат напоминания "Не забудьте составить сладенькое сопроводительное письмо" или "Можем тиснуть вас на временный контракт, чтобы переложить все головняки с компании на работягу".
Все эти милые кусочки программ на ассемблере хороши и ламповы, когда рассматриваешь их изолированно, с подробным комментарием и в ностальгическом контексте. А вот когда пытаешься пытаешься написать на ассемблере относительно сложную, контролируемую и сопровождаемую систему, то литературного слога очень скоро начинает не хватать...
Если не считать время на чистовую отделку, уже через 10 рабочих дней вы пьете чай в своем доме.
Вы напрасно перегибаете рекламную палку, пытаясь создать иллюзию неземной лёгкости перехода от коробки к дому. В целом по тексту вы достаточно аккуратно обходите вопрос суммарной стоимости и сроков строительства, но вот в этом абзаце рука у автора явно дрогнула.
Против смазываний можно попробовать высокопольные 3 Тл МРТ. В моём городе есть один такой, в рекламе утверждается, что "вы можете продолжать дышать во время сканирования брюшной полости" :)
Без структур данных действительно мало что получится. Цитируя Торвальдса, "Плохие программисты беспокоятся о коде. Хорошие программисты беспокоятся о структурах данных и их взаимосвязях".
Но структура данных ≠ схема данных. Возможно, вам для бизнес-логики оптимально подойдёт красно-чёрное или префиксное дерево, и заранее засовывать его в прокрустово ряляционное ложе было бы, на мой взгляд, большой ошибкой.
бизнес-логика - это то, чем люди будут заниматься даже при отсутствии какой-либо вычислительной техники вообще; скажем, банкиры будут считать сложный процент, а астрофизики - параметры звёзд, даже если у них останется только бумажка с ручкой; соответственно, при создании модели вообще про такие вещи, как зеркалирование, SQL, NoSQL думать нельзя, это инфицирует бизнес-логику чуждым кодом;
можно сказать, что вообще "никто не first"; Роберт Мартин особо подчёркивал (и даже гордился), что БД - это такой же легко заменяемый сегмент внешнего круга ПО, как, скажем, веб-интерфейс (с учётом реального положения дел, такое, конечно, можно встретить нечасто), и "проблемы базы шерифа не волнуют";
консистентность и правда хромает.
Но это, разумеется, только один из подходов к проектированию ПО, абсолютизировать его было бы неразумно.
Это карта в первую очередь для Python-программиста, для которого, на мой взгляд, любые познания в ML - не junior уровень. Разумеется, что если перекладывать её для узкого специалиста в какой-то из затронутых областей (DBE, DevOps, ML), то вся кривая распределения навыков сместится вниз (но еще больше навыков просто отвалится, кстати), и, скажем, основы статистики будут соответствовать junior уровню.
Вы либо сделали гениально-уникальную штуку, либо шляпу для пускания руководству пыли в глаза.
Расскажите, на основе какой информации и какими алгоритмами вы автоматизированно "оцениваете перформанс" и автоматизированно же "пересматриваете зарплаты". На мой взгляд, без скобочек это делает только руководитель, а из реквизита ему нужен только карандаш и клочок бумаги, а вовсе не HR-отдел.
Участь HR-отдела в эпоху автоматизации - взаимодействие с госорганами по вопросам кадрового делопроизводства, онбординг и подготовка подарков детишкам на Новый Год. Но вы упорно пытаетесь создать дымовую завесу из eNPS, HRD, HRBP, ATS, performance review, "360 градусов" и прочей белиберды (HRBP же наверняка лучше, чем PhD?), при этом "мы даже не могли точно сказать, сколько человек работает в управляющей компании", то есть, другими словами, не можете пройти джуновское собеседование на 1С или SQL.
Мне кажется, что это относительно несложно. Главное - перевести описание проекта на английский + разместить на reddit небольшую статью. Делайте свою работу доступной англоязычной аудитории, и, если она содержит какое-то мало-малькси интересное зерно, внимание к проекту будет. Как пример - мой крошечный пет flywheel c 75 звездочками или роадмап по Python (в тему статьи, кстати) pyroad c 340 звёздочками. Но я не уверен, что звёзды конвертируются в офферы, так что это скорее хоббийная история.
Pyroad, я, кстати, потихоньку превращаю в отдельный сайт pyroadmap.com, где, в отличие от очень уважаемого мной roadmap.sh, пытаюсь пометить цветом (зелёный, жёлтый, красный) учебные треки для junior, middle и senior соответственно. Так что, если вы только начинаете изучение Python и немножко офигеваете от обилия информации, попробуйте последовательно пройтись по зелёным пунктам путеводителя или хотя бы используйте эту информацию для разработки своего собственного учебного трека.
Если я правильно помню (пусть старшее поколение меня поправит), такой подход имеет корни как минимум в шестидесятых. Тогда тоже была надежда, что вот сейчас составим библиотеку всех потребных численных методов, вроде определения арктангенса, расчёта ФОТ и движения тела в атмосфере, а потом нагрузка на программиста существенно снизится.
Всё верно, именно пирог размером одного порядка с мировым ВВП сейчас и предлагают на рассмотрение инвесторам. В расчёте, разумеется, что нынешние модели удастся допилить до состояния, когда они будут способны конкурировать за рабочие места с человеком.
Насчёт полок вы, по-моему, сгущаете краски. Ручной пробойник в виде толстостенной металлической трубки с коронковой рабочей частью достаточно легко проходил сквозь бетон, на внешнюю, не несущую стену бетонной девятиэтажки (там марка цемента пожиже) даже я, будучи ребёнком, повесил часы.
Но, конечно же, с перфоратором это не сравнить и для нормальной каждодневной работы совершенно не подходит.
По-моему, в "Оппенгеймере" дискутируется не вопрос подогрева воздуха, а возможность реакции атмосферы, для которой первоначальный атомный взрыв будет лишь "активатором". Физики на этом этапе опасались уничтожить вообще всю Землю.
Просто делают процесс увольнения чуть менее комфортным, сотрудник подсознательно боится потерять свои ачивки.
Был. Не подтверждаю.
Да, статья странная. Вроде разумно рассуждают, "с одной стороны", "с другой стороны", но смысл статьи утекает сквозь пальцы.
Возможно, @Anarchist хотел сказать, что текст прихрамывает, периодически противореча самому себе; и я с ним полностью согласен.
Например, общему посылу статьи "Мы тут все такие демократичные, молодёжные, современные, быстро собесим сразу с лидом" противоречат напоминания "Не забудьте составить сладенькое сопроводительное письмо" или "Можем тиснуть вас на временный контракт, чтобы переложить все головняки с компании на работягу".
Все эти милые кусочки программ на ассемблере хороши и ламповы, когда рассматриваешь их изолированно, с подробным комментарием и в ностальгическом контексте. А вот когда пытаешься пытаешься написать на ассемблере относительно сложную, контролируемую и сопровождаемую систему, то литературного слога очень скоро начинает не хватать...
Вы напрасно перегибаете рекламную палку, пытаясь создать иллюзию неземной лёгкости перехода от коробки к дому. В целом по тексту вы достаточно аккуратно обходите вопрос суммарной стоимости и сроков строительства, но вот в этом абзаце рука у автора явно дрогнула.
Однажды, снимая костюм химической защиты, вы с улыбкой нащупаете одноразовую маску в кармане старого плаща...
У моей старенькой мамы есть городской. Полгода не было звонков ни от кого, кроме спамеров, я просто отключил звук звонка.
Против смазываний можно попробовать высокопольные 3 Тл МРТ. В моём городе есть один такой, в рекламе утверждается, что "вы можете продолжать дышать во время сканирования брюшной полости" :)
Есть варианты, типа пять капель раствора йода на стакан молока. Но это для особых случаев, вроде радиоактивного заражения местности.
Прямо Кримпай Можайский из "Лампы Мафусаила" Пелевина.
Вы напрасно так упираете на это "снизу"; центр тяжести всей конструкции всё равно не должен выходить за боковую грань нижнего кирпича.
Без структур данных действительно мало что получится. Цитируя Торвальдса, "Плохие программисты беспокоятся о коде. Хорошие программисты беспокоятся о структурах данных и их взаимосвязях".
Но структура данных ≠ схема данных. Возможно, вам для бизнес-логики оптимально подойдёт красно-чёрное или префиксное дерево, и заранее засовывать его в прокрустово ряляционное ложе было бы, на мой взгляд, большой ошибкой.
Если я правильно понимаю чистую архитектуру:
бизнес-логика - это то, чем люди будут заниматься даже при отсутствии какой-либо вычислительной техники вообще; скажем, банкиры будут считать сложный процент, а астрофизики - параметры звёзд, даже если у них останется только бумажка с ручкой; соответственно, при создании модели вообще про такие вещи, как зеркалирование, SQL, NoSQL думать нельзя, это инфицирует бизнес-логику чуждым кодом;
можно сказать, что вообще "никто не first"; Роберт Мартин особо подчёркивал (и даже гордился), что БД - это такой же легко заменяемый сегмент внешнего круга ПО, как, скажем, веб-интерфейс (с учётом реального положения дел, такое, конечно, можно встретить нечасто), и "проблемы базы шерифа не волнуют";
консистентность и правда хромает.
Но это, разумеется, только один из подходов к проектированию ПО, абсолютизировать его было бы неразумно.