С ним вообще весело пипец, даже если принять количественную величину на веру для ясности
Он фрактальный - если, скажем, в коллективе в котором 20% людей делают 80% работы отделить успешную выборку - они так же поделятся (даже если он один - по этому же принципу он 80% времени делает якобы незначимую фигню, а из 20% еще 80% тоже не такую значимую, итд)
Есть еще веселый эффект бабочки, который утверждает даже что самый малозначительный из факторов в неэффективных 80% может значительно повлиять остальные на 20%, но это случится не в первой итерации фрактала, а на достаточно удаленных его итерациях. Тут у нас расстоянием до другого конца планеты служит глубина анализа самых значимых факторов и разложение их на факторы поменьбше.
Очень примитивный пример: сотрудник Вася постоянно травит анекдоты в курилке и самый плохой работник месяца, сотрудник Петя самый результативный работник месяца. С первого взгляда Вася влияет на общий результат никак или очень мало (нормировка вклада от нуля, без отрицательных значений). Однако отбросив Васю как сырой фактор и детально прорабатывая Петины действия в течение месяца мы обнаруживаем что гениальная идея сильно повлиявшая на результат пришла Пете в курилке, когда он услышал анекдот от Васи (итерируем по фракталу Петиных действий, расщепляя их и отбрасывая 80% по влиянию на результат). И вот нам уже надо менять вес Васиного вклада в результат, но мы этого конечно делать не будем, потому что Вася раздолбай и нормально не умеет работать. Мы его уволим и возьмем Гену. Гена умный парень, результаты Пети, который хорошо общался с Васей возможно чуть упадут, но зато ему надо будет меньше вкалывать
Пока писал еще подумал еще про одну забавную связь Парето и каузальной атрибуции: Вася и Петя появились в одном отделе по-разному: Петя на 80% старался и ему на 20% повезло, а Вася на 20% старался и на 80% ему повезло, но оба считают что они молодцы.
Ну то есть в итоге контингент в основном это X-Y-Z. У которого такой дихотомии нет. Особенно смешно миллениалам, про которых медиа несли абсолютно ту же чушь что сейчас про зумеров еще лет 10-15 назад, а потом переключились на свежее поколение не меняя риторики. У людей чисто по субкультурным пристрастиям различий больше. Или по региональным. Но подаем как дихотомию, заметая все иксы и игреки под ковер к бумерам. Окей, чо. Я не то чтобы на вас наехать хочу, просто замечаю что сводить к дихотомии бумер-зумер это такой вот и есть неосознанный эйджизм. Как и то что саксесс-стори с возрастными людьми всегда пахнут немного как "ой вы посмотрите кто не накрылся своей простыней и не пополз на кладбище, как мило".
Индустрия взрослеет. Двадцать лет назад она была не такой большой и найти программиста с опытом в те же двадцать лет было очень и очень сложно. Так что в целом она была моложе. Но тогда же она и росла уже ударными темпами - в нее пришла куча людей которые к настоящему времени обзавелись теми самими двадцатью годами опыта. Как только появляется существенный разброс возрастов - начинается рефлексия. В частности появляется и эйджизм в обе стороны. И он никуда не уйдет, все с ним живут, во всех профессиях. "Мерзкий старикашка" и "заносчивый щенок" - стереотипные персонажи не просто так.
Это не возрастное. Точно так же пациенты слегка за двадцать заявляют что-то вроде "sql-базы устарели", или "везде интернет, так что надо писать только тонкие клиенты". Устраиваясь на проект мобильной кассы.
Хотя потом такой гражданин может подымить о том что деды навертели старых технологий и не берут молодых-продвинутых на нормальную зарплату.
Неважна мотивация и возраст персонажа с таким подходом. Равно как и его профессиональный уровень. С ним просто не получится сделать дело. Так что ну его нафиг.
еще бы неплохо научиться использовать Task.Delay вместо Thread.Sleep в асинхронном контексте выполнения
а то неясно что тестим, блокируя заранее неизвестный тред
это собственно и было значением фразы "тут нет тредов"
про них тут неизвестно, они вынесены за рамки этого кода, так что не надо их трогать
блокирующие тред операции должны быть заботливо упакованы в асинк-методы, которые не заблочат тред их вызывающий (скажем есть foo которая слипит тред на секунду - она же его в самом примитивном виде и должна породить, вернуть управление и по завершению работы в треде - вернуть результат в таск), потому что тот в свою очередь может быть например тредом ui или еще каким синглтредовым контекстом обвязан и там все от блокирующей операции колом встанет
я второй раз прошу автора заняться изучением теории асинхронщины
посмотреть статьи про сами реализацию асинк-эвейт например, а не шлепать непонятные примеры чтобы доказать что асинхронный код является причиной продуцирования тредов
он является, но это никак не противоречит фразе there is no thread потому что в реализации асинк-эвейтов, корутин, фьючей и прочей асинхронной дребедени нет продуцирования тредов, этим занимаются тредпулы в обвязке - контекст выполнения собственно стейт-машин асинхронщиной занимающихся, в котлин-корутинах, например их еще и наглядно можно задавать, а сама асинхронщина ближе всего к понятию "плоские коллбеки", которые и есть этот ваш тру-асинк
"Рабочая импотенция", девушка, бывает только одного типа. Это когда у вас "не встает" на рабочие задачи. Куража нет. Вы не способны провалиться в решение и потом "ой, тля, уже стемнело". Вы не обнаруживаете себя сидящим в три ночи в обнимку с так и недопитой бутылкой вина, играясь с какой-нить новой графической библиотекой которую вы сами себе сделали для рабочих задач в нерабочее время. Вам вообще неинтересно то что вы делаете. Вот это - она.
И от такой работы конечно надо бежать на собесы. И там искать именно то что зацепит в первую очередь. А лень - нужный и важный компонент вашей жизни, помогающий вам выжить на марафонской дистанции своей карьеры. Лениться надо уметь так же как учиться и работать. Невозможно пробежать марафон спринтами и не навредить себе. Нормальный график любой человеческой активности - синусоида.
У меня за 22 года трудовая подраспухла, периодически я менял стеки и начинал с младших позиций. Но вот что-то ни разу не случалось такого чтобы я стагнировал на продукте, даже просидев на нем рекордные 5 лет подряд. Потому что нормальный продукт живой - он поддерживается, обслуживается и рефакторится постоянно. В нем обновляются технологии. Ему постоянно нужны решения, ставящие перед инженером необходимость изучения чего-то нового. И, кстати, получение вот этого самого "опыта полного цикла", если повезет еще и с выводом из эксплуатации - серьезная вещь. Я последний раз полгода искал сеньора не с лычкой и знанием букваря от корки до корки, а именно опытом "сам седелал мвп, сам из него выстругал буратину и потом с этой буратиной не потонул - и крылья пришил и остальные хотелки-перделки и на орбиту вывел". Нашел, кстати. Причем взял даже не сойдясь во взглядах на архитектурные подходы. Именно за то что он умеет жить с тем что сам понаворотил, собрал все грабли которые мог и готов отвечать за этот свой подход.
Так что желаю вам поработать в хорошем продукте и вдумчиво. Там может быть максимально весело, если действительно любите свою работу.
на рынке мало квалифицированных специалистов, но они есть - периодически выходят на рынок
среди квалифицированных еще меньше специалистов квалифицированных не только в области своих обязанностей как таковых, но и в методах прохождения заградительных фильтров
постоянно усложняющийся за последние лет двадцать процесс найма мешает собственно задачам найма - поженить проект с подходящим ему специалистом именно с подходящим, а не умеющим получать офферы, надрессироваться их получать можно, это отдельное время и отдельный опыт
и сверху еще отягчающее - я тоже неоднократно участвовал в найме в продуктовых компаниях, сразу срезав кучу фильтров до попытки определения непосредственно нужных навыков, так вот по результатам я вижу что процесс найма портит и рынок кандидатов, они не готовы говорить по существу, они готовятся к этой дурацкой пародии на экзамен
В какую другую? На запад же. А лево-право тут сложно применять.
Вот вы щас техдолг себе и сделали на ровном месте. Не определили систему сторон света и привязали к рукам наблюдателя. Потому что по первоначальной задаче он неподвижный и наблюдает солнце со своего полушария лицом к противоположному полюсу. А потом крутим фичу чтобы наблюдатель вертелся и - надо делать нормально.
Вы всегда будете пытаться заставить что-то работать. Большую часть времени это будет не код. Сюрприз, ваш уже написанный код будет всегда ужасен, но дизайн (ака архитектурный подход здесь и далее) возможно будет когда-то неплох.
Ищите мудрость в книгах по программированию.
И не найдите, потому что любая теория суха, а древо жизни зеленеет в листах. В книгах много воды, прочухать очередной помогающий делу подход куда больше помогают короткие статьи и опыт наступания на грабли при выборе неверного дизайна. Так что делать плохо чтобы увидеть последствия - необходимо. Книги тут и не помогут и не помешают, просто займут время. Время которое можно с пользой для дела выстрелить себе в ногу и другие части тела. Начинать надо с документации и реальных задач. Книги идут паровозиком, как факультатив, после.
Создайте собственный кодерский проект.
И не получите ровно ничего, если он не завязан на реальную проблему, фидбеки, фичареквесты, если он не бьет вас по рукам всякий раз когда сталкивается с реальностью сидя в глубине своего приватного репозитория. Создайте свою библиотеку для решения вашей боли в текущем рабочем проекте, это - поможет.
Углубленная практика алгоритмов.
Научит вас проходить алгоритмические секции в компании где после пары лет работы вы навсегда потеряете навыки, собственно, программирования. Больше оно собственно ни за чем не нужно. Не, ну можно еще затусить на спешал олимпикс для программистов которые на самом деле не программируют.
Погружение в открытый исходный код.
А еще можно покопаться в чужом мусоре с тем же успехом, возможно там найдется что-то стоящее. Есть реальная проблема которую вам нужно решить с чьей-то либой в вашем проекте? Форкаете, потом делает ПР/МР, если репа еще живая. Но бога ради не на общественных началах. Весь нормальный опенсорс - не на общественных началах.
Продолжайте стремиться к росту.
Думаю на следующей неделе наберу еще пару килограмм. Думаю все же надо определиться с тем что именно интересно, а там уже и вопросов с мотивацией не будет, не заметите как станете расти.
Вы вот реально с этим пришли к профсообществу? Откуда?
Я всякое встречал. И это тоже. Качественно по этому показателю ничем именно русские компании не отличаются. Напомню что практика 4-х часовых марафонов алгоритмического онанизма она не от русских компаний родом.
это я себе говорю, вслух просто, а то что гоняют это я в курсе, тем забавнее на них ходить когда сам параллельно ищешь сеньоров по совсем другим критериям
А потом приходит понимание что то что ты считал "софтами" вполне "харды". Потому как у хорошего инженера есть как минимум три ответа на "когда" и "как дорого" - все с разными цифрами.
Юнит-тесты не про архитектуру. Вообще именно юнит-тестирование переоценено. Но подачу принял. Надо было дальше пойти по солиду:
Если классы должны быть закрыты для модификации и доступны для переопределения зачем тогда во многих апи используют final?
Если функции должны использовать наследника не зная об этом то зачем тогда sealed?
Если многие простые интерфейсы проще чем один сложный то почему всегда не использовать функциональные интерфейсы, или вовсе анонимные функциональные типы?
Насколько глубока кроличья нора абстракций? Если я с одного перехода в IDE вижу кто создает экземпляр имплементации интерфейса, то почему это плохой и неправильный DI, а правильный там где я его ищу полдня чертыхаясь и матерясь?
решение неформализованной задачи начинается с допроса с пристрастием всех к ней причастных и никак иначе
С ним вообще весело пипец, даже если принять количественную величину на веру для ясности
Он фрактальный - если, скажем, в коллективе в котором 20% людей делают 80% работы отделить успешную выборку - они так же поделятся (даже если он один - по этому же принципу он 80% времени делает якобы незначимую фигню, а из 20% еще 80% тоже не такую значимую, итд)
Есть еще веселый эффект бабочки, который утверждает даже что самый малозначительный из факторов в неэффективных 80% может значительно повлиять остальные на 20%, но это случится не в первой итерации фрактала, а на достаточно удаленных его итерациях. Тут у нас расстоянием до другого конца планеты служит глубина анализа самых значимых факторов и разложение их на факторы поменьбше.
Очень примитивный пример: сотрудник Вася постоянно травит анекдоты в курилке и самый плохой работник месяца, сотрудник Петя самый результативный работник месяца. С первого взгляда Вася влияет на общий результат никак или очень мало (нормировка вклада от нуля, без отрицательных значений). Однако отбросив Васю как сырой фактор и детально прорабатывая Петины действия в течение месяца мы обнаруживаем что гениальная идея сильно повлиявшая на результат пришла Пете в курилке, когда он услышал анекдот от Васи (итерируем по фракталу Петиных действий, расщепляя их и отбрасывая 80% по влиянию на результат). И вот нам уже надо менять вес Васиного вклада в результат, но мы этого конечно делать не будем, потому что Вася раздолбай и нормально не умеет работать. Мы его уволим и возьмем Гену. Гена умный парень, результаты Пети, который хорошо общался с Васей возможно чуть упадут, но зато ему надо будет меньше вкалывать
Пока писал еще подумал еще про одну забавную связь Парето и каузальной атрибуции: Вася и Петя появились в одном отделе по-разному: Петя на 80% старался и ему на 20% повезло, а Вася на 20% старался и на 80% ему повезло, но оба считают что они молодцы.
Не отпускает первое апреля короче.
Я тоже умею в занимательную статистику. Подержите мое пиво.
У 80% сотрудников HR когнитивные способности недостаточны для оценки кандидатов.
У 80% кандидатов когнитивные способности недостаточны для выполнения работы.
У 80% авторов хабра когнитивные способности недостаточны для того чтобы быть авторами технических статей.
У 80% комментаторов недостаточные когнитивные способности чтобы адекватно воспринять и прокомментировать статью по существу.
У 80% людей которые затирают про статистику цифры берутся с потолка.
Ну привет, заканчивается. Там ты такой красивый румяный сорокалетний будешь за пивом бегать олдскульным бородачам, потому что молодой ещо.
Ну то есть в итоге контингент в основном это X-Y-Z. У которого такой дихотомии нет. Особенно смешно миллениалам, про которых медиа несли абсолютно ту же чушь что сейчас про зумеров еще лет 10-15 назад, а потом переключились на свежее поколение не меняя риторики. У людей чисто по субкультурным пристрастиям различий больше. Или по региональным. Но подаем как дихотомию, заметая все иксы и игреки под ковер к бумерам. Окей, чо. Я не то чтобы на вас наехать хочу, просто замечаю что сводить к дихотомии бумер-зумер это такой вот и есть неосознанный эйджизм. Как и то что саксесс-стори с возрастными людьми всегда пахнут немного как "ой вы посмотрите кто не накрылся своей простыней и не пополз на кладбище, как мило".
Индустрия взрослеет. Двадцать лет назад она была не такой большой и найти программиста с опытом в те же двадцать лет было очень и очень сложно. Так что в целом она была моложе. Но тогда же она и росла уже ударными темпами - в нее пришла куча людей которые к настоящему времени обзавелись теми самими двадцатью годами опыта. Как только появляется существенный разброс возрастов - начинается рефлексия. В частности появляется и эйджизм в обе стороны. И он никуда не уйдет, все с ним живут, во всех профессиях. "Мерзкий старикашка" и "заносчивый щенок" - стереотипные персонажи не просто так.
Это не возрастное. Точно так же пациенты слегка за двадцать заявляют что-то вроде "sql-базы устарели", или "везде интернет, так что надо писать только тонкие клиенты". Устраиваясь на проект мобильной кассы.
Хотя потом такой гражданин может подымить о том что деды навертели старых технологий и не берут молодых-продвинутых на нормальную зарплату.
Неважна мотивация и возраст персонажа с таким подходом. Равно как и его профессиональный уровень. С ним просто не получится сделать дело. Так что ну его нафиг.
Хм. Я не помню методичек на всё.
еще бы неплохо научиться использовать Task.Delay вместо Thread.Sleep в асинхронном контексте выполнения
а то неясно что тестим, блокируя заранее неизвестный тред
это собственно и было значением фразы "тут нет тредов"
про них тут неизвестно, они вынесены за рамки этого кода, так что не надо их трогать
блокирующие тред операции должны быть заботливо упакованы в асинк-методы, которые не заблочат тред их вызывающий (скажем есть foo которая слипит тред на секунду - она же его в самом примитивном виде и должна породить, вернуть управление и по завершению работы в треде - вернуть результат в таск), потому что тот в свою очередь может быть например тредом ui или еще каким синглтредовым контекстом обвязан и там все от блокирующей операции колом встанет
я второй раз прошу автора заняться изучением теории асинхронщины
посмотреть статьи про сами реализацию асинк-эвейт например, а не шлепать непонятные примеры чтобы доказать что асинхронный код является причиной продуцирования тредов
он является, но это никак не противоречит фразе there is no thread потому что в реализации асинк-эвейтов, корутин, фьючей и прочей асинхронной дребедени нет продуцирования тредов, этим занимаются тредпулы в обвязке - контекст выполнения собственно стейт-машин асинхронщиной занимающихся, в котлин-корутинах, например их еще и наглядно можно задавать, а сама асинхронщина ближе всего к понятию "плоские коллбеки", которые и есть этот ваш тру-асинк
"Рабочая импотенция", девушка, бывает только одного типа. Это когда у вас "не встает" на рабочие задачи. Куража нет. Вы не способны провалиться в решение и потом "ой, тля, уже стемнело". Вы не обнаруживаете себя сидящим в три ночи в обнимку с так и недопитой бутылкой вина, играясь с какой-нить новой графической библиотекой которую вы сами себе сделали для рабочих задач в нерабочее время. Вам вообще неинтересно то что вы делаете. Вот это - она.
И от такой работы конечно надо бежать на собесы. И там искать именно то что зацепит в первую очередь. А лень - нужный и важный компонент вашей жизни, помогающий вам выжить на марафонской дистанции своей карьеры. Лениться надо уметь так же как учиться и работать. Невозможно пробежать марафон спринтами и не навредить себе. Нормальный график любой человеческой активности - синусоида.
У меня за 22 года трудовая подраспухла, периодически я менял стеки и начинал с младших позиций. Но вот что-то ни разу не случалось такого чтобы я стагнировал на продукте, даже просидев на нем рекордные 5 лет подряд. Потому что нормальный продукт живой - он поддерживается, обслуживается и рефакторится постоянно. В нем обновляются технологии. Ему постоянно нужны решения, ставящие перед инженером необходимость изучения чего-то нового. И, кстати, получение вот этого самого "опыта полного цикла", если повезет еще и с выводом из эксплуатации - серьезная вещь. Я последний раз полгода искал сеньора не с лычкой и знанием букваря от корки до корки, а именно опытом "сам седелал мвп, сам из него выстругал буратину и потом с этой буратиной не потонул - и крылья пришил и остальные хотелки-перделки и на орбиту вывел". Нашел, кстати. Причем взял даже не сойдясь во взглядах на архитектурные подходы. Именно за то что он умеет жить с тем что сам понаворотил, собрал все грабли которые мог и готов отвечать за этот свой подход.
Так что желаю вам поработать в хорошем продукте и вдумчиво. Там может быть максимально весело, если действительно любите свою работу.
не совсем так
на рынке мало квалифицированных специалистов, но они есть - периодически выходят на рынок
среди квалифицированных еще меньше специалистов квалифицированных не только в области своих обязанностей как таковых, но и в методах прохождения заградительных фильтров
постоянно усложняющийся за последние лет двадцать процесс найма мешает собственно задачам найма - поженить проект с подходящим ему специалистом именно с подходящим, а не умеющим получать офферы, надрессироваться их получать можно, это отдельное время и отдельный опыт
и сверху еще отягчающее - я тоже неоднократно участвовал в найме в продуктовых компаниях, сразу срезав кучу фильтров до попытки определения непосредственно нужных навыков, так вот по результатам я вижу что процесс найма портит и рынок кандидатов, они не готовы говорить по существу, они готовятся к этой дурацкой пародии на экзамен
Для начала
Что такое асинхронное выполнение и какими инструментами его можно добиться
Что такое континуации/фьючи
причем тут коллбеки
что такое контекст выполнения асинхронных функций и методов в языках с поддержкой тредов
чем отличаются точные науки (например программирование) от религиозной горячки
В какую другую? На запад же. А лево-право тут сложно применять.
Вот вы щас техдолг себе и сделали на ровном месте. Не определили систему сторон света и привязали к рукам наблюдателя. Потому что по первоначальной задаче он неподвижный и наблюдает солнце со своего полушария лицом к противоположному полюсу. А потом крутим фичу чтобы наблюдатель вертелся и - надо делать нормально.
С 2011 пишу под дроид. Так вот. А что я щас такое прочитал?
Итак, давайте по пунктам
Введение.
Вы всегда будете пытаться заставить что-то работать. Большую часть времени это будет не код. Сюрприз, ваш уже написанный код будет всегда ужасен, но дизайн (ака архитектурный подход здесь и далее) возможно будет когда-то неплох.
Ищите мудрость в книгах по программированию.
И не найдите, потому что любая теория суха, а древо жизни зеленеет в листах. В книгах много воды, прочухать очередной помогающий делу подход куда больше помогают короткие статьи и опыт наступания на грабли при выборе неверного дизайна. Так что делать плохо чтобы увидеть последствия - необходимо. Книги тут и не помогут и не помешают, просто займут время. Время которое можно с пользой для дела выстрелить себе в ногу и другие части тела. Начинать надо с документации и реальных задач. Книги идут паровозиком, как факультатив, после.
Создайте собственный кодерский проект.
И не получите ровно ничего, если он не завязан на реальную проблему, фидбеки, фичареквесты, если он не бьет вас по рукам всякий раз когда сталкивается с реальностью сидя в глубине своего приватного репозитория. Создайте свою библиотеку для решения вашей боли в текущем рабочем проекте, это - поможет.
Углубленная практика алгоритмов.
Научит вас проходить алгоритмические секции в компании где после пары лет работы вы навсегда потеряете навыки, собственно, программирования. Больше оно собственно ни за чем не нужно. Не, ну можно еще затусить на спешал олимпикс для программистов которые на самом деле не программируют.
Погружение в открытый исходный код.
А еще можно покопаться в чужом мусоре с тем же успехом, возможно там найдется что-то стоящее. Есть реальная проблема которую вам нужно решить с чьей-то либой в вашем проекте? Форкаете, потом делает ПР/МР, если репа еще живая. Но бога ради не на общественных началах. Весь нормальный опенсорс - не на общественных началах.
Продолжайте стремиться к росту.
Думаю на следующей неделе наберу еще пару килограмм. Думаю все же надо определиться с тем что именно интересно, а там уже и вопросов с мотивацией не будет, не заметите как станете расти.
Вы вот реально с этим пришли к профсообществу? Откуда?
Я всякое встречал. И это тоже. Качественно по этому показателю ничем именно русские компании не отличаются. Напомню что практика 4-х часовых марафонов алгоритмического онанизма она не от русских компаний родом.
это я себе говорю, вслух просто, а то что гоняют это я в курсе, тем забавнее на них ходить когда сам параллельно ищешь сеньоров по совсем другим критериям
кстати, вот что надо на собесе спрашивать, а не "расшифруйте мне солид"
А потом приходит понимание что то что ты считал "софтами" вполне "харды". Потому как у хорошего инженера есть как минимум три ответа на "когда" и "как дорого" - все с разными цифрами.
Юнит-тесты не про архитектуру. Вообще именно юнит-тестирование переоценено. Но подачу принял. Надо было дальше пойти по солиду:
Если классы должны быть закрыты для модификации и доступны для переопределения зачем тогда во многих апи используют final?
Если функции должны использовать наследника не зная об этом то зачем тогда sealed?
Если многие простые интерфейсы проще чем один сложный то почему всегда не использовать функциональные интерфейсы, или вовсе анонимные функциональные типы?
Насколько глубока кроличья нора абстракций? Если я с одного перехода в IDE вижу кто создает экземпляр имплементации интерфейса, то почему это плохой и неправильный DI, а правильный там где я его ищу полдня чертыхаясь и матерясь?
а можно еще "ку" и присесть два раза
но это если штаны малиновые