Сам работал 8 лет на заводе и пару раз "подгорел". Согласен только с одним пунктом
В IT больше необычных(странных, замкнутых и т.д.) людей, чем в других сферах - соответственно, у них больше необычных проблем (тараканов), Что и приводит к повышеному проценту выгораний
Мое мнение на этот счёт - айтишники, в большинстве случаев, достаточно молоды и получают хорошие деньги. Что позволяет им перейти из режима "не сдохнуть с голоду" в режим -"в чем смысл жизни и мое предназначение". Простого ответа на этот вопрос нет, да ещё и с ютуба-инстаграмма постоянно втирают, что нельзя просто перерабатывать воздух в метан и со2, А НУЖНО ДЕЛАТЬ ЧТО-ТО ПО-НАСТОЯЩЕМУ ВАЖНОЕ (для кого?почему? Делает ли кот или рыба что-то важное?) - отсюда и всяческие метания, сомнения и поиски.
На заводе денег платят сильно меньше и люди там в среднем проще, потому и горят не так как в айтишке, но тоже бывает.
Одно время работал менеджером по продажам 1С. Работал недолго, получалось плохо, но суть в другом - там я научился тому, что помогло мне в решении многих проблем в жизни, в т.ч. поиске работы. Кратко можно передать это анекдотом:
В конторе, продающей трубы, был туповатый менеджер, который при этом всегда стабильно делал план по продажам. Решили посмотреть, как он работает.
Утром приходит на работу, открывает справочник телефонов на том месте, где остановился накануне, и тупо звонит по списку: "Здравствуйте, вам трубы нужны? Нет? Жаль". И дальше по списку.
Слушали-слушали. Спрашивают его:
- А ты не пробовал что-то изменить?
- Что, например?
- Ну, например, спросить: "А вашим знакомым?"
- О! А это идея! - сказал менеджер и на следующий месяц удвоил прпродажи
Все знают, что чтобы научиться ходить - надо пытаться ходить. Чтобы научиться читать - надо читать. Чтобы найти работу - надо искать работу. Это ключевое. Не посещать митапы, не проходить тысячи курсов, а искать работу. Все остальное тоже имеет значение, но не решающее. Да и к тому же это все делать легче, чем каждый день бомбить все возможные контакты и вакансии в попытке попасть на собес, поэтому мозг с радостью будет стараться вас переключить на эту деятельность.
На собесе надо продавать себя так, чтобы все хотели тебя купить. Открою большую тайну, в обществе профессиональных продавцов - "впаривать", "втюхивать" товар, считается зашкваром - это плохо для бизнеса. Потому что клиент, которому ты что-то впарил, а ему это по факту не походит, к тебе больше не придет и другим будет рассказывать, что ты конченый тип. На собесах та же история - ты должен быть уверен в себе (в своем товаре), показывать себя с самых лучших сторон и рассказывать как ты поможешь команде делать больше и лучше. Если что-то не знаешь и не умеешь (у товара некоторые характеристики не очень) - молчи об этом, пока не спросят напрямую. Спросили - отвечай как есть, но с таким видом, мол "это вообще несущественный недостаток". НИКОГДА не показывай свою неуверенность - да, будут собеседующие, которым это не понравится - но это душнилы по определению и лучше с такими не работать.
Если продажа не состоялась - продолжай "бомбить". Попутно подтяни вопросы, которые завалил. Но будь готов, что "обзвонить" придется тысячу контактов, чтобы найти работу.
Чтобы сократить это количество, старайся подходить индивидуально к, по настоящему, интересным тебе вакансиям: прочитай про компанию, изучи продукты, стек. Напиши проникновенное сопроводительное письмо ("ваш продукт х - просто пушка, спасает людей и планету. Хочу стать частью команды, которая так меняет мир"). Говори то, что люди хотят услышать, но не ври про свои технические навыки (приукрасить можно, например, если у тебя спрашивают "есть опыт работы с БД?", а ты только в sqlite сделал три инсерта, два апдейта - говори, да есть. Уточняют ? Отвечай как есть. Не уточняют - сам глубже не лезь)
Если подытожить - мы каждый день что-то продаем: себя - красивой девушке, новую фичу - бизнесу, срок выполнения задачи - менеджеру. Поиск работы - это продажа себя нанимателю. На каком-то уровне ты станешь золотом, которое тысячи HR будут искать просеивая линкедин. Но пока ты кусок засохшей сливы - надо искать покупателя самому. И помни о том, что как в интернете действует правило 34, так и в продажах на любую фигню найдется покупатель.
Я то самый свитчер с завода. Ещё на заводе выработал простые правила:
Обед это святое. В очень крайнем, исключительном случая я мог его перенести на другое время. Это все знали и принимали.
Выхожу за порог завода - про работу не думаю.
Переработки либо по настоятельной просьбе руководства (с соответствующей оплатой), либо по собственной инициативе (как правило, это ставочка на премию) - последнее крайне редко и в случаях, когда незначительная задержка даст существенный выхлоп.
Когда перешел в айтишку, сразу на удалёнку, проблем не возникло. Работаю с 8 до 17, обед с 13 до 14. Закрыл ноут - про работу забыл.
Два чая этому господину. Если дорога до офиса занимает больше чем 15 минут пешком - я буду ходить туда только если зпха будет х2 от рынка. Будь он хоть тыщу раз классный и клёвый и с цветами и столовыми и велосипедами.
Я понимаю, зачем это нужно компании, но для меня офис - это место для работы. Работаю я по графику указанному в трудовом договоре (за исключением редких случаев, когда надо задержаться на пользу команде). В рабочее время я не играю в приставку, настольный теннис, не сплю, не жру бесплатную еду и не гоняю чаи.
Поболтать с коллегами - это да, но в большинстве случаев это вредно для работы (но хорошо для психики).
В общем, я работаю из дома и не могу представить себе офиса, который мог бы меня соблазнить
Увидев в заголовоке "решаем реальные задачи" - надеялся, что тут будут какие-то кейсы из промышленной разработки, а по факту, очередные бесполезные "вася завел два будильника, посчитайте сколько раз он проспит"
Плюсую, у самого сколиоз поясничного отдела и из-за сидячей работы часто болела спина. Один раз даже так схватило, что неделю вставать не мог (причем при активном лечении). После этого пошел в тренажерный зал, с грамотным тренером и через год забыл про боли в спине. Как показывает практика, достаточно ходить два раза в неделю, хотя бы 6 месяцев в году(не подряд, а месяц- два занимаемся, потом пропускаем месяц-два) делая упражнения на спину - и этого хватает.
Ключевое здесь - правильная техника и не гнаться за большими весами
Зачастую приведенные ситуации - это не злая воля, а просто автоматическая реакция. Собеседующий, в первую очередь, должен уметь абстрагироваться от своих личных переживаний и опыта и смотреть на кандидата с точки зрения решаемой задачи.
Сможет ли этот человек делать то, что от него требуется? Сколько ресурсов нужно будет потратить на его (человека) "доработку"? И всегда помнить, что испытательный срок (в РФ) - 3 месяца и он позволяет уволить любого без особых сложностей (кроме женщин ушедших в декрет в этот период).
Я, когда нанимал людей (инженеров на завод), задавал технические вопросы только с целью отсеять тех, кто вообще не шарит. Для меня важнее было то, как человек умеет общаться, что он делал до этого и почему ушел с прошлого места работы. Всем кандидатам говорил, что испытательный срок 3 месяца, описывал свои ожидания по его окончании, что должен делать, уметь и т.д.
И тех, кто производил хорошее впечатление - котелок варит, общаться с людьми умеет, умеет решать сложные задачи (не сдается) - брал на испыталку и смотрел выхлоп. Слабый выхлоп или много геммороя - обсуждаем отчего, почему, чем помочь. Если по итогу 2 месяцев и 3х недель меня что-то сильно не устраивает и я не вижу возможности это исправить - жаль, но ставочка не сыграла, "наша компания вам не подходит, всех благ!"
Про lru_cache: чтобы работало, нужно чтобы все аргументы функции были хэшируемыми.
Про декоратор @property: его назначение не только для организации сеттеров и геттеров, также используется для получения доступа к методу класса как к атрибуту. Т.е. можно будет вызывать его в виде Class.property, без скобок и т.д. Иногда очень упрощает понимание/нейминг
Читаю хабр лет десять. 5 лет назад (работал на заводе в это время), когда читал подобные, хм, "материалы" - думал, да, сложно быть программистом, нужно любить это дело, кодить на работе и после работы. Программиста окружают одни враги, не дают ему СОЗДАВАТЬ. Думал, это не мое, не смогу я так, я глупый и т.д.
2 года назад, посмотрев на свою зп(после 8 лет работы технологом на производстве) и зп джуна, решил, что, мое не мое - надо бы попробовать.
Отучился, устроился в контору бэкендером на питоне, год отработал и вот что имею сказать: промышленная разработка - это не про СОЗДАНИЕ, это очень похоже на производство машин или, скажем, электроники. Есть продукт-менеджер, который думает, что вот эта фича принесет денег. Твоя задача запилить ее и выкатить в прод. Желательно, чтобы посмотрев на свой код через полгода тебя не стошнило. Ну и тестами обмазать, чтобы не разваливалось. И все это происходит в конвеере: аналитик придумал алгоритм, ты его реализовал, Куэй протестил, выкатили на бой. Следующий!
Меня этот подход абсолютно устраивает, потому что я, как технолог, знаю, что лучше конвеера ничо не придумали со времен Форда. Более того, в этом есть кайф - ты оптимизируешь процесс, чтобы выдавать фичи как можно быстрее (что-то вроде ребят, которые на скорость игры проходят). Но я вижу у своих коллег (которые программисты по образованию и моложе лет на 7), что для многих это в тягость. Это же скучно, пилить такие простые фичи, вот если бы мир спасать.
В общем, это просто проблема восприятия. Бизнес фармит бабки, ты, как программист, пилишь свою часть продукта, также как сборщик на конвеере. Волнует ли хозяина завода как себя чувствует сборщик? - конечно, если сборщик будет грустный работа будет сделана плохо.
Очередная статья про "потоки, процессы и асинхронность" - зачем их столько? Хоть бы примеры какие-то из жизни привели, но нет все какая-то синтетическая копипаста.
Всю эту историю можно свести к тому, что там где код упирается в await - происходит переключение на следующую функцию с периодическим возвратом, пока она не вернет ответ.
А процессы работают через ProcessPoolExecutor, который инитится при старте приложения и, по необходимости, в него запихиваются нужные функции (и тоже периодически проверяется готовность результата)
Плюсую, самый удобный вариант. Сколько переводил - всегда было выгоднее чем золотой короной. Но надо проверять курс. Закидываете тестовую тыщонку и смотрите сколько тенге прилетело.
Самый выгодный был Юнистрим (получение в тенге), получать можно в отделении казпочты. Самый кайф в том, что тут же в казпочте можно купить доллары за тенге, причем по курсу выгоднее, чем если бы ты покупал нал. доллары а России
Если Эрик получает норм бабки и не хочет потерять свое место - яб на его месте, учитывая подходы маска к управлению, очень сильно посоветовался бы с HRом, что ответить на такое сообщение.
Я хоть за Маском особо и не слежу, уверен, что любой ответ кроме "сэр, мы ускорили твитор на 30% за последний год, сэр, и сделаем ещё больше под вашим мудрым руководством, сэр!!" его не устроит в любом случае
Без код ревью от более опытных коллег, к сожалению, спасения от говнокода нет.
Ситуацию могут облегчить книги и лекции Боба Мартина (чистый код, чистая архитектура) и какой-нибудь курс по шаблонам проектирования (именно на питоне, классическая книга банды четырех будет бесполезной тратой времени).
Сверху можно присыпать книгой с кабанчиком, но лучше найти способ показывать кому то свой код, если не целиком, то хотя бы структуру и какие-то основные элементы
Автор красиво расписал теорию (оно и понятно, не зря же он в скилбоксе преподает), но на практике все обычно сводиться к асинхронным i/o (fastapi, aiohttp), если сервис пишется свежий или django и flask, если уже на них многое реализовано(они тоже едут к асинхронщине). Если нужно чего-то посчитать тяжёлое - добавляют к асинхронщине ProcessPoolExecutor, с парой тройкой воркеров (тут главное правильно натыкать async/await и завернуть в нужный event loop и при этом поднять их при запуске сервиса, а не при запросе в него, иначе время на запуск процессов сожрёт весь профит). Но тут начинаются проблемы: если сервис крутится в кубере - нужно прописать правильные настроечки, чтобы ваш сервис не сожрал все свободные ядра.
Вообще, для меня, выглядит так, что потоки в питоне - это что-то ненужное и в промышленных решениях очень малоиспользуемое. Асинхронщина и многопроцессность - this is the way.
Я проработал инженером-технологом на заводе по производству электроники 8 лет. И я могу вам сказать, что есть люди, которые 20 лет паяют платы и делают это абсолютно хреново и есть люди, которые стараются каждый раз спаять лучше, чем в предыдущий - и за 3 года на две головы обгоняют "профессионалов" с 20 летним опытом. Это и есть развитие. Ты каждый раз стараешься сделать что-то лучше, чем в предыдущий.
Делать одно и то же 1000 раз - это не деградация. Делать 1000 раз одно и тоже _одним и тем же способом_ - это путь в утиль.
Вы, когда ходите в спортзал, постепенно увеличиваете нагрузку? Я уверен, что да. Это может быть увеличение на 5% в месяц, но оно есть. Потому что иначе, ваше тело тратит все меньше и меньше ресурсов на выполнение упражнений и приводит к тому, что форма не поддерживается.
Это тоже развитие. Любое движение вперёд и вверх - это развитие. Сегодня пожал на 200г больше, чем позавчера? - Красавчик, через год будешь жать на 365÷2×0,2=36.5кг больше. Но как только перестаешь накидывать вес - мозг оптимизирует работу мышц на
столько, что процесс жима будет потреблять меньше калорий, чем поход в магаз за хлебом.
К сожалению, в большинстве случаев, "адекватная культура" - это результат эволюции.
Я могу судить по себе - когда я был начинающем руководителем, я пытался везде внедрить новое, улучшить старое и вообще все перекроить по своему разумению (ну и по книжкам написанным Умными Людьми, разумеется). И, естественно, я встречал мощнейшее сопротивление, потому что никто, я повторюсь, НИКТО (да, даже ты, самый продвинутый чувак на планете) не любит изменения. Любые изменения, нужно продавать, и продавливать.
А для того чтобы их внедрять, нужно тонко разбираться в психологии людей с которыми ты работаешь. С кем то работает одно, с кем-то другое, всегда есть те, кто будет саботировать внедрение нового - и это норма, это всегда и везде так, потому что это внедрено в нас, людей, на уровне физиологии (мозг не предназначен для постоянной работы, жрет слишком много ресурсов).
Но в силу особенностей профессии (я думаю, никто не будет спорить, что навыки коммуникации среднего ITшника уступают навыкам коммуникации самого плохого менеджера по продажам машин) руководители выросшие в джунглях IT не обладают достаточным опытом внедрения изменений и управления этим процессом. Безусловно, многие этот опыт набирают в процессе, и про таких менеджеров никто нк говорит, но большинство пытается внедрять изменения насильно, заставляя всех чему-то учиться и как-то отчитываться, что приводит к полыханию на Хабре.
Вот это, кстати, отличный совет! Наберут на себя обязательств, а потом под их весом тонут )))
Сам работал 8 лет на заводе и пару раз "подгорел". Согласен только с одним пунктом
В IT больше необычных(странных, замкнутых и т.д.) людей, чем в других сферах - соответственно, у них больше необычных проблем (тараканов), Что и приводит к повышеному проценту выгораний
Мое мнение на этот счёт - айтишники, в большинстве случаев, достаточно молоды и получают хорошие деньги. Что позволяет им перейти из режима "не сдохнуть с голоду" в режим -"в чем смысл жизни и мое предназначение". Простого ответа на этот вопрос нет, да ещё и с ютуба-инстаграмма постоянно втирают, что нельзя просто перерабатывать воздух в метан и со2, А НУЖНО ДЕЛАТЬ ЧТО-ТО ПО-НАСТОЯЩЕМУ ВАЖНОЕ (для кого?почему? Делает ли кот или рыба что-то важное?) - отсюда и всяческие метания, сомнения и поиски.
На заводе денег платят сильно меньше и люди там в среднем проще, потому и горят не так как в айтишке, но тоже бывает.
Одно время работал менеджером по продажам 1С. Работал недолго, получалось плохо, но суть в другом - там я научился тому, что помогло мне в решении многих проблем в жизни, в т.ч. поиске работы. Кратко можно передать это анекдотом:
Все знают, что чтобы научиться ходить - надо пытаться ходить. Чтобы научиться читать - надо читать. Чтобы найти работу - надо искать работу. Это ключевое. Не посещать митапы, не проходить тысячи курсов, а искать работу. Все остальное тоже имеет значение, но не решающее. Да и к тому же это все делать легче, чем каждый день бомбить все возможные контакты и вакансии в попытке попасть на собес, поэтому мозг с радостью будет стараться вас переключить на эту деятельность.
На собесе надо продавать себя так, чтобы все хотели тебя купить. Открою большую тайну, в обществе профессиональных продавцов - "впаривать", "втюхивать" товар, считается зашкваром - это плохо для бизнеса. Потому что клиент, которому ты что-то впарил, а ему это по факту не походит, к тебе больше не придет и другим будет рассказывать, что ты конченый тип. На собесах та же история - ты должен быть уверен в себе (в своем товаре), показывать себя с самых лучших сторон и рассказывать как ты поможешь команде делать больше и лучше. Если что-то не знаешь и не умеешь (у товара некоторые характеристики не очень) - молчи об этом, пока не спросят напрямую. Спросили - отвечай как есть, но с таким видом, мол "это вообще несущественный недостаток". НИКОГДА не показывай свою неуверенность - да, будут собеседующие, которым это не понравится - но это душнилы по определению и лучше с такими не работать.
Если продажа не состоялась - продолжай "бомбить". Попутно подтяни вопросы, которые завалил. Но будь готов, что "обзвонить" придется тысячу контактов, чтобы найти работу.
Чтобы сократить это количество, старайся подходить индивидуально к, по настоящему, интересным тебе вакансиям: прочитай про компанию, изучи продукты, стек. Напиши проникновенное сопроводительное письмо ("ваш продукт х - просто пушка, спасает людей и планету. Хочу стать частью команды, которая так меняет мир"). Говори то, что люди хотят услышать, но не ври про свои технические навыки (приукрасить можно, например, если у тебя спрашивают "есть опыт работы с БД?", а ты только в sqlite сделал три инсерта, два апдейта - говори, да есть. Уточняют ? Отвечай как есть. Не уточняют - сам глубже не лезь)
Если подытожить - мы каждый день что-то продаем: себя - красивой девушке, новую фичу - бизнесу, срок выполнения задачи - менеджеру. Поиск работы - это продажа себя нанимателю. На каком-то уровне ты станешь золотом, которое тысячи HR будут искать просеивая линкедин. Но пока ты кусок засохшей сливы - надо искать покупателя самому. И помни о том, что как в интернете действует правило 34, так и в продажах на любую фигню найдется покупатель.
Я то самый свитчер с завода. Ещё на заводе выработал простые правила:
Обед это святое. В очень крайнем, исключительном случая я мог его перенести на другое время. Это все знали и принимали.
Выхожу за порог завода - про работу не думаю.
Переработки либо по настоятельной просьбе руководства (с соответствующей оплатой), либо по собственной инициативе (как правило, это ставочка на премию) - последнее крайне редко и в случаях, когда незначительная задержка даст существенный выхлоп.
Когда перешел в айтишку, сразу на удалёнку, проблем не возникло. Работаю с 8 до 17, обед с 13 до 14. Закрыл ноут - про работу забыл.
Два чая этому господину. Если дорога до офиса занимает больше чем 15 минут пешком - я буду ходить туда только если зпха будет х2 от рынка. Будь он хоть тыщу раз классный и клёвый и с цветами и столовыми и велосипедами.
Я понимаю, зачем это нужно компании, но для меня офис - это место для работы. Работаю я по графику указанному в трудовом договоре (за исключением редких случаев, когда надо задержаться на пользу команде). В рабочее время я не играю в приставку, настольный теннис, не сплю, не жру бесплатную еду и не гоняю чаи.
Поболтать с коллегами - это да, но в большинстве случаев это вредно для работы (но хорошо для психики).
В общем, я работаю из дома и не могу представить себе офиса, который мог бы меня соблазнить
Увидев в заголовоке "решаем реальные задачи" - надеялся, что тут будут какие-то кейсы из промышленной разработки, а по факту, очередные бесполезные "вася завел два будильника, посчитайте сколько раз он проспит"
Плюсую, у самого сколиоз поясничного отдела и из-за сидячей работы часто болела спина. Один раз даже так схватило, что неделю вставать не мог (причем при активном лечении). После этого пошел в тренажерный зал, с грамотным тренером и через год забыл про боли в спине. Как показывает практика, достаточно ходить два раза в неделю, хотя бы 6 месяцев в году(не подряд, а месяц- два занимаемся, потом пропускаем месяц-два) делая упражнения на спину - и этого хватает.
Ключевое здесь - правильная техника и не гнаться за большими весами
Зачастую приведенные ситуации - это не злая воля, а просто автоматическая реакция. Собеседующий, в первую очередь, должен уметь абстрагироваться от своих личных переживаний и опыта и смотреть на кандидата с точки зрения решаемой задачи.
Сможет ли этот человек делать то, что от него требуется? Сколько ресурсов нужно будет потратить на его (человека) "доработку"? И всегда помнить, что испытательный срок (в РФ) - 3 месяца и он позволяет уволить любого без особых сложностей (кроме женщин ушедших в декрет в этот период).
Я, когда нанимал людей (инженеров на завод), задавал технические вопросы только с целью отсеять тех, кто вообще не шарит. Для меня важнее было то, как человек умеет общаться, что он делал до этого и почему ушел с прошлого места работы. Всем кандидатам говорил, что испытательный срок 3 месяца, описывал свои ожидания по его окончании, что должен делать, уметь и т.д.
И тех, кто производил хорошее впечатление - котелок варит, общаться с людьми умеет, умеет решать сложные задачи (не сдается) - брал на испыталку и смотрел выхлоп. Слабый выхлоп или много геммороя - обсуждаем отчего, почему, чем помочь. Если по итогу 2 месяцев и 3х недель меня что-то сильно не устраивает и я не вижу возможности это исправить - жаль, но ставочка не сыграла, "наша компания вам не подходит, всех благ!"
Про lru_cache: чтобы работало, нужно чтобы все аргументы функции были хэшируемыми.
Про декоратор @property: его назначение не только для организации сеттеров и геттеров, также используется для получения доступа к методу класса как к атрибуту. Т.е. можно будет вызывать его в виде Class.property, без скобок и т.д. Иногда очень упрощает понимание/нейминг
tl;dr Позвали на собес, сказали решить задачку в непонятном редакторе, решение интервьюеру не понравилось
Как по мне - обычное дело. Очевидно, что в Яндексе повышенные требования из-за количества единорогов, поэтому не вижу смысла чего-то обсуждать.
Читаю хабр лет десять. 5 лет назад (работал на заводе в это время), когда читал подобные, хм, "материалы" - думал, да, сложно быть программистом, нужно любить это дело, кодить на работе и после работы. Программиста окружают одни враги, не дают ему СОЗДАВАТЬ. Думал, это не мое, не смогу я так, я глупый и т.д.
2 года назад, посмотрев на свою зп(после 8 лет работы технологом на производстве) и зп джуна, решил, что, мое не мое - надо бы попробовать.
Отучился, устроился в контору бэкендером на питоне, год отработал и вот что имею сказать: промышленная разработка - это не про СОЗДАНИЕ, это очень похоже на производство машин или, скажем, электроники. Есть продукт-менеджер, который думает, что вот эта фича принесет денег. Твоя задача запилить ее и выкатить в прод. Желательно, чтобы посмотрев на свой код через полгода тебя не стошнило. Ну и тестами обмазать, чтобы не разваливалось. И все это происходит в конвеере: аналитик придумал алгоритм, ты его реализовал, Куэй протестил, выкатили на бой. Следующий!
Меня этот подход абсолютно устраивает, потому что я, как технолог, знаю, что лучше конвеера ничо не придумали со времен Форда. Более того, в этом есть кайф - ты оптимизируешь процесс, чтобы выдавать фичи как можно быстрее (что-то вроде ребят, которые на скорость игры проходят). Но я вижу у своих коллег (которые программисты по образованию и моложе лет на 7), что для многих это в тягость. Это же скучно, пилить такие простые фичи, вот если бы мир спасать.
В общем, это просто проблема восприятия. Бизнес фармит бабки, ты, как программист, пилишь свою часть продукта, также как сборщик на конвеере. Волнует ли хозяина завода как себя чувствует сборщик? - конечно, если сборщик будет грустный работа будет сделана плохо.
Очередная статья про "потоки, процессы и асинхронность" - зачем их столько? Хоть бы примеры какие-то из жизни привели, но нет все какая-то синтетическая копипаста.
Всю эту историю можно свести к тому, что там где код упирается в await - происходит переключение на следующую функцию с периодическим возвратом, пока она не вернет ответ.
А процессы работают через ProcessPoolExecutor, который инитится при старте приложения и, по необходимости, в него запихиваются нужные функции (и тоже периодически проверяется готовность результата)
Плюсую, самый удобный вариант. Сколько переводил - всегда было выгоднее чем золотой короной. Но надо проверять курс. Закидываете тестовую тыщонку и смотрите сколько тенге прилетело.
Самый выгодный был Юнистрим (получение в тенге), получать можно в отделении казпочты. Самый кайф в том, что тут же в казпочте можно купить доллары за тенге, причем по курсу выгоднее, чем если бы ты покупал нал. доллары а России
Если Эрик получает норм бабки и не хочет потерять свое место - яб на его месте, учитывая подходы маска к управлению, очень сильно посоветовался бы с HRом, что ответить на такое сообщение.
Я хоть за Маском особо и не слежу, уверен, что любой ответ кроме "сэр, мы ускорили твитор на 30% за последний год, сэр, и сделаем ещё больше под вашим мудрым руководством, сэр!!" его не устроит в любом случае
Без код ревью от более опытных коллег, к сожалению, спасения от говнокода нет.
Ситуацию могут облегчить книги и лекции Боба Мартина (чистый код, чистая архитектура) и какой-нибудь курс по шаблонам проектирования (именно на питоне, классическая книга банды четырех будет бесполезной тратой времени).
Сверху можно присыпать книгой с кабанчиком, но лучше найти способ показывать кому то свой код, если не целиком, то хотя бы структуру и какие-то основные элементы
Это и тот факт, что у корпораций есть юристы и бухгалтерия, которые смогут натянуть сову на глобус.
Автор красиво расписал теорию (оно и понятно, не зря же он в скилбоксе преподает), но на практике все обычно сводиться к асинхронным i/o (fastapi, aiohttp), если сервис пишется свежий или django и flask, если уже на них многое реализовано(они тоже едут к асинхронщине). Если нужно чего-то посчитать тяжёлое - добавляют к асинхронщине ProcessPoolExecutor, с парой тройкой воркеров (тут главное правильно натыкать async/await и завернуть в нужный event loop и при этом поднять их при запуске сервиса, а не при запросе в него, иначе время на запуск процессов сожрёт весь профит). Но тут начинаются проблемы: если сервис крутится в кубере - нужно прописать правильные настроечки, чтобы ваш сервис не сожрал все свободные ядра.
Вообще, для меня, выглядит так, что потоки в питоне - это что-то ненужное и в промышленных решениях очень малоиспользуемое. Асинхронщина и многопроцессность - this is the way.
Я проработал инженером-технологом на заводе по производству электроники 8 лет. И я могу вам сказать, что есть люди, которые 20 лет паяют платы и делают это абсолютно хреново и есть люди, которые стараются каждый раз спаять лучше, чем в предыдущий - и за 3 года на две головы обгоняют "профессионалов" с 20 летним опытом. Это и есть развитие. Ты каждый раз стараешься сделать что-то лучше, чем в предыдущий.
Делать одно и то же 1000 раз - это не деградация. Делать 1000 раз одно и тоже _одним и тем же способом_ - это путь в утиль.
Вы, когда ходите в спортзал, постепенно увеличиваете нагрузку? Я уверен, что да. Это может быть увеличение на 5% в месяц, но оно есть. Потому что иначе, ваше тело тратит все меньше и меньше ресурсов на выполнение упражнений и приводит к тому, что форма не поддерживается.
Это тоже развитие. Любое движение вперёд и вверх - это развитие. Сегодня пожал на 200г больше, чем позавчера? - Красавчик, через год будешь жать на 365÷2×0,2=36.5кг больше. Но как только перестаешь накидывать вес - мозг оптимизирует работу мышц на
столько, что процесс жима будет потреблять меньше калорий, чем поход в магаз за хлебом.
К сожалению, в большинстве случаев, "адекватная культура" - это результат эволюции.
Я могу судить по себе - когда я был начинающем руководителем, я пытался везде внедрить новое, улучшить старое и вообще все перекроить по своему разумению (ну и по книжкам написанным Умными Людьми, разумеется). И, естественно, я встречал мощнейшее сопротивление, потому что никто, я повторюсь, НИКТО (да, даже ты, самый продвинутый чувак на планете) не любит изменения. Любые изменения, нужно продавать, и продавливать.
А для того чтобы их внедрять, нужно тонко разбираться в психологии людей с которыми ты работаешь. С кем то работает одно, с кем-то другое, всегда есть те, кто будет саботировать внедрение нового - и это норма, это всегда и везде так, потому что это внедрено в нас, людей, на уровне физиологии (мозг не предназначен для постоянной работы, жрет слишком много ресурсов).
Но в силу особенностей профессии (я думаю, никто не будет спорить, что навыки коммуникации среднего ITшника уступают навыкам коммуникации самого плохого менеджера по продажам машин) руководители выросшие в джунглях IT не обладают достаточным опытом внедрения изменений и управления этим процессом. Безусловно, многие этот опыт набирают в процессе, и про таких менеджеров никто нк говорит, но большинство пытается внедрять изменения насильно, заставляя всех чему-то учиться и как-то отчитываться, что приводит к полыханию на Хабре.